Good morning JimI am sending this email off list and I hope that you would help me.I am working to adapt the S390X SLJIT engine to native z/OS. The current development direction is bound toLinux, as the initiative came from the IBM Linux team. Therefore, the code is peppered with Linux mambo jumbo and is using C headers not available in the normal IBM C that I am using (to create LE comptible code, not Linux). Basically they use gcc and make their effort incompatible.Yet, I want the result code of my effort to be as compatible as possible. If I want to allocate storage for executale purpose in normal IBM C, protecting it the z/OS way, what should I do? Thank youZe'ev Atlas
Sent from Yahoo Mail on Android On Tue, Nov 17, 2020 at 2:11 AM, Jim Mulder<[email protected]> wrote: That is correct, a subpool has 2 SPQEs - one for EXECUTABLE=YES, and one for EXECUTEABLE=NO. In z/OS 2.3 and 2.4, we search only the SPQE for the EXECUTABLE attribute that you specify when releasing storage, In future release which follows z/OS 2.4, release processing has been enhanced to treat what you specify as a performance hint, and search that SPQE first, and then search the other one if necessary. So you will no longer need to specify EXECUTABLE correctly on the release, but you will get better performance if you do. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" <[email protected]> wrote on 11/16/2020 05:29:02 PM: > From: "Ngan, Robert" <[email protected]> > To: [email protected] > Date: 11/17/2020 02:03 AM > Subject: Re: security with storage allocation under z.OS > Sent by: "IBM Mainframe Assembler List" <[email protected]> > > I found out the hard way that, if you code EXECUTABLE=YES of the > STORAGE OBTAIN, you must also code it on the associated STORAGE RELEASE. > Evidently, it's implemented as a subpool under the covers, so like > subpool getmains, you must have matching values on OBTAIN and RELEASE. > > Robert Ngan > HCL Technologies
