- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- TCPIP SS$_IVBUFLEN problem
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2007 06:13 AM
тАО03-19-2007 06:13 AM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2007 06:32 AM
тАО03-19-2007 06:32 AM
Re: TCPIP SS$_IVBUFLEN problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2007 06:44 AM
тАО03-19-2007 06:44 AM
Re: TCPIP SS$_IVBUFLEN problem
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2007 07:38 AM
тАО03-19-2007 07:38 AM
Re: TCPIP SS$_IVBUFLEN problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2007 08:42 AM
тАО03-19-2007 08:42 AM
SolutionThis 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2009 02:12 PM
тАО08-11-2009 02:12 PM
Re: TCPIP SS$_IVBUFLEN problem
Question: can a VMS 7.3-2 system be upgraded with TCPIP 5.5? Or is the TCPIP version tied to the VMS version?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2009 03:35 PM
тАО08-11-2009 03:35 PM
Re: TCPIP SS$_IVBUFLEN problem
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2009 03:35 PM
тАО08-11-2009 03:35 PM
Re: TCPIP SS$_IVBUFLEN problem
OpenVMS Alpha V8.3 has been out for three years.
It's time to upgrade.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2009 05:35 PM
тАО08-11-2009 05:35 PM
Re: TCPIP SS$_IVBUFLEN problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2009 07:35 PM
тАО08-11-2009 07:35 PM
Re: TCPIP SS$_IVBUFLEN problem
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).