> 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
