As you explained it - the following is what is getting us:
> 1 - If the number of drives as determined by the mountlimit is not in use
yet then that second tape can be mounted without having to wait for
a dismount of the first tape.
It is hard to argue with this logic. However, this logic is what is causing
all of our problems -- the drives are in fact not available, even though the
assumption is that they should be (afterall - we told you the limit was 4 and
you're only using 2.....)
> For the request of ADSM putting out a message there should already be a
> message from the operating system indicating ADSM is waiting for a device
> to become available to satisfy a mount request. Let me know if there is
> not. I am under the assumtion that there will already be messages issued
> by the operating system.
The following log example shows exactly what we see. I am sorry for the
truncation - I cut it out of a PMR - If you would like the complete example, I
think I can still get it. Please note that other than the time gaps (shown by
the blank lines), there were no other cuts or snips to make this readable -
all of the messages you see happened in this order with nothing removed for
"clarity".
2109365. ST1 R= ADSM ANR1040I Space reclamation started for volume 8
2109365. ST1 R= ADSM TISDSILO......................................
2109365. ST1 R= ADSM (process number 103)..........................
2109367. ST1 R= ADSM ANR1044I Removable volume 881041 is required f
2109367. ST1 R= ADSM ANR1044I Removable volume 881047 is required f
2109367. ST1 R= ADSM ANR1044I Removable volume 881048 is required f
2109369. ST1 R= ADSM ANR5216I CARTRIDGE 881041 is expected to be mo
2109369. ST1 R= ADSM ANR5216I CARTRIDGE 881047 is expected to be mo
2109369. ST1 R= ADSM ANR5216I CARTRIDGE 881048 is expected to be mo
2109381. IAT5110 JOB ADSM (JOB02223) GET C 876154 ,SL ADSM.BFS
2109383. IAT5110 JOB ADSM (JOB02223) GET C 881041 ,SL ADSM.BFS
2109383.*ST1 R= ADSM IEC501A M 0608,876154,SL,COMP,ADSM,ADSM,ADSM.B
2109383.*ST1 R= ADSM IEC501A M 0609,881041,SL,COMP,ADSM,ADSM,ADSM.B
2112235. ST1 R= ADSM ANR5209I Dismounting volume 881041 (read-only
2112236. IAT5110 JOB ADSM (JOB02223) GET C 881047 ,SL ADSM.BF
0751416.+V (60A,60B),ON,ST1............................................
0751418. IAT5510 60A VARIED ONLINE ON ST1..............................
0751419. IAT5510 60B VARIED ONLINE ON ST1..............................
0751437. ST1 R= S9OCNTT1 CSV002I REQUESTS FOR MODULE KCNDLI EXCEED MA
0751451.*ST1 R= ADSM IEF234E R 0609,881041,PVT,ADSM,ADSM...........
0751451. ST1 R= ADSM ANR0400I Session 776 started for node DMWC (Ne
0751451. ST1 R= ADSM ANR0400I Session 777 started for node SS04468
0751451. IAT5918 ST1 JES3V C 609 ACL UPDATE...............
0751451. ST1 R= ADSM ANR0400I Session 779 started for node APSDED (
0751451.*ST1 R= ADSM IEC501A M 060A,881047,SL,COMP,ADSM,ADSM,ADSM.B
0751452.&IAT5410 KEEP C 881041 ON 609,ST1..........................
0751452. ST1 R= ADSM ANR0400I Session 780 started for node APSD2 (N
0751452. ST1 R= ADSM ANR0400I Session 778 started for node IESD1 (S
0751453. IAT5918 ST1 JES3V1R 60A, , , , ,881047...................
0751455. ST1 R= ADSM ANR2102I Activity log pruning started removin
0751455. ST1 R= ADSM 06/27/1996....................................
0751455. ST1 R= ADSM 00 00 00......................................
0751457. ST1 R= ADSM ANR0400I Session 775 started for node CORP_REL
The first set of messages is pretty clear - just the normal messages
surrounding the reclaim processing, including the Mount messages from MVS.
The second set of messages (only 2 messages) that occur 2 minutes later
indicates the problem - one message from ADSM indicating that it is done with
the first tape, and a JES3 message to the operator indicating that a new tape
is needed (the IAT5110 GET message). That was the last time we saw any
indication that the tape in question (881047) was needed until 7:51 the next
morning. The only other messages that pertain to ADSM were the normal log mes
sages of other activity, until they got caught in the SYSZTIOT wait. The only
indication that ADSM was waiting was when the operator issued the JES3 I S A
command, and ADSM was reported to be waiting in DYN (surprise!) - but with no
indication of for what or why.
I have a PMR open on this (5433E), and I added myself to the PN84364 IP list,
but the way this APAR is written, it sounds more like Pub Change than anything
else.
Jerry Lawson
jlawson AT itthartford DOT com
________________________Forward Header________________________
Author: INTERNET.OWNERAD
Subject: MVS SERVER goes to sleep.....
07-12-96 03:38 PM
Hello Jerry:
OK, I probably was not precise enough in some of my wording. Of course
we would not ask for 3 tape drives up front because that would be a
waste of your resources. These other drives could be used by other
ADSM processes so we can't just grab them.
What I really meant to say is when we are done with the first tape
and need a second tape there is one of two actions that can be performed
1 - If the number of drives as determined by the mountlimit is not in use
yet then that second tape can be mounted without having to wait for
a dismount of the first tape.
2 - If the number of drives as determined by the mountlimit are in use then
we must wait for a dismount of a tape before we can ask for a mount
of a new tape.
In the situation you have where 4 tape drives are in use ADSM will wait
for an unmount of one of the tapes before mounting a new tape.
For the request of ADSM putting out a message there should already be a
message from the operating system indicating ADSM is waiting for a device
to become available to satisfy a mount request. Let me know if there is
not. I am under the assumtion that there will already be messages issued
by the operating system.
I agree that there are some changes that could probably be made to ADSM
to change how this works. My recommendation is to see if there will be
a code change made with APAR PN84364. If not we will at least have the
input from the devlopers that worked on the APAR to understand if there
are some technical issues we are not aware of with being able to make
some changes.
I hope this helps to clear things up.
David Bohm, ADSM technical support.
|
