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 [email protected] with the message: INFO IBM-MAIN

Reply via email to