Re: Http jobs and job name

On 1/19/06, Richard ECUYER <recuyer@xxxxxxx> wrote:
> Thank you for the answer,
> I know that each job is unique (with internal job number or with jobname and
> jobnumber)
> The problem i have is :
> I use another software that use 2 Dataqueues (one for the question the other
> for the answer) but (here is the problem) i can only attach one dataQueue to
> one JOBNAME, i have tried to create the dataqueue in qtemp, but the software
> (no source, no maintenance) certainly have the dataqueue library hardcoded
> so it does not work.
> It seems that if one job get a problem betwwen the question and the answer,
> another job will read the first answer and so on...

I hope I am answering the right question.  I assume that you mean that
you have a PAIR of data queues associated with a particular job name.

You could create an intermediary program that runs in a separate job
and has a single pair of data queues, which is used for the purpose of
collecting requests from the web server jobs and passing the answer
back.  You could use sockets for the program to program communication
between the web server and the request program.

Your web server instance is BTOB, so you have some number of jobs all
named BTOB.  You create a program and run it in a job, called perhaps
DQCOMM.  The job is started once, and the program never terminates. 
The program listens for socket requests, processes them through the
static data queue process, and passes the answer back through the
socket to the requesting (BTOB) job.

--> Scott Klement's sockets tutorial -- http://www.scottklement.com/rpg/socktut/

The underlying logic of this program is very simple ...
- listen on socket until a request comes in ...
- send the request to the data queue 1
- listen for the response on data queue 2
- pass the response back through the socket.

You could also use data queues in a similar fashion.  Have DQCOMM
listen on a data queue as well as communicating to the target program
through the job name data queues.  Have the CGI program create it's
own (unique, temporary) data queue, and include in the request data
the name of the data queue for response.

In this case, the underlying logic is similar ...
- listen on a defined (permanent) data queue until a request comes in ...
- parse the received data into response data queue and the request ...
- send the request to the data queue 1
- listen for the response on data queue 2
- pass the response back to the response data queue

I would take the plunge and use sockets unless the tutorial completely
throws you for a loop.  In either case you could have multiple DQCOMM
jobs (obviously in differently named jobs) if the transaction volume
so requires.

Another alternative is to create a web service as an intermediary, but
I don't know enough about web services to even tell you where to
start.

Good luck.

--
Tom Jedrzejewicz
tomjedrz@xxxxxxxxx