× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I looked at the flight recorder after the backup completed. There are
indeed records written to it.

Seems odd to me as well. Chuck had an initial suggestion to remove BRMS
and then reinstall. Likely would have worked. Changing the attribute on
the flight recorder files to not save is simpler and maybe safer.

Begs the question if allow save is default on 5.4 or newer and was changed,
or if default was later changed. Or, if some PTF at any level changed some
behavior to prevent the lock condition from causing the backup to fail.

Bad thing about this fix is that, if needed, flight recorder just isn't
going to be available to restore.

John McKee

On Wed, Sep 30, 2015 at 10:51 AM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>
wrote:

So are we stating that a non BRMS save still writes to the BRMS flight
recorders?
This doesn't appear correct.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
John McKee
Sent: Wednesday, September 30, 2015 11:43 AM
To: Midrange Systems Technical Discussion
Subject: 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.


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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.