Problem : Trigger program to log changes and inserts

A journal monitoring function generally consists of two programs. One program sets up the environment with the RCVJRNE command; the other program is the ‘exit program’ that actually receives the entries. The exit program is indicated with the RCVJRNE EXITPGM() parameter.

The controlling program sets up the parms on the RCVJRNE command. Those are set according to whatever rules you choose. It also receives control back whenever the RCVJRNE command ends. The command ends essentially when the *exit* program tells it to end.

The exit program can decide to end for a number of reasons. The RCVJRNE command has a DELAY() parm, for example, that is used as a potential escape mechanism. If you set DELAY(30) and no new entries appear on the journal within 30 seconds, then the exit program is called anyway. The parms for the exit program contain an indicator that tells the exit program that this is merely an empty ‘delay’ cycle. The exit program could, for example, take the opportunity to check job status to see if anyone had requested ENDJOB. If ending was requested, the exit program sets the indicator parm to the ending value and the RCVJRNE command returns control to the outer program. Otherwise, the indicator is left alone and the next delay cycle starts.

For whatever reason, the exit program might decide that it’s time to end. In my programs, I’ll usually take the name of the journal, the name of the receiver, the journal entry timestamp and the entry sequence number from the last entry that came through and stash it someplace, perhaps as an entry on a user index. (Before *USRIDXs were easily available, I would’ve stashed it all in a *DTAARA.)

I stash that info so that the outer, control program can retrieve it the next time things start up. The info is used for a kind of ‘checkpoint restart’. You can code it to always start with the next entry to arrive or to start at some point in the past (the checkpoint). A checkpoint lets you end and restart the job without missing entries that are added while the job’s not running.

You can use a storage container such as a *USRIDX/*DTAARA to communicate between the control and exit programs. A *USRIDX lets you pass all kinds of info back and forth with a single object, but *DTAARAs can make it easier to change the data manually if you want to exercise some external control.

For external control, though, I usually use a *DTAQ. My exit program would receive entries from the *DTAQ to see if there was an entry with a value of ‘*ENDMONITOR’ or whatever. Using a *DTAQ leaves open the possibility of sending all kinds of future commands as the need might arise. The control program would clear the *DTAQ as one of its first steps upon startup to ensure that no entries were left over from any previous power failure or other disaster.

Hmmm… getting too far from the topic here…

Time to mention again that a trigger program can do what you want to do. Dave already has covered that according to the question that was asked and should be given credit. If journal monitoring takes over the thread, it _should_  be done in a new topic; that becomes a topic that later members can search for and find.

But general answers for your remaining questions…

The RCVJRNE command can be prompted (and actually even run) from a command line. This lets you review the available parms an [help] to get a picture of how narrow or broad you can make your selection criteria. In particular, you can name a single specific file or *ALLFILE or list up to 300 files for a given monitor process. Since you’re really interested in one file, the exit program will only fire when that file causes an entry.

You can have one program per file or have all files handled by a single program; it depends on how you do your coding. By running it in its own activation group and not closing it down when it returns, there shouldn’t be much of a performance hit.

It _shouldn’t_ affect existing journal processing at all as long as you don’t establish locks on the journal objects that conflict with iTera. (I can’t think of why you’d want to.)

Actually, I’d probably look at iTera to see if they provide any kind of interface for just this kind of thing. It’d be irrational of such a vendor not to accommodate this if there was an likely chance of interference. If such an interface is supplied, iTera documentation would be the place to look.

There shouldn’t be any impact on journaling itself.

You can determine what journal is involved by running DSPFD over the file you’re interested in. Scan down to see the name of the journal plus info on what types of journal entries are created. When you know the name of the journal, you can use the WRKJRNA command to find current details about receivers. However, you’ll often simply use the special values *CURRENT and/or *CURCHAIN rather than needing to know an actual receiver name.

If iTera is running, you shouldn’t need to worry about receivers at all for this (except potentially for checkpoint restart stuff, at which points your programming will have kept track anyway). If iTera was installed and configured correctly and journaling is running correctly, then that part is already handled.

I generally create a subsystem specifically for this kind of ‘never-ending program’ function. I don’t like using the standard subsystems because I want to have total control over all of the work management aspects. But you can use default elements without much trouble. You could, for example, submit the job to the standard QSYSNOMAX *JOBQ. That usually feeds into the QSYSWRK subsystem. Better would probably be the QUSRNOMAX *JOBQ for the QUSRWRK subsystem.

I’m into wringing as much as I can out of systems, so I avoid running my own stuff in the same subsystem as IBM-supplied server functions. I create shared memory pools and private pools and control all work routing to keep things in there dedicated areas — including all IBM-supplied functions. That takes a lot of setup work, though, and few want to go that route. You can do fine by using QSYSNOMAX and running in QSYSWRK or going to any further level.