Re: Communication between jobs

[Pete Hall <pete@xxxxxxxxxxxxxx>]

David Gibbs wrote:
> James H. H. Lampert wrote:
> > Aside from opening up a loopback TCP connection, or temporarily some 
> > object in a library (such as the *USRQs that are so ubiquitous in socket 
> > hand-off), does anybody know of a good way for one job to talk to another?
>
> Data queue seems like a logical choice.
>
> david
Queues are great for sending commands and state changes. Keyed queues
also work well for segregating data by client. A session ID, for
instance, can be used as a data queue key for returning web response
data to the middle tier. For making status values available across jobs,
user spaces work well also. They can be accessed just as if they are
local storage. Get a pointer to the space, then just offset to the value
of interest, as a data structure subfield or use a pointer offset from
the space location. I did that many moons back to sync converted S36
nep-mrt programs so only one client at a time could run the primary
program cycle. All global variables, as well as semaphore states (before
semaphores existed on the i) were stored in the user space. It worked well.