|
IBM notifica acerca de un problema potencial con las versiones 5, 6 y 7 de DB2 UDB para OS/2 que pueden causar errores durante las copias de seguridad al utilizar USEREXITs o después del 8 o 9 de Septiembre del 2001, basados en los husos horarios en los cuales opera la maquina. Esto podría necesitar corrección mediante la instalación de un parche (fix) o bien seguir un procedimiento de rodeo para burlar el problema. Rogamos envíen la siguiente nota a todos los usuarios afectados inmediatamente.
(El resto del mensaje permanece en ingles original).
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.
| 
