Les, As soon as the 3494 HW folks (once again) permitted the specification of TARGETCAT VOLSPECIFIC on a p2p MOUNT command, I had to revoke/reverse the fix that separated the single MOUNT request into a SET VOLCAT VOLSPECIFIC followed by a MOUNT for the volser.
The SET VOLCAT VOLSPECIFIC had to be done first to ensure no one else could select the tape before the MOUNT completed ... to prevent "tape stealing". That ended up completely defeating "fast scratch" ... so VTS mounts were taking 3 to 5 minutes due to the back-end data being recalled because the tape was not in a Scratch Category when the MOUNT request was issued. That PTF was reversed in September 2003 ... JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) > Sent: Friday, April 04, 2008 01:55 PM > To: [email protected] > Subject: Re: Question about virtual tape in a zVM environment > > A word of caution here, I realize it appears the problem is resolved > going from z/VM 4.4 and 5.3. However, I can not tell you any change > that has been made to Diag X'254' nor RMS that would have magically > allowed a target category of VOLSPECIFIC to be honored by the ATL on a > mount command. > I can tell you, hardware has identified situations where > VOLSPECIFIC is > not honored as a target category on a mount command. And I > am not aware > the fix has been released. > Make sure you consider this carefully before going into production. > > JR, didn't you make a change at one time where the set > category was done > separate from the mount? Could it be in one of the environments this > code was being executed? > > > Best Regards, > Les Geer > IBM z/VM and Linux Development > > >Hi Alain, > > > >Actually, in this case, I really don't really feel like going back in > >time :-) > > > >In reality, it would need to be a real crisis for me to get > >authorization to use a LPAR to IPL z/VM 4.4.0. > > > >I'm just happy for you that you should finally have this problem > >resolved when you are up and running z/VM 5.3 in production! > > > >JR > > > >JR (Steven) Imler > >CA > >Senior Software Engineer > >Tel: +1 703 708 3479 > >Fax: +1 703 708 3267 > >[EMAIL PROTECTED] > > > > > > > >> -----Original Message----- > >> From: The IBM z/VM Operating System > >> [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste > >> Sent: Friday, April 04, 2008 12:12 PM > >> To: [email protected] > >> Subject: Re: Question about virtual tape in a zVM environment > >> > >> Jr, > >> > >> If you are interested in, I can send you a copy of our z/VM440. > >> > >> Regards > >> Alain > >> > >> > >> Le 4/04/08 3:26, =AB=A0Imler, Steven J=A0=BB > <[EMAIL PROTECTED]> a > >=E9crit=A0: > >> > >> > Hmmm ... Les, Alain did say z/VM FOUR.FOUR ... it's for > >> sure there are > >> > likely CP changes (DIAG 254 "things" come to mind) that > might effect > >> > this behavior in some way ... again keeping in mind his > >> HOST is running > >> > z/VM 4.4.0 (except for the test when everything WORKED! > [when he had > >> > z/VM 5.3 running 1st level in addition to his test guest > system]). > >> > > >> > In any case, I have no way to go back to prove this ... all > >> our hosts > >> > are z/VM 5.3 and we generally are running the GA release of > >> z/VM at GA > >> > for all our hosts. So it's been a LONG time since we've had z/VM > >> > 4.anything as "top dog". > >> > > >> > JR > >> > > >> > JR (Steven) Imler > >> > CA > >> > Senior Software Engineer > >> > Tel: +1 703 708 3479 > >> > Fax: +1 703 708 3267 > >> > [EMAIL PROTECTED] > >> > > >> > > >> >> -----Original Message----- > >> >> From: The IBM z/VM Operating System > >> >> [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer > >> (607-429-3580) > >> >> Sent: Thursday, April 03, 2008 08:42 PM > >> >> To: [email protected] > >> >> Subject: Re: Question about virtual tape in a zVM environment > >> >> > >> >>> Les and JR, > >> >>> > >> >>> Firstly : > >> >>> Thanks to gave me the info 'PMH 84921,004,000'. I asked our > >> >> hardware to l > >> >>> > >> >>> ook > >> >>> at this. I don't have a feedback yet. > >> >>> > >> >>> Secondly : > >> >>> I was able to IPL our z/VM530 today and ... > >> >>> - from z/VM440, I ipled z/VM530 2nd lvl and did a test about > >> >> the target : > >> >>> > >> >>> > >> >>> nothing changed. Problem still alive :( > >> >>> > >> >>> - I ipled z/VM530 1st lvl and did a test, then did it again > >> >> and again to > >> >>> > >> >>> be > >> >>> absolutely sure. I washed my glasses and yes our problem > >> >> disappeared. NO > >> >>> MORE PROBLEM !!! > >> >>> > >> >>> So it was not a hardware problem. Glad to see this has been > >> >> corrected in > >> >>> > >> >>> the > >> >>> z/VM version. > >> >>> > >> >> > >> >> There isn't anything in a newer release of z/VM that would > >> change the > >> >> behavior of this problem. It really is a hardware problem. > >> >> This problem only occurs when you use VOLSPECIFIC as a target > >> >> category on a mount request. > >> >> > >> >> > >> >> Best Regards, > >> >> Les Geer > >> >> IBM z/VM and Linux Development > >> >> > >> >> > >> > > >> > >> > >
