Re: DSN SYNTAX (was: ... last node in DFSORT)
On Wed, 27 May 2020 19:04:09 +, Seymour J Metz wrote: >No, it is not correct; it does not check the lengths of quoted components, but >it does check the total length. > IBM agrees, promptly: IBM>Hello. IBM>I am the writer for the z/OS JCL Reference documentation and have received your comment ... IBM>I forwarded your email to development and here is their response. Thanks for sending your comments. As a result, I will make an update in the book. IBM>"We do check for length when the name is specified in quotes. You can remove the reference to length in that excerpt of text." -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSN SYNTAX (was: ... last node in DFSORT)
Hence my reference to the bleeding corpse of orthogonality. The obvious way to generate JCL is with RECFM=255 and a large LRECL, but why should you have to? It's what I call user fiendly (sic). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, May 27, 2020 12:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DSN SYNTAX (was: ... last node in DFSORT) On Wed, 27 May 2020 23:29:23 +0800, David Crayford wrote: >>> //... >> This moved me to look up DSN syntax in the JCL Ref. >> It's chaos; I detect no plan in the design; it was put >> together One Piece At A Time: >> https://www.youtube.com/watch?v=060A15ELz00 >Agreed! I had to write a program to create JCL that wrapped the UNIX >path names over multiple lines. It beggars belief but it is what it is I >suppose! > Yup. o Especially when generating JCL with a program. A symbol can't be split over a continuation. The converter does things in the wrong order; it should first join continuations, then resolve symbols. It may be necessary to insert several symbols that evaluate to empty string earlier in the argument in order that no symbol is split. And there's no upward-compatible fix. o And why does allocation limit DALPATH to 255 bytes when: - The OMVS limit is much larger? - The count field in the TU is 16 bits? As I said, One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 ... with a dash of Conway's Law. --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: DSN SYNTAX (was: ... last node in DFSORT)
No, it is not correct; it does not check the lengths of quoted components, but it does check the total length. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, May 27, 2020 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DSN SYNTAX (was: ... last node in DFSORT) On Wed, 27 May 2020 03:13:08 +, Seymour J Metz wrote: >PATH ¬= DSN > But he did include the substring ".dsn" in the pathname. > >From: Sri h Kolusu >Sent: Tuesday, May 26, 2020 9:49 PM >... >> Empirically, I found I couldn't create a DSN starting with a period even >> within apostrophes. I don't know where this is documented. > >This works fine for me >... >//SORTOUT DD PATH='/tmp/.create.dsn.with.period', >//... This moved me to look up DSN syntax in the JCL Ref. It's chaos; I detect no plan in the design; it was put together One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 One sentence in particular moved me to an RCF: Hello, MHVRCFs, In: z/OS Version 2 Release 4 MVS JCL Reference IBM SA23-1385-40 Under DD:DSNAME Syntax I see: • The system does not check data set names enclosed in apostrophes for valid characters or valid length. That seems to imply that "the system" permits data set names longer than 44 characters. Is that correct, or is a clarification required? Thanks, 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: DSN SYNTAX (was: ... last node in DFSORT)
Yes, but he had no apostrophes in his input. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, May 27, 2020 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DSN SYNTAX (was: ... last node in DFSORT) Not an excuse but I bet they mean they don't validate the length of the node names. DSN='MYLONGNODE.WHATEVER' is valid. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2020 8:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DSN SYNTAX (was: ... last node in DFSORT) On Wed, 27 May 2020 03:13:08 +, Seymour J Metz wrote: >PATH ¬= DSN > But he did include the substring ".dsn" in the pathname. > >From: Sri h Kolusu >Sent: Tuesday, May 26, 2020 9:49 PM >... >> Empirically, I found I couldn't create a DSN starting with a period even >> within apostrophes. I don't know where this is documented. > >This works fine for me >... >//SORTOUT DD PATH='/tmp/.create.dsn.with.period', >//... This moved me to look up DSN syntax in the JCL Ref. It's chaos; I detect no plan in the design; it was put together One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 One sentence in particular moved me to an RCF: Hello, MHVRCFs, In: z/OS Version 2 Release 4 MVS JCL Reference IBM SA23-1385-40 Under DD:DSNAME Syntax I see: • The system does not check data set names enclosed in apostrophes for valid characters or valid length. That seems to imply that "the system" permits data set names longer than 44 characters. Is that correct, or is a clarification required? Thanks, 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: DSN SYNTAX (was: ... last node in DFSORT)
JCL had design flaws from Day One, e.g., the abysmal default for SPACE. I'm fairly sure that SYSCTLG was there from the start, and I believe that Control Volumes (CVOLs) were as well. The late entry of Unix paths doesn't explain the limit of 255; if anything, that makes it harder to justify. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, May 27, 2020 2:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DSN SYNTAX (was: ... last node in DFSORT) Well, it was designed one piece at a time. First came DSN's and VTOC's; then came catalogs; then came UNIX filenames. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2020 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DSN SYNTAX (was: ... last node in DFSORT) On Wed, 27 May 2020 23:29:23 +0800, David Crayford wrote: >>> //... >> This moved me to look up DSN syntax in the JCL Ref. >> It's chaos; I detect no plan in the design; it was put >> together One Piece At A Time: >> https://www.youtube.com/watch?v=060A15ELz00 >Agreed! I had to write a program to create JCL that wrapped the UNIX >path names over multiple lines. It beggars belief but it is what it is I >suppose! > Yup. o Especially when generating JCL with a program. A symbol can't be split over a continuation. The converter does things in the wrong order; it should first join continuations, then resolve symbols. It may be necessary to insert several symbols that evaluate to empty string earlier in the argument in order that no symbol is split. And there's no upward-compatible fix. o And why does allocation limit DALPATH to 255 bytes when: - The OMVS limit is much larger? - The count field in the TU is 16 bits? As I said, One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 ... with a dash of Conway's Law. --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: DSN SYNTAX (was: ... last node in DFSORT)
Well, it was designed one piece at a time. First came DSN's and VTOC's; then came catalogs; then came UNIX filenames. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2020 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DSN SYNTAX (was: ... last node in DFSORT) On Wed, 27 May 2020 23:29:23 +0800, David Crayford wrote: >>> //... >> This moved me to look up DSN syntax in the JCL Ref. >> It's chaos; I detect no plan in the design; it was put >> together One Piece At A Time: >> https://www.youtube.com/watch?v=060A15ELz00 >Agreed! I had to write a program to create JCL that wrapped the UNIX >path names over multiple lines. It beggars belief but it is what it is I >suppose! > Yup. o Especially when generating JCL with a program. A symbol can't be split over a continuation. The converter does things in the wrong order; it should first join continuations, then resolve symbols. It may be necessary to insert several symbols that evaluate to empty string earlier in the argument in order that no symbol is split. And there's no upward-compatible fix. o And why does allocation limit DALPATH to 255 bytes when: - The OMVS limit is much larger? - The count field in the TU is 16 bits? As I said, One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 ... with a dash of Conway's Law. --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: DSN SYNTAX (was: ... last node in DFSORT)
Not an excuse but I bet they mean they don't validate the length of the node names. DSN='MYLONGNODE.WHATEVER' is valid. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 27, 2020 8:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DSN SYNTAX (was: ... last node in DFSORT) On Wed, 27 May 2020 03:13:08 +, Seymour J Metz wrote: >PATH ¬= DSN > But he did include the substring ".dsn" in the pathname. > >From: Sri h Kolusu >Sent: Tuesday, May 26, 2020 9:49 PM >... >> Empirically, I found I couldn't create a DSN starting with a period even >> within apostrophes. I don't know where this is documented. > >This works fine for me >... >//SORTOUT DD PATH='/tmp/.create.dsn.with.period', >//... This moved me to look up DSN syntax in the JCL Ref. It's chaos; I detect no plan in the design; it was put together One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 One sentence in particular moved me to an RCF: Hello, MHVRCFs, In: z/OS Version 2 Release 4 MVS JCL Reference IBM SA23-1385-40 Under DD:DSNAME Syntax I see: • The system does not check data set names enclosed in apostrophes for valid characters or valid length. That seems to imply that "the system" permits data set names longer than 44 characters. Is that correct, or is a clarification required? Thanks, 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: DSN SYNTAX (was: ... last node in DFSORT)
I hate JCL! On 2020-05-28 12:11 AM, Paul Gilmartin wrote: On Wed, 27 May 2020 23:29:23 +0800, David Crayford wrote: //... This moved me to look up DSN syntax in the JCL Ref. It's chaos; I detect no plan in the design; it was put together One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 Agreed! I had to write a program to create JCL that wrapped the UNIX path names over multiple lines. It beggars belief but it is what it is I suppose! Yup. o Especially when generating JCL with a program. A symbol can't be split over a continuation. The converter does things in the wrong order; it should first join continuations, then resolve symbols. It may be necessary to insert several symbols that evaluate to empty string earlier in the argument in order that no symbol is split. And there's no upward-compatible fix. o And why does allocation limit DALPATH to 255 bytes when: - The OMVS limit is much larger? - The count field in the TU is 16 bits? As I said, One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 ... with a dash of Conway's Law. --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: DSN SYNTAX (was: ... last node in DFSORT)
On Wed, 27 May 2020 23:29:23 +0800, David Crayford wrote: >>> //... >> This moved me to look up DSN syntax in the JCL Ref. >> It's chaos; I detect no plan in the design; it was put >> together One Piece At A Time: >> https://www.youtube.com/watch?v=060A15ELz00 >Agreed! I had to write a program to create JCL that wrapped the UNIX >path names over multiple lines. It beggars belief but it is what it is I >suppose! > Yup. o Especially when generating JCL with a program. A symbol can't be split over a continuation. The converter does things in the wrong order; it should first join continuations, then resolve symbols. It may be necessary to insert several symbols that evaluate to empty string earlier in the argument in order that no symbol is split. And there's no upward-compatible fix. o And why does allocation limit DALPATH to 255 bytes when: - The OMVS limit is much larger? - The count field in the TU is 16 bits? As I said, One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 ... with a dash of Conway's Law. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSN SYNTAX (was: ... last node in DFSORT)
On 2020-05-27 11:20 PM, Paul Gilmartin wrote: From: Sri h Kolusu Sent: Tuesday, May 26, 2020 9:49 PM ... Empirically, I found I couldn't create a DSN starting with a period even within apostrophes. I don't know where this is documented. This works fine for me ... //SORTOUT DD PATH='/tmp/.create.dsn.with.period', //... This moved me to look up DSN syntax in the JCL Ref. It's chaos; I detect no plan in the design; it was put together One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 Agreed! I had to write a program to create JCL that wrapped the UNIX path names over multiple lines. It beggars belief but it is what it is I suppose! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DSN SYNTAX (was: ... last node in DFSORT)
On Wed, 27 May 2020 03:13:08 +, Seymour J Metz wrote: >PATH ¬= DSN > But he did include the substring ".dsn" in the pathname. > >From: Sri h Kolusu >Sent: Tuesday, May 26, 2020 9:49 PM >... >> Empirically, I found I couldn't create a DSN starting with a period even >> within apostrophes. I don't know where this is documented. > >This works fine for me >... >//SORTOUT DD PATH='/tmp/.create.dsn.with.period', >//... This moved me to look up DSN syntax in the JCL Ref. It's chaos; I detect no plan in the design; it was put together One Piece At A Time: https://www.youtube.com/watch?v=060A15ELz00 One sentence in particular moved me to an RCF: Hello, MHVRCFs, In: z/OS Version 2 Release 4 MVS JCL Reference IBM SA23-1385-40 Under DD:DSNAME Syntax I see: • The system does not check data set names enclosed in apostrophes for valid characters or valid length. That seems to imply that "the system" permits data set names longer than 44 characters. Is that correct, or is a clarification required? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
