>> I'm looking at a situation where RMSMASTR is reporting errors at >> initialization time: >> >> --- tear here --- >> ... >> 11:03:57 TAPE 0580 ATTACHED TO RMSMASTR 0580 >> 11:03:57 FSMBAC2018E Request cancelled because of a library >> sequence-check, request identifier = 0, reason code = 3372 >> 11:03:57 TAPE 0580 DETACHED BY RMSMASTR >> 11:03:57 TAPE 0581 ATTACHED TO RMSMASTR 0581 >> 11:03:57 FSMBAC2018E Request cancelled because of a library >> sequence-check, request identifier = 0, reason code = 3372 >> 11:03:57 TAPE 0581 DETACHED BY RMSMASTR >> 11:03:57 FSMSMS3203I RMSMASTR is running >> --- tear here --- >> >> Subsequent mount requests are also failing with reason code 3372. >> >> From here, things get murky: >> >> Documentation tells me that reason code 3372 signifies "Demount was >> already pending". >> >> My in-house (z/OS-centric) hardware support folks tell me they had a >> lovely field trip to the CoLo facility where this ATL lives. They >> performed a laying-on of hands, and determined the hardware appears to >> be functioning properly. Because I have a vested interest in their >> long-term happiness, I stifled the impulse to give an "I beg to >> differ..." reply until I have a better understanding of what these >> messages really mean. Docs in Knowledge Center don't shed any >> additional useful light on these messages, and I've never before had the >> privilege of fighting this particular battle. >> >> For the experts in the community, I ask that you "Explain it Like I'm >Five:" >> >> - What is a "library sequence-check", really? > >It's a hardware-generated error that centers around mount, unmount, >import, and export, all things that must complete before another request >of the same type can occur. > >> - "Demount was already pending" seems obvious, but I've been assured >> there are no signs that a cartridge is wedged halfway in/out of a >> drive. Any better insights to this condition? > >That information comes from the library (via the drive). When RMS >initializes, it cancels any pending mount requests on its drives and >requests that anything already mounted be unmounted. > >> No changes to my RMS configuration since early January. UM35228 (RMS >> support for use of CP GIVE) was installed more recently, but things >> worked fine for weeks before this issue developed. No I/O errors have >> been logged to the system OPERATOR console. I'm not aware of any recent >> IODF changes or modifications to the physical CEC-to-device cabling >> infrastructure. >> >> Something does seem a bit off in the I/O subsystem: When I VARY OFF the >> devices (580-583) associated with the ATL, the response is immediate. >> When I VARY ON 580-583, the first two drives come online immediately. >> The "<rdev> varied online" messages for 582 and 583 lag by 50 seconds >> each. No MIH events or other messages reported on the system operator >> console in conjunction with these delays. >> >> Does this look familiar to any of you? I'd rather not reboot the LPAR >> mid-week, but that's looking like the next level of intervention. > >What kind of ATL is this? (3494, 3594, VTS, TS7700, 3x94 attached to a >VTS or TS7700, equivalent?, other?) A TRSOURCE I/O trace (IODATA 128) >will verify if the hardware is generating the data, versus CP caching and >not clearing the UNIT CHECK. The results of that will tell you whether >you have a CP or ATL problem. I would VARY all address offline, activate >the trace, VARY all addresses online, initialize RMS, turn off the traces. > >MIH on tapes is a very long time. Like, 10 minutes. >
I seriously doubt CP is generating this error. A 3372 means: Demount was already pending In other words, RMS issued a DEMOUNT, either upon request, as part of mount processing, or during initialization to all free devices, and the hardware responded with a failure RMS translated into the 3372. In olden days, I would suggest a tape was stuck in the drive (could not be ejected). The trace Alan recommends should simply show the demount failure with appropriate sense data which maps to the 3372 I recommend opening a hardware problem to IBM and have a CE take a look at the ATL, and pull hardware logs or get someone from hardware support to dial in and have a look at the logs. Best Regards, Les Geer IBM z/VM and Linux Development ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
