On 11-Sep-2015 14:34 -0600, John McKee wrote:
I think I have what you requested. <<SNIP>>
<<snip links to VLog data>>


If I understand correctly, the failure origin is a seize conflict that is being detected during the Tape Exit (QTATAPEX) processing that gets invoked during Tape End Of Volume (QTAEOV) processing that gets invoked during the save processing [for the SAV request]. That there is a seize conflict, is inferred from the following Vlog recording at the top of the stack showing the LIC module RMSLSEIZECONFLICT invoked by the RMSLSEIZEADDR LIC module:

VL07000120, TYPE 0700 (SOURCE/SINK) 0120 at 09/09/15 09:40:10
LOAD/DUMP, #LDMODE, CONFLICT OBJECT
... CONFLICT TASK
CFTBLOCKER 0AE6F6729C
stack paraphrased\compressed:
• RMSLSEIZECONFLICT
• RMSLSEIZEADDR
• QP0LLIB1\QP0LASTAT - STAT64
• Q1AQS - FLIGHT...
• Q1AMS - CHECKKEXIST...
• Q1ARTMS [QBRM]
• QTATAPEX [QSYS; as are the rest:]
• QTAEOV
• QTAFEOV
• QSRSAV
• QCMDEXC
• QMNSAVE
• QMNSRBND

The apparent conflict is on an x/1E01 (*STMF) object with the name [appearing in Unicode, so not so conspicuous in EBCDIC dump]: flightrec

As such I believe the origin for the issue is related to either the BRMS or Tape flight recorders. The symptoms match closely with an APAR dealing with restore from parallel saves with fewer drives, and that had similar origins as a seize conflict.

That same file is the origin each time, and the file is at address 0AE6F6729C, so the object is permanent; not sure where that file is [in what directory], but deleting the file is unlikely [albeit possibly] able to change the effect. Also unsure if omitting the file [with the *OMIT feature of SAV, or perhaps the Change Attribute (CHGATR) command to modify the Allow Save (*ALWSAV) attribute to *NO] or the directory would resolve; i.e. I am unsure if the concurrent access is a conflict between the save and the flight-recording or something else.

I presume turning off the flight recorder(s) and\or deactivating the Media Storage Extensions (MSE) [library QMSE] for which the BRMS product-exit-program [as I recall] would be activated by the Tape Exit feature. The later can be deactivated by first Save Licensed Program (SAVLICPGM) and second Delete Licensed Program (DLTLICPGM) of the option that provides library QMSE [OPTION(18) of the OS]; recovery [e.g. after testing the GO SAVE Opt-21 after the deletion] is to Restore Licensed Program (RSTLICPGM), after which no maintenance application is required like is typical after restoring code, because that restore would be made from the /current/ save taken earlier.

Hmm. Further research suggests the capability for the Tape Exit was moved into the Work With Registration Information (WRKREGINF); in v5r4 [and since v5r3 for sure] the feature was integrated as the Exit Point named QIBM_QTA_TAPE_TMS [format TMS00200] for which the program named Q1ARTMS in QBRM is the registered Exit Program. I suppose therefore, that disabling the feature via that interface could be easier than the saving\deletion of the OS Option(18). I am too long-removed to recall the ease outside of the registration APIs, and I have not used those APIs.

FWiW:

The stack logged during the processing in the above\first Vlog does *not* include the inquiry messaging for the End Of Volume (EOV) condition [i.e. the stack expected for the inquiry, QTAFEOV->QTAEOV->QTAERR, does not appear], instead showing only the /flight recording/ of the work. The conspicuous inference\presumption then, is that the inquiry messaging _follows_ the above VLog. That also is consistent with the timing of the inquiry; i.e. the above VLog appears up to four seconds prior to the inquiry.

msg CPA4088 at 09/09/15 09:40:14.278424 F/QTAERR T/QTAERR "Load next tape volume on device TAP35. (C G)"

Very soon after the above vlog are the following vlogs; because the Load\Dump tasks run parallel and asynchronous to the SAV processing, whether the following occurred before, after, or concurrent to the aforementioned Inquiry, I am unsure:

VL07000101, TYPE 0700 (SOURCE/SINK) 0101 at 09/09/15 09:40:14
• ¿apparently recording an ABnormal EXIT; presumably as side effect of the aforementioned /conflict/ condition?
0700(0101), #LDMAIN ABEXIT, SESSION STATUS
... BEGIN EX DATA
... LDSCB
... OIMCB

Immediately followed by each of:

VL07000108 TYPE 0700 (SOURCE/SINK) 0108 at 09/09/15 09:40:14
0700(0108), BUFFERED BLOCK QUEUE
LDBBQSID

VL2E000803 TYPE 2E00 (TAPE SUPPORT) 0803 at 09/09/15 09:40:14
IOD - SET DAMAGE
IoDriverTape Object
WEEKLY
IOFLIGHTREC OBJ TAIOD 4510 TAP35
63A0 TAPE HARDWARE DRIVER OBJECTTAP01
IOFLIGHTREC OBJ TAHWD 451. TAP01

VL03000210 TYPE 0300 (DAMAGE SET) 0210 at 09/09/15 09:40:14
IODRIVERTAPE TAP35
x/1001 TAP35

VL07000195 TYPE 0700 (SOURCE/SINK) 0195 at 09/09/15 09:40:14
0700(0195), DUMP LDSCB FLIGHT

After the message Reply G=Go is received;
msg *NONE 09/09/15 09:42:38.280704 T/QMHDSMSS T/QTAERR "G":

VL2E000804 TYPE 2E00 (TAPE SUPPORT) 0804 09/09/15 09:42:38
IOD - THROW EXCEPTION
IoDriverTape Object
WEEKLY
IOFLIGHTREC OBJ TAIOD 4510 TAP35


That sequence shows why only the _open_ *after* the volume change exhibits the damaged device; the damage occurred, effectively, after the last volume completed and prior to starting the next. Thus after the G=Go, the program QTAVOPEN fails upon encountering the damaged device.


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