Moving Folders from OpenVMS to Windows

[nipun_2]

Hello all,
We have OpenVMS 7.3-2. I would like to FTP some of the folders (containing scripts, texts, logs, data) onto my Windows Machine.

Typically I have done this for specific files.
This works fine.

However, I am not clear how the versions are treated on Windows. Is the latest version of a specific file kept while the lower versions get overwritten?

Also, is there a way I can get all the versions on my Windows machine. That would be really helpful ? If there are any softwares I can install on windows that can track VMS versions ? Please let me know.

Thanks in advance.

[Steven Schweda]

> I am not clear how the versions are treated
> on Windows. [...]

They aren't? So far as I know, Windows file
systems don't do versions. What happens on
Windows depends on what you do on Windows.

> Also, is there a way I can get all the
> versions on my Windows machine.

Zip version 2.32 (and probably earlier) has

-w store file version numbers

So you use it to could create a Zip archive
with multiple files like file.type;3,
file.type;2, file.type;1, but those names
might cause problems on a non-VMS destination
system.

Zip 3.0e (pre-release, "BETA") (or later)
also has:

-ww store file version numbers as ".nnn"

Using it, you'd get file names like
file.type.3, file.type.2, file.type.1, and so
on. Perhaps the UnZip program on your
Windows system could do something more useful
with names like those.

[Hein van den Heuvel]

I would probably just zip them up with the -w option:

$ zip -?
Copyright (c) 1990-2006 Info-ZIP -
Zip 2.32 (June 19th 2006).
:
-w append version number to stored name

This will confuse windows somewhat in the sense that you will not be able to drag and drop from the zip file onto an editor.
But you can drag it into a folder, or onto the desktop, and then toss it at an editor.

Zip will also deal with the variable length record thing automagically for you.

Of course any trivial script can readily rename the multiple versions into a standard of your own with the version in the name or type. For example, with perl on the windoze side you could use:

perl -e "foreach (<*>) {($n,$t,$v)=split /\.|;/; rename $_, qq(${n}_$v.$t)}"

That will change name.type;version to name_version.type

Same thing on the VMS side (don't!) would be:

perl -e "foreach (<*.*;*>) {($n,$t,$v)=split /\.|;/; rename $_, qq(${n}_$v.$t)}"

You need the ;* to make the perl glob function return version numbers.

hth,
Hein.

[Steve Underwood]

Some Windows FTP clients I have seen (old one from Procomm specifically, I seem to remember) knew about VMS versions and could rename the file with the version something like (filename_version.extension). A few different clients I currently have do file renaming, but do not see the versions when downloading.

Good luck

[John Gillings]

I've seen several Windows FTP clients which, by default, will create a file on Windows with the version number intact. For example "myfile.txt;1", "myfile.txt;2". Windows perceives this as files of types ".txt;1" and ".txt;2", which usually isn't very helpful. The clients sometimes have an option to strip off OpenVMS version numbers. You'll then get newer versions overwriting older versions.

The only way I know of to recognise version numbers on Windows is to manually RENAME files either on OpenVMS or Windows to resolve any potential name conflicts, or file type confusion.

(It's rather curious to me that other operating systems haven't copied/used the OpenVMS version concept in file names. It's such an obvious and useful idea)

[Willem Grooters]

It depends on the FTP tool used on Windows.
In general, what I've seen, is that if no version is mentioned, the latest version will be retrieved . Specifying a version will get that particular version. Completely consistent with the way VMS would do.
The naming on the Windows (or *x) side depends. It's fairly usual that the name speccified in GET is used:

GET file.ext ==> stored as "file.ext"
GET file.ext;vrs ==> stored as "file.ext;vrs"

For what I've seen, using a wildcard as version, this would follow the second rule, retrieving files in the same order as VMS commands would show them: in descending order of version number (highest first). but if your program would ignore this order and would overwrite the latest retrieved version, chnaces are you'll end up with the file with the lowest version number - usually the oldest file.

beware though that files on VMS containing multiple dots and 'escaped' characters on ODS-5 disks can not always be handled.

I concur with Steven: ZIPPING the files on VM using the -w option and transferring the file BINARY to any other platform would be a better and safer idea. If your files are plan ASCII to be processed on Windows or Unix (and not transferred back), the -l option is useful (ZIP -h will show you all the options)

[Colin Butcher]

You could use "SET FILE/VERSION_LIMIT=1" and "SET DIRECTORY/VERSION_LIMIT=1" to emulate inferior file system behaviour on OpenVMS for the directory trees. Then you wouldn't have to worry about the version numbering "problem".

I've seen it done. Confused me mightily.

Cheers, Colin (http://www.xdelta.co.uk).

[Willem Grooters]

@Colin:
You could indeed, but that would mean loss of logs (and other stored data) and I doubt that is appreciated :).

@nipun:
Though I cannot check - I don't have a Windows Server at hand - think about this:
If the windows environment is a WindowsServer (not a Workstation), it should be possible to PUT files and give it a name on Windows (PUT file.ext;vrs file.ext_vrs, for instance). You will ba able to control it from the VMS system where you have all facilities - on the commandline (so you can pass over files in batch).