RE: TCP/IP Server concepts (RPGLE)

David,

By call other programs do you mean with a CALL?  (Eg: Same job), then 
yes, no problem.  Actually, my "client processor" job is a mixture of 
ILE/C and RPG so I am doing a lot of calls.  Just pass the socket 
descriptor as a parm.

If you are submitting new jobs, then you must use the give/take 
descriptor method.

Bob


-----Original Message-----
From:   David Gibbs [SMTP:David.Gibbs@IL.US.MKS.com]
Sent:   Monday, April 19, 1999 8:48 AM
To:     Bob Crothers (E-mail)
Cc:     'Midrange Mailing List'
Subject:        RE: TCP/IP Server concepts (RPGLE)

Bob:

This information is EXTREEMLY useful... got a question for ya though.

Can the "Client Processor" job call other programs, handing off the 
socket
id, to other programs that will continue the communications process?

My client processes will have multiple functions... and I don't really 
want
to have to build in all the functions into a single program.  I'd 
really
like to have the client processor receive a single message that tells 
it
what function to perform, and then call the appropriate program that 
will
perform that function..

Thanks!

david

> -----Original Message-----
> From: Bob Crothers [mailto:   
> Sent: Tuesday, April 13, 1999 8:15 AM
> To: 'MIDRANGE-L@midrange.com'
> Subject: RE: TCP/IP Server concepts (RPGLE)
>
>
> David,
>
> You can do this.  Easyily in C, a little bit (but not much I 
suspect)
> harder in RPG.
>
> First, create a subsystem for the monitor & client jobs to
> run it.  It
> should be maxjobs(*nomax) on both the subsystem and the job queue.
>
> next, create a "Socket Monitor" program.  More details below. This
> program does not actualy handle the client, it only listens for the
> connect requests from the client.  Set this up as an autostart job 
in
> the above subsystem.
>
> The first thing this job/program does is create/clear a data queue.
>  Lets call it TAKEDQ.  Then submit 2 "Client Processor" jobs to the
> jobq.  The exact number can vary based on the load.  I use 2.  One
> would also work.  More than 10 or so is probably over kill.   These
> are kind of a "prestart job".
>
> Now, the Socket Monitor should do its normal stuff to initialize
> itself and sockets.
>
> The mainline should then hang on a listen().
>
> When it returns from the listen (with no error), create a new socket 
> and pass it to accept().
>
> Now submit a new monitor.  We are about to take one of the idle
> montors.  This sbmjob creates a new one.
>
> Now, do a QRCVDTAQ on the TakeDQ data que.  When the client jobs
> starts, they send a data structure with their job info  in it
> (specificly a JobID) to this data que.  With this job id, now do a
> givedescriptor() passing the socket handle and JobID retrieved from
> the data queue.
>
> The monitor now loops back up and does a listen() again.
>
> In the Client Processor, the first thing it does is retrieve
> its JobID
> (via QUSRJOBI API), and sends it to the Socket Monitor via the Data
> Queue.
>
> Now, it issues a takedescriptor(NULL);  This will hang until the
> monitor process issues a givedescriptor against it's JOBID.
>
> When the takedescriptior returns (with no errors), the client
> processor now "owns" the socket and can do as little or as much as 
it
> wants without worrying about other clients.
>
> Clear as mud by now? <g>
>
> It really is not as hard to do as the above implies.  And it works
> VERY well on systems down to V3R1.  I use this technique in a
> commercial product (you guessed it, Fax Server/401) and have had no
> problems.
>
> If you are on a release that support threads, V4R1 or V4R2 I think,
> this is also an ideal use of multi threading...and is how I do 
things
> in my WinNT socket servers. With threads, you can skip all the stuff 
> about data queues etc and replace it with attach() and
> detach() calls.
>  BTW, I do not know how well RPG handles a multithreaded
> enviornment..this MIGHT cause you SEVERE problems.
>
> Regards,
> Bob Crothers
> Cornerstone Communications, LLC
> www.faxserver401.com
>
> another day done
> all targets met
> all systems fully operational
> all customers satisfied
> all staff keen and motivated
> all pigs fed and ready to fly...
>
>
>
>
> -----Original Message-----
> From: David Gibbs [SMTP:David.Gibbs@IL.US.MKS.com]
> Sent: Tuesday, April 13, 1999 11:27 AM
> To:   'Midrange Mailing List'
> Cc:   Brad Sommerfeld
> Subject:      TCP/IP Server concepts (RPGLE)
>
> Ok, here's a question for all you "Bare Metal" Programmers out
> there...
>
> I've got a simple TCP/IP server written in V3R2 RPGLE and it
> works ...
> but I
> need to make the process more robust.
>
> I need my server program to be able to handle multiple clients at 
the
> same
> time... but in a "Stateful" manner (i.e., the server has to
> do a whole
> bunch
> of work for the client and keep track of what is going on).  Kinda
> like
> evoking an ICF comms program and carrying on a conversation (send,
> receive,
> send receive, etc).
>
> >From my research, I've determined that if the server were written 
in
> C... on
> Unix... I would use the "fork()" operation to detach from the 
current
> process into a child process and the socket would handed off to the
> child.
> The server program would then allocate another socket and go
> back into
> a
> "listen()" mode.
>
> Is this basic logic possible to do in V3R2 RPGLE?  Am I biting off
> more than
> I can chew?
>
> Thanks!
>
> david
>
>
> --
>
> David Gibbs
> Sr. Software Engineer
> Mortice Kern Systems US, Inc.
> 2500 S. Highland Ave., Suite 200
> Lombard, IL  60148
>
> phone: (630) 495-2108 x5004
> http://www.mks.com <http://www.mks.com/>
> mailto:dgibbs@mks.com <mailto:dgibbs@mks.com>
>
>
> Opinions expressed are strictly my own and do
> not necessarily reflect those of my employer.
>
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to 
MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to 
MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to 
MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to 
MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---