Phil ESGUERRA ([log in to unmask]) wrote:
: If you're on 5.0 PUSH, and are attempting to replace a disc drive
: mech, read on.
...
:  Even when another temporary password was given, the DTDUTIL program could
not
:  be found. It was not in ldev 1!
 
This underscores the importance of what I suggested a few months ago:
 
   Manually make sure, now, that @.DIAG.SYS is on ldev 1 ... since
   the people/mechanism that generates the FOS & SUBSYS tapes didn't
   do it!
 
Do:
 
   1) logon as MANAGER.SYS
 
   2) STORE @.DIAG.SYS; ; SHOW
 
   3) put tape back on line
 
   4) RESTORE ; @.DIAG.SYS; DEV = 1; OLDDATE; SHOW
 
A few files (including: CMEML000, DIAGMON, MEMLOGP, XL) will not
be restored, since they are in use already...they normally are
already on ldev 1, so that's ok.
 
You can verify if a file is "locked" onto ldev 1 by doing:
 
   :listf filename, 3
 
and looking for a line like:
 
   VOLNAME   : MPEXL_SYSTEM_VOLUME_SET:MEMBER1
 
If it says ...MPEXL_SYSTEM_VOLUME_SET:DISC, then if you STORE/RESTORE
it, it will go onto any disk drive in MPEXL_SYSTEM_VOLUME_SET.
If it says "MEMBER1", then a STORE/RESTORE will only go onto ldev 1.
 
Personally, I'd suggest submitting a bug report for any file in
@.DIAG.SYS that isn't "locked" onto ldev 1.  (and, @.ARPA.SYS and @.NET.SYS?)
 
BTW, if the current @.DIAG.SYS files have a particular volume
restriction (:MEMBER1 or :DISC), then it is very likely that the
next tape you receive from HP will have the same restrictions (or
lack thereof) on those files.
 
You can see which disk drive a file is on *now* by doing:
 
   :listf filename, 3
 
and looking for a line like:
 
    DISC DEV #: 2
 
Technically, the above line means: the file label is on ldev 2, and
makes no statement about which disk any of the file's extents are on.
However, it *usually* indicates that at least the first extent
of the file is on that same ldev...and, since most of the @.DIAG.SYS
files are a single extent, that's fairly good.  On my system, all but two
of the @.DIAG.SYS files are a single extent each...and the two exceptions
(MEMLOGP.DIAG.SYS and XL.DIAG.SYS) are both restricted to ldev 1 (:MEMBER1).
 
If you want to be absolutely sure, do:
 
   :run fscheck.mpexl.telesup
   de filename
 
Example:
 
   FSCHECK, A.04.71. (C) Hewlett-Packard Co., 1987. All rights reserved.
   fscheck: de xl.diag.sys
 
   SECT_ADDR   SECTS_IN_EXTENT  VOL_SET_INDEX  FILE_SECT_OFFSET
   ---------   ---------------  -------------  ----------------
 
   $00116D50         256               1          $00000000
   $00116E50         256               1          $00000100
   $00116F50         512               1          $00000200
   $00117150        1024               1          $00000400
   $00117550        2048               1          $00000800
   $00117D50        2048               1          $00001000
   $0012E1B0        2048               1          $00001800
 
   fscheck: exit
 
The VOL_SET_INDEX of "1" above indicates that all the extents are
on the same volume (volume 1, in this case).
 
Note that "VOL_SET_INDEX" isn't an ldev ... but for MPEXL_SYSTEM_VOLUME_SET,
VOL_SET_INDEX of 1 always means ldev 1.  (An index of '1' means the
master volume of the volume set.)
 
: It's interesting, for we did not move those files out of ldev1. They have
been
: there since we updated to 5.0 several weeks ago.
 
Is there any chance you did a:
 
   :RESTORE ; @[log in to unmask]
 
since the last update?
 
Stan Sieler
 
P.s.: gee, I wrote an entire reply without a single complaint about
the @#$%^ diagnostic password policy that Rich Sevcik said
wouldn't be implemented!