I hope that there is at last a warning associated with that, if not an option for strict enforcement: the most recently active CSECT might not be what was intended.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Jonathan Scott [[email protected]] Sent: Friday, January 1, 2021 10:12 AM To: [email protected] Subject: Re: Metal C CATTR Assembly error Ref: Your note of Fri, 1 Jan 2021 07:31:30 -0500 Joe Reichman <[email protected]> writes: > I am getting the following error on a CATTR Assembly statement > > 0001B0A 00000000 00001B51 2833 OPENFI#C CSECT , > 000000 > > 2834 M_WSA CATTR > RMODE(ANY),PART(openfile),NOTEXECUTABLE,ALIGN(2) 000000 > > ** ASMA155S Previous use of symbol is not this section type You probably need HLASM APAR PH05788, for which the MVS PTF is UI60232 (from December 2018). The original implementation of CATTR in HLASM did not work exactly as documented. When APAR PI76678 changed HLASM to work as documented, this caused errors in some programs generated by Metal C, because the compiler could incorrectly issue CATTR within a DSECT to define the Writable Static Area (WSA), which is not supported by the Binder (although HLASM at the time failed to detect this conflict). HLASM was therefore changed again by APAR PH05788 to tolerate this incorrect usage, in that if CATTR with a given name was first issued within a DSECT, the definition would be associated with the most recently active CSECT. The Metal C compiler was also changed for APAR PI84091 to avoid the incorrect usage, although this was no longer necessary with the HLASM fix. Of course, if you already have all the relevant maintenance applied, this might be a new problem, in which case please report it as a possible defect (initially against Metal C, who can of course pass it on to HLASM if the generated HLASM code turns out to be correct). Jonathan Scott, HLASM IBM Hursley, UK
