As far as the batch NEP that relays, I really like the sound of that, but do not know what it is.
Sorry... NEP -- Never-Ending Program.
Basically, it's a program that you submit to run in some batch subsystem and that is expected to loop forever. (Well, until some kind of command or signal tells it to end.) You might submit it to job queue QSYSNOMAX to run like various server programs.
Your program would start by opening the socket connection. Then it would sit while waiting for an entry to arrive on a data queue. Whenever an entry appeared, it would send it across the socket and go back to see if another entry was on the data queue.
It might spend 99.999% of its time just waiting. Any number of programs from other jobs could be sending commands to the single data queue.
If necessary, the data queue could be keyed so that every command had a unique identifier, perhaps derived from the GENUUID API. When a command is pulled from the queue and sent out the socket, the unique ID is used to send an acknowledgment back through the data queue. Only the sending job would know which key was the acknowledgment for it. The data queue would provide two-way communication between your jobs and your "socket server".
If the volume was so much that your server couldn't keep up, you'd simply start a second one.
The "socket server" would have everything needed to do your sockets work. It wouldn't have any complications from needing to understand the commands from the data queue -- it just sends whatever shows up. Keep the logic focused in nicely separated proc, modules and programs -- neat division of labor.
Your "client programs" will also be simple. All they do is handle the appropriate command strings and send them to the data queue. (Optionally, it's a two-way data queue; but that might be a later enhancement. Make it work, then make it better.)
If you haven't used data queues, you should find them much easier than sockets.
Tom
