Conference vaxaxp::vmsnotes

:    Hi there can anyone tell me where I can get a copy of VAX VMS
:    STABACKIT.COM  (Ident X-46 I think) that will support a TLZ09
:    DAT drive.

   X-46 dates from 26-OCT-1995.  I don't see a release of OpenVMS VAX
   that specifically includes the TLZ09.  On OpenVMS Alpha V7.1, the
   TLZ09 device type is 28, which is the `generic MK' device type. 
   A fix for `generic MK' support did go into into the OpenVMS VAX
   X-45 baselevel of STABACKIT -- this looks like the minimum version
   you would want.

   The OpenVMS VAX STABACKIT fixes X-44 through X-48 are in Gryphon,
   better known as OpenVMS VAX V7.1.  X-42 and X-43 went into Redhawk
   (V6.2 Comp-Kit), Dragon (V6.2), and Eagle (V7.0).

   In other words, pull STABACKIT off the OpenVMS VAX V7.1 kit.
   (See the low-numbered VMSNOTES notes for a pointer to the kit.)

   I would *strongly* recommend getting a CD-ROM and moving to the
   CD-ROM distribution, and using the OpenVMS VAX bootable root
   (SYS1) present on the OpenVMS VAX V7.1 software distribution.
   It's _far_ more convienient, and far faster than waiting for
   standalone BACKUP to bootstrap off tape...
    
   You can elevate the problem via IPMT, log a QAR, or fix it
   yourself.  As there appears to be no explicit code for the
   TLZ09, you'll want to raise this issue formally, and -- it'll
   likely be the most expedient -- add the tape drive yourself.
   (Codes for the various recent TLZ drives will need to be added
   in DTDEF, and support will need to be integrated into STABACKIT.)

    
    Steve...
    
    once again thank you for a swift reply. I've suggested that the 
    customer uses the V7.1 version of Stabackit.com and this appears to
    work just fine.
    
    Much appreciated
    
    Chris D.
    
    

    Just one query to add to this string. I've got a customer who has an
    AlphaServer 2000 with OpenVMS V6.2-1H3, and I'm wondering how
    standalone backup works if you do *not* have the CD-ROM. 
    
    I haven't tried this, but the customer insists that you cannot build a
    standalone backup kit on a tape and boot from there to do full image
    disk backups. I thought this was odd, since this was a typical thing I
    would do with a VAX (I'm sort of rusty on OpenVMS, I'm afraid 8-).
    
    Also, he says that you can boot standalone from the system disk (by
    changing the boot flags at the console prompt), but you do not have the
    ability to do full image backups of *all* the disks on the system if
    you do this.
    
    I think this has something to do with expected behaviours between the
    VAX and Alpha environments. Sorry for being so naive here, but could
    someone explain this for me?
    
    Thanks in advance,
    Jim

:    Just one query to add to this string. I've got a customer who has an
:    AlphaServer 2000 with OpenVMS V6.2-1H3, and I'm wondering how
:    standalone backup works if you do *not* have the CD-ROM. 

   Access to a CD-ROM drive is *required* on OpenVMS Alpha.  They're
   cheap, convenient, and they're the standard distribution medium --
   at worst, have one that can be hand-carried to and connected to the
   target system.

   The distributions are also cheaper for us to produce, and cheaper
   for the customer to purchase.

   And access to a CD-ROM drive -- either a direct or served connection,
   or via an InfoServer -- is also a very good idea in an OpenVMS VAX
   environment, as well...
    
:    I haven't tried this, but the customer insists that you cannot build a
:    standalone backup kit on a tape and boot from there to do full image
:    disk backups. I thought this was odd, since this was a typical thing I
:    would do with a VAX (I'm sort of rusty on OpenVMS, I'm afraid 8-).

   OpenVMS Alpha has *never* supported non-block-structured storage
   device (eg: tape) bootstraps. 
    
:    Also, he says that you can boot standalone from the system disk (by
:    changing the boot flags at the console prompt), but you do not have the
:    ability to do full image backups of *all* the disks on the system if
:    you do this.

   Standalone BACKUP was available on Alpha only prior to V6.1.
   One can create a bootable root on another disk storage device,
   if one does not have access to a CD-ROM drive.
    
:    I think this has something to do with expected behaviours between the
:    VAX and Alpha environments. Sorry for being so naive here, but could
:    someone explain this for me?

   OpenVMS engineering spends a non-trivial amount of time maintaining
   standalone BACKUP and the standalone BACKUP-related procedures and
   tools, as well as maintaining all the tape, floppy, RL02, etc,
   bootstrap drivers and associated support.  On VAX.  On Alpha, we
   have to maintain (only) the same set of drivers and support needed
   for the main OpenVMS bootstrap, because tape and floppy bootstraps
   are not supported.

Thanks for the info Steve,

The reason I am asking about this is that we just upgraded the system
disk on this particular machine from V6.2 to V6.2-1H3 and the customer
does not have the V6.2-1H3 CD-ROM to boot from to perform standalone
backup (OpenVMS crashes in a most bodacious manner if you are running
V6.2 and have a KZPDA installed in the box!).

I saw once a reference to the part number of *just* the CD-ROM (I 
think it would have a AA-*****-** part number), and I think if the
customer ordered this, this would solve his problem (I had my
V6.2-1H3 upgrade saveset on an SBB and therefore I don't have the
CD-ROM myself for reference).  Could someone kindly post this part
number?

Thanks in advance,
Jim

 

>   One can create a bootable root on another disk storage device,
>   if one does not have access to a CD-ROM drive.
    
SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM provides a way to do this.

$ @sys$system:AXPVMS$PCSI_INSTALL_MIN


    This procedure will allow you to install OpenVMS Alpha with no options
    on a disk other than your regular system disk.  You can then boot
    from the other disk to backup your system disk.

    You must enter the device name for the target disk.  Before this
    procedure is run, the target disk must be mounted privately to this
    process.  This means that it must not be mounted with /SYSTEM,
    /CLUSTER, /GROUP or /SHARE qualifiers.  It also must not be mounted
    with the /FOREIGN qualifier.  If any of these qualifiers were used
    when the disk was mounted, dismount it and re-mount it without them.

    (If you need to MOUNT enter Ctrl-Y to exit.)


Enter device name for target disk: (? for choices) ...
...

:I saw once a reference to the part number of *just* the CD-ROM (I 
:think it would have a AA-*****-** part number), and I think if the
:customer ordered this, this would solve his problem (I had my
:V6.2-1H3 upgrade saveset on an SBB and therefore I don't have the
:CD-ROM myself for reference).  Could someone kindly post this part
:number?

   Order QA-MT1AG-H8, the OpenVMS Alpha V6.2-1H3 CD-ROM bootable
   disk.   List price is US$14.

    Thanks for the timely and accurate info.
    Jim

I'm doing this on OpenVMS Alpha V6.2-1H2. The procedure does its 100%,
but there is an error. I haven't tried booting the disk to see if it is
OK or not. Is this a known problem?

Regards,
Slobodan

$ @sys$system:AXPVMS$PCSI_INSTALL_MIN
...
Enter device name for target disk: (? for choices) dka400

*** DEC AXPVMS VMS V6.2-1H2: OpenVMS Operating System, Version V6.2-1H2

    COPYRIGHT (c) 19-FEB-1996 -- All rights reserved

    Digital Equipment Corporation

%PCSIUI-I-DONEASK, execution phase starting
The following product will be installed:
DEC AXPVMS VMS V6.2-1H2
%PCSI-I-VOLINFO, estimated space information for volume USER4
-PCSI-I-VOLSPC, 89014 required; 455349 available; 366335 net
Portion Done: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%
%PCSI-I-PRCOUTPUT, output from subprocess follows...
%SET-E-READERR, error reading USER4:<000000>SYSMAINT.DIR;1
-SYSTEM-W-NOSUCHFILE, no such file
Portion Done: 100%
The following product has been installed:
DEC AXPVMS VMS V6.2-1H2
%SYSGEN-I-CREATED, DKA400:[SYSE.][SYSEXE]PAGEFILE.SYS;1 created

    The installation of minimum OpenVMS Alpha is now complete.

    Use the following command to boot minimum OpenVMS.
       BOOT -FLAGS E,0 <device-name>

    (Your system may require additional parameters to boot)

   Looks like there might be a disk structure oddity here...

   See the SYS$MAINTENANCE logical name, and check around for the
   SYSMAINT.DIR directories -- here is an example of the logical
   name and of a "normal" set of system-specific (2137,1,0) and
   system-common (1913,1,0) SYSMAINT.DIR directories...

$ sho log SYS$MAINTENANCE/fu
   "SYS$MAINTENANCE" [exec] = "SYS$SYSROOT:[SYSMAINT]" (LNM$SYSTEM_TABLE)
$ dir sys$sysdevice:[*...]sysmaint.dir/fi

Directory SYS$SYSDEVICE:[SYS0]

SYSMAINT.DIR;1       (2137,1,0)

Total of 1 file.

Directory SYS$SYSDEVICE:[SYS0.SYSCOMMON]

SYSMAINT.DIR;1       (1913,1,0)

Total of 1 file.

Directory SYS$SYSDEVICE:[VMS$COMMON]

SYSMAINT.DIR;1       (1913,1,0)

Total of 1 file.

re: 203.9 
...
%SET-E-READERR, error reading USER4:<000000>SYSMAINT.DIR;1
-SYSTEM-W-NOSUCHFILE, no such file
...

I suggest you ANAL/DISK the USER4: device.

I suggest you re-do the INSTALL_MIN after fixing the problem.

It is highly likely that your minimum system will work, but I'd re-do
it anyway, just to be certain.

This looks OK:

JOBIM_5>$ dir sys$sysdevice:[*...]sysmaint.dir/fi

Directory SYS$SYSDEVICE:[SYS0]

SYSMAINT.DIR;1       (2131,1,0)                 1/3

Total of 1 file, 1/3 blocks.

Directory SYS$SYSDEVICE:[SYS0.SYSCOMMON]

SYSMAINT.DIR;1       (1907,1,0)                 1/3

Total of 1 file, 1/3 blocks.

Directory SYS$SYSDEVICE:[VMS$COMMON]

SYSMAINT.DIR;1       (1907,1,0)                 1/3

Total of 1 file, 1/3 blocks.

Grand total of 3 directories, 3 files, 3/9 blocks.

>I suggest you ANAL/DISK the USER4: device.

Yup, got lots of errors, including:

%ANALDISK-W-BADDIRENT, invalid file identification in directory entry
        [000000]SYSMAINT.DIR;1
-ANALDISK-I-BAD_DIRHEADER, no valid file header for directory

>
>I suggest you re-do the INSTALL_MIN after fixing the problem.
>
>It is highly likely that your minimum system will work, but I'd re-do
>it anyway, just to be certain.

Yes, the minimum system worked fine, but I'll repair the disk and re-install
INSTALL_MIN. 

Thanks!

Regards,
Slobodan