Short answer: Choose a job-step owned subpool. They are documented in the authorized assembler services guide SA22-7608.
More complicated answer: "It depends what you're trying to accomplish". You can just pick an appropriate job step task owned subpool but you must bear in mind that there may be a different job step task (and a different set of job step subpools) depending on which task you happen to be running under when the exit is called and, in the case of a batch address space, whether there is a job running in the initiator or not. e.g. early SMF exits like IEFUSI run under the initiator task before the "real" job step is attached and (IIRC) late exits like IEFACRT run after the job step is detached. The lifetime of a piece of task owned storage is bounded by the life of the task itself and if that task also happens to be a job step, then the life of any job step storage obtained by that task or its subtasks will also be bounded by that task. If you used job step storage owned by the real application's job step task, it would be gone when the next step got control. SO the major stumbling block is choosing the correct storage owning task. You can specify the address of the correct owning TCB on the STORAGE macro if necessary (and assuming the exit runs privileged which almost all do) You need to check your exit documentation carefully and understand what the dispatching environment looks like when the exit gets control. You also need to be aware of the storage key and the key your exit runs in, but that's a whole nuther long winded subject. If you want a hunk of storage you can stash stuff in and come back to it over and over each time you're called then you will also need some sort of skyhook to recover the storage address on the 2nd and subsequent calls. Some exits give you a handy dandy place in the input parameter list to stash just such a pointer and they give it back to you every time you call. Others may not be so helpful and you would have to resort to, shall we say, "creativity". There are ways of doing this (e.g. Name/Tokens) but they also have problems with task and step lifetime and you're not supposed to call them at all from within EOT resource managers and SSI calls - at least according to the books anyway. Bottom line; study the exit description and pick the task, storage subpool and anchoring mechanism to suit the circumstances presented by that exit. CC On Wed, May 27, 2009 at 4:55 PM, Ward, Mike S <[email protected]> wrote: > I investigated the Storage macro and it seems to work just like the > getmain and freemain macros. If you have any expertise in selecting > persistent storage, I'm more than happy to listen. It seems there are 4 > types of storage. Task, job step, address space, and system. I was > thinking that job step storage would be a good candidate, but I'm not > sure of how to code that request in a Storage obtain. Would you have any > hints in this area? > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of [email protected] > Sent: Wednesday, May 27, 2009 2:42 PM > To: [email protected] > Subject: Re: z/OS STORAGE service > > Mike Ward wrote: > I would like to use the persistent storage between invocations, but I > can't seem to find anything on the "z/OS STORAGE service". > > If this is an MQ Client Channel Exit You need to be very careful how you > obtain, pass, and release storage. > Will You be passing the address of the storage between invocation of an > individual exit ? -or- are You passing the persistent storage area to > other Channal Exits ? > > > > ____________________________________________________________ > Earn a degree in Criminal Justice and work as a Police officer. Click > here for more info. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEe1ZgF1qH5ErFg0ueneEe > hGSamcQ8ZWPXgTmUXh9eEqtch6tcsms/ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ========================== > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity > to which they are addressed. If you have received this email in error > please notify the system manager. This message > contains confidential information and is intended only for the individual > named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please notify the > sender immediately by e-mail if you > have received this e-mail by mistake and delete this e-mail from your > system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this > information is strictly prohibited. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
