Re: GIVE command on a tape drive with intervention required
On Wed, 24 May 2006 18:15:18 -0400, Alan Altmark [EMAIL PROTECTED] wrote: On Wednesday, 05/24/2006 at 01:37 EST, Brian Nielsen [EMAIL PROTECTED] wrote: 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'abl e DDR problem or user error caused by the HALT - don't do that? Please open a PMR, Brian. Because you asked so nicely [he's such a *nice* boy] and you have such helpful problem determination skills, we' re inclined to treat it initially as a bug. (And I'm not 100% certain, but I think it helps that the developer is also named Brian.] Okay, will do. (Honestly, though, my personal opinion is that usage note 1 for HALT probably applies: 1. ATTENTION: Use this command only in extreme cases and after careful consideration. Indiscriminate use of thi s command may cause unwanted results.) HALT causing DDR to abend is obviously an unwanted result. :) Maybe I'm getting a free pass because I'm not using it indiscriminatly. But I ask you, why can't everyone else include a nice detailed analysis of the problem in *their* problem descriptions? I mean, it's not like in some alien language like Java or C++! ;-) [OCO modules excluded, of course] OCO modules never stopped me! Back in 1987 I wrote a disassembler in REX X that processed TEXT decks and MODULES and created assembler source with labels. Later on (1989) I used it to create a ZAP to the COBOL compiler to remove it's requirement for using an auxilary directory. This allowed COBOL to run from a minidisk whose directory had been saved in a DCSS wit h SAVEFD. Brian Nielsen
Re: GIVE command on a tape drive with intervention required
Dumps are snapshots and you're trying to debug a process. So unless the process is recorded in the trace table entries available in the dump all the dump tells you is - yep, there's a problem with that counter. If it were me I'd want to first make sure that the relevent events are creating trace table entries - if not, either use TRSOURCE or add code to create the trace table entries. Then, use TRSAVE to write the trace entries to tape until the problem happens. After that it's just a data reduction problem. ;) A long time ago I had a modification to CP that would timestamp the trace table entries. Now-a-days, trace table entries contain the time-of-day clock value. The other alternative is to have intimate knowledge of the process and debug it from the logic end with the source code. Not always a reliable process and frequently requires adding code to get the some debugging information - which is exactly what the trace table is for. See above. Brian Nielsen It's only ones and zeroes On Wed, 24 May 2006 15:34:10 -0700, Schuh, Richard [EMAIL PROTECTED] wrot e: It is difficult to be too helpful with a problem that even the vendor cannot solve after having been provided several dumps ;-) I speak of user s hung in LOGOFF/FORCE PENDING status with a deferred work count of 2 and nothing in the queue. If you can find some way to determine whether it is the result of a process that increments the count without putting anythin g on the queue or one that fails to decrement the count when it has completed, please let me know. You get extra credit if you can figure out a way to determine how long the count has been bogus. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, May 24, 2006 3:15 PM To:IBMVM@LISTSERV.UARK.EDU Subject: Re: GIVE command on a tape drive with intervention required On Wednesday, 05/24/2006 at 01:37 EST, Brian Nielsen [EMAIL PROTECTED] wrote: 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'abl e DDR problem or user error caused by the HALT - don't do that? Please open a PMR, Brian. Because you asked so nicely [he's such a *nice* boy] and you have such helpful problem determination skills, we're inclined to treat it initially as a bug. (And I'm not 100% certain, but I think it helps that the developer is also named Brian.] But I ask you, why can't everyone else include a nice detailed analysis of the problem in *their* problem descriptions? I mean, it's not like in some alien language like Java or C++! ;-) [OCO modules excluded, of course] Alan Altmark z/VM Development IBM Endicott = ===
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 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 = ===
Re: GIVE command on a tape drive with intervention required
On Wednesday, 05/24/2006 at 01:37 EST, Brian Nielsen [EMAIL PROTECTED] wrote: 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? Please open a PMR, Brian. Because you asked so nicely [he's such a *nice* boy] and you have such helpful problem determination skills, we're inclined to treat it initially as a bug. (And I'm not 100% certain, but I think it helps that the developer is also named Brian.] But I ask you, why can't everyone else include a nice detailed analysis of the problem in *their* problem descriptions? I mean, it's not like in some alien language like Java or C++! ;-) [OCO modules excluded, of course] Alan Altmark z/VM Development IBM Endicott
Re: GIVE command on a tape drive with intervention required
We ran into this with our use of DDR in SafeDR. What I found is that DDR issues the MOUNT NEXT TAPE message and then issues a a TAPE RUN followed by another tape command (can't recall which anymore). This has the effect of placing the drive into Intervention Required. The userid with the tape drive is effectively hung until the drive is reset (usually by loading a tape). This means that you can't use the CP SEND command to issue commands on the server (with the tape drive). (If that's what you're doing.) What would be the effect of using the LEAVE option on the output tape definition? Would DDR leave the tape at EOT and display the message, or what? Shimon
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 anymor e. 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
Re: GIVE command on a tape drive with intervention required
Title: RE: GIVE command on a tape drive with intervention required 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
