| Title: | File Transfer Spooler for VMS |
| Moderator: | ANNECY::BENDRIS |
| Created: | Mon Dec 12 1994 |
| Last Modified: | Sat May 24 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 86 |
| Total number of notes: | 232 |
Maybe this is addressed in the documentation, but I can't find it. The issue is close to the discussion in note 3, but not exactly. Suppose you have an ordinary text file on VMS, a file of variable length records. You do a spool copy to UNIX or NT. FTSV copies the file in block mode, so the record count words are transmitted to UNIX or NT, and the resulting file unusable on UNIX or NT. FAL on UNIX and on NT does understand variable length format, so it's legal to create the file, but FAL can only write the file correctly when the data is transmitted as record at a time. The FALs will take such data and write it locally in stream_lf format for UNIX and stream format for NT. Thus, the problem is avoided in SPOOL by doing COPY /TRANSFER_MODE=RECORD. Here's my problem. I maintain FAL on NT. Right now, FAL allows the user to open a file in block mode, specifying variable length format. I allow this because the default case of VMS COPY to NT will transfer the file correctly in record mode. The VMS user who enters EXC/NET/TRANS=BLOCK to copy the variable length file to NT is entering explicit commands. I figure that either that user knows what he's doing, or he deserves to get his data trashed. But FTSV will copy the file to NT in block mode by default, so the casual user finds the file appears to be garbage on NT. Should I alter FAL to refuse block I/O for variable length format? But then, suppose there's a VMS hacker who backs up his variable length files to NT, and restores their integrity when he copies them back: $ exc/net/trans=block foo.txt ntnode:: $ create varcc.fdl RECORD CARRIAGE_CONTROL carriage_return FORMAT variable $eod $ ext/net/trans=block/convert=varcc.fdl ntnode::*.txt *.* The user does not care that the file is hash on NT. He just wants to store his data on a big disk somewhere, so he can get it back on VMS later if the VMS disk dies. This is unconventional, but it produces valid results at present. If I forbid block I/O to variable length files in NT FAL, the above sequence will no longer work. So, I don't think I can change NT FAL. Should FTSV automatically do record mode transfers to dissimilar operating systems like COPY does? If not, should the documentation at least talk about this issue? (Or maybe it does, and I haven't spotted it.) thanks, -Steve
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 83.1 | More information on copy with non VMS systems | BALZAC::MARKOWSKI | Mon Mar 03 1997 16:03 | 24 | |
Hello Steve,
It would not be correct to alter the behaviour of the FAL as it
must allow to copy either in block mode or in record mode.
We have to specify the way FTSV handles copy of files with non
VMS systems (FTSV option /TRANFERT_MODE).
This information will be given in a specific note in this
notesfile because the modification of the official documentation
of FTSV will require the whole product to be submitted to the
ESSB process and it won't be available before a certain delay.
We don't feel any urgency to modify the SPOOL COPY command to
match the VMS COPY command because the functionality exists
with the /TRANFERT_MODE option, as you have mentioned it, and
because it would be a quite heavy modification. Last, there is
another product, called FTSO, that lets the users to manage copy
of files with a large range of systems (OpenVMS and non OpenVMS).
Kind regards,
sylviane.
| |||||
| 83.2 | JAMIN::RUZICH | PATHWORKS Client Engineering | Tue Mar 04 1997 21:56 | 38 | |
Sylviane,
.1> It would not be correct to alter the behaviour of the FAL as it
.1> must allow to copy either in block mode or in record mode.
I agree, so it's a documentation issue for you in the short run.
.1> We don't feel any urgency to modify the SPOOL COPY command to
.1> match the VMS COPY command because the functionality exists
.1> with the /TRANFERT_MODE option, as you have mentioned it, and
.1> because it would be a quite heavy modification.
Yes, I understand.
Also, if you are thinking about implementing the VMS COPY functionality in
FTSV, consider this: I don't think that VMS did it right. VMS COPY will convert
a file to a stream or stream_lf format if the remote operating system is one it
knows to have some sort of stream file system. However, if you have a variable
length file and you copy it in record mode, the remote FAL is very likely to
accept variable length format, because it is a very simple format to implement
in FAL. All the FAL implementations I've dealt with all understand variable
length via DECnet, though the read and write files on disk using their local
format. So, I don't think that VMS's conversion to stream is necessary.
For FTSV, I would suggest a different algorithm:
o If the remote operating system is not an RMS-based file system, use record
mode but don't convert the record format.
o If the record format is rejected, convert to variable length and try again
(because variable is the most generic format).
Of course, you want to minimize the amount of code in FTSV which works
differently for different remote operating systems, because you can't anticipate
all the cases. There are non-Digital FAL implementations out there, and unusual
Digital FALs, like one on an IBM gateway product.
Regards,
-Steve
| |||||
| 83.3 | Thank's for suggestions | BALZAC::MARKOWSKI | Wed Mar 05 1997 16:55 | 8 | |
Hello Steve,
Thank's for your interest and your suggestions.
Kind regards,
sylviane.
| |||||