At 12:07 PM -0700 11/5/03, Michael Downey wrote: >"Carl Braesicke" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >This script fragment hangs on OpenVMS until I trim "piece.out" below 64K >bytes; the same code works fine on a linux box with an untrimmed >"piece.out": > >Is there a 64K limit in the OpenVMS socket support? > >Regards, > >Carl B., x2796 > > >Yes, there is a 64K limit on socket writes on VMS at least when VMS 7.3 came >out. Both writev and write to a socket can only accept a 64K message. I >believe that the perl abstraction layer should handle this but since your >seeing this problem it likely isn't and would need to be fixed.
I've done a bit of digging on this issue, and it looks to me like there are plenty of bad assumptions to go around. Perhaps TCP/IP services should provide a way to send packets larger than 64K, though I'm not sure if that's even possible using a QIO interface (upon which the CRTL socket interface is clearly based) since the spot where it writes the number of bytes transferred in the IOSB is a 16-bit word. It is hard to find where, if anywhere, the 64K limit for sockets is documented. Even on linux or other operating systems, the maximum buffer sizes are not guaranteed to be greater than 64K and are generally tuneable by the system manager. So unless you control all the pieces, including networking hardware, you can't assume very large packets won't cause problems. IO::Socket should probably check the maximum chunk it can send and return an error if it's passed something too large. Net::MySQL should probably not assume that an entire query will be sent as one packet, though the same assumption may exist on the server side. The application should definitely not assume that it can suck an entire file into memory and send it to the database in one insert statement. Even if you manage to lift the 64K limit, you may eventually run into a 256K or 1MB or whatever limit. Pretty trivial changes to the script could do the inserts in more manageable pieces, say 1000 rows at a time. This is by far the easiest thing to change and should be done regardless of whether changes are possible in the underlying layers. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
