|
On 10/07/2006, at 12:58 AM, Vernon Hamberg wrote:
I am in complete agreement with you in this matter. I'm glad you tackled it. Allow me to mention a couple scenarios in common use that might further bolster your points and help us in our thinking about queue usage of any kind. 1. IBM's own MQ product is a guaranteed delivery mechanism that uses various kinds of queues - major financial institutions use it all the time. Simple program calls can't handle this kind of thing.
MQ was ripped out of CICS. CICS is essentially a transaction processor. Given that CICS is used by major financial institutions whatever transport mechanism it uses MUST be reliable. IBM saw the opportunity to sell the queue management part of CICS as a separate product. MQ doesn't use queue objects as we know them but they are still queues. MQ doesn't use MI queues because they've written cross-platform code to handle the queuing concept.
Simple program calls can't handle this but Remote Procedure Call can. What you lose with RPC is the asynchronous aspect of the process. With any form of program call you are saying "I want this done NOW" but with any form of queuing you are saying "I want this done but I don't care when".
2. The basic inner mechanism of Windows is message queueing - VB and C and Delphi and whatever insulate us from that mechanism, but to get real control of certain things, you SNDMSG to Windows and other processes asynchronously pick them up. Different from DTAQs in several ways but similar in principle.
Same as most GUI environments. OS/2 Presentation Manager and Java work the same way.
3. What you have described repeatedly and well is what I understand to be the contract model of development - a "user" and a "service" contract to behave certain ways, such as that the user will validate data and deliver it to the service in the form the service expects to see, then the service will process it and return certain data as agreed upon. I think we do this implicitly, but there is a framework in which this is more defined, IIRC. Even a development environment called Eiffel, I think.
Eiffel? Now there's a language I haven't thought about in over 10 years. Yes, all compilation units effectively enter a contractual arrangement with the consumer. In most programming languages the implementation of that contract is left to the programmer. Bertrand Meyer had many interesting ideas and this is one he implemented in the Eiffel programming language. Not sure if this idea was his alone or initiated by one of the other OOP names but as far as I know Eiffel is the only development environment to enforce it.
4. RPC - remote program calls, for some reason, creep into my thinking here. Or call it asynchronous processing or think about MQ.
See comments above.
5. As to robust production code that depends on this kind of thing, it is well known that much of the iSeries code is using user indexes and user queues (an even lower-level variant of a data queue). Iguess IBM has made a mistake depending on these "unreliable" things. <vbg>
Not so much USER queues and USER indices but certainly the MI variants of the basic queue and index object types.
Obviously IBM made a mistake--not only with the implementation of CPF, OS/400, i5/OS but also with pricing and marketing of i5 hardware. Equally obviously they should employ Steve immediately to take over and fix all these problems post-haste.
Am I off base here, Simon, or does this go along with your thoughts?
No you're not off-base. Judging by the comments from others sticking their tuppence-ha'penny into this topic the only one off-base is Steve. That's OK, he can continue to do things in whatever way he likes as long as he stops suggesting that just because HE has problems with some technique, that technique is not valid for anyone else and therefore should be avoided.
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 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.
midrange.com
