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

Hi Tom,

As far as the waiting is concerned... you could use semaphores instead of
the usrspc byte.

Kind regards,
Paul

-----Original Message-----
From: Tom Daly [mailto:Tdaly@sddsystems.com]
Sent: 18 April, 2002 16:27
To: 'rpg400-l@midrange.com'
Subject: RE: Local Sockets vs. Data Queues


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

------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains 
information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may 
be confidential, proprietary copyrighted and/or legally privileged, and is 
intended solely for the use of the individual or entity named on this message.  
If you are not the intended recipient, and have received this message in error, 
please immediately return this by e-mail and then delete it.

==============================================================================