db2vend crash or generating trap during DB2 backup or restore

Problem with bundled gskit code. The fix is in gskit 8.0.13.4. Tivoli Storage Manager API added gskit 8.0.13.4 in 6.2.2 API. This resolves the crash issue described in apar IC67672 . With the fix for IC67672 applied, the DB2 backup and restore may still generate a trap file. This is because DB2 uses its own gskit and to date, DB2 has not bundled gskit 8.0.13.4 in their code yet.

DB2 backups using Tivoli Storage Manager API client v6.2 to a Tape Storage.

DB2 backup or restore from a Tivoli Storage Manager creates traps. Example of a trap:


DB2 build information: DB2 v9.7.0.2 s100514 SQL09072
timestamp: 2010-11-02-10.48.28
Process name: db2vend (db2med - 66910 (TEDB1))
Signal #4
uname: S:AIX R:1 V:6 M:0005A5E3D600 N:HDQPS104
process id: 913410
thread id : 1 (0x1)
kthread id : 6377571
</Header>
<SignalDetails>
<Siginfo_t length="64">
00000004 00000000 0000001E 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
</Siginfo_t>
Signal #4 (SIGILL): si_addr is 0x0000000000000000, si_code is 0x0000001E
(ILL_ILLOPC:Illegal opcode.)


DB2 plans to add gskit 8.0.13.4 in DB2 9.7 FixPack 5, not yet released. The following option can be used with the Tivoli Storage Manager 6.2 client to work around the issue:

• Add the following line in the “dsm.opt ” file:testflag noaes

• • /<opt or usr>/tivoli/tsm/client/api/bin directory if DB2 is 32bit
  • /<opt or usr>/tivoli/tsm/client/api/bin64 directory if DB2 is 64bit

Note: The dsm.opt should be the one defined as “DSMI_CONFIG” or by default:

Note that with the “testflag noaes” option, the Tivoli Storage Manager API client is not able to do 128-bit encryption or client deduplication.