|
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 |
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.