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 /
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
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
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
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
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
> 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,
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
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
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
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
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;
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
> 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
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
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
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
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
18 matches
Mail list logo