• No replies
403 Posts

Pinned topic On the use of CANCEL in CICS programs

‏2012-07-11T13:57:01Z |

New to to the COBOL Café. I am the sysadmin (formerly known as MVS systems programmer) at an insurance company. Some of our developers use a CANCEL verb right after a dynamic CALL w-program, presumably to get the program to an initial state on the next CALL. To make things more confusing they also specify the program as INITIAL. I always insist that, to my knowledge, the CANCEL verb should not be used in CICS programs. In the IBM documentation I have not found specifics on this issue.
Perhaps the COBOL gurus out there in the Café can help me out with this one.


Gilberto Rodriguez-Rivera
Interactive Systems Inc, San Juan, Puerto Rico
Updated on 2012-07-11T18:41:02Z at 2012-07-11T18:41:02Z by dbzThedinosaur
  • dbzThedinosaur
    57 Posts

    Re: On the use of CANCEL in CICS programs

    INITIAL in the PROGRAM-ID paragraph has the same effect as a previously CALLed program that has been CANCELed.

    thus it is redundant to CANCEL a program with the INITIAL attribute.

    In a CICS environment where data division and procedure division are loaded into separate areas,
    CANCEL means that during subsequent CALLs both data and procedure are RE-LOADed from disk and control blocks built.
    INITIAL means that the data is INITIALIZED, PERFORM mechanisms are reset and ALTERed GOTO's are reset without the required re-LOAD and control block building - which takes time.

    It is a trade off between INITIAL and re-entrant code
    (re-entrant code is code in 'HOUSEKEEPING' that initializes the required data division entries so that subsequent CALLs to the module are not affected by values left over from the last CALL)

    I have always implemented re-entrant code. Initializing Data Div entries via code should not be that difficult. There is no need to initialize COBOL Internal Tables. Regardless of fixed-length or ODO, maintain a counter of active items. New items are always populated by MOVE.

    CANCEL can become problematic in OO or multi-enclave applications.

    using CANCEL when there is no CALL chain, instead many CALLs to sub-modules from a 'driver' module, does reduce storage requirements for the task,
    but here the trade-off is between the actual storage required for the multiple 'unCANCELd' modules waiting for task termination
    VERSUS the time required for the system to modify control blocks.

    have no idea what you application and system looks like,
    so I am reluctant to make any suggestions other than to research what your programmers tell you and take it with a grain of salt.

    That they are using both CANCEL and INITIAL tells me that there only claim to being slick is their BS. If they want to CANCEL a module that is only CALLed once during the task thus reducing storage requirements in a very tight system, I am not going to say that it is wrong/bad. But personal experience with CALL chains sometimes exceeding 40 or 50 modules in a high impact environment only meant that the storage requirements where higher than if everything was CANCELed.
    A first time CALL will load, build control blocks and transfer control.
    subsequent re-CALLs without INITIAL will just transfer control.
    subsequent re-CALLs with INITIAL with 'rewrite' DATA Division and transfer control.