I don't understand the reams of discussion about how to handle multiple threads working on a single ECB, or even a single thread spuriously posting an ECB. It isn't what it was designed for.
To me, saying that ECB is a poor design is like saying a bicycle is poor design because you can't use it to reasonably travel the 80 mile round trip to work and back. Just because you can't use it for a purpose you *want* to use it for doesn't mean it's poorly designed. Use it for the purpose it *was* designed for. If you want to do multiple task management, use a locking mechanism more suited to the task, like ENQ/DEQ or a spin lock if you can get away with it. Somebody mentioned that in Unix, there were half a dozen or so locking mechanisms that were incompatible with each other...So is also true on MVS. SETLOCK is incompatible with WAIT/POST is incompatible with ENQ/DEQ, etc. Locking mechanisms are designed to solve specific synchronization issues, with varying levels of performance and complexity, and you select the best one based on your needs. WAIT/POST is virtually identical in functionality to a unix mutex. Single waiter, single poster. It's efficient and does exactly what it is supposed to do. David Logan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Tuesday, January 22, 2008 7:36 PM To: [email protected] Subject: Re: How does ATTACH pass address of ECB to child? (1 Gerhard wrote: > Craddock, Chris wrote: > > Nope! After a normal post the compare value is going to be X'40000000' > > and the swap value is going to be 0. If another post intervenes and > > stores another X'40000000' in place of the first, then the compare is > > going to succeed and you'll miss a valid post. There's no way out of > > this dilemma. > > You're assuming that all POSTs will have the same completion > code; since this is program dependent, you have no knowledge of > the likelihood. A dilemma exists only in poorly implemented code. No, I am not assuming anything, but I can assure you the great majority of posts are going to be RC=0. In any case the actual value of the POST code is immaterial here. The point is that unless you somehow guaranteed some monotonically increasing sequence of post values, then CS will fail to "notice" an intervening update (by POST) with the same value because the compare portion is going to see the same value and compare equal. And there really is no way out of that. Do the thought experiment! OTOH if the application can guarantee that no two posts will be issued without an intervening clearing of the ECB then there is no problem. No doubt there are cases like that but they are the least common ones in real multitasking applications. If you really did need to use the ECB more than once, you were most likely going to have to deal with some sort of interlock between posting and clearing the ECB. Or do as you say below... > Either the POSTing task should wait for acknowledgment; or > > > In anything but the most trivial case you need more > > application logic combined with a queuing mechanism so that > > missing a post is harmless. > > Exactly. Usually that is handled by establishing a chain of work > requests (protected by CDS), followed by a POST that work has > been queued. Then multiple POSTs won't cause any harm. Er... that is exactly what I've been saying. So of course I agree :-) > In neither case is there a problem with the POST/WAIT design, > only its use. You might as well complain that a shared enqueue > doesn't protect you from changes. I've been using it a little while myself :-) and so I do agree that when used entirely within it's most tightly constrained boundaries "it works". But as I pointed out earlier there are many unobvious traps for the unwary. We've already seen several in the code fragments that have been bandied around in this discussion. Those pitfalls are not documented anywhere. The macro doc is silent. The assembly language programmer's guide is silent and nobody has yet written the definitive guide to where the bodies are buried in MVS. So application code and vendor code that "just works" (most of the time) is far more common than you would probably ever guess. I have probably diagnosed more problems in this one area than any other. So I conclude that most developers are just unaware of the inherent problems. That ought to be fairly compelling evidence of a poor design, or at least one whose nuances are nowhere spelt out for the casual user. Therefore, I argue that the original design was poor. And don't get me started on ENQ :-) CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
