Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Summary: Deallocating a tape drive from a nonexistent process

31 views
Skip to first unread message

Jo Schambach, 672-3146, 216

unread,
Aug 10, 1990, 3:27:00 PM8/10/90
to
I recently asked the list, whether somebody knew how to deallocate a tape drive
from a nonexistent process. This can happen through an unnormal exit out of
BACKUP or by deleteing a process that allocates it, before it is finished with
it, and other ways.
I want to thank everybody who responded to that request especially the four
people, who's responses I will append to this message. I hope that everybody
who has asked me to forward responses are reading this message. The following
responses were very helpful (I hope the authors of these letters don't object
to me posting their responses to the list):

************************ Response 1 ***************************************
From: IN%"jma...@td2cad.intel.COM" 8-AUG-1990 11:46:09.75
To: J...@ksuvxc.kent.edu
CC:
Subj: Re: Deallocating a Tape drive from a nonexisting process?


Joachim ...

DEC has a program that can do this. It's called DELLTAPE. We got a copy from
DEC Field Service by complaining loud and long about this problem (it can also
occur if BACKUP processes abort abnormally).

We made it very clear to our Field Service rep, our Sales rep, and Colorado
Springs that the DEC standard answer of "reboot the system" was unacceptable.

The worst part is that DEC has had this listed as a known problem since about
VMS V4.0 but has not yet put in a fix for the problem.

A quick warning (and part of the reason DEC doesn't generally distribute the
program): DELLTAPE requires that the tape drive be allocated to a non-
existent process. If it is used on a tape drive allocated by an existing
process, the system will hang or crash.


Hope this info helps.

John.
================================================================================
John Marek jma...@td2cad.intel.com

Any opinions in the above text are my own but feel welcome to use them.


****************** Response 2 ***********************************************

From: IN%"aa...@dragoon.telcom.arizona.EDU" 8-AUG-1990 14:59:58.69
To: J...@ksuvxc.kent.edu
CC:
Subj: Re: Deallocating a Tape drive from a nonexisting proc

Jo:

The only way to force a device deallocation from a nonexistent
process (or from an undeleteable process, such as one stuck in
RWAST), is thru some vicious kernel mode code (such as the
DEALLOCATE.MAR that someone sent you.) Such code is in fact
likely to crash a system. (I've done so myself, at any rate.)

A wimp's way out that may appeal to you, is to change the unit
number that the device reports. For example, your tape drive
is called "MUB0:". If it's a TU78 (let's say), then there's a
thumbwheel on it which changes its unit number. So if the
drive gets wedged as "MUB0:", then change it to "MUB1:".
Voila, a "new" tape drive appears on the system, suitable for
general use. In this way, you can get the drive back without
rebooting.

Aaron Leonard (AL104), <Leo...@Arizona.EDU>
University of Arizona Telecommunications, Tucson AZ 85721


******************* Response 3 ***********************************

From: IN%"goppelt%gssf....@scfd.nwc.navy.MIL" "GSSF::GOPPELT" 9-AUG-1990 10:40:58.62
To: jos <j...@ksuvxc.kent.edu>
CC:
Subj: RE: Deallocating a Tape drive from a nonexisting process?

There is a program from the DECUS tapes called ZDEC (try the Fall 89 tapes).
Used with the qualifier /OVERRIDE I have found it to be successful in
deallocating a tape drive from a nonexisting process.

cheers,
dave

------------------------------------------------------------------------------
|David S. Goppelt |Internet: goppelt%gssf....@nwc.navy.mil |
|Naval Weapons Center | goppelt%gssf....@26.3.0.85 |
|China Lake, CA 93555 USA|-------------------------------------------------|
|(619) 939-5023 av 437-5023|"I'm different than other people - pain hurts me"|
------------------------------------------------------------------------------

******************** Response 4 *******************************************

From: IN%"ALIS...@mits.com.AU" 10-AUG-1990 09:15:47.98
To: j...@ksuvxc.kent.edu
CC:
Subj: Deallocating a Tape drive from a nonexisting process?

The following is a program from DECUS. What it actually does is clear out
(zero) the owner field of the device (any type).

WARNING :- If you run this on a device in which the owner process exists YOU
WILL CRASH THE VAX !!

However, that said, I have found it to be quite a usefull program as the same
problem has happened to me several times.

This version works on VMS 5.2 and above (I've tried up to 5.3-1).
For earlier systems, see the comments at the start of the ZERO subroutine.

Thanks,

Alistair Grant

Internet: alis...@mits.com.au PSI Mail: psi%0505238730004::alistair
Phone: +61 3 615 4641 Fax: +61 3 615 4408


-------------------- Cut Here ----------------------------------
.TITLE ZOWN Zero Device Owner Field
.IDENT /1.0/
;++
;
; Title:
; ZOWN.MAR - Zero-out device owner field
;
; Version:
; 1-01
;
; Facility:
; System Management Tools.
;
; Abstract:
; This program zeros-out the device owner PID, reference count
; and DEVSTS fields stored in the UCB for a particular device.
; This is useful when you wish reset these values without booting
; the machine.
;
; Calling sequence:
;
; $ ZOWN := $mydev:[mydir]ZOWN
; $ ZOWN device
;
; Environment:
; CMKRNL privilege required, I/O data base is locked, program
; executed at elevated IPL.
;
; Author:
; Craig Beissel MMBW 12-Aug-1987
;
; From ZDEC by Mark Oakley DuPont Experimental Station
;
; Modifications:
; 1.01 Dougal Ingram - Modify for V5.2 , change to g^ctl$gl_pcb
;
;--

.SBTTL Symbols, Macros, Data

.LIBRARY /SYS$LIBRARY:LIB.MLB/

$TPADEF ; Symbols for LIB$TPARSE.
$SSDEF ; Symbols for return status.
$UCBDEF ; Symbols for device ucb.
$STSDEF ; Symbols for returned status.
$DVIDEF ; Symbols for $GETDVI service.
$DCDEF ; Symbols for device type.

.PSECT ZOWN_DATA,RD,WRT,NOEXE,LONG,SHR,PIC

CMD_BUF: ; Buffer to hold command line.
.BLKB 80
CMD_BUF_SIZ = . - CMD_BUF

CMD_BUF_DESC: ; Descriptor to command line.
.LONG CMD_BUF_SIZ
.ADDRESS CMD_BUF

PROMPT:
.ASCID /Device: /

PARSE_BLK: ; Parse block for LIB$TPARSE.
.LONG TPA$K_COUNT0
.LONG TPA$M_ABBREV ; Permit unambiguous abbreviations.
.BLKB TPA$K_LENGTH0-8

LOG_DEV_DESC: ; Descriptor for device on command line.
.BLKQ 1

DEV_BUF: ; Buffer to hold device name.
.BLKB 40
DEV_BUF_SIZ = . - DEV_BUF

DEV_BUF_DESC: ; Descriptor pointing to device name.
.LONG DEV_BUF_SIZ
.ADDRESS DEV_BUF

PID: ; Owner of device (if any).
.BLKL 1


DEV_ITEM_LIST: ; Device list for $GETDVI.
.WORD DEV_BUF_SIZ ; Make sure we have a physical device name.
.WORD DVI$_DEVNAM
.ADDRESS DEV_BUF
.ADDRESS DEV_BUF_DESC
.WORD 4 ; See if someone has this device allocated.
.WORD DVI$_PID
.ADDRESS PID
.LONG 0
.WORD 4
.WORD DVI$_DEVCLASS ; Check for a terminal.
.ADDRESS DEV_CLASS
.LONG 0
.LONG 0 ; End if item list.

TT_ITEM_LIST: ; Item list if we have a terminal.
.WORD DEV_BUF_SIZ ; Make sure we a have a physical device name.
.WORD DVI$_TT_PHYDEVNAM
.ADDRESS DEV_BUF
.ADDRESS DEV_BUF_DESC
.LONG 0

DEV_CLASS:
.LONG 1

K_ARG: ; Argument list for kernel-mode routine.
.LONG 1 ; Just one argument.
.ADDRESS DEV_BUF_DESC ; Pass descriptor for device name.


.SBTTL State Table
.PSECT ZOWN_STATES,RD,NOWRT,EXE,LONG,SHR,PIC

$INIT_STATE STATE_TABLE,KEY_TABLE

$STATE START
$TRAN TPA$_SYMBOL,DEV,,,LOG_DEV_DESC
$TRAN TPA$_EOS,TPA$_EXIT

$STATE DEV
$TRAN TPA$_EOS,TPA$_EXIT
$TRAN ':',COLON

$STATE COLON
$TRAN TPA$_EOS,TPA$_EXIT

$STATE
$TRAN TPA$_SYMBOL,DEV,,,LOG_DEV_DESC
$TRAN TPA$_EOS,TPA$_EXIT

$END_STATE


.SBTTL Main program
.PSECT ZOWN_CODE,RD,NOWRT,EXE,LONG,SHR,PIC
.ENTRY ZOWN,^M<R2,R3,R4,R5,R6,R7,R8,R9>

; Get the command line.
;
PUSHAL CMD_BUF_DESC ; Return length.
PUSHAL PROMPT ; Prompt for device name.
PUSHAL CMD_BUF_DESC ; Place to hold line.
CALLS #3,G^LIB$GET_FOREIGN
BLBS R0,20$ ; Error?
BRW EXIT
20$:
MOVL CMD_BUF_DESC,- ; Set length of string to parse.
PARSE_BLK+TPA$L_STRINGCNT
MOVL CMD_BUF_DESC+4,- ; Set address of string to parse.
PARSE_BLK+TPA$L_STRINGPTR
PUSHAL KEY_TABLE ; Parse the command line for
PUSHAL STATE_TABLE ; qualifier and device.
PUSHAL PARSE_BLK
CALLS #3,G^LIB$TPARSE
BLBS R0,30$ ; Error?
BRW EXIT
30$:

; Get the physical device name, and see if this device has an owner.
;
$GETDVI_S -
DEVNAM=LOG_DEV_DESC,- ; Command line has device name.
ITMLST=DEV_ITEM_LIST
BLBS R0,40$
BRW EXIT

40$:
CMPL #DC$_TERM,DEV_CLASS ; Did we get a terminal?
BNEQ 50$
$GETDVI_S - ; Yes, make sure we get the
DEVNAM=LOG_DEV_DESC,- ; physical device name.
ITMLST=TT_ITEM_LIST
BLBS R0,50$
BRW EXIT

50$:
$CMKRNL_S - ; Enter k-mode to zero out count.
ROUTIN=ZERO,-
ARGLST=K_ARG
BLBS R0,80$
BRW EXIT
80$:
EXIT:
RET

.SBTTL ZERO Routine
;++
;
; Functional Description:
; This routine zeros out the Owner PID, reference count and
; DEVSTS fields in the UCB for a specified device.
;
; Calling Sequence:
; $CMKRNL_S ROUTIN=ZERO,ARGLST=K_ARG
;
; where K_ARG is an argument list. This list contains
; the number of arguments passes (always 1), followed
; by the address of a descriptor pointing to the name
; of a device.
;
; Formal Parameters:
; Descriptor for name of a device.
;
; Implicit Inputs:
; I/O database.
;
; Implicit Outputs:
; Device owner PID, reference count and DEVSTS are set to zero.
;
; Completion Status:
; Returned in R0.
;
; Side Effects:
; I/O database is locked (routine runs in kernel mode at elevated
; IPL).
;
;--

.ENTRY ZERO,^M<R2,R4>

MOVL g^ctl$gl_pcb,r4 ;; Point to our PCB for system (V5 mod)
;;
;; Comment the above line and uncomment the line below for V4 systems
;;
;; MOVL G^SCH$GL_CURPCB,R4 ;; Our PCB address is input to SCH
;; routines.
JSB G^SCH$IOLOCKW ;; Lock the I/O database.

MOVL 4(AP),R1 ;;; Address of device name descriptor.
JSB G^IOC$SEARCHDEV ;;; Get UCB address for device into R1.
BLBS R0,60$
BRW ZERO_EXIT

60$:
CLRL UCB$L_PID(R1) ;;; Zero out PID field
CLRW UCB$W_REFC(R1) ;;; and reference count
CLRW UCB$W_DEVSTS(R1) ;;; and device status

ZERO_EXIT:
JSB G^SCH$IOUNLOCK ;;; Unlock I/O database (drop IPL).
MOVL #SS$_NORMAL,R0

RET

.END ZOWN
---------------------------- Cut Here ----------------------------------


*************************************************************************
* Joachim Schambach | Bitnet: JOS@KENTPHYS *
* Physics Department | Internet: J...@KSUVXC.KENT.EDU *
* Kent State University | *
* Kent, OH 44242, USA | Phone: x1-216-672-3146 *
*************************************************************************

0 new messages