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 issue d 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 i s 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 using 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 u p >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 order >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 believ e >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 coup le >>of >>>years ago. >>>The old brain cells fail me but I do remember it worked and I had to u se >>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, an d >>ATTACH it to a different user. However, when I ATTACH it back to the D DR >>user DDR gets an operation exception. Did you encounter that? >> >>Brian Nielsen >> >> >>__________________________________________________________________ >><< 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 >> >======================== ========================= =======================
