Data Extraction from DEC Alpha OpenVMS to Desktop PC

[KSchrader]

Hello -

Not sure this is the correct place...something of a different forum layout here!

I'm looking for some suggestions on transferring information from an old DEC system to a desktop.  I have a DEC 2000 Alpha that was turned off probably 6 years ago once I had made the transition of programs and most files to the desktop PC. I'm pretty sure we were running OpenVMS at the time.  I have the idea that I would like to revive it for the sake of retrieving any valuable information that I may have left on it. I have DAT tapes but have no way of reading them other than to bring the system up. I suppose I could send the tapes off to be read, but there's sensitive information on the tapes.

Can anyone recommend a course of action? Should I just plug in power and turn it on? Could I remove the hard drive and attach it to a local server and communicate with it that way? I was never very good as the system administrator, but have instructions on the general boot process. I would work with our company IT department to make sure the connections are correct.

Thanks for any help...Kurt

[abrsvc]

There is no single or simple answer to this.  There are a number of variables:

1) What kind of data? Programs or actual data?

2) What format for the data?  Indexed files or flat files?  Stream, fixed length records, variable length records?

3) How much data?  Would it make sense to create a socket based transfer program or perhaps just FTP the data files directly?

4) How confident are you that the system will boot?  Is the relevenat data on the actual drives of the system or only on tape?

5) What format is the tape?  Was it created with COPY or BACKUP? Is it a saveset of data or an entire disk backup?

As you can see, there are many questions that need to be answered to provide you with a reasonable response.

There are a number of us here in this forum that provide services to assist with this type of request (myself included).  Let us know where you are and try to provide additional details so we can post more detailed guidance.

Dan

[H.Becker]

>>> Could I remove the hard drive and attach it to a local server and communicate with it that way?

It depends on the server. If it runs or can run Linux you very likely can get the ods5 kernel module and just mount the plugged in disk, readonly. Then you can use Linux tools to copy the data as is or you can use the tool provided with the kernel modul which can get to and interpret the file attributes of all the common VMS file organizations for the copy operation.

[KSchrader]

Dan -

Thanks...I'll see if I can answer your questions.

1) What kind of data? Programs or actual data?

Most likely I'm after just data.  The data is flight data recorded from military aircraft from some projects I worked on.  I know that the VAX binary format was different than the PC format.  Any programs I had used in the past contained byte-swap routines, swapping the higher and lower order bytes coming from and going to the file.  If I could recover the data, I'd do the byte swap one last time, and save the file out to a tab-delimited ASCII  file.  Then it would be useful in existing programs that handle this kind of data.

2) What format for the data?  Indexed files or flat files?  Stream, fixed length records, variable length records?

The flight files should be individual for each separate flight.  They would be fixed format as I recall.

3) How much data?  Would it make sense to create a socket based transfer program or perhaps just FTP the data files directly?

I used to have an FTP program where I could copy files back and forth...but that was several versions of Windows ago.  Not sure of the amount of data...I know there were several military programs that had flight data that I was hoping to get back to.

4) How confident are you that the system will boot? Is the relevenat data on the actual drives of the system or only on tape?

I have no idea if it will boot.  If it doesn't then I move on...the data is not critical...just would be nice to have it back.  If the system would boot, I'm trying to figure what's the best approach...leave the system as is or pull the hard drive and connect to another network.  The problem is that if I leave it in the current system, I think there might be problems/restrictions from "allowing" this device to be connected to a larger network.  Any of the older ethernet approaches probably won't work.  Not sure about this...kind of over my head.

5) What format is the tape?  Was it created with COPY or BACKUP? Is it a saveset of data or an entire disk backup?

The tapes would be in backup format...probably saveset of the entire disk at that point in time.  What's currently on the drive would be the latest and greatest, so my first choice would be to go for that.

I also have data (savesets most likely) on TK50s from an older DEC 11/23...I think.  I'm still looking for hardware internally here at work to see if we can mount those and recover.  Different problem of course!

Thanks...Kurt

[KSchrader]

"It depends on the server. If it runs or can run Linux you very likely can get the ods5 kernel module and just mount the plugged in disk, readonly. Then you can use Linux tools to copy the data as is or you can use the tool provided with the kernel modul which can get to and interpret the file attributes of all the common VMS file organizations for the copy operation."

Thanks...I'll pass that on.  The DEC drive would need to be booted using the appropriate commands I would think.  I think it would come up in Sys Admin mode.  I wonder if I could still "see" the DEC drive and move files around.  Again, I'm not very hardware/system savvy.

Kurt

[abrsvc]

Kurt,

I have a VAX and a few Alpha machines with various tape types as well as hard drives. With the appropriate non-disclosure agreements, I can recover the files for you most likely on one way or another. Also, we may be able to setup a secure VPN to transfer the files directly to you from me or a disk or tape can be created for the Windows box. There are many options here. I am sure that others can offer the same services as well. This is not a lost cause. Many of us should be able to assist.

Let us know.

Dan

[Hoff]

Note: Some replies were posted into this thread while I was composing this.

If you haven't looked at the data here in six years, what are the chances that you'll ever look at it?  

Put another way - and without intending offense - why bother?

Reading an VMS disk on a VMS system is easier than on another platform, and a user or a programmer can then utilize the VMS tools and libraries to process the data. 

To use your "desktop PC" here, you'd need add-on software for Windows, Linux or OS X access to a VMS-format disk and its volume structures, and then you'd need to sort out what the particular file contents might be.  With a foreign platform accessing the volume structure, you're effectively looking directly at database files, and potentially without the assistance of or benefit of the associated database software; of RMS or whatever application or database was used for the particular files.  And then you'll need to sort out what the application was doing and what the format of the data might be, where that task can be easier directly on VMS.

In addition to the file system and tools, connecting the disk to Windows, Linux or OS X also means access to an older SCSI device on the target platform, which means you'll need a SCSI controller and cabling and adapters.  

It is possible to read VMS-format BACKUP savesets and probably also BACKUP tapes on arbitrary boxes, using a tool known as vmsbackup.  

Unfortunately for recovering data, DAT/DDS tape media and the tape devices aren't known for their longevity, nor their reliability.  They're cheap tapes, and with all that pricing entails.  I've had those tapes fail within a week of use, much less six years.

In general, the easiest way to recover or investigate the data here is to boot the VMS box and have a look around, and possibly create a new set of tapes on more reliable media.  If the box still boots, of course; that's an old box, and it's been idle for a long time.  It's almost certain that the BB_WATCH battery will be drained, so the box will likely prompt for time, for instance.  And whether the disk still works is an open question.  You'll likely have to break into the box, as the SYSTEM password has probably been forgotten.

If the box boots, then it's feasible to investigate further, and potentially migrate the data.  

But given that there was probably already a migration (apparently to Windows), and given that the box hasn't been booted and used in enough time that it's not entirely certain whether the DEC 3000 box was even running VMS, then there's not likely anything of value on the box.  

I don't see the point of the effort here.  Not unless you have something you need off the box.  

And there are easier ways to enjoy some operating system nostalgia, if that's your goal.

Erase the disks (on the off chance there's old sensitive data left on the disks), and send the box for salvage.

[KSchrader]

"If you haven't looked at the data here in six years, what are the chances that you'll ever look at it? 

Put another way - and without intending offense - why bother?"

True that, but in my business, having archival data for some older usage of a USAF aircraft or even an allied military could come in handy at some point.  Small chances, but possible.

I'm basically assessing the "pain" involved in doing this.  Then I'll make a decision.

Given the sensitive nature of this and International Trade Agreements and Restrictions, keeping this as in-house as I can will probably be the easiest way to go.  Haven't had to cross that bridge yet!

Thanks for the thoughts...Kurt

[H.Becker]

>>> The DEC drive would need to be booted using the appropriate commands I would think.  I think it would come up in Sys Admin mode.  I wonder if I could still "see" the DEC drive and move files around.

Once you have the drive connected to the Linux server and the kernel module loaded, the system admin, aka root, can mount the VMS filesystem (no matter if it is ODS-2 or ODS-5) to a directory in the Linux filesystem tree so that you can access the files (or root can set it up so that you can mount it). You can see and copy the VMS files just as any other file on the Linux box. The drive can only be mounted as readonly. You can copy files, but you can't move them as with the mv command. You may need to copy them according to their VMS/RMS file organization and file attributes. But that's covered by a tool which comes with the kernel module.

As pointed out by others, there are many options. You may want to make a disk image from the drive. That can be mounted by Linux and the kernel module as well. You may have a VM on your Windows server/PC where you can run Linux. Or you can use the disk image with an Alpha emulator on your Windows server/PC either as a system or data device.

[Eberhard Heuser]

Are your allowed to send the tapes to someone who has a DAT-drive to see if it is readable?

I have here all you possibly need:

DEC Alpha, SCSI-DAT-drive.

Eberhard

[abrsvc]

Kurt,

One other option is to make use of "local" hardware. Where Are you located? Perhaps some of us are local?

Dan

[KSchrader]

San Antonio.

[KSchrader]

It lives!  I had my IT department work with the machine and after several tries, it came up to the System Admin login screen.  A bit of fumbling to find the old password, and we were able to login.  They gave it an IP address and I'm working to connection via FTP to begin transferring files.

These things are tough...I believe the system was off for around 5 years.

Thanks...Kurt