[Info-vax] Reconfiguring VMS 6.2 - Shadow set question

[Stephen Hoffman]

On 2012-10-22 07:36:10 +0000, supervinx said:

> Il Mon, 22 Oct 2012 09:30:24 +0200, Joseph Huber ha scritto:
> 
>> supervinx wrote:
>> 
>> 
>>>> But before you remove this, you need to inventory your system startup
>>>> and other procedures for any direct references to the DSAxxx: devices
>>>> as the physical disk device names will change from DSAxxx: to DKAxxx:
>>>> once you no longer use shadow sets.
>>> 
>>> Can I use some logical symbol instead of go hunting all DSAXXX:
>>> reference ?

For now, leave the device references alone.   Fix the MOUNT command if 
you really, really must.   (But likely best to leave this all alone, 
until you have some idea of what hardware you're working with here; 
what's installed, what works, what doesn't, etc.  See below.)

>> 
>> As a general rule, one should use ONLY logical names instead of device
>> specifications everywhere except at the single place where a disk is
>> mounted (in systartup_vms, or some mount_disks.com called from
>> systartup). I usually use the disk$label logical generated by the mount
>> command, or define some concealed logical names for parts of a disk.
> 
> I agree, but I didn't configure this machine, so I have to imagine
> where and what someone else did ;)

No, you don't.  You can nuke and pave.  But if you want to spend 
(waste?) your time reverse-engineering an old and probably now invalid 
system configuration (and for little or no pay-off), well, sure.  Have 
at.  Entirely your call, of course.

So this box is probably that DEC 2000 model 300 you were mentioning 
earlier.  Also known as the DECpc AXP 150, as the Jensen, and also 
sometimes as "not my favorite Alpha) box", and "friends don't give 
other friends a Jensen".

That box is last officially supported by V7.3-1.  I don't immediately 
recall why OpenVMS Alpha support was withdrawn.  Whether it was a 
restriction around the available physical memory, or a graphics 
controller issue, removal of hardware support or something else.  The 
Adaptec 1742A did see performance problems as TCQ was introduced.  
(This was one of the first Alpha boxes with OpenVMS Alpha support 
removed, too.)

The Jensen requires a software tool known as the ECU floppy if any 
changes are made to the core I/O bus configuration and the EISA bus.   
Scrounge through any floppies you were provided, then (if you don't 
have it) start web searches for images of the ECU floppies.  (Access to 
the ECU disks was initially restricted due to some of the bits on the 
ECU disks; that may well have changed in the subsequent years.)

The Adaptec 1742A SCSI controller used in the Jensen is also 
particularly sensitive to the SCSI configuration.  If you stray outside 
what was provided by and supported by DEC - swapping random SCSI disks, 
and particularly attempts at extending the SCSI bus - then the SCSI 
controller very much prone to encountering oddities and problems.   If 
the SCSI disks are inside the box, then you can't (shouldn't) extend 
the bus outside the box.  And if the disks are mounted in an external 
enclosure, then you can't (shouldn't) use that SCSI bus for disks 
inside the box.  And some (unsupported) SCSI disks didn't work - at all 
- on that bus.  Put another way, straying beyond the original supported 
SCSI configuration and devices (which definitely did work), the SCSI 
bus was flaky, and alternations to the supported configurations 
variously didn't work.  And this box can be flaky.

You're probably still working with an acquired OpenVMS installation and 
which means you're reverse-engineering what was done, and you're 
probably not particularly familiar wioth OpenVMS.  Nuking and paving is 
generally a better idea for a new (to VMS) user, as you're not tossed 
into the deep end of system management.  (And in this case, with a very 
old, very slow, and possibly flaky box.)

Now...

You could have hardware problems with the disk devices that were 
specified in the shadowset MOUNT commands, or they could have been 
removed, or you could have one of the usual SCSI hardware problems with 
this box.  The only way to be sure is to open the box and look.  The 
SRM console >>> SHOW commands might or might not show the disks, and 
OpenVMS clearly isn't showing the disks.  This means you're going to 
have to reverse-engineer what happened.  Or get rid if the secondary 
members in the command, and move on.  Or nuke-and-pave, and start from 
a known configuration.

Given that you are not particularly experienced with VMS, I would 
strongly recommend nuking and paving this disk.  A fresh installation.  
Erase the disks, and install OpenVMS Alpha from distro.  V7.3-1 should 
work, and V8.3 or V8.4 might work.  Then you get to go through and 
tailor this system to meet your needs, and you can follow the OpenVMS 
documentation to do that - the OpenVMS User's guide and the OpenVMS 
System Managers' manuals being the first documents to review in the 
OpenVMS manual set - and not have to reverse-engineer what was 
previously done to this box.  (The VMS user interfaces were designed 
with the expectation that the system manager has read through and 
understood the provided documentation.  It's quite far from a 
self-guiding UI.)

Scrounge OpenVMS V7.3-1 and wipe and install it and the layered 
products.  Or try V8.3 or V8.4, and see if that still works.

Or continue with the reverse-engineering.

But you're going to have to crack open the box and see what's in it.

http://h18002.www1.hp.com/alphaserver/download/dec2000_ug.pdf
http://h18002.www1.hp.com/alphaserver/archive/axp/dec2000_specs.html
http://manx.classiccmp.org/collections/mds-199909/cd1/alpha/a0652ug1.pdf
http://manx.classiccmp.org/collections/mds-199909/cd1/alpha/a0654ug1.pdf
http://manx.classiccmp.org/collections/mds-199909/cd1/alpha/d23axupa.pdf
http://www.hp.com/go/openvms/doc (for the OpenVMS user's guide and the 
system manager's essentials)
http://www.mikeash.com/getting_answers.html (eg: why am I guessing 
about what hardware you're using?)




-- 
Pure Personal Opinion | HoffmanLabs LLC