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 [0000000433f07816-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
