Ref: Your note of Sun, 22 Nov 2020 11:35:41 -0500 Joe Reichman <[email protected]> writes: > Asking a few questions to see I understand the usage of CATTR > ...
CATTR is managed in the same way as other location counters such as CSECT and LOCTR. With GOFF, each new CSECT statement starts an element whose class name will be filled in later as B_TEXT and whose section name is the same as the CSECT name. It also generates a symbol definition associating the CSECT name as an external name with the start of the element. Coding CATTR starts a new element whose class name is given by the name field and which also belongs the current section (given by the current CSECT name). Do not attempt to specify class name B_TEXT explicitly for any purpose as this is not supported by HLASM and will probably cause errors at bind time. You can resume any existing location counter in the usual way (for example by a CSECT or LOCTR statement with the original name) to switch away from that element, and you can use CATTR again with the same name to resume the element. Uses for CATTR are rare, as it is primarily used to support compatibility with classes generated by compilers for special purposes. I certainly wouldn't recommend it in this case. All normal (sequential) I/O processing can be performed in 31-bit mode nowadays. The only aspect which requires 24-bit storage is the DCB. Since the DCB should be in dynamic storage rather than part of the program, that means you should acquire the relevant storage with LOC=BELOW. Exit addresses such as EODAD= should be specified via a DCBE to support 31-bit mode. If you really need separate loadable sections in 24-bit and 31-bit storage, just use a separate CSECT and specify the binder option RMODE(SPLIT). Jonathan Scott, HLASM IBM Hursley, UK
