[RESOLVED] Best Practice: Converting text files from OpenVMS to Windows for editing and back again?

« Back to Previous Page
1
0

We were looking for a best practice for converting text files so they could be used and edited on OpenVMS and Windows. We took some suggestions from the OpenVMS Likedin Group and did a series of tests in our lab. At the end of our basic testing, we found DCL commands to be the most dependable way to convert files that need to be moved between OpenVMS and Windows. Here is what we found.

Zip solutions: Storing files into a zip archive and converting text files to DOS

zip "-rl" archive.zip input.dir

Unzip archive and convert DOS text files to VMS format

Note that the following command will only work if the archive has OpenVMS file attributes saved, which states that the files are text and not binary. Since modifying or creating a zip in Windows will remove the attributes, we found these commands are of limited use.

unzip "-a" archive.zip

DCL Solutions: Converting to OpenVMS format

SET FILE/ATTRIBUTE=(RFM=STM) input.txt CONVERT input.txt output.txt /FDL="RECORD; FORMAT STREAM_LF;"

Converting to Windows format

CONVERT input.txt output.txt /FDL="RECORD; FORMAT STREAM;"

In products like NXTware Remote these transformations and movement between platforms is handled automatically, but if one were to use a basic text editor on Windows to modify OpenVMS source code these commands could be of use when manually moving files between platforms.

RESOLVED
Posted by Peter Marquez (Questions: 1, Answers: 1)
Asked on January 23, 2015 11:00 am
Category: Best Practices
3150 views
0

Hi Peter,

Just curious if your tests included HP CIFS for OpenVMS (which can eliminate the need to transfer the files between hosts by allowing both Windows clients and the OpenVMS host access to the same files)? Or perhaps your aim was to provide transfer among systems that are not directly interconnected?

Posted by Paul (Questions: 0, Answers: 1)
Answered on January 23, 2015 11:34 am

Hi Paul,
Great point. Some background. We’re considering releasing free Standalone DCL Editor for Eclipse at eCube. The Standalone DCL Editor wouldn’t have any of the high-end features in NXTware Remote, which simplify working between OpenVMS and Windows for all types of languages. However, it would provide some cool benefits over a basic editor.

To your point: Those using (our Standalone DCL Editor with) HP CIFS would be able to move files transparently. No issue.

But for those not using CIFS or NXTware Remote we wanted to document a simple utility/best practice to handle converting the files.

(Peter Marquez at January 23, 2015 1:09 pm)
0

My only concern here is that the standard format for text files on OpenVMS is not Stream format which is what you have listed above. If the files are created on a Windows system and you wish to edit them on OpenVMS, the methodology stated will work just fine. If not, and the files are created on OpenVMS, the file format is likely to be record format with CR,LF terminators and either fixed or variable length.

Can you be more clear about the origin of the files. There are other commands that can be used for proper transfer of files.

Dan

Posted by Abrsvc (Questions: 0, Answers: 13)
Answered on February 20, 2015 8:33 pm

Dan,

You may have a point here. But we ran a test in our lab and this seemed to work for moving from OpenVMS to Windows. In most cases that is what folk will need to do when using the DCL editor.

CONVERT input.txt output.txt /FDL=”RECORD; FORMAT STREAM;”

We will retest and confirm.

(openvmstoday at February 21, 2015 8:05 am)

You are correct, converting the file to stream will make the transfer to Windows easier My only concern was the return trip as most files on OpenVMS are NOT stream. Any file created by DCL itself is usually VFC (variable length with fixed control) which is a completely different record format. The caution here is that some editors on the OpenVMS side can’t handle some record types easily. For example EDT (one of the most popular) can’t handle records larger than 256 bytes. It is important to retain the initial record type for conversion on the return trip as well.

(Abrsvc at February 21, 2015 8:39 am)
« Back to Previous Page