Andrew, In the SDSF PS display for the COZBATCH example, all the PIDS ran in the same AS except for the one you asked about:
ANDREWRB STC03080 RUNNING ANDREWR 1R 16843329 16843349 79 004F /bin/sh /home/andrewr/breakit.sh the parent of this is process: ANDREWRB JOB03101 WAITING FOR CHILD ANDREWR 1W 16843349 50397780 51 0033 /bin/sh /home/andrewr/breakit.sh Both of these are what you see when you run a shell script file with /bin/sh. I'm not sure what breakit.sh does, but these two are what you would see if the /bin/sh shell forked itself without doing an exec. This is what the shell would do for cases like using a builtin in a pipe. If you aren't pretty familiar with what the fork() and exec() system calls in UNIX actually do, you might want to look at it. It's really wacky, and I think that a good understanding is probably helpful here. On Thu, Oct 29, 2020 at 9:40 PM Andrew Rowley <[email protected]> wrote: > On 30/10/2020 2:32 am, Kirk Wolf wrote: > > Your performance work in this area is very interesting to me. I would > love > > to hear more if you ever write up your findings, even informally. > > I have been looking at SMF data and trying to build a picture of the > work that was running from the SMF records. I have written up some of > what I have found here: > > https://www.blackhillsoftware.com/news/2019/08/27/comparing-bash-and-bin-sh-on-z-os/ > and here: > > https://www.blackhillsoftware.com/news/2019/06/20/understanding-z-os-unix-work-with-easysmf/ > > When a job runs unix work much of the work can appear in SMF records for > the unix tasks, not the original job. > > E.g. for the script I was testing, running under bash only 0.02s of CPU > time appears in the SMF record for the job. But there are SMF records > for about 9000 unix tasks which add up to about 66s of CPU. > > Under /bin/sh, the job CPU time appears the same at 0.02s, but with the > records from the unix work it is about 4.7s. Either way, you miss most > of the work if you just look at the job records. > > Interestingly, I tried running the script under COZBATCH and it broke > the logic to associate the unix tasks with the main job. I will have to > look into that. COZBATCH did run steps in a separate address space and > generated about the same number of SMF records, but it looked different > to BPXBATCH with _BPX_SHAREAS. > > I don't really understand what I see in the SDSF PS display. The same > script, run under COZBATCH and BPXBATCH with _BPX_SHAREAS (sorry about > the wrap): > > JOBNAME JobID Status Owner State PID PPID > ASID ASIDX Command > ANDREWRB JOB03101 FILE SYS KERNEL WAIT ANDREWR 1F 66115 16843349 > 51 0033 cut -c1 > ANDREWRB STC03080 RUNNING ANDREWR 1R 16843329 > 16843349 79 004F /bin/sh /home/andrewr/breakit.sh > ANDREWRB JOB03101 WAITING FOR CHILD ANDREWR 1W 16843349 > 50397780 51 0033 /bin/sh /home/andrewr/breakit.sh > ANDREWRB JOB03101 WAITING FOR CHILD ANDREWR 1W 50397780 > 67175122 51 0033 /bin/sh > ANDREWRB JOB03101 FILE SYS KERNEL WAIT ANDREWR 1F 67175122 > 1 51 0033 COZBATCH > > > JOBNAME JobID Status Owner State PID PPID > ASID ASIDX Command > ANDREWRE STC03080 RUNNING ANDREWR 1R 33620729 > 50397388 79 004F setfacl -m u:IBMUSER:rwx broken/24793 > ANDREWRE STC03080 WAITING FOR CHILD ANDREWR 1W 50397388 > 83952212 79 004F /bin/sh /home/andrewr/breakit.sh > ANDREWRE JOB03106 FILE SYS KERNEL WAIT ANDREWR 1F 83952212 > 1 51 0033 BPXBATCH > > What is the extra "/bin/sh /home/andrewr/breakit.sh" command in the > separate address space under COZBATCH? > > Under COZBATCH, PS consistently showed the cut command which is part of > the pipe. Under BPXBATCH, the only command which seemed to show up was > setfacl. Presumably that is because that was the command where most of > the time was spent. > > -- > Andrew Rowley > Black Hill Software > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
