>From z/OS 1.7 Migration, topic 5.2.9 "Remove CUNUNIxx parmlib members when Unicode is used for TCB callers":
"Description: As of z/OS V1R7, enhancements made to z/OS support for the Unicode Standard no longer require you to run the image generator program to create a conversion image and to customize the CUNUNIxx parmlib members with that conversion image name. As of this writing, these enhancements are made only for those callers that run in TCB mode. SRB mode callers, such as DB2, are not included in this support at this time." Further, after APAR OA14231, the restrictions mentioned in the above paragraph are eliminated. Now, "Unicode On Demand" dynamically builds any required Unicode conversion tables for all callers. I always disliked having to predict which conversions my applications might use. How could any sysprog possibly know what conversions might be needed in applications? I certainly don't! "Unicode On Demand" is a very compelling concept to my point of view! On my systems, this works just fine (z/OS 1.7), with one current issue: If more than one DB2 V8 subsystem happens to start at exactly the same time at IPL, the one-time initial dynamic installation of Unicode doesn't quite work right, and the DB2 V8 startup fails (ABEND04E RSN00E80084). The failure is very early in DB2 startup, and DB2 does start successfully the second time, because the dynamic installation of Unicode for DB2 is a once-per-IPL event. In any event, APAR OA19072 will fix this (minor) problem. Brian On Tue, 5 Dec 2006 04:17:30 -0600, Dave Cartwright <[EMAIL PROTECTED]> wrote: >I'm just building our ZOS1.7 system to eventually replace 1.4, and I just >want to say that the berk who put a thirty thousand record member in >PARMLIB is a right SYS1.SCUNTBL. > >Dave ---------------------------------------------------------------------- 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
