![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: Dear Wizard, My question is about the $ICC system services (intra cluster communications). I have a server program (same program, same code) that runs on multiple nodes of an OpenVMS cluster (CI interconect), and a client program that can be run interactively from any node in the cluster. The client program connects to one of the server programs (the user of the client program specifies the node to connect to on the command line) using the default ICC Association (ie. the client program does not explicitly call $ICC_OPEN_ASSOC). The client program sends a message to the server program by calling $ICC_TRANSMITW and then waits for a response by calling $ICC_RECEIVEW (both calls using the same ICC Connection). When the client and server are on DIFFERENT nodes, everything works fine. But when the client and server are on the SAME node, any responses from the server larger than 4096 bytes are received as all zeros. The fields in the iosb (ios_icc$w_status and i os_icc$l_rcv_len) indicate success and the correct message length, but if the message is larger than 4096 bytes, then it is blank (the client's receive buffer is 16000 bytes). Prior to programming the client to use $ICC_TRANSMITW and $ICC_RECEIVEW, I programmed it to use $ICC_TRANSCEIVEW. With the transceive, any messages larger than 4096 bytes always failed with SS$_MAXBOBMEM regardless of which nodes the server and client w ere running on (sysgen parameter MAXBOBMEM = 25000 on all nodes). I never have any problems when the messages are 4096 bytes or smaller. Could this be a V7.2-1 issue? Is there a limitation to using the default ICC association? The client program transmits and sends over the same connection - do I need seperate connections? Any ideas would be appreciated... Thanks Rob The Answer is : After installing the mandatory ECO kits or (better) upgrading to a more current release, please contact the support center directly for assistance in resolving this -- this is not a problem that the OpenVMS Wizard immediately recognizes.
|