| Title: | MRU Internal Bug Reports |
| Moderator: | COOKIE::STMARTIN |
| Created: | Wed Sep 20 1995 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 346 |
| Total number of notes: | 1175 |
Media Robot Utility T1.2 (5)
OpenVMS Alpha V6.2-1H3
ROBOT3> @SYS$COMMON:[SYSTEST]ROBOT$IVP.COM;6
*** STORAGEWORKS MRU V1.1 Installation Verification Procedure (IVP) ***
Copyright(c) Digital Equipment Corporation 1996.
The following HSx connected SCSI loaders and libraries were found :
The following Direct connected SCSI loaders and libraries were found :
Device Device Error
Name Status Count
GKA200: Online 0
The following DSSI connected loaders were found :
The following DSA connected loaders were found :
Please enter the robot name of a media loader or library: GKA200:
%SYSTEM-F-NOLOGNAM, no logical name match
*** The IVP for STORAGEWORKS MRU V1.1 has failed! ***
%SYSTEM-F-NOLOGNAM, no logical name match
ROBOT3>
Commenting out the following command worked around the problem:
$! if f$trnlnm("mru_robot") .nes. "" then $ deassign mru_robot
Seems like you need to test for the existence of the logical name
before using f$trnlnm . . .
tl
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 345.1 | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Wed May 21 1997 18:01 | 4 | |
I suspect the IVP failed because you used a media changer with ports. Since we can't easily know whether the changer has ports we now ignore the status on that case. The IVP failure led to the other problem. | |||||
| 345.2 | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Wed May 28 1997 17:49 | 7 | |
I really did see this once or twice myself, but I can't reproduce it now. I've run the script on V6.2-1H3, V6.1 and V7.1, and it works fine. I've run the offending line and it works fine as well. I can probably figure out how to check for the existance of the logical first, but I'll need a bit of help... | |||||
| 345.3 | COOKIE::KYLER | Thu May 29 1997 14:27 | 20 | ||
Alan,
This statement
$! if f$trnlnm("mru_robot") .nes. "" then $ deassign mru_robot
assumes that mru_robot is a supervisor mode logical name in the process
table. If it is user mode or exec mode, or is in the job, group, or
system tables, the f$trnlnm will return the translation, but the
deassign will fail with exactly the message Terry got.
If you need to reassign this logical for the purposes of the IVP,
consider a user mode assignment, e.g., $ DEFINE/USER MRU_ROBOT 'DEV'
The user mode assignment is good for one image activation, after which
it is automagically deassigned, revealing the previous supervisor or
exec mode assignment.
- Dan.
| |||||
| 345.4 | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Thu May 29 1997 16:57 | 4 | |
It is starting to make sense now. It only seems to fail when the command file is run by the installation procedure. I think I have a clearer solution; don't use a logical... We don't really need to define MRU_ROBOT. | |||||
| 345.5 | Close. | SSDEVO::ROLLOW | Dr. File System's Home for Wayward Inodes. | Wed Jun 04 1997 00:54 | 5 |
When in doubt, use a sledge hammer... I just rewrote the robot commands using the robot name to use the inquired variable directly instead of using it to define MRU_ROBOT. | |||||