Stand-Alone Backup Install to Disk Fails

[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.