A fix is available
APAR status
Closed as program error.
Error description
An unload statement specifying a LOADOPT option that contains the undocumented "INDDN (ddname)" form (with parentheses around the ddname)) of the INDDN ddname option stops with completion code of 8 after having issued a INZU039E FATAL SYNTAX ERROR message. This occurs if the maintenance for PI86871 (PTF UI52374) is applied. PB52967 Unload job using zIIP processors intermittently and rarely hang. This issue is intermittent and rare because it is a z/OS task serialization issue that occurs when the critical section of two sub-tasks overlap and more likely occurs during the unload of several partitions or table spaces or at the end of any unload. Failures can occur when output dataset to be written on tape are allocated through a TEMPLATE statement specifying the STACK(YES) or STACK(NO) option. - the tapes are released too soon, before cataloging, which causes the "tape report" to display erroneous information about the volumes and can lead to troubles when the files are cataloged or ABENDS0C4. - if STACK YES is specified, the file sequence number (FILESEQ) is unduly not incremented with can lead all the output datasets to be overridden by the output dataset written at the end of the unload process. Here is an example of the STACK(YES) specific issue. With an UNLOAD statement as follows: TEMPLATE SYSREC01 DSN MZLFD.TEST.TAPE.S&SEL. UNIT 581 STACK YES DISP(NEW,CATLG ,DELETE) UNLOAD TABLESPACE OPTIONS TEMPLATESET (SEL=:SELNUM) QUIESCE YES LOCK YES DB2 YES PARALLELISM (10,10,10) SELECT * FROM MZLFRD.TBDZBAFRD21601 OUTDDN(SYSREC01 ) FORMAT DSNTIAUL SELECT * FROM MZLFRD.TBDZBAFRD22501 ORDER BY 2 OUTDDN(SYSREC01 ) FORMAT DSNTIAUL system messages such as the following are issued, where FILESEQ is always 1 IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=1, COMPLETE VOLUME LIST, 916 DSN=MZLFD.TEST.TAPE.S00001,VOLS=R ,TOTALBLOCKS=9 IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=1, COMPLETE VOLUME LIST, 936 DSN=MZLFD.TEST.TAPE.S00002,VOLS=R ,TOTALBLOCKS=10 IEF234E D 0581,R ,PUB,Z1732,TAOHPU instead of the following expected messages IEC705I TAPE ON 0581,R,SL,COMP,Z1732,TAOHPU,MEDIA0 IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=1, COMPLETE VOLUME LIST, 155 DSN=MZLFD.TEST.TAPE.S00001,VOLS=R ,TOTALBLOCKS=9 IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=2, COMPLETE VOLUME LIST, 164 DSN=MZLFD.TEST.TAPE.S00002,VOLS=R ,TOTALBLOCKS=10
Local fix
remove the parentheses from INDDN(ddname)
Problem summary
**************************************************************** * USERS AFFECTED: * * Users of High Performance Unload * **************************************************************** * PROBLEM DESCRIPTION: * * PI96914: * * The "DB2 CATALOG VERSION" field from the INZI020I message * * displays an incorrect version instead of * * V12 CM and might lead to incorrect behavior of the unload. * * This occurs when the following conditions * * are fulfilled: * * - the DB2 subsystem the unload is run against is part of a * * data sharing group * * - the DB2 catalog has been migrated to DB2 V12 * * - the DB2 subsystem the unload is run against has not been * * migrated to DB2 V12 * * The incorrect version displayed by the INZI020I is Vnnn CM * * where Vnnn is the version of the subsystem * * involved in the unload. * * * * PI97568: * * An ABENDS0C4 can occur when unloading, in native mode, a * * table which contains a column defined with * * one of the following attributes: * * - WITH DEFAULT USER * * - WITH DEFAULT SESSION_USER * * - WITH DEFAULT CURRENT_SQLID. * * * * PI97698: * * In HPU versions prior to 5.1, the evaluation of the :SELNUM * * variable used in the data set names of * * templates involved in the unload of a set of objects defined * * through a LISTDEF statement (SELECT ... * * FROM LIST(...)) was made with two distinct algorithms * * depending on the setting of the * * ONDEMAND_RESOURCE_ALLOCATION subparameter. * * When ONDEMAND_RESOURCE_ALLOCATION(NO) was specified, the * * value of :SELNUM started at 1 and was * * incremented by 1 for each table to be unloaded. * * When ONDEMAND_RESOURCE_ALLOCATION(YES) was specified, the * * value of :SELNUM was reset at 1 for each * * new table space to be unloaded and incremented by 1 for each * * table of a given table space to be * * unloaded. * * * * For example, for a LISTDEF matching the following objects : * * - table space TSA with 1 table (TBA1) * * - table space TSB with 1 table (TBB1) * * - table space TSC with 3 tables (TBC1, TBC2, TBC3) * * the :SELNUM was generated as follows in HPU 4.3 * * - when ONDEMAND_RESOURCE_ALLOCATION(NO) * * + for TBA1 - SELNUM=00001 * * + for TBB1 - SELNUM=00002 * * + for TBC1 - SELNUM=00003 * * + for TBC2 - SELNUM=00004 * * + for TBC3 - SELNUM=00005 * * - when ONDEMAND_RESOURCE_ALLOCATION(YES) * * + for TBA1 - SELNUM=00001 * * + for TBB1 - SELNUM=00001 * * + for TBC1 - SELNUM=00001 * * + for TBC2 - SELNUM=00002 * * + for TBC3 - SELNUM=00003 * * * * With the algorithm for ONDEMAND_RESOURCE_ALLOCATION(YES) , * * the uniqueness of data set names requires * * an additional variable related to the UNLOAD number * * (:UNLNUM) or to the table space (&SP.). * * In HPU 5.1, as setting ONDEMAND_RESOURCE_ALLOCATION(NO) is * * deprecated, the related algorithm also * * becomes unavailable. * * As switching from one algorithm to another has impacts on * * the naming of the output file and may lead * * to failure of the subsequent processing that relies on the * * former naming or even of the unload job * * themselves when the uniqueness of the data set names was * * only ensured by the use of :SELNUM, the * * ability to choose, via a parmlib parameter, the algorithm * * that was used in HPU 4.3 when * * ONDEMAND_RESOURCE_ALLOCATION(NO) applied is given from HPU * * 5.1 on. * * * * PI98011: * * Unexpected rows can be unloaded when the following * * conditions are fulfilled : * * - a partitioned tablespace is involved * * - the data from a global (all partitions) image copy is to * * be unloaded * * - a output dataset per partition is requested * * - the INTERNAL format is requested * * The unexpected records are records from others partitions. * * The DB2 internal record prefix of some of * * these undesirable records may be altered. * * The problem more likely occurs if: * * - ORIGINOBID 0 is specified * * - the number of partitions and the number of records to * * unload is big * * * * PI98090: * * An ABENDS0c4 can occur if the unload statement contains at * * least one of the following item: * * - a WHERE clause with predicates involving * * DATE/TIME/TIMESTAMP data * * - a reformat request (requested either via USER format or * * REFORMAT or INTO clause) with * * DATE/TIME/TIMESTAMP source date type. * * * * PI98092: * * Unload job using zIIP procesors intermittently and rarely * * hangs. * * * * PI98105: * * An unload statement specifying a LOADOPT option that * * contains the undocumented "INDDN (ddname)" form * * (with parentheses around the ddname)) of the INDDN ddname * * option stops * * with completion code of 8 after having issued a INZU039E * * FATAL SYNTAX ERROR message. * * This occurs if the maintenance for PI86871 (PTF UI52374) is * * applied. * * * * PI98246: * * Failures can occur when output dataset to be written on tape * * are allocated through a TEMPLATE * * statement specifying the STACK(YES) or STACK(NO) option. * * - the tapes are released too soon, before cataloging, which * * causes the "tape report" to display * * erroneous information about the volumes and can lead to * * troubles when the files are cataloged or * * ABENDS0C4. * * - if STACK YES is specified, the file sequence number * * (FILESEQ) is unduly not incremented with can * * lead all the output datasets to be overridden by the output * * dataset written at the end of the unload * * process. * * Here is an example of the STACK(YES) specific issue. * * With an UNLOAD statement as follows: * * TEMPLATE SYSREC01 DSN MZLFD.TEST.TAPE.S&SEL. * * UNIT 581 STACK YES DISP(NEW,CATLG ,DELETE) * * UNLOAD TABLESPACE OPTIONS TEMPLATESET (SEL=:SELNUM) * * QUIESCE YES LOCK YES * * DB2 YES PARALLELISM (10,10,10) * * SELECT * * * FROM MZLFRD.TBDZBAFRD21601 * * OUTDDN(SYSREC01 ) * * FORMAT DSNTIAUL * * SELECT * * * FROM MZLFRD.TBDZBAFRD22501 * * ORDER BY 2 * * OUTDDN(SYSREC01 ) * * FORMAT DSNTIAUL * * system messages such as the following are issued, where * * FILESEQ is always 1 * * IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=1, COMPLETE VOLUME * * LIST, 916 * * DSN=MZLFD.TEST.TAPE.S00001,VOLS=R ,TOTALBLOCKS=9 * * IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=1, COMPLETE VOLUME * * LIST, 936 * * DSN=MZLFD.TEST.TAPE.S00002,VOLS=R ,TOTALBLOCKS=10 * * IEF234E D 0581,R ,PUB,Z1732,TAOHPU * * instead of the following expected messages * * IEC705I TAPE ON 0581,R,SL,COMP,Z1732,TAOHPU,MEDIA0 * * IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=1, COMPLETE VOLUME * * LIST, 155 * * DSN=MZLFD.TEST.TAPE.S00001,VOLS=R ,TOTALBLOCKS=9 * * IEC205I SYS00001,Z1732,TAOHPU,FILESEQ=2, COMPLETE VOLUME * * LIST, 164 * * DSN=MZLFD.TEST.TAPE.S00002,VOLS=R ,TOTALBLOCKS=10 * * * * PI98510: * * Fix#1 - An ABENDS0C4 can occur when unloading XML or LOB * * data as LOB files into partitioned data * * sets. The issue was on encountered on a z/OS 1.11 system. * * Fix#2 - Various and unpredictable failure occur when * * unloading a formerly compressed table space that * * has been altered to remove compression and not reorganized * * since then. * * Some of the identified symptoms are: * * - incorrect data unloaded * * - 227 * EXPRESSION EVALUATION ERROR * ddname * column name * * - ABENDS0C4 with traceback as follows * * 6 oenclaveWaitTerminatedThread * * -1DAE2010 INZU * * CEE3841I A statement number is not available * * 7 ozprocWaitForTerminated * * +000000A2 867 INZU * * 8 _inzzpiltWaitForOneTask * * +0000012E 4978 INZU * * 9 _inzzpiltWaitForAllTasks * * +00000124 5126 INZU * * 10 _inzzpiltUnload * * +00000200 3353 INZU * * 11 _inzzpiltUnloadThread * * +0000018A 1929 INZU * * or as follows * * 6 _oenclavePetWait_internal * * * * -1E17EB50 DBGUTILK * * * * CEE3841I A statement number is not available for this * * DSA. An internal routi * * 7 oenclavePetWaitProb * * * * +0000005E 768 DBGUTILK * * oenclave.h * * 8 oenclaveWaitTerminatedThread * * * * +00000386 1161 DBGUTILK * * oenclave.c * * 9 ozprocWaitForTerminated * * * * +000000B8 867 DBGUTILK * * ozproc.c * * 10 _inzzpiltWaitForOneTask * * * * +00000352 4978 DBGUTILK * * inzzpilt.c * * 11 _inzzpiltWaitForAllTasks * * * * or with no traceback and a shymptom dump as follows: * * SYSTEM COMPLETION CODE=0C4 REASON CODE=00000011 * * * * TIME=08.45.58 SEQ=17124 CPU=0000 ASID=00AF * * * * PSW AT TIME OF ERROR 078D2000 A00EFB8A ILC 6 INTC 11 * * * * NO ACTIVE MODULE FOUND * * * * NAME=UNKNOWN * * * * DATA AT PSW 200EFB84 - D2FD4248 625ED2FD 4346635C * * * * AR/GR 0: 00000000/00000000_00000000 1: * * 00000002/00000000_20089FBC * * 2: 00000000/00000048_200EE4F0 3: * * 00000000/00000000_1F41A950 * * 4: 00000000/00000000_203EE9C4 5: * * 00000000/00000000_00000444 * * 6: 1FEE0E10/00000000_20AA5BED 7: * * E9D3D6C7/00000000_000001A9 * * 8: 00000000/00000000_200EFA88 9: * * 00000000/00000000_20089FCC * * A: 00000000/00000000_20089FD0 B: * * 00000000/00000048_21C4A110 * * C: 00000000/00000048_1F462B5C D: * * 00000000/00000000_200EDD50 * * E: 00000000/00000000_9F4192B0 F: * * 00000000/00000000_1F462B5C * * Fix#3 - An ABENDU1017 occurs when unloading LOB data in SQL * * mode with the SPANNED YES option when the * * following others conditions are fulfilled: * * - the length of a LOB to be unloaded is greater than 65510 * * bytes * * - VUU041/ULOCSIZE > 65510 * * Fix#4 - Intermittent ABENDS30A-24 occurs during any HPU job. * * * * Fix#5 - HPU terminates in abend ABENDS0C4 with the following * * traceback: * * ohashLoad +00000022 506 INZUTILK * * _inzzpiltBuildTasksForPartitioned * * +0000061A 2392 INZUTILK * * _inzzpiltBuildTasksForParallelRead * * +00000314 2204 INZUTILK * * _inzzpiltUnload * * +00000136 3313 INZUTILK * * _inzzpiltUnloadThread * * +0000018A 1925 INZUTILK * * oenclaveBootXplink * * when the following conditions are fullfilled: * * - the unload is performed in native mode * * - a partition-by-range and a partition-by-growth are * * unloaded * * - the data from both tablespaces are to be unloaded into the * * same single (not a separate output * * dataset per partition) dataset * * - GBLPARAL YES and SUBTKSOF YES apply * * Fix#6 - An ABENDS0C4 occurs during the unload of the LOB * * data from a subset of the partitions of a * * tablespace. This occurs if the following conditions are * * fullfilled: * * - the unload is run in SQL mode * * - LOB data is to be unloaded * * - the SPANNED YES options is specified * * - the SQLPART option specifies less partitions than the * * table space involved in the unload has * * Fix#7 - An ABENDS0C4 occurs during a logical unload (OUTDDN * * opion) involving a conversion from a char * * constant to a * * char/varchar/graphic/vargraphic/binary/varbinary field too * * short to contain the whole * * data once converted to the output format. * * This occurs only if the following conditions are fulfilled: * * - the unload is performed in native mode * * - the character loss notification feature is enabled, i.e. * * the value determined from the * * CHARACTER_LOSS option from the OPTIONS block if any and from * * VUU071/LOSSCHAR in parmlib otherwise is * * different from IGNORE. * * For example, the following unload fails: * * GLOBAL OPTIONS CHARACTER_LOSS WARNING ; * * UNLOAD TABLESPACE * * SELECT '12345', ACCOUNT_ID, WITHDRAW * * INTO EXCERPT_ID CHAR(4) * * FROM me.mytable * * OUTDDN(SYSREC) * **************************************************************** * RECOMMENDATION: * * Apply the PTF for problem resolution * ****************************************************************
Problem conclusion
Code has been changed to fix this problem
Temporary fix
PI98011: None, but the data can be unloaded in INTERNAL format into a single dataset or into datasets per partition if another format can be used. PI98092: Rerun the unload job or consider disabling the zIIP processors use by specifying ZIIP OFF to avoid any occurrence of the issue. PI98105: Remove the parentheses from INDDN(ddname). PI98246: Allocate the output dataset using DD statements or consider unloading to disk. PI98510: Fix#2 - Reorganize the tablespace to remove compressed data from the underlying LDSes. Fix#3 - Set VUU041/ULOCSIZE to a value less than 65510. Fix#5 - Specify GBLPARAL NO or SUBTKSOF NO. Fix#7 - Solve the trivial truncation situation or accept it by specifying CHARACTER_LOSS IGNORE or force the SQL mode by specifying DB2 FORCE.
Comments
APAR Information
APAR number
PI98105
Reported component name
DB2 HI PERF UNL
Reported component ID
5697F4400
Reported release
510
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-05-17
Closed date
2018-06-19
Last modified date
2018-08-27
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI56696
Modules/Macros
INZUTILK
Fix information
Fixed component name
DB2 HI PERF UNL
Fixed component ID
5697F4400
Applicable component levels
R510 PSY UI56696
UP18/06/22 P F806
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSAUUV","label":"IBM Db2 High Performance Unload for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
12 February 2021