Skip to Main Content
IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Created by Guest
Created on Jan 23, 2024

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!


Idea priority High
  • Guest
    Reply
    |
    May 2, 2024
    Thank you for submitting this Idea. It's not a bad idea in theory, and I can see how this would be useful. However, if a job can't keep up with the wrap, the job is ended. I think we'd start seeing a lot more jobs with *wrap or *prtwrap being ended because they can't keep up. Therefore I am declining the request at this time.

    IBM Power Systems Development
  • Admin
    Carmelita Ruvalcaba Cevallos
    Reply
    |
    Feb 20, 2024

    The CAAC has reviewed this IBM Idea and recommends that IBM view this as a medium priority Idea that should be addressed.

    This would help admins but, only if they also can handle programming and use the exit program.

    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual IBM Ideas on the broader IBM i community and has therefore reviewed your Idea.

    For more information about CAAC, see www.common.org/caac

    Carmelita Ruvalcaba- CAAC Program Manager