Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
buggabill Absent Member.
Absent Member.
2719 views

RESIDENT and CANCEL ALL

Jump to solution

I was wondering if a program that is made resident by including the RESIDENT clause in the PROGRAM-ID paragraph will remain in memory after it exits using an EXIT PROGRAM.  If not, can I exit from the program and remove it from memory?  I need to shield a program from a CANCEL ALL in a called program.

I have a BIS service program calling another program that is calling a final program that has a CANCEL ALL in it that is resetting the XML object in the initial service program.  This is pretty highly undesirable as BIS core dumps and dies when trying to do an XML EXPORT FILE.  

0 Likes
2 Solutions

Accepted Solutions
DougP Outstanding Contributor.
Outstanding Contributor.

RE: RESIDENT and CANCEL ALL

Jump to solution

Yes @buggabill, you can toggle the CANCEL_ALL_DLLS setting within your application with the SET statement.

View solution in original post

0 Likes
Chuck Edgin Absent Member.
Absent Member.

RE: RESIDENT and CANCEL ALL

Jump to solution

A bit of a correction: a program invoked by BIS (ProgA in the scenario above) is NOT really a main program. It's effectively CALLed by the BIS Service Engine. I just confirmed this in a BIS program, using a call to C$CALLEDBY, which returned -1 (meaning "Caller unknown; routine not called by a COBOL program"). A main program will return 0, and a program CALLed by another COBOL program will return 1.

I also confirmed that a CANCEL ALL in a called subprogram causes my initial service program to crash on an XML EXPORT FILE statement. But adding CANCEL_ALL_DLLS=FALSE in my cblconfig prevented the crash.

@buggabill, I don't believe a SET ENVIRONMENT statement will just affect the program in which it's executed; rather, it should effect the entire run unit. As Doug states, you can toggle it on and off, but each time it's toggled the new value will affect the entire run unit.

View solution in original post

0 Likes
6 Replies
DMiller1 Absent Member.
Absent Member.

RE: RESIDENT and CANCEL ALL

Jump to solution

Why hasn't this one been answered yet?

Here's how I understand it...

The resident program will remain in memory after the exit program statement returns processing control to the parent program.  A cancel all statement does not cancel a resident program.  The only way to cancel a resident program is by using an explicit cancel statement, cancel "<resident prog>".  

0 Likes
DougP Outstanding Contributor.
Outstanding Contributor.

RE: RESIDENT and CANCEL ALL

Jump to solution

This is a bit more complex than I first thought.  Please correct my understanding if it is wrong.

To clarify, you have a BIS program, let's call it ProgA, which calls another program, ProgB, which calls another program, ProgC.  ProgA calls either a DLL or shared library to create an XML object and a CANCEL ALL in ProgC is affecting that XML object.  

In this scenario, adding RESIDENT to ProgA will have no effect.  RESIDENT is used to keep called COBOL programs in memory and shielded from CANCEL statements.  ProgA is not called, it is the main program and so will always remain in memory during the life of a specific runtime process.  

Because it is the main program ProgA should never be affected by a CANCEL statement.  However a DLL or shared library called by ProgA would be affected.

You may be able to clear this up by adding "CANCEL_ALL_DLLS FALSE" in the runtime congifuration file.  This should exclude the DLL or shared library from the CANCEL ALL.

0 Likes
buggabill Absent Member.
Absent Member.

RE: RESIDENT and CANCEL ALL

Jump to solution

@DougP - You are correct in your understanding of the issue.  I am using XML extensions.  Can I set this configuration variable for just the affected programs (i.e. programs using XML extensions) with something like this?

SET ENVIRONMENT "CANCEL_ALL_DLLS" TO "FALSE".

There may be occasions where I would want this type of behavior for a CANCEL ALL.

0 Likes
DougP Outstanding Contributor.
Outstanding Contributor.

RE: RESIDENT and CANCEL ALL

Jump to solution

Yes @buggabill, you can toggle the CANCEL_ALL_DLLS setting within your application with the SET statement.

View solution in original post

0 Likes
Chuck Edgin Absent Member.
Absent Member.

RE: RESIDENT and CANCEL ALL

Jump to solution

A bit of a correction: a program invoked by BIS (ProgA in the scenario above) is NOT really a main program. It's effectively CALLed by the BIS Service Engine. I just confirmed this in a BIS program, using a call to C$CALLEDBY, which returned -1 (meaning "Caller unknown; routine not called by a COBOL program"). A main program will return 0, and a program CALLed by another COBOL program will return 1.

I also confirmed that a CANCEL ALL in a called subprogram causes my initial service program to crash on an XML EXPORT FILE statement. But adding CANCEL_ALL_DLLS=FALSE in my cblconfig prevented the crash.

@buggabill, I don't believe a SET ENVIRONMENT statement will just affect the program in which it's executed; rather, it should effect the entire run unit. As Doug states, you can toggle it on and off, but each time it's toggled the new value will affect the entire run unit.

View solution in original post

0 Likes
buggabill Absent Member.
Absent Member.

RE: RESIDENT and CANCEL ALL

Jump to solution

Thanks!  Your help is much appreciated!

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.