Stand-Alone Backup Install to Disk Fails

[Rick Dyson]

I have used the Mini PCI VMS install (called by StaBackIt on Alpha) to local hard drives for the safety and the performance it offers over a CD for any stand-alone backup needs on many different Alpha VMS boxes for the past few years. It beats booting off a CD!

Though I think I will also just make a backup copy of the install CD onto an old RZ28 and then be able to carry it around should the need arrise. :)

I just ran into one that seems to immediately go into a loop (or fit!) when trying to install to an empty RZ28 I have on the local SCSI bus. It is an AlphaServer 2000 with OpenVMS v7.3-1. (Last F/W: v5.3-6) I believe I have all published ECOs installed.

The RZ28 is empty, ODS-2, just init only. It is internal on the BA shelf using the built-in SCSI controller. I mounted it locally to SYSTEM's process and ran the install. It prompts for the device to use, I spell it out explicitly (i.e., $1$DKA200:) and it never returns after that.

Another session shows it's drawing 100% of the CPU for as long as I have let it run (20 minutes?). It is running PCSI$MAIN.EXE, incrementing Buffered I/O and the PC.

Any ideas? For completeness, I rebooted and tried it all again and get the same thing. I have never seen this one before.

Thanks!
Rick

[Uwe Zessin]

I can only guess, but I would check now if a process quota is exhaused.

[Willem Grooters]

Rick,
a suggestion I used lately, is to make an image backup of your CD to disk - all is then included. I have successfully backedup my system disk and upgrade the system after booting from that backup.

[Rick Dyson]

Thanks Uwe. That is a good idea. I'll try again and run some monitoring first to see what it is sucking up.

I was going to also do the entire CD ==> RZ28 route too. I think I saw that idea from someone recently on these forums. It is a glaringly obvious one once I see it! Most of my boxes still use SBBs, so I can make it work. :)

rick

[Uwe Zessin]

I agree that this is a good idea if you can divert a 'full' disk. Best to use a BACKUP/IMAGE to do the copy from CD-ROM. I have used this a long time ago when I had to upgrade 2 systems and one had a defective CD-ROM drive :-(

The PCSI-based copy, if I recall correctly, is smaller and can be copied to an existing disk with data on it already. It will also have current drivers, which the CD-ROM based copy does not have. I doubt that it will matter with an AlphaServer 2000 ;-)

[Tim Hughes_3]

I like to keep a disk copy of the VMS distribution CD online. Originally used for doing upgrades (much faster) but also good for sorting out LAN problems (LANCP and SDA work) and fixing broken startup files etc.(mount and edit work),

Tim

[Rick Dyson]

I tried again tonight and can't find any quotas running out. All primary ones are only down a few %. I *have* found that the buffered I/O goes through the roof, >900/s, for the entire time.

I have even run an AutoGen and tried again with no changes.

rick

[Uwe Zessin]

OK, another guess: do both disks have the same ODS level (2/5)?

[Rick Dyson]

yes. both are ODS-2. One is a direct SCSI attach from the internal SCSI controller. The other one is a RAID set (a virtual volume on a RAID 3+5) off an internal KZPAC (RA230).

[Cass Witkowski]

On the SCSI disk you are copying to if you do a SHOW DEVICE /full do is high-water marking listed. If so it may be doing an erase of the space being allocated. You can turn that off with the INIT/NOHIGH

If this disk is in a cluster and the other node has an internal disk as well named DKA200 then you may have two disks in two different nodes with the same device name. This is not good. You will need to set the DEVICE_NAMING sysgen parameter and set the class on that device to 0

Boot conversational
SYSBOOT> SET DEVICE_NAMING 1
SYSBOOT> SET/CLASS DKA 0
SYSBOOT> CONTINUE

[Rick Dyson]

The Alpha is a stand-alone. I typically have nohighwater turned on (or is that off?).

Sorry about the formatting, but here is the plain disk I have been trying to use:

Disk $1$DKA200: (WOLF), device type RZ28, is online, mounted, file-oriented
device, shareable, available to cluster, error logging is enabled.

Error count 0 Operations completed 63
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 1 Default buffer size 512
Total blocks 4110480 Sectors per track 86
Total cylinders 2988 Tracks per cylinder 16
Allocation class 1

Volume label "PUP" Relative volume number 0
Cluster size 4 Transaction count 1
Free blocks 4110080 Maximum files allowed 411048
Extend quantity 5 Mount count 1
Mount status System Cache name "_$1$DRA0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 411008
File ID cache size 64 Blocks in extent cache 0
Quota cache size 0 Maximum buffers in FCP cache 2350
Volume owner UIC [SYSTEM] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

Volume Status: ODS-2, subject to mount verification, write-back caching
enabled.

I'm pretty sure the INIT I used was:

Init/nohigh/owner=system/user=system $1$dka200: pup

[Cass Witkowski]

Rick,

If you do a SHOW PROCESS/CONTINUOUS/ID= of the process that is in the compute loop does it say what image it is running?

Have you tried just copying files to the disk and doing a directory to make sure the disk is working properly.

[Rick Dyson]

Yes. I use the little script that is all over called Mon_Quota that essentially does that as well as show primary process quota use at about 3sec intervals. I also monitored the process with AMDS. That is where I noticed my Buffered I/O was at an (it seemed to me) an extreamely high rate. Sustained at about 900 (/sec, right?) It is the PCSI$MAIN (from memory!) exe and none of the process quotas that I could see ever dipped much below 95% left. They were essentially not being exhausted.

I even ran an AutoGen on the system since I had tried this 5-6 times with the thought that maybe it would have collected feedback helpful, but it didn't seem to have any effect.

Rick

[Uwe Zessin]

I wonder where the buffered I/Os come from/ go to. Of course it is poking in the dark, but what the hell...
Can you do an:
$ analyze/system
set process ...
show process/channel

You might be lucky and hit the busy I/O channel. Else you might go over the CCBs (channel control blocks) and link from there via CCB$L_UCB to the UCB (unit control block). The I/O count is in UCB$L_OPCNT. Of course, multiple CCBs can point to the same UCB.

Sounds like an interesting project if such a program does not already exist.

[Steve Reece]

Whatever happens, be careful to make sure that either nothing has changed the behaviour of the MOUNT command for the installation that you're creating the kit from. There was one instance in a previous version of VMS to the one that you're using Rick that altered the options on the MOUNT command, updated DCLTABLES.EXE but _didn't_ update DCLTABLES.TEMPLATE. Result? If you didn't copy DCLTABLES.EXE across as well, you would be able to boot from the minimum environment but you wouldn't be able to mount anything! No disk, no tape, nothing.

Either way, for the situation that you've got now, have you tried modifying the DCL to do a SET VERIFY and show you the commands that are running? That could be an easy way of finding out what's going on and why it's apparently screwing up.

[Rick Dyson]

I did insert a Set Ver and got tons of looping reads from a temp file it created, but then it reached:

$PRODUCT INSTALL VMS /version=V7.3-1 -
/PRODUCER=DEC -
/BASE_SYSTEM=AXPVMS -
/DEBUG=(CONTINUE_ERROR) -
/SOURCE=sys$sysdevice:[vms$common...] -
/DESTINATION=$1$DKA200:[vms$common] -
/CONFIGURATION=input=sys$scratch:vms$min000001EB.pcf -
/WORK=$1$DKA200:[000000] -
/NOHELP -
/REMOTE -
/NOLOG

and that is the endless looping step. The install never actually does anything on the target disk, so I can't even say whether the DCLTABLES will be good or not. :)

One note I am working with a home system/Hobbyist so that is why I am sticking to this forum for assistance. :) The box started life at OpenVMS v7.3-1, so it does not have a long history of updates or changes except the standard ECOs for v7.3-1.

[Steve Reece]

Have you tried modifying the /NOLOG to /LOG in SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM and see what that gives?

Steve

[Rick Dyson]

didn't really resolve this, but have dropped
it for now.