On Wed, 23 Jan 2008 00:10:57 -0500, Craddock, Chris <[EMAIL PROTECTED]> wrote:
>... >Yes because leaving aside the "quirks" with the current wait/post >mechanism, the wait/post logic is at best, half of the problem in any >true multitasking code. ... Sorry to be falling way behind in my pedantary. Work got in the way. My only point here was that your strongest complaint seems to be the lack of the queing mechanism. IBM has chosen to consider the queuing and shoulder-tapping as 2 separate issues (and left the queuing mechanism as an excercise for the reader) so your complaints about the format of the ECB and the fragility of wait/ post (or EVENT, as recently mentioned) sort of miss the mark. For those of us that have developed our own simple queuing mechanisms, wait/post logic works fine. It would be nice if IBM had decided to give us a queing mechanism (not, not MQ), but its lack is not the fault of post/wait. >... Obviously I am talking about more complex >software than you would perhaps see in an exit or a simple application >where you would use wait and post pretty sparingly if at all. I am >biased to that end of the problem domain because "it's what I do." >... I have no experience with cross-memory issues - just multitasking within a single address space. And I let VTAM handle the details of task scheduling. >If you really do have multiple units of work that need to coordinate >their processing then you need; not only a way to poke the other guy in >the arm or wait for a poke in the arm, but you also need something that >doesn't allow you to miss a poke in the arm. In other words, you need a >predictable and reliable means of passing data back and forth between >the poker and the pokee... >... I don't pretend to have much experience here, but in my case it was obvious that a queueing scheme was needed, and the subtasks had to awaken a waiting main task to process the queue. And it was obvious that it didn't matter how many times the main task was posted before it was dispatched if the queue contained all the information necessary for the main task to do its work. >Ed Jaffe has previously described the problem and its solution >accurately. He knows what he's talking about! ... Just for the record, I don't think anybody in this thread has suggested that about Ed (or you). But I don't think the major problem is with wait/post. >... ...ANY solution based >on the >algorithm he described will work just fine in spite of all the "quirks" >with wait/post. And it is that part of the solution that is completely >missing from z/OS. No system mediated service does anything like that >except (arguably) the WLM work queueing services. (Blech) >... And I think you just agreed with me. :-) >Without a system mediated solution the problem is twofold. Most people >who have only a casual acquaintance with multitasking miss all these >fine details and get flaky code for their trouble. The folks who DO >understand end up reproducing the same queuing code over and over... >Eventually we get tired of it and wrap the whole mechanism up in some >helpful code and make it an infrastructure service. It sure would have >been nice if the OS had supplied the missing parts of the solution 30 >years ago. > Have you submitted a requirement? :-) Pat O'Keefe ---------------------------------------------------------------------- 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
