At 5:18 PM -0800 11/7/03, Mark Berryman wrote: >There are, indeed, a number of places in VMS that require an individual >I/O call to transfer less than 64KB of data. In fact, some system >routines still expect to receive (or return) such info in a WORD-sized >data structure (i.e. 16 bits). This happens to be the case with the >DECC socket routines. If you pass a buffer size of exactly 65536 bytes >to a socket, the WORD that the socket routine looks at will be zero and >it will write zero bytes. If, however, you were to pass a buffer size >of, say, 70000 bytes, the socket routine would write 4464 bytes (which >is the value of the low-order WORD of the 32-bit Integer 70000). > >In other words, you can use any size buffer you want. Just be aware >that the socket routines only look at 16 bits of the size parameter. (I >have not verified if this WORD-sized behaviour is limited to sockets or >to the send/write functions themselves).
The buffer size argument to write() is __size_t, which on VMS is an unsigned int. So any interface that accepts a 32-bit unsigned integer and is implemented via another interface that can only handle buffers sized by a 16-bit integer ought to, it seems to me, either return an error, limit itself to the maximum size it can handle, or possibly break up the operation into multiple pieces when it gets a size that's too big to be stored in 16 bits. In other words, if the C socket interface in the TCP/IP stack simply loses the high word of the size parameter when it turns around and calls SYS$QIO, that ain't good. I don't know for sure that this is what happens, but it's one possible explanation for problems people have described. None of this obviates the need to handle cases where only part of the requested write happens the first time around and you need to check how much was actually written and send the rest if necessary. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
