No, there is no supported way to suspend alert generation. These alerts are probably generated because your SVCs are loaded on a different address during the IPL process. Most of the time, they are at the same location, but if you changed something in your system configuration, they might land on a different spot.
The way to temporarily disable all ExtMon alerts is to manually delete the current baseset. The next time, zSecure Alert will tell you that the baseset is gone, and suspend for one environment interval. But this is not a supported approach. Or you could ensure that your IPL process takes longer than the CKFREEZE retention period :-)
For 1603 in particular, it might be possible to tweak it such that it doesn't trigger right after an IPL. That might not be possible for other alerts.
We have this issue too...after every IPL we get alerts saying that most or all SVCs have been changed which is not helpful at all. If there is an RFE or something I would be happy to concur/vote for it.
Dan W Little | Senior Director, Mainframe Operating Systems | Mainframe & Midrange Hosting Services | Tech Infrastructure | Tech & Ops | RBC |
If you received this email in error, please advise the sender (by return email or otherwise) immediately. You have consented to receive the attached electronically at the above-noted email address; please retain a copy of this confirmation for future reference.
Si vous recevez ce courriel par erreur, veuillez en aviser l'expéditeur immédiatement, par retour de courriel ou par un autre moyen. Vous avez accepté de recevoir le(s) document(s) ci-joint(s) par voie électronique à l'adresse courriel indiquée ci-dessus; veuillez conserver une copie de cette confirmation pour les fins de reference future.
Hmmm, that's not exactly what I said. A change in the address indicates that something has changed in your IPL process. And as such it's not completely useless. The only SVC that normally jumps around is the one for ICSF, because it's installed dynamically, and is dependent on the timing of the ICSF start command.
I'm not in favor of simply discarding all extended monitoring alerts if it's the first compare after the IPL. Suppose that somebody inserts a new SVC, you'd definitely want an alert about that.
The minor change that I was thinking about, and that I needed to test was a change of the compare fields. For example, change the alert to compare not the address, but the first 256 bytes of the code. That might also trigger on an address change, but is less likely, and at least will continue to trigger on all significant changes, even across an IPL. I'll suggest to change the code accordingly.
Yes, a custom alert will do: in the compareopt, change curr_address into curr_contents (one line).
An actual product change might be FIN.
Yes, that's what I used in my testing, and it helped me get rid of some "false positives", especially the one for ICSF.
I guess it now goes beyond discussion in a public forum to determine what causes the alerts. For example, I would like to see which SVCs trigger the alerts, and the contents of the variables. That involves running some extra carla scripts using the temporary EM-CKFREEZE files (the one from before the IPL, and the first one after it).
One of the reasons that the alert still triggers might be that the SVC code has relocatable constants (addresses) in the beginning of the code.