Barbara, I disagree on some points in this part of the discussion:
> > >>Setting this up as a > >>started task and then explaining to Ops/Automation that the only way to > >>stop it was to Cancel the Started task was not fun (against their > >>operational procedures) .... > >Shutting down a Started Task can be done in the way other STCs are > >controlled. You can issue a WTOR which allows the request to shut > >down to be sent or you can just use the Modify (F) or STOP (P) > >command . If MODIFY is good enough for TCP, TSO, etc, it should be > >good enough for your RYO STC. It sounds like those Ops/Automation > >types are brain dead and do not understand what they are doing. > > No, I don't think so. MODIFY can easily tie up the CSCB for the address space, > and then you get some sort of error message when you retry any command. That is: MODIFY REJECTED, TASK BUSY. This menas that the task has not provided a new CIB to receive a new MODIFY command. > There needs to be programming done to prevent this. > There is no basic difference with WTOR: after a MODIFY command, the application must process it and provide a new CIB to be able to receive a new MODIFY. The same applies to WTOR: the application must process the reply and set out a new REPLY. If it does not act this way, the results are the same in both situations: an STC with which you cannot communicate anymore. > And a cancel can also easily have been mandatory when the stop command > was accepted, but the address space just goes to sleep waiting for something > that will never happen. The next stop has no effect. So you have to cancel. > Both for WTOR and MODIFY. > You obviously have never been in the situation where you stop and things > hang, you stop again, nothing happens. You cancel, the thing says 'cancel > command accepted' and then it hangs again. In fact MVS says "CANCEL COMMAND ACCEPTED", sets a bit in the appropriate TCB and goes on with its work, supposing that the task will respond neatly to this CANCEL bit, but guarantees nothing. > You try force and are told that > you haven't force arm'd first. You try force arm and are told that you cannot > force arm the asid. Or you get another hang. In your desperation you dump > the address space and then assemble the callrtm program with different tcbs > in hopes that it will go. > > Best regards, Barbara > So in the end there is no basic difference between WTOR and MODIFY for the programming in the application, but there is a great difference for the operator, constantly having to ignore the WTORs poluting his/her screen. Kees. ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- 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
