Re: multi-line STDPARM shell script for BPXBATCH
The Initiator attaches the jobstep with a few privileged options on the ATTACH. The new jobstep runs in the same address space but does not share job-related control blocks with the Initiator. SVC 99 uses a privileged option of ENQ to use the Initiators TCB for the queue head. The Initiator does not retain any key 8 storage. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, November 2, 2019 3:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-line STDPARM shell script for BPXBATCH On Sat, 2 Nov 2019 18:53:35 +, Jon Perryman wrote: > ... >How many people ignore that AOPBATCH and COZBATCH execute in the callers >address space and think it's always a good thing! When called from a program, >you are exposing anything running in the address space to various problems and >security exposures. BPXBATCH eliminates this consideration. If IBM fixes this >exposure, then AOPBATCH loses the features you treasure. > I see. But I need enlightment. Doesn't any program object invoked by // EXEC PGM= execute in the initiator's address space? Else ENQs and DDNAMEs created by the initiator would not be available to the target program. Does this create the same exposure? Does the initiator protect itself by keeping its own storage all in system key or protected by segment protection? Is AOPBATCH not protected the same way? Is there the same exposure for any user-coded program that uses LINK or ATTACH? How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh? -- gil -- 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
Re: multi-line STDPARM shell script for BPXBATCH
On Saturday, November 2, 2019, 07:35:08 PM PDT, Paul Gilmartin wrote: >> Sorry. I forgot to say EXEC PGM=AOPBATCH is safe. > That might be true if AOPBATCH were installed with AC=0 in an authorized > library. AOPBATCH and COZBATCH must be linked AC=0 because the shell runs in problem state. >>> How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh? >> It's been a long time. If I remember correctly, it has the exposure. >> What makes this acceptable is that you know there are risks but willing to >> accept those risks. > How does this interact with the z/OS Statement of Integrity? The ISPF case I mentioned has nothing to do with bypassing security or gaining authorized state. The exposures I mentioned occur simply because of the shared address space. , > If an ISPF macro invokes BPX1SPN BPX_SHAREAS=MUST /bin/sh, > only IBM code is involved and SoI applies. SoI has no "willing > to accept" loophole. .I don't understand your point here. If your code (or macro) specifies shared address space, the exposure is your responsibility. You need to fully understand shared address space concept if you are going to use it. > Is AOPBATCH an IBM product? If not, SoI applies if it's installed > only in non-authorized libraries. AOP product has something to do with printing. AOPBATCH is a utility for AOP. Shared address has nothing to do with authorized / non-authorized. As for SOL, running shared address spaces gives you access to the those features but at some risk. It has nothing to do with IBM. > COZBATCH is not an IBM product so SoI applies if it's installed > only in non-authorized libraries. See previous comment. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sat, 2 Nov 2019 23:03:16 +, Jon Perryman wrote: > >> Doesn't any program object invoked by // EXEC PGM= execute in the initiator's >> address space? > >Sorry. I forgot to say EXEC PGM=AOPBATCH is safe. > That might be true if AOPBATCH were installed with AC=0 in an authorized library. >> Is there the same exposure for any user-coded program that uses LINK or >> ATTACH? > >The AOPBATCH exposure is with LINK or ATTACH. For example, calling it from >ISPF exposes everything running in that ISPF session. TSO region size tends to >be smaller than dubbed processes. Unix programs tend to consume lots of >storage. Things like MALLOC do not abend and program's don't always check for >success. Using & in scripts could leave forked processes running. I could come >up with more > >Address space sharing has rules and it's been far too long for me to remember >the specifics. Those rules could easily have changed since I last used it. >BPXBATCH always ensured you worked in a safe environment without the need to >understand those rules. > >> How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh? > >It's been a long time. If I remember correctly, it has the exposure. What >makes this acceptable is that you know there are risks but willing to accept >those risks. > How does this interact with the z/OS Statement of Integrity? If an ISPF macro invokes BPX1SPN BPX_SHAREAS=MUST /bin/sh, only IBM code is involved and SoI applies. SoI has no "willing to accept" loophole. Is AOPBATCH an IBM product? If not, SoI applies if it's installed only in non-authorized libraries. COZBATCH is not an IBM product so SoI applies if it's installed only in non-authorized libraries. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Saturday, November 2, 2019, 12:38:38 PM PDT, Paul Gilmartin wrote: > Doesn't any program object invoked by // EXEC PGM= execute in the initiator's > address space? Sorry. I forgot to say EXEC PGM=AOPBATCH is safe. > Is there the same exposure for any user-coded program that uses LINK or > ATTACH? The AOPBATCH exposure is with LINK or ATTACH. For example, calling it from ISPF exposes everything running in that ISPF session. TSO region size tends to be smaller than dubbed processes. Unix programs tend to consume lots of storage. Things like MALLOC do not abend and program's don't always check for success. Using & in scripts could leave forked processes running. I could come up with more Address space sharing has rules and it's been far too long for me to remember the specifics. Those rules could easily have changed since I last used it. BPXBATCH always ensured you worked in a safe environment without the need to understand those rules. > How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh? It's been a long time. If I remember correctly, it has the exposure. What makes this acceptable is that you know there are risks but willing to accept those risks. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sat, 2 Nov 2019 18:53:35 +, Jon Perryman wrote: > ... >How many people ignore that AOPBATCH and COZBATCH execute in the callers >address space and think it's always a good thing! When called from a program, >you are exposing anything running in the address space to various problems and >security exposures. BPXBATCH eliminates this consideration. If IBM fixes this >exposure, then AOPBATCH loses the features you treasure. > I see. But I need enlightment. Doesn't any program object invoked by // EXEC PGM= execute in the initiator's address space? Else ENQs and DDNAMEs created by the initiator would not be available to the target program. Does this create the same exposure? Does the initiator protect itself by keeping its own storage all in system key or protected by segment protection? Is AOPBATCH not protected the same way? Is there the same exposure for any user-coded program that uses LINK or ATTACH? How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Tuesday, October 29, 2019, 01:45:18 PM PDT, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > Oh, my. True Blue! > AOPBATCH removes that limitation and introduces no new limitations (AFAIK?) > Are you arguing for a semantic distinction between "fixing a problem" and > "removing an onerous limitation"? IBM knows that people will do things regardless of the risk. In this case, they avoid responsibility by not documenting and maintaining AOPBATCH as a BPXBATCH replacement. Oh my, True Blue doing one more smart thing by letting you take responsibility for the risk. How many people ignore that AOPBATCH and COZBATCH execute in the callers address space and think it's always a good thing! When called from a program, you are exposing anything running in the address space to various problems and security exposures. BPXBATCH eliminates this consideration. If IBM fixes this exposure, then AOPBATCH loses the features you treasure. There are situations where you don't care but you should always review AOPBATCH's use when called from a program. When I was a developer for a system critical OEM product, I occasionally encountered failure situations where customers were using AOPBATCH within the product. Our standard answer was that AOPBATCH is not documented for this use. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
That's quite nifty. Does it support local spawn and using DD names in
the script?
On 2019-10-30 7:45 PM, John McKown wrote:
Here is my "solution". Actually, I got it from someone R Zenuk. It consists
of a PROC, and a REXX program.
=== proc ===
//BPXJCL PROC USSCMD=,
//***
//* PROC: BPXJCL *
//* *
//* PURPOSE: RUN A USS COMMAND USING THE BPXJCL EXEC *
//* *
//* SYMBOLICS: *
//* *
//* USSCMD - THE USS COMMAND TO EXECUTE *
//* EXECLIB - DSN WHERE BPXJCL EXEC LIVES *
//* *
//* CHANGE LOG *
//* *
//* USERREASON DATE*
//* - *
//* R. ZENUK INITIAL SETUP 01/20/00*
//* *
//***
// EXECLIB=SYS1.LI.CLIST.CNTL
//***
//* *
//***
//BPXJCL EXEC PGM=IKJEFT01,PARM='%BPXJCL &USSCMD'
//SYSEXEC DDDSN=&EXECLIB,DISP=SHR
//SYSTSPRT DDSYSOUT=*
//SYSTSIN DDDUMMY
//STDOUT DDSYSOUT=*
//STDERR DDSYSOUT=*
//STDINDDDUMMY
=== REXX program ===
/*/
/*REXX */
/*/
/* Purpose: Use BPXWUNIX to redirect STDOUT and STDERR to SYSOUT */
/*---*/
/* Syntax: BPXJCL command*/
/*---*/
/* Parms: command- Any USS command*/
/**/
/*/
/* Change Log*/
/**/
/* AuthorDate Reason */
/* - - */
/* R. ZenukJan 2000 Initial Creation */
/**/
/*/
parse arg command
say mvsvar('SYSNAME') mvsvar('SYMDEF','JOBNAME') date() time()
say
say 'Executing command:' command
say
exit BPXWUNIX(command,'DD:stdin','DD:stdout','DD:stderr','0')
=== Sample JOB ===
//TSH009X3 JOB (H0I),'BPXJCL',
// CLASS=Z,TIME=NOLIMIT,
// MSGCLASS=X, SER=BPXROOT,
// NOTIFY=&SYSUID
//*
//STEP1 EXEC PROC=BPXJCL,USSCMD='/bin/sh -L'
//STDIN DD *
set -x
df
//
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, 30 Oct 2019 22:07:13 +, Frank Swarbrick wrote: > >Actually, I am curious to the need of BPXBATCH altogether. I ponder, >occasionally, if JCL could be changed somehow to support a kind of EXEC >statement that would allow for a lower case parameter that would be the name >of, or path to, a USS program. But I don't have any idea what other >requirements these "batch" programs fulfill. > o Support UNIX directories as STEPLIB catenands. Using Data Sets states that a Partitioned Concatenation may mix PDS, PDSE, and UNIX directories. This works for HLASM SYSLIB. Why not likewise for STEPLIB and Binder SYSLIB? o Allow a quoted argument in EXEC PGM='MixCase'. Relaxing the 8-character limit would be added value, but not essential. There should be no need for a new "kind of EXEC statement". This leaves unaddressed the need for STDIN, STDOUT, and STDERR; pretty much required by POSIX. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Frank, As one example, consider text manipulation and reformatting. In the *ix worlds (including z/Linux), (g)awk and/or perl seem to be the languages of choice for searching and/or rearranging and/or selecting data from text files. z/OS Unix has at least a version of the awk utility that supports the POSIX version of the language, and I have used it myself quite often in off-the-cuff data analysis and formatting tasks for management reports. "awk" is one program you might indeed want to run in a batch JCL process. BPXBATCH or one of its replacements (AOPBATCH, COZBATCH) is how you do that in JCL. Could JCL support z/OS Unix programs directly rather than via an interface program like BPXBATCH? Sure, SMOP. But not very likely to get IBM's attention or resources (ROI, don'cha know). Tools or system facilities that make programmers jobs easier but don't predictably result in a (larger) IBM profit are never very high on that scale. Could you use Rexx for these kinds of tasks? Sure you could, but sometimes the other languages let you do it with less person-time and effort because of the facilities that each offers that Rexx may not, or at least not as easily. I'm not trying to start a language flame war here, just providing an example from my own experience. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Wednesday, October 30, 2019 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-line STDPARM shell script for BPXBATCH As someone who rarely uses BPXBATCH, and doesn't have an alternate program, I'm curious as to some of the major issues with BPXBATCH. Actually, I am curious to the need of BPXBATCH altogether. I ponder, occasionally, if JCL could be changed somehow to support a kind of EXEC statement that would allow for a lower case parameter that would be the name of, or path to, a USS program. But I don't have any idea what other requirements these "batch" programs fulfill. From: IBM Mainframe Discussion List on behalf of Kirk Wolf Sent: Wednesday, October 30, 2019 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-line STDPARM shell script for BPXBATCH On Wed, Oct 30, 2019 at 12:27 AM David Crayford wrote: > I have used COZBATCH for years but recently had a requirement to be > able to ship something similar so we could install a web application > from a PAX member using a batch job. > I wrote my own batch shell utility using a tip from Kirk Wolf. It was > very simple to implement, another reason why it's so disappointing > that BPXBATCH is so wretched. > > Anyway, we already had this conversation 10 years ago and it's not > worth dragging it up again. > > FWIW, it was much longer than that! We originally released COZBATCH > in 2007 as a free download (at that time named "DTLSPAWN"). We wrote it in a day after utter frustration with how much list traffic was posted *for years* on BPXBATCH issues.The mvs-oe list was almost completely dedicated to it. It has been enhanced with lots of little creature comforts over the years, but it is still about 1000 lines of code. Kirk Wolf Dovetailed Technologies https://dovetail.com/docs/cozbatch/intro.html#intro_features https://dovetail.com/support.html -- 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
Re: multi-line STDPARM shell script for BPXBATCH
As someone who rarely uses BPXBATCH, and doesn't have an alternate program, I'm curious as to some of the major issues with BPXBATCH. Actually, I am curious to the need of BPXBATCH altogether. I ponder, occasionally, if JCL could be changed somehow to support a kind of EXEC statement that would allow for a lower case parameter that would be the name of, or path to, a USS program. But I don't have any idea what other requirements these "batch" programs fulfill. From: IBM Mainframe Discussion List on behalf of Kirk Wolf Sent: Wednesday, October 30, 2019 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-line STDPARM shell script for BPXBATCH On Wed, Oct 30, 2019 at 12:27 AM David Crayford wrote: > I have used COZBATCH for years but recently had a requirement to be able > to ship something similar so we could install a web application from a > PAX member using a batch job. > I wrote my own batch shell utility using a tip from Kirk Wolf. It was > very simple to implement, another reason why it's so disappointing that > BPXBATCH is so wretched. > > Anyway, we already had this conversation 10 years ago and it's not worth > dragging it up again. > > FWIW, it was much longer than that! We originally released COZBATCH in 2007 as a free download (at that time named "DTLSPAWN"). We wrote it in a day after utter frustration with how much list traffic was posted *for years* on BPXBATCH issues.The mvs-oe list was almost completely dedicated to it. It has been enhanced with lots of little creature comforts over the years, but it is still about 1000 lines of code. Kirk Wolf Dovetailed Technologies https://dovetail.com/docs/cozbatch/intro.html#intro_features https://dovetail.com/support.html -- 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
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, Oct 30, 2019 at 12:29 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > BPBATCH still sucks. IBM is unlikely to enhance it because it competes > with the separately priced AOPBATCH. > > It seems very unlikely to me that this is the reason. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, 30 Oct 2019 09:36:59 -0400, Don Poitras wrote: > >//* The idea here is that I'd like to see the commands printed >//* along with the output. set -x will do that (while printing >//* a "+" in front of the commands, but that's ok), but sends >//* it's debugging output to stderr. By setting stdout and >//* stderr to the same file, the output is interleaved and the >//* final step prints the result. >//* Nowadays (for several releases) BPXBATCH can use SYSOUT for STDOUT and STDERR, so the COPY2 step is unnecessary. STDOUT and STDERR can be merged with the shell command: exec 2>&1 BPBATCH still sucks. IBM is unlikely to enhance it because it competes with the separately priced AOPBATCH. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, Oct 30, 2019 at 12:27 AM David Crayford wrote: > I have used COZBATCH for years but recently had a requirement to be able > to ship something similar so we could install a web application from a > PAX member using a batch job. > I wrote my own batch shell utility using a tip from Kirk Wolf. It was > very simple to implement, another reason why it's so disappointing that > BPXBATCH is so wretched. > > Anyway, we already had this conversation 10 years ago and it's not worth > dragging it up again. > > FWIW, it was much longer than that! We originally released COZBATCH in 2007 as a free download (at that time named "DTLSPAWN"). We wrote it in a day after utter frustration with how much list traffic was posted *for years* on BPXBATCH issues.The mvs-oe list was almost completely dedicated to it. It has been enhanced with lots of little creature comforts over the years, but it is still about 1000 lines of code. Kirk Wolf Dovetailed Technologies https://dovetail.com/docs/cozbatch/intro.html#intro_features https://dovetail.com/support.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
When I looked into this a while back, here's what I came up with. I really don't like the semi-colons and I really want to see the output along with the commands. I'm also a fan of having everything contained in one member so that I don't have to maintain stuff in different spots. --- //DONBPX2 JOB (,R282),POITRAS,NOTIFY=SASDTP,TIME=(0,10),CLASS=A, //REGION=1M,MSGCLASS=A //* //* The idea here is that I'd like to see the commands printed //* along with the output. set -x will do that (while printing //* a "+" in front of the commands, but that's ok), but sends //* it's debugging output to stderr. By setting stdout and //* stderr to the same file, the output is interleaved and the //* final step prints the result. //* //COPY1EXEC PGM=IEBGENER //SYSINDD DUMMY //SYSUT1 DD * set -x cd /u/sasdtp/temp pwd ls -Fartl date /* //SYSUT2 DD PATH='/u/sasdtp/donbpx2.txt', //PATHOPTS=(ORDWR,OTRUNC,OCREAT),PATHMODE=SIRWXU, //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //SYSPRINT DD SYSOUT=* //BPXBAT EXEC PGM=BPXBATCH,PARMDD=PARMINDD //STDINDD DUMMY //STDOUT DD PATH='/u/sasdtp/donbpx2.out.txt', //PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU, //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //STDERR DD PATH='/u/sasdtp/donbpx2.out.txt', //PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU, //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //PARMINDD DD * sh /u/sasdtp/donbpx2.txt /* //COPY2EXEC PGM=IEBGENER //SYSINDD DUMMY //SYSUT1 DD PATH='/u/sasdtp/donbpx2.out.txt', //PATHOPTS=(ORDONLY), //RECFM=VB,LRECL=1024,BLKSIZE=3000 //SYSUT2 DD SYSOUT=* //SYSPRINT DD SYSOUT=* // --- Running this job sends the output to sysout: --- + cd /u/sasdtp/temp + pwd /u/sasdtp/temp + ls -Fartl total 20172 -rw-r--r--1 SASDTP CCD 5797 Jan 19 2011 hexdump.C -rwxr-xr-x1 SASDTP CCD 118784 Jan 19 2011 hexdump* -rwx--1 SASDTP CCD 129024 Jan 20 2011 hexdump.pax* -rw-r--r--1 SASDTP CCD 1000 Jul 30 2018 tmp.txt drwxr-xr-x2 SASDTP CCD 8192 Jul 30 2018 ./ drwxr-xr-x 130 SASDTP CCD32768 Oct 4 15:29 ../ + date Wed Oct 30 09:34:09 EDT 2019 --- -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Here is my "solution". Actually, I got it from someone R Zenuk. It consists
of a PROC, and a REXX program.
=== proc ===
//BPXJCL PROC USSCMD=,
//***
//* PROC: BPXJCL *
//* *
//* PURPOSE: RUN A USS COMMAND USING THE BPXJCL EXEC *
//* *
//* SYMBOLICS: *
//* *
//* USSCMD - THE USS COMMAND TO EXECUTE *
//* EXECLIB - DSN WHERE BPXJCL EXEC LIVES *
//* *
//* CHANGE LOG *
//* *
//* USERREASON DATE*
//* - *
//* R. ZENUK INITIAL SETUP 01/20/00*
//* *
//***
// EXECLIB=SYS1.LI.CLIST.CNTL
//***
//* *
//***
//BPXJCL EXEC PGM=IKJEFT01,PARM='%BPXJCL &USSCMD'
//SYSEXEC DDDSN=&EXECLIB,DISP=SHR
//SYSTSPRT DDSYSOUT=*
//SYSTSIN DDDUMMY
//STDOUT DDSYSOUT=*
//STDERR DDSYSOUT=*
//STDINDDDUMMY
=== REXX program ===
/*/
/*REXX */
/*/
/* Purpose: Use BPXWUNIX to redirect STDOUT and STDERR to SYSOUT */
/*---*/
/* Syntax: BPXJCL command*/
/*---*/
/* Parms: command- Any USS command*/
/**/
/*/
/* Change Log*/
/**/
/* AuthorDate Reason */
/* - - */
/* R. ZenukJan 2000 Initial Creation */
/**/
/*/
parse arg command
say mvsvar('SYSNAME') mvsvar('SYMDEF','JOBNAME') date() time()
say
say 'Executing command:' command
say
exit BPXWUNIX(command,'DD:stdin','DD:stdout','DD:stderr','0')
=== Sample JOB ===
//TSH009X3 JOB (H0I),'BPXJCL',
// CLASS=Z,TIME=NOLIMIT,
// MSGCLASS=X, SER=BPXROOT,
// NOTIFY=&SYSUID
//*
//STEP1 EXEC PROC=BPXJCL,USSCMD='/bin/sh -L'
//STDIN DD *
set -x
df
//
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On 2019-10-30 4:45 AM, Paul Gilmartin wrote: On 2019-10-07 2:06 AM, Jon Perryman wrote: I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. IBM can and have fixed the problem! BPXBATCH is so bad they wrote a replacement AOPBATCH which works just as Kirk describes. IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator. How do you know? Do you work for IBM? Only the village idiot would consider BPXBATCH not to be *bad* :) Maybe you've never been unlucky enough to have to use it! AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP. Oh, my. True Blue! Reminds me of a lawyer defending a hopeless case! An often-criticized limitation of BPXBATCH is that it does not tolerate instream data sets or classic data sets as STDIN. AOPBATCH removes that limitation and introduces no new limitations (AFAIK?) Stacked commands using a semicolon separator do not allow "#" comments. Comments are widely considered a valuable aspect of coding technique. To paraphrase; BPXBATCH sucks! I have used COZBATCH for years but recently had a requirement to be able to ship something similar so we could install a web application from a PAX member using a batch job. I wrote my own batch shell utility using a tip from Kirk Wolf. It was very simple to implement, another reason why it's so disappointing that BPXBATCH is so wretched. Anyway, we already had this conversation 10 years ago and it's not worth dragging it up again. Are you arguing for a semantic distinction between "fixing a problem" and "removing an onerous limitation"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Welcome back. On Tue, 29 Oct 2019 20:21:07 +, Jon Perryman wrote: > >On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford wrote: > > >On 2019-10-07 2:06 AM, Jon Perryman wrote: > >>> I'm saying that IBM can't fix this problem because the problem lies with >>> Unix shell design. > >> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a >> replacement AOPBATCH which works just as Kirk describes. > >IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for >BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe >that BPXBATCH was documented as running a Unix command but we stacked commands >by using the semicolon command separator. > >AOPBATCH simply changes the problems. IBM doesn't need to address those >problems because they are outside the scope of AOP. > Oh, my. True Blue! An often-criticized limitation of BPXBATCH is that it does not tolerate instream data sets or classic data sets as STDIN. AOPBATCH removes that limitation and introduces no new limitations (AFAIK?) Stacked commands using a semicolon separator do not allow "#" comments. Comments are widely considered a valuable aspect of coding technique. Are you arguing for a semantic distinction between "fixing a problem" and "removing an onerous limitation"? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford wrote: >On 2019-10-07 2:06 AM, Jon Perryman wrote: >> I'm saying that IBM can't fix this problem because the problem lies with >> Unix shell design. > IBM can and have fixed the problem! BPXBATCH is so bad they wrote a > replacement AOPBATCH which works just as Kirk describes. IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator. AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On 2019-10-07 2:06 AM, Jon Perryman wrote: I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. I have no idea what you're talking about! IBM can and have fixed the problem! BPXBATCH is so bad they wrote a replacement AOPBATCH which works just as Kirk describes. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.aokfa00/batdd.htm#batdd https://dovetail.com/products/cozbatch.html Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable solution because commands and programs may consume the script. Script files do not get consumed. The mangled command does not get consumed. Creating a script file really is not a good option. Unique file names and finding a directory for the script file can be a problem. Ensuring the script file is deleted at script termination could be a problem. I'm sure there are other problems that would need to be resolved. Additionally, there are many shells available. All shells support passing a single line of commands which is the interface designed specifically for situations such as BPXBATCH. Sadly, shell design doesn't give us the best solution. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
The Unix concept of line implies the new line character which is not standard
z/OS. Multi-line JCL parm does not make sense in this context.
JCL does in fact pass multiple arguments but it is not compatible with Unix
(PARM=(A,B) ).
Specifying alternate DD names has nothing to do with JCL. If I remember
correctly there are several utilities that allow this. BPXBATCH could easily
support this if needed.
Ask yourself why there are so many variations on running a shell in batch.
First, they are extremely easy to create. Second, everyone has their own idea
what is needed.
As for FD0 (stdin) being consumed, I could care less. I'm just stating that
implementing this in BPXBATCH would cause confusion. A command or readline
could potentially be reading part of the script as if it were data.
I don't know where you get the idea I'm arguing against myself. Using a file as
a possible solution poses a unique set of problems. Ultimately you don't want a
command to use the script as data.
Creating complex commands is not a problem as such but do they make sense to
use in STDPARM outside of personal use? I would think it's less desirable for
production where operations makes changes that could easily be error prone and
difficult for those with less experience.
Jon.
On Sunday, October 6, 2019, 12:10:09 PM PDT, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
On Sun, 6 Oct 2019 18:06:16 +, Jon Perryman wrote:
>
>I'm saying that IBM can't fix this problem because the problem lies with Unix
>shell design. This same exact problem exists in products that utilize "sh -c
>some-mangled-commands" (e.g. system automation). For those products, it's
>considered a bad practice to use script statements (e.g. IF) as part of the
>the mangled command.
>
Why?
The problem lies with JCL design, namely JCL's inability to pass a multi-line
PARM.
Even use of ";" command stacking should be limited. Instead, a script file is
the preferred method. The BPXBATCH STDPARM example in this thread should be a
script file because of it's complexity.
>
>Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable
>solution because commands and programs may consume the script. Script files do
>not get consumed. The mangled command does not get consumed.
>
So, you want it to persist rather than be consumed?
>Creating a script file really is not a good option. Unique file names and
>finding a directory for the script file can be a problem. Ensuring the script
>file is deleted at script termination could be a problem. I'm sure there are
>other problems that would need to be resolved.
>
You're arguing against yourself. Here you seem to want that script
to be consumed rather than persist.
(sh invisibly creates and deletes temp files for constructs such as
command substitution and here-documents.)
>Additionally, there are many shells available. All shells support passing a
>single line of commands which is the interface designed specifically for
>situations such as BPXBATCH. Sadly, shell design doesn't give us the best
>solution.
>
UNIX commands, including shell, accept multiple arguments. The problem
lies in BPXBATCH's (in fact all of JCL's) inability to pass multiple arguments.
I can't even pass an alternate DDNAME list to a classic utility.
POSIX shell allows great complexity in a single line. An example:
695 $ cat x
#! /bin/sh
: Define a multiple command string:
S="p() { echo; echo \"The argument passed was:\"; echo \" \$1\"; return; };
p foo; p bar"
: Execute it with sh:
/bin/sh -c "$S"
696 $ ./x
The argument passed was:
foo
The argument passed was:
bar
697 $
--
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
Re: multi-line STDPARM shell script for BPXBATCH
On Sun, 6 Oct 2019 18:06:16 +, Jon Perryman wrote:
>
>I'm saying that IBM can't fix this problem because the problem lies with Unix
>shell design. This same exact problem exists in products that utilize "sh -c
>some-mangled-commands" (e.g. system automation). For those products, it's
>considered a bad practice to use script statements (e.g. IF) as part of the
>the mangled command.
>
Why?
The problem lies with JCL design, namely JCL's inability to pass a multi-line
PARM.
Even use of ";" command stacking should be limited. Instead, a script file is
the preferred method. The BPXBATCH STDPARM example in this thread should be a
script file because of it's complexity.
>
>Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable
>solution because commands and programs may consume the script. Script files do
>not get consumed. The mangled command does not get consumed.
>
So, you want it to persist rather than be consumed?
>Creating a script file really is not a good option. Unique file names and
>finding a directory for the script file can be a problem. Ensuring the script
>file is deleted at script termination could be a problem. I'm sure there are
>other problems that would need to be resolved.
>
You're arguing against yourself. Here you seem to want that script
to be consumed rather than persist.
(sh invisibly creates and deletes temp files for constructs such as
command substitution and here-documents.)
>Additionally, there are many shells available. All shells support passing a
>single line of commands which is the interface designed specifically for
>situations such as BPXBATCH. Sadly, shell design doesn't give us the best
>solution.
>
UNIX commands, including shell, accept multiple arguments. The problem
lies in BPXBATCH's (in fact all of JCL's) inability to pass multiple arguments.
I can't even pass an alternate DDNAME list to a classic utility.
POSIX shell allows great complexity in a single line. An example:
695 $ cat x
#! /bin/sh
: Define a multiple command string:
S="p() { echo; echo \"The argument passed was:\"; echo \"\$1\"; return; };
p foo; p bar"
: Execute it with sh:
/bin/sh -c "$S"
696 $ ./x
The argument passed was:
foo
The argument passed was:
bar
697 $
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Sunday, October 6, 2019, 08:10:44 AM PDT, Kirk Wolf wrote: > I don't understand what you are saying. I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. This same exact problem exists in products that utilize "sh -c some-mangled-commands" (e.g. system automation). For those products, it's considered a bad practice to use script statements (e.g. IF) as part of the the mangled command. Even use of ";" command stacking should be limited. Instead, a script file is the preferred method. The BPXBATCH STDPARM example in this thread should be a script file because of it's complexity. Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable solution because commands and programs may consume the script. Script files do not get consumed. The mangled command does not get consumed. Creating a script file really is not a good option. Unique file names and finding a directory for the script file can be a problem. Ensuring the script file is deleted at script termination could be a problem. I'm sure there are other problems that would need to be resolved. Additionally, there are many shells available. All shells support passing a single line of commands which is the interface designed specifically for situations such as BPXBATCH. Sadly, shell design doesn't give us the best solution. Jon. On Sat, Oct 5, 2019 at 1:35 PM Jon Perryman wrote: > On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote: > > You really like all of this mangling of the shell syntax? > > In all Unix systems, we simply avoid situations where this mangling is > needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good > practice in BPXBATCH when it's considered a bad practice in Unix? The > commonly accepted solution is to create a proper script file and call it. > > What exactly are you referring to as good or bad practice? I don't understand your point here at all. > By the way, "#" comments must be terminated by a newline. The ";" command > terminator character is considered to be part of the comment which is why > you cannot terminate comments properly. > > > For heaven's sake, why doesn't it just read the input from DD:STDIN > > IBM simply followed the Unix standard practice. They start the shell and > pass STDPARM data as an argument. Probably "sh -c > data-from-stdparm-as-a-string". I suspect that newline is not supported > because it's should be interpreted as end of the "sh" command. > > Which Unix standard practice? You never seem to address why taking DD:STDIN as stdin to /bin/sh isn't the most desirable way for it to work? BTW: You are correct: the concatenated lines from STDPARM are passed as the arg to "sh -c". This is why all sorts of things work much differently than if the script was in a file (either real or pipe). Another example is that an an error message that refers to a line number in the input is lost since it appears as one line. > For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix > stdin ) which introduces several much larger problems and would cause > confusion for the user. Scripts should always be in a script file otherwise > the behavior changes and will cause confusion. > > Exactly what problems do you refer to? > If you truly need the newline feature from inline JCL data, then have > STDPARM copy your script DD (including newlines) and execute this copied > script.. > > Alternatively, you could have an edit macro that submits a BPXBATCH job > calling the script file you are currently editing. > > Jon. > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Jon, I don't understand what you are saying. On Sat, Oct 5, 2019 at 1:35 PM Jon Perryman wrote: > On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote: > > You really like all of this mangling of the shell syntax? > > In all Unix systems, we simply avoid situations where this mangling is > needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good > practice in BPXBATCH when it's considered a bad practice in Unix? The > commonly accepted solution is to create a proper script file and call it. > > What exactly are you referring to as good or bad practice? I don't understand your point here at all. > By the way, "#" comments must be terminated by a newline. The ";" command > terminator character is considered to be part of the comment which is why > you cannot terminate comments properly. > > > For heaven's sake, why doesn't it just read the input from DD:STDIN > > IBM simply followed the Unix standard practice. They start the shell and > pass STDPARM data as an argument. Probably "sh -c > data-from-stdparm-as-a-string". I suspect that newline is not supported > because it's should be interpreted as end of the "sh" command. > > Which Unix standard practice? You never seem to address why taking DD:STDIN as stdin to /bin/sh isn't the most desirable way for it to work? BTW: You are correct: the concatenated lines from STDPARM are passed as the arg to "sh -c". This is why all sorts of things work much differently than if the script was in a file (either real or pipe). Another example is that an an error message that refers to a line number in the input is lost since it appears as one line. > For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix > stdin ) which introduces several much larger problems and would cause > confusion for the user. Scripts should always be in a script file otherwise > the behavior changes and will cause confusion. > > Exactly what problems do you refer to? > If you truly need the newline feature from inline JCL data, then have > STDPARM copy your script DD (including newlines) and execute this copied > script.. > > Alternatively, you could have an edit macro that submits a BPXBATCH job > calling the script file you are currently editing. > > Jon. > > -- > 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
Re: multi-line STDPARM shell script for BPXBATCH
On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote: > You really like all of this mangling of the shell syntax? In all Unix systems, we simply avoid situations where this mangling is needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good practice in BPXBATCH when it's considered a bad practice in Unix? The commonly accepted solution is to create a proper script file and call it. By the way, "#" comments must be terminated by a newline. The ";" command terminator character is considered to be part of the comment which is why you cannot terminate comments properly. > For heaven's sake, why doesn't it just read the input from DD:STDIN IBM simply followed the Unix standard practice. They start the shell and pass STDPARM data as an argument. Probably "sh -c data-from-stdparm-as-a-string". I suspect that newline is not supported because it's should be interpreted as end of the "sh" command. For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix stdin ) which introduces several much larger problems and would cause confusion for the user. Scripts should always be in a script file otherwise the behavior changes and will cause confusion. If you truly need the newline feature from inline JCL data, then have STDPARM copy your script DD (including newlines) and execute this copied script.. Alternatively, you could have an edit macro that submits a BPXBATCH job calling the script file you are currently editing. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Fully agree about the "too many solutions". If I could just use COZBATCH
everywhere by default, I would, but I'm stuck with BPXBATCH and can now at
least comment the multi-line shell scripts it supports, subject to correct
placement of semicolons and other "mangled" shell and JCL.
The bit that bit me was the sparsely-documented semicolons ('do' and 'for'
especially tricky) and the "EOF" from the '#' comment. Once bitten twice shy
:-)
Thanks also to John M for his awk example which was educational.
best regards,
Peter
On Wed, 2 Oct 2019 15:02:29 -0500, Paul Gilmartin wrote:
>On Wed, 2 Oct 2019 14:52:32 -0500, Kirk Wolf wrote:
>
>>You really like all of this mangling of the shell syntax?
>>What about "here" documents (quoted or otherwise) ?
>>The addition of STDPARM only makes it suck slightly less than before :-)
>>
>>For heaven's sake, why doesn't it just read the input from DD:STDIN and
>>then send that to fd0 of the /bin/sh process?
>>
>BPXWUNIX can do that.
>Too many incomplete solutions.
>
>>That should be required for a passing grade. Extra credit if you can get
>>it to run /bin/sh as a *login* shell in the same address space, but not
>>much.
>>
>AOPBATCH. But IBM doesn't give it away.
>Long ago, I posted my BPXWUNIX wrapper at:
>http://vm.marist.edu/htbin/wlvtype?MVS-OE.26963
>
>Some of the mangling I did there is now unnecessary with more
>recent enhancements to BPXWUNIX.
>
>-- gil
>
>--
>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
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, 2 Oct 2019 14:52:32 -0500, Kirk Wolf wrote: >You really like all of this mangling of the shell syntax? >What about "here" documents (quoted or otherwise) ? >The addition of STDPARM only makes it suck slightly less than before :-) > >For heaven's sake, why doesn't it just read the input from DD:STDIN and >then send that to fd0 of the /bin/sh process? > BPXWUNIX can do that. Too many incomplete solutions. >That should be required for a passing grade. Extra credit if you can get >it to run /bin/sh as a *login* shell in the same address space, but not >much. > AOPBATCH. But IBM doesn't give it away. Long ago, I posted my BPXWUNIX wrapper at: http://vm.marist.edu/htbin/wlvtype?MVS-OE.26963 Some of the mangling I did there is now unnecessary with more recent enhancements to BPXWUNIX. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
You really like all of this mangling of the shell syntax? What about "here" documents (quoted or otherwise) ? The addition of STDPARM only makes it suck slightly less than before :-) For heaven's sake, why doesn't it just read the input from DD:STDIN and then send that to fd0 of the /bin/sh process? That should be required for a passing grade. Extra credit if you can get it to run /bin/sh as a *login* shell in the same address space, but not much. On Wed, Oct 2, 2019 at 1:22 PM John McKown wrote: > On Wed, Oct 2, 2019 at 1:15 PM Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote: > > >> > > >Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12! > > > > > Easy enough when you have only one shell command and no comments. > > > > You can do multiple shell commands by using the semi-colon "end of command" > character. But you're very correct about no comments. Well, sort of. there > is the "colon" command which is the equivalent of IEFBR14 in batch. > > SH cd /tmp2; >pwd; >: sort of a comment; >ls -l; > > Will work too. Output from above: > > /LIH1/tmp2 > total 2 > drwxr-x--- 3 AXRUSER TSHG 288 Oct 13 2016 AXRUSER > > > -- > I find television very educational. The minute somebody turns it on, I go > into the library and read a good book > -- Groucho Marx > > Maranatha! <>< > John McKown > > -- > 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
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, Oct 2, 2019 at 1:15 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote: > >> > >Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12! > > > Easy enough when you have only one shell command and no comments. > You can do multiple shell commands by using the semi-colon "end of command" character. But you're very correct about no comments. Well, sort of. there is the "colon" command which is the equivalent of IEFBR14 in batch. SH cd /tmp2; pwd; : sort of a comment; ls -l; Will work too. Output from above: /LIH1/tmp2 total 2 drwxr-x--- 3 AXRUSER TSHG 288 Oct 13 2016 AXRUSER -- I find television very educational. The minute somebody turns it on, I go into the library and read a good book -- Groucho Marx Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
>>
>Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
>
Easy enough when you have only one shell command and no comments.
(I didn't know semicolons were optional between awk pattern-action statements.
YLSED.)
It's a pity that "//DD:DDNAME" isn't supported as an operand of "cp".
Some say it works regardless, just if it breaks you get to keep both pieces.
>//PS001 EXEC PGM=BPXBATCH,REGION=0M
>//*PARM='SH printenv '
>//STDOUT DD SYSOUT=*
>//STDERR DD SYSOUT=*
>//STDINDD DUMMY
>//STDPARM DD *
>SH awk 'BEGIN {count=0;file="";}
> file != FILENAME && file != ""
> {print "file " file " has " count " records"}
> FNR == 1 {file=FILENAME;count=0;}
> {count++;}
> END {print "file " file " has " count " records"};
> '
>"//'sys1.maclib(getmain)'"
>"//'sys1.maclib(read)'" |
>cp /dev/fd/0 "//'tsh009.stdout.txt'"
>/*
>//
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, Oct 2, 2019 at 11:54 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote:
>
> >BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck.
> >It is probably the most to blame for slow uptake of z/OS Unix.
> >Thankfully, there are much better alternatives. Some even work the way
> >that you would expect to be able to run z/OS Unix programs / the shell in
> >batch.
> >
> AOPBATCH at least allows instream DD STDIN. IBM is unlikely to add that
> capability because that would enhance a bundled program to compete
> with a separately charged program.
>
> (I've heard a rumor that AOPBATCH is distributed with base z/OS, but
> can't be used legally without a license.)
>
> Would a SYSEXEC wrapper for BPXWUNIX be useful? What additional
> features should it have beyond those of BPXBATCH?
>
> -- gil
>
>
Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
//PS001 EXEC PGM=BPXBATCH,REGION=0M
//*PARM='SH printenv '
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDINDD DUMMY
//STDPARM DD *
SH awk 'BEGIN {count=0;file="";}
file != FILENAME && file != ""
{print "file " file " has " count " records"}
FNR == 1 {file=FILENAME;count=0;}
{count++;}
END {print "file " file " has " count " records"};
'
"//'sys1.maclib(getmain)'"
"//'sys1.maclib(read)'" |
cp /dev/fd/0 "//'tsh009.stdout.txt'"
/*
//
--
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote: >BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck. >It is probably the most to blame for slow uptake of z/OS Unix. >Thankfully, there are much better alternatives. Some even work the way >that you would expect to be able to run z/OS Unix programs / the shell in >batch. > AOPBATCH at least allows instream DD STDIN. IBM is unlikely to add that capability because that would enhance a bundled program to compete with a separately charged program. (I've heard a rumor that AOPBATCH is distributed with base z/OS, but can't be used legally without a license.) Would a SYSEXEC wrapper for BPXWUNIX be useful? What additional features should it have beyond those of BPXBATCH? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck. It is probably the most to blame for slow uptake of z/OS Unix. Thankfully, there are much better alternatives. Some even work the way that you would expect to be able to run z/OS Unix programs / the shell in batch. Kirk Wolf Dovetailed Technologies http://dovetail.com Download and use COZBATCH free using our Community License: https://dovetail.com/docs/cozbatch/intro.html#intro_features On Tue, Oct 1, 2019 at 11:44 PM Peter Bishop wrote: > I love JCL (errrat least I don't hate it quite as much as you). > > I guess I'm just used to it and its infrastructure, e.g. automatic SYSOUT > archiving (admittedly beyond the scope of JCL itself, but based on > JCL-specified SYSOUT to start with). Lots of other good options from you > below for those yet to acquire a taste for it. I for one am very happy to > have multi-line STDPARM which greatly increases the utility of BPXBATCH for > me. JCL and shell scripts: best of both worlds if you do it right. > > best regards, > Peter > > On Tue, 1 Oct 2019 22:35:35 -0500, Paul Gilmartin > wrote: > > >On Tue, 1 Oct 2019 22:10:12 -0500, Peter Bishop wrote: > > > >>Thanks heaps. > >> > >Yaay! You're welcome. > > > >>Firstly, the inline 'no op' which is handy but needs care. > >> > >Oops! > > > >Other thoughts: > > > >BPXWUNIX supports DD:STDIN, DD:STDOUT, and DD:STDERR, for the > >cost of a trivial Rexx driver. Then you get true multi-line code in > >STDIN and comments work. But the FB80 afflicts you with trailing > >blanks which interfere with continuation. > > > >(You can code such a Rexx driver instream and REPRO it into SYSEXEC, > >or keep it in a library.) > > > >If you're using an editor such as ISPF that lets you insert binary > >characters in hex, you can code: > >SET NL='newline' > >CHANGE 'newline' x'15' > >... and use STDPARM SYMBOLS to insert linebreaks. You need > >this only once, in a JCLLIB member. Code the &NL at the front > >of each STDPARM line rather than the back to avoid leading blanks. > > > >I hate JCL! > > > >-- gil > > > >-- > >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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
I love JCL (errrat least I don't hate it quite as much as you). I guess I'm just used to it and its infrastructure, e.g. automatic SYSOUT archiving (admittedly beyond the scope of JCL itself, but based on JCL-specified SYSOUT to start with). Lots of other good options from you below for those yet to acquire a taste for it. I for one am very happy to have multi-line STDPARM which greatly increases the utility of BPXBATCH for me. JCL and shell scripts: best of both worlds if you do it right. best regards, Peter On Tue, 1 Oct 2019 22:35:35 -0500, Paul Gilmartin wrote: >On Tue, 1 Oct 2019 22:10:12 -0500, Peter Bishop wrote: > >>Thanks heaps. >> >Yaay! You're welcome. > >>Firstly, the inline 'no op' which is handy but needs care. >> >Oops! > >Other thoughts: > >BPXWUNIX supports DD:STDIN, DD:STDOUT, and DD:STDERR, for the >cost of a trivial Rexx driver. Then you get true multi-line code in >STDIN and comments work. But the FB80 afflicts you with trailing >blanks which interfere with continuation. > >(You can code such a Rexx driver instream and REPRO it into SYSEXEC, >or keep it in a library.) > >If you're using an editor such as ISPF that lets you insert binary >characters in hex, you can code: >SET NL='newline' >CHANGE 'newline' x'15' >... and use STDPARM SYMBOLS to insert linebreaks. You need >this only once, in a JCLLIB member. Code the &NL at the front >of each STDPARM line rather than the back to avoid leading blanks. > >I hate JCL! > >-- gil > >-- >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
Re: multi-line STDPARM shell script for BPXBATCH
On Tue, 1 Oct 2019 22:10:12 -0500, Peter Bishop wrote: >Thanks heaps. > Yaay! You're welcome. >Firstly, the inline 'no op' which is handy but needs care. > Oops! Other thoughts: BPXWUNIX supports DD:STDIN, DD:STDOUT, and DD:STDERR, for the cost of a trivial Rexx driver. Then you get true multi-line code in STDIN and comments work. But the FB80 afflicts you with trailing blanks which interfere with continuation. (You can code such a Rexx driver instream and REPRO it into SYSEXEC, or keep it in a library.) If you're using an editor such as ISPF that lets you insert binary characters in hex, you can code: SET NL='newline' CHANGE 'newline' x'15' ... and use STDPARM SYMBOLS to insert linebreaks. You need this only once, in a JCLLIB member. Code the &NL at the front of each STDPARM line rather than the back to avoid leading blanks. I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-line STDPARM shell script for BPXBATCH
Thanks heaps. Firstly, the inline 'no op' which is handy but needs care. STDPARM: SH ( set -o verbose ; set -o errexit ; set -x ; for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ; do : 'any old comment' ; if [ -z "$(echo $jarname | grep Doc\.jar)" ] ; then echo adding to ClassPath ; CLASSPATH="$CLASSPATH":"$jarname" ; fi done ; echo CLASSPATH is $CLASSPATH ; ) > &E.bcd-write.out 2>&E.bcd-write.err STDERR is empty for this one. Works as expected. This next one fails, probably reasonably as it's in the middle of a 'for'. STDPARM: SH ( set -o verbose ; set -o errexit ; set -x ; for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ; : 'any old comment' ; do if [ -z "$(echo $jarname | grep Doc\.jar)" ] ; then echo adding to ClassPath ; CLASSPATH="$CLASSPATH":"$jarname" ; fi done ; echo CLASSPATH is $CLASSPATH ; ) > &E.bcd-write.out 2>&E.bcd-write.err STDERR FSUM7332 syntax error: got Word, expecting do The JCL concatenation worked, and I'm going to use it as it's foolproof. As long as the comment and the resumption of SYSIN are moved together, they can go pretty much anywhere. If you need the symbols, remember to keep the SYMBOLS keyword on the resumed SYSIN. //EXPORT SYMLIST=* // SET BCDHOME='/usr/lpp/bcp/'home directory for BCP // SET E='/u/bhpprq/' error messages here //* //* multiline shell script with complex control structures //* //* //BPXBATCH EXEC PGM=BPXBATCH //OUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD *,SYMBOLS=(EXECSYS,OUT) SH ( set -o verbose ; set -o errexit ; set -x ; for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ; do //* any old comment // DD *,SYMBOLS=(EXECSYS,OUT) if [ -z "$(echo $jarname | grep Doc\.jar)" ] ; then echo adding to ClassPath ; CLASSPATH="$CLASSPATH":"$jarname" ; fi done ; echo CLASSPATH is $CLASSPATH ; ) > &E.bcd-write.out 2>&E.bcd-write.err // cheers, Peter On Tue, 1 Oct 2019 21:42:24 -0500, Paul Gilmartin wrote: >On Tue, 1 Oct 2019 20:31:39 -0500, Peter Bishop wrote: >> >>in case anyone wants it, after much trial and error I finally found this >>working example of a multi-line STDPARM shell script for BPXBATCH. I still >>haven't found a way to have #comment lines, which seem to generate syntax >>errors, but if I accept that li
Re: multi-line STDPARM shell script for BPXBATCH
On Tue, 1 Oct 2019 20:31:39 -0500, Peter Bishop wrote: > >in case anyone wants it, after much trial and error I finally found this >working example of a multi-line STDPARM shell script for BPXBATCH. I still >haven't found a way to have #comment lines, which seem to generate syntax >errors, but if I accept that limitation, I am happy enough ... > Depends on what you need: #! /bin/sh -x uname -a; : ' This is a no-op masquerading as a comment'; date; exit; Or, use JCL concatenation: //STDPARM DD * uname -a; //* This //* an embeddfed //* JCL comment. // DD * date; exit; -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
multi-line STDPARM shell script for BPXBATCH
Hi, in case anyone wants it, after much trial and error I finally found this working example of a multi-line STDPARM shell script for BPXBATCH. I still haven't found a way to have #comment lines, which seem to generate syntax errors, but if I accept that limitation, I am happy enough with this. //EXPORT SYMLIST=* // SET BCDHOME='/usr/lpp/bcp/'home directory for BCP // SET E='/u/x/' error messages here //* //* multiline shell script with complex control structures //* //* haven't found a way yet to include #comments without error //* //BPXBATCH EXEC PGM=BPXBATCH //OUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD *,SYMBOLS=(EXECSYS,OUT) SH ( set -o verbose ; set -o errexit ; set -x ; for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ; do if [ -z "$(echo $jarname | grep Doc\.jar)" ] ; then echo adding to ClassPath ; CLASSPATH="$CLASSPATH":"$jarname" ; fi done ; echo CLASSPATH is $CLASSPATH ; ) > &E.bcd-write.out 2>&E.bcd-write.err // What I like about this is when there is a syntax error I get the message in STDERR, and when there isn't the normal and error output goes to my specified files. I needed this as the placement of the semicolons was a bit hard to glean from the manual, e.g. 'for' needs one but not 'then' or 'fi', etc. If anyone can suggest how to put a comment it that works without error, I'm all ears. For example of the error, this code that has the #comment added to the 'for', SH ( set -o verbose ; set -o errexit ; set -x ; for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` #comment ; do if [ -z "$(echo $jarname | grep Doc\.jar)" ] ; then echo adding to ClassPath ; CLASSPATH="$CLASSPATH":"$jarname" ; fi done ; echo CLASSPATH is $CLASSPATH ; ) > &E.bcd-write.out 2>&E.bcd-write.err gives this error in STDERR: FSUM7332 syntax error: got EOF, expecting do I'm still learning the ins and outs of SH but I was surprised to read that a comment is "EOF". best regards, Peter (MVS-OE seems a little quiet so I thought I might start here). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
