REPORT (Generate Reports) › TYPE=U - Debugging Report › How to Use

How to Use

A TYPE=U report function opens a data set, reads the first block, and (if possible) identifies it from the following example list of data sets subject to identification by pointing to a DD statement with a data set name that contains unknown data needing identification. Therefore, to use a TYPE=U report function, the DDNAME must be provided, the data set must be able to be opened, and the first block of the data set must be able to be read.

You must have read access to a data set to execute a TYPE=U report function, because the data set to be identified is opened for read processing in the DBUTLTY address space.

Execute the TYPE=U report function with the following syntax.

►►─ REPORT ─ TYPE=U ─ ,DDNAME=DD-name ────────────────────────────────────────►◄

DD-name

The DD-name specifies the JCL statement needing identification.

The TYPE=U report function does not open any data set not named in the DDNAME= keyword, and no data set opened is fully validated as the data set it appears to be. Identification of a data set does not necessarily make it the specific data set you wanted to identify. CA Datacom does not uniquely own the byte values used for identifying data sets, and misidentification is therefore possible. Also note that CA Datacom does not currently, nor does CA Datacom have any plans to ever provide field layouts of any CA Datacom data set.

A DDNAME is not acceptable for sequential input or output files if it is a name reserved for a CA Datacom area. Names with the following patterns are therefore not acceptable for DDNAME=:

• 3-byte names that end with XX, meaning they are reserved as either current or future CA Datacom control areas.
• 6-byte names that end with what could be a database ID from 001 through 999.
• 7-byte names that end with what could be a database ID from 1000 through 9999.

  The DDNAME= value is verified for acceptability to protect you from unintentionally causing data corruption. The DDNAME check is the default but optional. You can prevent the DDNAME check by using a DBSIDPR parameter (DBUTLTY_EDIT_DATA_SET=) for individual MUF environments. However, we recommend that you allow the DDNAME check.

  The data corruption risk involves not the DDNAME itself but the content of the data set. For example, suppose that you used the CXX DDNAME as the output of a backup. You then copied the CXX DD statement and changed the DDNAME of the copy to be acceptable, avoiding the DDNAME= error. The backup would, however, then overlay the CXX data set, which is not the intent of a backup.

  If you specify an unacceptable name for DDNAME=, message DB10059E is generated. For more information about DB10059, see the CA Datacom/DB Message Reference Guide.

  Note: We recommend that you allow DDNAME= check protection. You can, however, disable DDNAME= protection. To disable protection, assemble the DBSIDPR module used for this CA Datacom environment and specify NONE for the DBUTLTY_EDIT_DATA_SET= parameter. The default is DBUTLTY_EDIT_DATA_SET=FULL_1, which allows DDNAME= protection. For more information about DBSIDPR and DBUTLTY_EDIT_DATA_SET=, see the CA Datacom/DB Database and System Administrator Guide.