Peter Relson wrote:
Our standard position with respect to ISVs is that if they encounter an IBM problem due to their use of dirty getmain, we will try to fix it. The CICS situation that Jim Mulder mentioned is, I hope, more the exception than the rule. Clearly if problems do not get fixed, then you will be turning off dirty getmain as you can't do your own work if on an unstable system, and thus not getting any of the testing benefit that dirty getmain can provide.
I have an IBM program product (PSF V3) that won't work with IgvInitGetmain active. I reported the "bug" years ago and they didn't take my complaint seriously. So, I resolved that we would no longer spend money on PSF upgrades until some incompatibility forced us to. (So far, so good on that front.) I honestly don't know if they ever fixed this problem in later releases. Based solely on their attitude toward my request, I would guess not. But, stranger things have happened.
Please note also that dirty getmain does not try to be omniscient. It is a fact (but not a documented promise) that the first getmain done under a job for a user-region subpool will get 0's, simply because of the "free region" done between jobs.
If this behavior isn't documented, then what difference does it make? A program that depends on this behavior is no different than one that depended on undocumented alignment properties from pre-z/OS 1.10 GETMAIN behavior.
Dirty getmain may not note that and may "dirty it". A program that relied on that behavior would technically be "correct" but would not work with dirty getmain active. We tend to try to remove that reliance just so that other programs can use dirty getmain, We want the system to be usable with dirty getmain active, we just cannot guarantee it. If there were the notion of "here is something for your sandbox system, please let us know if you find some problem, but we cannot promise to take an APAR to fix it", is that something that would work for you? Many of the DIAGxx traps would fall into that categorization. This notion is, sort of, the "agreement" we have with the ISVs. I'm not speaking legal-ese because I don't know how.
As Jim noted earlier, the TRAPS for "dirty" IARST64 and "dirty" IATCP64, implemented via: IarCp64InitFree, IarCp64InitGet, IarCp64Trailer, IarSt64InitFree, IarSt64InitGet, IarSt64Trailer, are documented to customers in http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e290/27.6. All that's needed is for IgvInitGetmain, IgvInitFreemain, and IgvInitCpool to be added to the list.
-- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- 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
