Thanks John. I will give that a try. Peter
-----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Friday, March 17, 2017 2:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: How to automatically position generated data areas after all program-defined areas On Fri, Mar 17, 2017 at 1:22 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Thanks John, that does look like it would work, though it does still > require adding that last "MACINIT LOCCTR" statement manually at the > end of the program code and data. > > But if I have to manually place a statement at the end of the program > anyway it may as well be a MACDATA macro that just defines all the > data areas there. > Sorry I wasn't clearer. You only need the last "MACINIT LOCTR" in open code if you want to add _more_ data into that LOCTR. Otherwise, just leave it off. It is _not_ needed to "generate the data" or tell HLASM "put the MACINIT data here". If you only have the CSECT and the MACINIT LOCTR, then everything defined in the MACINIT macro will be gathered together, in the same relative order, and placed at the very end; after all the things (data & code) generated in the CSECT (i.e. the stuff outside the MACINIT macro and the stuff within the MACINIT macro which is after the "&HOLD LOCTR" instruction, but before any "MACINIT LOCTR" instruction). > > Now if the assembler had a CSECT length value I could safely use, an > "ORG csect_name+csect_length" inside of MACINIT in front of the data > definitions would take care of the problem for me, with a blank "ORG" > to return to the in-line code. > > Peter > > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of John McKown > Sent: Friday, March 17, 2017 2:06 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: How to automatically position generated data areas after > all program-defined areas > > On Fri, Mar 17, 2017 at 12:29 PM, Farley, Peter x23353 < > peter.far...@broadridge.com> wrote: > > > I cannot see a way to do the following, so any enlightenment you can > > provide is appreciated. > > > > I have created new versions of an existing set of macros and the new > > versions require a fairly large set of non-reentrant data areas > > defined in the CSECT in which they are used. The first macro > > invoked (say, MACINIT) needs to define these areas in existing > > assembler programs that may or may not be close to exceeding their > > defined base registers. This is old, non-reentrant code that has > > not been converted to "baseless" mode, and doing that conversion now > > is not on the table due to time and resource constraints. > > > > Rather than defining the new data areas at the place where MACINIT > > is invoked (there is code as well as data in MACINIT, and the code > > has to be positioned near the start of the program), I would like to > > be able to have MACINIT place all of the new data areas AFTER all > > other data or code defined in the CSECT. > > > > All of the new data areas are referred to in the new macro versions > > by "relative long" instructions in the generated code, so they will > > work correctly even if the data areas are totally outside of the > > defined base register coverage areas. > > > > I have looked at the LOCCTR assembler instruction thinking that it > > might be a way to accomplish what I want to do, but I am not really > > clear on how to use it, or even if that is a way for me to do what I > want to do. > > > > So far the only way to accomplish this that I can see is to have a > > separate "MACDATA" macro to be manually inserted into the old code > > at the appropriate position. I would prefer an automated solution > > that does not require a new "data" macro, if at all possible. > > > > TIA for any help you can provide. > > > > Peter > > > > > I think that LOCTR is definitely the way to go. You MACINIT has two > parts to it: the code part and the data part. The relative positions > of the "contents" of the various LOCTRs are in the relative definition > sequence. > The initial LOCTR has the same name as your > START/CSECT/DSECT/RSECT/CATTR/COM (whichever you're doing). So your MACINIT > could look (for use in a CSECT): > > MACRO > &LBL MACINIT ... > &HOLD SETC '&SYSLOC' SAVE CURRENT LOCTR NAME > &LBL DS 0H > LARL R??,MACINIT_DATA SELECT UNUSED REGISTER > USING MACINIT_DATA,R?? ADDRESS DATA > ... SOME MORE CODE > MACINIT LOCTR , DATA LOCATION > ... DEFINE DATA > &HOLD LOCTR , RESUME PREVIOUS LOCATION > ... MORE CODE > MACINIT LOCTR , RESUME DATA LOCATION > .... MORE DATA > &HOLD LOCTR , RESUME PREVIOUS LOCATION > DROP R?? FORGET MAPPING > MEND > > At the end of your code, before any DSECTs or other such things: > > ... END OF CODE > MACINIT LOCTR , FINISH UP MACINIT DATA ... REGULAR DATA FOR MACINIT > USE, IF ANY &SYSECT LOCTR , RESUME CSECT LOCTR ... DSECT DEFINITIONS, > ET AL. > END > > > Now, the stuff generated while the MACINIT LOCTR was in effect will > go after all the code / data defined at the CSECT level LOCTR. If you > don't use any other LOCTRs in your code, this means it will be at the > _end_ of the CSECT. You can access the MACINIT data via register R??, > which is loaded each time in the MACINIT via the LARL (Load Address Relative > Long). > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
