Re: Http jobs and job name -- WEB400

Thank's tom i will take a look at your solution...
and let you know if i get success.
----- Original Message ----- 
From: "Tom Jedrzejewicz" <tomjedrz@xxxxxxxxx>
To: "Web Enabling the AS400 / iSeries" <web400@xxxxxxxxxxxx>
Sent: Friday, January 20, 2006 5:13 PM
Subject: Re: [WEB400] 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
>
> -- 
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>
>