ypass and selecting UA94607. (And 31
> >others that had dependencies satisfied :) )
> >
> >Only running them in the sandboxes for now.
> >
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List On
> >> Behalf Of Brian Westerman
>
e PTFs to aid detecting and migrating from USERCSA.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List On
>> Behalf Of Jousma, David
>> Sent: Tuesday, September 17, 2019 12:00 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Considerin
You run into it when (for instance), VPSIP gets the 16e abend but won't come
down. Unfortunately, we found it the 'hard" way by cancelling VPSIP only to
have to IPL when IGC00020 went into a tight loop. It's still not completely
fixed, but we know now not to let VPSIP get anywhere close to
I completely agree, when I apply maintenance, I ALWAYS create an entirely new
target and dlib zone, and I keep the old one for at least a year.
Brian
On Tue, 17 Sep 2019 14:23:56 -0500, Tom Marchant
wrote:
>On Tue, 17 Sep 2019 19:00:04 +, Jousma, David wrote:
>
>>I suspect you won't
nal Message-
>> From: IBM Mainframe Discussion List On
>> Behalf Of Brian Westerman
>> Sent: Monday, September 16, 2019 9:22 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Considering Bypassing ERROR HOLD for OA58037
>>
>> That's part of a pret
Hello Dave,
yes you do need a newer level of MXG:-
Change 36.188 Support for new Bit 4 of SMF30_RAXFLAGS and creation of
BUILD005 these new bit-level variables with explanation in label
BUIL3005 SMF30_RAXFLAG0='RAX0*USERKEY*COMMON*AUDIT*ENABLED?'
VMAC30
019 12:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Considering Bypassing ERROR HOLD for OA58037
>
> I'm getting confused by this thread. I thought I recalled you had said the
> PTF
> you were bypassing was for S16E? All of those DEB Check PTF's are in
> support of the chang
ent: Tuesday, September 17, 2019 12:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Considering Bypassing ERROR HOLD for OA58037
>
> On Tue, 17 Sep 2019 19:00:04 +, Jousma, David
> wrote:
>
> >I suspect you won't have much luck backing these PTF's off because they
>
Incidentally, we do have UA95897 applied for over a year now, and have not run
into the scenario that OA58037 describes. Seems like a pretty small window of
problem, and even then, it was on a task/job that was being cancelled to begin
with. I'd probably open ticket with IBM on that APAR,
On Tue, 17 Sep 2019 19:00:04 +, Jousma, David wrote:
>I suspect you won't have much luck backing these PTF's off because they reach
>out and touch a lot of different modules. The only real option would be if
>you have a known complete backup of the entire SMPE environment *before* the
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gibney, Dave
Sent: Tuesday, September 17, 2019 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Considering Bypassing ERROR HOLD for OA58037
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from
Sent: Monday, September 16, 2019 9:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Considering Bypassing ERROR HOLD for OA58037
>
> On Mon, 16 Sep 2019 23:15:40 +, Gibney, Dave
> wrote:
>
> >Well, I did do this. But, I am not sure it was worth it. The
> ZOSMIGV2R
That is a LONG*** pe chain to restore/re-apply
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gibney, Dave
Sent: Tuesday, September 17, 2019 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Considering Bypassing ERROR HOLD for OA58037
Well, I do run VPS/TCPIP
2019 9:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Considering Bypassing ERROR HOLD for OA58037
>
> That's part of a pretty long comedy of errors that apply to (mostly) LRS's
> VPSIP product. If you are running VPSIP, like several of our sites, then you
> are likely aware
On Mon, 16 Sep 2019 23:15:40 +, Gibney, Dave wrote:
>Well, I did do this. But, I am not sure it was worth it. The
>ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM check only tells me what I already knew. That
>I have some address spaces using user key common. I had hoped it went further
>and identified
That's part of a pretty long comedy of errors that apply to (mostly) LRS's
VPSIP product. If you are running VPSIP, like several of our sites, then you
are likely aware of the issues that this whole string of aparas has caused.
On 17/09/2019 9:15 am, Gibney, Dave wrote:
Yes, I do see the info on interpreting SMF30_UserKeyCsaUsage and
SMF30_UserKeyCadsUsage. So, I guess my next step is to see if my MXG level has
this support, or do I need to update (in part, or fully) MXG.
Or, alternatively, is there some ICE tool
nframe Discussion List On
> Behalf Of Allan Staller
> Sent: Monday, September 16, 2019 5:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Considering Bypassing ERROR HOLD for OA58037
>
> I just this the same thing. The DEBCHK lock function is a pe-chain that seems
> it has
I just this the same thing. The DEBCHK lock function is a pe-chain that seems
it has run on for about 18 months.
I ended up bypassing 2 APARs that do not affect my installation.
OA58037 is according to L2 support, a very specific set of conditions.
IMO, it is OK to bypass an error hold, as long
19 matches
Mail list logo
