TCPIP SS$_IVBUFLEN problem

[TedMaringer]

I have a program which uses SYS$QIO system services (IO$_WRITEVBLK and IO$_READVBLK) to
send TCPIP messages back and forth. The problem occurs when I try to increase the length of the message to more than 32767 bytes.
The IOSB status block returns the SS$_IVBUFLEN error code. What do I need to do to be able to increase the size of the message? Is this being limited by a process quota, system quota, or TCPIP parameter? I have not been able to find the correct parameter to change. I am running OpenVMS 7.3-1 on an Alpha ES40.

[Hein van den Heuvel]

It would not surprise me if that was simply the max. The receiver/sender will have to learn how to break up a message.

It might depend on the IP stack being used.
UCX? Multinet? ...

Finally it could be a programming error where a signed short is used to store / move the length arounf in which case anything over 32767 becomes negative.
Try unsigned!?

What language?

hth,
Hein.

[Hoff]

TCP connections are streams of data, and are not record-oriented transfers. This can lead to some quite confusing -- but correct behavior when the messages are delivered. This really gets weird when you're dropping "datagrams" into an unintialized buffer.

You can send a single TCP write I/O containing the buffer:

[This is my message]

and the receiver might encounter a sequence of reads such as the following:

[This][ ][is my mess][age]

Just toss what you need in how ever many messages you need, in other words. It's the receiver's job to re-package it all.

Prior to TCP/IP Services V5.5 (IIRC), the BG device I/O maximum transfer size limit is 64K, and further limited by the process BYTLM quota and the system MAXBUF parameter setting. Again, IIRC. But do remember that the TCP recipient (still) has to reassemble the "datagram" in any case.

Stephen Hoffman
HoffmanLabs

[TedMaringer]

I am using TCPIP Services for OpenVMS V5.3-04. One VMS program that sends and receives messages to another VMS program is written in Fortran. Another program that receives from the VMS program and also sends and receives from a Windows platform is written in C. The software is from a third party vendor which provided the source. It looks like that I will need to develop a strategy to break up the messages into parts in order to send a large amount of data. Thanks for your help.

[Hoff · Accepted solution]

Expect to receive those packet fragments, too.

This is a very common TCP coding mistake, and the errors -- when a packet arrives in fragments -- can be very obscure.

For additional details on this, you can find:
http://h71000.www7.hp.com/openvms/journal/v3/tcpip.html
has a brief discussion of this in its:
"TCP Data Transfer â Stream of Bytes"
section.

[Chris Wesling]

I've been having the same problem as the original poster. I'd already guessed that it might be related to the TCPIP version, because it occurs on a system that has VMS 7.3-2 and TCPIP 5.4, but not on a system that has VMS 8.2 and TCPIP 5.5. Thanks for confirming that, Hoff!

Question: can a VMS 7.3-2 system be upgraded with TCPIP 5.5? Or is the TCPIP version tied to the VMS version?

[Richard J Maher]

Hi,

Just to pick up on what Hoff was saying, ucx$c_msg_blockall is definitely your friend.

Also for an example of piecing messages together please see the CLIENT_RECV program in the attached COBOL source.

The message format convention has the first 2 bytes identifying the browser tab that contains the JavaScript "callback" function to process the response, and the next 4 bytes are the message length (followed by the actual message). The client_recv sub-program returns control until Tier3 has received at least a complete header (6 bytes) and then however many bytes were in the length.

If there is any residue in the buffer after processing the first message(common with event driven clients queueing up requests) then server-affinity is retained for the next request (Quite a nice optimization)

When a complete message is available the Process_Msg sub-program is called.

This is an example-in-progress as I'm working on something to demo our new SSO multi-tab multi-webpage Tier3Client Applet, and may have no relevance to what you are doing, but it does highlight the issues Hoff was discussing.

Cheers Richard Maher

[Hoff]

Per the published product documentation, both TCP/IP Services V5.5 and V5.6 minimally require OpenVMS Alpha V8.2.

OpenVMS Alpha V8.3 has been out for three years.

It's time to upgrade.

[Chris Wesling]

Yeah, I just found that requirement in the release notes for TCPIP 5.5. Rats.

Unfortunately, all our software clients are hospitals, so they tend to be very resistant to OS upgrades due to fear of messing up a working system. I think it was only within the last year or two that we got all of them up to VMS 7.3 or higher! So it sounds like I'll probably have to rewrite my code to break up the messages into 64K chunks, to allow use with TCPIP 5.4.

Is there some way my program can find out which version of TCPIP is currently installed? Then at least it wouldn't have to chunkify the messages unless it needs to. I haven't found anything in the documentation yet about finding the version number.

[David Jones_21]

The code should have been using a loop to begin with and assuming that WRITEVBLK only sent the number of bytes returned in the second word of the IOSB.

If you are using a regular ethernet for the network, the MTU will be 1500 bytes. The kernel is going to break up your 32K write into over 20 IP datagrams anyway, so you get diminishing returns with super-sized writes.

If you want to make it adaptive to the version, the only thing I can think of is to set the max write to 2GB in your loop and if you can an IVBUFLEN, set the max write to 32767 and treat as zero bytes written for that pass through the write loop. There is the complication that which part of the IOSB you check depends upon how many bytes you tried to write (use second longword if over 65K, second word otherwise).