Re: RCVJRNE - get name of procedure that performed the file output

On Wed, Nov 5, 2014 at 11:42 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 11/5/2014 10:49 AM, Steve Richter wrote:

No. The journal is an independent and asynchronous process from the

> actual database update.

that is interesting. But there must be some way the database tracks
individual outputs to a table. How else would the journal pick up those
changes as it asynchronously writes entries to the journal?

It's a one-way feed. The database manager sends the database buffers to
the journal component which then does its thing separately from the
database manager.

I follow. But the database system must be uniquely identifying changes that
are sent to the journal system.

Two updates are applied to a database table, one after another, from two
different programs and jobs. The journal system, running asynchronously,
picks up info about those changes, assigns a journal seqnbr and writes to
the journal receiver. Since the journaling process is picking up the
program and job name that performed each update the database system must
have queued up 2 entries that were fed to the journal system.

What I am asking for is to have the ID number of the queue entries that are
fed to the journal system to both be stored in the journal entry and made
available to the ADDPFTRG trigger exit program. That way the trigger exit
program could retrieve the call stack and write it to a file with a key
that would be found in the journal entry. Assuming that the trigger exit
program runs in the same job as the procedure that performs the file
output. Or, IBM could just write the procedure name to the journal entry.

-Steve

--
--buck

'I had nothing to offer anybody except my own confusion' - Jack Kerouac
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.