[Linux-decnet-user] fal problems

[Larry B. <ba...@us...>]

I've run into some problems using linux-decnet fal with OpenVMS BACKUP:

1. I set up linux-decnet to start fal with the -m option (create/read =
record attribute metafiles in a .fal subdirectory).  It is not reliable. =
 I have files that were created by fal, but there is no corresponding =
metafile entry.  I changed the fal startup to use -ae.

I'd like to see the metafile format documented (on the fal man page?).  =
Better yet, I'd like fal to use an .fdl metafile directory with ASCII =
.fdl files that conform to the OpenVMS FDL specification.  (This is the =
way Process Software's MultiNet NFS client stores OpenVMS file =
attributes.)  That way, I can change the file attributes with a text =
editor, if necessary.

2. fal does not negotiate the buffer size like OpenVMS FAL does.  =
Sometimes remote BACKUP operations work; other times they do not.  I had =
to use SET RMS_DEFAULT /NETWORK_BLOCK_COUNT=3D64 on OpenVMS to eliminate =
the failures ("%BACKUP-E-READERRS, excessive error rate reading ...").

3. fal appears to limit the file size to 2 GB.  (This may also be true =
of OpenVMS FAL as well; I don't know.)  The reason I installed =
linux-decnet was to use my Linux system as an online repository for =
OpenVMS BACKUP save sets.  I originally tried to use NFS, but the TCP/IP =
package on our OpenVMS systems only supports NFS version 2 =
clients/servers, which limits file sizes to 2 GB.  It appears =
linux-decnet's fal has the same limitation (because of the DAP =
protocol?).  If this is truly a restriction of the DAP protocol, that's =
a killer for us -- we won't be able to use linux-decnet.

Comments?  Suggestions?

Larry Baker
US Geological Survey