We have a problem that is easy to reproduce with the VTAPE product from VSSI.
We do not have the type of access to the hardware that will prove that the same
problem occurs with real 3490 drives, but it appears that it should. Here is
the situation:
This simple EXEC:
/* */
address command
trace i
'CP DEFINE V3490 181'
'CP VTM 181 SCRATCH'
'CP Q V TA'
'FILEDEF IN DISK JUNK DATA A'
'FILEDEF OUT TAP1 SL'
'MOVEFILE IN OUT'
'CP VTRUN 181'
'CP Q V TA'
'FILEDEF * CLEAR'
'CP VTM 181 SCRATCH'
'CP Q V TA'
'FILEDEF IN DISK JUNK DATA A'
'FILEDEF OUT TAP1 SL'
'MOVEFILE IN OUT'
'CP Q V TA'
'CP VTRUN 181'
'FILEDEF * CLEAR'
'CP Q V TA'
'CP VTM 181 SCRATCH'
'FILEDEF IN DISK JUNK DATA A'
'FILEDEF OUT TAP1 SL'
'MOVEFILE IN OUT'
'CP Q V TA'
'CP VTRUN 181'
'FILEDEF * CLEAR'
'CP DET 181'
gives these results:
RSCHUH CMS 22 (CMS22A);
test
4 *-* 'CP DEFINE V3490 181'
>L> "CP DEFINE V3490 181"
TAPE 0181 DEFINED
5 *-* 'CP VTM 181 SCRATCH'
>L> "CP VTM 181 SCRATCH"
A03282 mounted on 0181
6 *-* 'CP Q V TA'
>L> "CP Q V TA"
TAPE 0181 V3490 A03282 3480 R/W S000D AT LOAD POINT
7 *-* 'FILEDEF IN DISK JUNK DATA A'
>L> "FILEDEF IN DISK JUNK DATA A"
8 *-* 'FILEDEF OUT TAP1 SL'
>L> "FILEDEF OUT TAP1 SL"
9 *-* 'MOVEFILE IN OUT'
>L> "MOVEFILE IN OUT"
10 *-* 'CP VTRUN 181'
>L> "CP VTRUN 181"
A03282 unloaded from 0181
11 *-* 'CP Q V TA'
>L> "CP Q V TA"
TAPE 0181 V3490 NOTRDY 3480 R/W S000D DEFLIB A
12 *-* 'FILEDEF * CLEAR'
>L> "FILEDEF * CLEAR"
13 *-* 'CP VTM 181 SCRATCH'
>L> "CP VTM 181 SCRATCH"
A03488 mounted on 0181
14 *-* 'CP Q V TA'
>L> "CP Q V TA"
TAPE 0181 V3490 A03488 3480 R/W S000D AT LOAD POINT
15 *-* 'FILEDEF IN DISK JUNK DATA A'
>L> "FILEDEF IN DISK JUNK DATA A"
16 *-* 'FILEDEF OUT TAP1 SL'
>L> "FILEDEF OUT TAP1 SL"
17 *-* 'MOVEFILE IN OUT'
>L> "MOVEFILE IN OUT"
DMSTVS265I Attempting to change tape volume for DDNAME OUT
DMSTVS266I To cancel the tape volume switch, type CANCEL
DMSTVS268I Message sent to userid OPERATOR:
DMSTVS269I Mount tape volume SCRATCH on virtual 181 with a write ring; request
number 1
I have traced the I/O for device and found that CMS never receives the
interrupt for device 181 that should result from the mount in line 13. I
reported this to VSSI and they traced their code and found that VTAPE is giving
the interrupt to CP via their normal code. The conclusion is that either CP is
not passing the interrupt to CMS. The question is why does the interrupt not
make it to CMS? It could be a CP failing or CMS could have it masked. VSSI
guesses that the same failure would occur if real tapes were used instead of
virtual. The VTRUN command is the equivalent of pushing the Unload button on
the drive.
* Would IBM be inclined to accept a problem report for this failure while
using VSSI's VTAPE or would it need to be reproduced using real tapes?
* If real tapes must be used, is there anyone who has real tapes that are
easily accessed and would be willing to test VSSI's conjecture?
Regards,
Richard Schuh
