C flushing/closing a decnet file created using creat w/ "fop=sqo"

[Tom Musson]

Hi all,

I'm using C (HP C V7.1-015 on OpenVMS Alpha V7.3-2) to create a file that can be on a remote node. I use the creat routine with the "fop=sqo" option. Problem is that when the file is remote (::) I get an exception attempting to fsync, fflush, or close the file. When the program exits, I get an empty file.

The exception is:

%rms-f-ftm, network file transfer mode precludes operation (sqo set)

...which seems fairly obvious for the fsync and fflush, but I get this on the close as well.

This only happens if the target file includes a decnet node name.

I've attached my example.

Same results on:

HP C V7.2-001 on OpenVMS IA64 V8.3
HP C V7.3-009 on OpenVMS Alpha V8.3

Any ideas?

Thanks,

Tom

[Steven Schweda]

"Doctor, it hurts when I do this."

"Don't do that."


HELP /MESSAGE FTM

[Hoff]

"FAB$V_SQO
Local File Accesses

Sequential only; indicates that the file can be processed only in a sequential manner, permitting certain processing optimizations. Any attempt to perform random access results in an error. This option is restricted to sequential files and is ignored for all other file organizations. The FAB$V_SQO option is input to the Create and Open services.

Remote DECnet Accesses

For OpenVMS DECnet operations, this option has an added meaning. When set for a remote file access, it indicates that file transfer mode (FTM) should be used for Get, Put, Read, and Write services. File transfer mode is a Data Access Protocol (DAP) feature that allows several records to be transferred in a single-network I/O operation to maximize throughput for sequential access file transfers.

While the file transfer mode (FTM) feature for the SQO option is applied regardless of file organization to remote accesses, FTM has restrictions to make it consistent with the sequential only meaning applied to local accesses. For a remote file access, FTM is restricted to sequential access; if FTM is requested (FAB$V_SQO option set), a keyed or RFA record access will fail with an RMS-F-FTM error (network file transfer mode precludes operation (SQO set)). For record I/O, FTM is also restricted to Gets or Puts; Updates or Deletes, if attempted, will fail with the RMS-F-FTM error.

The transmitting of records as a block of data, of course, results in performance improvement; what is not as obvious is that some of the improvement is due to the fact that the Data Access Protocol (DAP) eliminates much of its messaging for the FTM feature. Messages are not sent between the local and remote systems on a record-by-record basis but rather for the whole block of records transferred. This can result in apparent inconsistencies in what a reader sees when FTM is used.

While the RMS default locking behavior does not change when FTM is used, by the time the record is in your buffer on the local system, the record may have already been updated or deleted by another process that is not using FTM. If a locking collision happens on the remote system when the records are being loaded into the message buffer, then the locking error will not be returned until the end of the transfer. When using the file transfer mode (SQO) feature with shared write access to a remote file, you should expect to see the same kind of inconsistencies in reading data as you see when the read-regardless (RRL) option is set. To avoid the possibility of a hang that may be induced by retrying remote accesses after a record lock error, you are advised to set both the no-lock (NLK) and read-regardless (RRL) options in the RAB$L_ROP in applications that use the file transfer mode (SQO) feature for remote file accesses. (The no query locking (NQL) option is not supported by the DAP protocol for remote files.)

This option corresponds to the FDL attribute FILE SEQUENTIAL_ONLY."

[Hein van den Heuvel · Accepted solution]

>> %rms-f-ftm, network file transfer mode precludes operation (sqo set)

...which seems fairly obvious for the fsync and fflush, but I get this on the close as well.

Hmmm, it is not obvious at all to me why that error would be ok on flush, but not on close as close implies a flush.

But the error actual occurs on the WRITE, not the flush. The error is hidden/postponed due to the excessively large buffer the program requests.
Try the test with a large file !

Or... change the MBC to 1 recompile and try.

So what's happening is that for the Unix IO function the C RTL is doing it's own buffering, but still using the RMS controls to size those buffers. As the buffer fills, a write is attempted. If the buffer does not fill, then the write only happens on the flush/close.

I can not verify just now, but this could still be an C RTL bug of sorts. Maybe it sets the VBN for the output write, which is disallowed with SQO requested. SYS$WRITE calls are permitted for SQO, but only as a 'write next'.

This info should make you reconsider the value of SQO for this usage though! It is great for record-oriented IO, but this program does not do that. It will buffer up record oriented IO, but the C-RTL already does that!

Please also reconsider the MBF=16.
That's just silly. It makes this program allocate 1MB total buffer space for input and output. For small files that's pointless.
For large files it dirties more memory, but does generally really not buy you anything.

Have you experimented with MBF at all, or just using the 'more is better' simple-think?
I found quickly diminshing incremental improvements after 3 buffers and would recommend 4 - 8 at the most.
I found NEGATIVE improvement for more than 20 buffers... due to increased CPU time for certain test.

The MBC=127 is odd. Some storage setups prefer multiples of 4, and the XFC layer prefer multiples of 16: try 112?

Finally, when tweaking Decnet file IO, be sure to set the FAL$LOG logical to 7 or 17 for a few tests and review NETSERVER.LOG.
I this case you would have seen that the write was refused on the client side. The request never made it accross the wire.

Hope this helps,
Hein van den Heuvel
HvdH Performance Consulting

[Tom Musson]

Steven, Hoff - I read both of those references before I entered the question in the forum, however, neither of them suggest that you cannot close a file once created using the fop=sqo option, nor that data written to such a file will not be flushed by RMS.

Hien - Thanks for all the information. While my little test program does not do much of significance, the application I wrote/support can be configured to write anything from nothing to millions of records per hour. Unfortunately, the code has no way to know which it is going to be and it can change continuously.

I was shooting for maximal performance at the high-end and neglected the low-end.

I will do some testing using the information you provided. Thanks!

Closing this thread/assigning points.

[Tom Musson]

Thanks

[Steven Schweda]

It'd be more effort, but I'd guess that you
could specify an access callback function for
the creat/open operation, and in that, look
at the NAM block (or somewhere) to see if the
file is DECnet remote, and then set SQO only
where it'd work.

SQO does such nice things when allocating a
large (local) file (when highwater marking is
enabled), that it'd be a pity to lose it in
the situations when it'd work.

[Hoff]

If you want maximum I/O speed, the C RTL probably isn't your best choice.

Yes, you can get good speed that way, but it's real work to get there -- the C standard library first and foremost provides C and Unix compatibility. You end up shutting off all of the C RTL I/O processing, by and large, and will likely still occasionally find yourself in a tussle with the C RTL.

The C RTL is an excellent choice for C applications and for non-performance-critical I/O work. But if I wanted or needed I/O speed, I'd use RMS or $qio directly.

Direct RMS is pretty easy to code from C given some examples, and I've posted some examples over in the SRH_EXAMPLES and HOFFMAN_EXAMPLES directories on various Freeware. Better still, you have full and direct control over the buffers and related traffic, and the SQO option and related.