Add exit point for job message queue full event

IBM has provided the very useful SQL table function QSYS2.JOBLOG_INFO to return the messages in a job log (we also have the messaging API's, but I will focus on JOBLOG_INFO here because of its ease of use). JOBLOG_INFO can be used to investigate what's happened in the job, extract important information from the job log and maybe store that info in an application log for later analysis or debugging. Even completed jobs can be investigated by this function if the job had the JOBLOG(*PENDING) attribute.

However, when the job message queue gets full, the message queue is either simply wrapped (or more commonly printed in a QPJOBLOG spoolfile before wrapping), and then the eldest messages in the queue gets overwritten.

This is a problem for long-running jobs, that has produced a lot of often not important messages like SQL0811 (Result of SELECT more than one row.) or CPF5009 (Duplicate record key in member ZZZZZZZZZ.), because it is not possible to read the printed or wrapped messages with JOBLOG_INFO or any other message API to find the important messages. Only the QPJOBLOG spoolfiles from the job are available, and analyzing messages from the spoolfiles programmatically is almost impossible.

I would like IBM to add an exit point to the job message queue full event, so it will be possible to add a program, that will be called by IBM i when the job message queue is about to be (printed and) wrapped! It should also be called before the job ends and the job log printed (or dismissed). So we can add some log investigation / analysis / storing to jobs, even while they're running and even if their logs are not being printed (job attribute LOG(N N *NOLIST)).

Such an exit point will of course have some impact on the performance, but this is always the case with exit points and should be left to the customer to decide if it's worth the effort / performance penalty. Given the opportunities for job analysis I think it's worth it!

There is also a security aspect to consider, since an exit program would get access to the job history. I find this a minimal risk, since it would require the same authority requirement to add a program to this exit point as to any other exit point.

The exit point should allow more than one program, since it could be used for multiple purposes by multiple parties. It would be a pity not being able to add a program to the exit point because a vendor had already added their own program.

Since the exit program is called in the same job producing the job log, there is no need for any parameters to the exit program that I can think of. If the exit program should only act in specific jobs or under specific circumstances, it can check for this itself. But maybe IBM has some ideas?

I'm aware of the Control Job Log Output (QMHCTLJL) API, but QMHCTLJL has some shortcomings that a new exit point would solve:

1. It only works for the job in which it is called.

2. The output files produced after use of the API is like the QPJOBLOG spoolfile, i.e. can write more than one row per message.

3. The message filter can only omit messages, not select them.

An exit program will complement the QMHCTLJL API and work across all jobs without need for creating or changing a program to call the API in a job. The exit program will be called automatically by IBM i and can perform any user-defined operations, like

• Select and write messages in the job log to a file for later analysis.

• Alert the operator of predefined conditions met in the job.

• Whatever the exit program creator can think of to look for and react to in a job log.

I'm also aware of watches, but these are more geared towards a single message and run in another job, so they are not suited for job log handling like the suggested exit point.

I hope IBM will consider this idea and implement it, because this would be a great tool for system administrators!