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?"
midrange.com
