Edward I detect some failure properly to make an effort to understand the point *I* was trying to make!
The reason for the delay is that I have now taken the trouble to read your excellent presentation material on the topic in hand. I am quite able to interpret this as CANCEL being the only option when the program has not made provision - such as through support for STOP (or MODIFY) - for arranging program termination - and you just about say precisely that. However you go on to deal with the rarer cases - I would submit, m'lud - where NOCANCEL has been imposed by a PPT or SCHEDxx entry[1] which require what to an unbiased jury would surely be considered a "sterner" command - not just semantically - since FORCE is to bypass the strictures the system designer has placed on the use of the CANCEL command. It may look and feel different to someone at the MVS coalface but from the surface CANCEL and FORCE (ARM) look like different levels of severity. And don't bother to point out that FORCE and FORCE ARM should not be placed too close together. Remember I have read your excellent presentation! I wondered if there might be a command which could be used to display which of the CANCEL or NOCANCEL "attribute" had been specified. I couldn't find one - which is a shame and seems to introduce a "requirement". does it not? However, it is possible to check through the PPT table and applicable SCHEDxx entry so that someone setting up automation would be able to discover which of CANCEL or FORCE ARM was required - having first established from the product documentation that no other command was available. I remember when setting up my fully automated MVS startup (and shutdown) - including a switch of JES2 environment - for my test/education systems, I managed to test it all out thoroughly little by little.[2] I can't imagine that any *professional* automation would need to try one command and then try an alternative when only one ever always applied. Having said that it all ought to be predictable, I seem to recall that I did have to build in a cycle on shutting down JES2 for some reason of which I never got to the bottom. Chris Mason [1] Your presentation doesn't actually mention a SCHEDxx entry as an alternative to or override for a PPT entry - tut! tut!. [2] Using NetView. I even had to create messages which "stayed" on the console only during the period a particular startup (or shutdown) step was in progress - since otherwise no messages appeared until the automation process was complete. On Thu, 30 Sep 2010 16:05:32 -0700, Edward Jaffe <[email protected]> wrote: > On 9/30/2010 3:38 PM, Chris Mason wrote: >>> Only CANCEL is/can be independent of the program. >> Incidentally the "can be" was to cover the possibility I imagine may exist >> for >> the program to intercept the CANCEL which - come to think of it - may give >> rise to the need for sterner "commands"! > >I think you missed my point, which has nothing whatsoever to do with programs >that "intercept" CANCEL. Also, FORCE ARM is not a "sterner" command than CANCEL. >(That would imply some sort of non-existent hierarchical relationship between >CANCEL and FORCE ARM.) > >This case is strictly either-or--but you have to know in advance which one is >appropriate for the program with which you are working. I suppose in the case of >automation, one could try the most predominant case and switch to the other >command if the response so dictates. PITA. > >-- >Edward E Jaffe ---------------------------------------------------------------------- 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
