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
