DS20 from Tru64 to VMS
Claude Marinier
I inherited a DS20 and I want to use it to replace the old DEC 3000
Model 400. It was running Tru64 and I want to run VMS 7.3.
I copied the files to two larger disks (17GB), connected them to the
DS20, changed a few settings at the console boot prom, and booted VMS.
VMS cannot see any SCSI devices other than the boot disk. I tried
SYSMAN's IO REBUILD and IO AUTOCONFIGURE but it does not help.
For the last few years, I have been busy with other operating systems
and have forgotten so much VMS it is not funny. I have found a few posts
about converting from NT to VMS and suspect that this may be more
difficult than I thought.
Is this possible?
Am I missing something simple?
By the way, I updated the firmware with the CD that came with VMS.
Thanks.
P.S. Half forgotten VMS experience may be worse than no experience at all.
--
Claude Marinier, Information Technology
Defence Research & Development Canada (Ottawa)
claude....@drdc-rddc.gc.ca
http://www.ottawa.drdc-rddc.gc.ca
Peter 'EPLAN' LANGSTOEGER
>I inherited a DS20 and I want to use it to replace the old DEC 3000
>Model 400. It was running Tru64 and I want to run VMS 7.3.
Please consider the current version V7.3-2
>I copied the files to two larger disks (17GB), connected them to the
>DS20, changed a few settings at the console boot prom, and booted VMS.
What settings ? BOOT_OSFLAGS ? What else ?
>VMS cannot see any SCSI devices other than the boot disk. I tried
>SYSMAN's IO REBUILD and IO AUTOCONFIGURE but it does not help.
>[snip]
>Am I missing something simple?
A disk controller supported by VMS ?
Is the boot disk and the other disks on the same controller ?
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail pe...@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
Claude Marinier
I did set BOOT_OSFLAGS to "0,0". I also set the one that used to say
"UNIX" and the default boot device.
Could the SCSI controler be unsupported with VMS? All three disks are on
the same controller (PKA) and I do see DKA200.
Peter 'EPLAN' LANGSTOEGER wrote:
> In article <10878383...@news.drenet.dnd.ca>, Claude Marinier <claude....@drdc-rddc.gc.ca> writes:
>
>>I inherited a DS20 and I want to use it to replace the old DEC 3000
>>Model 400. It was running Tru64 and I want to run VMS 7.3.
>
>
> Please consider the current version V7.3-2
>
>
>>I copied the files to two larger disks (17GB), connected them to the
>>DS20, changed a few settings at the console boot prom, and booted VMS.
>
>
> What settings ? BOOT_OSFLAGS ? What else ?
>
>
>>VMS cannot see any SCSI devices other than the boot disk. I tried
>>SYSMAN's IO REBUILD and IO AUTOCONFIGURE but it does not help.
>>[snip]
>>Am I missing something simple?
>
>
> A disk controller supported by VMS ?
> Is the boot disk and the other disks on the same controller ?
>
--
Peter 'EPLAN' LANGSTOEGER
>Could the SCSI controler be unsupported with VMS? All three disks are on
>the same controller (PKA) and I do see DKA200.
What does a SHOW CONFIG tell about the controller ?
Could it be that the disks aren't compatible (non-ultra)
with the controller (ultra SCSI) ?
Claude Marinier
related to SCSI devices. In the mean time, the 'SHOW CONFIG' PROM
command tells me that I have three NCR 53C895 SCSI controllers: PKA,
PKB, and PKC; and two Adaptec AIC 7895 SCSI controllers: PKD and PKE.
These last two are on the same board as the Ethernet controller
(DE500-AA). The system also has two IDE controllers: DQA and DQB; the CD
drive is DQA0. All SCSI devices are on PKA: the internal disk (saving
the copy of Tru64), the two external disks, and the external tape drive.
I can boot from DKA200 but VMS only sees that one SCSI device. MultiNet
does not see the Ethernet controller.
I would like to put the external devices on a different SCSI bus. I may
open the box to see if I can attach the external connector to a
different controller. That would eliminate the possibility of
interference between the SCSI devices.
I tried to apply the most recent VMS update patch in the hopes of fixing
the driver problem. It fails with an undefined symbol (something related
to post processing). I may have to re-install VMS so it discovers the
actual devices; I do not know how VMS goes about the boot process and
device discovery & configuration but expected it to be dynamic. I will
start asking about purchasing the latest VMS (I think it is 7.3-2).
Peter 'EPLAN' LANGSTOEGER wrote:
> In article <40D7350A...@drdc-rddc.gc.ca>, Claude Marinier <claude....@drdc-rddc.gc.ca> writes:
>
>>Could the SCSI controler be unsupported with VMS? All three disks are on
>>the same controller (PKA) and I do see DKA200.
>
>
> What does a SHOW CONFIG tell about the controller ?
>
> Could it be that the disks aren't compatible (non-ultra)
> with the controller (ultra SCSI) ?
--
Robert Deininger
claude....@drdc-rddc.gc.ca wrote:
>I will try booting again soon; at that time, I will note messages
>related to SCSI devices. In the mean time, the 'SHOW CONFIG' PROM
>command tells me that I have three NCR 53C895 SCSI controllers: PKA,
>PKB, and PKC; and two Adaptec AIC 7895 SCSI controllers: PKD and PKE.
>These last two are on the same board as the Ethernet controller
>(DE500-AA). The system also has two IDE controllers: DQA and DQB; the CD
>drive is DQA0. All SCSI devices are on PKA: the internal disk (saving
>the copy of Tru64), the two external disks, and the external tape drive.
>I can boot from DKA200 but VMS only sees that one SCSI device. MultiNet
>does not see the Ethernet controller.
What does the SHOW DEVICE command display at the console? You might post
that output, the disk names might be recognizable to someone.
One simple way to make drives disappear is to have a SCSI ID conflict. Or
a bad cable. Have you done all the standard SCSI bus debugging?
Is this a new installation of VMS? One can tell VMS to ignore devices.
(See SYSMAN IO SET EXCLUDE.)
Multinet might not see the network controller if it has been configured to
look for a different controller.
These problems might show up if you move an existing, customized VMS
system disk from one system to another without adjusting the
customizations.
>I would like to put the external devices on a different SCSI bus. I may
>open the box to see if I can attach the external connector to a
>different controller. That would eliminate the possibility of
>interference between the SCSI devices.
In general, if a SCSI controller has an internal connector and an external
connector for the same SCSI bus, you are only supposed to use one
connector. There may be exceptions, but I can't think of them offhand.
>
>I tried to apply the most recent VMS update patch in the hopes of fixing
>the driver problem. It fails with an undefined symbol (something related
>to post processing).
You should post the exact message.
>I may have to re-install VMS so it discovers the
>actual devices; I do not know how VMS goes about the boot process and
>device discovery & configuration but expected it to be dynamic.
VMS discovers disks when it boots, or when you explicitly ask it to (using
SYSMAN IO AUTOCONFIGURE). You don't need to re-install VMS to make it
locate disks, assuming you have a good installation to begin with.
The fact that VMS recognizes one disk on the SCSI controller, but not the
others, suggests the controller is probably not the problem. I guess
there's something wrong with the disks (at least from VMS's point of
view), or the cabling is bad, or VMS has been misconfigured.
JF Mezei
> One simple way to make drives disappear is to have a SCSI ID conflict. Or
> a bad cable. Have you done all the standard SCSI bus debugging?
I believe that in the original post, the writer stated that the system worked
fine with TRu64, and it is only when he tried to load VMS that it stopped working.
Assuming the above paragraph is correct, wouldn't the only possible answer be
a problem with VMS drivers not being compatible with whatever device was
loaded whereas the Tru64 drivers were ?
Could it be a problem with the hardware not having the ROM software needed to
boot VMS (or would a DS20 have all pre-requisite ROM based console software to
boot VMS ?)
Also, not sure if I saw this, but starting at what version of VMS would the
DS20 be supported ?
Michael Unger
> [...]
>
> Also, not sure if I saw this, but starting at what version of VMS would the
> DS20 be supported ?
According to the QuickSpecs (28-Feb-2000 edition, Page 2) that would be
V7.1-2.
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
Robert Deininger
<jfmezei...@teksavvy.com> wrote:
>Robert Deininger wrote:
>> One simple way to make drives disappear is to have a SCSI ID conflict. Or
>> a bad cable. Have you done all the standard SCSI bus debugging?
>
>I believe that in the original post, the writer stated that the system worked
>fine with TRu64, and it is only when he tried to load VMS that it stopped
working.
>
>Assuming the above paragraph is correct, wouldn't the only possible answer be
>a problem with VMS drivers not being compatible with whatever device was
>loaded whereas the Tru64 drivers were ?
I think there are lots of possible answers. If the OS switch didn't
include any HW reconfiguring, that's a useful clue.
>Could it be a problem with the hardware not having the ROM software needed to
>boot VMS (or would a DS20 have all pre-requisite ROM based console software to
>boot VMS ?)
I don't think there were ever DS20s that couldn't support VMS. There were
SCSI adapters that were OS-specific. Maybe in VMS the adapter works on
the boot device "by accident", but won't work with any other disk. But
I've never heard of that in practice.
>Also, not sure if I saw this, but starting at what version of VMS would the
>DS20 be supported ?
Dunno off the top of my head. Probably 7.1 or thereabouts. I think the
FAQ has a pointer to minimum version information.
Recent VMS versions are much less picky about disk characteristics. I
remember a time when the SCSI driver wouldn't work with many SCSI-3
drives. A later version fixed that problem.
JF Mezei
> I don't think there were ever DS20s that couldn't support VMS.
I recall a discussion some time ago where Compaq had announced a "special
order" DS20 sold to some corporation/government (big sale) and that particular
"batch" had been made to run only Tru64 (lacking the VMS console features). I
recall this because I had decried such a model, especially since the
anouncement had spoken of a model number that was available with VMS (eg:
making some of those models bootable with VMS, others not). "DS20" sounds
familiar for this.
Paul Repacholi
> Robert Deininger wrote:
>> One simple way to make drives disappear is to have a SCSI ID conflict. Or
>> a bad cable. Have you done all the standard SCSI bus debugging?
> I believe that in the original post, the writer stated that the
> system worked fine with TRu64, and it is only when he tried to load
> VMS that it stopped working.
> Assuming the above paragraph is correct, wouldn't the only possible
> answer be a problem with VMS drivers not being compatible with
> whatever device was loaded whereas the Tru64 drivers were ?
It has those dual SCSI/E'net controllers? I thoought that there was no
VMS support for them?
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Dirk Munk
made by Alpha Computers and adapted by Compaq for Telco customers. There is no
VMS support for this box, just Tru64.
JF Mezei
>
> Don't you mean the DS20L ? That wasn't a DS20 at all afaik, but a motherboard
> made by Alpha Computers and adapted by Compaq for Telco customers. There is no
> VMS support for this box, just Tru64.
Yep that was it. Would someone who inherits this box as a hobbyist know that
this is a DS20L though obvious means (label on box), or would one have to take
a big look at the motherboard to realise that it wasn't a "Digital"
motherboard ?
Robert Deininger
<jfmezei...@teksavvy.com> wrote:
A DS20L doesn't look anything like a DS20, and it won't identify itself as
a DS20.
That said, VMS on a DS20L wouldn't behave as the original poster described.
Claude Marinier
The SHOW CONFIG and SHOW DEV commands correctly list the devices that
are attached to the system. The SCSI IDs are OK.
The system did run well with Tru64. It was running off a 9.1 GB drive
(BD009122C6).
I have removed the LSI Logic SCSI controller (SYM8952U). I connected the
disk drives to the combo card; it has one DE500 plus two NCR 53875 SCSI
controllers. That card uses the compact SCSI connectors; I got it
working by adding a DLT drive (fun with SCSI cables).
Everything is visible from the console. Interestingly, I can also see
the SCSI devices when I boot from the VMS CD-ROM.
I suspect that the boot process hands VMS the means of accessing the
SCSI disk but VMS is not able to do more.
This next question may be key. Does anyone have a definitive answer?
Paul Repacholi wrote:
> It has those dual SCSI/E'net controllers? I thought that there was no
> VMS support for them?
--
JF Mezei
> I suspect that the boot process hands VMS the means of accessing the
> SCSI disk but VMS is not able to do more.
This may not be adefinitive answer, but may help you understand whaty goes on.
I had put an old 250meg apple SCSI-1 drive on my VAXstation 3100. At the
console level, it was shows as existing, was able to format it etc.
When I booted, VMS would begin to boot, at at one point, would just stop.
Physically powering off the drive and powering it back one would fix it and
VMS would then continue to boot happily.
The reason this was happening is that once VMS was sufficiently booted, it
started to issue its own SCSI-2 commands, and one of them probably jammed the
drive itself which didn't understand those commands. Powering off the drive
and back on cleared the problem and VMS was then able to continue (and did so
due to mount verification logic that allows VMS to retry IOs for a period of time).
Also, do you know if the drive itself is properly configured ? (parity for
instance). I got a 4gig drive once which showed up fine in the console, but
VMS would constantly complain about parity errors. (and since I couldn't find
any doc for that drive model, couldn't figure out how ensure its parity was
set properly).
dit...@dittman.net
> Some answers to previously posted questions.
>
> The SHOW CONFIG and SHOW DEV commands correctly list the devices that
> are attached to the system. The SCSI IDs are OK.
SRM will show the devices if you are using a SCSI controller with a
supported chipset.
> I have removed the LSI Logic SCSI controller (SYM8952U). I connected the
> disk drives to the combo card; it has one DE500 plus two NCR 53875 SCSI
> controllers. That card uses the compact SCSI connectors; I got it
> working by adding a DLT drive (fun with SCSI cables).
>
> Everything is visible from the console. Interestingly, I can also see
> the SCSI devices when I boot from the VMS CD-ROM.
Have you tried installing at this point and seeing if the disks show up
on the installed system?
>> It has those dual SCSI/E'net controllers? I thought that there was no
>> VMS support for them?
It depends on the model number. Some of them don't have the VMS/Tru64
ROMs. Tru64 will use the controller anyway in 53C810 mode, but VMS will
complain and refuse to use the controller.
If the controller is an Intraserver card, the part number will be ITI-xxxx-?
if the ? (there may be one or two characters and/or a number) has a V in it,
the card has the VMS/Tru64 ROMs. For example, the ITI-4280UE-4 will not
work with VMS, but the ITI-4280UE-4V and ITI-4280UE-4VS will both work (the
"S" means it also has the proper OB firmware ROM for Sun systems).
--
Eric Dittman
dit...@dittman.net
John Santos
> JF Mezei <jfmezei...@teksavvy.com> writes:
>
> > Robert Deininger wrote:
>
> >> One simple way to make drives disappear is to have a SCSI ID conflict. Or
> >> a bad cable. Have you done all the standard SCSI bus debugging?
>
> > I believe that in the original post, the writer stated that the
> > system worked fine with TRu64, and it is only when he tried to load
> > VMS that it stopped working.
>
> > Assuming the above paragraph is correct, wouldn't the only possible
> > answer be a problem with VMS drivers not being compatible with
> > whatever device was loaded whereas the Tru64 drivers were ?
>
> It has those dual SCSI/E'net controllers? I thoought that there was no
> VMS support for them?
KZPCM? Two SCSI ports + 10/100 Enet? They work just fine on VMS.
Got lots of customers using them. Many configured/sold/supported
by HP, so nothing unofficial about it.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Claude Marinier
else). I will cannibalize an older system and use its SCSI controller.
We will see if that does it (it will be Monday by the time I get to it).
John Santos wrote:
> On Thu, 24 Jun 2004, Paul Repacholi wrote:
>>It has those dual SCSI/E'net controllers? I thought that there was no
>>VMS support for them?
>
> KZPCM? Two SCSI ports + 10/100 Enet? They work just fine on VMS.
> Got lots of customers using them. Many configured/sold/supported
> by HP, so nothing unofficial about it.
--
dit...@dittman.net
> I have a KZPCM-DX but it also says Intra Server ITI 4280UE (nothing
> else). I will cannibalize an older system and use its SCSI controller.
> We will see if that does it (it will be Monday by the time I get to it).
I'm not sure the the KZPCM-DX is the VMS/Tru64 version. I know the
KZPCM-DA has the correct ROMs.
If the KZPCM-DX does have the correct ROMs, it may not work if someone
has flashed the ROMs to a newer non-DEC version of firmware.
--
Eric Dittman
dit...@dittman.net