On Wed, Aug 28, 2013 at 6:53 AM, John McKown <[email protected]>wrote:
> And one thing to remember is that the main task, in the PAUSE/RESUME or > WAIT/POST must "poll" for communications from the subtask. I have not used > PAUSE/RELEASE, but it appears that, unlike WAIT/POST, the task doesn't have > a way to "poll" to see if something has sent a message. I.e. when the main > task does a PAUSE, it stops until something does a RELEASE or a TRANSFER. > This may or may not be acceptable. > > Pause/Release has an API to test the status of a Pause Element Token. This can be used to implement polling if it is needed. > Being my own weird self, I might consider using UNIX IPC. This could be via > UNIX message queues. Or perhaps semaphores. > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb1c0/2.104 > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb1c0/2.163 > > The above will work both between tasks in a single address space and tasks > in separate address spaces. But you might need to change from ATTACH to > POSIX threads. I'm not sure. These options are much more attractive if you > are using the C language instead of HLASM. I don't recall if you use C or > not. > > > > > On Wed, Aug 28, 2013 at 8:16 AM, John Gilmore <[email protected]> wrote: > > > I recommend that you use the PAUSE/RELEASE pair instead of WAIT/POST. > > > > The WAIT/POST pair is, like GETMAIN/FREEMAIN, lumbered with the > > detritus of the ages, much of it ugly. > > > > Let me also add that another important, in some contexts crucial, use > > of subtasks stems from the fact that failures within them are less > > catastrophic. Suppose that task A attaches subtask B and that subtask > > B in turn attaches its own subtask C. Now if C fails/ABENDs, A and B > > survive; and if B fails A survives [B and its subtask(s), C here, are > > terminated]. > > > > The idea of relegating perilous undertakings, those that may fail, to > > subtasks that do not bring down the whole shebang when they do in fact > > fail is thus a very useful one. (This same recoverability argument > > can sometimes make the use of multiple address spaces highly > > desirable, but I am not sure you are quite ready for that.) > > > > > > John Gilmore, Ashland, MA 01721 - USA > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > > > -- > As of next week, passwords will be entered in Morse code. > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
