Re: Failed GO SAVE 21

Chuck, and anybody else interested,

Changing the flight recorder attribute to not allow save WORKED!


I sat and watched as the SAV plodded along. It looked like it was about to
fail, since the status was not changing for over ten minutes. But, a check
on the drive itself showed alternating between ready and writing. More
waiting. Maybe twenty minutes, and finally saw a message to change the
tape. After waiting for tape to stabilize at load point, I gave the G
response. Maybe ten more minutes, and backup completed.

A really nice feeling, almost giddy.

Thank you for your efforts!

John McKee

On Tue, Sep 29, 2015 at 8:22 AM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 29-Sep-2015 02:51 -0600, W3 wrote:

On Aug 26, 2015 10:34 PM, "John McKee" wrote:

It happened again. Runs along fine, then aborts.

I did get a job log.

System also created QPSRVDMP.

The 3590 device is in FAILED state.

From looking at QEZDEBUG, I see from the call stack, the last
three entries are:

qsrProcessIoReqForGroup_FP7qsrList
qsrSwitchMediaVolume_FP15qsrIO_Request_T13qsrTypeOfFEOV
qsrFeovDevUfcb_FP9qsrFileCb

From looking at QSYSOPR, there is CPI5922 Device description TAP35
is not usable at this time. No other error message related to the
drive before or after that message.

From QPSRVDMP

DUMP TAKEN FOR UNMONITORED ESCAPE MESSAGE

MCH5203 Condition of source/sink object TAP35 not valid.

System (v5r4) has 246.1G and %system ASP used is 67.4779

My WAG is that the tape got full. But, unlike last week, I never
saw a message requesting a tape change. Last week, I did see that
message along with a message that tape drive needed to be cleaned -
which I did last week.

So, any idea as to why there was no tape change message?

Hi John,

Looking @ the message it is said that the tap35 not valid... What I
usually do is when this thing happen is I call IBM to replace the
drive.. The drive could be at the end of their time :-D

The issue had already been identified, back in August, as software by
the CE:
[http://archive.midrange.com/midrange-l/201508/msg00890.html]
"...
I called IBM. I was sent to a hardware tech. He said the LIC log in SST
was software, not hardware. The two options he worked with as far as
hardware logs showed no entries.
..."

And my replies since alluded the same; in which I also recommended some
probable means of circumventing that software problem, as well as
suggesting that the effective timing for the failure was the reason no
tape-change message was seen.

Hopefully we will hear back, that the most straightforward of those
circumventions [i.e. to mark the AlwSav attribute of the BRMS flight
recorder files prior to the GO SAVE Opt21], will have successfully
prevented the issue on the upcoming Wednesday save.

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