I think we're getting a lot of suggestions as if this were some system service. Name/token, CDE lookups and such are fine if you need to bootstrap yourself from some unknown state. The description of this program is just batch. Save the address in an external variable. LE provides macros to allocate and access externs from assembler. See CEEPDDA and CEEPLDA. Read the LE Programming Guide for descriptions. You can even share these areas with your C++ code.
Thompson, Steve wrote: > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Charles Mills > Sent: Sunday, February 21, 2010 8:00 PM > To: IBM-MAIN@bama.ua.edu > Subject: Best practice for 24-bit storage in assembler called from C/C++ > > I'm writing a fairly large MVS batch application in C++. At several > points > it is necessary to call "library" type routines that I am writing in > assembler. Several of the routines (unfortunately) need to use QSAM > macros > and so need below-the-line storage. > > > > Obviously I could do a GETMAIN or STORAGE OBTAIN LOC=24 on the way in > and > FREEMAIN or STORAGE RELEASE on the way out. But that's less than optimal > for > a routine that is called multiple times. (And it would not work at all > if > the routine had to save state across calls, but fortunately that is not > the > case, at least for my requirements so far.) > > > > I could make the calling C++ responsible for providing a "work area" > obtained with _malloc24(). But I don't like that for "aesthetic" reasons > - > violates encapsulation, making the caller responsible for the inner > workings > of the called function. > > > > Is there a better way? Is there some sort of "anchor word" where a > library > of called assembler routines could save an address across calls? Is this > what CEECAA_TCASRV_USERWORD in CEECAA is for? Does R12 reliably point to > the > CEECAA on entry? Can I count on CEECAA_TCASRV_USERWORD being initialized > to > zero? Where is this stuff documented? I don't see much in LE > Programming, in > LE ILC, or in the C/C++ Programming Guide. > > <SNIP> > > If you KNOW that you will be serialized, then you can either build your > DCB info into a REUSE program that you can LOAD. You can then call it to > do the I/O that you need done, not get into all the overhead of multiple > OPEN/CLOSE, etc. You can then do an INIT call and a Terminate call for > the OPEN and CLOSE issues. > > Otherwise, you can get the storage from your assembler routine, and then > have it IDENTIFY that storage so that you can find it again using LOAD, > or a run of the CDE chain(s). > > Just two options you might want to consider. > > Regards, > Steve Thompson > > -- Opinions expressed by this poster may not reflect those of poster's > employer -- > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Don Poitras - zSeries R & D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677-4444 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
