When routing work by user profile, using the QSYS2.SET_SERVER_SBS_ROUTING() service, there are two CPIAD09 messages in QHST. The first one is sent from an intermediate job running in QUSRWRK, the second is sent for the job running in the configured subsystem, but the message is sent from the intermediate job in QUSRWRK.
The second message is the most interesting one, since that is the job where the actual work requests run. However, the sender of the message is from the first job. This makes it impossible to search the history log for all the messages from the desired job.
Below is a more detailed description:
My test scenario is I found a job using a lot of CPU in my Collection Services data. CS does have the current user information, but it's much quicker to just do a DSPLOG to find the CPIAD09 message to locate the current user. But a DSPLOG on that job only return the CPF1124 message. This led me down my analysis path to determine what is happening, and the request to correct this situation by submitting this RFE.
I have set up my own subsystem and route my work to my subsystem (DAWNMAY) for all the supported server jobs.
There are now two CPIAD09 messages in QHST:
User DAWNM from client 127.0.0.1 connected to job 991629/QUSER/QZDASOINIT in subsystem QUSRWRK in QSYS on 12/04/18 06:55:30.
User DAWNM from client 127.0.0.1 connected to job 924740/QUSER/QZDASOINIT in subsystem DAWNMAY in DAWNM on 12/04/18 06:55:30.
This makes it hard to find the CPIAD09 message in the history log if I am looking for who used job 924740/QUSER/QZDASOINIT.
A DSPLOG JOB(924740/QUSER/QZDASOINIT) does not show me the CPIAD09 messages I need to find.
I.e.,
CPIAD09 -
Message . . . . : User DAWNM from client 127.0.0.1 connected to job
924740/QUSER/QZDASOINIT in subsystem DAWNMAY in DAWNM on 12/04/18 06:55:30.
The Message Details show this message was actually sent from the job running in QUSRWRK subsystem:
Message ID . . . . . . : CPIAD09 Sever
Date sent . . . . . . : 12/04/18 Time
Message type . . . . . : Information
From . . . . . . . . . : DAWNM CCSID
From job . . . . . . . . . . . : QZDASOINIT
User . . . . . . . . . . . . : QUSER
Number . . . . . . . . . . . : 991629
From program . . . . . . . . . : QZBSCOMM
The CPIAD09 message really needs to come from the job handling the work request, not the intermediate job in QUSRWRK.
My request is two changes:
#1. For the intermediate job, use a message other than CPIAD09 to log the fact that it initially handled the work request. Also, the message text should reflect that this was due to the QSYS2.SET_SERVER_SBS_ROUTING() configuration in place.
#2. The CPIAD09 message sent for the job in my configured subsystem should come directly from that job itself, not the prior job.
Use Case: I am debugging an issue with my prestart server jobs. I want to review all the messages sent from my job. I cannot find the CPIAD09 message because it is sent from a different job.
I am using connection pooling and review the CPIAD09 messages to review the effectiveness of my configuration. I now have 2 CPIAD09 messages which skews the results.
When using the Routing Work by User Profile for host servers, the initial job will now send a new message, MSGCPIAD0C (User &4 from client &8 transferred to job &3/&
2/&1 in subsystem &6 in &7 on &5.)
Alternatively, add a session ID to the CPIAD09 that would be identical for the two messages in the scenario that Dawn May describes.
We understand this request.
I am also running into this issue making analysis most difficult.
Thank you for submitting this request.
The original MSGCPIAD09 message will remain. That message indicates when the original connection is made and is important from a serviceability standpoint to keep that as it is. At the point this message is sent it isn't known if the SET_SERVER_SBS_ROUTING service was used for the user. There are some steps that have to happen before the check is made.
We do however, understand how the second CPIAD09 message sent from the original job can cause confusion even though the actual job is part of the message data and no message is sent from the actual job servicing the connection. We will consider other options to provide a clearer indication of this situation.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - IFS (Integrated File System) and Servers
Operating system - IBM i
Source - COMMON
For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Work Management and Messaging
Operating system - IBM i
Source - COMMON
The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. Doing anything that encourages a more enhanced use of debugging capabilities is a benefit to the community.
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 RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager
Attachment (Use case): Examples of using CPIAD09 to review prestart job use
Short answer:
No, Mark's circumvention is not sufficient. His answer only addresses the issue with the second message not being sent from the final job.
Long answer:
The larger problem is due to having two CPIAD09 messages for the one connection to the system.
There is only one CPIAD09 message when:
- No subsystem configuration is done for the host server prestart jobs
- When routing by IP address
- When you use the secure servers
I have been doing work to provide clients a way to better understand the work being done by prestart jobs (mostly the QZDASO* jobs). I am using the CPIAD09 message to review the workload. Having 2 CPIAD09 messages when routing work by user profile skews the results of this analysis.
I have used the QSYS2.History_Log_Info service to provide insights such as:
- The number of connections by IP address to understand where the connections are coming from
- Review what users are using which prestart jobs
- Understand how many connections are made to the database servers
- Review your subsystem configuration to verify work is running where you expect it
- Assess whether connection pooling is being used effectively
When a client is routing work by user profile, the results are now inconclusive.
These additional use cases have been developed since I originally wrote this RFE.
I have attached a PDF that provides examples of how I am using the CPIAD09 message to review the above information.
Short answer:
No, Mark's circumvention is not sufficient. His answer only addresses the issue with the second message not being sent from the final job.
Long answer:
The larger problem is due to having two CPIAD09 messages for the one connection to the system.
There is only one CPIAD09 message when:
- No subsystem configuration is done for the host server prestart jobs
- When routing by IP address
- When you use the secure servers
I have been doing work to provide clients a way to better understand the work being done by prestart jobs (mostly the QZDASO* jobs). I am using the CPIAD09 message to review the workload. Having 2 CPIAD09 messages when routing work by user profile skews the results of this analysis.
I have used the QSYS2.History_Log_Info service to provide insights such as:
- The number of connections by IP address to understand where the connections are coming from
- Review what users are using which prestart jobs
- Understand how many connections are made to the database servers
- Review your subsystem configuration to verify work is running where you expect it
- Assess whether connection pooling is being used effectively
When a client is routing work by user profile, the results are now inconclusive.
These additional use cases have been developed since I originally wrote this RFE.
I have attached a PDF that provides examples of how I am using the CPIAD09 message to review the above information.
Please read Comments below from Mark Anderson and CAAC, and post a Comment to let us know if the alternate approach is acceptable.
The CAAC has reviewed this RFE. More information is needed. In particular, is the work-around described by Mark Anderson in the comment below an acceptable alternative?
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 RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager
An SQL service can be used to make this task much easier than using DSPLOG:
select * from table (qsys2.history_log_info()) as x
where message_id = 'CPIAD09' and message_text like '%924740/QUSER/QZDASOINIT%'
The COMMON Europe Advisory Council (CEAC) has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed.
Background: The CEAC members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.
To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT
Therese Eaton – CEAC Program Manager, IBM