>So, my question is, are there any repercussions changing to USEZOSV1R9RULES( >NO) for shop running, lets say z/OS 2.2 + all OEM products up to date with >compatibility? >we're not a large DB2 shop be most of our workload is DB2, DB2 data sharing in >a 3 system sysplex. >any recommendations?
We have been running with USEZOSV1R9RULES( NO) for the past 1.5 years, ever since I set it when I joined the company. We did not have any issues, and we run mostly DB2 in addition to homegrown stuff. If you go back in the archives you'll find the discussions about that parm in detail. The 'side effect' (IIRC) of setting the parm to NO and using the better performing behavior is that VSM now doesn't clear the storage it hands out to binary zeros anymore (only for the cases explicitly stated in the documentation). So if you have a home-grown application that has relied on getting hex zeros despite not having followed the docs, that may lead to some rude awakening because there might be some residual storage left that wasn't cleared. These days I would guess it is only home-grown applications that would suffer any problems. Back when the parm first came out, I used the (undocumented except partially on ibmmain) DIAGxx traps that fill any storage (and registers and the PSA) with hex FFFFFFFF to attempt to test our applications. I found a number of OEM products that abended with abend0c4/0C6/0C1, but one of the home-grown Assembler exits was also falling all over itself because it wasn't coded correctly. I am sad to say that MEMDSENQMGMT has escaped my notice. I'll turn that on in the sandplex and see how it goes. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
