To concur with the answers to the original question: 126. Period. And regarding substitution: no exceptions. This is one reason why normal system symbols limit their substitution text to be no longer than the symbol name. If you use those symbols you cannot increase the size of your text. And if you choose to use the "_" trailer, it is up to you to deal with (and/or avoid) any overflow, in general.
Regarding the "typical format" vs "second format" -- I did not realize they had chosen to document my command style as a "second" format. These are all commands that I designed and implemented, and likely others have followed. Unfortunately no one asked me to review the doc. The problems I see with the doc of the second format are -- it does not clearly describe the differences of the second format from the typical format or emphasize the main difference -- it is not a "restriction" that you "may, but do not have to, use a comma". That is the reverse of a restriction. It is a flexibility. I do not agree that there is much of an implication that any command can use this second format, but changing "required by" to "used by" could help. Note that under "Typical format" it mentions "Most...can use". That implies that some cannot (which is true). But it also follows that "use" is a good term to use in the other section too. And I'd change the "Typical format" to remove the word "can". The one thing that I intended to document was how to do comments in these commands. SETPROG does that. As a logical consequence, unlike the "Typical format" commands, a blank is not a comment delimiter. While it is true that commas are optional for this second formatl, there was no requirement (or even request by me) to document that. It is reasonable to do so, but you won't see in the documentation for the PROGxx parmlib member that commas may be used as separators instead of blanks. It happens to be true (because PROGxx and SETPROG share a parser, so both support both ways), but the intent was always to document the style that was typical (commands use keyword=value notation with comma separators, parmlib members use keyword(value) notation with blank separators). To me, then, the more interesting thing is that SETPROG lets you code in either command style or parmlib style, and so does PROGxx. If we are to leave this "second format" as a "thing", as an update I would have them start the text after the diagram with: The differences between the second format and typical format are that within the second format comments may appear after any operand and each comment begins with a slash-asterisk and ends with an asterisk-slash. <<I note that the current text talks about a comment as being within a slash-asterisk asterisk-slash pair. I think instead of the comment including the /* */. Isn't that more typical -- the slash-asterisk is "start of comment" and the "asterisk-slash" is end of comment?>> a blank does not indicate that everything following the blank is a comment commas are optional (blanks may be used as separators) Then the "restrictions" are not restrictions, just examples. Having looked here, I looked at what they said within SETPROG. I don't like how that was done either. SETPROG refers you to "System commands formats" which is a good start, but does not say why. It should refer you to the "a second format" subsection of "system commands format" since I assume that's what it is trying to get you to realize -- that this command uses the second format. Perhaps it should say that SETPROG uses the comment style described in the "a second format" section of "System commands formats". SETPROG, DISPLAY PROD, DISPLAY PROG have a note that each "requires a /* */ around comments". Instead, I'd suggest "begins a comment with /* and ends the comment with */". I also spotted the puzzling note (why bother?) "The SETPROG command does not have an abbreviation". Nor does just about any other command, and those don't have this note. If you agree with my thoughts here, I'll ask to get this updated... Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
