It’s not clear how this relates to this thread. If this is an unrelated question, please open a new question so it can be given attention.

Tom

Tom

It is the job message. It doesn’t have a name. Every job has its own job message queue. The API retrieves the messages from the job message queue of the job name that you give to the API.

It can only access the job message queue of a job that is active or on a job queue. The only message that it’s likely to find for a job on a job queue is the request (*RQS) message for the job. Hmmm… I haven’t tried, but it might also find messages for jobs that have their joblog in a pending state.

It doesn’t matter what subsystem is involved either way, as long as you have sufficient authority.

Tom

I don’t think there is a best way. It shouldn’t be done by an independent process.

I’m only aware of one way with two alternatives. But I wouldn’t call it the “best way”. The List Job Log Messages (QMHLJOBL) API can list messages from a job’s job message queue into a user space.

An independent process could call the API repeatedly until all messages had been returned. After each block is returned, the independent process would loop through the user space looking for messages that indicated something needed to be done. When a block was finished and more messages are available, the API would be called again to get the next block.

As an alternative, if you don’t want to handle user spaces, you could call the Open List of Job Log Messages (QGYOLJBL) API and handle it as an ‘open list’.

Tom