Data Manager

General Restrictions

• For DB2 tables with non-direct access, Life Cycle requires SYSPUNCH and DCLGEN to be partitioned data set (PDS) members, even though the cataloging phase supports SYSPUNCH and DCLGEN as sequential files. If you want to use Life Cycle and you have cataloged SYSPUNCH in a sequential file, you will need to delete it from the knowledge base and re-catalog it as a PDS member.
• Currently Data Manager only shows the first 1000 distinct values and ranges, which are sorted either numerically or alphanumerically based on the data element type. When there are more than 1000 distinct data element values, the Data Element Value ends at the 1000^th unique value instead of the greatest data element value.

DB2 for z/OS Environment Restrictions

Lists size restrictions and process identifier limitations for data types.

DB2 Large Object Data Types Restrictions

Data Manager does not support a direct link to all the DB2 Large Object data types for these three operations:

• Masking
• Subsetting
• Sampling

In order to mask or subset or sample your data, you must first use file reference variables method to unload each LOB or XML to a separate file. With this method, the LOB or XML values are unloaded to a different file than the normal unload file. DB2 creates or uses a different output file for each LOB or XML value to be unloaded. The output file should be on the following type:

Member of a partitioned data set (PDS) or partitioned data set extended (PDSE). See the following example JCL:

//LOADLOB JOB KRM,MSGCLASS=A,CLASS=1,NOTIFY=&SYSUID                     
//* *******************************************
//* TABLE &OWNNAME.&TABNAME
//* (PDFBLO BLOB (27994))
//* (TXTCLO CLOB (16094) )
//* (PDFBLO BLOB (16032) )
//* UNIT(SYSDA) SPACE ((20,2) MB)
//* (PDFBLO VARCHAR(54) BLOBF TSYSLOB)
//* ****************************************
//STEP1 EXEC DSNUPROC,UTPROC=,SYSTEM=&SYSTEM,LIB=DSN810.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  TEMPLATE TSYSPUN
     DSN('URADAR.&SS..&DB..PUNCH.&TABNAME')
     DISP(MOD,CATLG,CATLG)
  TEMPLATE TSYSREC
     DSN('URADAR.&SS..&DB..SYSREC.&TABNAME')
     DISP(MOD,CATLG,CATLG)
  TEMPLATE TSYSLOB
     DSN('URADAR.&SS..&DB..PDS.&TABNAME')
     DISP(MOD,CATLG,CATLG)
     DSNTYPE(PDS)
  UNLOAD DATA FROM TABLE &OWNNAME.&TABNAME
   (A, B,C VARCHAR(44) CLOBF TSYSLOB, D)
  UNLDDN(TSYSREC) PUNCHDDN(TSYSPUN)
/*
//

Data Manager supports a direct link to all the Large Object data types for this operation:

• Cataloguing
• Life Cycle
• Reload
• Unload

For the Data Manager skeleton of Unload and/or Reload's Job, there are some modifications to apply:

• Add the "TEMPLATE" condition.
• If needed, add the field list with the specific keyword &FLDLST to be substituted.

The following example shows the Data Manager Unload skeleton with the modifications applied:

//SYSIN     DD *
  TEMPLATE TSYSLOB
     DSN('URADAR.&DBNAME.&TSNAME.PIPPO')
     DISP(MOD,CATLG,CATLG)
     DSNTYPE(PDS)
 UNLOAD FROM TABLE
             &OWNAME.&FILNAME   HEADER NONE    LIMIT 0
&FLDLST
&DBNAME.&TSNAME

Process Identifier Limitations

Data Manager needs a specific Process Identifier in order to works properly with DB2 Large Object data type.

Since Data Manager doesn't have a pre-loaded Process Id for this kind of data, we recommend creating a new Process Identifier following these specific properties:

• Access Type: Unload File Access (UNLOAD)
• I/O Program Name: KURFIO.

For information about the Process Identifier structure, see the section Process identifier and database types relationships.

DB2 VARBINARY Data Types Restrictions

When Data Manager accesses DB2 by direct access, it does not work directly with the execution of sub-extraction query created when applying a method's filter criteria if the filter is applied to a VARBINARY column or to a combined field containing VARBINARY column.

In general, when Data Manager accesses DB2 by direct access, it creates a SELECT * statement with a WHERE clause in order to apply the appropriate filters.

For VARBINARY data type, Data Manager will not generate this WHERE condition, but just the SELECT * statement.

The access to data in this case is done by a sequential access and the application of filter's criteria is done by Data Manager in a transparent way, applying the filter criteria to each record and discarding this record not satisfying the filter.

For information about the Filter properties, see Work with Method - selection class /filter properties.