Java to OpenVMS Mailbox

[OwensJ]

This was a question I had while thinking about using it as a file. If they would be "thread-safe". I think based on the fact that several web-requests could come in that may try to open and write to the same mailbox at the same time, it would be much safer to go the socket route.

[abrsvc]

Yes you can open the mailbox from multiple streams. The "records" will be processed in order of receipt.

Dan

[John Gillings]

> If they would be "thread-safe".

Mailboxes are definitely thread safe in the sense that multiple threads cannot write to a mailbox "at the same time" because mailboxes are robustly synchronised at the operating system level. One thread will always "win" the race.

As others have mentioned, mailbox I/O is, by default, end-to-end synchronous. That is, the writer will wait for the message to be read before proceeding. This may have an effect on threading, as a thread may block on a mailbox write. If that prevents another thread from reading the mailbox, you could have a deadlock (depends on your threading mechanism being capable of switching threads during an OS level I/O stall).

You may not have control over mailbox read behaviour when do a device independent/blind I/O. If you access a mailbox explicitly, you can do asynch I/O.

[OwensJ]

All good to know, thank you!

[Richard J Maher]

Hi,

The reason I mentioned stream i/o is, having used java.io.BufferedInputStream for Socket i/o, I wasn't sure the exact behaviour the OP was expecting with a JAVA program writing/streaming to a mailbox, expecially if he intented to have multiple simultaneous writers, or messages larger than the mailbox size.

For those unaware of the streaming possibilities of the VMS Mailbox may I suggest you look up the io$m_stream modifier at: -
http://h30266.www3.hp.com/odl/i64os/opsys/vmsos84/BA554_90018/ch04s03.html#mbx-read-func

For those worried about blocking on a write there is always the io$m_now and io$m_norswait modifiers.

If this is all happening on the same node then I would use Mailboxes over Sockets but you'd want to be "listening" on a single control mailbox for connection requests that would include the connect/user/process specific mailbox device name that your server must connect back to to complete the handshake. How JAVA would call a VMS system service directly to creates a mailbox, I know not. (But there seems to be stuff in the FAQ http://www.compaq.com/java/faq/ovms.html)

Maybe the OS implementation-specific bits of other classes like Pipe do something useful? Or maybe Sockets are just easier and more transparent/generic after all?

Cheers Richard Maher

[Craig A Berry]

>For those unaware of the streaming possibilities
>of the VMS Mailbox may I suggest you look up the io$m_stream modifier

which only applies to reads, not writes. You can do partial stream emulation by reading less than a full record at a time, but writes always introduce a record boundary. For the OP that may not be a problem as long as he always writes a complete message and makes sure it fits within the mailbox buffer. He might have to do a flush between writes depending on how the Java classes are implemented.

[Richard J Maher]

>>For those unaware of the streaming possibilities
>>of the VMS Mailbox may I suggest you look up the io$m_stream modifier
>
>which only applies to reads, not writes.

Which is why I gave the following direct link to "4.3.1 Read": -
http://h30266.www3.hp.com/odl/i64os/opsys/vmsos84/BA554_90018/ch04s03.html#mbx-read-func

> You can do partial stream emulation by
> reading less than a full record at a time,

No! As is clearly explained in Figure 4-2 in the explicit refernce that I went to the trouble of providing, one can clearly see that a streaming read can read any number of records (and/or part there off) in a single $qio read without loss of residue.

> but writes always introduce a record
> boundary.

So what?

> For the OP that may not be a problem as
> long as he always writes a complete
> message and makes sure it fits within the
> mailbox buffer.

Quite. As I said "For the OP it may be a problem if . . ."

> He might have to do a flush between writes

Might?

> depending on how the Java classes are
> implemented.

I believe an implementer of the stream i/o interface has to "as a minimum" provide single-byte i/o. God bless Unix.

Regards Richard Maher

[Craig A Berry]

>>>For those unaware of the streaming possibilities
>>>of the VMS Mailbox may I suggest you look up the io$m_stream modifier
>>
>>which only applies to reads, not writes.

>Which is why I gave the following direct link to "4.3.1 Read": -
>http://h30266.www3.hp.com/odl/i64os/opsys/vmsos84/BA554_90018/ch04s03.html#m
bx-read-func

I'm familiar with the article.

>> You can do partial stream emulation by
>> reading less than a full record at a time,

>No! As is clearly explained in Figure 4-2 in the explicit
>refernce that I went to the trouble of providing, one can
>clearly see that a streaming read can read any number of
>records (and/or part there off) in a single $qio read
>without loss of residue.

You seem to be going out of your way to disagree with me while saying essentially the same thing I said. The number of complete records you get is irrelevant; that works fine, even without IO$M_STREAM. It's what happens when you run out of buffer before you get to the end of the final (possibly only) record; that's where IO$M_STREAM allows you to get "less than a full record at a time" (my words) or "and/or part thereof in a single $qio" (your words) without introducing a spurious record boundary.

>> but writes always introduce a record
>> boundary.

>So what?

Because anyone doing stream I/O through mailboxes (such as anyone using pipe() in the CRTL) will eventually be bitten by this.