Replacing VMS mailbox concept in HP-UX

[Shivakumar_3]

hello everybody,
I am migrating from VAX server to HP-UX server.In VAX i have used mailbox to store incoming data from the Clients.How to replace this mailbox concept in HP-UX?
Pls help me out.

[Uwe Zessin]

Unix operating systems usually use "pipes" for this kind of interprocess communications, but I think you don't have all features of VMS mailboxes.

[Antoniov.]

Hi Shivakumar,
I think here nobody is able to help you because we are expert of VMS no Unix.

Unix uses pipe to connect two processes. Pipe is like a mailbox but with some limitations. For example, in unix both processes have to be running to comunicate each to other (pipe is merely an i/o channel) while vms mailbox keeps record until receiver process read from it.

Antonio Vigliotti

[Wim Van den Wyngaert]

Read this http://jan.netcomp.monash.edu.au/OS/l9_1.html

Or if you want more :
http://www.google.be/search?num=100&hl=nl&q=allintitle%3Ainter-Process+Communication+unix&meta=lr%3Dlang_de%7Clang_en%7Clang_fr%7Clang_nl

Wim

[Shivakumar_3]

Thank u for ur reply sir.
What exactly i am doing is i am getting a buffer with data from another m/c running qnx and storing that buffer data in the mailbox and accessing that mailbox through a fortran file.Is there any storing method now to save the buffer data in HP-UX and access that data from that stored method.
Please help me out sir.

[Antoniov. · Accepted solution]

If you want to store record on HP-UX box, post your question here
http://forums1.itrc.hp.com/service/forums/familyhome.do?familyId=117
If you want to store buffer in vms mailbox, you can just use a mailbox. Record is avaiable until receiver process read from it.

Antonio Vigliotti

[Peter Quodling]

How do you mimic VMS Mailboxes in Unix? You don't. The principles of Design of UNix do not lend themselves to efficient mechanisms like VMS Mailboxes. That said, if you must, why not just write the data as a file on the unix box. One of the aspects of Unix that they "beat up on VMS" with, is that it's faster to open/close files etc.

If you are looking for something a bit more robust, i.e. looking for guaranteed delivery, in order sequencing etc. Consider MQ (Either Bea MessageQ or IBM MQSeries)

p.s. why in goodnesses name are you writing in Fortran? Not that I don't like Fortran, but if you are doing a migration, you may want to consider something more portable, with a bigger maintenance skill base etc...

Peter

[Uwe Zessin]

Watch out, please:
- an OpenVMS mailbox works as a record-oriented device, by default.
- a PIPE is a stream-oriented device

[Shivakumar_3]

Thank u very much everybody.Now i am clear what to do and how to tackle the task.

[Hein van den Heuvel]

The natural replace for mailbox IO on VMS with something on Unix (any Unix) is "fifo's"
Ckeck out the Unix man pages for mknod.

However... while you are re-implementing you may want to consider to switch to sockets and use tcp to communicate, allowing client en server application to live on distinct nodes some day.

Of course the recommended upgrade from a VAX is an Alpha or Itanium OpenVMS server. You should be able to save a bundle of porting costs that way :-).

Hein.

[Ian Miller.]

FYI - You can do stream I/O using VMS mailboxes but normally you use record I/O which preserves message boundries. I don't know of an equivilent facility.

[Uwe Zessin]

There was a reason I appended a ", by default" ;-)

You can always encapsulate your 'records' in a protocol if you switch to a streams device. I have never tried it, so I assume it's pretty easy ;-)

[Antoniov.]

On vms box you can manage mailbox like file using open, close, read functions.
However, if you have to write code for vms and unix platforms, I'm with Hein: you have to use socket programming.

Antonio Vigliotti

[John Gillings]

First thing to do is to extract and encapsulate the mechanism. Your application code should be written in terms of things it understands. Some kind of procedural interface "SendMessage(message)" and "ReceiveMessage(message)". You can then implement or re-implement the underlying mechanism without upsetting the application logic.

Prototype using something simple to code and debug, refine later if necessary.

Also, when you come to your senses and port back to OpenVMS, you just plug in the OpenVMS implementation.

[Peter Quodling]

Amen, I must endorse John's comments. A mentor of mine, one of the most latented men to walk the halls of ZKO once told me good software follows the principle of SOFF (Separation of Form and Function). Treat every piece of code as it it were to callable. Inherent in this is the core framework upon which Object Oriented design is based. Encapsulation and the Underlying modularity facilitate good, maintainable and portable code.

Of course, as I have often said, when watching people in a headlong rush to move from the stable VMS platform to Unix or Windows (because some Journalist thinks it's a good idea), VMS because of it's design, was one of the first O/S's to gain Unix Systems Standards Certification.

I have often counselled folks heading in that direction to enhance their software running in a VMS environment to encapsulate the few core VMS'isms, and things that use specific features - Then, and only then, to migrate if appropriate to a different platform.

Sometime back, when I was heavily involved in Migrating client code from VAX to Alpha, we would routinely cross-test by attempting cross-compiles on different O/S. From the number of "errors" reported, which actually got a good feel for the skill level of the original developers...

Good code is more about maintainability then innovation or performance, or bells and whistles, or what platform it runs on.