> The SDSF "PS" panel may be more useful. Thanks. Was not aware of that. Here is the display for a similar process -- not exactly the same JCL as the OP:
JOBNAME JobID Status Owner State CPU-Time useridCA STC04595 SWAPPED,WAITING FOR CHILD userid 1WI 0.06 useridCA STC04465 OTHER KERNEL WAIT userid 1K 1.49 useridCA JOB04563 SWAPPED,FILE SYS KERNEL WAIT userid 1FI 0.01 I have not tried from a shell. When I use the shell on occasion it is appropriately responsive. ls and cd and so forth come back right away. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Kirk Wolf Sent: Thursday, February 1, 2018 9:34 AM To: [email protected] Subject: Re: Why does BPXBATCH/ar go to sleep The SDSF "PS" panel may be more useful. What happens if you run the ar from an interactive z/OS Unix shell ? Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Feb 1, 2018 at 11:11 AM, Charles Mills <[email protected]> wrote: > > basically, /bin/sh is doing a UNIX "wait" command for the child > processes to complete. IOW, it is sleeping the sleep of the just. > > Well, yeah, it's waiting because it's waiting for something. > > But why so long? Would you really expect an ar to *always* take 2 > minutes or so on a z13s, even when it is lightly loaded? There are 213 > object files in the archive already. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John McKown > Sent: Thursday, February 1, 2018 8:47 AM > To: [email protected] > Subject: Re: Why does BPXBATCH/ar go to sleep > > On Thu, Feb 1, 2018 at 10:40 AM, Charles Mills <[email protected]> wrote: > > > I have a batch job that has two steps: the first is a C++ compile > > and the second is an ar (archive) BPXBATCH of the object code. > > > > The jobstep for BPXBATCH looks like > > > > //BPXARCH EXEC PGM=BPXBATCH,COND=(4,LT), // PARM=('SH cd > > &CSOURCE/Object;', > > // ';ar -rvc MyArchive.a #MEMBER#.o') > > > > where #MEMBER# is set to a file name by the submission process. > > &CSOURCE is an exported symbol. It all "works perfectly" -- I don't > > need help troubleshooting the submission process or symbols or the > > PARM > syntax. > > That's > > not the problem. > > > > I want to know why the job always seems to go to sleep for a minute > > or two on that second step. Here's a typical SDSF DA display > > > > The BPXBATCH command runs /bin/sh to run the command you gave it (cd > &CSOURCE/Object;ar -rvc ...). This is UNIX. Those command run in a > _separate_ address space from BPXBATCH from a UNIX fork() (or maybe a > spawn(). (not as z/OS subtasks or via LINK). So, basically, /bin/sh is > doing a UNIX "wait" command for the child processes to complete. IOW, > it is sleeping the sleep of the just. > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
