----------------------<snip>---------------------
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...
---------------------<unsnip>---------------------
I've always used two dynamic queues for this: a "waiting for service"
queue and a "Service complete" queue, managing the chaining via CS. Only
the mother task was allowed to create new elements or discard completed
elements. Also had two ECB's; one could be posted by the mother task to
inform subtasks that work was ready and the second posted by the subtask
to tell mother that work was complete. When I needed another subtask, I
just added another ECB pair and let it use the same two queues. The
mother task did all the terminal I/O (BTAM to 2260 terminals) and the
various subtasks each had specific calculation functions; restults were
passed back to the mother task, who then sent them to the appropriate
terminal. It was an attempt to emulate the old WANG calculators that so
many college engineering departments seemed to have. We had the
2260/2848 equipment; why not try to use it. I used multiple subtasks
because sometimes a user request would entail DASD I/O and let's face
it, 2314's weren't exactly blinding with their speed.
----------------------------------------------------------------------
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
