Re: Failed GO SAVE 21

Well, backup failed again. Details after PTF data you requested.

From DSPPTF

First panel
5722999
TL10292

Second panel
5722SS1
TC10292
Worked fine over an hour. No message on the drive about
All PTFs are permanently applied. IPL source ##MACH#B ##SERV#T. No action
required.

Backup ran smoothly for a tad over an hour. Then CPA4088 was displayed
requesting the next tape at 09:39:29.

Immediately following my response of G, CPI5922 Device description TAP35 is
not usable at this time was posted, also at 09:39:29.

Device TAP35 was now in FAILED status. Nothing I saw on the drive
indicating cleaning was needed.

I varied it OFF and back ON.

This is nuts. When I did testing Monday, I used multiple SAV commands
(with *LEAVE) to test full condition. That worked perfectly. Why it would
fail is nutty.

More thoughts:

Since I was told that a second tape had been required in the past, the
nagging question is whether the operator noticed the same error sequences,
or just ignored them. That would certainly explain the position that it
"worked" in the past.

I did SNDPTFORD for the PTF you suggested. I remember others were
downloaded as well. There is, of course, junk in QGPL. Looking at the
symptom strings for MF53911, I see most seem to be related to restore.
However, there is OSP-OTHER-SAP400-WAIT SAVING LARGE NUMBER OF IFS
OBJECTS. Not sure if that is relevant. Maybe. That is the area of the
save that failed. Only difference was the addition of 47 (or so) IFS
objects from previous weeks. System ASP is 246.1G and % used is 67.2201.
Current unprotect is 8941 M, maximum is 20261 M.

No IPL in months. Would that be worthwhile? Is the maximum unprotect just
a red herring?

I was told I >could< apply PTFs. Whoopee. Not sure what the concern ever
was. Something that required an IPL right now might raise a few eyebrows,
despite the system is basically running in view only. No new data is being
entered.

I used STRSST. Only saw statistic messages.

John McKee


On Mon, Aug 31, 2015 at 5:14 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 31-Aug-2015 15:29 -0600, John McKee wrote:

I am rusty as an old door hinge. I can't recall how to determine Cum PTF
level. The named PTF MF53911 is NOT installed. Place always ran on the
concept of "if it ain't broke". Potentially, it may be broke. Just my
bad
luck to stumble on to it.

Issuing the Display PTF (DSPPTF) CL command with defaults should present
the LIC PTFs first, then Enter presents the OS PTFs. On the first panel
showing LIC PTFs, there should be some TAxxxxx, TLxxxxx, or TCxxxxx and on
the second panel showing OS PTFs something similar; as I recall those
reveal the PTF Cumulative [and HIPer] levels [and status such as loaded or
applied].

I was just told that we have had two-tape backup in the past. No idea
if those overflowed on SAV or an earlier command.

The origin for the issue may not be directly per the transition to a new
tape, but might be exacerbated. The description for the APAR MA39266, and
that multiple LIC Tape tasks operate concurrently [much like threads] to
process multiple /descriptors/ as well as tape management is in-line with
the idea that the transition might increase the chance, but simply could be
the effective /layout/ of the parallel descriptor processing that has on
two prior occasions resulted in one /stomping/ on the other... and
[perhaps] luckily with a failure vs a hang that might have required more
onerous recovery than just the device reset.

Despite the fact that IBM has long ago sunsetted v5r4, the decision

maker on applying PTFs is reluctant to proceed. Nutty.

Quite. Hard to conceive how "High-Impact and Pervasive" fixes would be
ignored willfully, even if just ignoring the /cumulative/ might be
rationalized.

--
Regards, Chuck

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.