× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On 11/07/2006, at 1:12 AM, Steve Richter wrote:

I have found two way data queues very difficult to code. You have to
assign a transaction id to differentiate responses to other clients
from your client. The response queue has to be keyed by transaction
id. What happens when the server is down or stuck? Your client then
waits for how long for the return code?  Did you say 10 seconds?  Well
what if the system is running slow or another client has sent a large
transaction to the server?

What you describe here forces a synchronous process on to queues. There is no reason to wait for a return code. Deal with it when it arrives.

Also is no requirement for keyed queues. Each sender could have it's own response queue.

When do you clear the return queue of unreceived response messages?

Why would they not be received unless the sender died? Given that the sender is likely (and especially given your description) to be an interactive job it won't die without someone noticing.

Clearing can be handled during sender start, during a nightly clean up, or by deleting an recreating the queues.

When the return message is more than 1 day old or the sending job is no longer in the system? Then you have to permanently store the transaction in in a file so you can
calc the job and age of the transaction.

Not true. You can use the QMHRDQM to check the enqueue date and time. This can be used to determine the age and old entries can be removed.

With a program call none of these issues have to be addressed.

True, but what you're objecting to is the asynchronous nature of queues. If you want synchrony then use a synchronous process but don't use your requirement for synchrony to damn all legitimate uses of queues.

None of your objections are show-stoppers. They can all be handled by a decent design. All of your objections simply indicate that MAYBE queues are not a good fit for your requirements. Just because they don't (or can't be made) to work for you doesn't negate them as an ideal solution for someone else.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.