support for vms file versions
Downloading a file (sftp) from VMS(v8.4, TCPIPv5.7-ECO5), a version number is preserved in the windows filesystem. Everything else works fine, but this is ugly, you need to cut it before other use of the file on windows.
Support of VMS file versions would be easy, there is only a need to respect VMS principle of file versioning.
VMS filesystem stores multiple versions of files, they are numbered 1...32767.
Version number is delimited by a semicolon (i.e., "name.ext;3256").
You can specify version number to work with specific version of a file.
The version specification is required only for the file deletion, it can be omitted in all other cases.
If no version is specified, the behavior depends on file opening mode.
The last version of the file is open if the file is open for reading or reading and writing.
A new version of the file is created if the file is open for writing only or the file does not exist.
There are several "version wildcards", you can use them in any file specification:
;0 means the highest version number,
;-0 means the lowest version number,
;-1 (or generally ;-n) means previous version (or nth version before the highest),
;* means all versions.
To support file versions we need to be able to cut a version specification from the filename and to concatenate it when necessary.
There are several possible modes of operation:
1. Neutral OS mode - vms will be seen as all other systems - you will see the most recent file version only.
In communication to the server, ";0" is concatenated.
There is the only exception: ";*" needs to be concatenated in delete command(or ";0" - user can select).
Version is cut from all server responses, no version is displayed.
No change is required in download operation.
2. VMS mode - multiple versions on VMS, single version on windows.
Versions are preserved in server communication (both directions), versions are displayed.
Versions are cut in download operation.
3. VMS archive mode - multiple versions on both systems. It can be useful for archiving of VMS directory including all file versions.
Versions are preserved in server communication (both directions) and also in download operation (the current behavior).
For advanced use, we can specify four attributes independently on each other:
1. server attribute "version for directory operation" - string (max. 7 characters)
2. server attribute "version for delete operation" - string (max. 7 characters)
3. server attribute "cut versions from server response" - flag
4. download transfer attribute "cut versions in download" - flag
Neutral OS mode: ";0", ";*", yes, yes
VMS mode: "", "", no, yes
VMS archive mode: "", "", no, no
advanced mode settings:
";-1", "", no, yes or no: to work with previous versions
";-0", "", no, yes or no: to work with the oldest versions
";0", ";0", no, yes or no: to work with current versions, but not to affect older, see version
";0", ";0", yes, yes or no: to work with current versions, but not to affect older, don't see versions
etc.
If we add this small change, VMS community will be very happy.
I can help you to implement and test this functionality, I can provide a VMS system for testing, but I have no time to dig to sources and make my own build. If you are interested, please, let me known, we can arrange cooperation by email or phone.
Regards,
Jiri
Support of VMS file versions would be easy, there is only a need to respect VMS principle of file versioning.
VMS filesystem stores multiple versions of files, they are numbered 1...32767.
Version number is delimited by a semicolon (i.e., "name.ext;3256").
You can specify version number to work with specific version of a file.
The version specification is required only for the file deletion, it can be omitted in all other cases.
If no version is specified, the behavior depends on file opening mode.
The last version of the file is open if the file is open for reading or reading and writing.
A new version of the file is created if the file is open for writing only or the file does not exist.
There are several "version wildcards", you can use them in any file specification:
;0 means the highest version number,
;-0 means the lowest version number,
;-1 (or generally ;-n) means previous version (or nth version before the highest),
;* means all versions.
To support file versions we need to be able to cut a version specification from the filename and to concatenate it when necessary.
There are several possible modes of operation:
1. Neutral OS mode - vms will be seen as all other systems - you will see the most recent file version only.
In communication to the server, ";0" is concatenated.
There is the only exception: ";*" needs to be concatenated in delete command(or ";0" - user can select).
Version is cut from all server responses, no version is displayed.
No change is required in download operation.
2. VMS mode - multiple versions on VMS, single version on windows.
Versions are preserved in server communication (both directions), versions are displayed.
Versions are cut in download operation.
3. VMS archive mode - multiple versions on both systems. It can be useful for archiving of VMS directory including all file versions.
Versions are preserved in server communication (both directions) and also in download operation (the current behavior).
For advanced use, we can specify four attributes independently on each other:
1. server attribute "version for directory operation" - string (max. 7 characters)
2. server attribute "version for delete operation" - string (max. 7 characters)
3. server attribute "cut versions from server response" - flag
4. download transfer attribute "cut versions in download" - flag
Neutral OS mode: ";0", ";*", yes, yes
VMS mode: "", "", no, yes
VMS archive mode: "", "", no, no
advanced mode settings:
";-1", "", no, yes or no: to work with previous versions
";-0", "", no, yes or no: to work with the oldest versions
";0", ";0", no, yes or no: to work with current versions, but not to affect older, see version
";0", ";0", yes, yes or no: to work with current versions, but not to affect older, don't see versions
etc.
If we add this small change, VMS community will be very happy.
I can help you to implement and test this functionality, I can provide a VMS system for testing, but I have no time to dig to sources and make my own build. If you are interested, please, let me known, we can arrange cooperation by email or phone.
Regards,
Jiri
