Not a good plan:

>>> Gavin Scott  writes:

<snip>

>The "traditional 3000" way of doing this (in the pre-Posix world) which
still works today is to use CREATEPROCESS to start a son process to handle
each connection, using the IPCGIVE and IPCGET NetIPC functions to pass the
socket connection from the father process to the son process. <

The typical server sequence for Sockets is a follows:

     SOCKET
     BIND
     LISTEN
     ACCEPT
     
     RECEIVE
     SEND

     SCLOSE

This will work fine in COBOL if this is all there is to it.
However, if you want to carry on a conversation with SEND / RECEIVE pairs, there are some other steps to take.

At the ACCEPT, you actually get a socket port number, and this number is used to do the SEND / RECEIVE.
If you want to carry on a conversation with multiple clients, multiple socket ports must be used.

CREATEPROCESS cannot be used to carry on conversations because the file descriptors are lost when the new process is created!
If the program were listening to say, 5 clients, one RECEIVE would hold up processing on one socket.
That is why either a fork or pthread should be used for mult-tasking sockets.
The file descriptors are shared amoung the segments of the program using fork or pthread.

If you are only doing a single RECEIVE / SEND per client session, then you are fine [although in sharing data across to
our IBM Mainframe, we had to set up locks on the mainframe to insure packets were not lost].

What Gavin said is strictly true, except for implication that CREATEPROCESS can be used for file descriptors under 
certain circumstances for Berkley Sockets. Perhaps there is something I do not understand at this point, but I have tried nearly every
combination of CREATEPROCESS, and I cannot make a son process to handle each connection.
I even tried file shared memory. It may work well for NETIPC, but it sure as death, taxes and revenge doesn't work for Berkley Sockets.
To be fair, Gavin clarified this in the rest of his presentation. Just remember that NETIPC works differently than Berkley Sockets,
and, while CREATEPROCESS may work for NETIPC, it does NOT work for Berkley Sockets.

The rest of what Gavin said is quite useful:

>When writing network server programs for the 3000, you can either use the
"Unix" style (Berkeley sockets TLI, fork(), and select() probably using C as
the programming language) or the "MPE" style (NetIPC TLI, CREATEPROCESS, and
Nowait I/O, using most any language).

>Both have pretty much the same capabilities.

>The choice of which Transport Layer Interface you use on the 3000 (BSD
sockets or NetIPC) won't affect what the client programs see.  They are both
interfaces to the TCP protocol.

>G.

The cost of getting things done is hyperbole.