In the general case (amiglib perhaps an exception) to expect a DLIB (HLQ.Axxxxxx) to provide valid executables.
> -----Original Message----- > From: IBM Mainframe Assembler List <ASSEMBLER- > [email protected]> On Behalf Of Joe Reichman > Sent: Sunday, January 03, 2021 11:32 AM > To: [email protected] > Subject: Re: Metal C CATTR Assembly error > > 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- > [email protected]> On > Behalf Of Jonathan Scott > 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
