Date: Fri, 07 Sep 2001 06:52:15 -0400 From: madodelatptdprolog.net Subject: [VOICENWS] WARNING: DB2 UDB for OS/2 Versions 5, 6 and 7: DB2 Backups Using USEREXITs May Fail From: "Timothy Sipples" IBM is notifying you of a potential problem with DB2 UDB for OS/2 Versions 5, 6 and 7 that may cause DB2 backups using USEREXITs to fail on or after September 8th or 9th, 2001, based on the timezone the machine operates under. This may require you to either install a fix or to follow a workaround procedure to circumvent the problem. Please forward the attached note to all affected users immediately. Problem: On September 8th or 9th, 2001 (i.e., 21:46:40 Sept 8 EST (Toronto time) or 01:46:40 Sept 9 GMT), the 32-bit time value gains a digit to go from 999999999 to 1000000000. The exact time of the failure will depend on which timezone the machine operates under. The result is that DB2 will not pass the fifth parameter, the MODE or sequence #, to the BACKUP USEREXIT. As a result of this, after this date/time database backups on OS/2 via a USEREXIT for a database alias of 8 characters will no longer work and as such a backup will not be taken. The error or message seen will depend on how the USEREXIT is coded. If you are using the default USEREXIT, you will see an invalid parameter error being reported by the USEREXIT. DB2 Products affected: This problem is only related to the OS/2 platform and does not affect other USEREXITs (eg. LOG) or backups taken without USEREXITs. Impact: Inability to perform DB2 UDB backups on OS/2 via a USEREXIT as of September 8th or 9th, 2001 (i.e., 01:46:40 Sept 9 GMT, or 21:46:40 Sept 8 EST). Resolution: Apply DB2 UDB for OS/2 APAR JR16294 or use the suggested workaround. Fix Availability: Fix Status for releases currently in service: The fix for this problem has been uploaded to the DB2 UDB FIXPAK FTP site in the OS/2 directory for each release currently in service and we are developing a fix for V5 (out of service). The patched DLLs are stored in the archive file JR16294.zip. All national language versions use the same patch. A readme in the same directory (English only) is available to outline the problem/workaround/patch installation (JR16294.TXT). Location of FIX for V 6.1 FixPak 8: ftp://ftp.software.ibm.com/ps/products/db2/fixes/english/db2os2v61/FP8_WR21255/ Location of FIX for V 7.1 FixPak 3: ftp://ftp.software.ibm.com/ps/products/db2/fixes/english/db2os2v7/FP3_WR21251/ Note that this fix can only be applied to specified FIXPAK levels (FixPak 3 for V7.1 and FixPak 8 for V 6.1) and will not correct the problem for customers on special/private builds. They will either need to upgrade to one of these levels before applying the patch or will need to use the workaround until the next FixPak is made available. Fix Status for releases which are not in service (V5 only) where customers may have a service extension: Location of FIX for V 5.2 FixPak 16: A fix is being developed and will be uploaded to ftp://ftp.software.ibm.com/ps/products/db2/fixes/english/db2os2v5/FP16_WR21262/ location. The fix will be in a file called "db22v5_JR16294.zip" and a readme in the same directory (English only) will also be available to outline the problem/workaround/patch installation (JR16294.TXT). We are expecting to have this fix developed and uploaded by end of day Friday, September 7, 2001, Toronto time. Note that this fix could only be applied to V5.2 FixPak level 16 and will not correct the problem for customers on special/private builds. They will need to use the workaround. TCO Customers can use one of the following options: - Upgrade to one of the above listed levels and apply the available patch for your Version/FixPak level. - Contact your local DB2 support organization and provide all the service/build level for your TCO to request a special fix. In the meantime, you may have to use the workaround to circumvent the problem until a fix can be made available for the requested TCO level. Workaround: Catalog another database alias to your database using 7 characters or less and use this database alias for performing your backups. You must ensure that the restores are performed using the same database alias as was used for the backup. By cataloging a separate alias, you avoid having to reconfigure all your remote database clients, making it transparent to your users. Questions: Use the standard 24X7 BAU service and escalation procedure to contact your local support organization. ----------- To unsubscribe yourself from this list, send the following message to majormajoratos2voice.org unsubscribe news end If you have an announcement you would like posted to the VOICE News list, please send it to submitatos2voice.org. Please include a valid reply address and a real contact name. If you wish to comment on this post, please reply to feedbackatos2voice.org