I Have the following load modules HLA.SASMMOD1 , HLA.SASMMOD2 and HLA.AASMMOD1 HLA.AASMMOD2
I have what I believe to be the ADCD May 2020 edition of z/os 2.4 The MVS ptf UI60232 is applied to load modules ASMA2@ and ASMA2W The HLA.SAS load librarys is what I have in my link list ASMA2@ and ASM2W does not exits in HLA.SASMMOD1 but does exist in HLA.AASMMOD1 the two load mods have UI60232 applied When I steplib HLA.AASMOD1 And HLA.AASMOD2 I get a S0C1 on the assembly thanks -----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Jonathan Scott Sent: Friday, January 1, 2021 10:12 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Metal C CATTR Assembly error Ref: Your note of Fri, 1 Jan 2021 07:31:30 -0500 Joe Reichman <reichman...@gmail.com> 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
