Export VMS 6.1 RMS files to WINDOWS

[Joe Bozen]

We are starting to look at exporting our RMS files off our old legacy systems. Our VMS system run running on an WINDOWS system using a product called CHARON. It's been about 6 years for me working on VMS so things are a little blurry for me. Anyway, what I'd like to do is take my RMS files that are stored on my VMS system and get those to a WINDOWS machine where I hope to then IMPORT those tables into an Oracle database. I was hoping to get some ideas/options from all you experts out there. Is this something I can do with just the O/S or do I need to use some other software. I can write a COBOL program to flatten the files out to an ASCII file but I'd rather use some tool set that can make this process go much faster. I have around 200+ files that would need to be converted.

I did try to just FTP my RMS files to my windows client but the files come over all screwed up.

Thanks,

joe...

[atul sardana]

Joe ,

Are you tried FTP with ascii or binary fromat.

use it as per your file type.

ftp>bin (for binary files)
ftp>ascii (for text/ascii format files)

then mget or mput...

Atul sardana

[Hein van den Heuvel]

You can FTP your RMS files to Windows IF-AND-ONLY-IF they are strictly FIXED COLUMN, ASCII, data files.

In that case you would not need to 'do' anything on the VMS side, just transfer in ASCII, not binary, mode.

You MIGHT want to perform a simple convert to stream file on VMS from those INDEXED (?!)rms files to sequential files before FTP, in which case a binary transfer is acceptable.

$CREATE STREAM.FDL
FILE; ORGANIZATION SEQUENTIAL
RECORD; FORMAT STREAM
$
$CONVERT/STAT/FDL=STREAM file.indexed file.txt

You could do that in a loop in a script and than may want to ZIP up those text files on the VMS side to be able to do a single (or a few) FTPs.

You'd still need to explain to Oracle exactly where the columns are in the text files.

If there are numbers in the files, much more care it needed, and this project might just turn into 'work'. Yikes :-)

If you go the Cobol route, which is not a bad idea, then you may choose to output the text in a CSV format and format those numners 'just so' to make them easily palatable to an Oracle IMPORT definition.

If you've never done any of this, then you may want to consider professional support.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Hoff]

I'd tend to downplay FTP for the time being, that's an issue that can be dealt with later along in the whole coexistence and migration process. This isn't to say that FTP isn't a key step here, it's just that there are a couple of rather larger issues to deal with and -- if you get those issues dealt with correctly -- the FTP capabilities simply tend to fall out of the solution.

Ok... For moderate to large volumes of data or for moderate to complex organizations, I'd create a tool to export to a stream LF file containing XML-structured data. There are libxml2 libraries available for OpenVMS, and most environments can often import and export XML-structured data directly.

You can potentially use libxml2 to assist with the XML processing, or just have your COBOL code generate XML rather more directly. A port of libxml2 is available via the OpenVMS Freeware, and writing XML is little more than structuring your program output, and running some available verification tools such as xmllint.

XML gives you the ability to structure your data so that more generic tools and APIs -- whether on Windows, Linux, Mac OS X, HP-UX or OpenVMS -- can read and process and write it.

There's no generic export conversion tool around, due to the arbitrary and free-form (and untagged) nature of what can be freely stored in an RMS file. Beyond the key structures for indexed files and such, OpenVMS and RMS have no idea what data is stored in the file. These record-level structural details are entirely an application-level consideration. (If your files are entirely text, with no embedded binary data, then there are generic options potentially available.)

The conversion tool will want to generate stream LF or stream-format files for easy transport across platforms, and for easier interpretation.

The other approach is a distributed environment using ODBC or similar database connectors, and configuring Windows, Linux and OpenVMS to operate in a distributed environment. This would allow you to continue to use your present environment, and to gradually migrate your environment over to HP-UX, Linux, Mac OS X or Windows; to whatever your chosen target platform is.

I've posted up a couple of migration topics and some related comments a while back, at:

http://64.223.189.234/node/225 (off OpenVMS)
http://64.223.189.234/node/226 (to Integrity)

Stephen Hoffman
HoffmanLabs.com

[Phil.Howell]

another option...
There are various "odbc" drivers available for rms files on vms, I have used connx
see http://www.connx.com/products/rms.html

the steps are:
install software on vms and windows
create connx data dictionary
create odbc data source
connect to data source and get data

The connx data dictionary can be loaded from cdd record definitions or cobol record layout

Does your data include any vms-style dates or packed-decimal fields?

Phil