Hi JR, Yes, I have tried a native mount with DFSMSRM and got the same problem. It gives me a RC=8(3140) which suggests a drive problem but I also get a message saying NO SCRATCH80 - although, now I think about it, this was in the VMTAPE console.
If I do a DRSMSRM Q LIB DEV EE6 (LIBNAM VTSTPFC2 then I get a message back saying drive not available. While VMTAPE may be misunderstanding the reason for the problem - it is clear that the problem lies in DFSMSRM and not VMTAPE. Incidentally, I can successfully query that drive from another system - giving further credence to my idea that this is caused by this drive being in use when RMSMASTR was initialised on the system where I am see the problem (I think we had a problem with RACF the weekend before last where some service machines needed to be restarted). With best regards / mit den besten Grüßen, Colin Allinson Technical Manager - VM Systems Support Operating Systems Services Amadeus Data Processing GmbH T: +49 (0)8122 43 4975 F: +49 (0)8122 43 3260 [EMAIL PROTECTED] www.amadeus.com "Imler, Steven J" <[EMAIL PROTECTED]> To IBMVM@LISTSERV.UARK.EDU cc bcc Subject Re: DFSMS/RMS question "Imler, Steven J" <[EMAIL PROTECTED]> Please respond to : The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 25/02/2008 12:55 Colin, What is the RC and REASON returned by RMS when the mount request is issued to the "bad" drive? I assume you've tried the mount outside of VM:Tape using the native DFSMSRM command and that's why you are suspicious of DFSMS in this case? JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson Sent: Monday, February 25, 2008 04:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DFSMS/RMS question We have been using DFSMS/RMS on VM for a long time. At the weekend we had an issue which, I suspect, has happened before but not been identified. We have 16 drives per VTS shared between 6 VM systems (VMTAPE STAM) handles the sharing of the drives. Yesterday, on only one of these drives, I was getting a message that there were no scratch volumes available. An identical mount request (for the same scratch pool) in an adjacent drive in the same VTS was satisfied without problems. I think I know what happened - but I am not sure if this is a bug (or how to handle it). What I think happened is this:- When RMSMASTR was started on this system, it went through it's initialisation process but this particular drive was in use at the time. As a result, RMS is confused. If I am right then a restart of RMSMASTR would solve the problem for this drive but create other potential problems with the other drives in use. Because we have drives in use for long periods of time (by TPF test guest systems) it would almost take a system outage to have no VTS drives in use. Does anyone have any experience or knowledge of this situation? If so then :- a) Does my theory sound correct? b) Is this a reportable bug (should I open a PMR)? c) Is there a way to get round this problem (for example: can I get RMSMASTR to reinitialise a specific drive)? Thanks in advance Colin Allinson Technical Manager - VM Systems Support Operating Systems Services Amadeus Data Processing GmbH www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
