Re: D M=STOR causes disaster

2016-01-05 Thread Charles Mari
In case this hasn't been mentioned already, the D M=STOR improvements referenced in OA47706 are also available on V2R1 (HBB7790) via APAR OA47439. Regards, Charles Mari z/OS Development - IBM -- For IBM-MAIN subscribe /

Re: D M=STOR causes disaster

2016-01-05 Thread Elardus Engelbrecht
Charles Mari wrote: >In case this hasn't been mentioned already, the D M=STOR improvements >referenced in OA47706 are also available on V2R1 (HBB7790) via APAR OA47439. Many thanks for mentioning OA47439. It was NOT mentioned here on IBM-MAIN. I will certainly pass this (and the other

Re: D M=STOR causes disaster

2016-01-05 Thread Charles Mari
Also worth noting... The D M=STOR improvements in OA47439 (V2R1) only take effect on systems with 512G or more of real storage. If less than 512G, you get the existing processing even with the APAR applied. In V2R2, the D M=STOR improvements are in effect regardless of the amount of real

Re: D M=STOR causes disaster

2016-01-04 Thread John McKown
On Mon, Jan 4, 2016 at 2:14 PM, R.S. wrote: > Quick update from another test: > Outage after the command took 2 minutes (!!!), but after that only non-SNA > (OSA-ICC) connectivity cam back, regular IP connections went back after > another 2-3 minutes. > It is

Re: D M=STOR causes disaster

2016-01-04 Thread Skip Robinson
M-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: > > &g

Re: D M=STOR causes disaster

2016-01-04 Thread R.S.
Just checked: Mark Zelden's IPLINFO (thank you Mark!) shows correct memory amount with no negative effects.. Obviously Support Element shows memory allocation with no effects as well. TASID - I have version 5.19 installed, which shows some false value: 73 741 824KB (real value is 1 073 741

Re: D M=STOR causes disaster

2016-01-04 Thread Jim Mulder
> The following scenario: z13 2964-N30 401 (yes, the smallest CPU) and > ~1,5TB of memory. z/OS 1.13 with RSU at Oct-2015 (plus 2964DEVICE, AFAIK). > > 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,

Re: D M=STOR causes disaster

2016-01-04 Thread Martin Packer
gt; To: IBM-MAIN@LISTSERV.UA.EDU Date: 04/01/2016 21:05 Subject: Re: D M=STOR causes disaster Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 01/04/2016 02:35 PM, John Eells wrote: > Paul Gilmartin wrote: > >> From the APAR Radoslaw ci

Re: D M=STOR causes disaster

2016-01-04 Thread John Eells
Joel C. Ewing wrote: If this is an issue that had minor impact when real memory was much smaller, perhaps an INFO categorization was appropriate then. If with typical memory configurations of today it is now causing the appearance to end users of an outage of several minutes, the impact is no

Re: D M=STOR causes disaster

2016-01-04 Thread R.S.
W dniu 2016-01-04 o 19:46, Jim Mulder pisze: [...] IMHO such behavior is unacceptable even for testing activities. While I can avoid (and RACF-protect) the command, I have no idea whether some piece of software would issue the same service internally. Is it bug or feature? In other words, can I

Re: D M=STOR causes disaster

2016-01-04 Thread R.S.
Quick update from another test: Outage after the command took 2 minutes (!!!), but after that only non-SNA (OSA-ICC) connectivity cam back, regular IP connections went back after another 2-3 minutes. It is definitely not minor issue. -- Radoslaw Skorupka Lodz, Poland -- Treść tej

Re: D M=STOR causes disaster

2016-01-04 Thread John Eells
Paul Gilmartin wrote: From the APAR Radoslaw cited: http://www-01.ibm.com/support/docview.wss?uid=isg1II14147 Modified date: 2006-02-28 APAR status INTRAN "INTRAN" for 9+ years? I guess that's one way to avoid saying "WAD" or "PRS". It's not a defect APAR, but an INFO APAR;

Re: D M=STOR causes disaster

2016-01-04 Thread Joel C. Ewing
On 01/04/2016 02:35 PM, John Eells wrote: > Paul Gilmartin wrote: > >> From the APAR Radoslaw cited: >> http://www-01.ibm.com/support/docview.wss?uid=isg1II14147 >> >> Modified date: >> 2006-02-28 >> >> APAR status >> INTRAN >> > >> >> "INTRAN" for 9+ years? I guess that's one way to

Re: D M=STOR causes disaster

2016-01-04 Thread Jim Mulder
> If this is an issue that had minor impact when real memory was much > smaller, perhaps an INFO categorization was appropriate then. If with > typical memory configurations of today it is now causing the appearance > to end users of an outage of several minutes, the impact is no longer > minor

Re: D M=STOR causes disaster

2016-01-04 Thread Massimo Biancucci
Hi, IMHO IBM should fix it as far as it's possible even though the sentence "it works as designed" could make us think there's no way. I've ever thought such a command was "something of really simple" up to now. After you post I read with more attention the command scope and the expected

Re: D M=STOR causes disaster

2016-01-04 Thread Elardus Engelbrecht
R. Skorupka wrote: >The following scenario: z13 2964-N30 401 (yes, the smallest CPU) and ~1,5TB of >memory. z/OS 1.13 with RSU at Oct-2015 (plus 2964DEVICE, AFAIK). Is that ONE CPU? How many LPARS are using that CPU? >D M=STOR causes weird effects. System freeze for a while. For 2GB LPAR

Re: D M=STOR causes disaster

2016-01-04 Thread Paul Gilmartin
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

D M=STOR causes disaster

2016-01-04 Thread R.S.
The following scenario: z13 2964-N30 401 (yes, the smallest CPU) and ~1,5TB of memory. z/OS 1.13 with RSU at Oct-2015 (plus 2964DEVICE, AFAIK). 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