Re: Failed GO SAVE 21

I apologize. Thought I had looked properly and informed. Obvious to me
that I failed. What I had looked at earlier was Product Activity Log.
Specifically, Analyze log.

I now have a 4 page Product Activity Log that starts before the GO SAVE and
extends somewhat after that period. I have joblog for this morning and I
think I have the joblog from last week. Not sure about that. This
morning, I did see a message about previous damage. Which might be
explainable as I had not performed a reset. I also have a 611 spool file
of LIC messages (wrong terminology probably). Also a 19 page report from
DSPLOG.

I did perform a rest on the IOP a few minutes ago. There were two other
lines that had to be varied off first. As far as I know, those lines serve
no useful purpose anymore as the systems that were supplying data are
gone. Anyway, varied them OFF and then back on again after reset so
something else didn't get "unhappy" at an inopportune time.

I can easily convert the spool files to something in the IFS. Two
questions:

1) The LIC log, at 611 pages, seems a tad large. Maybe I used an incorrect
parameter or included too much by use of wrong paramter value. Does this
need to be corrected?

2) Where can I send the files to allow others to see them?

I appreciate your time, as well as explaining >why< multiple SAVs don't
trigger the same condition as GO SAVE >can<.

If I recall corectly (been well over ten years) applying cum will almost
certainly require an IPL to complete. So, no need to IPL now >just< to
clean up max unprotected.

The job log from this morning indicated a previous damaged condition.
Repairable via IOP reset. Wish I had thought that through and performed OP
reset last week when it happened. The commands are obviously doing a lot
more than is obvious, otherwise, it would seem like a nice feature to fail
at the start rather than after an hour. Some functions just don't work
that way.


So, just need a destination for these files. Maybe problem is now "fixed"
merely by me performig a proper rset.

John McKee

On Wed, Sep 2, 2015 at 12:37 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

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.