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 was 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:IBMVM@LISTSERV.UARK.EDU]On
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 issued
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 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 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 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 believe
>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:IBMVM@LISTSERV.UARK.EDU]On
>>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, and
>>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 aside
>>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
