On Wed, 7 Sep 2022 16:24:07 +0000, Sri h Kolusu wrote: >>> That contradicts "Column 1 ... blank" on page 80. A blank in column 1 is >>> *used* to indicate a control statement. > >Gil, > >Not sure as to what is contradictory. > >Statement 1 : "Column 1 of each control statement must be blank, unless the >first field is a label or a comment statement (see Inserting comment >statements)." >Statement 2 : " Column 1 of each control statement can be used only for a >label or for a comment statement that begins with an asterisk in column 1.” > The word "only" makes it contradictory. Column 1 is *used* for the blank indicating that the statement is neither a comment nor labelled.
>So Blank for Control statement and asterisks for Label or comment field. > >>> • Operation definers and operands must be in uppercase EBCDIC. Which >>> EBCDIC? 1047? 500? 037? Other (specify)? It matters. > >If you looked at the Appendix D you would have found “EBCDIC and ASCII >collating sequences” > >https://www.ibm.com/docs/en/zos/2.4.0?topic=sequences-ebcdic > The EBCDIC is incomplete. It shows only 91 (my count), less than half the 256 possibilities. Conspicuously, it omits [, ], {, and }; integral to DFSORT. Those characters occur at different code points in the popular 037, 500, and 1047 code pages. I mentioned this concern in an RCF several days ago. The ASCII is better; apparently complete. It's disturbing that the ATOE and ETOA tables are not inverses of each other. Those are called the TCP/IP "standard". Internet standards are admnistered by the IETF and bear RFC numbers. I see no RFC number. I suspect those tables are something IBM just made up and pretends they are a standard. >>> Is this the same Hexadecimal string format described above? No mention >>> except in an example of the leading "\". And that example shows: > >The Hexadecimal string definition is SAME across the operators >(INCLUDE/OMIT/INREC/OUTREC…). The leading “\” is used to denote the >Hexadecimal string. > It doesn't appear the same; INCLUDE/OMIT/INREC/OUTREC… lack the "\" but have apostrophes not shown in the regular expression example. And I consider it bad practice not to define syntax of a construct but merely to show a single example. >>> Then, Table 37. Examples of Valid and Invalid Hexadecimal String Separation >>> Like table 23, but more extensive. Is the earlier one necessary? The word >>> "Separation" doesn't seem to fit. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
