Maybe this problem could be approached from the 'outside'. I think the basic information that the user is looking for is how much storage is allocated to an LPAR. The HMC has a storage mapping facility that shows fairly quickly how much storage each LPAR owns. AFAIK this query has no impact the OS itself. Modern z/OS has the ability to interface with the HMC for any number of purposes. Why not allow D M=STOR to use this 'external' mechanism? At least for a high level summary. I don't think many shops these days run with storage offline; if so, that could be displayed optionally with an extra keyword.
. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Monday, January 4, 2016 10:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: D M=STOR causes disaster > > On Mon, 4 Jan 2016 11:20:02 -0600, Elardus Engelbrecht wrote: > > >R. Skorupka wrote: > > > >>D M=STOR causes weird effects. System freeze for a while. For 2GB LPAR > system behavior is normal, for ~64GB LPAR there is few-second freeze, but for > 1,1TB LPAR system freeze for approx half a minute, TSO sessions are broken, > the *$HASP9211 JES2 MAIN TASK NOT RUNNING is issued. HMC monitor show > 100% CPU utilization. > > > "broken" forever? Or just unresponsive for half a minute? > > >>IMHO such behavior is unacceptable even for testing activities. > > > >Indeed. Time for a PMR. > > > >>Is it bug or feature? > > > >It is a buggy bug! Apparently the response time is worsening with increasing > memory size. I'm smelling a badly designed D M=STOR command handler. > > > From the APAR Radoslaw cited: http://www- > 01.ibm.com/support/docview.wss?uid=isg1II14147 > > Modified date: > 2006-02-28 > > APAR status > INTRAN > > Error description > Processing for the D M=CONFIG(xx) and D M=STOR commands must > interrogate long control block chains. the data collected by > IAXXR - RSM RECONFIGURE-REAL-STORAGE ROUTINE to satisfy these > commands is required to accomplish the functions. Anything less > would reduce or eliminate functionality, therefore this is > working as intended designed. > > "INTRAN" for 9+ years? I guess that's one way to avoid saying "WAD" or "PRS". > > But if the number of such control blocks varies linearly with real storage > (might > some be paged out?) it's a difficult fix. Is it worth it? Might there be a > way to > consolidate blocks for idle extents? Is it worth it? Too bad TSO/ISPF has no > analogue of the spinning beach ball cursor. Or a "COMMAND PROCEEDING" > message. Even if it's not the end user's command. A way to cancel the > command in progress and clean up its temporary objects might be no easier. > > I suspect locking is needed lest the subject change in flight. > > Was there any lasting damage? > > I remember I once issued DISPLAY UNIT 000-FFF and watched thousands of > lines of "NOT AVAILABLE" messages scroll by. I wished there were a way > similar messages could be consolidated into ranges. There are some things an > operator should do only with extreme discretion. > > (Why I shouldn't have substituted as an operator.) > > -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
