Re: JCL to tar USS directory
On Fri, 15 Jan 2021 19:39:41 +, Frank Swarbrick wrote: > >From the z/OS Unix System Services Command Reference >(https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa500/bpxbatr.htm): > > * It must be a text file defined with read access only > So, must I have a RACF rule prohibiting write access, or what? Or prohibit write and execute access with UNIX mode bits? WTF!? > * Specify one argument per line > So, not //STDPARM DD * PGM /bin/echo FOO BAR /* >If a MVS data set is specified: >... > * The data set cannot have sequence numbers in it. > OK. >If you use the ISPF editor to edit the data set, set the sequence numbers off >by typing number off on the command line before you begin typing in the data. >If sequence numbers already exist, type UNNUM to remove them and set number >mode off. > That's a "How-to", belonging in a Users Guide, not a Command Ref., and undoubtedly well covered in the ISPF Ref. What about all other editors? > * Trailing blanks are truncated for SYSIN and variable block data sets, > but not for fixed block data sets. For a fixed block data set, trailing > blanks will be included in the parameter text for a given argument up to the > end of the record. > Truncated for variable but not for fixed!? Doesn't that seem backwards? After all, the programmer can control trailing blocks for variable; not for fixed. "Truncated for SYSIN ..., but not for fixed block data sets." Doesn't that statement contradict itself for fixed block SYSIN, a frequent occurrence? Who wrote this crap? Clearly no one proofread it with technical knowledge. >As for the note about "JCL in-stream data set", I disagree that it belongs in >the JCL ref. The behavior is specific to how BPXBATCH itself handles instream >data. I don't think it's a general statement about instream data. > I was thinking of the "immediately follows" qualification, not at all specific to BPXBATCH. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
From the z/OS Unix System Services Command Reference (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa500/bpxbatr.htm): BPXBATCH supports a parameter string up to 32754 characters when called from a TSO command environment. Also from both a batch and TSO environment, up to 65,536 characters can now be supplied via the a new input DD named stdparm. When the stdparm DD is allocated BPXBATCH will use the data found in the z/OS UNIX file or MVS data set associated with this DD rather that what is found on the parameter string or in the stdin DD. As a warning to the user, an informational message BPXM079I will be displayed indicating that this is occurring. The stdparm DD will allow either a z/OS UNIX file, or an MVS SYSIN PDS, PDSE or sequential data set. The following are characteristics of the parameter data that can be supplied in the stdparm DD, if a z/OS UNIX file is specified: * It must be a text file defined with read access only * Specify one argument per line * The file cannot have sequence numbers in it. TipIf you use the ISPF editor to create the file, set the sequence numbers off by typing number off on the command line before you begin typing data. If sequence numbers already exist, type UNNUM to remove them and then type number off. If a MVS data set is specified: * Specify one argument per line. If the parameter string for an argument spans more than one line of a data set or file, this string will be divided into two or more arguments that are passed to the corresponding shell script or program. * The maximum length of a single argument supplied to the program is 32,760, which is the same as the maximum LRECL for an unspanned non-VSAM data set. * The record format of the data set can fixed or variable (unspanned). * The data set cannot have sequence numbers in it. If you use the ISPF editor to edit the data set, set the sequence numbers off by typing number off on the command line before you begin typing in the data. If sequence numbers already exist, type UNNUM to remove them and set number mode off. * Trailing blanks are truncated for SYSIN and variable block data sets, but not for fixed block data sets. For a fixed block data set, trailing blanks will be included in the parameter text for a given argument up to the end of the record. I would agree that it's not all that clear. As for the note about "JCL in-stream data set", I disagree that it belongs in the JCL ref. The behavior is specific to how BPXBATCH itself handles instream data. I don't think it's a general statement about instream data. BTW, the "copy code" is an artifact of cut and paste from a web page. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, January 15, 2021 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL to tar USS directory On Fri, 15 Jan 2021 18:22:09 +, Frank Swarbrick wrote: >For in-stream data sets: with the SH option, trailing blanks are not >truncated. Records in in-stream data sets are concatenated with blanks as >separator characters, and the string remaining after the SH token is passed as >a single argument to a /bin/sh -c command. For the PGM option, the string is >divided not only at line boundaries but also at blanks within a line. > >From "Guidelines for defining STDPARM", >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm > Sigh. Users Guide. Syntactic rules belong not in a Users Guide but in a Command Ref., which is where I looked. > * [...] > * An JCL in-stream data set > >The BPXBATCH parameter data immediately follows the STDPARM DD statement. >Trailing blanks are truncated for in-stream data sets, but not for other data >sets. > And that's JCL. It belongs in the JCL Ref., where it undoubtedly appears. It shouldn't be duplicated here, except in an example. >... >Here is another way, placing the arguments on separate lines: > >//STDPARM DD * >SH /myscript.sh > > >/*[Copy code] > "[Copy code]"? The example might instructively show a trick to concatenate (long) lines with a command substitution: //STDPARM DD * SH /myscript.sh $( : These lines are concatenated! ) /* Is equivalent to: //STDPARM DD * SH /myscript.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: JCL to tar USS directory
On Fri, 15 Jan 2021 18:22:09 +, Frank Swarbrick wrote: >For in-stream data sets: with the SH option, trailing blanks are not >truncated. Records in in-stream data sets are concatenated with blanks as >separator characters, and the string remaining after the SH token is passed as >a single argument to a /bin/sh -c command. For the PGM option, the string is >divided not only at line boundaries but also at blanks within a line. > >From "Guidelines for defining STDPARM", >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm > Sigh. Users Guide. Syntactic rules belong not in a Users Guide but in a Command Ref., which is where I looked. > * [...] > * An JCL in-stream data set > >The BPXBATCH parameter data immediately follows the STDPARM DD statement. >Trailing blanks are truncated for in-stream data sets, but not for other data >sets. > And that's JCL. It belongs in the JCL Ref., where it undoubtedly appears. It shouldn't be duplicated here, except in an example. >... >Here is another way, placing the arguments on separate lines: > >//STDPARM DD * >SH /myscript.sh > > >/*[Copy code] > "[Copy code]"? The example might instructively show a trick to concatenate (long) lines with a command substitution: //STDPARM DD * SH /myscript.sh $( : These lines are concatenated! ) /* Is equivalent to: //STDPARM DD * SH /myscript.sh /* -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
For in-stream data sets: with the SH option, trailing blanks are not truncated. Records in in-stream data sets are concatenated with blanks as separator characters, and the string remaining after the SH token is passed as a single argument to a /bin/sh -c command. For the PGM option, the string is divided not only at line boundaries but also at blanks within a line. >From "Guidelines for defining STDPARM", >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm The wording is a bit problematic, but essentially in STDPARM only, a new line is treated as a space character. You can only pass a single "line", then, when using STDPARM. I also think the statement that "with the SH option, trailing blanks are not truncated" is not true at all. The next "page" in the manual, "Ways to define STDPARM" seem to contradict this. You can define the STDPARM parameter file by using one of the following: * [...] * An JCL in-stream data set The BPXBATCH parameter data immediately follows the STDPARM DD statement. Trailing blanks are truncated for in-stream data sets, but not for other data sets. The following is one way to define STDPARM to run the script: //STDPARM DD * SH /myscript.sh /* Here is another way, placing the arguments on separate lines: //STDPARM DD * SH /myscript.sh /*[Copy code] Result: Both of these STDPARM definitions produce the following output: From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, January 15, 2021 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL to tar USS directory On Fri, 15 Jan 2021 10:12:52 -0500, Kurt Quackenbush wrote: >On 1/14/2021 10:10 AM, Bill Giannelli wrote: >> can anyone provide JCL to tar a USS directory? >//PAX EXEC PGM=BPXBATCH >//STDPARM DD * >PGM /bin/pax -zvwf /u/user/paxfile.pax.Z >/directory/to/be/paxed/ >/* Must that second line be indented so it is not abbutted to the first, resulting in: PGM /bin/pax -zvwf /u/user/paxfile.pax.Z/directory/to/be/paxed/ ... ??? The manual, z/OS Version 2 Release 4 UNIX System Services Command Reference IBM SA23-2280-40 needs clarification here. And in From a TSO command environment, the parameter string itself will now support up to 32754 characters. Doesn't TSO CALL impose a limit of 100? Parameters to BPXBATCH can also be supplied via the stdparm DD up to a limit of 65,536 characters. 65,536? 65,535 is more plausible. In addition, program_name can contain option information. My experience has been that after SH the remainder of the PARM is passed as the command-string to "sh -c 'command-string'". When PGM is specified, the PARM is tokenized at blanks. The first token is the program (path)name; remaining tokens are arguments to the program. When PGM and program_name are specified and the specified program name does not begin with a slash character (/), BPXBATCH prefixes the user's initial working directory information to the program path name. "initial working directory"? I'd expect "current" working directory. What about when SH is specified? >//STDOUT DD SYSOUT=* >//STDERR DD SYSOUT=* > 5. BPXBATCH does not support any ddnames other than stdin , stdout, stderr, stdenv or stdparm. Attempting to allocate or reference any other ddnames will result in enqueue failures or unpredictable results. To use an MVS data set in your batch UNIX application, use "dynamic allocation", such as SVC99 or the TSO ALLOC command. Also, you must remove all "static allocations" (ddnames referring to the MVS data set in question) from all steps in the batch job. How many misstatements or misleading statements are in that paragraph? Certainly static (JCL) allocation is less susceptible to enqueue failures than dynamic allocation. -- 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: JCL to tar USS directory
On Fri, 15 Jan 2021 10:12:52 -0500, Kurt Quackenbush wrote: >On 1/14/2021 10:10 AM, Bill Giannelli wrote: >> can anyone provide JCL to tar a USS directory? >//PAX EXEC PGM=BPXBATCH >//STDPARM DD * >PGM /bin/pax -zvwf /u/user/paxfile.pax.Z >/directory/to/be/paxed/ >/* Must that second line be indented so it is not abbutted to the first, resulting in: PGM /bin/pax -zvwf /u/user/paxfile.pax.Z/directory/to/be/paxed/ ... ??? The manual, z/OS Version 2 Release 4 UNIX System Services Command Reference IBM SA23-2280-40 needs clarification here. And in From a TSO command environment, the parameter string itself will now support up to 32754 characters. Doesn't TSO CALL impose a limit of 100? Parameters to BPXBATCH can also be supplied via the stdparm DD up to a limit of 65,536 characters. 65,536? 65,535 is more plausible. In addition, program_name can contain option information. My experience has been that after SH the remainder of the PARM is passed as the command-string to "sh -c 'command-string'". When PGM is specified, the PARM is tokenized at blanks. The first token is the program (path)name; remaining tokens are arguments to the program. When PGM and program_name are specified and the specified program name does not begin with a slash character (/), BPXBATCH prefixes the user's initial working directory information to the program path name. "initial working directory"? I'd expect "current" working directory. What about when SH is specified? >//STDOUT DD SYSOUT=* >//STDERR DD SYSOUT=* > 5. BPXBATCH does not support any ddnames other than stdin , stdout, stderr, stdenv or stdparm. Attempting to allocate or reference any other ddnames will result in enqueue failures or unpredictable results. To use an MVS data set in your batch UNIX application, use "dynamic allocation", such as SVC99 or the TSO ALLOC command. Also, you must remove all "static allocations" (ddnames referring to the MVS data set in question) from all steps in the batch job. How many misstatements or misleading statements are in that paragraph? Certainly static (JCL) allocation is less susceptible to enqueue failures than dynamic allocation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
On 1/14/2021 10:10 AM, Bill Giannelli wrote: can anyone provide JCL to tar a USS directory? //PAX EXEC PGM=BPXBATCH //STDPARM DD * PGM /bin/pax -zvwf /u/user/paxfile.pax.Z /directory/to/be/paxed/ /* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
On Fri, 15 Jan 2021 02:55:30 -0600, Jantje wrote: >On Thu, 14 Jan 2021 09:00:21 -0600, Bill Giannelli wrote: > >>can anyone provide JCL to tar a USS directory? > Tar is obsolescent, largely replaced by pax with added features. >IMHO, if you are going to do anything in Unix on mainframe, you want to use >Co:Z from DovetailedTechnologies: https://www.dovetail.com/index.html > o Co:Z is generally highy recommended. o However, some sites choose by policy not to install Co:Z. o Therefore ISVs should avoid distributing to customers code that depends on Co:Z. o BPXBATCH suffices to invoke tar/pax. o SMP/E relies heavily on Unix on mainframe but is Co:Z free. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
On Thu, 14 Jan 2021 09:00:21 -0600, Bill Giannelli wrote: >can anyone provide JCL to tar a USS directory? IMHO, if you are going to do anything in Unix on mainframe, you want to use Co:Z from DovetailedTechnologies: https://www.dovetail.com/index.html I am not affiliated in any way with Dovetail, except as a very happy user of their excellent stuff. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
W dniu 14.01.2021 o 16:00, Bill Giannelli pisze: can anyone provide JCL to tar a USS directory? thanks Bill Correction: //K10 EXEC PGM=BPXBATCH,PARM='PGM /bin/tar -?' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL to tar USS directory
W dniu 14.01.2021 o 16:00, Bill Giannelli pisze: can anyone provide JCL to tar a USS directory? thanks //K10 EXEC PGM=BPXBATCH,PARM='SH tar parameterscd;ls' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* ls is redundant, it is just as example of second command within the step. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCL to tar USS directory
can anyone provide JCL to tar a USS directory? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
