If I were diagnosing this problem, I would take a console dump of ASID 1. If a resource manager is the culprit and it uses an eye catcher, I would expect to see a bunch of storage with that eye catcher. I was simply suggesting that an ASCB resource manager is a good possibility. Resource managers can be dynamically defined by the RESMGR service or statically defined at IPL. Chapter 18 in the MVS Programming: Authorized Assembler Service Guide has a section on resource managers including those statically defined at IPL time. I would look at the statically defined resource managers first particularly any that are defined to execute after the termination of all address spaces.
Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Martin Packer Sent: Monday, September 16, 2013 8:46 AM To: [email protected] Subject: Re: Memory For MSTJCL00 - Whose Is It? Thank you. Care to name a few - not to point the finger, but so I have some idea what they are? Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: [email protected] Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Kenneth Wilkerson <[email protected]> To: [email protected], Date: 09/16/2013 02:38 PM Subject: Re: Memory For MSTJCL00 - Whose Is It? Sent by: IBM Mainframe Discussion List <[email protected]> Address space resource managers execute in asid 1, *MASTER*. Unless they issue a message, you would never know they executed. If an ASCB RESMGR were not cleaning up after itself, it would account for accumulations. Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Staller, Allan Sent: Monday, September 16, 2013 8:01 AM To: [email protected] Subject: Re: Memory For MSTJCL00 - Whose Is It? General thoughts with no hard data behind them. I.E. SWAGs 1) MSTJCL00 (i.e. *MASTER*) has been flagged by WLM as Storage Critical. Check w/WLM development. 2) Turn on the VSM* parameters in SYS1.PARMLIB(DIAG*) for data gathering. View w/IPCS and/or RMF. Not sure what (if any) RSM* parameters are available. I believe your theory about MSTJCL00 being used as an anchor is reasonable, however, 2 GB of anchors seems excessive, even in a very large system. I do not believe this is a backing for anything that does not belong to a "system address space". FWIW, <snip> Almost a year ago in https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/bad_da ta_and_the_subjunctive_mood?lang=en I talked about seeing large numbers for memory in MSTJCL00. At the time I got no takers as to what it could be. So I'm trying again here... ... Is MSTJCL00 the anchor for something? Common Large Memory Objects perhaps? And are YOU seeing large memory numbers? </snip> ---------------------------------------------------------------------- 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- 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
