Peter, As others have said, the accounting for the OMVS processes is not aggregated into the job statistics of the original job.
While BPXBATCH will run the shell in a separate OMVS address space, it is also possible to run the shell and your cp commands in the original JES address space. BPXBATSL will allow you to do this with a non-login shell. Our COZBATCH utility is a superior alternative, and allows you to run a login shell in the same address space while at the same time using inline shell input. For example, the following will run everything in the original JES2 address space: // EXEC PGM=COZBATCH //MYDD1 DISP=SHR,DSN=... //MYDD2 DISP=SHR,DSN=... //STDIN DD * # input to the z/OS Unix shell: cp //DD:MYDD1 /my/unix/file1 cp //DD:MYDD2 /my/unix/file2 // Note: access to the job step DDs by the cp commands demonstrates that they are running in the JES address space. Kirk Wolf Dovetailed Technologies https://coztoolkit.com Co:Z is available under our free Community License, Commercial support agreements are also available. On Tue, Jun 25, 2024, at 7:30 PM, Farley, Peter wrote: > Hi All, > > Just a question of curiosity. In recent days I have been running some ad-hoc > BPXBATCH jobs that executes some "cp" commands to copy a few z/OS data files > down to a Unix directory, then a python script which uses that data. > > While the job is running I can use SDSF DA and PS to see the various Unix > parts running, but at the end of the job the shop-local IEFACTRT report in > the JESMSGLG output only seems to account for the actual BPXBATCH CPU time > and I/O count. The much more significant Unix I/O and CPU values are not > included in that report as far as I can tell. > > Similarly, the JESYSMSG end-of-step output messages for the BPXBATCH step > again only seem to account for BPXBATCH usage alone, and not any of the Unix > CPU or memory usage. > > Is there data available to an IEFACTRT routine or the JESYSMSG end-of-step > processing to report Unix usage in a batch step at all? Or is that only > available in DCOLLECT output (to which I do not have and cannot get any > permissions from local security due to zero trust rules)? > > Or am I seeing the python-on-ZIIP capability here, and the CPU isn't reported > because it is done on a ZIIP (though that would not explain the I/O count > being so low when I know the python script does quite a lot more I/O)? > > If it matters, we're on z/OS 2.5 here at a reasonably current RSU I believe, > but I don't know the exact level. HW is z15. > > Peter > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
