>We IPLed our testsystems with the traps on this morning and had some >great fireworks (TSS)! > >Just to be sure: do the traps only pollute storage that is not >documented to be set to zeros? In other words, do they leave storage >unmodified that is documented to be returned initialized to zeros?
Yes. Definitely. These traps help detect if not-initialized storage is used on *assumptions* (of content). Storage *documented* to be initialized will not be handed out 'modified'. The documented rules haven't changed. Any *assumption* made on zeroed storage (when it is not documented to be zeroed) has always been wrong. The code just got away with it. Actually, some of these getmain-related traps have a freemain-related trap, ie. VSM will reset the fffff pattern after something was freemained. Those I know of are these: IgvInitFreemain IarSt64InitFree IarCp64InitFree >How about putting these settings in a Informational APAR II##### as a >suggested debugging technique? I doubt that IBM would do that. The reason behind not documenting something is usually that IBM doesn't want to be obliged to take apars if something in the code happens to be wrong. (Same thing with IPCS - the undocumented panels/code are not documented for this reason. Plus a lot of 'internal debugging' is not documented for this reason.) If you can create an info apar in IBMs database, go right ahead (back when I was level2 in Germany, we weren't allowed to create info apars. Only the US had that authority.) Regards, Barbara Nitz ---------------------------------------------------------------------- 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
