Thanks for the idea. I could try testing with an older DDR, but even if it does work it's not sustainable over the long term when DDR gets update d to handle new tape/DASD hardware.
I suspect z/VM 5.1 let you do the DETACH without the HALT, which z/VM 5.2 won't do. Without the HALT, any version of DDR would probably work. Anybody on a 5.1 system who can test if a DETACH can be done on a tape drive that is in intervention required? (Just attach a drive, don't moun t a tape, start a DDR DUMP, then after the HCPERP2233I message DETACH the drive. If the DETACH works, mount a tape and re-attach the drive to see if DDR abends or processes.) Brian Nielsen On Wed, 24 May 2006 13:53:17 -0500, Huegel, Thomas <[EMAIL PROTECTED]> wrote: >Brian, >Here is an idea just for kicks, see if you can find an older release of DDR >and try it. >I just got an email from someone at my old place and he says my stuff is >still running there once a week every week z/VM 5.1. .. although I was a >little off with what I said before, I didn't do a DET rdev (LEAVE, it wa s >just a DET rdev. Then I wait for the robot message that a new tape was >loaded before I attach it to DDR again. > >-----Original Message----- >From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] >Behalf Of Brian Nielsen >Sent: Wednesday, May 24, 2006 1:37 PM >To: IBMVM@LISTSERV.UARK.EDU >Subject: Re: GIVE command on a tape drive with intervention required > > >I've run some traces and know why DDR is abending. If you don't want to >read the technical details below, the question is: Is this an APAR'able >DDR problem or "user error caused by the HALT - don't do that"? > >---- > >The sequence is as follows: > >1) DDR is running and the tape drive is attached but not ready (for ease >of debug I'm doing this at DDR startup, rather than at EOV). > >2) DDR issues a DIAG A8 (Synchronous I/O) for the tape drive. > >3) Message HCPERP2233I TAPE xxxx NOT READY, CP-OPERATOR NOTIFIED is issu ed > >4) I do a HALT to the rdev > >5) The DIAG A8 gets a rc=13 (Permanent I/O error) > >6) DDR drives it's error recovery routine CKDIAGER, then returns control >to the return address stored in IOBERROR - which sends it to INOUTER. > >7) The INOUTER routine determines it's a unit check and goes to UNITCHKE , >which tests the sense information and thinks it's a deferred reissue. > >8) So it does a BRANCH IOWAIT, which causes R12 to be loaded with the >address of IOWAIT. IOWAIT loads a wait state PSW. The problem is that >the code around IOWAIT uses R12 as a base register whose expected value is >STARTIO. > >9) I detach the tape drive. > >10) I re-attach the tape drive. This causes an I/O interrupt that >satisfies the wait state PSW loaded by IOWAIT. > >11) A dozen instructions later the code does a BNH to label TRCTSCH usin g >R12 as it's base register. Because R12 has the wrong value, this is a >wild branch. It deteriorates immediately with another wild branch, and >executes a handful of instructions before wild branching again to an >address which results in the operation exception. > > >Brian Nielsen > > >On Tue, 23 May 2006 12:16:03 -0500, Brian Nielsen ><[EMAIL PROTECTED]> wrote: > >>I'm running z/VM 5.2. I think it's the HALT that is ultimatly messing up >>DDR. DDR abends as soon as the button on 3590 tape drive is pushed to >>start the tape loading, so it's probably related to I/O interrupt >>particulars different from what DDR is expecting. >> >>I'll be interested in seeing what you did differently or if this is the >>result of "improved" error recovery in DDR. >> >>I've even experimented with using the tape drive attached in multiuser >>mode, but a HALT (and more) is still required to the tape drive in orde r >>to update the operator display. End result is the same - DDR abends. >> >>Brian Nielsen >> >> >>On Tue, 23 May 2006 11:14:36 -0500, Huegel, Thomas <[EMAIL PROTECTED]> >>wrote: >> >>>Brian, >>> >>>I don't remember having any problem with DDR abending, I ran this on z/VM >>>4.3 and z/VM 5.1. >>>In my case after I (prop) detached the tape I (prop) attached it to an >>>'automated tape manager' that recorded the tape then unloaded it and >>mounted >>>a new tape and then I (prop) attached the drive back to 'DDR'. I belie ve >>DDR >>>saw the new tape and continued the dump without any problem. >>>I am still looking for the exec but I was at a different company when I >>>wrote it, I think they still use it, I just need to find someone there >>that >>>will re-share it with me. >>> >>>Tom >>> >>> >>> >>>-----Original Message----- >>>From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] >>>Behalf Of Brian Nielsen >>>Sent: Tuesday, May 23, 2006 9:50 AM >>>To: IBMVM@LISTSERV.UARK.EDU >>>Subject: Re: GIVE command on a tape drive with intervention required >>> >>> >>>On Mon, 22 May 2006 17:00:05 -0500, Huegel, Thomas <[EMAIL PROTECTED]> >>>wrote: >>> >>>>I remember doing pretty much what you are attempting to do just a couple >>>of >>>>years ago. >>>>The old brain cells fail me but I do remember it worked and I had to use >>>the >>>>'HALT' command. I think I did a DETACH rdev (LEAVE and an ATTACHn not >>>GIVE, >>>>but I don't know why. It may have been something with the sequence.. . >>>> >>>>I'll look for the code, but to be honest, I don't think I have it >>anymore. >>> >>>I was able to do a HALT, DETACH the drive from the user running DDR, a nd >>>ATTACH it to a different user. However, when I ATTACH it back to the DDR >>>user DDR gets an operation exception. Did you encounter that? >>> >>>Brian Nielsen >>> >>> >>>__________________________________________________________________ >>><< ella for Spam Control >> has removed VSE-List messages and set asid e >>>VM-List for me >>>You can use it too - and it's FREE! http://www.ellaforspam.com >>> >>======================== ========================= ======================= > > >__________________________________________________________________ ><< ella for Spam Control >> has removed VSE-List messages and set aside >VM-List for me >You can use it too - and it's FREE! http://www.ellaforspam.com >
