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

On 05-Nov-2014 11:00 -0600, Steve Richter wrote:

On Wed, Nov 5, 2014 at 11:42 AM, Buck Calabro 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.

While identified with the sequence number scoped to the *JRN or to the /system/ (*SYSSEQ), the LIC journal component does that work rather than the LIC database component. That number is not passed back to the database component, because the process\thread of the user that performed that logged I\O has since moved-on with processing other [likely more I\O] work.

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.

That information effectively is passed via the alluded queue. However the sequence number is generated\assigned within the LIC task receiving the log data from the queue; the LIC journaling (JO) tasks. That sequence number is not generated\assigned within the job performing the I\O; obtaining that number within the thread performing the I\O would require that thread to communicate-with and possibly wait-on the JO task.

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.

To have that Sequence Number available for the [trigger for the] I\O would require that the I\O would _wait_ on the async logging request, or would require that the logging occur inline to the I\O; neither is an option. Conceivably another option is to assign the sequence number within the thread performing the I\O, but that would be a huge architectural change, changing the effective queueing\serializing of the numbers across the I\O work rather than how currently that is offloaded as async work; the change would be totally incompatible with all of the supporting and related features, probably even including SMAPP and delayed index rebuild.

Or, IBM could just write the procedure name to the journal entry.

They could; just like the other Fixed Length Data (FIXLENDTA) fields. However, that increases the amount of data for every log entry; something that is avoided where reasonable\possible. I suppose that data may not have been added because the maximum procedure name is ridiculously long? The *PGM (JOPGM) and *PGMLIB are /tiny/, as fixed 10-byte fields.

Of course there are other considerations. If the procedure name were to be added, then likely all of the capabilities for the program name would probably [be expected to] be extended to the procedure name. Minimally the capabilities for an Outfile Format (OUTFILFMT) [and effective equivalents; e.g. RJNE0100 RJNE0200 Format] would need to be enhanced.