SYSTEM account unable to mount device

[Jan Mlotkiewicz]

Got a VAX 6000-620 running OpenVMS 6.2 that we're porting to a CHARON-VAX emulator. We noticed that the SYSYEM account could dismount a volume on the emulator, but not remount it, except during a system boot.
Tried the same thing on the VAX 6000 with the same result.

Anyone know why the system account would not be able to mount disk? We try MOUONT/OVER=ID and MOUNT/SYSTEM SCRATCH SCRATCH and it times out.

SHO DEV lists the device as online, but the mount attempt says it can't find the device.

I don't have the same problem with tapes though. They mount / dismount just fine.

Any thoughts / ideas would be very welcome

Thanks.

[Jur van der Burg]

Take a look in the emulaotr's logfile. Any errors will be logged there. Also, show us the exact mount commands en the resulting error.

Jur.

[Hoff]

What connection between the real VAX and the CHARON-VAX exists here?

It seems that there are hardware configuration issues.

Anything in the error log?

Please post the commands used and the full text of the error messages received; paraphrasing commands and error text is hazardous as there are many errors here, and often with subtle differences.

Are there logical names getting in the way of the MOUNT command? SHOW LOGICAL on the device names referenced here, on the off change that somebody here is remapping devices via logical names.

[Jan Mlotkiewicz]

>> What connection between the real VAX and the CHARON-VAX exists here?

The CHARON-VAX was built from system backups of the 6000-620 that I ran using the BACKUP/IMAGE command. So it is an exact image of the existing VAX.

>>It seems that there are hardware configuration issues.

I do know that if we boot from a different system image, the emulator has no problem mounting. It appears to be something specific to the original VMS image taken from the 6000.

>>Anything in the error log?

Nope! I had the guy from the vendor check the emulator and he said it had nothing. ( By the way, Jur - Greg Snider said to say hi! )

>>Please post the commands used and the full text of the error messages received; paraphrasing commands and error text is hazardous as there are many errors here, and often with subtle differences.

OK..

Did a DISMOUNT RF0C24$DIA7:
( which was mounted with volume label of SCRATCH ). That went fine.
Then did MOUNT/SYSTEM RF0C24$DIA7 SCRATCH SCRATCH ( on the 6000-620 ). It sits for about 3 minutes, then comes back with:

%MOUNT-I-OPRQST, DEVICE _RF0C$DIA7: is not available for mounting

SHO DEV DIA shows that device as Online with 0 for error count

>>Are there logical names getting in the way of the MOUNT command? SHOW LOGICAL on the device names referenced here, on the off change that somebody here is remapping devices via logical names.

sho log/full MOUNT
%SHOW-S-NOTRAN, no translation for logical name MOUNT

show sym MOUNT
%DCL-W-UNDSYM, undefined symbol - check validity and spelling

so no, there are no logicals getting in the way.

[Jim_McKinney]

Throw a "/NOASSIST" on your MOUNT command and see if any error is then reported back to your terminal.

[Jan Mlotkiewicz]

>>>Throw a "/NOASSIST" on your MOUNT command and see if any error is then reported back to your terminal

MOUNT/SYSTEM/NOASSSIST RF0C24$DIA7 SCRATCH SCRATCH comes back with

%MOUNT-F-DEVBUSY, mount or dismount in progress on device

[Jim_McKinney]

But a SHOW DEVICE/FULL doesn't reveal what interest is held on it?

[Jan Mlotkiewicz]

SHO DEV /FULL RF0C24$DIA7 gives:

( I have to go back to the console to get this as the 6000 is off the network, so just getting some of it. )

Owner Process ""
Owner Process ID 00000000
Reference Count 0
Owner UIC [SYSTEM,MANAGER]
Host Type, avail RF72,yes

[Jim_McKinney]

Well, that doesn't look busy ;) Have you attempted to query the DSSI controller?

[Jan Mlotkiewicz]

>>Have you attempted to query the DSSI controller?

Nope. Not sure that I know the correct command for that either, since i'm sort of fumbling my way round as a VAX admin, since we no longer have one.

The system is not busy, since it is completely off the network, unavailable to users, since they're on the emulated environment. I couldn't take SCRATCH offline on the live environment so had to do the test on the 6000.
But, since the emulator is an exact image of the VAX, once I figure out the problem on the VAX, i'll have the solution for the emulator.

[Hoff]

Ok. MOUNT as a logical name or such might work to redirect the image activation (and the usual there is a symbol and not a logical name), but that's unusual. The intent here for the logical names was the device names. That's more common.

And here... a mount of RF0C24$DIA7: tosses out an error for _RF0C$DIA7:? That's odd. Are there logical names for SCRATCH, RF0C24$DIA7 and _RF0C$DIA7 around?

I'd probably use

PIPE SHOW LOGICAL | SEARCH SYS$PIPE DIA

to see what sorts of DSSI-related logical names lurk.

If this is really DSSI and not an emulation, then that's a cluster interconnect, and there are specific requirements around setting up nodes in a DSSI cluster.

[GSnider · Accepted solution]

Hello all,
I am working with Jan Mlotkiewicz, installing a Charon-Vax replacement system for their Old VAX 6620. Both the Old VAX and Charon-Vax had the same problem in mounting disk drive that had been dismounted.
Here is what I found out, they have always had this problem, and it is due to them running PerfectCache. When I stop PerfectCache from running, then I can mount disk drives. When I restart PerfectCache again I can no longe mount disk drives.

This is a new one for me.....

Greg Snider

[Volker Halle]

Greg,

there is probably some lock being held by PerfectCache for this device. This could explain the DEVBUSY message...

Thanks for letting us know.

Volker.

[GSnider]

Using Charon-Vax, I had created some Spare Disk drives about 5-6 of them, PerfectCache would not let me mount any of these new Spare drives either, but it would let me INIT the drive and give it a volume label, so PerfectCache most do something for all Disk drives....

I install a lot of Charon systems, and we get blamed for some old problems that they have and don't know about, just ask Jur......

Greg Snider

[Jur van der Burg]

Right. Many times when transferring contents of old systems to an emulator we get the blame for things that don't work correctly. Many times this is due to old software in use which has flaws, no patches installed, etc. When transferring to an emulator they run into these issues, many times because the emulator is much faster than the original systems. Bringing the systems up to rev is almost always the answer.

Jur (Emulators hat on).

[Volker Halle]

Greg, Jur,

my argument in these case is: look at how excellent CHARON-VAX emulates the system - including all the original bugs !

Volker.

[Hoff]

And my response is "and the blasted crash scrolls past so fast I can't read it"...

[Jim_McKinney]

Don't recall if this feature is available for VMS 6.2, but if so, it might save you some time spent in SDA.

$ set term/widt=132
$ defi show$debug 1
$ defi show$debug_lckbuf 1
$ show devi RF0C24$DIA7: