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



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.


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.