Re: Failed GO SAVE 21

Three weeks in a row. I saw at the LAN console. Waited for the tape
change message. It came. Change the tape. Waited until drive indicated
tape was at load point. Back to LAN console. Entered G. SAVE ended with
FAIL. I did IOP reset last week. Did it again after the FAIL message.

The job log shows my G response to the load next tape message. IMMEDIATELY
after thatis System object TAP35 partially damaged. Further down, it
states VLOG identifier is *NONE. For recovery, it states to delete and
recreate the DEVD.

Text for current TAP35 *DEVD has "CREATED BY AUTO-CONFIGURATION".

DSPOBJD shows creation as 07/13/06. Also shows change date as 08/16/10.
Never saved or restored.

Is there a way to see if it is damaged? Only way I have seen is to do GO
SAVE, wait over an hour and ten get the damaged message.

If I save the configuration source, vary off the device and then delete it,
then recreate from source - will THAT fix what is ailing?

I get to wait until next Wednesday to try a save again.

I don't have a problem with recreating the DEVD, even manually. But, I
sure would like to be able to see if the ruddy thing was damaged before an
hour has passed.

John McKee

On Thu, Sep 3, 2015 at 1:30 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 02-Sep-2015 12:48 -0600, John McKee wrote:

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 parameter
value. Does this need to be corrected?

Seem a reasonable size, but hopefully that size suggests the data from
the selected logs was included, rather than just the summary of all the
entries; i.e. a listing of all LIC Log entries without any data can be
somewhat informative [to see the pattern for each failure and what might
have preceded the first or each occurrence; obviously the timestamps of the
begin\end of each failure would need to be noted additionally], but the
actual list of the thirteen logs [consistent each time?] *with data* across
the time-span of the failure(s) is what is most desirable. Note: Review
the spools for any /sensitive/ data, as some logs could include some actual
data from the save; paging through the /eye-catcher/ data is generally able
to be completed fairly quick.

I can not recall the means to get a summary-with-data over a specific
date\time-range when spooling the LIC log data. I recall mostly, that
there is a 6=print against that can produce a spool-with-data against each
log; of course that is one spooled file per log.

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

Some people use dropbox; there are a variety of such places. Google
docs should be an option as well, but I am unsure if there is a fully
public access, or if authorization is made only to specific accounts [mine
is my email I post with].

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

Allusion as to how possibly, not an explanation of why :-)

If I recall correctly (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.

Applying the cumulative [and HIPers] will indeed require an IPL [perhaps
an additional implicit IPL to which there may be only limited visibility,
most notably, that the system never appears available until completion of
the final IPL].

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.

I would expect that, given the required repair for the partial damage is
vary-off and vary-on, the save would have failed quite nearly immediately
upon start; I do not recall the GO SAVE opt-21 having any Vary
Configuration requests coded. Additionally, a failure for reference to the
/damaged/ device should have been explicitly about the reference to the
previously-damaged object, not a condition diagnosing an issue for which
the effect was damage; perhaps not a conspicuous difference to those less
familiar, but trust that the difference is huge and an important
distinction.

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

Your call on if, where, and to whom the data is made available. I am
offering to look; not sure if anyone else would, and if not, I could look
at them sent as email attachments [preferably named in a way that clarifies
what each is; which incident and what type of data collection]

There is only a small chance I would be able to infer anything from the
set of VLogs [they are atypical of what I have had to review in the past].
The recording in this discussion the list-summary [from each occurrence; or
just one, and indication that they were the logs were the /same/ each time]
would at least be valuable in comparison with any other incidents in which
that minimal amount of information was recorded.

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