-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Wednesday, January 09, 2008 1:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LSQA orphan storage
On Tue, 8 Jan 2008 16:07:51 -0800, George Fogg <[EMAIL PROTECTED]> wrote: >I've only seen this behavior (ACEE and associated control blocks like >CGRP) when a job does not issue a RACROUTE REQUEST=VERIFY, >ENVIR=DELETE. I had to run a getmain trace to see what job was >allocating subpool 255. Found that it was an in-house application. I >would thing RTM would clean the ACEE(s) up when the job was canceled. >George Fogg I would expect some termination processing in the initiator to clean up the address space ACEE (ASXBSENV), but probably not TCB-level ACEEs or other ACEEs created by an APF-authorized program. The program that created those ACEEs is responsible for freeing them, and for providing recovery routines that will do so if the program abends or you cancel it. Or the program could use a subpool that RTM will clean up automatically. If it uses the default subpool of 255 then RTM shouldn't touch them as that storage is defined as "life of address space" not "life of job", and canceling the job leaves the address space around. <SNIP> And after that program has issued ENVIR=DELETE? Whose responsibility is it to get rid of them? If RACF decides to cache them in the user's address space for some period of time, but then the JOB gets cancelled... And that is where we see this. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- ---------------------------------------------------------------------- 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
