Michael Downey wrote: > Maybe you are missing what the initial problem is with VMS. You can not > write a buffer that is > 64K to a socket. If you try the socket will fail > to send ANY data, I even think there was a crash bug in the code that's > likely been fixed. So your above example would have to be even more > complicated. Basically you'd have to encorperate my example and your > example together to get the bullet proof code.
It may appear that way but if you dig into it you will find that it isn't really. Here is what happens: 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). > As far as I can tell you should only need to use your checks if you set the > socket into a non-blocking state. Nope. For proper stream-based programming, such checks are always necessary. Mark Berryman
