Skip to main content

I have an idea for a service.  It would accept incoming network connections but instead of launching a cobol-thread to process the socket that gets created, it would need to start a separate process, with a new runcbl session.   I've figured out how to pass enough information that the new-process could open a socket back to the service, and together they could handle the communication, but this would basically duplicate all the traffic going in/out of this server, because the information would have to be copied back and forth between the service and the new runtime.   Do-able, but inefficient.  Thus the desire to pass a socket handle to the newly started runtime and let it handle the communication by itself. 

This will normally be running on a linux server, but it would be nice if windows was also an option.


#CSOCKET

I have an idea for a service.  It would accept incoming network connections but instead of launching a cobol-thread to process the socket that gets created, it would need to start a separate process, with a new runcbl session.   I've figured out how to pass enough information that the new-process could open a socket back to the service, and together they could handle the communication, but this would basically duplicate all the traffic going in/out of this server, because the information would have to be copied back and forth between the service and the new runtime.   Do-able, but inefficient.  Thus the desire to pass a socket handle to the newly started runtime and let it handle the communication by itself. 

This will normally be running on a linux server, but it would be nice if windows was also an option.


#CSOCKET

This is currently not possible. But it could be an enhancement request.

Internally we would need to dup() the internal socket handle before fork()ing the new runtime, and allow that duplicated handle to remain open for the child. Possible to do, but currently we don't provide enough information to COBOL to allow this.

This is currently not possible. But it could be an enhancement request.

Internally we would need to dup() the internal socket handle before fork()ing the new runtime, and allow that duplicated handle to remain open for the child. Possible to do, but currently we don't provide enough information to COBOL to allow this.

About what I suspected.   A couple points though:

  • C$SYSTEM has an option, INHERIT-HANDLES.  Probably limited, but it could be enhanced to pass along socket handle(s).  Not sure if C$SYSTEM uses fork().
  • A google search reveals that linux allows passing a socket handle if you open a unix socket (not a tcp socket) and then you can pass along a copy of the file object (not just the file#), so the other process can access the socket opened by the first one, without requiring a fork.
  • Apparently windows is different, you have to duplicate the socket handle, pass that to the other process, and it can use the duplicate handle, but all it does is use the socket that's in the first routine's memory, so that first routine cannot shut down, or close the socket.  (this is from a quick search yesterday, and I'm going off memory, so anyone who knows better about this, please forgive any mistakes)

I have an idea for a service.  It would accept incoming network connections but instead of launching a cobol-thread to process the socket that gets created, it would need to start a separate process, with a new runcbl session.   I've figured out how to pass enough information that the new-process could open a socket back to the service, and together they could handle the communication, but this would basically duplicate all the traffic going in/out of this server, because the information would have to be copied back and forth between the service and the new runtime.   Do-able, but inefficient.  Thus the desire to pass a socket handle to the newly started runtime and let it handle the communication by itself. 

This will normally be running on a linux server, but it would be nice if windows was also an option.


#CSOCKET

For the record, and for anyone reading this topic in the future, I expected that a C$SOCKET handle cannot be passed to another runtime, and I had an idea for a workaround, but it would be significant work.  A google search reveals that c socket handles can be passed to other c programs.  This implies that a shared library, written in c, should get around this limitation. 

Idea: build a shared library, with similar functions to C$SOCKET, but call it mysocket.  Add a couple extra functions, to allow sending a socket to another process.  Since the libraries would be written in c, (or c or whatever) then the libraries could be used to open a unix socket (rather than tcp socket) and transfer the handle.  Then the 2nd runtime, the spawned runtime, could use the shared library code to do socket io directly rather than having to send to the service routine, and have it forward the data via a second socket connection.  In theory something similar could be done in windows, using it's duplicated handle technique.

For the record, and for anyone reading this topic in the future, I expected that a C$SOCKET handle cannot be passed to another runtime, and I had an idea for a workaround, but it would be significant work.  A google search reveals that c socket handles can be passed to other c programs.  This implies that a shared library, written in c, should get around this limitation. 

Idea: build a shared library, with similar functions to C$SOCKET, but call it mysocket.  Add a couple extra functions, to allow sending a socket to another process.  Since the libraries would be written in c, (or c or whatever) then the libraries could be used to open a unix socket (rather than tcp socket) and transfer the handle.  Then the 2nd runtime, the spawned runtime, could use the shared library code to do socket io directly rather than having to send to the service routine, and have it forward the data via a second socket connection.  In theory something similar could be done in windows, using it's duplicated handle technique.

I would recommend reaching out to your Micro Focus Sales Account Manager to discuss your application goals, as, we might have existing product solutions that meet your technical requirements.

In particular either the Xcentrisity Business Information Server, or AcuConnect Distributed Processing, solutions might provide the functionality that you have described.

Please let me know if you want me to reach out to Sales on your behalf.

I would recommend reaching out to your Micro Focus Sales Account Manager to discuss your application goals, as, we might have existing product solutions that meet your technical requirements.

In particular either the Xcentrisity Business Information Server, or AcuConnect Distributed Processing, solutions might provide the functionality that you have described.

Please let me know if you want me to reach out to Sales on your behalf.

Thank you, but no.  I've looked at those in the past and they don't fit this project.  We'll probably just accept the throughput penalty if we go forward.

Terms & ConditionsAccessibility statement