The title When tracing a job it helps to trace the correct address space is a clue – it looks obvious, but the problem was actually subtle.
The scenario
I was testing the new version of Zowe, and one of the components failed to start because it could not find a keyring. Other components could find it ok. I did a RACF trace and there were no records. The question is why were there no records?
The execution environment.
I start Zowe with S ZOWE33. This spawns some processes such as ZOWE335. This runs a Bash script which starts a Java program.
I start a GTF trace with
s gtf.gtf,m=gtfracf
#set trace(callable(type(41)),jobname(Zowe*))
Where callable type 41 is for r_datalib services to access a keyring.
No records were produced
What is the problem?
Have a few minute pause to think about it.
Solution
After 3 days I stumbled on the solution – having noticed, but ignored the evidence. I wondered if the Java code to process keyrings, did not use the R_datalib API, I wondered if Java 21 uses a different jar file for processing keyrings – yes – but this didn’t solve the problem.
The solution was I should have been tracing job ZWE33CS! Whoa – where did that come from?
The Java program was started with
_BPX_JOBNAME=ZWE33CS /usr/lpp/java/J21.0_64/bin/java
See here which says
When a new z/OS® UNIX process is started, it runs in a z/OS UNIX initiator (a BPXAS address space). By default, this address space has an assigned job name of userIDx, where userID is the user ID that started the process, and x is a decimal number. You can use the _BPX_JOBNAME environment variable to set the job name of the new process. Assigning a unique job name to each … process helps to identify the purpose of the process and makes it easier to group processes into a WLM service class.
If I use the command D A,L it lists all of the address spaces running on the system. I had seen the ZOWE33* ones, and also the ZWE* ones – but ignored the ZWE* ones. Once I knew the solution is was so obvious.
ColinPaice 