|
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. ==============================================================================
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.