RE: Local Sockets vs. Data Queues -- RPG400-L

Hi Evan,

Well in this particular case the current scenario is like this:

* a socket server job is running on the 400 (er...I mean iSeries) and it is
carrying on a conversation with a remote client

* i want/need to be able to suspend and then resume the conversation at any
time.  I don't want to just end the job because the client will just
reconnect and spawn off another server job.

When the client connects the server sends a request for data, and then
receives it, and then checks a usrspc byte for a 'stop conversation'
request.  It loops around on this.

When a stop request is indicated by the usrspc byte the pgm goes to sleep
and periodically wakes up and checks the byte looking for a resume request
(or an 'endjob' request).  This works ok but is not as responsive as I would
like.  Yeah I could shorten the sleep time but how short is too short?
Should the pgm wake up every second and check the byte?  How long is too
long?  The process could potentially be suspended for an extended time.

An earlier incarnation used a data queue to send 'commands' into the
communication job.  This worked fine but as Scott mentioned, requests are
queued.  This has the nasty effect that when a user makes a request to
resume the conversation, there may be multiple stopped requests queued up...
the pgm has to plow through those stop requests before it reaches the resume
request.  Since the pgm doesn't appear to be responding the user enters
multiple start requests... now the start requests are queued up and they
have to be plowed through before hitting the stop request.  The program
appears non responsive.  I get 4AM support calls.

I know I could have come up with some mechanism to prevent the entry of
multiple commands to the dtaq but there was another issue.  There could
potentially be hundreds of these jobs running (well ok.. we've only had a
few dozen to date) and I didn't want to have to create multiple dtaqs.  I
know: keyed dtaq, but it brings it's own problems.    In any case the
decision was made to have a 'process control block' array in a user space.

This control block idea seems to be working out pretty well with one
exception: a suspended process sleeps before checking the usrspc byte for a
'resume' request.  What I'm looking for is for the request to be acted upon
immediately.

So all that ;) is how I came to consider sockets.

One thing I like about sockets over a dtaq is that it is 'virtual' I don't
have any objects to create or clean up.  Conversely, data queues are alot
easier to use.  I think Scott nailed it pretty concisely when he listed
differences between sockets & data queues.  In fact I think I'm going to
read it again.

I think my socket programs are going to have to become service programs so
that they (sockets) can be easily used by other programs.  Programs that
aren't communication programs.  But before I go through the effort I thought
I'd see what others had to say.


Thanks for listening and I hope this makes sense!

Tom

 |  -----Original Message-----
 |  From: Evan Harris [mailto:spanner@ihug.co.nz]
 |  Sent: Thursday, April 18, 2002 03:06
 |  To: rpg400-l@midrange.com
 |  Subject: RE: Local Sockets vs. Data Queues
 |
 |
 |  Hi Tom and Scott
 |
 |  I'm really having trouble trying to picture how this could
 |  be easier if the
 |  server process is on the same machine as the proposed
 |  socket. Can someone
 |  enlighten me how this would be less work ?
 |
 |  I've used data queues many times to control server
 |  processes but if there's
 |  a better way I'm all ears.
 |
 |  BTW Scott, the two way communication - I find it easier to
 |  just have a
 |  queue for each process. Part of the information a job sends
 |  to the server
 |  on it's queue is the name of the queue to respond on.
 |  Obviously this takes
 |  some planning up front but works pretty well. Apologies if
 |  you already had
 |  this figured; I'll be surprised if you hadn't ! :)
 |
 |  Regards
 |  Evan Harris
 |