Mailbox message size limits.

[Brian Reiter]

Hi Folks,

I maintain a number of systems based on OpenVMS. These systems use mailboxes for inter-process communications, a new requirement imposed by the customer means that message that are sent by the processes via mailboxes are going to exceed the 64K message size limit.

The obvious solution is to use global sections for inter-process commuication but I was wondering if any other solutions were known about.

As the systems don't particpate as members of a cluster (they are generic units which communicate externally with PC and AIX systems) I'm not sure if the ICC_xxxx services will operate.

For the record the systems are written entirely in Pascal and rely heavily on the AST and Event Flag mechamisms for mailbox message delivery.

regards

Brian

[Ian Miller.]

If the systems are clustered then $ICC is the way to go. This can be used between processes on the same standalone (not-clustered) system. Between processes on different sysstems which are not clustered I think you are going to hit the 64K limit anyway (e.g $QIO over network links) so parhaps you should plan to split messages.

[Brian Reiter]

So do the ICC_xxxx services require a cluster license? If they don't then using them this is probabely the easiesy solution.

[Willem Grooters]

Brian,

In your case (non-clustered systems) I could think of using socket-IO, but I'm not sure whether this will fit your (appearently asunchronous) application. It may require some re-design and re-coding.
Clustering may than be the nices solution (amongst other advantages ;-))

[labadie_1]

I do not think the ICC... need a Cluster licence. You will find at http://www.pi-net.dyndns.org/jfp/english/

some
Tests performances decnet, icc, mailbox

which will let you try and compare the throuput of decnet Icc and mailboxes.

Regards

Gerard

[Brian Reiter]

Gerard,

Will try out the ICC_xxxxx routines on Monday. Sadly the development server is not available (we're in the throes of an office move) so can't do much at the moment.

Should all be back and working :) on Monday, although the cynics amongst us reckon at least a week.

I'm trying to do the work with minimum changes due to fairly tight timescales.

[Martin P.J. Zinser]

Hello Brian,

two other possibilities:

1.) Would it be feasible to split the messages to stay below the 64k limit?

2.) How about compressingthe message before sending it? Zou could either use a homegrown algorithm or a general purpose library like Zlib.

Greetings, Martin

[labadie_1]

If you are at Vms 7.3-1 or later, you can use larger mailboxes size, see on this mirror of the doc

http://www.pi-net.dyndns.org/docs/openvms0731/731final/6657/6657pro_007.html

5.10 Larger Mailbox Buffer Quotas

Prior to Version 7.3--1, the maximum size for the mailbox buffer quota was 64,000 bytes. OpenVMS Alpha Version 7.3--1 supports the creation of mailboxes with larger buffer quotas for improved application scaling.

When creating a mailbox with the $CREMBX system service, you can explicitly supply a mailbox buffer quota with the BUFQUO parameter. If not, the mailbox buffer quota is implicitly supplied by the system parameter DEFMBXBUFQUO.

Note the following:

* Temporary mailboxes do not have a specific size limit.
* The size of the mailbox is subtracted from the BYTLM quota of the process.
* Permanent mailboxes do not consume process quota; however, any data in a mailbox consumes nonpaged pool.

[Ian Miller.]

Yes you can have larger mailbox buffer quota in V7.3-1 but not messages larger than 64K which is what was asked for. I think the application should use ICC for within a node and a network link (DECnet,TCP/IP, X.25 or whatever you like) between nodes.

[Brian Reiter]

Hi All,

Thanks for all your responses. I think given the timescales we have (always too tight), creating global section on the reply when a mailbox message will exceed the 64K limit is the way forward - at least from my point of view it provides the simplest solution.

thanks anyway

Brian