Message CAL0999E issued in Task output
Article ID: 29170
Updated On:
Products
Issue/Introduction
What does it mean when I receive the CAL0999E message?
Resolution
To explain what the problem is and the requirements for dynamic intercepts.
First, the logic that CA 1 uses (and most other vendors that do similar dynamic intercepts) is that within a single load module we might "intercept" as csect A passes control to csect B. So, instead of A going to B, it goes to CA1 and then back to B. So, with our dynamic intercept installed, the path is now A to CA1 to B. In order to do this, we save the address we found that csect A normally passes control too (csect B's address) and then we pass control to it after we got control.
Second, is the validation issue. We know that we installed our intercept (so A passes control to CA1), and we validate that the address that csect A passes control to is still CA1. If it isn't, we issue the CAL0999E (Intercepts are not active) error message.
Now, what happens if another product (same vendor or different) uses the same technique and ALSO wants to capture csect A going to csect B. If CA 1 is already installaed they do the same thing that we did, but NOW, instead of saving off the address of csect B they are really saving off the csect of CA1 (since we had already inserted our intercept). So now the path is actually (using DST as an example), csect A goes to DST goes to CA1 goes to B. Everything is fine, everyone gets control.
However, when we (CA1) goes to validate that our intercept is still installed, we find that csect A is pointing to DST. So we report an error (the CAL0999E message). Everything is fine, and we will get control; we are reporting a problem that doesn't really exist. That is what the published maintenance will correct. So that if CA 1 is installed first, and DST is installed after, we will NOT report any errors with the intercepts.
Now, using the example mentioned before were CA 1 is installed first and DST is installed second; and the path is csect A to DST to CA1 to csect B. What happens when you want to remove a product? If you remove CA 1, we will put back into csect A the address we had found (csect B). So now it is back to csect A to csect B. When CA 1 is dynamically removed, we also removed the DST intercept. However, if you had removed DST first the path would be csect A to CA1 to csect B. And then if you removed CA 1 it would be csect A to csect B. The bottom line here is that dynamic intercepts MUST be removed in the reverse order they are installed. So, if CA 1 is always installed before DST, you must remove DST before you remove CA 1. You can then re-install DST by itself; and even re-install CA 1 dynamically after DST has been installed.
So, IF there is a need to remove a product that has dynamic intercepts AND the dynamic intercepts affect modules that also have dynamic intercepts from other products, the removal must be done in a LIFO order (Last In, First Out).
Lastly, as with most IBM operating system programs, there are many csects within a single load module. The load modules that CA 1 has dynamic intercepts into are the following;
IGC0001I - OPEN processing
IGC0005E - EOV processing
IFG0194A - OPEN processing
IGC00020 - CLOSE processing
IGFDI0 - DDR Swap
IEFW21SD - Allocation/De-allocation
IFG019RB - New IBM OPEN/CLOSE/EOV/Label Anomaly exits
IGC0006C - Checkpoint Restart
IGC0002F - Catalog processing
Some of these load modules might only have a single intercept (A to B), others might be installing/checking multiple intercepts (A to B, C to D, and A to D).
So to recap; the published maintenance RO41064 and RO41365 from Release 12.6 and will prevent CA 1 from reporting the missing intercepts (CAL0999E) when DST is installed after CA 1. And when removing products that have dynamic intercepts you must always use a LIFO order (Last In, First Out) when removing the products.
Feedback
