× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Even though you are Al <g>, is that documented anywhere?

GA

--- Al Barsa <barsa@xxxxxxxxxxxxxxxxxxx> wrote:
> The UB and the UP entries are generated from the same database
> instruction,
> which is why they are guaranteed to hit the *JRNRCV in a 1,2 sequence.
> 
> Al - unsure if I like being a fish for a week on Orlando
> 
> Al Barsa, Jr.
> Barsa Consulting Group, LLC
> 
> 400>390
> 
> 914-251-1234
> 914-251-9406 fax
> 
> http://www.barsaconsulting.com
> http://www.taatool.com
> 
> From G Armour: garmour400m@xxxxxxxxx>
> 
> I was going to ask for documentation references, but if Al says it...
> 
> BTW, Al, did you mean to say "precede"?
> 
> Actually, I presumed that a UB would always precede a UP, but my bigger
> question is whether there was a possibility of an interceding entry
> between the UB & UP entries for the same database record.  If I had 1000
> users in the same program that were updating 1000 different records (1
> each per user) in the same file, and they all hit the Enter key to
> update
> the record at the same time, will IBM guarantee that I won't encounter a
> scenario like:
> 
> Journal
> Sequence#  Type   Record's Key
>    201      UB    AAAAAAAAAAA      (From user Joe)
>    202      UB    BBBBBBBBBBB      (From user Fred)
>    203      UP    AAAAAAAAAAA      (From user Joe)
>    204      UP    BBBBBBBBBBB      (From user Fred)
> 
> This example shows that there is an interceding UB entry (202) between
> the
> UB & UP entries for the record with key AAAAAAAAAAA.  If this is
> possible,
> I need to build an array of UB entries in my RCVJRNE exit program, and
> Look-Up that array whenever I process a UP entry so that I can compare
> the
> changes made to the record.
> 
> Obviously, I would rather not have to deal with such an array in this
> program, but if I can't be sure that the above scenario will never
> happen,
> then I'll need to.
> 
> Advice & suggestions welcomed.
> 
> GA
> 
> --- Al Barsa <barsa@xxxxxxxxxxxxxxxxxxx> wrote:
> > You are absolutely guaranteed that a UB will immediately proceed a UP.
> >
> > Al
> >
> > Al Barsa, Jr.
> > Barsa Consulting Group, LLC
> >
> > 400>390
> >
> > 914-251-1234
> > 914-251-9406 fax
> >
> > http://www.barsaconsulting.com
> > http://www.taatool.com
> >
> >
> > From G Armour: garmour400m@xxxxxxxxx>
> >
> > Are an update record's UB (Update Before) & UP (Update After) entries
> > guaranteed (no quibble, rock-solid, cross-my-heart) to be in 1-2
> > sequence,
> > with NO possibility of another entry being written between them?  I
> > could
> > not find any reference to this in the manuals, and so I must now
> presume
> > the possibility exists and must store the UB entries in an array,
> > waiting
> > for the UP entry to arrive and match to the UB entry by JOCTRR (the
> > RRN)?
> > Since the program is RETURNed without setting LR on after each entry
> is
> > processed, the UB entries will still remain in the array on subsequent
> > calls to the program, correct?
> >
> > I am writing an exit program to a RCVJRNE command.  I need to compare
> > before & after images on an update to a record to determine if I need
> to
> > take a specific action.  The files being journaled are getting both
> the
> > before & after images journaled.
> >
> > Also, as I now see that the exit program is RETURNed without LR on
> after
> > *each* journal entry, doesn't that have the potential to be a resource
> > drain?
> >
> > TIA, GA


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.