On Wed, May 29, 2019 at 8:38 AM Billy Ashton <[email protected]> wrote:
> John, thanks for all your help - this has increased my knowledge a lot > about BPX... One last question that I could not find in the manuals or in > Google... > > Part of this process is to download a file from a server. This file is > tersed, though, and I was not able to find a way to run AMATERSE from the > shell script (would I even want to?). The problem I had is that BPX seems > to spawn in a different address, and the JCL step that execute it just > completes and goes on its merry way. This causes a problem because my > UnTerse step starts running before the BPX shell finishes. > > The process I have looks like this: > 1. Allocate the untersed output file > 2. Create sftp commands > 3. Run BPXBATCH to do some stuff, then to sftp download the tersed file, > and then do some more stuff > 4. Run AMATERSE to UnTerse the file > 5. Run application program against untersed file. > > The problem is that I get an EDC5061I with errno2=0xC00B0403, indicated the > file is open somewhere else, and it appears that steps 3 and 4, above are > running concurrently, causing the allocation error. > You are using sftp to download the tersed dataset? Where are you putting it? IIRC, IBM's sftp only supports UNIX files. And it doesn't support a binary transfer, so I am confused. To the best of my knowledge, the BPXBATCH shell process should wait for the sftp process to exit before doing the next command in the script. I did a quick test and that's what my job did. But I am on z/OS 1.12. Are you allowed to show me your BPXBATCH step (masking any secure information)? Is the EDC5061I coming from the sftp or from the AMATERSE step? If you could give me the entire job, again masking anything that can't be shared, it would likely help my understanding. > > You have done some magical things between MVS and Unix, and I am hopeful > you have some ideas here for keeping this all in one job. If not, however, > then so be it. > > Thanks again! > Billy > > > > On Tue, May 28, 2019 at 3:07 PM John McKown <[email protected]> > wrote: > > > On Tue, May 28, 2019 at 1:55 PM Billy Ashton <[email protected]> > > wrote: > > > > > Hi John, yes (sorry), I should have mentioned this is in a shell > script. > > A > > > couple more questions, if you don't mind: > > > 1. Can I force the RC to become zero if the delete fails (there is an > > > occasion where the process runs to create the file new the first time > in > > > the month)? > > > > > > > Why care about the RC from the "tso" command? It only sets the $? shell > > variable temporarily. Unless you are using "set -e" to abort the script > on > > an error. In that case, do something like: > > > > set +e # turn off abort on error > > tso "del 'some.dsn'" #might set $? to 8 if it doesn't exist > > : # The colon command does nothing (IEFBR14) but sets $? to 0 > > set -e # turn on abort on error > > > > > > > > > 2. Can I specify SMS parameters (data class, storage class) on that > > > allocate when I run in batch JCL mode? > > > > > > > I don't think that there is any difference in what you can do via > BPXBATCH > > versus an interactive UNIX shell, other than interacting with the user of > > course {grin}. > > > > You can include anything on the ALLOCATE that you can in TSO. Oh, the > "tso" > > command is like any other UNIX command. It usually runs in a separate > > address space. So there is no need to do a TSO FREE command after the > > ALLOCATE because that address space terminate and the DSN is > automatically > > freed. (OK, the BPXAS address space doesn't really terminate, but it goes > > through the equivalent of JOB termination in an initiator because BPXAS > is > > an initiator (IEFIIC) with a special PARM=. > > > > > > > > > > > > Thanks! > > > B > > > > > > > -- > > This is clearly another case of too many mad scientists, and not enough > > hunchbacks. > > > > > > Maranatha! <>< > > John McKown > > > > ---------------------------------------------------------------------- > > 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 > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
