And for JCL perhaps 255 is a reasonable limit. With only about 55 usable columns on a JCL continuation statement, anything more than that becomes a little unwieldy. (Yes, one might say all JCL statements are unwieldy!)
But why does DYNALLOC limit to 255? With a 16-bit text unit length field it would be easy to accommodate 1023 (or, of course, 32767 or 65535). I guess '/' is the only valid 1-byte filename in JCL, right? It's the only possible 1-byte fully-qualified filename, correct? Is there any reason it makes sense to allocate '/' in JCL but not in TSO? OT, I also note the DYNALLOC text unit documentation contains the common misuse of "hexadecimal": "A two-byte hexadecimal number." No, hexadecimal is a way of making arbitrary data printable. It's a two-byte *binary* number. Sigh. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Friday, December 4, 2020 3:49 PM To: [email protected] Subject: TSO ALLOCATE Pathname Length? As long as we're discussing pathname length limits: The JCL Ref says the value of PATH may be from 1 to 255 bytes. The DYNALLOC Guide says the value of DALPATH may be from 1 to 255 bytes. TSO/E commands and subcommands: ALLOCATE Command, which I assume is based on DYNALLOC says PATH(pathname) Identifies a UNIX file. ... The path name can be 2 to 250 characters, including the initial slash. Why the somewhat more restrictive limit? ObEmerson: Consistency? Conway's Law? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
