Operating System - OpenVMS
1819804 Members
2898 Online
109607 Solutions
New Discussion юеВ

Data Extraction from legacy system

 
Microvax 3100-80
New Member

Data Extraction from legacy system

i am new to microvax 3100-80 server. in our company this legacy system was used long back. now i want to extract the data stored in this server in a text file. the application is written in Cobol. my problems are

when i start the system, it says password has expired contact system administrator.

fortunately i was able to remove the tape from TZ30 drive, is it possible to connect this tape drive to any normal pc and extract the data. if not how can i solve the password expiration problem.

any tiny help would say my days guys.
4 REPLIES 4
Karl Rohwedder
Honored Contributor

Re: Data Extraction from legacy system

I have never seen a PC with a TZ30 connected to it (but who knows?), but beside the technical/driver problems, if the tape is written with VMS backup, you would need a program on the PC to understand this.

I would go the VMS way and solve the password problem. Seen the OpenVMS FAQ here:
http://hoffmanlabs.org/vmsfaq/vmsfaq.html
which contains a chapter about forgotten passwords (chapter 5.6)

regards Kalle
Hoff
Honored Contributor

Re: Data Extraction from legacy system

The OpenVMS FAQ has the break-in procedure; the sequence for getting into OpenVMS if you do not know the password to the SYSTEM username or that of any other privileged username.

What I would do here is forget about using the Windows box right now, and would extract the data using OpenVMS tools and mechanisms. This from experience using OpenVMS, Windows, Linux, Mac OS X, Tru64 UNIX, RSX-11M/M+ and a gazillion other platforms over the years. If the box boots and runs, it will almost always be massively easier to prepare for the export on OpenVMS, using the application and the tools available there. (Anything else is dealing with data archeology, and dealing with the low-level file system, and with the code. Been there, done that, earned the scars.)

What many folks don't realize here: even sequential files can and do have low-level format differences. It is almost certain that the OpenVMS box is using a format that the Windows box won't deal with directly. (OpenVMS can be asked to use formats which are compatible, but most applications will tend to default to other formats.) OpenVMS can also include binary data in the records, and can use file and record structures formats that Windows can only access with moderate or substantial local application coding effort. OpenVMS deals with all this for you, which means you can control the export, and can use constructions that Windows and Windows applications can deal with.

Here, I'd likely look to do some work on the OpenVMS box to export to a stream or stream LF, or to export the data into XML. Exporting into XML is a bit more work, but it means most applications can then immediately access it -- and the application on OpenVMS is the only piece that has the data definitions right now.

The TZ30 DLT drive should work on most any other system with a SCSI connection. It's an old first-generation DLT drive and is the half-height equivalent of the TK50 and TZK50 drive. You'll need to scrounge up media for it, and you probably won't be able to read DLT media this old in a newer-generation DLT drive. (And then there are file organization and record structure issues...)

The out-of-left-field option here is to use one of the available VAX emulators, and to continue running OpenVMS VAX and your applications directly within your Windows system. It's quite feasible to import and export files from the two environments, meaning you can avoid having to deal with the application and the data port for a while.

Stephen Hoffman
HoffmanLabs
Doug Phillips
Trusted Contributor

Re: Data Extraction from legacy system

Do you know that anything useful is actually on the tape, or how it's even formatted? Forget it unless all else fails. Read the FAQ and log into the system first.

Extracting the data to a useful text file requires that you understand how the data is stored, the format of each data record, and the relationship between data files or structure of the data base.

The fact that the application was written in Cobol is only meaningful if you have the source and can find the record and field def's and file relationships. The language really doesn't matter to the system.

Understanding the platform does matter. How are you going to get the data off of the system? You won't know what tools you have to work with until you can log into the system and then, know what to look for.

If the data is valuable, and you don't understand RMS and VMS, you would be time and money ahead to find someone with that knowledge and pay a little for their help.

Been on both sides of the issue --- not gazillions of times, but dozens for sure ;-)
Robert Gezelter
Honored Contributor

Re: Data Extraction from legacy system

Microvax 3100-80,

The procedure to get into a system where you have physical console access is described in the system management manual, and in the FAQ. (I have done it so many times for clients.)

Personally, if I were doing this, I would look deeper into the problem than presuming that I should move the data off onto a tape and move it to the PC. Without understanding the application, it is not wise to guess at the format of the data.

I would examine the data, and then consider the question of whether the application needs to:
- remain in place
- run under the Charon (or similar) emulator on a WinTel/Linux platform
- or can be migrated to a PC platform.

As to how to move the data, there are lots of options. Using tape might be problematical, for reasons of formatting. Personally, I have often used C-Kermit (http://www.columbia.edu/kermit ) to transfer the files over a serial or LAN connection. It depends on what is available in your hardware configuaration.

If the data is important, it may be a wise step to retain an experienced consultant (disclosure: we have assisted clients with similar situations) to discuss the issues and possibilities with you and your colleagues.

- Bob Gezelter, http://www.rlgsc.com