Passing channels through mailboxes... (COBOL)

[Yyrkoon]

Hi all,
I am having problems when I try to pass an I/O channel as a string through a mailbox. I mean, I have one cobol program which opens a tcp/ip (using fortran <-- not important) session and keep listening for some data. When it receives something it sends this data to a mailbox and a second program must take this data,generate a proper reply and send it back to same socket, so it must use the open connection and I need to pass the channel from the first program to the second.
My problem is that I do not know how to pass the channel as a parameter.

Can you help me?

Thanks in advance.

[abrsvc]

There have been recent discussions about 2 separate processes attemting to use the same socket without complete resolution. Since you currently have a mailbox for communicating between the two programs, why not return the data to the first program for it to send out the socket. In this fashion, all TCPIP communications are handled by one program and message processing is handled by the other. This is less likely to create communications or socket issues as all control will be within one program context.

Just a thought.
Dan

[Yyrkoon]

Actually is not a bad idea, in fact this was my first attempt but I found two problems:

1)first program is stuck reading the socket until it receives something.

2) As far as I know a mailbox is able to work just in one direction. I do not know a way to read a message without delete it. So if the second program writes on the mailbox it will read his own message and it goes into an infinite loop.

Of course I can make a second mailbox, one for each direction, and put a time-out when I read the socket, but this is what I want to avoid.

It is hard to believe that there is not a way to pass a channel as a 'parameter' (using logicals, mailboxes, a data file or whatever).

Any other ideas?

[Hoff · Accepted solution]

>1)first program is stuck reading the socket until it receives something.

If the application is coded synchronously, yes.

With asynch I/O and asynchronous system traps (event-triggered subroutines), the application can have a read pending, and can continue with other operations until the AST fires.

>2) As far as I know a mailbox is able to work just in one direction. I do not know a way to read a message without delete it. So if the second program writes on the mailbox it will read his own message and it goes into an infinite loop.

Mailboxes are bi-directional, but it's vastly easier to use a pair of mailboxes as you don't need to deal with the turn-around. A common mailbox application design here uses one or more writers, and one reader.

They are message-oriented devices, and attempting a read-ahead adds substantial complexity to the design.

Infinite loops are programming errors, usually in the application, though occasionally in the lower-level code.

>Of course I can make a second mailbox, one for each direction, and put a time-out when I read the socket, but this is what I want to avoid.

Why? Mailboxes are cheap to create and cheap to run. They're not the lightest-weight, but performance optimizations here are likely premature.

>It is hard to believe that there is not a way to pass a channel as a 'parameter' (using logicals, mailboxes, a data file or whatever).

OpenVMS I/O channels are process-local context references, and the values are meaningless outside the particular process.

Trying to have a shared socket should be approached with caution; you can end up with two readers operating in parallel, and that gets interesting to manage within the application image(s). This because you can end up with all the look-ahead push-back hand-off hackery, and that gets complex.

Here is code that allows socket sharing:

http://h71000.www7.hp.com/wizard/wiz_3995.html

Here's a recent discussion:

http://groups.google.com/group/comp.os.vms/browse_thread/thread/2fcbb036b7cc84b6

I'd suggest looking at the auxiliary server here, and have that start up the application that will listen on the socket.

And I'd probably also look to move up-stack with the designs here - from primitives such as mailboxes and sockets - as that's an older design and more involved, and you're going to be reimplementing a whole lot. Selection of appropriate communications middleware and better languages can help speed your deployments; you spend more time on your own application logic, and less time on the glue code and debugging same.

[Yyrkoon]

Many thanks!!

Now I don't know yet what I am going to do, but I think I have all information that I need to take a decision and a way to do it.

I close this thread. Thanks again.