‘No Job Log’ and More Hidden IBM i 7.5 Gems
This post continues reviewing some hidden gems in the 7.5 release, reviewing three IBM Ideas—also known as Requests for Enhancements (RFEs)—delivered in the 7.5 release. These changes may be small, but can lead to big improvements in managing your environment:
1. Eliminate QZSHSH and QP0ZSPWP/T job logs with ‘no job log’
If you have a job description with a logging level that results in a job log always being created, such as LOG(4 0 *SECLVL), you might end up with a job log with a single message, CPF2523, “No job log information.” This generally occurs if you use QShell, which runs most commands in a spawned job with a job name of QP0ZSPWP. With QShell commands, the CPF1124 and CPF1164 messages are surpassed, so unless you have an error, there are no messages to log in the job log. The high logging level forces the creation of a job log for every command that is run, but since there are no messages in the job log, it is generated with the CPF2523 message.
I worked with a client that used QShell to clean up their IFS. They submitted the batch job to do this with a job description of LOG(2 40 *SECLVL). This job ran weekly and generated around 60,000 job logs, all with “No job log information.” The client struggled to understand the need for so many job logs (and related jobs in the system). Once we identified the problem, we changed the job description to LOG(4 0 *NOLIST) and the issue went away.
However, using QShell with a high logging level is very wasteful of system resources in creating empty job logs, so I submitted the subject idea to IBM. I am happy to report that job logs will no longer be created with the “No job log information” message with 7.5 and we will no longer need to manage empty job logs.
2. Routing work by user profile results in 2 CPIAD09 messages in QHST, both sent from a job in QUSRWRK
Routing work by user profile using the QSYS2.SET_SERVER_SBS_ROUTING() service generates two CPIAD09 messages in QHST. The first one is sent from an intermediate job running in QUSRWRK and the second is sent for the job running in the configured subsystem.
The second message is the most interesting one, since that is the job where the actual work requests are running. However, the sender of the message originates from the first job. This situation makes it difficult to analyze connections rates to the system using the CPIAD09 message since the counts are double when work is routed by user profile to a different subsystem.
IBM addresses this issue in 7.5. When using the “routing work by user profile” for the host servers, the initial job will now send a new message, CPIAD0C, “User &4 from client &8 transferred to job &3/&2/&1 in subsystem &6 in &7 on &5” and the second CPIAD09 is sent for the job the user work runs in.
3. Added support to PRTTRC to sort by *TIME
If you have a need to collect a job trace (STRTRC/ENDTRC/PRTTRC/DLTTRC), the print trace command only supports printing the output sorted by thread. The SORT parameter lists two options, *THREAD and *TIME, but if you attempted to use SORT(*TIME), the PRTTRC command sends an error message that *TIME is not yet supported. Sorting by *TIME now works in 7.5.
While these changes are small and not covered in the announcement letter or the memo to users, they are valuable tweaks that help better manage the system. These three IBM Ideas were ones I submitted; there are several others that were also delivered with 7.5 and 7.4 TR6. IBM considers every IBM Idea they receive, so don’t hesitate to use that avenue to let IBM know what you need to make IBM i even better.
Thanks, IBM!