Re: Failed GO SAVE 21

I >think< I accomplished the IOP reset when I responded to Chuck's email.
However, started reading your email after that and, of course, got
curious. I am on the screen Hardware Resource Concurrent Maintenance.
Only entry is Tape Library. Model 3590-E11. Power status - Unknown.
Device and MLB are both currently varied off. Pressing F9 power off domain,
displays "The selected power domain cannot be powered off". Maybe because
this is just old, old, old?

I am also wondering if the message requesting the drive be cleaned, is the
only >real< issue, and merely vary off/on, while appearing ro correct the
problem, as evidenced by status changed from FAILED to ON did not actually
correis.ct the underlying issue that the reset(*YES) may have. I am not
wanting to run from applying PTFs, but wonder if all that was wrong was
underlying condition was not fully corrected and now is,

John McKee

On Wed, Sep 2, 2015 at 12:54 PM, <rob@xxxxxxxxx> wrote:

Let me repeat what Chuck said:
Be sure to /IPL/ the device by using: VRYCFG RESET(*YES)

If your tape IOP (since you're running V5R4 I assume you're still using
IOPs) is not on any disk IOP then you can also try:
WRKHDWRSC *STG
You should see
IOP
IOA
Tape device
Record the IOP. Make sure it only has tape.
STRSST
1. Start a service tool
7. Hardware service manager
Find it by drilling down into packaging resources. Use option 3 to
perform concurrent maintenance. Power off the domain. Power it back on.
Basically does everything that a physical IPL does to the card, except
maybe apply PTF's. Non disruptive to other users. I used to have to do
this quite often on troublesome tape drives. Of course, you have to vary
it off first.

I can't remember if V5R4 supported WRKPTFGRP. If so, you may want to
compare it with

http://www-912.ibm.com/s_dir/sline003.NSF/GroupPTFs?OpenView&Start=1&Count=30&Expand=4#4

You should have the current:
hiper
security
db2
tcp
java
backup
So order those. And also order the cume, SF99540. You can see if you're
current by seeing if '2094' is listed in DSPPTF for 57##999 or 57##SS1.
See also:

http://www-912.ibm.com/s_dir/sline003.nsf/2d3aff1c6b4d6ce086256453000d971e/9d2cbc7b715949d48625741f006f2b3a?OpenDocument
Well, you may not need java and what not, but I'd definitely get the hiper
and backup. If you order a cume you'll also get a copy of hiper and DB2.
See SNDPTFORD. If you're really behind expect this to take a LONG time.
Like, maybe fire it up before going home, (providing no nightly process
will kill that).






Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: CRPence <crpbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 09/02/2015 01:37 PM
Subject: Re: Failed GO SAVE 21
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



On 02-Sep-2015 10:13 -0600, John McKee wrote:

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

From DSPPTF

First panel
5722999
TL10292

Second panel
5722SS1
TC10292

That information seems a contradiction with my statement that the
"C0292540 has a preventive PTF MF53911 [for HIPer APAR MA39266]" given
an earlier followup that stated the "PTF MF53911 is NOT installed." My
error:

An APAR reveals the /latest superseding PTF available/ at the time
the APAR was finalized with the updates to the cumulative levels for the
associated PTFs. And at that time, the *latest supersede* was the PTF
MF53911 for v5r4; the original PTF for the APAR MA39266 however, was the
PTF MF50268.

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 expect the hardware guy was correct, and that the issue is
something with the software.

I varied it OFF and back ON.

Be sure to /IPL/ the device by using: VRYCFG RESET(*YES)

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.

I tried to explain that software can indeed seem /nutty/, and that
failures are easily influenced by the specific environment. Notably,
multiple SAV is decidedly not the same environment, quite different in
fact, than in what the GO SAVE Option-21 due to what each effects.

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.

Perhaps that was an oversight in the past. If so, then the same LIC
Logs [pattern of Source/Sink et al] would be seen in that\those past
failing save(s) that also took two tapes [assuming the log settings did
not effect a wrap of the summary entries, though they often may cover
several years].

I did SNDPTFORD for the PTF you suggested. I remember others were
downloaded as well. There is, of course, junk in QGPL.

Given the revelation [though yet to be confirmed] that the PTF for
the HIPer APAR is part of the already-applied cumulative PTF package, I
am less inclined to believe that latest PTF in the PTF chain of that LIC
code includes a preventive. I would suggest instead to apply the latest
cumulative, or at least the C2094540 on which that PTF MF53911 is
included.

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.

The superseded PTF MF50268 [to which I should have originally
pointed, and which is *probably* applied per C0292540 having been noted
as being installed\applied] has the primary\title symptom string of
"LIC-MSGMCH5204 Save operation ends abnormally" and notes additionally
in the text for the APAR MA39266 that alternate symptoms "may include
MSGMCH5203 and MSGMCH1668" for which the OP states the former and
alludes to the latter.

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?

Either\both of an IPL of the system and the temp storage are very
unlikely to be of any assist for a resolution.

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.

The DSPPTF SELECT(MF50268) is likely to show the PTF is installed.
Again, the newer PTF MF53911 comes with C2094540. I do not know if that
was the final cumulative, but that would seem a good minimum level to
attain; a full 530 days more recent maintenance.

But also there are a number of HIPer APARs for which PTFs were made
available since, both for TAPE and for SAVE; ordering/applying the HIPer
PSP along with that cumulative would be the most helpful [way more than
solely an IPL without maintenance, which is unlikely to accomplish
anything worthwhile].
[

http://www-912.ibm.com/systems/electronic/support/s_dir/sline003.nsf/PSP%20Number%20View/SF98014
]

I used STRSST. Only saw statistic messages.

Not sure what that means, as we do not know what was viewed. A
followup to the OP suggested there was a set of 13 VLogs issued for the
prior [two] failures,? Are we to infer this time there were none?

As I had noted, the LIC Log, the PALs, the history logs, and the
joblogs for the time spanning each of the failing saves would be
worthwhile to post [somewhere publicly available] for review, because
without those, any reviewer is dependent upon what _you_ think is worth
sharing rather than what they expect or know could help in their own
review of the failure. Certainly is acceptable to keep whatever secret,
but know that help is unlikely to be forthcoming, merely [more] guesses
and unsubstantiated recommendations; kinda begs the question, "Why ask
for help [in a public forum], if you don't want [to allow] any[one to]
help?"

--
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.



--
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.