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