Dependencies: AMODE 64 Someone explain that one to me. You need to be running 64-bit to allocate 24-bit storage.
That is probably why I did not use it! Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mario Bezzi Sent: Thursday, July 15, 2021 3:22 PM To: [email protected] Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM Charles, at least that's my understanding reading the doc. https://www.ibm.com/docs/en/zos/2.4.0?topic=functions-malloc24-allocate-24-bit-storage "Related information ..See the topic about using the system programming C facilities in z/OS XL C/C++ Programming Guide. .." https://www.ibm.com/docs/en/zos/2.4.0?topic=environments-using-system-programming-c-facilities mario On 7/15/21 8:54 PM, Charles Mills wrote: > That would certainly account for it! <g> 100% of my experience is full LE C++. > > But are you sure? I don't see any such restriction in the library reference > and I know the LE diagnostic storage report shows a below-the-line heap. The > library manual says it is supported for C++, which to me would seem to imply > "full" support. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Mario Bezzi > Sent: Thursday, July 15, 2021 11:23 AM > To: [email protected] > Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM > > As far as I know __malloc24 is only available when running in a System > programming C environment, which is an early incarnation of METAL-C and > does not use LE runtime services. Maybe this is the reason? > > mario > > On 7/15/21 12:30 AM, Charles Mills wrote: >> Correction: you can't use malloc or new to get the area -- they will return >> 31-bit storage. You might use __malloc24() which does the obvious. Looking >> at my code, I called out to a GETMAIN LOC=BELOW written in assembler. Can't >> tell you why I did that rather than use __malloc24(). >> >> Charles >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Charles Mills >> Sent: Wednesday, July 14, 2021 9:53 AM >> To: [email protected] >> Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM >> >> I played with the approach you suggest and abandoned the effort. Too hard, >> and too likely to break. >> >> What I did do that worked was code a number of atomic assembler routines >> that could be passed a DCB that was kept in an area that I malloc or new in >> C or C++. One of those routines was >> >> int MAKEDCB(void *DCBarea, const int DCBareaLen, const char *DCBtype, >> const char DDname[8]); >> >> It constructs a DCB in the C/C++ allocated area by moving in a model. >> DCBtype is, e.g., "BPAM". Other routines are, e.g., >> >> int OPNDCBIN(void *DCBarea); // OPEN a DCB for input >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
