Re: Possible RFE for new DISP JCL parameter options
On 2017-06-30, at 15:23, Frank Swarbrick wrote: > I agree on both points. I am totally mystified by the presence of O prefix > on the PATHOPTS values. It makes it so much hard for me to read; specially > OWRONLY. Why not just W, R and WR? Sheesh. > Consistency with UNIX/C. See, e.g. the description of open() in: XL C/C++ Runtime Library Reference Really, it ought to be O_WRONLY, but the JCL folks couldn't see their way to that degree of consistency. C macros endure similar constraints to Assembler EQUated symbols -- they must be globally unique, thus they are longer than you'd otherwise think necessary. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
On 2017-06-30, at 13:44, Jesse 1 Robinson wrote: > I'm all in favor of the RFE in principle, but I think that choice of keyword > is crucial. Based on decades of history: what happens in JCL stays in JCL. > Forever. > > I personally find the OMVS keywords unintuitive and therefore--unless one > uses them frequently--deucedly difficult to keep straight. > Many of those were assimilated from UNIX/C, so you can't blame IBM. (But which were you thinking of?) > ... In the ancient NDM (ancestor of Connect:Direct) 'REPLACE' is used in the > sense suggested by Gil: if it exists, overwrite it; otherwise create it; copy > the data and move on with no muss and no fuss. > > There are other possible values, but REPLACE seems to be available in JCL. > Old farts may remember the advent of 'REUSE' in the TSO ALLOCATE command. The > lengths we had to go to before REUSE move me to nominate the old mechanism as > the single worst design point of MVS. At least the one that impinged on users > in the most annoying manner. > Some of the problem with REUSE arose because "REUSE" (sometimes) has a specific meaning of converting an existing allocation. So for several releases after REUSE appeared in the ALLOCATE command it was incompatible with UNIX paths, which can't be converted. It's better now -- ALLOCATE REUSE simply frees the path and allocates anew. > Time for an innovation in JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
I agree on both points. I am totally mystified by the presence of O prefix on the PATHOPTS values. It makes it so much hard for me to read; specially OWRONLY. Why not just W, R and WR? Sheesh. I will suggest REPLACE instead of CREATE in the RFE. Although that kind of implies behavior like I mentioned in my previous email, which is if the file already exists it "deletes" it and the creates a "new" version. Is that the only behavior truly necessary? Do we need an option where if it exists it simply leaves it alone? I think so in the case of a job that may be reading the file. Specifically, if the file already exists we don't want to truncate it at all. But if it does not exist then we want to create it. So do we have both REPLACE (delete the file and then create it) and CREATE (essentially DISP=SHR (I think) if the file already exists and DISP=NEW if it does not exist)? Frank From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jesse 1 Robinson <jesse1.robin...@sce.com> Sent: Friday, June 30, 2017 1:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Possible RFE for new DISP JCL parameter options I'm all in favor of the RFE in principle, but I think that choice of keyword is crucial. Based on decades of history: what happens in JCL stays in JCL. Forever. I personally find the OMVS keywords unintuitive and therefore--unless one uses them frequently--deucedly difficult to keep straight. In the ancient NDM (ancestor of Connect:Direct) 'REPLACE' is used in the sense suggested by Gil: if it exists, overwrite it; otherwise create it; copy the data and move on with no muss and no fuss. There are other possible values, but REPLACE seems to be available in JCL. Old farts may remember the advent of 'REUSE' in the TSO ALLOCATE command. The lengths we had to go to before REUSE move me to nominate the old mechanism as the single worst design point of MVS. At least the one that impinged on users in the most annoying manner. Time for an innovation in JCL. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 30, 2017 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Possible RFE for new DISP JCL parameter options On Fri, 30 Jun 2017 11:24:18 -0700, Charles Mills wrote: >YES!!! > >Years ago I wrote and my company sold a mainframe-PC file transfer >product (in the pre-FTP days), and it supported a DISP operand for the >creation of mainframe datasets that worked exactly as you describe, >with two steps under the covers. I'm trying to remember the keyword for the >specification. >Perhaps CREATE. It made sense then (1989) and it makes sense today. > Many desktop editors call this REPLACE; SAVE fails for an existing file. >(It also did a kind of extended SDB under the covers. You could specify >any one or two of LRECL, RECFM and BLKSIZE and it would intuit the >others. Had an algorithm that made intelligent guesses. Specify >RECFM=FB,BLKSIZE=8000 it would give you LRECL=80. Specify >LRECL=137,BLKSIZE=8000 and it would give you RECFM=VB.) > What might it do for RECFM=FB,BKLSIZE=10640 (which happens to be 133 * 80). 526 $ factor 10640 Factors of 10640 are 2 2 2 2 5 7 19 It's ambiguous for any number with 2 or more prime factors. -- 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: Possible RFE for new DISP JCL parameter options
There were many best guesses in the algorithm, and I do not recall most of them. If you didn't like what it did you could always simply specify all three attributes. I think it tended to favor LRECL=80 in honor of Mr. Hollerith. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 30, 2017 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Possible RFE for new DISP JCL parameter options On Fri, 30 Jun 2017 11:24:18 -0700, Charles Mills wrote: >YES!!! > >Years ago I wrote and my company sold a mainframe-PC file transfer >product (in the pre-FTP days), and it supported a DISP operand for the >creation of mainframe datasets that worked exactly as you describe, >with two steps under the covers. I'm trying to remember the keyword for the >specification. >Perhaps CREATE. It made sense then (1989) and it makes sense today. > Many desktop editors call this REPLACE; SAVE fails for an existing file. >(It also did a kind of extended SDB under the covers. You could specify >any one or two of LRECL, RECFM and BLKSIZE and it would intuit the >others. Had an algorithm that made intelligent guesses. Specify >RECFM=FB,BLKSIZE=8000 it would give you LRECL=80. Specify >LRECL=137,BLKSIZE=8000 and it would give you RECFM=VB.) > What might it do for RECFM=FB,BKLSIZE=10640 (which happens to be 133 * 80). 526 $ factor 10640 Factors of 10640 are 2 2 2 2 5 7 19 It's ambiguous for any number with 2 or more prime factors. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
I've always thought that DISP=MOD was an odd duck. Seems to me that to be consistent it should be a JCL error if the dataset doesn't exist. Anyway, yes, this is a great idea. I can't believe we've gone this far without it. sas ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
I like this name (REPLACE instead of CREAT[E]). Prior to realizing that this behavior is supported with UNIX files I had pondered long and hard about the value. RENEW seemed OK, but I bit of a reach. CREAT[E] is based on the existing OCREAT, but REPL[ACE] could work just as well. I had a thought after I wrote the original post with regard to the actual behavior of TRUNC. If it was based on the behavior of OTRUNC it would just truncate the file. But in order to work more similarly to the two step "delete and define" behavior, perhaps it should work that way. This would specifically be desirable if the file attributes need to be changed. For example, if the LRECL changes (in the program) and TRUNC didn't actually "delete and define" the file then there would be a file attribute mismatch. But if TRUNC does do "delete and define" (and the LRECL is not specified on the JCL, but gets it from the program) then no JCL would need to be changed. So the question in my mind is, should there be options for both behaviors, or should TRUNC (or whatever) always do an implicit DELETE and an implicit NEW? I don't see any harm in the latter, but I could be missing a use case. Frank From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, June 30, 2017 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Possible RFE for new DISP JCL parameter options On Fri, 30 Jun 2017 11:24:18 -0700, Charles Mills wrote: >YES!!! > >Years ago I wrote and my company sold a mainframe-PC file transfer product >(in the pre-FTP days), and it supported a DISP operand for the creation of >mainframe datasets that worked exactly as you describe, with two steps under >the covers. I'm trying to remember the keyword for the specification. >Perhaps CREATE. It made sense then (1989) and it makes sense today. > Many desktop editors call this REPLACE; SAVE fails for an existing file. >(It also did a kind of extended SDB under the covers. You could specify any >one or two of LRECL, RECFM and BLKSIZE and it would intuit the others. Had >an algorithm that made intelligent guesses. Specify RECFM=FB,BLKSIZE=8000 it >would give you LRECL=80. Specify LRECL=137,BLKSIZE=8000 and it would give >you RECFM=VB.) > What might it do for RECFM=FB,BKLSIZE=10640 (which happens to be 133 * 80). 526 $ factor 10640 Factors of 10640 are 2 2 2 2 5 7 19 It's ambiguous for any number with 2 or more prime factors. -- 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: Possible RFE for new DISP JCL parameter options
I'm all in favor of the RFE in principle, but I think that choice of keyword is crucial. Based on decades of history: what happens in JCL stays in JCL. Forever. I personally find the OMVS keywords unintuitive and therefore--unless one uses them frequently--deucedly difficult to keep straight. In the ancient NDM (ancestor of Connect:Direct) 'REPLACE' is used in the sense suggested by Gil: if it exists, overwrite it; otherwise create it; copy the data and move on with no muss and no fuss. There are other possible values, but REPLACE seems to be available in JCL. Old farts may remember the advent of 'REUSE' in the TSO ALLOCATE command. The lengths we had to go to before REUSE move me to nominate the old mechanism as the single worst design point of MVS. At least the one that impinged on users in the most annoying manner. Time for an innovation in JCL. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 30, 2017 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Possible RFE for new DISP JCL parameter options On Fri, 30 Jun 2017 11:24:18 -0700, Charles Mills wrote: >YES!!! > >Years ago I wrote and my company sold a mainframe-PC file transfer >product (in the pre-FTP days), and it supported a DISP operand for the >creation of mainframe datasets that worked exactly as you describe, >with two steps under the covers. I'm trying to remember the keyword for the >specification. >Perhaps CREATE. It made sense then (1989) and it makes sense today. > Many desktop editors call this REPLACE; SAVE fails for an existing file. >(It also did a kind of extended SDB under the covers. You could specify >any one or two of LRECL, RECFM and BLKSIZE and it would intuit the >others. Had an algorithm that made intelligent guesses. Specify >RECFM=FB,BLKSIZE=8000 it would give you LRECL=80. Specify >LRECL=137,BLKSIZE=8000 and it would give you RECFM=VB.) > What might it do for RECFM=FB,BKLSIZE=10640 (which happens to be 133 * 80). 526 $ factor 10640 Factors of 10640 are 2 2 2 2 5 7 19 It's ambiguous for any number with 2 or more prime factors. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
On Fri, 30 Jun 2017 11:24:18 -0700, Charles Mills wrote: >YES!!! > >Years ago I wrote and my company sold a mainframe-PC file transfer product >(in the pre-FTP days), and it supported a DISP operand for the creation of >mainframe datasets that worked exactly as you describe, with two steps under >the covers. I'm trying to remember the keyword for the specification. >Perhaps CREATE. It made sense then (1989) and it makes sense today. > Many desktop editors call this REPLACE; SAVE fails for an existing file. >(It also did a kind of extended SDB under the covers. You could specify any >one or two of LRECL, RECFM and BLKSIZE and it would intuit the others. Had >an algorithm that made intelligent guesses. Specify RECFM=FB,BLKSIZE=8000 it >would give you LRECL=80. Specify LRECL=137,BLKSIZE=8000 and it would give >you RECFM=VB.) > What might it do for RECFM=FB,BKLSIZE=10640 (which happens to be 133 * 80). 526 $ factor 10640 Factors of 10640 are 2 2 2 2 5 7 19 It's ambiguous for any number with 2 or more prime factors. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
On Fri, 30 Jun 2017 17:39:49 +, Frank Swarbrick wrote: > >I would like to see two new [DISP] options that behave in a manner similar to >the two options above that are not currently supported for MVS data sets. I >suggest the following: > >DISP=CREAT: Similar in behavior to PATHOPTS=(ORDWR,OCREAT). >DISP=TRUNC: Similar in behavior to PATHOPTS=(ORDWR,OCREAT,OTRUNC) > Be sure your RFE mentions DYNALLOC, TSO ALLOCATE, BPXWDYN, and the various programming language interfaces to Open or Allocation. Otherwise they might implement the facility in JCL but not in the other nterfaces. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
YES!!! Years ago I wrote and my company sold a mainframe-PC file transfer product (in the pre-FTP days), and it supported a DISP operand for the creation of mainframe datasets that worked exactly as you describe, with two steps under the covers. I'm trying to remember the keyword for the specification. Perhaps CREATE. It made sense then (1989) and it makes sense today. (It also did a kind of extended SDB under the covers. You could specify any one or two of LRECL, RECFM and BLKSIZE and it would intuit the others. Had an algorithm that made intelligent guesses. Specify RECFM=FB,BLKSIZE=8000 it would give you LRECL=80. Specify LRECL=137,BLKSIZE=8000 and it would give you RECFM=VB.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, June 30, 2017 10:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Possible RFE for new DISP JCL parameter options One MVS behavior that has annoyed me since we migrated to z/OS from VSE is the fact that MVS has no DISP option that will both create a data set if it does not already exist and simply allow its use if it does already exist. One has to "emulate" this behavior using a two step process, where step 1 specifies DISP=(MOD,DELETE) and step two specifies DISP=NEW. Since this use case exists so often (in my environment, anyway!), shouldn't there be direct JCL support, probably a new DISP option, to perform this behavior without the need for an additional step to first delete the file (if it exists) so that the DISP=NEW in the later step will always succeed? MVS *does* have such a feature for Unix system files. The following assume the default PATHDISP=(KEEP,DELETE). PATHOPTS=(ORDWR,OCREAT,OEXCL) This creates the Unix file if it does not already exist, and gives a JCL error if the file does already exist. This behavior is similar to DISP=(NEW,CATLG) for an MVS data set. PATHOPTS=(ORDWR,OCREAT) This creates the Unix file if it does not already exist, and allows the program to use the existing file when it already exists. There currently is no equivalent behavior for an MVS data set. PATHOPTS=(ORDWR,OCREAT,OTRUNC) This creates the Unix file if it does not already exist, and allows the program to use the existing file when it already exists. Additionally, when the program opens the file its file length is truncated to zero. There currently is no equivalent behavior for an MVS data set. PATHOPTS=(ORDWR,OCREAT,OAPPEND) This creates the Unix file if it does not already exist, and allows the program to use the existing file when it already exists. Additionally, the file offset is set to the end of the file after earch write, so that data is written at the end of the file. This behavior is similar to DISP=(MOD,CATLG) for an MVS data set. I would like to see two new PATH options that behave in a manner similar to the two options above that are not currently supported for MVS data sets. I suggest the following: DISP=CREAT: Similar in behavior to PATHOPTS=(ORDWR,OCREAT). DISP=TRUNC: Similar in behavior to PATHOPTS=(ORDWR,OCREAT,OTRUNC) If I make an RFE for this will you vote for it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
On Fri, 30 Jun 2017 17:39:49 +, Frank Swarbrick wrote: >One MVS behavior that has annoyed me since we migrated to z/OS from VSE is the >fact that MVS has no DISP option that will both create a data set if it does >not already exist and simply allow its use if it does already exist. One has >to "emulate" this behavior using a two step process, where step 1 specifies >DISP=(MOD,DELETE) and step two specifies DISP=NEW. > Doesn't take two steps; it can be done within one step with some Byzantine DD statements: //HANDLE DD DISP=MOD,CATLG,UNIT=SYSALLDA,SPACE=(...),DSN=... //SYSUT2 DD DISP-SHR,DSN=*.HANDLE,VOL=REF=*.HANDLE. >Since this use case exists so often (in my environment, anyway!), shouldn't >there be direct JCL support, probably a new DISP option, to perform this >behavior without the need for an additional step to first delete the file (if >it exists) so that the DISP=NEW in the later step will always succeed? > Good luck; I'm not betting on it. But I hear you. >MVS *does* have such a feature for Unix system files. The following assume >the default PATHDISP=(KEEP,DELETE). > >PATHOPTS=(ORDWR,OCREAT,OEXCL) >This creates the Unix file if it does not already exist, and gives a JCL error >if the file does already exist. >This behavior is similar to DISP=(NEW,CATLG) for an MVS data set. > True. Very similar. >PATHOPTS=(ORDWR,OCREAT) >This creates the Unix file if it does not already exist, and allows the >program to use the existing file when it already exists. >There currently is no equivalent behavior for an MVS data set. > >PATHOPTS=(ORDWR,OCREAT,OTRUNC) >This creates the Unix file if it does not already exist, and allows the >program to use the existing file when it already exists. Additionally, when >the program opens the file its file length is truncated to zero. >There currently is no equivalent behavior for an MVS data set. > True. That's what you're asking for. >PATHOPTS=(ORDWR,OCREAT,OAPPEND) >This creates the Unix file if it does not already exist, and allows the >program to use the existing file when it already exists. Additionally, the >file offset is set to the end of the file after earch write, so that data is >written at the end of the file. >This behavior is similar to DISP=(MOD,CATLG) for an MVS data set. > >I would like to see two new PATH options that behave in a manner similar to >the two options above that are not currently supported for MVS data sets. I >suggest the following: > ITYM "DISP", not "PATH". >DISP=CREAT: Similar in behavior to PATHOPTS=(ORDWR,OCREAT). >DISP=TRUNC: Similar in behavior to PATHOPTS=(ORDWR,OCREAT,OTRUNC) > >If I make an RFE for this will you vote for it? > I suspect it's a waste of time. And JES3 setup would need to accommodate it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Possible RFE for new DISP JCL parameter options
I would vote for it Dennis Roach, CISSP, PMP AIG IAM Platform Administration | Identity & Access Management 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019 Phone: 713-831-8799 dennis.ro...@aig.com | www.aig.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, June 30, 2017 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Possible RFE for new DISP JCL parameter options One MVS behavior that has annoyed me since we migrated to z/OS from VSE is the fact that MVS has no DISP option that will both create a data set if it does not already exist and simply allow its use if it does already exist. One has to "emulate" this behavior using a two step process, where step 1 specifies DISP=(MOD,DELETE) and step two specifies DISP=NEW. Since this use case exists so often (in my environment, anyway!), shouldn't there be direct JCL support, probably a new DISP option, to perform this behavior without the need for an additional step to first delete the file (if it exists) so that the DISP=NEW in the later step will always succeed? MVS *does* have such a feature for Unix system files. The following assume the default PATHDISP=(KEEP,DELETE). PATHOPTS=(ORDWR,OCREAT,OEXCL) This creates the Unix file if it does not already exist, and gives a JCL error if the file does already exist. This behavior is similar to DISP=(NEW,CATLG) for an MVS data set. PATHOPTS=(ORDWR,OCREAT) This creates the Unix file if it does not already exist, and allows the program to use the existing file when it already exists. There currently is no equivalent behavior for an MVS data set. PATHOPTS=(ORDWR,OCREAT,OTRUNC) This creates the Unix file if it does not already exist, and allows the program to use the existing file when it already exists. Additionally, when the program opens the file its file length is truncated to zero. There currently is no equivalent behavior for an MVS data set. PATHOPTS=(ORDWR,OCREAT,OAPPEND) This creates the Unix file if it does not already exist, and allows the program to use the existing file when it already exists. Additionally, the file offset is set to the end of the file after earch write, so that data is written at the end of the file. This behavior is similar to DISP=(MOD,CATLG) for an MVS data set. I would like to see two new PATH options that behave in a manner similar to the two options above that are not currently supported for MVS data sets. I suggest the following: DISP=CREAT: Similar in behavior to PATHOPTS=(ORDWR,OCREAT). DISP=TRUNC: Similar in behavior to PATHOPTS=(ORDWR,OCREAT,OTRUNC) If I make an RFE for this will you vote for it? Thanks, Frank -- 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
