Operating System - OpenVMS
1754339 Members
3256 Online
108813 Solutions
New Discussion юеВ

Radiology Information System running OpenVMS is Dying

 
SOLVED
Go to solution
Jan van den Ende
Honored Contributor

Re: Radiology Information System running OpenVMS is Dying

Sorry,

"load" read "loan"
(I need typing lessons! :-(

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Willem Grooters
Honored Contributor

Re: Radiology Information System running OpenVMS is Dying

Given it's age and probably (over)heating due to all the dust inside, I simply have to agree it's an hardware error, either with the system disk (DKA300), the controller it's connected to, or the cabling in between. And, seen what came accross your screen when booting, that won't be all. Even if you were able to fix this, other parts may (will) fail in due time. IMHO, it's beyond repair.

Although a refurbished Vax 3100 (or other) may be cheaper, I would advise to use a PC with CharonVax, since you already use Wintel boxes. The extra advantage will be you can then use technology that cannot be used on VAX. All your disks can be transferred to your Wintel storage; it's been done before several times.
Your VMS license can be transferred - at no, or very low cost. The only thing you will need is your system disk backup to be restored, or media to built a new one from scratch. But the first is the easy option.

Willem
Willem Grooters
OpenVMS Developer & System Manager
Carl Couric
Occasional Advisor
Solution

Re: Radiology Information System running OpenVMS is Dying

Hi Deuterium,

If your in the USA, I've got 3 MV3100s just sitting here in my lab doing nada, nothing, collecting dust.... I can give you one, just pay for shipping :) .

Based on everyones response, you have either:

1) Lost a SCSI bus controller
2) Lost a SCSI disk on the bus (to test, you would take each drive off one at a time and see if the bus behaves, but if you pull the system drive, well, kind of hard to test then, you need a backup SCSI disk).

Also, if it is just a disk (like a 1Gb or 2Gb [RZ-26 or RZ-28]) I may have a few of those around as well... I think I may even have a box of 4Gb RZ-29s around here somewhere!

And to test a disk (BIG DISCLAIMER HERE: USE AT YOUR OWN RISK, IF IT DELETES YOUR DISKS DATA, DON'T EVEN THINK OF BLAMING US!), you can from the >>> prompt "T 50" and "T 51" if I recall. One will run a format on a new/replacement SCSI disk and other does a verify. It will completely erase the disk but if you getting failures in there, you know you have hardware issues.

Carl
http://www.carlc.com - OpenVMS webhosting since 1999
deuterium
Occasional Advisor

Re: Radiology Information System running OpenVMS is Dying

wow. i just want to thank everybody again for the great help and advice that you've offered during the past week. here's the update:

so, i opened up the box a second time, as per Jan and Robert's suggestion, and sorted through the cables, maticulously looking for broken pins and whatnot. didn't really find anything though, so the SCSI cable seems relatively intact. but who know. i plugged the SCSI cable abck in, making sure that it was securely connected on both ends.

When I rebooted, the machine started to boot into the OpenVMS operating system again, which was a good sign. I did notice an error which I didn't notice before saying something to the affect of '%SYSTEM_F_FULL Unable to write to dev'. It did manage to get past that stage, however, and proceeded to the regular system start up. Then it crashed again with the register dumps.

I rebooted, and again got "%SYSBOOT-F-Unexpected Machine Check error" .

Out of curiosity, is it common for OpenVMS to have register dumps if a drive is completely filled?

For the record, the idea that the error is being caused by hardware failure is amongst the most easily believable suggestions I've ever run into. You simply have no idea what kind of horrid condition this system was in. When I came into this position about a year ago, it was covered in grime, dirt, dust, and water stains. Parts of the plastic are turning yellow-brown from over-heating and/or chemicals or something. And you should have seen the state of the terminal server and fax-server data lines. The morons who hooked it up had no clue about cable management, and over the past 15 years the cables became a giant 10 square-foot spider-web-knot of data lines. It was literally the kind of mess that I wouldn't have been surprised if a couple bugs or rodents had made a nest inside of it.

After about 9 months on the job, I decided I was ready to decomission the fax and terminal servers so that we could move it to our server room or something. Everything was going along fairly smoothly until I physically moved it from it's rack to a new rack. That's when it had it's first bad heart attack, I think.

Anyhow, we have plenty of data backups, so we're not worried that critical patient data is lost. But we do need to get this thing back up and running, as we got another subpeona yesterday.
deuterium
Occasional Advisor

Re: Radiology Information System running OpenVMS is Dying


So, after a week of responses, the overwelming response seems to be to investigate replacing the hardware; an option I hadn't initially considered seriously.

Currently, my thinking is that I would like to follow up with Carl Couric's offer. Carl, if you could send me your email, I'd like to discuss with you about obtaining one of your MV3100s. As a not-for-profit organization, we can at least write up one of those receipts-of-donation-thingers with our tax-code, so you should be able to get an honest to goodness legit tax write-off for the donation. We'll send a thank you note, letter of appreciation, and all that jazz too. And we will, of course, pay for shipping and handling. =)

If that doesn't work, then we'll go on to investigate the possibility of accessing the the via Windows somehow as per Willem's suggestion. There are definately some possible benefits to doing that, and given the condition of the equipment, I have to agree that future hardware errors are a matter of when, not if. However, the rest of the equipment and the new controller might be able to muck along for another couple years until our legal requirements expire. That, and it would be far easier to migrate the data with a working MicroVax3100 (e.g. being able to FTP the database to a new machine).

As per camarow's question, the system doesn't have a CD drive anywhere. In fact, it doesn't seem to have a floppy drive of any sort anywhere. It did used to have an honest-to-goodness tape reel storage system though (6250 BPI, 3/4" inch tape, about 18" in diameter reels). The tape reel system was decommissioned about 10 years ago when they got the 2Gig hard-drive though. =)

If Carl's offer doesn't work out, we'll have to look at some of the solutions that Antiniov offered. Thank you for the list of of suppliers, Antoniov!

And good call on the terminal emulator, Volker. That hadn't quite occured to me, although it actually solves a number of minor concerns that we had been thinking about, in the case of console failure.

As per John's question, I'm not sure if we have an IMAGE backup of our system disk. That could be a problem. However, we do have lots of data backup sitting around here, so I'll sort through them and try to get an answer to that question. We may very well have something.

Next week, I'm also going to switch out the UPS on the system also. It's been having some battery problems, and Robert may be onto something regarding the fluctuating power supply. I know that any rechargeable battery has only so many recharges before it goes dead. ALthough a UPS seems to be always charged, and doesn't have the same problems of charge/drain that normal rechargeable batteries have, I can only assume that ours might be on the fritz.

Anyhow, that's it for this week. I'm sure I'll be posting updates in the upcoming weeks as we get the machine restored or the data migrated.
jrd
Advisor

Re: Radiology Information System running OpenVMS is Dying

Robert,

It is very unlikely that the %SYSTEM_F_FULL condition is causing the Machine Checks. VMS should boot (with reduced functionality) even if the system disk is full.

Machine Checks are often memory or CPU errors; IO components can cause them as well. If your disk wasn't full, there's a good chance some useful information about the machine checks could be gleaned from the crash dump file and/or the error log file.
Daniel Fernandez Illan
Trusted Contributor

Re: Radiology Information System running OpenVMS is Dying

Robert.
Are you check banks of memory into microvax?
Some errors can be produced by a failure in hardware memory. Also I doesn't remember well error codes on MV3100, but i think that 84 FAIL indicates that Ethernet device is open.
You can probe to disconnet banks of memory and check startups.
Saludos.
Daniel.
Carl Couric
Occasional Advisor

Re: Radiology Information System running OpenVMS is Dying

Hi,

Use my old Email address carlc@iname.com, it will send you an email with my corrected email address :) .... I'm just happy to give one of the little guys (MV3100) a home.

Carl
comarow
Trusted Contributor

Re: Radiology Information System running OpenVMS is Dying

Can you boot to sysboot?

If so, can you boot minimum?

Maybe with the other system will come a bootable disk and you'll be able to do an image copy of the disk to another disk!

Bob