Processes transfering data using mailboxes.

[Michelle_68]

We have a process that transfers data between VMS machines using mailboxes. This application runs successfully on old VMS 4.4, OpenVMS 6.1, and OpenVMS 7.2-1 running on an AlphaServer DS20. We recently purchased several AlphaServer DS25s which are running OpenVMS 7.3-2 and OpenVMS 8.2. This same process will work for files up to 20 blocks in size. Any file larger than that, the process seems to freeze and no error messages are seen. My conclusion is that something has changed in the OS between versions 7.2-1 and 7.3-2 in the implementation of mailboxes. ??? Any suggestions???

[David B Sneddon]

Michelle,

Can you explain how you transfer _between_ machines
using mailboxes?
(Have a look at the SYSGEN parameter MAXBUF on each
of the systems to see if there is a difference)

Dave

[Ian Miller.]

Michelle,
can you expand on "the process seems to freeze and no error messages are seen. "?

What state is the process in ?

There where certainly changes in mailboxes to enhance performance

V7.3-1 introduced per mailbox spinlocks
V8.2 fast UCB create/delete.
Also in V8.2 mailbox device fullnames changed from nodename$MBAn: to _MBAn: (nnm device characteristic was removed).

Mailbox buffer quotas are now allowed to be larger

[Allan Bowman]

Michelle,

It sounds like you are connecting, so the mailbox names must be correct.

You need to make sure that the mailbox size is specified as the same within the create command on all systems. It is possible that the default mailbox size is different between the systems - this would cause transfer problems.

Allan in Atlanta

[Michelle_68]

In order to give you more information as far as what is actually happening during the transfer we will have to go through the code to see what the programmer was actually doing. We have tried the transfer from an Alpha DS25 running 8.2 to a MicroVax running V4.4. We have tried the tranfer from an Alpha DS25 running 7.3 to a MicroVax running V4.4. We have tried an AlphaStation 255 running 7.3 transferring the files to itself. All of these combinations do not work. If you are running V7.2 and under there is no problem transferring to any other kind of machine. Are there other SYSGEN parameters that may be causing problems? I will let you know what we find in our code search.

[Wim Van den Wyngaert]

DEFMBXBUFQUO default buffer size when not specified by the program.
DEFMBXMXMSG maximum value default when not specified by the program.
PQL_DJTQUOTA when run /... is done but no JTQUOTA is specified.

Wim

[Hein van den Heuvel]

Michelle,

Don't dig too deep. What we are trying to understand here is how mailboxes supposedlly play a role in transfer between system.

What is the basic mechanisme used to move the data oveer the wire? DECnet? FTP? NFS? EMail?

When you talk about mailbox, do you mean the VMS primitive driver which allows, much like a unix fifo / pipe, one process on a system to write some data into is, and an other to read that data?

Or are you perhaps referring to an 'application function' which happens to have been called mailbox?

How does your system decide that a transfer failed?
Is there a specific error message reported in a log perhaps? Lack of a message? Is there an final status in the accounting system perhaps?

hth,
Hein.

[David Jones_21 · Accepted solution]

A VMS mailboxes communicate between processes on a single host. If the transfers are between machines then something else is involved. DECnet calls its pseudo-devices created to handle logical links 'network mailboxes', perhaps that is what you mean. Do a "SHOW RMS" on the various machines and compare the network block count.

[Wim Van den Wyngaert]

May be reading sylogin.com and/or login.com and comparing it with worlking versions might reveal something.

BTW : we have simular stuf were client programs pass data via mailboxes to processes that transfer it to other nodes where a process receives it, writes it to a mailbox for the destination (that MUST read it). Transport is done with X25/TCp/DECNET.

Wim

[Michelle_68]

Eureka!!! It was the RMS_DFMBC SYSGEN parameter (Default Multi Block Countthat was causing our problem. After looking through the code, we found the the programmer was using this parameter to calculate a block count for the file transfer. In 7.2 and later versions, the default value for RMS_DFMBC was changed from "16" to "32".
Thanks to all for your input, support and assistance. Thanks also to David Jones for the "SHOW RMS" command.

[Hein van den Heuvel]

David might be on to something here with the NETWORK BLOCK COUNT setting.
Check the SHOW RMS output on the systems involved.


On VMS systems, the following three items determine the size of a DECNET data message:

- XAB$_NET_BLOCK_COUNT set in a XABITM structure (unliekly to be used)
- DCL command SET RMS/NETWORK_BLOCK_COUNT
- SYSGEN parameter RMS_DFNBC

This is all different if the transfer is being made in record access mode. In this mode the data buffer must contain the entire data record. This means that to copy a 32256 byte record, the network block count must be 63 blocks.

Now in your case, maybe this is a 'binary' file, stream-lf file with no real terminator, making is a single long record?

If you have an easy reproducer, then just SET RMS/NET=64 and try again?!
Note: You probably need to do this with /SYSTEM or in a login.com path for the server process to be created. Maybe:
$if f$mode().eqs."NETWORK" then set rms/net=127

hth,
Hein.

[Hein van den Heuvel]

Ah, my last reply reply became somewhat redundant, as it sat in my buffer too long did it not. Oh well.

Then again... we see two conflicting forces at work here, and you may want to think about this a little longer still. Reducing the network buffer from 32 to 16 made it fit with 'the other system', but it would seem better to increase the other systems to 32 in order not to hold out on performance.
The program may need a minor modification for it not to blindly take the default, but to add a min and max test function around that.

fwiw,
Hein.

[Wim Van den Wyngaert]

I have 7.3 and the default value is 16.
It must be from 7.3-2.

Wim

[Michelle_68]

My Mistake. We are running V7.3-2 and 8.2 on our Alpha DS25s. The default for these RMS_DFMBC is "32" not "16".

[Robert Gezelter]

Michelle,

Please note that you may only need to change the RMS settings for that particular process.

The change was to the standard system default. You can always override the standard setting on a per-process basis (you can also use a group LOGIN.COM file to reset the initial settings on a group-wide basis, if that is appropriate).

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Michelle,

from your Forum Profile:


I have assigned points to 15 of 50 responses to my questions.

And one of those is quite old...

Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.

Thanks on behalf of your Forum colleagues.

PS. - nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before - please do not take offence - none is intended!

Proost.

Have one on me.

jpe

[Michelle_68]

Thank you Bob Gezelter for the information about just changing the RMS parameters for a certain process. We will look into that.
Thanks again to all.
(Promise I will be more diligent in assigning points)