CA Datacom Datadictionary · CA Product References This document references the following CA products: CA Datacom®/DB (CA Datacom/DB) CA Datacom® CICS Services (CA Datacom CICS

CA Datacom® Datadictionary™

Batch Reference Guide r12

This documentation and any related computer software help programs (hereinafter referred to as the “Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and protected by the copyright laws of the United States and international treaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the documentation for their own internal use, and may make one copy of the related software as reasonably required for back-up and disaster recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the product are permitted to have access to such copies.

The right to print copies of the documentation and to make a copy of the related software is limited to the period during which the applicable license for the Product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.

EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS OR DAMAGE.

The use of any product referenced in the Documentation is governed by the end user’s applicable license agreement.

The manufacturer of this Documentation is CA.

Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Copyright © 2009 CA. All rights reserved.

CA Product ReferencesThis document references the following CA products:

■ CA Datacom®/DB (CA Datacom/DB)■ CA Datacom® CICS Services (CA Datacom CICS Services)■ CA Datacom® Datadictionary™ (Datadictionary)■ CA Datacom® SQL (CA Datacom SQL)■ CA Datacom® STAR (CA Datacom STAR)■ CA Datacom® VSAM Transparency (CA Datacom VSAM Transparency)■ CA Datacom®/AD■ CA Dataquery™ for CA Datacom® (CA Dataquery)■ CA Ideal™ for CA Datacom® for CA Datacom (CA Ideal)■ CA IPC■ CA Common Services for z/OS■ CA Librarian® (CA Librarian)■ CA MetaCOBOL+■ CA Panvalet■ CA Roscoe® Interactive Environment (CA Roscoe IE)

Contact CAContact Technical Support

For your convenience, CA provides one site where you can access theinformation you need for your Home Office, Small Business, and EnterpriseCA products. At http://ca.com/support, you can access the following:

■ Online and telephone contact information for technical assistance andcustomer services

■ Information about user communities and forums

■ Product and documentation downloads

■ CA Support policies and guidelines

■ Other helpful resources appropriate for your product

Provide Feedback

If you have comments or questions about CA product documentation, youcan send a message to [email protected].

If you would like to provide feedback about CA product documentation,please complete our short customer survey, which is also available on theCA Support website, found at http://ca.com/support.

3

4 Datadictionary Batch Reference Guide

Contents

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Batch Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Listing Libraries for CA Datacom Products in JCL . . . . . . . . . . . . . . . 19Using Batch Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Establishing User Identification . . . . . . . . . . . . . . . . . . . . . . . 20Using Predefined Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Transaction 1: -DEF PATH . . . . . . . . . . . . . . . . . . . . . . . . 24Transaction 2: -DEF TRACE . . . . . . . . . . . . . . . . . . . . . . . . 25Transaction 3: -END . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25TRACEF and TRACEB Transactions . . . . . . . . . . . . . . . . . . . 26

Coding Multiple Line Transactions . . . . . . . . . . . . . . . . . . . . . . 27Entering Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Abbreviations Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Maintenance Portion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Specific Information Portion . . . . . . . . . . . . . . . . . . . . . . . . . 30Error Recap Portion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Reading Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Statement Without Parameters . . . . . . . . . . . . . . . . . . . . . . . 33Statement with Required Parameters . . . . . . . . . . . . . . . . . . . . 34Delimiters Around Parameters . . . . . . . . . . . . . . . . . . . . . . . . 34Choice of Required Parameters . . . . . . . . . . . . . . . . . . . . . . . 34Default Value for a Required Parameter . . . . . . . . . . . . . . . . . . 35Optional Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Choice of Optional Parameters . . . . . . . . . . . . . . . . . . . . . . . 35Repeatable Variable Parameter . . . . . . . . . . . . . . . . . . . . . . . 36Separator with Repeatable Variable and Delimiter . . . . . . . . . . . . 36Optional Repeatable Parameters . . . . . . . . . . . . . . . . . . . . . . 37Default Value for a Parameter . . . . . . . . . . . . . . . . . . . . . . . . 37Variables Representing Several Parameters . . . . . . . . . . . . . . . . 38Syntax Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

JCL Example Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 2. DDBTGLM - Generating Batch Transactions . . . . . . . . . 41When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

For Partitioned Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45For SQL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46For Dataviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

-BTG AUXOUT - Specifying Auxiliary Output Device . . . . . . . . . . . . . 47-BTG TABLE - Special Transactions for Partitioned Tables . . . . . . . . . 48

When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Contents 5

-BTG TRACE - Printing Diagnostic Information . . . . . . . . . . . . . . . . 49When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

-BTG USER - Preparing and Invoking a User-Written Exit . . . . . . . . . . 50When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

-BTG VERSION - Specifying a Status/Version . . . . . . . . . . . . . . . . . 52-BTG - Initiating Batch Transaction Generator Transactions . . . . . . . . . 53


-BTG START - Indicating a Starting Point . . . . . . . . . . . . . . . . . . . 56-END - Concluding Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 59


Using DDBTGLM for Partitioned Tables . . . . . . . . . . . . . . . . . . . . . 60PARTITION Predefined Path . . . . . . . . . . . . . . . . . . . . . . . . . 60-BTG TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 60How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Sample Job Streams and Output . . . . . . . . . . . . . . . . . . . . . . . . . 62z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Sample Report - DDBTGLM - for DATABASE Structures . . . . . . . . 63Sample Output - DDBTGLM - for DATABASE Structure . . . . . . . . . 68Sample Report - DDBTGLM - for DATAVIEW Structure . . . . . . . . . 73Sample Output - DDBTGLM - for DATAVIEW Structure . . . . . . . . . 75

Chapter 3. DDCFBLD - Cataloging Datadictionary Definitions . . . . . 77When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79-CXX BUILD - Building the Entity-Occurrence Definitions . . . . . . . . . . . 80Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . . 82

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Sample Report - DDCFBLD (-CXX BUILD) . . . . . . . . . . . . . . . . 84

-CXX CATALOG - Cataloging the Definitions to the Directory . . . . . . . . 87Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . . 89

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Sample Report - DDCFBLD (-CXX CATALOG) . . . . . . . . . . . . . . 91

-HSD RESET - Resetting the HSD Table . . . . . . . . . . . . . . . . . . . . 95Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . . 96

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Sample Report - DDCFBLD (-HSD RESET) . . . . . . . . . . . . . . . . 97

Chapter 4. DDICF - Generating Input Transactions . . . . . . . . . . . 101When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103CA FILE Model Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104


CA Datacom/DB TABLE Substructure . . . . . . . . . . . . . . . . . . . . . 105Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106-UTL LIBRARY - Invoking DDICF . . . . . . . . . . . . . . . . . . . . . . . 107-UTL LANGUAGE - Specifying the Input Language . . . . . . . . . . . . . 108-UTL AREA - Specifying Area and Table Information . . . . . . . . . . . . 109-UTL ICF - Specifying the Copybook Member . . . . . . . . . . . . . . . . 110Sample Job Streams and Output . . . . . . . . . . . . . . . . . . . . . . . . 112

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Sample Report - DDICF - for a Table . . . . . . . . . . . . . . . . . . . 115Sample Output - DDICF - for a Table . . . . . . . . . . . . . . . . . . . 116Sample Report - DDICF - for a File . . . . . . . . . . . . . . . . . . . . 119Sample Output - DDICF - for a File . . . . . . . . . . . . . . . . . . . . 121

Chapter 5. DDRMFLM - Converting Field Definitions . . . . . . . . . . 125When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Valid Field Type Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . 129Inserting Fields and Specifying the VALUE Value . . . . . . . . . . . . . . 130Deleting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Changing Fields with Decimals . . . . . . . . . . . . . . . . . . . . . . . . . 132Handling Filler Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Truncating Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Handling Null-filled Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Report Produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136-RMF INPUT - Specifying the Input . . . . . . . . . . . . . . . . . . . . . . 137-RMF OUTPUT - Specifying the Output . . . . . . . . . . . . . . . . . . . . 139-RMF EXITS - Specifying Exit Programs . . . . . . . . . . . . . . . . . . . 141

Contents of the Exit Program . . . . . . . . . . . . . . . . . . . . . . . 142Sample Job Streams and Reports . . . . . . . . . . . . . . . . . . . . . . . 143

z/OS Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143z/VSE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Sample Report - DDRMFLM . . . . . . . . . . . . . . . . . . . . . . . . 144Sample Report - DDRMFLM Report with Errors . . . . . . . . . . . . . 148

Chapter 6. DDRTVCAT - Using the Runtime and Verify CatalogProgram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151-CXX CATALOG - Cataloging the Definitions to the Directory . . . . . . . 152-RTV BASIS - Modeling a Database . . . . . . . . . . . . . . . . . . . . . . 154Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . 155

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Sample Report - DDRTVCAT . . . . . . . . . . . . . . . . . . . . . . . 157

Chapter 7. DDTRSLM - Transporting Definitions . . . . . . . . . . . . 159When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Contents 7

Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Non-SQL Access Considerations . . . . . . . . . . . . . . . . . . . . . . . . 169How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170EXPORT Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172IMPORT Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Importing a Specific Entity-Occurrence . . . . . . . . . . . . . . . . . . 175Excluding Entity-Types or Entity-Occurrences . . . . . . . . . . . . . . 175Importing Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Importing Only Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Using the ONLY Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Using the REPLACE Option . . . . . . . . . . . . . . . . . . . . . . . . 176Listing Objects Exported . . . . . . . . . . . . . . . . . . . . . . . . . . 176Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Syntax for IMPORT ALL Commands . . . . . . . . . . . . . . . . . . . 177Syntax for IMPORT or TRIAL IMPORT Commands . . . . . . . . . . 177IMPORT DIRECTORY Command . . . . . . . . . . . . . . . . . . . . . 182TRIAL IMPORT Command . . . . . . . . . . . . . . . . . . . . . . . . . 182

Report Produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184SET USER - Establishing User Identification . . . . . . . . . . . . . . . . . 185SET EXPORT FORMAT PREV RELEASE - Convert Format . . . . . . . 186SET IMPORT COLLISION - Handling Duplicates . . . . . . . . . . . . . . 187SET TRACE - Debugging the Utility . . . . . . . . . . . . . . . . . . . . . . 188Sample Job Streams and Input . . . . . . . . . . . . . . . . . . . . . . . . . 189

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Exporting Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Transporting Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Transporting Tables, Views, and Synonyms . . . . . . . . . . . . . . . . . 199Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Example EXPORT Command . . . . . . . . . . . . . . . . . . . . . . 200Example IMPORT Command . . . . . . . . . . . . . . . . . . . . . . . 200Example Transport File for a Table . . . . . . . . . . . . . . . . . . . 201

Chapter 8. DDUPDATE - Updating Datadictionary . . . . . . . . . . . . 205Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211-AUXIN Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

z/OS Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212z/VSE Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Processing -GRP Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 213Updating the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Generating DDUPDATE Transactions Using DDICF . . . . . . . . . . . . 215Processing -BTG Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216


Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Automatically Generated Reports . . . . . . . . . . . . . . . . . . . . . 219Maintenance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Error Recap Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Requested Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Sample Job Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221


Header Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Using the -ADD Header Transaction . . . . . . . . . . . . . . . . . . . 224Using the -CPY Header Transaction . . . . . . . . . . . . . . . . . . . 226Using the -DEL Header Transaction . . . . . . . . . . . . . . . . . . . 228Using the -UPD Header Transaction . . . . . . . . . . . . . . . . . . . 230Using the -UPG Header Transaction . . . . . . . . . . . . . . . . . . . 233

Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 234Using the -GRP Header Transaction . . . . . . . . . . . . . . . . . . . 234-GRP END Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Using the Maintenance Transactions . . . . . . . . . . . . . . . . . . . . . 237Maintaining Support Data . . . . . . . . . . . . . . . . . . . . . . . . . . 237Maintaining the CA Datacom/DB and CA FILE Models . . . . . . . . . 238Maintaining Occurrence Attributes . . . . . . . . . . . . . . . . . . . . . 239Returning Attribute Values to Default . . . . . . . . . . . . . . . . . . . 240

1000 ALTER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Example Transaction Collection . . . . . . . . . . . . . . . . . . . . . . 242Relevant Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

1000 APPLY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2461000 CATALOG Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2481000 CONNECT Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2491000 DISABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2501000 ENABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2511000 MODEL Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2521000 NEWNAME Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 255

Impact of Changing Names . . . . . . . . . . . . . . . . . . . . . . . . 255Changing Names of Tables Created in SQL . . . . . . . . . . . . . . . 256How To Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

1000 NEWPSWD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 258Assigning a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Changing a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Deleting a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

1000 OBSOLETE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 2601000 RESTORE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 261

How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Required Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261From HISTory Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Contents 9

Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

1000 SET Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264TABLE Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265KEY Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267ELEMENT Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . 268FIELD Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

1000 TRANSFER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 2701000 VERIFY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Verifying a DATABASE Structure . . . . . . . . . . . . . . . . . . . . . 272DATABASE Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . 272AREA Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272TABLE Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272KEY Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273ELEMENT Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Verifying a FILE Structure . . . . . . . . . . . . . . . . . . . . . . . . . 274FILE Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274RECORD Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . 274ELEMENT Occurrence (If Any) . . . . . . . . . . . . . . . . . . . . . . 275KEY Occurrence (If Any) . . . . . . . . . . . . . . . . . . . . . . . . . 275

Verifying a TABLE Structure . . . . . . . . . . . . . . . . . . . . . . . . 275TABLE Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275ELEMENT Occurrence (If Any) . . . . . . . . . . . . . . . . . . . . . . 275KEY Occurrence (If Any) . . . . . . . . . . . . . . . . . . . . . . . . . 275

1001 Author Controller Transaction . . . . . . . . . . . . . . . . . . . . . . 2761002 Description Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2771003 Relationship Transactions . . . . . . . . . . . . . . . . . . . . . . . . 278

1003 RELT Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2781003 UNRL Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2801003 DATA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2811003 AFTER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 282

1101 Descriptor Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 2841103 Alias Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2861200 TEXT Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

1200 TEXT ADD Transaction . . . . . . . . . . . . . . . . . . . . . . . 2891200 TEXT CLS Transaction . . . . . . . . . . . . . . . . . . . . . . . . 290

Naming a Text Classification . . . . . . . . . . . . . . . . . . . . . . . 290Renaming a Text Classification . . . . . . . . . . . . . . . . . . . . . 290Copying Text Classifications . . . . . . . . . . . . . . . . . . . . . . . 291Copying Text to a New Text Classification . . . . . . . . . . . . . . . 291Copying Text to the Same Text Classification (Sharing) . . . . . . . 292Copying All Text to the Same Text Classifications . . . . . . . . . . 292Copying All Text to a New Text Classification . . . . . . . . . . . . . 293Excluding a Specific Text Classification from Copy or Share . . . . 293No Text Copied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

1200 TEXT DEL Transaction . . . . . . . . . . . . . . . . . . . . . . . . 2941200 TEXT INS Transaction . . . . . . . . . . . . . . . . . . . . . . . . 2951200 TEXT REP Transaction . . . . . . . . . . . . . . . . . . . . . . . 296


1500 Attribute Value Update Transaction . . . . . . . . . . . . . . . . . . . 3002000 Relationship Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 302

Using the -ADD Relationship Transaction . . . . . . . . . . . . . . . . 3022000 Relationship Transaction . . . . . . . . . . . . . . . . . . . . . . . 303

2900 to 2901 DATABASE Transactions . . . . . . . . . . . . . . . . . . . . 3062900 DATABASE Transaction . . . . . . . . . . . . . . . . . . . . . . . 3072901 DATABASE Transaction . . . . . . . . . . . . . . . . . . . . . . . 309

3001 to 3004 AREA Transactions . . . . . . . . . . . . . . . . . . . . . . . 3103001 AREA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3113002 AREA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3113004 AREA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 313

3120 to 3122 FILE Transactions . . . . . . . . . . . . . . . . . . . . . . . . 3163120 FILE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3173121 FILE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3183122 FILE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

3150 to 3160 TABLE Transactions . . . . . . . . . . . . . . . . . . . . . . . 3213150 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3223151 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3253152 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3263153 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3283160 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 329

3200 RECORD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3314010 to 4020 FIELD Transactions . . . . . . . . . . . . . . . . . . . . . . . 332

4010 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3344011 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3354012 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3354013 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3394014 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3404015 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3414016 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3424017 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3434018 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3444020 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 345

4099 Field Access Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 3485000 to 5100 KEY Transactions . . . . . . . . . . . . . . . . . . . . . . . . 351

5000 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3525010 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3555011 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3565012 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3565100 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

5200 to 5203 PARTITION-COLUMN-VALUE Transactions . . . . . . . . . 3605200 PARTITION-COLUMN-VALUE Transaction . . . . . . . . . . . . 3605203 PARTITION-COLUMN-VALUE Transaction . . . . . . . . . . . . 361

6000 to 6011 ELEMENT Transactions . . . . . . . . . . . . . . . . . . . . 3676000 ELEMENT Transaction . . . . . . . . . . . . . . . . . . . . . . . . 3686010 ELEMENT Transaction . . . . . . . . . . . . . . . . . . . . . . . . 3696011 ELEMENT Transaction . . . . . . . . . . . . . . . . . . . . . . . . 370

6100 LIBRARY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3726200 MEMBER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Contents 11

7011 to 7025 PARTITION-VALUE Transactions . . . . . . . . . . . . . . . 3757011 to 7015 PARTITION-VALUE Transactions . . . . . . . . . . . . . 3757021 to 7025 PARTITION-VALUE Transactions . . . . . . . . . . . . . 376

7100 PANEL Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3777110 SYSTEM Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3797120 PROGRAM Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 3817130 MODULE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3837140 AUTHORIZATION Transaction . . . . . . . . . . . . . . . . . . . . . . 3857150 to 7156 PERSON Transactions . . . . . . . . . . . . . . . . . . . . . 386

7150 PERSON Job Transaction . . . . . . . . . . . . . . . . . . . . . . 3877155 PERSON Language Transaction . . . . . . . . . . . . . . . . . . 3887156 PERSON Name Transaction . . . . . . . . . . . . . . . . . . . . 390

7160 REPORT Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3917170 JOB Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3937180 STEP Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3957190 DATAVIEW Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 397

7210 NODE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3987211 NODE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 398

7999 Application Attribute Transaction . . . . . . . . . . . . . . . . . . . . 4009000 User-Defined Transactions . . . . . . . . . . . . . . . . . . . . . . . . 401

Chapter 9. DDUTILTY - Producing Reports and Source LanguageStatements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Obtaining a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Requesting the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Report Heading Content . . . . . . . . . . . . . . . . . . . . . . . . . . 409Maintenance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Error Recap Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Using the Authorization Transaction . . . . . . . . . . . . . . . . . . . 410Coding Multiple Line Transactions . . . . . . . . . . . . . . . . . . . . . 411Pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Coding the Basic Report Request . . . . . . . . . . . . . . . . . . . . . . . 412Specifying the Report Type . . . . . . . . . . . . . . . . . . . . . . . . 413Restricting Entity-Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Restricting Entity-Occurrences . . . . . . . . . . . . . . . . . . . . . . . 413Requesting Generic Selection . . . . . . . . . . . . . . . . . . . . . . . 414Restricting Version or Status . . . . . . . . . . . . . . . . . . . . . . . . 414Using the Override Code . . . . . . . . . . . . . . . . . . . . . . . . . . 416Using Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416Ending the Report Request . . . . . . . . . . . . . . . . . . . . . . . . 416Example Requests for Basic Reports . . . . . . . . . . . . . . . . . . . 416

Using Pathing in Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Coding the Path Request . . . . . . . . . . . . . . . . . . . . . . . . . . 418Defining the Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419Defining Trace Statements . . . . . . . . . . . . . . . . . . . . . . . . . 419TRACEF Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421TRACEB Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Returning Multiple Levels of a Relationship . . . . . . . . . . . . . . . 422


Coding the -END Transaction . . . . . . . . . . . . . . . . . . . . . . . 422Using the STANDARD Path . . . . . . . . . . . . . . . . . . . . . . . . 422DATABASE Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422FILE Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423Using Nested Pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423-RPT NEST Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 423-RPT NESTEND Transaction . . . . . . . . . . . . . . . . . . . . . . . 425Processing Nested Report Requests . . . . . . . . . . . . . . . . . . . 425Designating the Report Start . . . . . . . . . . . . . . . . . . . . . . . . 425Coding Modifiers When Using Pathing . . . . . . . . . . . . . . . . . . 428

Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429Ending the Report Request . . . . . . . . . . . . . . . . . . . . . . . . 429Example Modified Report Requests . . . . . . . . . . . . . . . . . . . 429Reporting Valid Entity-Types . . . . . . . . . . . . . . . . . . . . . . . 430

Sample Job Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Example Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433Single Report Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 433Grouping Reports in a Request . . . . . . . . . . . . . . . . . . . . . . 435Using a Nested Path in a Request . . . . . . . . . . . . . . . . . . . . 438

Alias Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

ALIAS Report - By Entity-Type . . . . . . . . . . . . . . . . . . . . . . 442ALIAS Report - By Alias Name . . . . . . . . . . . . . . . . . . . . . . 444

Definitions Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

DEFINITIONS Report - By Entity-Type . . . . . . . . . . . . . . . . . 447DEFINITIONS Report - For All Entity-Types . . . . . . . . . . . . . . 448

Descriptors Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

DESCRIPTORS Report - By Entity-Type . . . . . . . . . . . . . . . . 453Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457Report Heading Content . . . . . . . . . . . . . . . . . . . . . . . . . . 458Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459AREA Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459AUTHORIZATION Detail Report . . . . . . . . . . . . . . . . . . . . . . 460CONSTRAINT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . 461DATABASE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . 461DATAVIEW Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 462ELEMENT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 464FIELD Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Contents 13

FILE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469JOB Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471KEY Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471LIBRARY Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 473MEMBER Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 474MODULE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 475NODE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476PANEL Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476PARAMETER-LIST Detail Report . . . . . . . . . . . . . . . . . . . . . 477PARTITION-COLUMN-VALUE Detail Report . . . . . . . . . . . . . . 478PARTITION-VALUE Detail Report . . . . . . . . . . . . . . . . . . . . . 478PERSON Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 479PLAN Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481PROCEDURE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . 483PROGRAM Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 484RECORD Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 486REPORT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 487STATEMENT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . 488STEP Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489SYNONYM Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 489SYSTEM Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 490TABLE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490TRIGGER Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 495VIEW Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497DETAIL Report - No Modifiers . . . . . . . . . . . . . . . . . . . . . . . 498

Field Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501KEY and ELEMENT Field Reports . . . . . . . . . . . . . . . . . . . . 504Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504FIELD Report - STANDARD Path . . . . . . . . . . . . . . . . . . . . . 505

Indented Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510INDENTED Report - No Path . . . . . . . . . . . . . . . . . . . . . . . 511INDENTED Report - STANDARD Path . . . . . . . . . . . . . . . . . . 514Impact Analysis Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

For CA Ideal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518For CA MetaCOBOL+ . . . . . . . . . . . . . . . . . . . . . . . . . . . 519For CA Datacom STAR . . . . . . . . . . . . . . . . . . . . . . . . . . 519For SQL Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

INDENTED Report - Impact Analysis - For CA Ideal . . . . . . . . . . 520INDENTED Report - Impact Analysis - For a Dataview . . . . . . . . 521

Index Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525INDEX REPORT - No Path . . . . . . . . . . . . . . . . . . . . . . . . 526INDEX Report - STANDARD Path . . . . . . . . . . . . . . . . . . . . 528

Relationship Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530


Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531RELATIONSHIP Report - No Path . . . . . . . . . . . . . . . . . . . . 532

RELATIONSHIP Report - STANDARD Path . . . . . . . . . . . . . . 534RELATIONSHIP Report - With Modifiers . . . . . . . . . . . . . . . . . 537RELATIONSHIP Report - Ordered Relationships . . . . . . . . . . . . 538

Schema Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541SCHEMA Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

SQL Column Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544Report Request Transactions . . . . . . . . . . . . . . . . . . . . . . . 544Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554TEXT Report - Without ALIGN Option . . . . . . . . . . . . . . . . . . 556TEXT Report - With ALIGN Option . . . . . . . . . . . . . . . . . . . . 559TEXT Report - STANDARD Path with ALIGN Option . . . . . . . . . . 560

Generating Source Language Statements . . . . . . . . . . . . . . . . . . 562Datacom View Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Using the Source Language Generation . . . . . . . . . . . . . . . . . . . 563-UTL LIBRARY - Specifying the Library Type . . . . . . . . . . . . . . 563-UTL MODE - Specifying SQL-Compatible Copybooks . . . . . . . . . 564-UTL LANGUAGE - Specifying the Language . . . . . . . . . . . . . . 565-RPT START - Specifying the Starting Point in the Path . . . . . . . . 568-UTL COPY - Specifying the Entity-Occurrence . . . . . . . . . . . . . 569Defining a Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572Source Language Generation Facility Output . . . . . . . . . . . . . . 574

Printed Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574Punched Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574CATALOG Statement for z/VSE . . . . . . . . . . . . . . . . . . . . . 575CA Datacom/DB Reporting Facility Considerations . . . . . . . . . . 576Report Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576Controlling Beginning Displacement . . . . . . . . . . . . . . . . . . . 576

Sample Job Streams and Output . . . . . . . . . . . . . . . . . . . . . . . . 577Output from the Datacom View Generator . . . . . . . . . . . . . . . . 587Additional Comment Lines . . . . . . . . . . . . . . . . . . . . . . . . . 591

Appendix A. Sample User-Written Exit for DDBTGLM (COBOL) . . . 595

Appendix B. Sample User-Written Exits for DDRMFLM (Assembler) 599Input User-Written Exit for DDRMFLM . . . . . . . . . . . . . . . . . . . . . 600Output User-Written Exit for DDRMFLM . . . . . . . . . . . . . . . . . . . . 602

Appendix C. Maintaining Tables with Related Constraints . . . . . . 605Impact of ALTER TABLE on TEST and HISTory Status Versions . . . . . 606Preventing ALTER TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 607Impact of Changing Structure Definitions on Constraints . . . . . . . . . . 608

Contents 15

Adding a Column to a Table . . . . . . . . . . . . . . . . . . . . . . . . 608Deleting a Column from a Table . . . . . . . . . . . . . . . . . . . . . . 608Adding a Column to a Key . . . . . . . . . . . . . . . . . . . . . . . . . 609Deleting a Column from a Key . . . . . . . . . . . . . . . . . . . . . . . 609Deleting Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610Updating Table Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 610Updating Key Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 611Updating Field Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619


Chapter 1. Introduction

This chapter contains the following topics:

Batch Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Listing Libraries for CA Datacom Products in JCL . . . . . . . . . . . . . . . 19Using Batch Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Establishing User Identification . . . . . . . . . . . . . . . . . . . . . . . 20Using Predefined Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Coding Multiple Line Transactions . . . . . . . . . . . . . . . . . . . . . . 27Entering Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Abbreviations Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Maintenance Portion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Specific Information Portion . . . . . . . . . . . . . . . . . . . . . . . . . 30Error Recap Portion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Reading Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Statement Without Parameters . . . . . . . . . . . . . . . . . . . . . . . 33Statement with Required Parameters . . . . . . . . . . . . . . . . . . . . 34Delimiters Around Parameters . . . . . . . . . . . . . . . . . . . . . . . . 34Choice of Required Parameters . . . . . . . . . . . . . . . . . . . . . . . 34Default Value for a Required Parameter . . . . . . . . . . . . . . . . . . 35Optional Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Choice of Optional Parameters . . . . . . . . . . . . . . . . . . . . . . . 35Repeatable Variable Parameter . . . . . . . . . . . . . . . . . . . . . . . 36Separator with Repeatable Variable and Delimiter . . . . . . . . . . . . 36Optional Repeatable Parameters . . . . . . . . . . . . . . . . . . . . . . 37Default Value for a Parameter . . . . . . . . . . . . . . . . . . . . . . . . 37Variables Representing Several Parameters . . . . . . . . . . . . . . . . 38Syntax Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

JCL Example Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

This guide explains how to use the transactions you can use with the utilitiesprovided by CA Datacom/DB Datadictionary.

You can code batch transactions to perform the general maintenanceprocessing of occurrences with the Datadictionary utilities. Before you begin,you must understand the basics of Datadictionary. For the detailed rules andguidelines on how to use Datadictionary, see the CA Datacom DatadictionaryUser Guide.

Chapter 1. Introduction 17

Batch Facilities

Batch Facilities

You can complete Datadictionary tasks with batch transactions using thefollowing utilities. You must use batch to create your own relationshipdefinitions.

Utility Description

DDBTGLMThe Batch Transaction Generator (DDBTGLM) creates DDUPDATE batchtransactions from selected occurrences. You can use these transactionsto add or update occurrences in another Datadictionary system. You canalso use the Batch Transaction Generator to create an archive copy ofoccurrence information in batch transaction format.

DDCFBLDThis utility reads Datadictionary definitions and formats them forsubmission to DBUTLTY or catalogs them directly to CA Datacom/DB.You can also use it to update Datadictionary's High-Speed Directory.

DDICFThe Input Creation Facility analyzes COBOL record description copybooksand creates transactions necessary for entering the appropriate TABLE,FILE, RECORD, FIELD and ELEMENT occurrence information.

DDRMFLMThe Datadictionary Record Migration Facility (DDRMFLM) converts thefields of data records in an extracted (unloaded) file to a format thatconforms to a different Datadictionary TABLE or RECORDentity-occurrence definition. The converted file can then serve as input toload a CA Datacom/DB table.

DDTRSLMThe Transport Utility transports or backs up selected Datadictionarydefinitions from a CA Datacom site for loading into another. The CADatacom site can have CA Datacom/DB running on the mainframe or onother platforms.

DDUPDATEThis update utility performs the general maintenance processing ofoccurrences. Additionally, you can use it to perform the reporting functionsof DDUTILTY.

DDUTILTYThis utility processes report definition and utility transactions withinDatadictionary. The Source Language Generation (SLG) facility, which ispart of DDUTILTY, allows you to reproduce the field definitions ofELEMENT, KEY, RECORD and TABLE occurrences as high-levellanguage statements.


Listing Libraries for CA Datacom Products in JCL

Listing Libraries for CA Datacom Products in JCL

Guidelines to assist you in preparing your JCL are provided in this manual.The sample code provided in this document is intended for use as a referenceaid only and no warranty of any kind is made as to completeness orcorrectness for your specific installation.

Samples for JCL and programs are provided in the install library (in z/OS, thedefault name for this library is CAIMAC). In z/VSE, sample PROCs areprovided that allow you to make use of parameter substitution. You can copyand modify these samples for your specific requirements.

Any JOB statements should be coded to your site standards and specifications.All data set names and library names should be specified with the correctnames for the installation at your site. In many examples, a REGION= orSIZE= parameter is displayed in an EXEC statement. The value displayedshould be adequate in most instances, but you can adjust the value to yourspecific needs.

The libraries listed for searching must include the following in the order shown:

1. User libraries you may have defined for specially assembled and linkedtables, such as DBMSTLST, DBSIDPR, DDSRTLM, DQSYSTBL, or UserRequirements Tables

2. CA Datacom base libraries (CAILIB): CA Datacom/DB, Datadictionary, CADataquery, SQL

3. CA Common Services for z/OS or CA CIS (Common InfrastructureServices) for z/VSE base libraries

4. CA IPC libraries

5. Libraries for additional products, such as CA Datacom CICS Services, CADatacom VSAM Transparency, CA Ideal, and so on

CA Dataquery users also need the following libraries and data sets for thefollowing specific functions:

■ The z/OS data set DQOUT or the z/VSE data set DQOUTD is used only ifthe DQBATCH execution uses the EXPORT function.

■ In z/OS, running deferred queries with separate JCL members in batchrequires, in addition to the SYSIN statement DEFER, the inclusion of a DDstatement for the internal reader used by VPE. This DD statement shouldbe:

//IRDR DD SYSOUT=(A,INTRDR)


Using Batch Transactions


This section describes general procedures you must follow to execute the batchutilities. The utilities execute Datadictionary transactions to accomplish eachfunction. These transactions include:

-USR The batch input streams, except DDTRSLM, begin with a -USRtransaction to establish the appropriate Authorization Profile.

-DEF PATH For DDBTGLM, DDUPDATE and DDUTILTY, you can includepath definition transactions to establish the desired connectionsbetween occurrences for reporting and data extraction purposes.

Specific transactionsEach utility requires that you include transactions specific to thefunction you are performing. These specific transactions aredescribed in the individual chapters in this book.

-END Datadictionary automatically generates an -END transactioninternally as it encounters the next header transaction or when itencounters an end-of-file. This -END transaction marks theconclusion of each header transaction. The only exception to theDatadictionary provided -END transaction is the one you mustenter at the conclusion of a series of transactions when defining apath. For more information, see “Using Predefined Paths” onpage 22.

Establishing User Identification

The -USR transaction identifies the user to Datadictionary if your site does notuse the user ID from a security product such as CA Top Secret®, CA ACF2 orRACF.

■ When Datadictionary encounters a -USR transaction, it checks the user'sAuthorization Profile and enforces those authorizations on each transactiongroup that follows.

■ The authorizations remain in effect until the run concludes or untilDatadictionary encounters the next -USR transaction.

When to Use: If your site does not use the user ID from a security product,you must place a -USR transaction as the first transaction in the input streamfor utilities that call the Datadictionary Service Facility (DSF). If it is not the firsttransaction, Datadictionary issues an error message and reads to the next valid-USR transaction or end-of-file. The following are the utilities that require thetransaction:

DDBTGLMDDCFBLDDDRMFLM

DDUPDATEDDUTILTYDDICF



Exceptions: The Transport Utility (DDTRSLM) requires a SET USERcommand instead of the -USR transaction.

How to Use: Use the following transaction to establish your authorization.

Establish your Authorization

��──-USR─ ──name,password ──┬ ┬───────────── ─────────────────────────────�� └ ┘ ─,datacom-id─

name(Required) Individual's name as specified in the PERSON entity-type.

Valid Entries: Any valid user identification

Default Value: (No default)

,password(Required) Specify the individual's user password. This is the value forthe PASS-WORD attribute for the PERSON occurrence.

Valid Entries: User password as it appears in the PERSONoccurrence


,datacom-id(Optional) The identifier for the Datadictionary (DATA-DICT) databasewhich contains the definitions you wish to access.

Valid Entries: 1 to 5000

Default Value: The default established with BASEID= in the SystemResource Table



Using Predefined Paths

Datadictionary uses named relationships, both supplied and user-defined, toshow the connection between entity-types. You use a path to trace theconnection between occurrences of the entity-types named in the relationshipdefinition.

More Information

■ For more information and a chart of the supplied relathionships, see thesection about defining and maintaining relationship definitions in the CADatacom Datadictionary User Guide.

■ For more information and instructions about obtaining a complete list of boththe supplied relationships and all relationships defined for use at your site,see “Definitions Report” on page 446.

Datadictionary supplies predefined paths that you can use for eitherDATABASE or FILE structures. Use of these predefined paths are availableusing the DDBTGLM utility or the Reporting Facility depending on the type ofstructure on which you are reporting. Refer to the following chart for detailsand to the illustrations which follow for examples of each type of predefinedpath. Do not attempt to define these paths yourself.

DATABASE Structure Path Using the DDBTGLM Utility: -DEF TRACE,DATABASE.AREA,$INTERNAL -DEF TRACE,AREA.TABLE,$INTERNAL -DEF TRACE,TABLE.FIELD,$INTERNAL -DEF TRACE,TABLE.KEY,$INTERNAL -DEF TRACE,KEY.FIELD,$INTERNAL -DEF TRACE,TABLE.ELEMENT,$INTERNAL -DEF TRACE,ELEMENT.FIELD,$INTERNAL

Specify: For structure: Using:

-DEF PATH,STANDARD DATABASE DDBTGLM utilityorReporting Facility

-DEF PATH,STANDARD FILE Reporting Facility

-DEF PATH,DBMODEL DATABASE towhich dataviews aredefined

DDBTGLM utility

-DEF PATH,PARTITION DATABASE towhich at least onepartitioned table isdefined

DDBTGLM utility



DATABASE Structure Path Using the Reporting Facility (DDUTILTY orDDUPDATE): -DEF TRACE,DATABASE.AREA,$INTERNAL -DEF TRACE,AREA.TABLE,$INTERNAL -DEF TRACE,TABLE.KEY,$INTERNAL -DEF TRACE,TABLE.ELEMENT,$INTERNAL -DEF TRACE,TABLE.FIELD,$INTERNAL

FILE Structure Path ONLY Using the Reporting Facility (DDUPDATE orDDUTILTY): -DEF TRACE,FILE.RECORD,$INTERNAL -DEF TRACE,RECORD.FIELD,$INTERNAL -DEF TRACE,RECORD.KEY,$INTERNAL -DEF TRACE,RECORD.ELEMENT,$INTERNAL

Note: There is no STANDARD path for FILE structures using the DDBTGLMutility.

DATABASE Structure Path (DATAVIEW to ELEMENT) ONLY Using theDDBTGLM Utility: -DEF TRACE,DATABASE.AREA,$INTERNAL -DEF TRACE,AREA.TABLE,$INTERNAL -DEF TRACE,TABLE.FIELD,$INTERNAL -DEF TRACE,TABLE.KEY,$INTERNAL -DEF TRACE,KEY.FIELD,$INTERNAL -DEF TRACE,TABLE.ELEMENT,$INTERNAL -DEF TRACE,ELEMENT.FIELD,$INTERNAL -DEF TRACE,TABLE.ELEMENT,$INTERNAL,SKIP -DEF TRACE,ELEMENT.DATAVIEW,$INTERNAL -DEF TRACE,DATAVIEW.ELEMENT,$INTERNAL -DEF TRACE,TABLE.KEY,$INTERNAL,SKIP -DEF TRACE,KEY.DATAVIEW,$INTERNAL -DEF TRACE,DATAVIEW.KEY,$INTERNAL

DATABASE Structure Path for Partitioned Tables Only Using DDBTGLM-DEF TRACE,DATABASE.AREA,$INTERNAL,SKIP-DEF TRACE,AREA.TABLE,$INTERNAL,SKIP-DEF TRACEF,TABLE.TABLE,TBL-TBL-PARTITION-DEF TRACE,TABLE.PARTITION-COLUMN-VALUE,TBL-PCV-PARTITION-DEF TRACE,PARTITION-COLUMN-VALUE.FIELD,PCV-FLD-PARTITION-DEF TRACE,TABLE.KEY,TBL-KEY-PARTITION

When to Use: Use path definition to locate occurrences by identifying theconnections between them for reporting and data extraction purposes.



How to Use: The path definition transactions are listed following:

■ A -DEF PATH transaction

■ -DEF TRACE transactions (These transactions are unnecessary if the pathname is DBMODEL, PARTITION, or STANDARD.)

■ An -END transaction

-DEF PATH Transaction

��──-DEF─ ──PATH,path-name ─────────────────────────────────────────────��

-DEF TRACE Transaction

��─ ──┬ ┬──────────────────────────────────────────────── ───────────────��└ ┘──-DEFTRACE,from.to,relationship-name ──┬ ┬───────

└ ┘ ─,SKIP─

-END Transaction

��──-END──────────────────────────────────────────────────────────────��

Transaction 1: -DEF PATH

Identifies the path name for the path you are defining.

,path-name(Required) Specifies a valid path name. STANDARD is a special,Datadictionary supplied path for CA Datacom/DB and CA FILE Modelstructure processing. DBMODEL includes the Datadictionary suppliedSTANDARD path, plus the dataviews. PARTITION is a special path foruse with partitioned tables.

Valid Entries: STANDARDDBMODELPARTITIONAny valid name up to 32 characters




Transaction 2: -DEF TRACE

Specifies that Datadictionary return the occurrences associated by the namedrelationship. If the path name specified is STANDARD, DBMODEL, orPARTITION, you do not need to include TRACE transactions.

Note: The number of -DEF TRACE transactions that you can include isdefined in MAXLVLS= parameter of the System Resource Table (SRT). Thedefault value for this parameter is 20.

,from.(Required) For the first TRACE in a path definition, the name of theentity-type with which the structure starts.

If multiple -DEF TRACE transactions occur, the “from” entity-type mustrepeat the name of the “to” entity-type in a previous -DEF TRACEtransaction.

Valid Entries: Name of the desired entity-type


to, (Required) The name of the entity-type to which the “from” entity-type isrelated.

Valid Entries: Name of the desired entity-type


,relationship-name(Required) The name of the relationship Datadictionary is to followbetween the two entity-types when processing the path.

Valid Entries: Name of the desired relationship


,SKIP(Optional) Forces Datadictionary not to process any occurrences of the“to” entity-type. The “to” entity-type is simply used as a bridge to anotherentity-type.

Transaction 3: -END

Concludes the structure definition.



TRACEF and TRACEB Transactions

Two additional trace transactions exist. They are only necessary whenprocessing relationships where the subject and the object entity-types are thesame.

The TRACEF transaction limits the occurrences returned to those found on thepath from the subject to the object. The TRACEB transaction limits thetransactions returned to those found on the path from the object back to thesubject.

The formats for the two transactions are:

TRACEF Transaction

��──-DEF─ ──TRACEF,from.to,relationship-name ──┬ ┬─────── ────────────────�� └ ┘ ─,SKIP─

TRACEB Transaction

��──-DEF─ ──TRACEB,from.to,relationship-name ──┬ ┬─────── ────────────────�� └ ┘ ─,SKIP─

The keywords and values are the same as those for the TRACE as detailedpreviously.



Coding Multiple Line Transactions

All transactions, with the exception of the 1200 TEXT transaction, must conformto the following format:

Bytes 1 through 71 Transaction data

Byte 72 Must be blank

Bytes 73 - 80 Not processed by Datadictionary

The text within a 1200 TEXT transaction can be coded inbytes 73 through 80. However, if you intend to use bothbatch and online facilities to maintain text created inbatch, we recommend you use a maximum line length of72. For more information about updating text, see the CADatacom Datadictionary Online Reference Guide.

The following rules apply to continued transactions:

■ You can divide a transaction only after a comma, period or rightparenthesis.

■ A comma, parenthesis, or period cannot be the first character following thehyphen.

■ Use the continuation capability only with header and 1000 transactions.

To continue a transaction to the next line, insert a hyphen (-) in the firstcolumn of the continued transaction. Follow the hyphen with a space andcontinue coding the transaction.

For example, for a FIELD occurrence with a 32-character table name and a32-character occurrence name, you could continue the transaction after theperiod following the table name. That way there will be sufficient room foroccurrence name, version, password, override code or lock code.

An example transaction collection which uses the continuation characterfollows:

-ADD FIELD, - PERSONNEL-DEPARTMENT-NEWHIRE-REC. - EMPLOYEE-PREVIOUS-POSITION-HELD(T1) -END



Entering Comments

Optional comment lines can be included in a DDCFBLD, DDUPDATE orDDUTILTY job stream. A comment line must begin with the word -COM incolumns 1-4. The utilities do not process these comment lines nor do theyappear on the maintenance report.

You can also enter comments in a DDTRSLM utility job stream by using thedelimeters /* and */ around the text of the comment. If you have comments inz/OS JCL, be sure to indent the /* past the first column or the SYSIN will stopat the previous line and possibly cause a syntax error.

Abbreviations Used

The following abbreviations are used in the transaction formats of this manual:

Abbreviation Description

entity Entity-type

lock Lock level setting

occ-name Occurrence name

ovrd Override code

parent-name RECORD, TABLE or VIEW occurrence name

pswd Password

rec-name RECORD occurrence name

stat Status

tbl-name TABLE occurrence name

vrs Version number


Reports

Reports

Datadictionary automatically generates a report when you execute one of thebatch utilities. The contents of the report varies based on the utility youexecute. The following describes three possible contents you may receive:

■ The maintenance or process portion of the report is produced automaticallyfor DDCFBLD, DDUPDATE and DDUTILTY. It provides information aboutthe transactions submitted and returns a brief message about the results ofprocessing. This portion of the report is titled Maintenance Report.

■ The next portion of the report provides information specific to the functionyou are performing with the utility. The title of this portion of the reportvaries with the utility you are running. For example, for the DDCFBLDUtility, the title is Indented Report; for the DDBTGLM Utility, the title is BatchTransaction Generator.

■ The last portion of the report is only produced for DDBTGLM, DDICF,DDUPDATE, and DDUTILTY. It is produced automatically if any errors aredetected during processing of the batch transactions.

The following sections describe each portion of the report in detail.

Maintenance Portion

This portion of the report lists the Datadictionary maintenance transactioncollection submitted and the outcome of Datadictionary processing only forDDCFBLD, DDUPDATE and DDUTILTY. For DDUTILTY, this portion of thereport only lists the -USR transaction. For DDCFBLD and DDUPDATE themaintenance transactions listed include:

For each transaction collection being reported on, this portion of the reportprints the following information:

■ The expected transaction format■ The transaction as entered■ A code indicating whether the transaction was successfully processed:

PROC Transaction is syntactically correct

MSGN Error encountered - message is displayed on the next line

FLSH Flushed - transaction is not processed

■ A summary of the transaction keywords entered and expected.

-ADD-BTG-CPY-CXX

-DEL-GRP-UPD-UPG

-USRnumbered transactions


Reports

The following is an example of the Maintenance portion of the DDCFBLD utility:

Date: mm/dd/ccyy Time: hh.mm.ss Page: 1 CA Datacom Datadictionary

Security Level: 1 Maintenance Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2

----------------------------------------------------------------------------------- CODE USER-NAME,PSWD,DATABASE-ID

-USR SAMPLE-USER, ; PROC -----------------------------------------------------------------------------------



User: SAMPLE-USER DD Base: 2 ----------------------------------------------------------------------------------- CODE FUNCTION,ENTITY-TYPE,OCCURRENCE(VERS,PSWD,OVRD) -CXX CATALOG,DATABASE,ORDER-ENTRY(PROD) ; -----------------------------------------------------------------------------------

FUNCTION = CATALOG-STRUCTURE ENTITY-TYPE = DATABASE OCCURRENCE = ORDER-ENTRY VERSION = PROD

Specific Information Portion

The following briefly describes the batch utility and the correspondinginformation produced. Sample reports are documented in the individualchapters which follow.

Executing Produces

DDBTGLM The DDUPDATE transactions created by executing the utility.

DDCFBLD Specific results for each type of transaction entered:

■ For -CXX BUILD, a listing of the database occurrencedefinition built.

■ For -CXX CATALOG, a listing of the database structurecataloged.

■ For -HSD RESET, a listing of the Data Group Tables(DGT) defined in the High-Speed Directory (HSD).

DDICF The DDUPDATE transactions generated from the COBOLsource language transactions.

DDRMFLM The results of the conversion and certain diagnosticinformation. The report lists the action performed by theRecord Migration Facility to convert each field, information onthe input and output FIELD occurrences, and any conversionerrors and conflicts.


Reports

DDTRSLM The results of the TRIAL IMPORT or IMPORT commandswhich includes a listing of errors, warnings, andentity-occurrences that are being imported.

DDUPDATE Detailed information about the occurrences being updated orcreated with this utility. The Detail Report is documented in“Detail Report” on page 457. Generation of this report can bestarted and stopped by using the -SET RPOFF and -SETRPON transactions as documented in the "DatadictionaryDiagnostics" chapter of the CA Datacom/DB Database andSystem Administration Guide. If you are using a -UPGtransaction, no Detail Report is generated unless there is anerror in thich case, the occurrence in error is reported.

DDUTILTY The results of reproducing field definitions of ELEMENT, KEY,RECORD and TABLE occurrences as high-level languagestatements for the Source Language Generation (SLG) Facility.

Error Recap Portion

If any errors are detected during processing, Datadictionary prints an ErrorRecap as the last page of the report for DDBTGLM, DDICF, DDUPDATE andDDUTILTY.

Some examples of potential errors are:

■ Datadictionary does not find a required transaction in the transactioncollection

■ Dependent information cannot be found in the system

This portion of the report prints the page number of the report on which theerror occurred, the error message number, and a brief description of each error.See the following example illustrating this portion of a utility report. For moreinformation about the error messages, see the CA Datacom/DB MessageReference Guide.


Security Level: 1 Error Recap Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2PAGE.. ERROR.......... MESSAGE..............................................................

12 DDPFLDA NAMED AFTER DOES NOT EXIST13 DDFHDR77 PREVIOUS GROUP START FLUSH14 DDFHDR77 PREVIOUS GROUP START FLUSH15 DDPKEY3 FIELD NOT IN RECORD17 DDPELM3 FIELD NOT IN RECORD17 DDPELM3 FIELD NOT IN RECORD

END OF RECAP REPORT-------- E N D O F J O B -----------


Disclaimer

Disclaimer

The sample code, JCL, and reports provided in this guide are intended for useas reference aids only. No warranty of any kind is made as to thecompleteness or correctness of the exact samples in your specific installationenvironment. If you are planning to use any of the samples provided in thisguide, be sure to adjust them for your site standards and use.


Reading Syntax Diagrams


Syntax diagrams are used to illustrate the format of statements and some basiclanguage elements. Read syntax diagrams from left to right and top to bottom.

The following terminology, symbols, and concepts are used in syntax diagrams:

■ Keywords appear in uppercase letters, for example, COMMAND or PARM.These words must be entered exactly as shown.

■ Variables appear in italicized lowercase letters, for example, variable.

■ Required keywords and variables appear on a main line.

■ Optional keywords and variables appear below a main line.

■ Default keywords and variables appear above a main line.

■ Double arrowheads pointing to the right indicate the beginning of astatement.

■ Double arrowheads pointing to each other indicate the end of a statement.

■ Single arrowheads pointing to the right indicate a portion of a statement, orthat the statement continues in another diagram.

■ Punctuation marks or arithmetic symbols that are shown with a keyword orvariable must be entered as part of the statement or command.Punctuation marks and arithmetic symbols can include the following:

, comma > greater than symbol

. period < less than symbol

( open parenthesis = equal sign

) close parenthesis ¬ not sign

+ addition − subtraction

* multiplication / division

Statement Without Parameters

The following is a diagram of a statement without parameters:

��──COMMAND───────────────────────────────────────────────────────────��

For this statement, you must write the following:

COMMAND



Statement with Required Parameters

Required parameters appear on the same horizontal line, the main path of thediagram, as the command or statement. The parameters must be separated byone or more blanks.

The following is a diagram of a statement with required parameters:

��──COMMAND──PARM1──PARM2─────────────────────────────────────────────��

You must write the following:

COMMAND PARM1 PARM2

Delimiters Around Parameters

Delimiters, such as parentheses, around parameters or clauses must beincluded.

The following is a diagram of a statement with delimiters around parameters:

��──COMMAND─ ──(PARM1) ──PARM2='variable' ───────────────────────────────��

If the word variable is a valid entry, you must write the following:

COMMAND (PARM1) PARM2='variable'

Choice of Required Parameters

When you see a vertical list of parameters as shown in the following example,you must choose one of the parameters. This indicates that one entry isrequired, and only one of the displayed parameters is allowed in the statement.

The following is a diagram of a statement with a choice of required parameters:

��──COMMAND─ ──┬ ┬─PARM1─ ───────────────────────────────────────────────�� ├ ┤─PARM2─ └ ┘─PARM3─

You can choose one of the parameters from the vertical list, such as in thefollowing examples:

COMMAND PARM1 COMMAND PARM2 COMMAND PARM3



Default Value for a Required Parameter

When a required parameter in a syntax diagram has a default value, the defaultvalue appears above the main line, and it indicates the value for the parameterif the command is not specified. If you specify the command, you must codethe parameter and specify one of the displayed values.

The following is a diagram of a statement with a default value for a requiredparameter:

┌ ┐─YES─��──COMMAND─ ──PARM1= ──┴ ┴─NO── ─PARM2───────────────────────────────────��

If you specify the command, you must write one of the following:

COMMAND PARM1=NO PARM2COMMAND PARM1=YES PARM2

Optional Parameter

A single optional parameter appears below the horizontal line that marks themain path.

The following is a diagram of a statement with an optional parameter:

��──COMMAND─ ──┬ ┬─────────── ───────────────────────────────────────────�� └ ┘─PARAMETER─

You can choose (or not) to use the optional parameter, as shown in thefollowing examples:

COMMAND COMMAND PARAMETER

Choice of Optional Parameters

If you have a choice of more than one optional parameter, the parametersappear in a vertical list below the main path.

The following is a diagram of a statement with a choice of optional parameters:

��──COMMAND─ ──┬ ┬─────── ───────────────────────────────────────────────�� ├ ┤─PARM1─ └ ┘─PARM2─



You can choose any of the parameters from the vertical list, or you can writethe statement without an optional parameter, such as in the following examples:

COMMAND COMMAND PARM1 COMMAND PARM2

Repeatable Variable Parameter

In some statements, you can specify a single parameter more than once. Arepeat symbol indicates that you can specify multiple parameters.

The following is a diagram of a statement with a repeatable variable parameter:

┌ ┐────────────��──COMMAND─ ───� ┴─variable─ ────────────────────────────────────────────��

In the preceding diagram, the word variable is in lowercase italics, indicatingthat it is a value you supply, but it is also on the main path, which means thatyou are required to specify at least one entry. The repeat symbol indicates thatyou can specify a parameter more than once. Assume that you have threevalues named VALUEX, VALUEY, and VALUEZ for the variable. The followingare some of the statements you might write:

COMMAND VALUEXCOMMAND VALUEX VALUEYCOMMAND VALUEX VALUEX VALUEZ

Separator with Repeatable Variable and Delimiter

If the repeat symbol contains punctuation such as a comma, you must separatemultiple parameters with the punctuation. The following diagram includes therepeat symbol, a comma, and parentheses:

The following is a diagram of a statement with a separator with a repeatablevariable and a delimiter:

┌ ┐─,────────��──COMMAND──(─ ───� ┴─variable─ ─)───────────────────────────────────────��

In the preceding diagram, the word variable is in lowercase italics, indicatingthat it is a value you supply. It is also on the main path, which means that youmust specify at least one entry. The repeat symbol indicates that you canspecify more than one variable and that you must separate the entries withcommas. The parentheses indicate that the group of entries must be enclosedwithin parentheses. Assume that you have three values named VALUEA,VALUEB, and VALUEC for the variable.



The following are some of the statements you can write:

COMMAND (VALUEC) COMMAND (VALUEB,VALUEC) COMMAND (VALUEB,VALUEA) COMMAND (VALUEA,VALUEB,VALUEC)

Optional Repeatable Parameters

The following diagram shows a list of parameters with the repeat symbol foroptional repeatable parameters:

┌ ┐─────────── ┌ ┐─────────── ┌ ┐───────────��──COMMAND─ ───� ┴┬ ┬─────── ───� ┴┬ ┬─────── ───� ┴┬ ┬─────── ───────────────────�� └ ┘─PARM1─ └ ┘─PARM2─ └ ┘─PARM3─

The following are some of the statements you can write:

COMMAND PARM1COMMAND PARM1 PARM2 PARM3COMMAND PARM1 PARM1 PARM3

Default Value for a Parameter

The placement of YES in the following diagram indicates that it is the defaultvalue for the parameter. If you do not include the parameter when you writethe statement, the result is the same as if you had actually specified theparameter with the default value.

The following is a diagram of a statement with a default value for an optionalparameter:

��──COMMAND─ ──┬ ┬───────────────── ─PARM2───────────────────────────────�� │ │┌ ┐─YES─

└ ┘──PARM1= ──┴ ┴─NO──

For this command, COMMAND PARM2 is the equivalent of COMMANDPARM1=YES PARM2.



Variables Representing Several Parameters

In some syntax diagrams, a set of several parameters is represented by asingle reference.

The following is a diagram of a statement with variables representing severalparameters:

��──COMMAND─ ──┬ ┬───────────────────── ─────────────────────────────────�� ├ ┤─PARM1───────────────

└ ┘─┤ parameter-block ├─

parameter-block:├─ ──┬ ┬────────────────── ───────────────────────────────────────────────┤ ├ ┤─PARM2──────────── └ ┘──PARM3 ──┬ ┬─────── ├ ┤─PARM4─ └ ┘─PARM5─

The parameter-block can be displayed in a separate syntax diagram.

Choices you can make from this syntax diagram therefore include, but are notlimited to, the following:

COMMAND PARM1 COMMAND PARM3

COMMAND PARM3 PARM4

Note: Before you can specify PARM4 or PARM5 in this command, you mustspecify PARM3.

Syntax Note

A note in a syntax diagram is similar to a footnote except that the note appearsat the bottom of the diagram.

The following is a diagram of a statement with a syntax note:

��──COMMAND─ ──┬ ┬───────── ─────────────────────────────────────────────�� └ ┘ ─PARM1───(1)

Note:1 This is a note about the item.


JCL Example Notation

JCL Example Notation

This guide uses the following JCL notation.

UPPERCASEIdentifies commands, keywords, and keyword values which must becoded exactly as shown.

symbolsSymbols, such as commas, equal signs, and slashes, must be codedexactly as shown.

Do not type the following when they appear in the JCL examples. They areprovided to clarify the JCL syntax.

lowercaseIdentifies a value or values that you must supply.

. . . Indicates the omission of one or more keywords or parameters that youmust code according to the specific installation at your site.



Chapter 2. DDBTGLM - GeneratingBatch Transactions


When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

For Partitioned Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45For SQL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46For Dataviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

-BTG AUXOUT - Specifying Auxiliary Output Device . . . . . . . . . . . . . 47-BTG TABLE - Special Transactions for Partitioned Tables . . . . . . . . . 48


-BTG TRACE - Printing Diagnostic Information . . . . . . . . . . . . . . . . 49When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

-BTG USER - Preparing and Invoking a User-Written Exit . . . . . . . . . . 50When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

-BTG VERSION - Specifying a Status/Version . . . . . . . . . . . . . . . . . 52-BTG - Initiating Batch Transaction Generator Transactions . . . . . . . . . 53


-BTG START - Indicating a Starting Point . . . . . . . . . . . . . . . . . . . 56-END - Concluding Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 59


Using DDBTGLM for Partitioned Tables . . . . . . . . . . . . . . . . . . . . . 60PARTITION Predefined Path . . . . . . . . . . . . . . . . . . . . . . . . . 60-BTG TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 60How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Sample Job Streams and Output . . . . . . . . . . . . . . . . . . . . . . . . . 62z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Sample Report - DDBTGLM - for DATABASE Structures . . . . . . . . 63Sample Output - DDBTGLM - for DATABASE Structure . . . . . . . . . 68Sample Report - DDBTGLM - for DATAVIEW Structure . . . . . . . . . 73Sample Output - DDBTGLM - for DATAVIEW Structure . . . . . . . . . 75

The Batch Transaction Generator (DDBTGLM) provides a means of creatingDDUPDATE transactions from selected occurrences in Datadictionary.

Chapter 2. DDBTGLM - Generating Batch Transactions 41

You can also use this utility as an archiving system to retain backup occurrenceinformation without using disk storage space allocated to the activeDatadictionary.


When to Use

When to Use

Use the Batch Transaction Generator to:

■ Create DDUPDATE transactions for a related set of occurrences within astructure or for a single occurrence to be implemented in anotherDatadictionary.

■ Create an archive copy of occurrence information in batch transactionformat.

After obtaining the appropriate occurrence definitions, use the batchtransactions the Batch Transaction Generator created as input to theDDUPDATE utility to create or to update occurrences in another Datadictionarysystem or store them as an archived copy.

Note: If SQL objects are involved such as CONSTRAINTS, use the TransportUtility, DDTRSLM. For more information, see Chapter 7, “DDTRSLM -Transporting Definitions.”


How to Use

How to Use

The -BTG transaction initiates the process of generating transactions for one ormore existing occurrence definitions. By using the -BTG START transactionand defining a path, you can initiate the DDBTGLM utility and designate thestarting point for generating the transactions.

In addition to generating transactions with -BTG or -BTG START, you can codeadditional optional transactions. These optional transactions must be codedbefore either the -BTG or -BTG START transaction to ensure accurate andcomplete output. Refer to the following for a description of each of theseoptional transactions.

Transaction: To specify:

-BTG AUXOUT An auxiliary output device

-BTG TABLE Prepare special transactions for partitioned tables.

-BTG TRACE Printing diagnostic information

-BTG USER A particular user-written exit

-BTG VERSION A particular status/version for all transactions generated

After running the Batch Transaction Generator to create the desiredtransactions, you can modify individual transactions before processing them.You can also do this by invoking a user-written exit. For more information, see“-BTG USER - Preparing and Invoking a User-Written Exit” on page 50.

When the DDUPDATE utility encounters a -BTG header transaction (thetransaction generated by the DDBTGLM facility), it treats the entire transactioncollection as either an -ADD or -UPD transaction collection depending on theentity-type, its status, and whether the entity-occurrence already exists. Formore information, see Chapter 8, “DDUPDATE - Updating Datadictionary” onpage 205.

When setting up Batch Transaction Generator transactions, you can use acontinuation capability to enter long transactions. Note the folloring exampleformat:

-BTG START,ELEMENT,- ACCTSRECEIVABLE.CUSTOMERSORDERS(PROD),STANDARD

The continuation is specified by a transaction start character (-) followed by onespace.


Special Considerations


The DDBTGLM job stream or DDBTGLM SYSIN file must contain a -USRtransaction to verify authorization before the batch utility can execute.

To create a copy of a related set of occurrences, you must identify a path whichspecifies where Datadictionary is to start and stop the copying procedure. Youcan use one of the following paths predefined by Datadictionary for DATABASEstructures:

■ STANDARD path■ DBMODEL path (includes DATAVIEW to ELEMENT relationships)■ PARTITION path (only for use with partitioned tables)

For all other structures, including FILE structures, you must define the path.For more information, see “Using Predefined Paths” on page 22.

To create a copy of occurrences with similar names, use generic selection ofone or more characters followed by an asterisk. For example, to find all namesbeginning with DR, you can enter DR*. The asterisk indicates thatDatadictionary is to select only those occurrences with names that begin withthe characters preceding the asterisk for processing.

For Partitioned Tables

To properly process partitioned tables with the DDBTGLM utility, there is apredefined path (PARTITION) and an input transaction (-BTG TABLE).

Using DDBTGLM to generate transactions for a DATABASE structurecontaining partitioned tables is a two-phase process. First, DDBTGLM must berun using the appropriate predefined path for your standard processing, eitherSTANDARD or DBMODEL. These transactions are processed by DDUPDATEfirst. The second phase of the transaction generation is to run against thesame DATABASE occurrence using the PARTITION predefined path and the-BTG TABLE transaction to assure that TABLE occurrences are not affected bythe generated transactions.

As an example, if the SAMPLE-DATABASE database contains partitionedtables, you would execute DDBTGLM twice. The first time with the followinginput:

-DEF PATH,STANDARD-END-BTG VERSION,T2-BTG START,DATABASE,SAMPLE-DATABASE(T1),STANDARD-END

The second execution of the DDBTGLM utility would have the following input:



-DEF PATH,PARTITION-END-BTG VERSION,T2-BTG TABLE,UPD-BTG START,DATABASE,SAMPLE-DATABASE(T1),PARTITION-END

The resulting transactions generated by these two executions can be submittedto DDUPDATE either separately or in the same execution, but the generatedtransactions from the first execution of DDBTGLM must precede thosegenerated by the second execution of DDBTGLM.

More Information

■ For more information about predefined path (PARTITION), see “DATABASEStructure Path for Partitioned Tables Only Using DDBTGLM” on page 23

■ For more information aobut and input transaction (-BTG TABLE), see “-BTGTABLE - Special Transactions for Partitioned Tables” on page 48

For SQL Objects

You cannot use the Batch Transaction Generator to create DDUPDATEtransactions for an occurrence of the VIEW, CONSTRAINT, SYNONYM, PLANor STATEMENT entity-types. -BTG transactions will be generated but thesewill be rejected by DDUPDATE. For more information, see Chapter 7,“DDTRSLM - Transporting Definitions.”

If you generate transactions for an occurrence of the TABLE entity-type whichis accessed by SQL, you cannot access the new version of the table with SQLuntil you modify it. For more information, see “3150 to 3160 TABLETransactions” on page 321 and for information on SQL, see the CADatacom/DB SQL User Guide.

For Dataviews

■ When executing DDBTGLM with a path defined from database throughdataview using a user-defined path, the elements and keys for the datavieware returned in alphabetical sequence. This is the native sequence. Thedataview structure may be modified as a result. Consider using the specialpredefined path named DBMODEL instead.

■ When executing DDBTGLM with the special DBMODEL path and startingon the database, all dataviews and relationships to elements appear at theend of the stream of DDUPDATE transactions.

■ When using a user-defined path to access DATAVIEW occurrences fortransaction generation, if the path used is from ELEMENT or KEY toDATAVIEW, generation of the DATAVIEW transaction is delayed to the endof the path. In all other cases, the transactions are generated in stream.


-BTG AUXOUT - Specifying Auxiliary Output Device

-BTG AUXOUT - Specifying Auxiliary Output Device

Note: You must code this optional transaction before initiating the DDBTGLMutility with either the -BTG or the -BTG START transaction.

In z/OS: Use the -BTG AUXOUT transaction to designate that the output fromthis particular transaction is to be in a format other than SYSPUNCH. This canserve as source transactions for input at another location. Using thistransaction enables you to specify an output format other than unblocked80-byte records.

-BTG AUXOUT Transaction in z/OS

��──-BTG──AUXOUT──────────────────────────────────────────────────────��

In z/VSE: Use the -BTG AUXOUTD or AUXOUTT transaction to designate thatthe output from this particular transaction is to be in a format other thanSYSPCH. Using this transaction enables you to specify an output format otherthan unblocked 80-byte records.

-BTG AUXOUTD or AUXOUTT Transaction in z/VSE

��──-BTG─ ──┬ ┬─AUXOUTD─ ──┬ ┬───────────── ──┬ ┬──────────────── ───────────�� └ ┘─AUXOUTT─ └ ┘ ─,SYSNUM=nnn─ └ ┘ ─,BLKSIZE=nnnnn─

-BTG AUXOUTDSpecifies that the output of the utility is to disk.

-BTG AUXOUTTSpecifies that the output of the utility is to tape.

,SYSNUM=(Optional) Specify the unit number for the output file.



,BLKSIZE=(Optional) Specify the block size for the output file in 80-byte increments.This cannot exceed the ROSFD BLKSIZE for the device as specified inthe DDVPEFT assembly.


Default Value: 4000


-BTG TABLE - Special Transactions for Partitioned Tables

-BTG TABLE - Special Transactions for Partitioned Tables

The -BTG TABLE transaction is used to specify the type of transactions to begenerated at the TABLE level and below, specifically for use with partitionedtables. You must specify the PARTITION path before executing DDBTGLMwith the -BTG TABLE transaction. When the DDUPDATE utility processes aBTG transaction for a TABLE occurrence, the entire TABLE (or RECORD)sub-structure is deleted under the assumption that all of the FIELD, KEY, andELEMENT definitions will be regenerated by the transactions that follow.

When to Use

The -BTG TABLE transaction allows you to specify that only updates are to begenerated at the TABLE level, thus preventing the deletion of the TABLEsub-structure when only minor modifications (no new fields, keys, or elementsare being added).

How to Use

The format of the transaction is as follows:

-BTG TABLE

��──-BTG─ ──TABLE,function ─────────────────────────────────────────────��

,function(Required) If you code this transaction, this entry is required. This entryspecifies the type of transactions to be generated at the TABLE level.Specify BTG for regular DDBTGLM transactions or UPD for only updatetransactions.

Valid Entries: ,BTG or ,UPD

Default Value: (No default) (If you do not code the transaction, regularDDBTGLM transactions are produced.)


-BTG TRACE - Printing Diagnostic Information

-BTG TRACE - Printing Diagnostic Information

The Batch Transaction Generator Trace Facility can collect diagnosticinformation during execution. This information is helpful in resolving problems ifa malfunction occurs while the Batch Transaction Generator is executing.

When to Use

Use the Batch Transaction Generator Trace Facility only at the direction ofTechnical Support to collect diagnostic information during execution.


How to Use

Use the following format to specify the trace facility:

-BTG TRACE

┌ ┐─NO──��──-BTG─ ──TRACE= ──┴ ┴─YES─ ────────────────────────────────────────────��

NO or YESIndicate whether the trace facility is enabled. NO disables the tracefacility. YES enables it.

Valid Entries: NO or YES

Default Value: NO


-BTG USER - Preparing and Invoking a User-Written Exit


A user-written exit transaction directs the Batch Transaction Generator to passcontrol to an exit module for verification or modification of the generatedtransactions. The Batch Transaction Generator calls the specified modulebefore each write to SYSPUNCH or SYSPCH. Use the -BTG USERtransaction to designate the exit module name. After Datadictionary processesthe transaction, the user-written exit module can modify or delete thetransaction before it is written to the output stream. For more information, seeAppendix A, “Sample User-Written Exit for DDBTGLM (COBOL)” on page 595.

To discontinue use of this exit module, you must either disable it or specifyanother user exit module. A -BTG USER= transaction without a module namedisables the previously specified exit module. Each new user exit modulewhich you specify automatically supersedes any previous exit module. There isno limit on the number of user exit modules which you can employ during oneexecution of the Batch Transaction Generator.

When the user exit gets control, register 1 points to a parameter list.

■ The first fullword in the parameter list is the address of the buffer containingthe generated transaction that is about to be written. In your exit module,you can modify the generated transaction in any way or you can reject it(choose not to write it). To reject a transaction, move hexadecimal zeros(X'00') into the first position in the transaction buffer.

■ The second fullword in the parameter list is the address of a buffercontaining a copy of the last header (-ADD) transaction generated.

Note: Each transaction can be a maximum of 80 bytes in length.

When all requested occurrences have been processed by the BatchTransaction Generator, the user exit is called one last time. In this case, thefirst parameter points to a transaction in the buffer filled with a specific specialcharacter, called the “flag line,” to indicate that this is the last call. The flag lineis filled with asterisks (*) unless you use the FLAG= parameter to specify adifferent character. At this time, you can place any last transaction into thebuffer to be written.



When to Use

When you want to pass control to an exit module for the inspection andmodification of transactions or to disable a previously specified exit module,code a -BTG USER transaction. When your exit module returns control to theBatch Transaction Generator, the modified transaction is written to SYSPUNCHor SYSPCH.

A user-written exit module can:

■ Make changes to the output transactions before they are written to theoutput data set or output file.

■ Delete generated transactions before writing them to the output data set oroutput file.


How to Use

Use the following command format to execute a user-written exit module:

Executing a User-Written Exit Module

��──-BTG─ ──USER= ──┬ ┬───────────── ──┬ ┬───────── ────────────────────────�� └ ┘ ─module-name─ └ ┘ ─,FLAG=x─

module-name(Optional) Enter the name of the user-written exit module that the BatchTransaction Generator calls before each write to the output data set.Leave this field blank to disable the previously specified exit module.

Valid Entries: Name of user-written exit module(blank)


,FLAG=(Optional) Designate the character used to fill the flag line. This flag lineis the one pointed to by the first fullword parameter upon entry to the userexit for the last time. The preceding comma is required if you specify thisparameter.

Note: Do not choose a character that will be misinterpreted by the logicof your user exit. For example, if an occurrence being processed byDDBTGLM BTG has an entire line of asterisks (*) or dashes ( to ) toseparate portions of text, do not choose asterisk or dash as the flagcharacter.

Valid Entries: Any character

Default Value: * (asterisk)


-BTG VERSION - Specifying a Status/Version

-BTG VERSION - Specifying a Status/Version

The -BTG VERSION transaction designates the particular status/version thatyou want Datadictionary to use for the transactions generated by -BTG or -BTGSTART transaction. Code the -BTG VERSION transaction before the -BTG or-BTG START transaction. If you do not provide this transaction, the default forversion is:

T001 For CA Datacom/DB and CA FILE Model entity-types

001 For all other entity-types

If you are using the DDBTGLM to generate UNIVERSAL field transactions, youmust specify 0000 as the status/version.

For the CA Datacom/DB and CA FILE Model entity-types, unless you specifyPROD, all occurrences in the generated transactions will be in TEST status. Ifyou are migrating definitions from one system to another, you must copy themto PRODuction status and catalog them to the CA Datacom/DB Directory at thedestination system.

Note: The CATALOG function is not available in the version of Datadictionarysupplied with CA Datacom/AD. See documentation for the CA applicationproduct using CA Datacom/AD for information.

Use the following format to specify a status/version:

-BTG VERSION

��──-BTG─ ──VERSION,stat ───────────────────────────────────────────────��

,stat (Required) If you code this transaction, this entry is required. This is thestatus/version for the generated transactions specified by the -BTG or-BTG START transaction.

Valid Entries: 0000T001 to T9991 to 999PROD



-BTG - Initiating Batch Transaction Generator Transactions


The -BTG transaction initiates the process of generating transactionsrepresenting one or more existing occurrence definitions. Subsequenttransactions depend on the nature and scope of the copying process as theprevious transactions presented explain.

When to Use

Use the -BTG transaction to request a duplicate copy of the specifiedoccurrence totally independent of any structures.

To generate a set of transactions and their existing relationships, you mustdefine a structure or path in order to generate the relationship transactions. Formore information, see “Using Predefined Paths” on page 22 and “-BTG START- Indicating a Starting Point” on page 56.

How to Use

Before you initiate the DDBTGLM utility by coding the -BTG transaction, reviewthe following chart to ensure the output you request is complete. You must firstcode the following transaction for specific output:

-BTG VERSIONSpecify a particular status/version for all transactions generated

-BTG AUXOUTDesignate an auxiliary output device

-BTG USERPrepare and invoke a particular user-written exit -BTG TRACE

Print diagnostic information

Use the following command format:.

-BTG Command Format

��──-BTG──entity-type,─ ──┬ ┬────────────── ──occ-name(stat ──┬ ┬─────── ) ───� └ ┘─parent-name.─ └ ┘─,ovrd─

�─ ──┬ ┬───────────── ───────────────────────────────────────────────────�� └ ┘─,as-of-date─



entity-type,(Required) Specify any valid Datadictionary or user-defined entity-type.

Valid Entries: A valid entity-typeALL

Default Value: ALL

parent-name.(Optional) Specify the desired TABLE or RECORD occurrence name.This entry is only valid if the entity-type specified is FIELD, KEY orELEMENT. Your entry must be followed by a period (.) to concatenatethe TABLE or RECORD occurrence name with the name of the FIELD,KEY or ELEMENT occurrence.

You can enter a generic selection or ALL for all occurrences of thespecified entity-type that meet your other criteria.

Valid Entries: TABLE or RECORD occurrence nameGeneric selectionALL

Default Value: ALL

occ-name(Required) Specify the name of the desired Datadictionary occurrence.

You can enter ALL for all occurrences or a generic selection using 1 to 31characters of an occurrence name and an asterisk (*). For example,ACC* processes all occurrences of this entity-type with ACC as the firstthree characters in the name.

Valid Entries: Existing occurrence nameGeneric selectionALL


(stat)(Required) Specify the status/version of the selected occurrence.

T001 to T999 are valid for DATABASE, AREA, TABLE, FILE, RECORD,KEY, ELEMENT, FIELD, and DATAVIEW occurrences only.

1 to 999 are valid for all other occurrences.

Valid Entries: TEST or T001 to T9991 to 999PRODHIST or H000 to H997 (000—997 is the generationnumber)ALLASOF




,ovrd(Optional) Enter the system override code within the parenthesessurrounding the stat parameter if you are selecting an occurrence which isprotected from unauthorized access by Lock Level 2. If the occurrence isnot protected by this lock level, you can omit the override code and itspreceding comma.

Valid Entries: System override code


,as-of-date(Optional) Specify the date and time to be used if you coded ASOF in thestat parameter. (Use ASOF to obtain the version of the occurrence inPRODuction status on the specified date and time.) The format isYYYYMMDDhhmm, where YYYY is the year, MM is the month, DD is theday, hh is the hour and mm is the minute. The preceding comma isrequired if you use this parameter.

You can specify a partial date/time if you do not know the full date andtime. Any of the date/time positions which you do not use default to zeroor the earliest period of the date/time you provide. For example,20020101 is the beginning of the day on January 1, 2002, whereas200201012359 is the end of the same day.

Note: If your time value includes seconds, round up to the nearestminute.

Valid Entries: A valid date that begins with 1 or 2



-BTG START - Indicating a Starting Point


The -BTG START transaction establishes the starting point for generatingtransactions. It is possible to include multiple -BTG START transactions in asingle execution of the Batch Transaction Generator.

When to Use: If you are processing a path, use the -BTG START transactionto specify the point at which you want to begin generating DDUPDATEtransactions.

You can process a single path or multiple paths with the Batch TransactionGenerator. If you define one path, it can be referenced in multiple -BTGSTART transactions.

Because DDBTGLM only stores one path at a time, if you want to use multiplepaths, you must define each path before the -BTG START transaction whichwill use that path. For example, you can define a path named PATH1 andspecify a -BTG START transaction using PATH1, then define a second pathnamed PATH2 and specify another -BTG START transaction using PATH2.

If you define both paths first, then specify two consecutive -BTG STARTtransactions, the first using PATH1 and the second using PATH2. The first-BTG START transaction using PATH1 is bypassed and the following messageis output:

INVALID CONTROL CARD - IGNORED

How to Use: Before you initiate the DDBTGLM utility by coding the -BTGtransaction, review the following chart to ensure the output you request iscomplete. You must first code the following transaction for specific output:

-BTG VERSIONSpecify a particular status/version for all transactions generated

-BTG AUXOUTDesignate an auxiliary output device

-BTG USERPrepare and invoke a particular user-written exit

-BTG TRACEPrint diagnostic information



Use the following transaction format to specify the point at which you want tobegin generating transactions for submission with the DDUPDATE utility:

-BTG START

��──-BTG─ ──START,entity-type, ──────────────────────────────────────────�

�─ ── ──┬ ┬────────────── occ-name(stat ──┬ ┬─────── ) ─,path-name─────────────� └ ┘ ─parent-name.─ └ ┘ ─,ovrd─

�─ ──┬ ┬───────────── ───────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

,entity-type,(Required) Specify a valid Datadictionary or user-defined entity-typespecified in the from parameter within the structure defined in the pathdefinition transactions.

Valid Entries: Name of the desired entity-type within the defined path


parent-name.(Optional) Specify the desired TABLE or RECORD occurrence name onlyif the entity-type specified is FIELD, KEY, or ELEMENT. Your entry mustbe followed by a period (.) to concatenate the TABLE or RECORDoccurrence name with the name of the FIELD, KEY, or ELEMENToccurrence.


Valid Entries: TABLE or RECORD occurrence nameGeneric selectionALL

Default Value: ALL

occ-name(Required) Specify the name of the desired Datadictionary occurrence.

You can enter a generic selection or ALL for all occurrences of thespecified entity-type that meet your other criteria.

Valid Entries: Name of the occurrenceGeneric selectionALL


(stat)(Required) Specify the status/version of the selected occurrence.

T001 to T999 are valid for DATABASE, AREA, TABLE, FILE, RECORD,KEY, ELEMENT, FIELD, and DATAVIEW occurrences only.



1 to 999 are valid for all other occurrences.

Valid Entries: TEST or T001 to T999PROD1 to 999HIST or H000 to H997 (000—997 is the generationnumber)I1 to I999ALLASOF


,ovrd(Optional) Specify the system override code within the parenthesessurrounding the stat parameter if you are selecting an occurrence which isprotected from unauthorized access by Lock Level 2. If the occurrence isnot protected by this lock level, you can omit the override code and itspreceding comma.



,path-name(Required) Specify the name of the path defined in the path definitiontransaction. For more information, see “Using Predefined Paths” onpage 22.

Valid Entries: Specified path name


,as-of-date(Optional) Specify the date and time to be used only if you coded ASOFin the stat parameter. (Use ASOF to obtain the version of the occurrencein PRODuction status on the specified date and time.) The format isYYYYMMDDhhmm, where YYYY is the year, MM is the month, DD is theday, hh is the hour and mm is the minute.

You can specify a partial date/time if you do not know the full date andtime. Any of the date/time positions which you do not use default to zeroor the earliest period of the date/time you provide. For example,20020101 is the beginning of the day on January 1, 2002, whereas200201012359 is the end of the same day.


Valid Entries: A valid date that begins with 1 or 2



-END - Concluding Processing

-END - Concluding Processing

The -END transaction terminates a collection of Batch Transaction Generatortransactions.

Insert an -END transaction to conclude a collection of transactions following aheader transaction. This is a way to ensure that the collection terminates.

Datadictionary automatically assumes the processing associated with aparticular header transaction is complete when Datadictionary encounters thenext header transaction or end-of-file. Datadictionary then creates its own-END transaction.

When to Use

Use the -END transaction to designate the end of a collection of BatchTransaction Generator transactions.

How to Use

After the last header transaction in a job stream or SYSIN file, insert an -ENDtransaction to inform Datadictionary that the last transaction has beenprocessed.

Use the following transaction format to designate the end of a collection ofBatch Transaction Generator transactions.

-END

��──-END──────────────────────────────────────────────────────────────��


Using DDBTGLM for Partitioned Tables


To properly process partitioned tables using DDBTGLM, you must specify apredefined path (PARTITION) and a special input transaction.

PARTITION Predefined Path

This path is specified using the following transaction:

-DEF PATH,PARTITION

The path is only recognized by the DDBTGLM utility. The following representsthe trace structure of the path:

-DEF TRACE,DATABASE.AREA,$INTERNAL,SKIP -DEF TRACE,AREA.TABLE,$INTERNAL,SKIP -DEF TRACEF,TABLE.TABLE,TBL-TBL-PARTITION -DEF TRACE,PARTITION-COLUMN-VALUE.FIELD,PCV-FLD-PARTITION -DEF TRACE,TABLE.KEY,TBL-KEY-PARTITION

-BTG TABLE Transaction

The -BTG TABLE transaction is used to specify the type of transactions to begenerated at the table level and below. When the DDUPDATE utility processesa BTG transaction for a TABLE occurrence, the entire TABLE (or RECORD)substructure is deleted with the assumption that all of the FIELD, KEY, andELEMENT definitions will be regenerated by the transactions that follow.

The -BTG TABLE transaction allows you to specify that only updates are to begenerated at the TABLE level, thus avoiding the deletion of the TABLEsubstructure when only minor modifications (no new fields, keys, or elementsare being added) are to be performed. The format of the transaction is asfollows:

Partitioned Table -BTG Transaction

��──-BTG─ ──TABLE,function ─────────────────────────────────────────────��

-BTG TABLESpecifies that this is the special DDBTGLM process for partitioned tables

,function(Required) If you code this transaction, this entry is required. Use it tospecify the type of transactions to be generated at the TABLE level, either-BTG or -UPD transactions.

Valid Entries: ,BTG or ,UPD




How to Use

Using DDBTGLM to generate transactions for a DATABASE occurrencecontaining partitioned tables is a two-phase process. First, DDBTGLM must berun using the appropriate predefined path for your standard processing, eitherSTANDARD or DDMODEL. These transactions are processed by DDUPDATEfirst. The second phase of the transaction generation is to run against thesame DATABASE occurrence using the PARTITION predefined path and the-BTG TABLE transaction to assure that TABLE occurrences are not affected bythe generated transactions.

As an example, if DATABASE occurrence SAMPLE-DATABASE containspartitioned tables, DDBTGLM would be executed twice. The first time with thefollowing input:

-DEF PATH,STANDARD -END -BTG VERSION,T2 -BTG START,DATABASE,SAMPLE-DATABASE(T1),STANDARD -END

The second execution of the DDBTGLM utility would have the following input:

-DEF PATH,PARTITION -END -BTG VERSION,T2 -BTG TABLE,UPD -BTG START,DATABASE,SAMPLE-DATABASE(T1),PARTITION -END

The resulting transaction generated by these two executions can be sumitted toDDUPDATE either separately or in the same job, but the generatedtransactions from the first execution of DDBTGLM must precede thosegenerated by the second execution.


Sample Job Streams and Output


The following are example JCL and sample output and reports.

z/OS Example JCL

Note: Use the following as a guide to prepare your JCL. The JCL statementsare for example only. Lowercase letters in a statement indicate a value youmust supply. Code all statements to your site and installation standards.

//jobname See the note above and page 19. // EXEC PGM=DDBTGLM,REGION=124K //STEPLIB See the note above and page 19. //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//AUXOUT DD DSN=dd.output,UNIT=..., Auxiliary output // dcb=(blksize=nnnn) Optional info//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR SAMPLE-USER Authorized user information -DEF PATH,STANDARD -END -BTG START,DATABASE,ORDER-ENTRY(PROD),STANDARD -BTG AUXOUT -END /

z/VSE Example JCL


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYSnnn,device-type,VOL=volser,SHR // DLBL auxout,'aux.output.file' Output other than SYSPCH // EXTENT // EXEC DDBTGLM,SIZE=6K -USR SAMPLE-USER Authorized user information -DEF PATH,STANDARD -END -BTG START,DATABASE,ORDER-ENTRY(PROD),STANDARD -BTG AUXOUTD,SYSNUM=nnn,BLKSZE=nnnn Parms match those in ROSFD -END / /& $$ EOJ



Sample Report - DDBTGLM - for DATABASE Structures

The following is the report produced through execution of the sample JCL. Thereport has been truncated for this example.

If any error is encountered during processing transactions, Datadictionaryproduces an Error Recap Report as the last page of the report. For moreinformation, see “Error Recap Portion” on page 31.


Security Level: 1 Backup/Transport Generator Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

-DEF PATH,STANDARD -END -BTG START,DATABASE,ORDER-ENTRY(PROD),STANDARD GENERATED CARD ==> -BTG DATABASE,ORDER-ENTRY(T1) GENERATED CARD ==> 11 'DEMO-ADMIN ', GENERATED CARD ==> - 'DEMO-ADMIN ' GENERATED CARD ==> 12 'ORDER-ENTRY DEMO DATABASE ' GENERATED CARD ==> 12 TEXT CLS STRUCTURE GENERATED CARD ==> 12 TEXT ADD GENERATED CARD ==> The ORDER-ENTRY database consists of nine tables defined to eight GENERATED CARD ==> areas. The areas and tables are as follows: GENERATED CARD ==> GENERATED CARD ==> Area Name Table Name GENERATED CARD ==> --------- ---------- GENERATED CARD ==> GENERATED CARD ==> ACCTS ACCTS GENERATED CARD ==> CUST CUST GENERATED CARD ==> DETAIL DETAIL GENERATED CARD ==> ORDERS GENERATED CARD ==> ITEMS ITEMS GENERATED CARD ==> ORD-NO ORD-NO GENERATED CARD ==> RCPTS RCPTS GENERATED CARD ==> SHIPTO SHIPTO GENERATED CARD ==> SLSHST SLSHST GENERATED CARD ==> 12 TEXT END GENERATED CARD ==> 29 1 RELATION DATACOM N GENERATED CARD ==> 291 N GENERATED CARD ==> -END GENERATED CARD ==> -BTG AREA,ACCTS(T1) GENERATED CARD ==> 1 CONNECT,ORDER-ENTRY GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'ORDER ENTRY DEMO ACCTS AREA ' GENERATED CARD ==> 31 ACT GENERATED CARD ==> 32 Y 338 496 DATACOM 1 5 GENERATED CARD ==> 34 ACCTS N GENERATED CARD ==> -END GENERATED CARD ==> -BTG TABLE,ACCTS(T1) GENERATED CARD ==> 1 CONNECT,ACCTS GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'ORDER ENTRY DEMO ACCTS FILE ' GENERATED CARD ==> 315 ACT 6 N N N N Y DATACOM Y GENERATED CARD ==> 3151 31 N GENERATED CARD ==> 3152 Y SYSADM ACCTS GENERATED CARD ==> -END GENERATED CARD ==> -GRP START,TABLE,ACCTS(T1) GENERATED CARD ==> -BTG FIELD,ORD-ID GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 START START GENERATED CARD ==> 412 S N R N 5 1 N C N N N N N N 5 GENERATED CARD ==> 413 ORDER ID GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 ORD_ID GENERATED CARD ==> -END





GENERATED CARD ==> -BTG FIELD,BILL-DT GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 ORD-ID START GENERATED CARD ==> 412 C C L N 1 N C N N N N N N GENERATED CARD ==> 413 BILLING DATE GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 BILL_DT GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,BILL-YR GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 BILL-DT BILL-DT GENERATED CARD ==> 412 S C L N 2 1 N C N N N N N N 2 GENERATED CARD ==> 413 BILLING YEAR GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 BILL_YR GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,BILL-MO GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 BILL-YR BILL-DT GENERATED CARD ==> 412 S C L N 2 1 N C N N N N N N 2 GENERATED CARD ==> 413 BILLING MONTH GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 BILL_MO GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,BILL-DAY GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 BILL-MO BILL-DT GENERATED CARD ==> 412 S C L N 2 1 N C N N N N N N 2 GENERATED CARD ==> 413 BILLING DAY GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 BILL_DAY GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,ORD-AMT GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 BILL-DT START GENERATED CARD ==> 412 S D R Y 5 2 1 N C N N N N N N 9 GENERATED CARD ==> 413 ORDER DOLLAR AMOUNT GENERATED CARD ==> 414 Z,ZZZ,ZZ9.99 GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 ORD_AMT GENERATED CARD ==> -END





GENERATED CARD ==> -BTG FIELD,FRT-AMT GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 ORD-AMT START GENERATED CARD ==> 412 S D R Y 5 2 1 N C N N N N N N 9 GENERATED CARD ==> 413 FREIGHT AMOUNT GENERATED CARD ==> 414 Z,ZZZ,ZZ9.99 GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 FRT_AMT GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,DISC-AMT GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 FRT-AMT START GENERATED CARD ==> 412 S D R Y 5 2 1 N C N N N N N N 9 GENERATED CARD ==> 413 ORDER DISCOUNT AMOUNT GENERATED CARD ==> 414 Z,ZZZ,ZZ9.99 GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 DISC_AMT GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,CUST-ID GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 DISC-AMT START GENERATED CARD ==> 412 C C L N 1 N C N N N N N N GENERATED CARD ==> 413 CUSTOMER ID GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 CUST_ID GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,IND-CD GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 CUST-ID CUST-ID GENERATED CARD ==> 412 S C L N 1 1 N C N N N N N N 1 GENERATED CARD ==> 413 INDUSTRY CODE GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 IND_CD GENERATED CARD ==> -END GENERATED CARD ==> -BTG FIELD,CUST-NO GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 41 IND-CD CUST-ID GENERATED CARD ==> 412 S C L N 4 1 N C N N N N N N 4 GENERATED CARD ==> 413 CUSTOMER NUMBER GENERATED CARD ==> 416 N GENERATED CARD ==> 417 A N GENERATED CARD ==> 42 CUST_NO GENERATED CARD ==> -END GENERATED CARD ==> -GRP END





GENERATED CARD ==> -BTG KEY,ACCTS. GENERATED CARD ==> - CUST-ID-KEY(T1) GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'CUST-ID SECONDARY KEY ' GENERATED CARD ==> 5 ACSTI 1 N N 1 N ACTCUSKY ACCTS-CUST-ID-KEY GENERATED CARD ==> 51 ADD CUST-ID GENERATED CARD ==> 511 $FIRST GENERATED CARD ==> 512 ACT-CUST-ID-KEY CUSTID A N GENERATED CARD ==> 51 ADD IND-CD GENERATED CARD ==> 511 CUST-ID GENERATED CARD ==> 512 ACT-IND-CD-KEY INDCD A N GENERATED CARD ==> 51 ADD CUST-NO GENERATED CARD ==> 511 IND-CD GENERATED CARD ==> 512 ACT-CUST-NO-KEY CUSTNO A N GENERATED CARD ==> 51 N ACSTI_ACT1 N GENERATED CARD ==> -END GENERATED CARD ==> -BTG KEY,ACCTS. GENERATED CARD ==> - ORD-ID-KEY(T1) GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'ORD-ID MASTER KEY ' GENERATED CARD ==> 5 ACTOR 4 Y Y 5 Y ACTORDKY ACCTS-ORD-ID-KEY GENERATED CARD ==> 51 ADD ORD-ID GENERATED CARD ==> 511 $FIRST GENERATED CARD ==> 512 ACT-ORD-ID-KEY ORDID A N GENERATED CARD ==> 51 N ACTOR_ACT1 N GENERATED CARD ==> -END GENERATED CARD ==> -BTG ELEMENT,ACCTS. GENERATED CARD ==> - ACCTS(T1) GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'FULL RECORD ELEMNT ' GENERATED CARD ==> 12 TEXT CLS STANDARD GENERATED CARD ==> 12 TEXT ADD GENERATED CARD ==> The ACCTS element of the ACCTS table consists of the order-id; GENERATED CARD ==> billing date (in YYMMDD format); the order, freight and discount GENERATED CARD ==> amounts; and customer identification information. GENERATED CARD ==> All fields in the ACCTS table are included in this element. GENERATED CARD ==> 12 TEXT END GENERATED CARD ==> 6 ACTFL ACCTREC ACCTS GENERATED CARD ==> 61 ADD ORD-ID GENERATED CARD ==> 611 ACT-ORD-ID ORDID GENERATED CARD ==> 61 ADD BILL-DT GENERATED CARD ==> 611 ACT-BILL-DT BILLDT GENERATED CARD ==> 61 ADD BILL-YR GENERATED CARD ==> 611 ACT-BILL-YR BILLYR GENERATED CARD ==> 61 ADD BILL-MO GENERATED CARD ==> 611 ACT-BILL-MO BILLMO GENERATED CARD ==> 61 ADD BILL-DAY GENERATED CARD ==> 611 ACT-BILL-DAY BILLDAY





GENERATED CARD ==> 61 ADD ORD-AMT GENERATED CARD ==> 611 ACT-ORD-AMT ORDAMT GENERATED CARD ==> 61 ADD FRT-AMT GENERATED CARD ==> 611 ACT-FRT-AMT FRTAMT GENERATED CARD ==> 61 ADD DISC-AMT GENERATED CARD ==> 611 ACT-DISC-AMT DISCAMT GENERATED CARD ==> 61 ADD CUST-ID GENERATED CARD ==> 611 ACT-CUST-ID CUSTID GENERATED CARD ==> 61 ADD IND-CD GENERATED CARD ==> 611 ACT-IND-CD INDCD GENERATED CARD ==> 61 ADD CUST-NO GENERATED CARD ==> 611 ACT-CUST-NO CUSTNO GENERATED CARD ==> -END GENERATED CARD ==> -BTG ELEMENT,ACCTS. GENERATED CARD ==> - CUST-ID(T1) GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'CUST-ID ELEMENT ' GENERATED CARD ==> 12 TEXT CLS STANDARD GENERATED CARD ==> 12 TEXT ADD GENERATED CARD ==> The CUST-ID element of the ACCTS table consists of information which GENERATED CARD ==> identifies the customer (customer-id, customer number, etc.). GENERATED CARD ==> 12 TEXT END GENERATED CARD ==> 6 ACTCS ACTCUST ACCTS-CUST-ID GENERATED CARD ==> 61 ADD CUST-ID GENERATED CARD ==> 611 ACT-CUST-ID CUSTID GENERATED CARD ==> 61 ADD IND-CD GENERATED CARD ==> 611 ACT-IND-CD INDCD GENERATED CARD ==> 61 ADD CUST-NO GENERATED CARD ==> 611 ACT-CUST-NO CUSTNO GENERATED CARD ==> -END GENERATED CARD ==> -BTG ELEMENT,ACCTS. GENERATED CARD ==> - ORD-ID(T1) GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'ORD-ID ELEMENT ' GENERATED CARD ==> 12 TEXT CLS STANDARD GENERATED CARD ==> 12 TEXT ADD GENERATED CARD ==> The ORD-ID element of the ACCTS table consists of the single field GENERATED CARD ==> ORD-ID (order-id). GENERATED CARD ==> 12 TEXT END GENERATED CARD ==> 6 ACTOR ACTORDID ACCTS-ORD-ID GENERATED CARD ==> 61 ADD ORD-ID GENERATED CARD ==> 611 ACT-ORD-ID ORDID GENERATED CARD ==> -END GENERATED CARD ==> -BTG AREA,CUST(T1) GENERATED CARD ==> 1 CONNECT,ORDER-ENTRY GENERATED CARD ==> 11 'DEMO ADMIN ', GENERATED CARD ==> - 'DEMO ADMIN ' GENERATED CARD ==> 12 'CUSTOMERS AREA ' GENERATED CARD ==> 31 CUS GENERATED CARD ==> 32 Y 338 496 DATACOM 1 5 GENERATED CARD ==> 34 CUST N GENERATED CARD ==> -END

. . .

. . .

. . .



Sample Output - DDBTGLM - for DATABASE Structure

The following is the output produced through execution of the sample JCL. Thelisting has been truncated for this example.

-BTG DATABASE,ORDER-ENTRY(T1)11 'DEMO-ADMIN ',- 'DEMO-ADMIN '12 'ORDER-ENTRY DEMO DATABASE '12 TEXT CLS STRUCTURE12 TEXT ADDThe ORDER-ENTRY database consists of nine tables defined to eight

areas. The areas and tables are as follows:

Area Name Table Name --------- ----------

ACCTS ACCTS CUST CUST DETAIL DETAIL ORDERS ITEMS ITEMS ORD-NO ORD-NO RCPTS RCPTS SHIPTO SHIPTO SLSHST SLSHST12 TEXT END29 1 RELATION DATACOM N291 N-END-BTG AREA,ACCTS(T1)1 CONNECT,ORDER-ENTRY11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'ORDER ENTRY DEMO ACCTS AREA '31 ACT32 Y 338 496 DATACOM 1 534 ACCTS N-END-BTG TABLE,ACCTS(T1)1 CONNECT,ACCTS11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'ORDER ENTRY DEMO ACCTS FILE '315 ACT 6 N N N N Y DATACOM Y 3151 31 N 3152 Y SYSADM ACCTS-END -BTG TABLE,ACCTS(T1) 1 CONNECT,ACCTS 11 'DEMO ADMIN ', - 'DEMO ADMIN ' 12 'ORDER-ENTRY ACCTS TABLE ' 111 ADD ORDER-ENTRY 111 ADD ACCTS 113 ADD ACCTS-TABLE 315 ACT 6 N N Y N Y DATACOM Y 3151 31 N



3152 N -END -GRP START,TABLE,ACCTS(T1) -BTG FIELD,ORD-ID 11 'DEMO ADMIN ', - 'DEMO ADMIN ' 12 'ACCTS ORD-ID FIELD ' 111 ADD ORDER-ENTRY 111 ADD ACCTS 113 ADD ACCTS-ORD-ID 41 START START 412 S N R N 5 1 N C 413 ORDER ID 416 N 417 A N 42 ORD_ID -END -BTG FIELD,BILL-DT 11 'DEMO ADMIN ', - 'DEMO ADMIN ' 12 'ACCTS BILL-DT FIELD ' 111 ADD ORDER-ENTRY 111 ADD ACCTS 111 ADD DATE 113 ADD ACCTS-BILL-DT 41 ORD-ID START 412 C C L N 1 N C 413 BILLING DATE 416 N 417 A N 42 BILL_DT -END-BTG FIELD,BILL-YR11 'DEMO ADMIN ',- 'DEMO ADMIN '41 BILL-DT BILL-DT412 S C L N 2 1 N C N N N N N N 2413 BILLING YEAR416 N417 A N42 BILL_YR-END-BTG FIELD,BILL-MO11 'DEMO ADMIN ',- 'DEMO ADMIN '41 BILL-YR BILL-DT412 S C L N 2 1 N C N N N N N N 2413 BILLING MONTH416 N417 A N42 BILL_MO-END-BTG FIELD,BILL-DAY11 'DEMO ADMIN ',- 'DEMO ADMIN '41 BILL-MO BILL-DT412 S C L N 2 1 N C N N N N N N 2413 BILLING DAY416 N



417 A N42 BILL_DAY-END-BTG FIELD,ORD-AMT11 'DEMO ADMIN ',- 'DEMO ADMIN '41 BILL-DT START412 S D R Y 5 2 1 N C N N N N N N 9413 ORDER DOLLAR AMOUNT414 Z,ZZZ,ZZ9.99416 N417 A N42 ORD_AMT-END-BTG FIELD,FRT-AMT11 'DEMO ADMIN ',- 'DEMO ADMIN '41 ORD-AMT START412 S D R Y 5 2 1 N C N N N N N N 9413 FREIGHT AMOUNT414 Z,ZZZ,ZZ9.99416 N417 A N42 FRT_AMT-END-BTG FIELD,DISC-AMT11 'DEMO ADMIN ',- 'DEMO ADMIN '41 FRT-AMT START412 S D R Y 5 2 1 N C N N N N N N 9413 ORDER DISCOUNT AMOUNT414 Z,ZZZ,ZZ9.99416 N417 A N42 DISC_AMT-END-BTG FIELD,CUST-ID11 'DEMO ADMIN ',- 'DEMO ADMIN '41 DISC-AMT START412 C C L N 1 N C N N N N N N413 CUSTOMER ID416 N417 A N42 CUST_ID-END-BTG FIELD,IND-CD11 'DEMO ADMIN ',- 'DEMO ADMIN '41 CUST-ID CUST-ID412 S C L N 1 1 N C N N N N N N 1413 INDUSTRY CODE416 N417 A N42 IND_CD-END-BTG FIELD,CUST-NO11 'DEMO ADMIN ',- 'DEMO ADMIN '



41 IND-CD CUST-ID412 S C L N 4 1 N C N N N N N N 4413 CUSTOMER NUMBER416 N417 A N42 CUST_NO-END-GRP END-BTG KEY,ACCTS.- CUST-ID-KEY(T1)11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'CUST-ID SECONDARY KEY '5 ACSTI 1 N N 1 N ACTCUSKY ACCTS-CUST-ID-KEY51 ADD CUST-ID511 $FIRST512 ACT-CUST-ID-KEY CUSTID A N51 ADD IND-CD511 CUST-ID512 ACT-IND-CD-KEY INDCD A N51 ADD CUST-NO511 IND-CD512 ACT-CUST-NO-KEY CUSTNO A N51 N ACSTI_ACT1 N-END-BTG KEY,ACCTS.- ORD-ID-KEY(T1)11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'ORD-ID MASTER KEY '5 ACTOR 4 Y Y 5 Y ACTORDKY ACCTS-ORD-ID-KEY51 ADD ORD-ID511 $FIRST512 ACT-ORD-ID-KEY ORDID A N51 N ACTOR_ACT1 N-END-BTG ELEMENT,ACCTS.- ACCTS(T1)11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'FULL RECORD ELEMNT '12 TEXT CLS STANDARD12 TEXT ADDThe ACCTS element of the ACCTS table consists of the order-id;

billing date (in YYMMDD format); the order, freight and discountamounts; and customer identification information.All fields in the ACCTS table are included in this element.

12 TEXT END6 ACTFL ACCTREC ACCTS61 ADD ORD-ID611 ACT-ORD-ID ORDID61 ADD BILL-DT611 ACT-BILL-DT BILLDT61 ADD BILL-YR611 ACT-BILL-YR BILLYR61 ADD BILL-MO611 ACT-BILL-MO BILLMO61 ADD BILL-DAY611 ACT-BILL-DAY BILLDAY



61 ADD ORD-AMT611 ACT-ORD-AMT ORDAMT61 ADD FRT-AMT611 ACT-FRT-AMT FRTAMT61 ADD DISC-AMT611 ACT-DISC-AMT DISCAMT61 ADD CUST-ID611 ACT-CUST-ID CUSTID61 ADD IND-CD611 ACT-IND-CD INDCD61 ADD CUST-NO611 ACT-CUST-NO CUSTNO-END-BTG ELEMENT,ACCTS.- CUST-ID(T1)11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'CUST-ID ELEMENT '12 TEXT CLS STANDARD12 TEXT ADDThe CUST-ID element of the ACCTS table consists of information which

identifies the customer (customer-id, customer number, etc.).12 TEXT END6 ACTCS ACTCUST ACCTS-CUST-ID61 ADD CUST-ID611 ACT-CUST-ID CUSTID61 ADD IND-CD611 ACT-IND-CD INDCD61 ADD CUST-NO611 ACT-CUST-NO CUSTNO-END-BTG ELEMENT,ACCTS.- ORD-ID(T1)11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'ORD-ID ELEMENT '12 TEXT CLS STANDARD12 TEXT ADDThe ORD-ID element of the ACCTS table consists of the single field

ORD-ID (order-id).12 TEXT END6 ACTOR ACTORDID ACCTS-ORD-ID61 ADD ORD-ID611 ACT-ORD-ID ORDID-END-BTG AREA,CUST(T1)1 CONNECT,ORDER-ENTRY11 'DEMO ADMIN ',- 'DEMO ADMIN '12 'CUSTOMERS AREA '31 CUS32 Y 338 496 DATACOM 1 534 CUST N-END. . .. . .. . .



Sample Report - DDBTGLM - for DATAVIEW Structure

The following is an example of a report where a dataview is the entity-type:



-DEF PATH,PATH1 21-DEF TRACE,DATAVIEW.ELEMENT,$INTERNAL 22-END 23-BTG START,DATAVIEW,ORDERS(PROD),PATH1 24GENERATED CARD ==> -BTG DATAVIEW,ORDERS(T1)GENERATED CARD ==> 11 'DEMO ADMIN ',GENERATED CARD ==> - 'DEMO ADMIN 'GENERATED CARD ==> 719 OEORDER OE-ORDER YGENERATED CARD ==> -ENDGENERATED CARD ==> -BTG ELEMENT,ORDERS.GENERATED CARD ==> - ORDERS(T1)GENERATED CARD ==> 11 'DEMO ADMIN ',GENERATED CARD ==> - 'DEMO ADMIN 'GENERATED CARD ==> 12 'ORDERS FULL TABLE ELEMENT 'GENERATED CARD ==> 13 RELT,DATAVIEW,ORDERS(T1),$INTERNALGENERATED CARD ==> 13 AFTER,$LASTGENERATED CARD ==> 111 ADD ORDER-ENTRYGENERATED CARD ==> 113 ADD ORDERS-ELEMENTGENERATED CARD ==> 6 OFULE ORDERS ORDERSGENERATED CARD ==> 61 ADD ORD-IDGENERATED CARD ==> 611 ORD-ORD-ID ORDIDGENERATED CARD ==> 61 ADD CUST-IDGENERATED CARD ==> 611 ORD-CUST-ID CUSTIDGENERATED CARD ==> 61 ADD IND-CDGENERATED CARD ==> 611 ORD-IND-CD INDCDGENERATED CARD ==> 61 ADD CUST-NOGENERATED CARD ==> 611 ORD-CUST-NO CUSTNOGENERATED CARD ==> 61 ADD ORD-DTGENERATED CARD ==> 611 ORD-ORD-DT ORDDTGENERATED CARD ==> 61 ADD ORD-YRGENERATED CARD ==> 611 ORD-ORD-YR ORDYRGENERATED CARD ==> 61 ADD ORD-MOGENERATED CARD ==> 611 ORD-ORD-MO ORDMOGENERATED CARD ==> 61 ADD ORD-DAYGENERATED CARD ==> 611 ORD-ORD-DAY ORDDAYGENERATED CARD ==> 61 ADD EXP-DTGENERATED CARD ==> 611 ORD-EXP-DT EXPDTGENERATED CARD ==> 61 ADD EXP-YRGENERATED CARD ==> 611 ORD-EXP-YR EXPYRGENERATED CARD ==> 61 ADD EXP-MOGENERATED CARD ==> 611 ORD-EXP-MO EXPMOGENERATED CARD ==> 61 ADD EXP-DAYGENERATED CARD ==> 611 ORD-EXP-DAY EXPDAYGENERATED CARD ==> 61 ADD DISC-PCTGENERATED CARD ==> 611 ORD-DISC-PCT DISCPCTGENERATED CARD ==> 61 ADD STATGENERATED CARD ==> 611 ORD-STAT STATGENERATED CARD ==> 61 ADD SHIP-DTGENERATED CARD ==> 611 ORD-SHIP-DT SHIPDTGENERATED CARD ==> 61 ADD SHIP-YRGENERATED CARD ==> 611 ORD-SHIP-YR SHIPYRGENERATED CARD ==> 61 ADD SHIP-MOGENERATED CARD ==> 611 ORD-SHIP-MO SHIPMO





GENERATED CARD ==> 61 ADD SHIP-DAYGENERATED CARD ==> 611 ORD-SHIP-DAY SHIPDAYGENERATED CARD ==> 61 ADD TERMSGENERATED CARD ==> 611 ORD-TERMS TERMSGENERATED CARD ==> 61 ADD INSTRGENERATED CARD ==> 611 ORD-INSTR INSTRGENERATED CARD ==> 61 ADD CUST-POGENERATED CARD ==> 611 ORD-CUST-PO CUSTPOGENERATED CARD ==> 61 ADD SHIP-IDGENERATED CARD ==> 611 ORD-SHIP-ID SHIPIDGENERATED CARD ==> 61 ADD ORDER-TOTALGENERATED CARD ==> 611 ORD-ORDER-TOTAL ORDTOTGENERATED CARD ==> 61 ADD FRT-AMTGENERATED CARD ==> 611 ORD-FRT-AMT FRTAMTGENERATED CARD ==> 61 ADD SLMN-IDGENERATED CARD ==> 611 ORD-SLMN-ID SLMNIDGENERATED CARD ==> 61 ADD ACT-DTGENERATED CARD ==> 611 ORD-ACT-DT ACTDTGENERATED CARD ==> 61 ADD ACT-YRGENERATED CARD ==> 611 ORD-ACT-YR ACTRYGENERATED CARD ==> 61 ADD ACT-MOGENERATED CARD ==> 611 ORD-ACT-MO ACTMOGENERATED CARD ==> 61 ADD ACT-DAYGENERATED CARD ==> 611 ORD-ACT-DAY ACTDAYGENERATED CARD ==> 61 ADD ORD-AMTGENERATED CARD ==> 611 ORD-ORD-AMT ORDAMTGENERATED CARD ==> -END-END 22- END OF FILE ENCOUNTERED READING SYSIN - PROCESSING TERMINATED



Sample Output - DDBTGLM - for DATAVIEW Structure

The following is an example of the output where a dataview is the entity-type:

-BTG DATAVIEW,ORDERS(T1) 11 'DEMO ADMIN ', - 'DEMO ADMIN ' 719 OEORDER OE-ORDER Y -END -BTG ELEMENT,ORDERS. - ORDERS(T1) 11 'DEMO ADMIN ', - 'DEMO ADMIN ' 12 'ORDERS FULL TABLE ELEMENT ' 13 RELT,DATAVIEW,ORDERS(T1),$INTERNAL 13 AFTER,$LAST 111 ADD ORDER-ENTRY 113 ADD ORDERS-ELEMENT 6 OFULE ORDERS ORDERS 61 ADD ORD-ID 611 ORD-ORD-ID ORDID 61 ADD CUST-ID 611 ORD-CUST-ID CUSTID 61 ADD IND-CD 611 ORD-IND-CD INDCD 61 ADD CUST-NO 611 ORD-CUST-NO CUSTNO 61 ADD ORD-DT 611 ORD-ORD-DT ORDDT 61 ADD ORD-YR 611 ORD-ORD-YR ORDYR 61 ADD ORD-MO 611 ORD-ORD-MO ORDMO 61 ADD ORD-DAY 611 ORD-ORD-DAY ORDDAY 61 ADD EXP-DT 611 ORD-EXP-DT EXPDT 61 ADD EXP-YR 611 ORD-EXP-YR EXPYR 61 ADD EXP-MO 611 ORD-EXP-MO EXPMO 61 ADD EXP-DAY 611 ORD-EXP-DAY EXPDAY 61 ADD DISC-PCT 611 ORD-DISC-PCT DISCPCT 61 ADD STAT 611 ORD-STAT STAT 61 ADD SHIP-DT 611 ORD-SHIP-DT SHIPDT 61 ADD SHIP-YR 611 ORD-SHIP-YR SHIPYR 61 ADD SHIP-MO 611 ORD-SHIP-MO SHIPMO 61 ADD SHIP-DAY 611 ORD-SHIP-DAY SHIPDAY 61 ADD TERMS 611 ORD-TERMS TERMS 61 ADD INSTR



611 ORD-INSTR INSTR 61 ADD CUST-PO 611 ORD-CUST-PO CUSTPO 61 ADD SHIP-ID 611 ORD-SHIP-ID SHIPID 61 ADD ORDER-TOTAL 611 ORD-ORDER-TOTAL ORDTOT 61 ADD FRT-AMT 611 ORD-FRT-AMT FRTAMT 61 ADD SLMN-ID 611 ORD-SLMN-ID SLMNID 61 ADD ACT-DT 611 ORD-ACT-DT ACTDT 61 ADD ACT-YR 611 ORD-ACT-YR ACTRY 61 ADD ACT-MO 611 ORD-ACT-MO ACTMO 61 ADD ACT-DAY 611 ORD-ACT-DAY ACTDAY 61 ADD ORD-AMT 611 ORD-ORD-AMT ORDAMT -END


Chapter 3. DDCFBLD - CatalogingDatadictionary Definitions


When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79-CXX BUILD - Building the Entity-Occurrence Definitions . . . . . . . . . . . 80Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . . 82

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Sample Report - DDCFBLD (-CXX BUILD) . . . . . . . . . . . . . . . . 84

-CXX CATALOG - Cataloging the Definitions to the Directory . . . . . . . . 87Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . . 89

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Sample Report - DDCFBLD (-CXX CATALOG) . . . . . . . . . . . . . . 91

-HSD RESET - Resetting the HSD Table . . . . . . . . . . . . . . . . . . . . 95Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . . 96

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Sample Report - DDCFBLD (-HSD RESET) . . . . . . . . . . . . . . . . 97

You can use the DDCFBLD (Datadictionary Control File Build) Utility to performthe following functions. When these functions are executed, the DatadictionaryVERIFY function is also executed and any resulting error messages are issued.For more information, see “1000 VERIFY Transaction” on page 271.

-CXX BUILDBuilds the batch transactions necessary to post Datadictionary definitionsto the Directory using DBUTLTY.

-CXX CATALOGCatalogs the Datadictionary definitions directly to the Directory (CXX).

Catalogs definitions of databases with tables that are SQL-accessible tothe DDD database.

-HSD RESETPerforms a RESET of the Datadictionary High-Speed Directory (HSD) asa separate function, or automatically as the -CXX BUILD executes againstthe DATA-DICT database.

Chapter 3. DDCFBLD - Cataloging Datadictionary Definitions 77

When to Use

When to Use

When it is necessary to update either the CA Datacom/DB Directory (CXX), theDatadictionary High-Speed Directory (HSD), or the DDD with definitionsmaintained in Datadictionary, use the DDCFBLD utility to format the occurrencedefinitions for input to the Directory (CXX). You can also use the 1000CATALOG transaction with DDUPDATE or the CATALOG DATABASEcommand online to update the CXX and the DDD.

Note: For CA Datacom/DB Accounting tables, use the ACCT function ofDBUTLTY. For more information, see the CA Datacom/DB DBUTLTYReference Guide.

The BUILD function is valid for only the DATA-DICT and DDD-DATABASEstructures and must be used for these definitions. All other database definitionsmust use the CATALOG function.

When changes made to the DATA-DICT database do not require a recatalog ofthe definition in the Directory, you can submit this utility with the -HSD RESETtransaction. Some examples are when you add, delete, or change thedefinitions of a relationship.

If you find that the DDD-SYNC attribute-value of an SQL table is N (no),recatalog the definitions using the CATALOG function.

Before running the -CXX BUILD or -CXX CATALOG transactions, back up theCA Datacom/DB Directory (CXX).

After running the -CXX BUILD transaction, complete the process of posting thedefinitions to the Directory by running the DDPROD option of the CXXMAINTfunction in DBUTLTY.

Note: The CATALOG function is not valid in the version of Datadictionarysupplied with CA Datacom/AD. However, the -CXX BUILD transaction is validfor the databases named DATA-DICT and DDD-DATABASE. For information,see the documentation for the CA application product using CA Datacom/AD.


How to Use

How to Use

DDCFBLD has three transactions -CXX BUILD, -CXX CATALOG, and -HSDRESET. These transactions are discussed in the following sections.


-CXX BUILD - Building the Entity-Occurrence Definitions


Use the -CXX BUILD transaction to build the occurrence definitions of theDATA-DICT and DDD-DATABASE structures for input to the Directory (CXX).All other database structures must use the CATALOG function of DDCFBLD,DDUPDATE, or DDOL. To place these definitions in the Directory, you mustexecute the DBUTLTY CXXMAINT OPTION=DDPROD function. For moreinformation about the CXXMAINT OPTION=DDPROD function, see the CADatacom/DB DBUTLTY Reference Guide.

This transaction:

■ Verifies the database structure

■ Creates a sequential file for input to the DDPROD option of the CXXMAINTfunction in DBUTLTY

When using -CXX BUILD, the SQL accessible tables are posted to the DDDtable. These are the ONLY exceptions to the rule about cataloging SQL tables.If -CXX BUILD is used only for the purpose of populating the DDD table withdefinitions of the SQL accessible tables in databases, the CXXMAINT DDPRODoption is not necessary. Also note that using the -CXX BUILD on databaseDATA-DICT also performs the -HSD RESET function.

Use the following format for the -CXX BUILD transaction:

��──-CXX──BUILD──,DATABASE─ ──,occ-name(stat ──┬ ┬──────────── ) ──────────�� ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────

,DATABASE(Required) Indicates that the occurrence is a DATABASE occurrence.

,occ-name(Required) Specify the DATABASE occurrence name. When theoccurrence name is DATA-DICT, the DDCFBLD utility also updates theDatadictionary High-Speed Directory (HSD).

Valid Entries: DATA-DICT or DDD-DATABASE


(stat)(Required) Specifies the status of the occurrence used as input to theDDCFBLD execution.

Valid Entries: T001 to T999PROD




,pswd(Optional) Enter the password for the DATABASE occurrence within theparentheses surrounding the stat parameter. If the occurrence is notprotected by a password and you must enter an override code, enter thepreceding comma.

Valid Entries: Password assigned to the occurrence


,ovrd(Optional) Enter the system override code within the parenthesessurrounding the stat parameter if you are selecting an occurrence which isprotected from unauthorized update or access by a lock level. If theoccurrence is not protected by a lock level, you can omit the overridecode and its preceding comma.




Sample Job Streams and Report



z/OS Example JCL

The following sample JCL builds the occurrence definitions for input to the CADatacom/DB Directory (CXX).


//jobname See the note above and page 19. // EXEC PGM=DDCFBLD,REGION=248K //STEPLIB See the note above and page 19. //DDCFBLD DD DSN=dd.output,DISP=(NEW,PASS), BUILD function output to // UNIT=SYSDA,SPACE=(CYL,(5,5),RLSE) CA Datacom/DB DBUTLTY //SYSPRINT DD SYSOUT= Print output //SYSPUNCH DD SYSOUT= Punch output //SYSUDUMP DD SYSOUT= System dumps//SNAPER DD SYSOUT= CA Datacom/DB dumps //SYSIN DD Input transactions -USR SAMPLE-USER Authorized user information -COM -COM THE FOLLOWING STATEMENT INVOKES THE BUILD FUNCTION -COM -CXX BUILD,DATABASE,occ-name(PROD) /

For more information about the CXXMAINT OPTION=DDPROD function, seethe CA Datacom/DB DBUTLTY Reference Guide.



z/VSE Example JCL

The following sample JCL builds the occurrence definitions for input to the CADatacom/DB Directory (CXX).


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYSnnn,device-type,VOL=volser,SHR // DLBL ddcfbld,'ddcfbld.output.trans' BUILD function output to // EXTENT CA Datacom/DB DBUTLTY The above statements are required. If the BUILD function is performed this data set will be open and closed, insuring incorrect data from the last BUILD function is not used to update the directory. // EXEC DDCFBLD,SIZE=6K -USR SAMPLE-USER Authorized user information -COM -COM THE FOLLOWING STATEMENT INVOKES THE BUILD FUNCTION -COM -CXX BUILD,DATABASE,occ-name(PROD) / /& $$ EOJ

For more information about the CXXMAINT OPTION=DDPROD function, seethe CA Datacom/DB DBUTLTY Reference Guide.



Sample Report - DDCFBLD (-CXX BUILD)





-USR DATACOM-INSTALL,,2 �A� ; PROC �B� -----------------------------------------------------------------------------------




----------------------------------------------------------------------------------- CODE FUNCTION,ENTITY-TYPE,OCCURRENCE(VERS,PSWD,OVRD) -CXX BUILD,DATABASE,DDD-DATABASE(PROD,,) �C� ; -----------------------------------------------------------------------------------

FUNCTION = BUILD-STRUCTURE ENTITY-TYPE = DATABASE OCCURRENCE = DDD-DATABASE �D� VERSION = PROD

Maintenance Information

�A� The information that can be entered for this transaction followed by thetransaction as entered: a -USR transaction.

�B� The PROC code indicating the transaction is syntactically correct.

�C� The information that can be entered for this transaction followed by thetransaction as entered: a -CXX BUILD transaction.

�D� A summary of the transaction keywords entered and expected.




Security Level: 1 Indented Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ENTITY-TYPE................... OCCURRENCE....................................................... S VERS DATACOM/DB

DESCRIPTION................................... NAME ID USE SQLNAME............................................

�E� �F� �H� �I� �J� �L�

BAS DDD-DATABASE P 1 15DATA DEFINITION DIRECTORY �── �G�

ARA DATACOM-SIT P 1 SITDATACOM SCHEMA AREA

TBL SYSAUTHOBJ P 1 AOB 3SQL SYSTEM AUTH OBJECT

SYSADM.SYSAUTHOBJ �── �M� I AKEY SYSAUTHOBJ.DBID-KEY P 1 AOBK2 5

SYSADM.AOBK2_15 FLD SYSAUTHOBJ.AUTHOBJ2 P 1 SYSADM.AUTHOBJ2

KEY SYSAUTHOBJ.TABLE-KEY P 1 AOBKY 6 M N SYSADM.AOBKY_15 FLD SYSAUTHOBJ.AUTHOBJ P 1 SYSADM.AUTHOBJ

ELM SYSAUTHOBJ.TABLE P 1 AOBRWTBL SYSCOLAUTH P 1 ACL 4

SQL COLUMN AUTHORIZATIONS SYSADM.SYSCOLAUTH I A

KEY SYSCOLAUTH.GRANTEE-KEY P 1 ACLK2 7 SYSADM.ACLK2_15 FLD SYSCOLAUTH.GRANTEE P 1 SYSADM.GRANTEE FLD SYSCOLAUTH.TABAUTHID P 1 SYSADM.TABAUTHID FLD SYSCOLAUTH.TNAME P 1 SYSADM.TNAME FLD SYSCOLAUTH.COLNAME P 1 SYSADM.COLNAME

KEY SYSCOLAUTH.GRANTOR-KEY P 1 ACLK3 8 SYSADM.ACLK3_15 FLD SYSCOLAUTH.GRANTOR P 1 SYSADM.GRANTOR

Report of the CA Datacom/DB structure built

�E� CA Datacom/DB entity-type name

�F� Datadictionary occurrence name

�G� Datadictionary occurrence description

�H� Occurrence status

�I� Occurrence version

�J� DATACOM-NAME of the area, table, key or element

�L� DATACOM-ID of the database, table or key

�M� SQL name of the entity-occurrence






DESCRIPTION................................... NAME ID USE SQLNAME............................................ �N�

TBL SQL_STATUS_CURR P 1 SCA 21 SYSADM.SQL_STATUS_CURRENT_ACTIVITY I A

KEY SQL_STATUS_CURR.SQ29 P 1 SQ29 29 M N SYSADM.SQ29_15 FLD SQL_STATUS_CURR.RUN_UNIT P 1 SYSADM.RUN_UNIT

ELM SQL_STATUS_CURR.SQLEL P 1 SQLELTBL SQL_STATUS_PLAN P 2 SSP 22

SYSADM.SQL_STATUS_PLAN I AKEY SQL_STATUS_PLAN.SQ26 P 2 SQ26 26 M N

SYSADM.SQ26_15 FLD SQL_STATUS_PLAN.REQ_STAMP P 2 SYSADM.REQ_STAMP

ELM SQL_STATUS_PLAN.SQLEL P 2 SQLELTBL SQL_STATUS_URT P 2 SSU 23

SYSADM.SQL_STATUS_URT I AKEY SQL_STATUS_URT.SQ28 P 2 SQ28 28 M N

SYSADM.SQ28_15 FLD SQL_STATUS_URT.RUN_UNIT P 2 SYSADM.RUN_UNIT

ELM SQL_STATUS_URT.SQLEL P 2 SQLEL ----------------------------------------------------------------------------------- SUCCESSFUL BUILD-STRUCTURE -----------------------------------------------------------------------------------

�O�




----------------------------------------------------------------------------------- END OF JOB �P�

-----------------------------------------------------------------------------------

�N� For keys, in the USE column:

■ M indicates that the key is a Master Key, blank indicates that it is not.■ N indicates that the key is a Native Key, blank indicates that it is not.

For tables, in the USE column:

■ I indicates that the SQL-INTENT attribute-value is Y (yes) or R (SQLread-only), blank indicates it is N (no).

■ A indicates that the SQL-ACCESS attribute-value is Y (yes) or R (SQLread-only), blank indicates it is N (no).

�O� A message indicating that the BUILD completed successfully.

�P� A message indicating that the job has ended.


-CXX CATALOG - Cataloging the Definitions to the Directory


Use the -CXX CATALOG transaction to verify the database structure andcatalog the occurrence definitions to the CA Datacom/DB Directory (CXX). Youcan catalog TEST and PRODuction status DATABASE structures.

Note: If you are only updating specific attributes of a DATABASE or AREAoccurrence, you may be able to make these changes using the 1000 ALTERtransaction in DDUPDATE.

The -CXX CATALOG transaction should be used to process all databasesexcept the DATA-DICT and Data Definition Directory databases. You must usethis transaction if the database contains any tables accessed by SQL since thecatalog process places SQL related information in the DDD database. TheDATA-DICT and DDD databases must be processed with the -CXX BUILDtransaction (see “-CXX BUILD - Building the Entity-Occurrence Definitions” onpage 80).

For the CA Datacom/DB Accounting database, use the DBUTLTY ACCTOPTION. For more information, see the CA Datacom/DB DBUTLTY ReferenceGuide.


The following is the format for -CXX CATALOG transaction:

��──-CXX──CATALOG──,DATABASE─ ──,occ-name.(stat ──┬ ┬──────────── ) ───────�� ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────


,occ-name(Required) Specifies a valid DATABASE occurrence name.

Valid Entries: Any valid DATABASE occurrence name


(stat)(Required) Specifies the status of the occurrence used as input to theDDCFBLD execution.





,pswd(Optional) Enter the user-assigned password for the DATABASEoccurrence within the parentheses surrounding the stat parameter. If theoccurrence is not protected by a password and you must enter anoverride code, enter the preceding comma.









z/OS Example JCL

The following sample JCL posts the DATABASE structure definition to the CADatacom/DB Directory (CXX).


//jobname See the note above and page 19. // EXEC PGM=DDCFBLD,REGION=6K //STEPLIB See the note above and page 19. //DDCFBLD DD DSN=dd.output,DISP=... BUILD function output to // CA Datacom/DB DBUTLTY //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR SAMPLE-USER Authorized user informati on -COM -COM THE FOLLOWING STATEMENT INVOKES THE CATALOG FUNCTION -COM -CXX CATALOG,DATABASE,ORDER-ENTRY(PROD) /



z/VSE Example JCL



$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYSnnn,device-type,VOL=volser,SHR // DLBL ddcfbld,'ddcfbld.output.trans' BUILD function output to // EXTENT CA Datacom/DB DBUTLTY The above statements are required. If the CATALOG function is performed this data set will be open and closed, insuring incorrect data from the last BUILD function is not used to update the directory. // EXEC DDCFBLD,SIZE=6K -USR SAMPLE-USER Authorized user information -COM -COM THE FOLLOWING STATEMENT INVOKES THE CATALOG FUNCTION -COM -CXX CATALOG,DATABASE,ORDER-ENTRY(PROD) / /& $$ EOJ



Sample Report - DDCFBLD (-CXX CATALOG)





-USR SAMPLE-USER, �A� ; PROC �B� -----------------------------------------------------------------------------------


�A� The information that can be entered for this transaction followed by thetransaction as entered: a -USR transaction.




User: SAMPLE-USER DD Base: 2 ----------------------------------------------------------------------------------- CODE FUNCTION,ENTITY-TYPE,OCCURRENCE(VERS,PSWD,OVRD) -CXX CATALOG,DATABASE,ORDER-ENTRY(PROD) �C� ; -----------------------------------------------------------------------------------

FUNCTION = CATALOG-STRUCTURE ENTITY-TYPE = DATABASE OCCURRENCE = ORDER-ENTRY �D� VERSION = PROD


�C� The information that can be entered for this transaction followed by thetransaction as entered: a -CXX CATALOG transaction.

�D� A summary of the transaction keywords entered and expected.







�E� �F� �H� �I� �J� �L�

BAS ORDER-ENTRY P 3 1ORDER-ENTRY DEMO DATABASE �── �G�

ARA ACCTS P 3 ACTORDER-ENTRY ACCTS AREA

ACCTS_AREA �── �M�TBL ACCTS P 3 ACT 6

ORDER-ENTRY ACCTS TABLEKEY ACCTS.CUST-ID-KEY P 3 ACSTI 1

CUST-ID SECONDARY KEY FLD ACCTS.CUST-ID P 3

ACCTS CUST-ID FIELD CUST_ID FLD ACCTS.IND-CD P 3

ACCTS IND-CD FIELD IND_CD FLD ACCTS.CUST-NO P 3

ACCTS CUST-NO FIELD CUST_NO

KEY ACCTS.ORD-ID-KEY P 3 ACTOR 4 M NORD-ID MASTER KEY

FLD ACCTS.ORD-ID P 3ACCTS ORD-ID FIELD

ORD_IDELM ACCTS.ACCTS P 3 ACTFL

ACCTS FULL TABLE ELEMENTELM ACCTS.CUST-ID P 3 ACTCS

CUST-ID ELEMENTELM ACCTS.ORD-ID P 3 ACTOR

ORD-ID ELEMENTARA CUST P 3 CUS

ORDER-ENTRY CUST AREA CUSTOMERS_AREA

TBL CUST P 3 CUS 1ORDER-ENTRY CUST TABLE

SYSADM.CUSTOMERS I A

The report of the database structure cataloged.

�E� CA Datacom/DB entity-type name

�F� Occurrence name

�G� Occurrence description

�H� Occurrence status

�I� Occurrence version

�J� DATACOM-NAME of the area, table, key or element

�L� DATACOM-ID of the database, table or key

�M� SQL name of the entity-occurrence







ELM SHIPTO.SHIP-TO P 3 SHPTO �N�SHIP-TO FULL TABLE ELEMENT

ARA SLSHST P 3 SALORDER-ENTRY SALES-HIST AREA

SALES_HIST_AREATBL SLSHST P 3 SAL 7

ORDER-ENTRY SALES-HIST TABLE SYSADM.SALES_HIST I A

KEY SLSHST.CUST-ID-KEY P 3 SHCUS 1CUST-ID SECONDARY KEY

FLD SLSHST.CUST-ID P 3 SYSADM.CUST_ID FLD SLSHST.IND-CD P 3 SYSADM.IND_CD FLD SLSHST.CUST-NO P 3 SYSADM.CUST_NO

KEY SLSHST.ITMID-ORDID-KEY P 3 SHIDS 7 M NITMID AND ORDID MASTER KEY

FLD SLSHST.ITM-ID P 3 SYSADM.ITM_ID FLD SLSHST.ORD-ID P 3 SYSADM.ORD_ID

ELM SLSHST.CUSTID-ORDDT P 3 SLSCOCUST-ID ORDDATE ELEMENT

ELM SLSHST.ITEM-ID P 3 SLSIT ITEM-ID

ELM SLSHST.ORD-ID P 3 SLSOR ORD-ID ELEMENT

ELM SLSHST.ORDID-HIST P 3 SLSOHORD-ID THRU DISC-PCT ELEMENT

ELM SLSHST.SALES-HIST P 3 SLSFLSALES-HIST FULL TABLE ELEMENT

----------------------------------------------------------------------------------- SUCCESSFUL CATALOG �O� -----------------------------------------------------------------------------------




----------------------------------------------------------------------------------- END OF JOB �P�

-----------------------------------------------------------------------------------



�N� For keys, in the USE column:

■ M indicates that the key is a Master Key, blank indicates that it is not.■ N indicates that the key is a Native Key, blank indicates that it is not.

For tables, in the USE column:

■ I indicates that SQL-INTENT attribute-value is Y (yes) or R (SQLread-only), blank indicates it is N (no).

■ A indicates that SQL-ACCESS attribute-value is Y (yes) or R (SQLread-only), blank indicates it is N (no).

�O� A message indicating that the CATALOG completed successfully.

�P� A message indicating that the job has ended.


-HSD RESET - Resetting the HSD Table

-HSD RESET - Resetting the HSD Table

The High-Speed Directory (HSD) Table resides in the DATA-DICT database.Within the HSD are Data Group Tables (DGT) which contain information abouteach of the entity-types in Datadictionary. In a multiple Datadictionaryenvironment, each Datadictionary has its own HSD. To update the HSD Table,execute the DDCFBLD utility using the -HSD RESET transaction.

Note: The HSD Table is automatically updated by the DDCFBLD utility whenthe BUILD transaction is executed against the DATA-DICT database.

Use the -HSD RESET transaction to refresh or restore the HSD Table whenyou make changes to the DATA-DICT database that do not require recatalogingthe definition in the Directory (CXX). For example, update the HSD Table whenyou add, delete or change the definitions of a relationship.

Note: Since the Batch Transaction Generator and the Record MigrationFacility place work records in the HSD, it is possible you could receive aBDM007 return code indicating that the HSD is full when running either of thoseutilities. Try initializing and null loading the HSD using the INIT function ofDBUTLTY, then resetting the HSD. If processing either BTG or RMF continuesto fill the HSD, try allocating more space for the HSD area.

The following is the format for the -HSD RESET transaction:

��──-HSD──RESET───────────────────────────────────────────────────────��





z/OS Example JCL

The following sample JCL refreshes the HSD table.


//jobname See the note above and page 19. // EXEC PGM=DDCFBLD,REGION=6K //STEPLIB See the note above and page 19. //DDCFBLD DD DSN=dd.output,DISP=... BUILD function output to // CA Datacom/DB DBUTLTY //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR SAMPLE-USER Authorized user information -COM -COM THE FOLLOWING STATEMENT INVOKES THE RESET FUNCTION -COM -HSD RESET /



z/VSE Example JCL

The following sample JCL refreshes the HSD table.


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYSnnn,device-type,VOL=volser,SHR // DLBL ddcfbld,'ddcfbld.output.trans' BUILD function output to // EXTENT CA Datacom/DB DBUTLTY The above statements are required. If the CATALOG function is performed this data set will be open and closed, insuring incorrect data from the last BUILD function is not used to update the directory. The statements shown are skeletal. Code these statements according to your installation standards. // EXEC DDCFBLD,SIZE=6K -USR SAMPLE-USER Authorized user information -COM -COM THE FOLLOWING STATEMENT INVOKES THE RESET FUNCTION -COM -HSD RESET / /& $$ EOJ

Sample Report - DDCFBLD (-HSD RESET)





-USR SAMPLE-USER, �A� ; PROC �B� -----------------------------------------------------------------------------------

�A� The information that can be entered for this transaction followed by thetransaction entered: a -USR transaction. (The asterisks replace the userpassword.)







----------------------------------------------------------------------------------- CODE FUNCTION -HSD RESET �C� ; -----------------------------------------------------------------------------------

FUNCTION = DEFINE SRF �D�

FUNCTION = DEFINE DGT NAME = AGGREGATE

FUNCTION = DEFINE DGT NAME = ALIAS

FUNCTION = DEFINE DGT NAME = AREA

FUNCTION = DEFINE DGT NAME = AUTHORIZATION

FUNCTION = DEFINE DGT NAME = CONSTRAINT

FUNCTION = DEFINE DGT NAME = DATABASE

FUNCTION = DEFINE DGT NAME = DATAVIEW

FUNCTION = DEFINE DGT NAME = DD-HSD-FILE

FUNCTION = DEFINE DGT NAME = DESCRIPTOR

FUNCTION = DEFINE DGT NAME = ELEMENT

FUNCTION = DEFINE DGT NAME = FIELD

FUNCTION = DEFINE DGT NAME = FILE

FUNCTION = DEFINE DGT NAME = FUNCTION

FUNCTION = DEFINE DGT NAME = JOB

FUNCTION = DEFINE DGT NAME = KEY

FUNCTION = DEFINE DGT NAME = LIBRARY

FUNCTION = DEFINE DGT NAME = MEMBER

�C� The transaction specifying the operation performed. A report illustratingresetting the -HSD.

�D� A report of the Data Group Tables (DGT) defined in the High-SpeedDirectory (HSD) by the RESET.






FUNCTION = DEFINE DGT NAME = MODULE

FUNCTION = DEFINE DGT NAME = NODE

FUNCTION = DEFINE DGT NAME = PANEL

FUNCTION = DEFINE DGT NAME = PARTITION-COLUMN-VALUE

FUNCTION = DEFINE DGT NAME = PARTITION-VALUE

FUNCTION = DEFINE DGT NAME = PERSON

FUNCTION = DEFINE DGT NAME = PLAN

FUNCTION = DEFINE DGT NAME = PROCEDURE

FUNCTION = DEFINE DGT NAME = PROGRAM

FUNCTION = DEFINE DGT NAME = RECORD

FUNCTION = DEFINE DGT NAME = RELATIONSHIP

FUNCTION = DEFINE DGT NAME = REPORT

FUNCTION = DEFINE DGT NAME = STATEMENT

FUNCTION = DEFINE DGT NAME = STEP

FUNCTION = DEFINE DGT NAME = SYNONYM

FUNCTION = DEFINE DGT NAME = SYSTEM

FUNCTION = DEFINE DGT NAME = TABLE

FUNCTION = DEFINE DGT NAME = TEXT

FUNCTION = DEFINE DGT NAME = TRIGGER

FUNCTION = DEFINE DGT NAME = VIEW

FUNCTION = DEFINE TRANSACTIONS

FUNCTION = CATALOG PROFILE NAME = ALL






FUNCTION = VERIFY-STRUCTURE ENTITY-TYPE = DATABASE OCCURRENCE = DATA-DICT VERSION = PROD

----------------------------------------------------------------------------------- SUCCESSFUL HSD RESET

-----------------------------------------------------------------------------------




----------------------------------------------------------------------------------- END OF JOB

-----------------------------------------------------------------------------------


Chapter 4. DDICF - Generating InputTransactions


When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103CA FILE Model Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104CA Datacom/DB TABLE Substructure . . . . . . . . . . . . . . . . . . . . . 105Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106-UTL LIBRARY - Invoking DDICF . . . . . . . . . . . . . . . . . . . . . . . 107-UTL LANGUAGE - Specifying the Input Language . . . . . . . . . . . . . 108-UTL AREA - Specifying Area and Table Information . . . . . . . . . . . . 109-UTL ICF - Specifying the Copybook Member . . . . . . . . . . . . . . . . 110Sample Job Streams and Output . . . . . . . . . . . . . . . . . . . . . . . . 112

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Sample Report - DDICF - for a Table . . . . . . . . . . . . . . . . . . . 115Sample Output - DDICF - for a Table . . . . . . . . . . . . . . . . . . . 116Sample Report - DDICF - for a File . . . . . . . . . . . . . . . . . . . . 119Sample Output - DDICF - for a File . . . . . . . . . . . . . . . . . . . . 121

The Datadictionary Input Creation Facility can use COBOL source languagecopybook statements to create most of the DDUPDATE transactions that youneed to add TABLE substructures or FILE structures to the Datadictionary.

Chapter 4. DDICF - Generating Input Transactions 101

When to Use

When to Use

Use this facility to create table or file and record transactions, field transactions,and element transactions from source language statements to populate yourDatadictionary.

Note: DDICF does not support numeric literals for the parent of 88-level fields.These fields are limited to 20-byte character data.

The following can occur when using DDICF utility:

■ A set of file and record transactions or a set of table transactions is createdbased on the parameters coded in the DDICF transactions. See thefollowing sections for more information and considerations.

■ Group (-GRP), 4010, and 4012 transactions are generated for FIELDoccurrences encountered in the copybook. You can add the other desiredFIELD transactions.

■ The 6010 and 6011 transactions to define all the fields in the copybook toone ELEMENT occurrence are generated. You MUST add the 6000transaction.

■ The DDICF utility does not generate transactions for a KEY occurrence.You must add those transactions.

■ A report is produced that lists the transactions created.

Datadictionary error messages are produced for any transaction syntaxerrors.


How to Use

How to Use

There are four transactions used in the job stream of the DDICF. The -UTLICF transaction must be the last of these transactions that you enter.

■ -UTL LIBRARY transaction identifies the source library.

■ -UTL LANGUAGE transaction indicates the language of the input and thelength of the occurrence names.

■ -UTL AREA transaction indicates the associated AREA occurrence nameand the DATACOM-NAME attribute-value of the table.

■ -UTL ICF transaction indicates the input name of the copybook member andthe occurrence names for the transaction output generated by the utility.


CA FILE Model Structure

CA FILE Model Structure

To create a FILE structure, execute the DDICF utility without the -UTL AREAtransaction. A FILE and RECORD occurrence will be generated. Defaultstaken on the 3120 FILE transaction (see “3120 FILE Transaction” on page 317)are:

DBMS-USED = NONEBLOCK-SIZE = 4096RECORD-FORMAT = UNDF

If you desire different values for these attributes, you can modify the output ofDDICF before it is input into DDUPDATE. The -GRP START generated willreference a record.


CA Datacom/DB TABLE Substructure

CA Datacom/DB TABLE Substructure

To create a TABLE substructure, use a -UTL AREA transaction. It specifies theDATACOM-NAME attribute-value for the 3150 TABLE transaction (see “3150TABLE Transaction” on page 322) and the AREA occurrence name for the1000 CONNECT transaction to the existing AREA substructure. The generated-GRP START transaction references a table.




If any tables resulting from using the DDICF are to be accessed by SQL, youmust modify the SQL-INTENT attribute of each table through Datadictionaryonline or batch transaction 3152 (see 326), copy the tables to PRODuctionstatus and catalog them to the Directory before SQL can access the tables. Ifyou modify the SQL-INTENT attribute and the verification for SQL accessibilityis not successful during the catalog attempt, the table cannot be accessed bySQL. For more information about SQL, see the CA Datacom/DB SQL UserGuide.


-UTL LIBRARY - Invoking DDICF

-UTL LIBRARY - Invoking DDICF

Use the following transaction to invoke DDICF and identify the source library.Only 80-byte records are supported as input to DDICF from any source.

-UTL LIBRARY Transaction to Invoke DDICF

��──-UTL─ ──LIBRARY,library-id ─────────────────────────────────────────��

,library-id(Required) Identifies the source library.

ID Input is

LIB Directly from CA Librarian

OS Directly from a partition data set

SP From a LIBR PUNCH of one or more members of a source statementlibrary

Valid Entries: LIBOSSP



-UTL LANGUAGE - Specifying the Input Language

-UTL LANGUAGE - Specifying the Input Language

Use the following transaction to specify the language of the input and the lengthof the occurrence names.

��──-UTL─ ──LANGUAGE,language ──┬ ┬───────── ─────────────────────────────�� └ ┘ ─,LEN=nn─

,language(Required) Specify the language.

Valid Entries: COBOLCOBOL2COBOL85 (Fujitsu machine)


,LEN=(Optional) Specify the maximum length of the occurrence names from theinput copybook in the generated transactions. If the occurrence name islonger, it will be truncated to the specified length.

Note: Occurrence names from the -UTL AREA and -UTL ICFtransactions are taken as is and not truncated.


Default Value: 15


-UTL AREA - Specifying Area and Table Information

-UTL AREA - Specifying Area and Table Information

Use the following optional transaction to indicate that the output should begenerated in the form for a CA Datacom/DB TABLE occurrence.

��──-UTL─ ──AREA ──┬ ┬──────────── ──┬ ┬─────────────── ────────────────────�� └ ┘ ─,area-name─ └ ┘ ─,datacom-name─

,area-name(Optional) Identifies the Datadictionary occurrence name for an existingarea to which the table is added. This name is used on the resulting1000 CONNECT transaction that DDUPDATE utility uses to relate thetable to the area. If you do not specify this parameter, a 1000 CONNECTtransaction is not generated.

Valid Entries: 1- to 32-character name


,datacom-name(Optional) Identifies the three-character DATACOM-NAME attribute-valuefor the table which appears on the resulting 3150 TABLE transaction. Ifyou do not specify this parameter, the 3150 transaction will not contain avalue.

Valid Entries: 3 characters where the first character is alphabetic



-UTL ICF - Specifying the Copybook Member


Use the following transaction to specify the input name of the copybookmember and the occurrence names for the transaction output generated by theutility:

��──-UTL──ICF──,member-name────────────────────────────────────────────�

�─ ──┬ ┬───────────────────────────────────────────────── ───────────────�� └ ┘ ─,─ ──┬ ┬────────────────────────── ──┬ ┬──────────── └ ┘─parent-name.element-name─ ├ ┤─(stat)───── └ ┘─,file-name─

,member-name(Required) The name of the member containing the copybook used forinput to DDICF. If you code the following optional entries, you must placea comma (,) after the member-name entry.

Valid Entries: Existing member name


parent-name.(Optional) The name for the TABLE or RECORD occurrence that isgenerated during processing to qualify the ELEMENT occurrence. Yourentry must be followed by a period (.) to concatenate the TABLE orRECORD occurrence name with the name of the ELEMENT occurrence.

■ If you do not specify a table or record name, the member-name isused.

■ If you specify the name of a RECORD occurrence, you must code thefile-name parameter for this transaction.

■ If you are using these transactions to define a TABLE occurrence,specify the name of the table for this parameter and omit the file-nameparameter.

Valid Entries: 1- to 32-character RECORD or TABLE occurrencename

Default Value: The member-name

element-name(Optional) The name for the ELEMENT occurrence that is generatedduring processing. Your entry must be preceded by the TABLE orRECORD occurrence name followed by a period (.) to concatenate theTABLE or RECORD occurrence name with the ELEMENT occurrence.

Valid Entries: 1- to 32-character ELEMENT occurrence name

Default Value: The member-name



(stat)(Optional) The status/version of the occurrences that are generatedduring processing. Valid only if the file-name is not specified. If thefile-name is specified, this parameter is ignored and T001 is used.

Valid Entries: T001 to T999

Default Value: T001

,file-name(Optional) The name of the FILE occurrence that is generated duringprocessing.

■ If file-name is specified, a RECORD occurrence name must also bespecified in parent-name to create appropriate FILE and RECORDoccurrences.

■ If the same file-name was specified in a previous request, only theRECORD occurrence is created.

■ If parent-name is specified without specifying a file-name, theRECORD occurrence is used to qualify the FIELD and ELEMENToccurrences, but no FILE or RECORD occurrences are created.

■ If you are using this transaction to define a TABLE occurrence, omitthis parameter and the preceding comma.

Valid Entries: 1- to 32-character FILE occurrence name






z/OS Example JCL

The following sample JCL executes DDICF to create DDUPDATE transactionsfrom a COBOL copybook.


//jobname See the note above and page 19. // EXEC PGM=DDICF,REGION=6K //STEPLIB See the note above and page 19. //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps//MASTER DD DSN=libr.master, DISP=... CA Librarian Master File if // CA Librarian member is used // as input //DDICF DD DSN=pdsname,DISP=... OS PDS data set if // PDS member is used as input //SYSIN DD Input transactions -USR SAMPLE-USER,SAMPSWD Authorized user information -UTL LIBRARY,OS -UTL LANGUAGE,COBOL -UTL AREA,CUST,CUS -UTL ICF,CUSCPY,CUST-TBL.CUST-ELM,CUST-TBL /



z/VSE Example JCL

The following are examples of JCL that execute DDICF to create DDUPDATEtransactions from a COBOL copybook. The first example illustrates storing thetransactions in a CA LIBRARIAN Master File, and the second exampleillustrates storing the transactions in a z/VSE library.


CA LIBRARIAN Master File: $$ JOB ... See the note above and page 19. $$ LST ... // JOB name System LIBS and Source Statement information // ASSGN SYS4,device type,VOL=volser,SHR // ASSGN SYSPCH,device type,PERM,VOL=volser,SHR // LIBDEF SL,FROM=library // DLBL MASTER,'work-file-name', CA Librarian Master File // EXTENT SYS4,volser // EXEC DDICF -USR SAMPLE-USER,SAMPSWD Authorized user information -UTL LIBRARY,LIB -UTL LANGUAGE,COBOL -UTL AREA,CUST,CUS -UTL ICF,CUSCPY,CUST-TBL.CUST-ELM,CUST-TBL / /& $$ EOJ



z/VSE Library: $$ JOB ... See the note above and page 19. $$ LST ... // JOB name System LIBS and Source Statement information // DLBL IJSYSPH,'work-file-name', // EXTENT SYSPCH,vol-num,,,work-space // ASSGN SYSPCH,DISK,TEMP,VOL=vol-num,SHR // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // EXEC LIBR ACCESS S=library.sublib PUNCH mem-name1.mem-type PUNCH mem-name2.mem-type PUNCH mem-name3.mem-type . . . / CLOSE SYSPCH,PUNCH // ASSGN SYSnnn,device type,VOL=volser,SHR // DLBL DDICF,'work-file-name', Name of work file if work file // EXTENT SYSnnn,volser used as input // EXEC DDICF -USR SAMPLE-USER,SAMPSWD Authorized user information -UTL LIBRARY,SP -UTL LANGUAGE,COBOL -UTL AREA,CUST,CUS -UTL ICF,CUSCPY,CUST-TBL.CUST-ELM,CUST-TBL / /& $$ EOJ



Sample Report - DDICF - for a Table

The following is an example of a report produced by the sample z/OS jobstream to create DDUPDATE transactions for a table substructure:



Security Level: 1 Utility Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx


-UTL LIBRARY,OS ; -UTL LANGUAGE,COBOL �A� ; -UTL ICF,CUSCPY,CUST-TBL.CUST-ELM,CUST-TBL ; -UTL AREA,CUST,CUS ; -END ;




2 CUST. 3 CUST-ID. 4 IND-CD PICTURE X(1). 4 CUST-NO PICTURE X(4). 3 NAME PICTURE X(3). 3 ADDR-1 PICTURE X(3). 3 ADDR-2 PICTURE X(3). 3 CITY PICTURE X(15). 3 STATE PICTURE X(2). �B� 3 ZIP PICTURE X(9). 3 CRED-IND PICTURE X(1). 3 PHONE. 4 AREA-CD PICTURE X(3). 4 PH-EXCH PICTURE X(3). 4 PH-NO PICTURE X(4). 3 OPEN-$ PICTURE S9(7)V9(2) COMPUTATIONAL-3. 3 YTD-SALES PICTURE S9(7)V9(2) COMPUTATIONAL-3. 3 ACT-DT. 4 ACT-YR PICTURE X(2). 4 ACT-MO PICTURE X(2). 4 ACT-DAY PICTURE X(2). 3 SLMN-ID PICTURE X(5).

�A� The DDICF transactions as entered.

�B� The copybook statements used to generate the DDUPDATE transactions.



Sample Output - DDICF - for a Table

The following are the transactions created for a TABLE substructure.

-ADD TABLE,CUST-TBL(T1)1 CONNECT,CUST315 CUS-GRP START,TABLE,CUST-TBL(T1)-ADD FIELD,CUST41 START412 C C L N 1-END-ADD FIELD,CUST-ID41 CUST CUST412 C C L N 1-END-ADD FIELD,IND-CD41 CUST-ID CUST-ID412 S C L N 1 1-END-ADD FIELD,CUST-NO41 IND-CD CUST-ID412 S C L N 4 1-END-ADD FIELD,NAME41 CUST-ID CUST412 S C L N 3 1-END-ADD FIELD,ADDR-141 NAME CUST412 S C L N 3 1-END-ADD FIELD,ADDR-241 ADDR-1 CUST412 S C L N 3 1-END-ADD FIELD,CITY41 ADDR-2 CUST412 S C L N 15 1-END-ADD FIELD,STATE41 CITY CUST412 S C L N 2 1-END-ADD FIELD,ZIP41 STATE CUST412 S C L N 9 1-END-ADD FIELD,CRED-IND41 ZIP CUST412 S C L N 1 1-END-ADD FIELD,PHONE41 CRED-IND CUST412 C C L N 1-END-ADD FIELD,AREA-CD41 PHONE PHONE



412 S C L N 3 1-END-ADD FIELD,PH-EXCH41 AREA-CD PHONE412 S C L N 3 1-END-ADD FIELD,PH-NO41 PH-EXCH PHONE412 S C L N 4 1-END-ADD FIELD,OPEN-$41 PHONE CUST412 S D R Y 5 2 1-END-ADD FIELD,YTD-SALES41 OPEN-$ CUST412 S D R Y 5 2 1-END-ADD FIELD,ACT-DT41 YTD-SALES CUST412 C C L N 1-END-ADD FIELD,ACT-YR41 ACT-DT ACT-DT412 S C L N 2 1-END-ADD FIELD,ACT-MO41 ACT-YR ACT-DT412 S C L N 2 1-END-ADD FIELD,ACT-DAY41 ACT-MO ACT-DT412 S C L N 2 1-END-ADD FIELD,SLMN-ID41 ACT-DT CUST412 S C L N 5 1-END-GRP END-ADD ELEMENT,CUST-TBL.CUST-ELM(T1)61 ADD CUST611 CUST61 ADD CUST-ID611 CUST-ID61 ADD IND-CD611 IND-CD61 ADD CUST-NO611 CUST-NO61 ADD NAME611 NAME61 ADD ADDR-1611 ADDR-161 ADD ADDR-2611 ADDR-261 ADD CITY611 CITY61 ADD STATE611 STATE61 ADD ZIP



611 ZIP61 ADD CRED-IND611 CRED-IND61 ADD PHONE611 PHONE61 ADD AREA-CD611 AREA-CD61 ADD PH-EXCH611 PH-EXCH61 ADD PH-NO611 PH-NO61 ADD OPEN-$611 OPEN-$61 ADD YTD-SALES611 YTD-SALES61 ADD ACT-DT611 ACT-DT61 ADD ACT-YR611 ACT-YR61 ADD ACT-MO611 ACT-MO61 ADD ACT-DAY611 ACT-DAY61 ADD SLMN-ID611 SLMN-ID-END



Sample Report - DDICF - for a File

The following is a sample report produced for a FILE structure request. Thedefinitions contain redefining fields.





-UTL LIBRARY,OS ; -UTL LANGUAGE,COBOL �A� ; -UTL ICF,SAMP-CPY,SAMP-REC.SAMP-ELM,SAMP-REC ; -END ;






3 SAMPLE-GROUP.4 REC-TYPE-CODE PICTURE X(1).

88 TYPE- VALUE ''. 88 TYPE-1 VALUE '1'. 88 TYPE-2 VALUE '2'. 88 TYPE-3 VALUE '3'. 4 COMMON-FIELD-1 PICTURE X(3). 4 COMMON-FIELD-2 PICTURE S9(9) COMPUTATIONAL. 4 TYPE--PORTION. 5 TYPE--FIELD-1 PICTURE S9(9) �B� COMPUTATIONAL-3. 5 TYPE--FIELD-2 PICTURE X(2). 5 TYPE--FIELD-3 PICTURE X(3). 5 TYPE--FIELD-4 REDEFINES TYPE--FIELD-3 PICTURE X(3). 5 TYPE--FIELD-5 REDEFINES TYPE--FIELD-4 PICTURE X(3). 5 TYPE--FIELD-6 REDEFINES TYPE--FIELD-5. 6 TYPE--FIELD-6A PICTURE X(1). 6 TYPE--FIELD-6B PICTURE X(2). 4 TYPE-1-PORTION REDEFINES TYPE--PORTION. 5 TYPE-1-FIELD-1 PICTURE X(5). 5 TYPE-1-FIELD-2 PICTURE X(2). 5 TYPE-1-FIELD-2R REDEFINES TYPE-1-FIELD-2 PICTURE X(2). 5 TYPE-1-FIELD-3 PICTURE X(3). 4 TYPE-2-PORTION REDEFINES TYPE--PORTION. 5 TYPE-2-FIELD-1 PICTURE X(8). 5 TYPE-2-FIELD-2 PICTURE X(1). 4 TYPE-3-PORTION REDEFINES TYPE--PORTION. 5 TYPE-3-FIELD-1 PICTURE X(7).

�A� The DDICF transactions as entered.

�B� The copybook statements used to generate the DDUPDATE transactions.



Sample Output - DDICF - for a File

The following are the transactions created for a FILE substructure:

-ADD FILE,SAMP-REC312 NONE 496 UNDF-ADD RECORD,SAMP-REC(T1)1 CONNECT,SAMP-REC-GRP START,RECORD,SAMP-REC(T1)-ADD FIELD,SAMPLE-GROUP41 START412 C C L N 1-END-ADD FIELD,REC-TYPE-CODE41 SAMPLE-GROUP SAMPLE-GROUP412 S C L N 1 1-END-ADD FIELD,TYPE-41 REC-TYPE-CODE REC-TYPE-CODE412 V C L N 1 -END-ADD FIELD,TYPE-141 TYPE- REC-TYPE-CODE412 V C L N 1 1-END-ADD FIELD,TYPE-241 TYPE-1 REC-TYPE-CODE412 V C L N 1 2-END-ADD FIELD,TYPE-341 TYPE-2 REC-TYPE-CODE412 V C L N 1 3-END-ADD FIELD,COMMON-FIELD-141 REC-TYPE-CODE SAMPLE-GROUP412 S C L N 3 1-END-ADD FIELD,COMMON-FIELD-241 COMMON-FIELD-1 SAMPLE-GROUP412 S B R Y 4 1-END-ADD FIELD,TYPE--PORTION41 COMMON-FIELD-2 SAMPLE-GROUP412 C C L N 1-END-ADD FIELD,TYPE--FIELD-141 TYPE--PORTION TYPE--PORTION412 S D R Y 5 1-END-ADD FIELD,TYPE--FIELD-241 TYPE--FIELD-1 TYPE--PORTION412 S C L N 2 1-END-ADD FIELD,TYPE--FIELD-341 TYPE--FIELD-2 TYPE--PORTION412 S C L N 3 1-END-ADD FIELD,TYPE--FIELD-4



41 TYPE--FIELD-3 TYPE--PORTION412 S C L N 3 1 P-END-ADD FIELD,TYPE--FIELD-541 TYPE--FIELD-4 TYPE--PORTION412 S C L N 3 1 P-END-ADD FIELD,TYPE--FIELD-641 TYPE--FIELD-5 TYPE--PORTION412 C C L N 1 P-END-ADD FIELD,TYPE--FIELD-6A41 TYPE--FIELD-6 TYPE--FIELD-6412 S C L N 1 1-END-ADD FIELD,TYPE--FIELD-6B41 TYPE--FIELD-6A TYPE--FIELD-6412 S C L N 2 1-END-ADD FIELD,TYPE-1-PORTION41 TYPE--PORTION SAMPLE-GROUP412 C C L N 1 P-END-ADD FIELD,TYPE-1-FIELD-141 TYPE-1-PORTION TYPE-1-PORTION412 S C L N 5 1-END-ADD FIELD,TYPE-1-FIELD-241 TYPE-1-FIELD-1 TYPE-1-PORTION412 S C L N 2 1-END-ADD FIELD,TYPE-1-FIELD-2R41 TYPE-1-FIELD-2 TYPE-1-PORTION412 S C L N 2 1 P-END-ADD FIELD,TYPE-1-FIELD-341 TYPE-1-FIELD-2R TYPE-1-PORTION412 S C L N 3 1-END-ADD FIELD,TYPE-2-PORTION41 TYPE-1-PORTION SAMPLE-GROUP412 C C L N 1 S-END-ADD FIELD,TYPE-2-FIELD-141 TYPE-2-PORTION TYPE-2-PORTION412 S C L N 8 1-END-ADD FIELD,TYPE-2-FIELD-241 TYPE-2-FIELD-1 TYPE-2-PORTION412 S C L N 1 1-END-ADD FIELD,TYPE-3-PORTION41 TYPE-2-PORTION SAMPLE-GROUP412 C C L N 1 S-END-ADD FIELD,TYPE-3-FIELD-141 TYPE-3-PORTION TYPE-3-PORTION412 S C L N 7 1-END



-GRP END-ADD ELEMENT,SAMP-REC.SAMP-ELM(T1)61 ADD SAMPLE-GROUP611 SAMPLE-GROUP61 ADD REC-TYPE-CODE611 REC-TYPE-CODE61 ADD TYPE-611 TYPE-61 ADD TYPE-1611 TYPE-161 ADD TYPE-2611 TYPE-261 ADD TYPE-3611 TYPE-361 ADD COMMON-FIELD-1611 COMMON-FIELD-161 ADD COMMON-FIELD-2611 COMMON-FIELD-261 ADD TYPE--PORTION611 TYPE--PORTION61 ADD TYPE--FIELD-1611 TYPE--FIELD-161 ADD TYPE--FIELD-2611 TYPE--FIELD-261 ADD TYPE--FIELD-3611 TYPE--FIELD-361 ADD TYPE--FIELD-4611 TYPE--FIELD-461 ADD TYPE--FIELD-5611 TYPE--FIELD-561 ADD TYPE--FIELD-6611 TYPE--FIELD-661 ADD TYPE--FIELD-6A611 TYPE--FIELD-6A61 ADD TYPE--FIELD-6B611 TYPE--FIELD-6B61 ADD TYPE-1-PORTION611 TYPE-1-PORTION61 ADD TYPE-1-FIELD-1611 TYPE-1-FIELD-161 ADD TYPE-1-FIELD-2611 TYPE-1-FIELD-261 ADD TYPE-1-FIELD-2R611 TYPE-1-FIELD-2R61 ADD TYPE-1-FIELD-3611 TYPE-1-FIELD-361 ADD TYPE-2-PORTION611 TYPE-2-PORTION61 ADD TYPE-2-FIELD-1611 TYPE-2-FIELD-161 ADD TYPE-2-FIELD-2611 TYPE-2-FIELD-261 ADD TYPE-3-PORTION611 TYPE-3-PORTION61 ADD TYPE-3-FIELD-1611 TYPE-3-FIELD-1-END



Chapter 5. DDRMFLM - ConvertingField Definitions


When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Valid Field Type Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . 129Inserting Fields and Specifying the VALUE Value . . . . . . . . . . . . . . 130Deleting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Changing Fields with Decimals . . . . . . . . . . . . . . . . . . . . . . . . . 132Handling Filler Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Truncating Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Handling Null-filled Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Report Produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136-RMF INPUT - Specifying the Input . . . . . . . . . . . . . . . . . . . . . . 137-RMF OUTPUT - Specifying the Output . . . . . . . . . . . . . . . . . . . . 139-RMF EXITS - Specifying Exit Programs . . . . . . . . . . . . . . . . . . . 141

Contents of the Exit Program . . . . . . . . . . . . . . . . . . . . . . . 142Sample Job Streams and Reports . . . . . . . . . . . . . . . . . . . . . . . 143

z/OS Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143z/VSE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Sample Report - DDRMFLM . . . . . . . . . . . . . . . . . . . . . . . . 144Sample Report - DDRMFLM Report with Errors . . . . . . . . . . . . . 148

The Record Migration Facility (DDRMFLM) is a batch utility for converting thefields in a data record to a new displacement, length or type. Additionally, thisfacility supports adding and initializing new fields to tables or records anddeleting fields from tables or records.

Chapter 5. DDRMFLM - Converting Field Definitions 125

When to Use

When to Use

You can use the DDRMFLM facility to create a sequential file in a formatdefined by the TABLE and FIELD occurrences or the RECORD and FIELDoccurrences in Datadictionary.

You can direct the Record Migration Facility to pass control to user-written exitprograms to modify either the input or output records.

The Record Migration Facility reads the Datadictionary definitions of the tablesor records for the input and output files. The input and output files must befixed-block sequential files. They can be on disk or tape. You can use theEXTRACT function of DBUTLTY to produce the fixed-block sequential input file.For more information, see the CA Datacom/DB DBUTLTY Reference Guide.

The utility reads each record from the input file, converts it to the format definedfor the output file and writes it to the output file. You can use this output file asinput to the DBUTLTY LOAD function to load a CA Datacom/DB table.


How to Use

How to Use

After defining the appropriate occurrences in Datadictionary, you can use thisbatch facility to change the format of data records as follows:

■ Insert new fields in a table or record.■ Delete fields from a table or record.■ Change the order of fields in a table or record.■ Change certain field types in a table or record (see chart on page 129).■ Change field lengths in a table or record.




The number of fields in the input record cannot exceed the number specified inMAXFLDS= in the System Resource Table (SRT). When the DDRMFLM utilityexecutes, it uses special Datadictionary Service Facility (DSF) commands tocomplete its work. One of these commands results in a temporary Data GroupTable (DGT) in the High-Speed Directory (HSD). This DGT contains a field foreach field in the input record. Although the DGT only exists for the duration ofthe run of the utility, it must follow the same rules as a DGT built for aDatadictionary entity-type, including the maximum size. If the number of fieldsexceeds the MAXFLDS= limit, consider reassembling the SRT with a largervalue.

When a sign change is the only change to a field, the DDRMFLM utility doesnot convert the field in any way.

Only one file can be converted in each execution of the Record MigrationFacility. The file must contain occurrences of only one TABLE or RECORDdefinition.

All processing in the DDRMFLM utility is based solely on simple field(CLASS=S) definitions. Compound (CLASS=C), value or qualifier (CLASS=V)and filler (CLASS=F) fields are ignored in the conversion process.

This utility does not support TABLE or RECORD occurrence definitionscontaining the following:

■ Redefinition fields (REDEFINES=P or S)■ Fields with a REPEAT attribute-value greater than 1■ Binary (TYPE=B) fields with lengths greater than 7 bytes■ Packed decimal fields greater than 8 bytes (15 unpacked)■ Any fields with a length greater than 255 bytes■ Any fields defined with a data type of V (VARCHAR)


Valid Field Type Conversions

Valid Field Type Conversions

Not all field type conversions are possible with the Record Migration Facility.The following chart lists the valid conversions for the field types:


Inserting Fields and Specifying the VALUE Value

Inserting Fields and Specifying the VALUE Value

When inserting a new field, the value specified in the VALUE attribute for theFIELD occurrence is used as the default initialization value. Every occurrenceof that field will be initialized with this value.

If you do not specify the value, the utility fills the field with character blanks(X'40') for the character, double-byte character set, Kanji and graphic datatypes. For all numeric data types, the utility fills the field with the appropriateformat for zero:

■ Binary zeros for binary type■ Packed decimal zeros with a positive sign for packed decimal■ Character zeros for zoned decimal numeric


Deleting Fields

Deleting Fields

To remove a field from all data records in the file, delete that FIELD occurrencedefinition from the Datadictionary definition for the TABLE or RECORDoccurrence for the output file. The utility ignores the data for the deleted FIELDoccurrence and adjusts the other field displacements accordingly.


Changing Fields with Decimals

Changing Fields with Decimals

DDRMFLM does not change the placement of decimals in a field if you do oneor both of the following:

■ Increase or decrease the overall length of the field■ Change the number of decimal positions in the field


Handling Filler Fields

Handling Filler Fields

Filler fields are converted from blanks in the input file to nulls in the output file.To avoid this conversion, change each filler field to a simple character (type C)field in the Datadictionary definition for the TABLE or RECORD occurrence inthe input file. You can then change the fields back to filler fields in theDatadictionary definition for the output file after the conversion is complete.

For example, you might have a compound field, BILL-DATE, with fields ofBILL-MO, FILL1, BILL-DAY, FILL2, BILL-YR that represent the date entered as01/31/2002. You must delete the parent of the compound field and make thesubordinate fields into simple fields. Also, change FILL1 and FILL2 toone-character simple fields with a value of / (slash) in the Datadictionarydefinitions for both input and output files. You can then change the fields backto a compound field and filler fields after completion of the Record MigrationFacility.


Truncating Data

Truncating Data

When you convert fields to a shorter length, the utility generates a messagewhen it must truncate significant data. You do not receive the message if theutility truncates leading zeros or trailing blanks.

The DDRMFLM job stream or the SYSIN file must contain a -USR transactionto verify authorization before the batch utility can execute. For moreinformation, see “Establishing User Identification” on page 20.


Handling Null-filled Fields

Handling Null-filled Fields

DDRMFLM converts null-filled, left-justified character fields on input toblank-filled fields on output. If the rightmost portion of a field is null-filled, it isfilled with blanks. If null-filled fields is the desired result, use one of thefollowing options:

■ If the data is predictably null-filled, write an output exit to replace the fieldsor portion of the fields in the output records.

■ If the nulls are unpredictable and there is at least one hex value that isnever used within the field, translate the trailing portion of the field to thathex value in an input exit and write an output exit to restore the charactersto null-filled.

■ If neither of these is acceptable, temporarily define the field as a binary fieldof seven bytes or less.


Report Produced

Report Produced

When you execute this utility, a report is automatically produced which showsthe results of the conversion and certain diagnostic information. The report liststhe action anticipated by the Record Migration Facility to convert each field,information on the input and output FIELD occurrences and any conversionerrors and conflicts.For more information, see the sample reports starting onpage 144.


-RMF INPUT - Specifying the Input


Use the following command format to identify the Datadictionary definition forthe existing sequential file.

In z/OS:

��──-RMF─ ──INPUT,occ-name(stat ──┬ ┬─────── ),blksz ──────────────────────�� └ ┘ ─,ovrd─

In z/VSE:

��──-RMF─ ──INPUT,occ-name(stat ──┬ ┬─────── ),blksz ──┬ ┬───────── ─────────�� └ ┘ ─,ovrd─ └ ┘ ─,device─

,occ-name(Required) Specify the name of the TABLE or RECORD occurrencedefined for the input sequential file.

Valid Entries: TABLE or RECORD occurrence name


(stat)(Required) Specify the status/version of the TABLE or RECORDoccurrence in Datadictionary.

Valid Entries: T001 to T999PROD1 to 999H001 to H997 (000 to 997 is the generation number)HIST or H001 to H997 (000 to 997 is the generationnumber)


,blksz(Required) Specify the block size of the input file. The minimum that canbe specified is 960. The maximum value is the track size of the device or32767 bytes, whichever is smaller.

Valid Entries: 960 to track size or 32767, whichever is less




,ovrd(Optional) Enter the system override code within the parenthesessurrounding the stat parameter if the TABLE or RECORD occurrence isprotected from unauthorized access by Lock Level 2. If the table orrecord is not protected by the lock level, you can omit the override codeand its preceding comma.



,device(Optional) For z/VSE only, specify if the input file is on disk or tape.

Valid Entries: DISKTAPE

Default Value: DISK


-RMF OUTPUT - Specifying the Output


Use the following command format to identify the Datadictionary definition thatthe Record Migration Facility utility will use when creating the new sequentialfile.

In z/OS and z/VSE:

��──-RMF──OUTPUT─ ──,occ-name(stat ──┬ ┬─────── ) ──────────────────────────� └ ┘─,ovrd─

�─ ──┬ ┬─────────────────────────────── ─────────────────────────────────�� ├ ┤ ─,errs─ ──┬ ┬──────────────────── │ │└ ┘ ─,proc─ ──┬ ┬───────── │ │└ ┘─,device─ ├ ┤──┬ ┬───────────────────── ────── │ │└ ┘ ─,,proc─ ──┬ ┬───────── │ │└ ┘─,device─ └ ┘─,,,device─────────────────────

,occ-name(Required) Specify the name of the TABLE or RECORD occurrencedefined for the output sequential file.

Valid Entries: TABLE or RECORD occurrence name


(stat)(Required) Specify the status/version of the TABLE or RECORDoccurrence in Datadictionary.

Valid Entries: T001 to T999PROD1 to 999


,ovrd(Optional) Enter the system override code within the parenthesessurrounding the stat parameter if the TABLE or RECORD occurrence isprotected from unauthorized access by Lock Level 2. If the table orrecord is not protected by the lock level, you can omit the override codeand its preceding comma.



,errs (Optional) Specify the number of record conversion errors per run youwant to allow before terminating the conversion run. If you omit this entrybut specify the type of processing, you must enter the preceding comma.


Default Value: 15



,proc(Optional) Specify the type of processing for this execution of the utility.

■ If you specify REPORT, you only receive a report similar to thesample on page 144, and the Record Migration Facility does notcreate the new file.

■ If you specify PROCESS, the Record Migration Facility creates thenew file and gives you the report.

If you omit the errs entry but specify the type of processing, you mustenter the two preceding commas.

Valid Entries: PROCESSREPORT

Default Value: PROCESS

,device(Optional) Specify if the output file is on disk or tape. If you omit the twopreceding entries but specify the type of device, you must enter the threepreceding commas.

The output device selected affects the output block size calculated. IfDISK is selected, the output block size is calculated as the largest evenmultiple of the output record length that does not exceed the input blocksize. If TAPE is selected, the output block size is calculated as thelargest even multiple of the output record length that does not exceed32,767.

Valid Entries: DISKTAPE

Default Value: DISK


-RMF EXITS - Specifying Exit Programs


You can direct the Record Migration Facility to pass control to user-written exitprograms at two points in the conversion process for each record. For moreinformation, see Appendix B, “Sample User-Written Exits for DDRMFLM(Assembler)” on page 599.

The first exit point allows a program to gain control after each record has beenread from the input file and before the conversion takes place. You can codethis exit program to skip specific records or records that meet certainuser-defined criteria. You can also code this exit program to edit the contentsof fields which exist on the input record.

With the second exit point, you can direct the Record Migration Facility to passcontrol to a user-written program after each record conversion takes place andbefore the converted record is written to the output sequential file. You cancode this program to change records or change values of inserted fields. Theconversion process will initialize inserted fields to the default for the field type orto a specific value defined in the VALUE attribute in the Datadictionarydefinition of the field that is inserted.

You can code either user-written exit program to specify messages that willappear in the conversion report, such as interim progress messages.

Use the following command format to identify the user-written exit programs forthe Record Migration Facility transactions. You can specify the user-written exitprograms that will have access to each table or record before and after theconversion process or either one.

��──-RMF EXITS─ ──┬ ┬────────────────────────── ─────────────────────────�� ├ ┤──┬ ┬────────────────────── │ │└ ┘ ─,uexit1─ ──┬ ┬───────── │ │└ ┘─,uexit2─ └ ┘─,,uexit2─────────────────

,uexit1Specify the name of a user-defined exit program that gains control afterthe utility reads each table or record and prior to the conversion. This isthe table or record in the format described by the Datadictionary definitionfor the input file. If you omit this exit and specify the next exit, thepreceding comma is required.

Valid Entries: Existing user-written exit program name




,uexit2Specify the name of a user-defined exit program that gains control afterthe utility converts each table or record, but before it is written to theoutput file. This is the table or record in the format described by theDatadictionary definition for the output file. If you omit the previous exit,you must precede this exit with two commas.

Valid Entries: Existing user-written exit program name


Contents of the Exit Program

Standard linkage conventions apply. When the user exit gains control, register 1points to a parameter list. The parameter list consists of the following fourfullwords:

Address of the input recordThis is meaningless in the second exit and should be referenced in thefirst exit only.

Address of the output recordThis is meaningless in the first exit and should be referenced in thesecond exit only.

Address of a message areaThis address points to a 119-character area that can receive user-writtenmessages to appear on the conversion report produced by the RecordMigration Facility.

Address of the return codeThis address points to a binary fullword where the user can place a returncode to affect subsequent processing.

Return code greater than 0Print any message provided by user

Return code less than 4Continue processing

Return code 4Skip record and continue processing

Return code greater than 4Terminate processing


Sample Job Streams and Reports


The following are examples of JCL and sample reports.

z/OS Example


//jobname See the note above and page 19. // EXEC PGM=DDRMFLM,REGION=124K //STEPLIB See the note above and page 19. //RMFIN DD DSN=input.dataset.name,DISP=SHR Input sequential file //RMFOUT DD DSN=output.dataset.name,DISP=SHR Output sequential file //SYSPRINT DD SYSOUT=a Print output//SNAPER DD SYSOUT=b CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR SAMPLE-USER Authorized user information -RMF INPUT,DEMO-TABLE(T1),496 -RMF OUTPUT,DEMO-TABLE(T2) -RMF EXITS,INPEXIT,OUTEXIT /

z/VSE Example


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYSnnn,device-type,VOL=volser,SHR // DLBL auxout,'aux.output.file' Output other than SYSPCH // EXTENT // DLBL RMFIN,'name.rmfin.file' Input sequential file // EXTENT SYSnnn,volser... // DLBL RMFOUT,'name.rmfout.file' Output sequential file // EXTENT SYSnnn,volser... // EXEC DDRMFLM,SIZE=6K -USR SAMPLE-USER Authorized user information -RMF INPUT,DEMO-TABLE(T1),496 -RMF OUTPUT,DEMO-TABLE(T2) -RMF EXITS,INPEXIT,OUTEXIT / /& $$ EOJ



Sample Report - DDRMFLM

Date: mm/dd/ccyy Time: hh.mm.ss Page: 1 Advantage CA-Datacom Database Datadictionary Option

Security Level: 1 Record Migration Facility Version: 12 Copyright © 29 CA. All rights reserved. MUF Name: x

User: SAMPLE-USER DD Base: -USR SAMPLE-USER-RMF INPUT,DEMO-TABLE(T1),496-RMF OUTPUT,DEMO-TABLE(T2) �A�-RMF EXITS,INPEXIT,OUTEXIT

�B�



User: SAMPLE-USER DD Base: 2 �C�

RECORD MIGRATION REPORT ...INPUT RECORD ATTRIBUTES... ...OUTPUT RECORD ATTRIBUTES..

RMF ACTION FIELD NAME TYPE LENGTH DISPL TYPE LENGTH DISPL NOTES--------- -------------------------------- -------------- ----- ----- -------------- ----- ----- -----UNCHANGED ACCT-NUMBER ZONED DECIMAL 5 1 ZONED DECIMAL 5 1MODIFIED ACCT-TYPE CHARACTER 1 6 CHARACTER 5 6MOVED ACCT-STATUS CHARACTER 1 7 CHARACTER 1 11MOVED PREV-BALANCE ZONED DECIMAL 8 8 ZONED DECIMAL 8 12MOVED TOT-DEPOSITS ZONED DECIMAL 8 16 ZONED DECIMAL 8 2MOVED TOT-WITHDRAWALS ZONED DECIMAL 8 24 ZONED DECIMAL 8 28MODIFIED NEW-BALANCE ZONED DECIMAL 8 32 BINARY D-WORD 8 41

DDRMFI1 - OUTPUT BLKSIZE IS 32. MODIFY FILE LOAD PARAMETERS ACCORDINGLY.SKIPPED AN INPUT RECORDRECORDS IN 221 RECORDS OUT 22

�A� The transactions exactly as entered. Any errors found are flagged with anote in the left margin.

�B� Any messages related to syntax processing will appear after thetransactions.

�C� The CA Datacom/DB Database ID (DBID) for the Datadictionarycontaining both input and output TABLE or RECORD occurrencedefinitions.







�D� �E�



�D� An identification of the action taken by the Record Migration Facility. Thepossible actions are:

ADDED

DELETED

MODIFIED

MOVED

UNCHANGED

**ERROR**

If the action is **ERROR**, the NOTES column will list a letter designationfor additional information concerning the conversion. For an example of**ERROR**, see page 148.

�E� The FIELD occurrence name from the Datadictionary definitions.







�F�



�F� The input FIELD occurrence types are identified on the report as follows:

Identifier Type

BINARY Binary

BINARY D-WORD Doubleword binary (aligned)

BINARY F-WORD Fullword binary (aligned)

BINARY H-WORD Halfword binary (aligned)

CHARACTER Character

DBL CHAR MIXED Mixed DBCS and single byte

DOUBLE CHAR Double-byte character set (DBCS)

EXTENDED FLOAT Extended floating-point

GRAPHICS Graphic data

HEXADECIMAL Hexadecimal

KANJI Kanji

LONG FLOAT PT Long floating-point

PL/I BIT STRING PL/I bit representation

PACKED DECIMAL Packed decimal

SHORT FLOAT PT Short floating-point

ZONED DECIMAL Numeric (zoned decimal)







�G� �H� �I� �J� �M� �N�


�O�

DDRMFI1 - OUTPUT BLKSIZE IS 32. MODIFY FILE LOAD PARAMETERS ACCORDINGLY. �P�SKIPPED AN INPUT RECORD ────┐RECORDS IN 221 RECORDS OUT 22 ├────────────────── ────┘

�G� The FIELD occurrence length defined for the input field.

�H� The FIELD occurrence displacement in the input record.

�I� The FIELD occurrence type defined for the output field.(See F. on the previous page.)

�J� The FIELD occurrence length defined for the output field.

�M� The FIELD occurrence displacement in the output record.

�N� A letter referencing additional information concerning the conversion innotes near the bottom of the report (see N here and on the next page).

�O� If there are any letters in the NOTES column, messages will appear here.(See �N�)

�P� Error messages issued by DDRMFLM display here.

�Q� Information concerning the conversion, including the number of inputrecords and the number of records converted to the output file.



Sample Report - DDRMFLM Report with Errors

The following sample report was prepared to display the error messagespresented by the Record Migration Facility on the report. Notice the keys in theNOTES column and the corresponding messages near the bottom of the report.





�N�

RMF ACTION FIELD NAME TYPE LENGTH DISPL TYPE LENGTH DISPL NOTES--------- -------------------------------- -------------- ----- ----- -------------- ----- ----- -----MODIFIED FIELD-1 CHARACTER 1 1 ZONED DECIMAL 1 1 VMODIFIED FIELD-2 ZONED DECIMAL 2 2 PACKED DECIMAL 2 2MODIFIED FIELD-4 BINARY 4 7 HEXADECIMAL 4 7ERROR FIELD-5 HEXADECIMAL 6 11 SHORT FLOAT PT 4 11 EMODIFIED FIELD-6 SHORT FLOAT PT 4 17 LONG FLOAT PT 8 15MODIFIED FIELD-7 LONG FLOAT PT 8 21 EXTENDED FLOAT 16 23ERROR FIELD-8 EXTENDED FLOAT 16 29 BINARY H-WORD 2 39 EMODIFIED FIELD-9 BINARY H-WORD 2 45 BINARY F-WORD 4 41MODIFIED FIELD-1 BINARY F-WORD 4 49 BINARY D-WORD 8 49ERROR FIELD-11 BINARY D-WORD 8 57 PL/1 BIT STRING6 57 EERROR FIELD-12 PL/1 BIT STRING8 65 DOUBLE CHAR 6 63 EMODIFIED FIELD-13 DOUBLE CHAR 8 73 KANJI 6 69DELETED FIELD-14 KANJI 8 81ERROR FIELD-15 DBL CHAR MIXED 8 89 GRAPHICS 6 75 EERROR FIELD-16 GRAPHICS 8 97 CHARACTER 6 81 EADDED FIELD-3 BINARY 3 4ADDED FIELD-17 CHARACTER 6 87

NOTE E - TYPE CONVERSION IS INVALID OR UNSUPPORTED ────┐NOTE V - SUCCESSFUL MIGRATION DEPENDS ON INPUT FIELD VALUES BEING VALID FOR OUTPUT FIELD TYPE ├─── �P�NOTE P - CONVERSION ALLOWED. RESULTS MAY BE UNPRINTABLE ────┘DDRMFP98 - INVALID TYPE CONVERSION ATTEMPTED - PROCESSING TERMINATED

�N� A letter referencing additional information concerning the conversion innotes near the bottom of the report (see O).

�P� The messages referenced by the letters in the NOTES column.(Messages only appear if there are entries in the NOTES column. SeeM.)


Chapter 6. DDRTVCAT - Using theRuntime and Verify Catalog Program


When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151-CXX CATALOG - Cataloging the Definitions to the Directory . . . . . . . 152-RTV BASIS - Modeling a Database . . . . . . . . . . . . . . . . . . . . . . 154Sample Job Streams and Report . . . . . . . . . . . . . . . . . . . . . . . . 155

z/OS Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155z/VSE Example JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Sample Report - DDRTVCAT . . . . . . . . . . . . . . . . . . . . . . . 157

For CA Datacom/AD, use the DDRTVCAT (Datadictionary Runtime Verify andCatalog) Utility to perform the following functions. When these functions areexecuted, the Datadictionary VERIFY function is also executed and anyresulting error messages are issued. For more information, see theDatadictionary error messages in the CA Datacom/DB Message ReferenceGuide.

-CXX CATALOGSpecifies the occurrence name of the database to be cataloged to theDirectory (CXX).

-RTV BASISSpecifies the occurrence name of the database to be used as a model orbase when running the catalog program. The -RTV BASIS transaction isoptional. It is used when making an exact copy of an existing database inorder to have multiple databases.

Important:

The database being cataloged cannot be open for update by the Multi-UserFacility or any Single-User job when running DDRTVCAT.

The Directory (CXX) is the heart of the CA Datacom/AD production system.Therefore, we recommend that you run the DBUTLTY BACKUP AREA=CXXfunction prior to executing the DDRTVCAT program. For more informationabout the BACKUP function, see the CA Datacom/DB DBUTLTY ReferenceGuide.

The DDRTVCAT program first compares the database description that wasshipped with the CA application product to the newly modified databasedescription and verifies changes. You are only allowed to redefine existingfields and add keys. DDRTVCAT also makes sure that no other changes aremade to the shipped database structure. If the DDRTVCAT checks meet theestablished criteria, the program copies the database to PRODuction status,

Chapter 6. DDRTVCAT - Using the Runtime and Verify Catalog Program 149

catalogs the database structure, and enables it for use with CA Dataquery orCA Ideal.

Error Messages: The DDRTVCAT error messages are listed in the CADatacom/DB Message Reference Guide in the chapter containingDatadictionary numbered messages. The format is DDRTVcnnnn.


When to Use

When to Use

The DDRTVCAT utility is provided for use with CA Datacom/AD. It can,however, also be executed in a full CA Datacom/DB environment.

During the installation process, your Datadictionary is fully populated with thedefinitions required by the using product. If you find that you need to tailorDatadictionary for your particular requirements, use the DDRTVCAT utility tocatalog these changes to the Directory (CXX).




Use the -CXX CATALOG transaction submitted through the DDRTVCAT utilityto verify the database structure and catalog the occurrence definitions to the CADatacom/AD Directory (CXX). You can catalog TEST and PRODuction statusDATABASE structures.

For the CA Datacom/DB Accounting database, use the DBUTLTY ACCTOPTION. For more information, see the CA Datacom/DB DBUTLTY ReferenceGuide.

The following is the format for the -CXX CATALOG transaction:

��──-CXX──CATALOG──,DATABASE─ ──,occ-name.(stat ──┬ ┬──────────── ) ───────�� ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────





(stat)(Required) Specifies the status of the occurrence used as input to theDDRTVCAT execution.



,pswd(Optional) Enter the user-assigned password for the DATABASEoccurrence within the parentheses surrounding the stat parameter. If theoccurrence is not protected by a password and you must enter anoverride code, enter the preceding comma.






Valid Entries: system override code



-RTV BASIS - Modeling a Database

-RTV BASIS - Modeling a Database

Use the -RTV BASIS transaction to identify the existing database structure onwhich to model the new database structure.

The following is the format for the -RTV BASIS transaction:

��──-RTV─ ──BASIS,occ-name ─────────────────────────────────────────────��








z/OS Example JCL

The following sample JCL catalogs the DATABASE structure definition to theDirectory (CXX).


//jobname See the note above and page 19. // EXEC PGM=DDRTVCAT,REGION=6K //STEPLIB See the note above and page 19. //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/AD dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR SAMPLE-USER,password Authorized user information -CXX CATALOG,DATABASE,MP33(T99) -RTV BASIS,MP3 /



z/VSE Example JCL



$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYSnnn,device-type,VOL=volser,SHR // DLBL ddrtvcat,'ddrtvcat.output.trans' BUILD function output // EXTENT to DBUTLTY The above statements are required. If the CATALOG function is performed this data set will be open and closed, insuring incorrect data from the last BUILD function is not used to update the directory. // EXEC DDRTVCAT,SIZE=6K -USR SAMPLE-USER,password Authorized user information -CXX CATALOG,DATABASE,MP33(T99) -RTV BASIS,MP3 / /& $$ EOJ



Sample Report - DDRTVCAT




----------------------------------------------------------------------------------- �A� CODE USER-NAME,PSWD,DATABASE-ID -USR SAMPLE-USER, �B� ; -----------------------------------------------------------------------------------

�A�Identifies the database ID.

�B�The information that can be entered for this transaction followed by thetransaction as entered: a -USR transaction.



User: SAMPLE-USER DD Base: 2 ----------------------------------------------------------------------------------- CODE FUNCTION,ENTITY-TYPE,OCCURRENCE(VERS,PSWD,OVRD) -CXX CATALOG,DATABASE,MP33(T1) �C� ; -----------------------------------------------------------------------------------

----------------------------------------------------------------------------------- CODE FUNCTION,BASIS

-RTV BASIS,MP3 �C� ; -----------------------------------------------------------------------------------

FUNCTION = VERIFY-OLD-TO-NEW �D� ENTITY-TYPE = DATABASE OCCURRENCE = MP33

VERIFY ERROR MESSAGES DDRTVC19 CAUTION DATABASE ID HAS CHANGED �E�

OCCURRENCE = MP33 ATTRIBUTE = DATACOM-ID OLD VALUE = 3 NEW VALUE = 33

TOTAL ERRORS

FUNCTION = VERIFY-NEW-TO-OLD �F� ENTITY-TYPE = DATABASE OCCURRENCE = MP33

VERIFY ERROR MESSAGES

TOTAL ERRORS

FUNCTION = COPY-TO-PROD �G� ENTITY-TYPE = DATABASE OCCURRENCE = MP33

FUNCTION = CATALOG-STRUCTURE �H� ENTITY-TYPE = DATABASE OCCURRENCE = MP33

FUNCTION = ENABLE-STRUCTURE �I� ENTITY-TYPE = DATABASE OCCURRENCE = MP33



�C� The information that can be entered for this transaction followed by thetransaction as entered.

�D� The first function is the Datadictionary VERIFY function to compare theexisting database definition to the new database definition.

�E� Any errors or warnings that Datadictionary finds are reported.DDRTVC0019 is an information message only and confirms that you havecopied a database and given it a new database ID (DATACOM-ID).

�F� The next VERIFY function compares the new database definition to theexisting database definition.

�G� Datadictionary copies the new database definition from TEST toPRODuction status.

�H� Datadictionary catalogs the new database to the Directory (CXX).

�I� Datadictionary enables the new database definition.




----------------------------------------------------------------------------------- END OF JOB �J�

-----------------------------------------------------------------------------------

�J� A message indicating that the job has ended.


Chapter 7. DDTRSLM - TransportingDefinitions


When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Non-SQL Access Considerations . . . . . . . . . . . . . . . . . . . . . . . . 169How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170EXPORT Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172IMPORT Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Importing a Specific Entity-Occurrence . . . . . . . . . . . . . . . . . . 175Excluding Entity-Types or Entity-Occurrences . . . . . . . . . . . . . . 175Importing Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Importing Only Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Using the ONLY Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Using the REPLACE Option . . . . . . . . . . . . . . . . . . . . . . . . 176Listing Objects Exported . . . . . . . . . . . . . . . . . . . . . . . . . . 176Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Syntax for IMPORT ALL Commands . . . . . . . . . . . . . . . . . . . 177Syntax for IMPORT or TRIAL IMPORT Commands . . . . . . . . . . 177IMPORT DIRECTORY Command . . . . . . . . . . . . . . . . . . . . . 182TRIAL IMPORT Command . . . . . . . . . . . . . . . . . . . . . . . . . 182

SET USER - Establishing User Identification . . . . . . . . . . . . . . . . . 185SET EXPORT FORMAT PREV RELEASE - Convert Format . . . . . . . 186SET IMPORT COLLISION - Handling Duplicates . . . . . . . . . . . . . . 187SET TRACE - Debugging the Utility . . . . . . . . . . . . . . . . . . . . . . 188Sample Job Streams and Input . . . . . . . . . . . . . . . . . . . . . . . . . 189


Exporting Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Transporting Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Transporting Tables, Views, and Synonyms . . . . . . . . . . . . . . . . . 199Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

DDTRSLM is a Datadictionary utility that transports or backs up selectedDatadictionary definitions from one CA Datacom site for loading into another.DDTRSLM is primarily intended for use in an SQL-only environment. Objectssuch as tables and keys that are used by non-SQL programs could experiencesome anomalies when transported using this facility. If a table is accessed by

Chapter 7. DDTRSLM - Transporting Definitions 159

both SQL and non-SQL programs, we recommend that the Batch TransactionGenerator (DDBTGLM) be used to transport tables, and DDTRSLM be used forthe SQL-only objects such as plans, procedures, views, and so on. For moreinformation regarding non-SQL access considerations, see page 169.

The entity-types you can transport using this utility are TABLE, PLAN,PROCEDURE, TRIGGER, VIEW, and SYNONYM.

All occurrences transported are EXPORTed from PRODuction status andIMPORTed to PRODuction status.

When you import these entity-types, the dependent entity-types are alsoimported, with the exception of DATABASE and AREA entity-occurrences whichmust already exist at the destination site. Authorization IDs (SCHEMAs) usedmust also exist at the destination site. The following table lists the entity-typesyou can transport with this utility and their corresponding dependencies.

When you transport: The dependent entity-typestransported are:

PLAN entity-types STATEMENTSYNONYMTABLE (and its associated entity-types)VIEW

PROCEDURE entity-types PARAMETER-LISTPLAN, if a path exists (A procedure might notcontain SQL statements.)PROGRAMSTATEMENT and its associated entity-types:

TRIGGER (If not the root entity. There maynot be any related to the STATEMENT.)

PROCEDURE (If not the root entity.)

PROGRAM (Unless the PROCEDURE is theroot entity.)

PLAN (Unless the PROCEDURE is the rootentity.)

TABLE, if a path exists (A procedure might notcontain SQL statements.)



PROGRAM entity-types(for EXPORT only)

PLANPROCEDURE (and its associated entity-types)

PARAMETER-LIST

PLAN

PROGRAM (If not the root entity.)

STATEMENT

TRIGGER (There may not be any related tothe STATEMENT.)

STATEMENTSYNONYMTABLE (and its associated information)VIEW

SYNONYM entity-types TABLE (and its associated information)VIEW

TABLE entity-types AREA (definitions only, see note below)CONSTRAINTDATABASE (definitions only, see note below)DATAVIEWELEMENTFIELDKEYTRIGGER (and its associated entity-types)

PARAMETER-LIST

PLAN

PROCEDURE

PROGRAM

STATEMENT

Note: If you import the TABLE entity-types in SQL mode, the database andarea must already exist at the destination site and have already beencataloged, initialized, and loaded. The area must have an SQLNAME in boththe source and the target regions so that the SQL import of the table will putthe table in the correct area. The CREATE TABLE generated on the EXPORTwill not have an IN areaname clause if the area does not have an SQLNAMEand the IMPORT places the table in the default area.



TRIGGER entity-types STATEMENT and its associated entity-types:

PLAN (Unless the PROCEDURE is the rootentity.)

PROCEDURE (Unless the PROCEDURE isthe root entity.)

PROGRAM (Unless the PROCEDURE is theroot entity.)

TRIGGER (Unless the TRIGGER is the rootentity. There may not be any related to theSTATEMENT.)

TABLE (and its associated information)

VIEW entity-types SYNONYMTABLE (and its associated information)VIEW


When to Use

When to Use

Use this utility to migrate Datadictionary definitions between Multi-User Facilityenvironments. The two Multi-User Facilities may be executing in differentoperating systems, z/OS and z/VSE. This utility provides an alternative tomanually creating SQL objects and re-precompiling programs with embeddedSQL statements.

The SQL objects are added through the CA Datacom/DB SQL Option at thedestination site. Therefore, this function of the utility operates only at siteswhere the CA Datacom/DB SQL Option is installed.

Examples of when to use this utility are:

■ You may want to move a program from test to production environments. Tooperate at the destination site, the program must have all referenced SQLobjects (tables, views, and synonyms) and the SQL plan corresponding tothe program. By using this utility, all this information can be moved at thesame time by transporting the plan. To transport CA Ideal programs, usethe CA Ideal Object Transport Utility (IDUTOTRN) in conjunction withDDTRSLM.

■ You may want to provide application programmers using a differentoperating system with the table definitions. They can develop and testapplications on the other operating system for eventual execution with thetables on your machine. To accomplish this, EXPORT the definitions withDDTRSLM, send the transport file with any file transfer utility, and IMPORTwith the DDTRSLM utility available on the other operating system.


How It Works

How It Works

The transport utility is driven by EXPORT, IMPORT, and SET commands. TheEXPORT and IMPORT commands must be run in separate DDTRSLMexecutions to allow for different input job stream specifications.

For either the EXPORT or IMPORT commands, you must provide a valid username and password to successfully execute the commands.

The PERSON entity-occurrence must be defined at the import destinationDatadictionary site and must have authority to retreive, add, and updateDatadictionary definitions.

If security is in effect at the destination site, the accessor ID you use must haveauthority to create SQL objects. See the person responsible for security at thedestination site.

To transport Datadictionary definitions, execute the following commands:

■ The EXPORT commands extract the requested objects from the sourceenvironment and DDTRSLM saves the information in a transport file. Thefile can be on disk or tape as specified in the JCL with the DD name ofTRANSF.

DDTRSLM uses DSF to read all information from the Datadictionary. Thedata definitions will be read from the PRODuction status version of theoccurrences in the primary Datadictionary and related data may be readfrom the primary DDD-DATABASE database.

■ The IMPORT commands indicate what objects you want added to thedestination CA Datacom environment from the transport file.

The DDTRSLM utility reads the EXPORT commands and uses either DSFcommands or SQL CREATE statements to define the tables, views, andsynonyms for transport to the destination site. The schema authorizationIDs (AUTHIDs), databases, and areas must be present at the destinationsite before you use this utility.

■ The SET commands specify information used in processing of the EXPORTand IMPORT commands. See the sections beginning with “SET USER -Establishing User Identification” on page 185 for details.

SET USER (Required) Identifies the Datadictionary PERSONentity-occurrence of the person transporting the data. It mustbe the first command entered in the input job stream or youwill receive a syntax error.

SET EXPORT FORMAT PREVIOUS RELEASE(Optional) Enter this command prior to the EXPORTcommands to export Datadictionary definitions and convertthem to the format of the previous release. These definitionsare then available to import into a system at the previous


How It Works

release level. For more information about using this optionalcommand, see “SET EXPORT FORMAT PREV RELEASE -Convert Format” on page 186.

SET IMPORT COLLISION(Optional) Enter this command prior to the IMPORTcommands to indicate how to resolve adding duplicates of theentity-occurrence definition. For more information, see “SETIMPORT COLLISION - Handling Duplicates” on page 187.

SET TRACE (Optional) Only use this command if it is requested byTechnical Support. For more information, see “SET TRACE- Debugging the Utility” on page 188.




DDTRSLM only transports PRODuction status entity-occurrences for the validentity-types. This section details the restrictions governing transportingdefinitions and what you need to do to ensure a successful transport.

The following includes the task and an explanation of the restriction orconsideration

Transporting support data (aliases, descriptors, and text)Use the DDBTGLM and DDUPDATE utilities, not the DDTRSLM utility.

Transporting non-CA Datacom model entitiesUse the DDBTGLM and DDUPDATE utilities, not the DDTRSLM utility.

Transporting a planUse the DDTRSLM utility to transport a plan with associated SQL objectsor individual SQL objects in SQL source form. These are theDatadictionary entity-types of TABLE, VIEW, and SYNONYM. Otherrequired entity-occurrences (such as statements, databases, areas,elements, keys, fields, constraints) are also transported but cannot bemoved by themselves.

Move the program's source, object, or executable (load) moduleseparately or by using the CA Ideal Object or Source Transport Utility.

Exporting a programUse the DDTRSLM utility to export all the associated plans of theprogram. When a program is exported, all related programs are alsoexported. Specify the root program Datadictionary entity-occurrence nameand all programs related to the program through the PGM-PGM-CALLrelationship will be exported.

Note: Use the CA Ideal Object Transport Utility (IDUTOTRN) to transportprograms, and use DDTRSLM to transport the corresponding plans. ForDDTRSLM you specify the Datadictionary name of the program with theEXPORT and command. The CA Ideal Object Transport utility uses theUNLOAD and LOAD commands, and the CA Ideal program name is used.If you use CA Ideal Source Transport utility (IDUTSTRN), with theEXPORT and IMPORT commands, do not use DDTRSLM to transport theplans. For more information, see the CA Ideal Batch Utilities.

Importing a tableThe database and area with which the table is associated must alreadyexist and be loaded at the destination site.

Importing tables includes processing that maintains the Datadictionary, theData Definition Directory (DDD), the Schema Information Tables (SIT),and the Directory (CXX). Because of this, we strongly recommend thatyou back up the environment before importing tables, specifically if anycritical table definitions are involved. Also, importing VIEWs or PLANs will



implicitly import dependent tables. Therefore, prior to importing VIEWsand PLANs, back up:

■ The tables in the primary Datadictionary■ The SIT and DDD areas■ The Directory (CXX)■ Any required data in existing copies of the table

If constraints are being imported with the table and the table definition isbeing changed, you may encounter a TABLE NOT LOADED error whenthe constraints are added. If this happens, reload the area and reimportthe table with the ONLY ALL CONSTRAINT option. Also, be sure that noone else is maintaining tables in the same database, since a catalog ofthe database occurs. Partial maintenance to other tables while the importis running could cause verification or catalog errors.

Using SQL DML StatementsThe SQL DML statement syntax is not converted from the current versionto the previous version using the SET EXPORT PREVIOUS RELEASEcommand.

DDTRSLM cannot transport plans or views containing SQL DMLstatements that are only available in the current version to a prior versionenvironment. Therefore, you must change the source SQL statementsand recompile the programs or re-create views in the previous version'senvironment, and do not use DDTRSLM.

Creating namesWhen you create names for an AUTHID, an SQL name, or aDatadictionary entity-occurrence name, the name must conform toDatadictionary naming standards and must avoid the SQL reservedwords. If a name is used that does not adhere to these restrictions, theymust be changed before you perform the EXPORT function.

AUTHID and SQL nameEach SQL object is referenced by its AUTHID and SQL name. TheAUTHID of entity-occurrences cannot be changed from the source tothe destination with this utility, except for PLAN entity-occurrences.Use the NEWAUTHID syntax when importing plans.

Constraint NamesConstraint names remain the same. This restriction includes thosegenerated by default. This could generate a DSF error, SQLNAMEALREADY EXISTS (SAE), when processing the IMPORT command.



Transporting password or lock protected databasesThe DDTRSLM utility will not successfully import password or lockprotected databases. If databases are defined with these options, thecatalog will fail and the system returns a PWR DSF error code. Tosuccessfully import this type of database:

■ Manually catalog the database and reimport the tables with the ONLYALL CONSTRAINT option to complete the import of the tables, or

■ Reset the password and remove the lock options, and then reimportthe table.


Non-SQL Access Considerations

Non-SQL Access Considerations

When using DDTRSLM in a mixed SQL and non-SQL access environment, ifyou are generating the table definitions using either Datadictionary maintenancefacilities or the SQL Data Definition Language (DDL), consider the following:

■ When using SQL DDL to define objects that are going to be accessed byboth SQL and non-SQL programs, use the CA Datacom SQL extensionDATACOM NAME on the CREATE TABLE and CREATE INDEX statementsto provide the DATACOM-NAME attribute values. This assures that theDATACOM NAMEs remain consistent between the exported and importedstructures.

■ If you are using shared key IDs (two or more keys with the same ID), youcannot use DDTRSLM to transport the table definition, because key IDs aregenerated during DDL processing and cannot be the same when imported.In this case, use DDBTGLM to transport your table definition.

■ Unless keys satisfying the requirements of the constraint are alreadypresent, some keys are generated as the result of adding constraints.Non-SQL programs should not use keys generated by constraint definition,because these key names are subject to change when the IMPORTprocess is performed.


How to Use

How to Use

This section outlines how you use the DDTRSLM commands to transportdefinitions from one site to another. For step-by-step procedures abouttransporting these types of definitions, see “Transporting Plans” on page 193and “Transporting Tables, Views, and Synonyms” on page 199.

Note: There are restrictions associated with partitioned tables:

■ Table partitions (PARTITION attribute-value set to P) and their associatedPARTITION-COLUMN-VALUE entity-occurrences cannot be exported. Onlypartitioned tables (PARTITION attribute-value set to Y) can. Use theDDBTGLM and DDUPDATE utilities instead of the DDTRSLM utility fortable partitions and PARTITION-COLUMN-VALUE entity-occurrences.

■ When importing a partitioned table, the partitions with which the partitionedtable is associated must already exist at the destination site.

■ There are no restrictions on exporting or importing plans associated witheither partitioned tables or table partitions.

When importing tables with the REPLACE option specified, any previouslyexisting constraints at the destination site are automatically dropped as the firststep of the import process. After the constraints are dropped, the systemissues an SQL COMMIT statement. Any errors encountered during the rest ofthe import causes the job to stop and leave all the constraints dropped from thetable.

To recover the constraints, reload the backup of the Datadictionary databasetaken prior to the IMPORT and rerun the IMPORT after correcting the errorscausing the problem.

To use DDTRSLM, include the appropriate commands in your batch job streamor SYSIN file. The commands are entered in 80-byte lines and arefixed-blocked format. They can be continued over as many lines as necessary.Continuation is assumed until the utility encounters a semicolon (;). However, aword must not cross over a line boundary. The semicolon at the end of thecommand is required. If it is missing, a syntax error occurs.

You can place comments in the input job stream. Use /* to indicate the startand */ to indicate the end of a comment.

Enter the SET USER command as the first command in the input job stream.This command is required before entering the EXPORT and IMPORTcommands. For more information, see “SET USER - Establishing UserIdentification” on page 185.

Step 1 (Optional): Specify the SET EXPORT FORMAT PREVIOUSRELEASE optional command if you want to export definitions and convert theminto the previous format.


How to Use

Step 2: Specify the EXPORT command with the appropriate entity-types andnames. For more information, see “EXPORT Command” on page 172. OneEXPORT command is required for each basic entity-occurrence you areexporting that is not included indirectly, as the result of exporting anotherentity-occurrence.

Step 3: Submit the DDTRSLM utility. This step produces a transport file,which is in an 80-byte, fixed-blocked record format.

Step 4: Transfer the transport file to the destination site with any file transferutility.

After the transfer, verify that the AUTHIDs, databases, and areas exist and areusable for SQL CREATE TABLES before attempting the import.

Step 5 (Optional, Recommended): If tables are being imported or replaced,back up the Datadictionary environment (including the DATA-DICT, DDD, theDirectory (CXX), and any required data in existing copies of the table) beforeimporting them. For more information, see page 166.

Step 6 (Optional): In the input job stream, before you specify the IMPORTcommand, you can specify the following optional commands:

SET IMPORT MODESET IMPORT COLLISION

IMPORT DIRECTORY TRIAL IMPORT

General descriptions are documented in the previous section, “How It Works”on page 164, and detailed information is available for each command later inthis chapter.

Step 7: After you have verified that the IMPORT commands are accurate,submit DDTRSLM with the IMPORT command specified. For more information,see “IMPORT Command” on page 175.


EXPORT Command

EXPORT Command

The EXPORT command specifies the beginning of the structure. You canspecify only one entity-type in an EXPORT command, but you can includemultiple EXPORT commands in one execution of the utility.

The EXCLUDE and ONLY keywords are followed by one entity-type or aspecific object or occurrence. EXCLUDE and ONLY options can appearmultiple times in the same EXPORT command and apply only to the currentEXPORT command in the input stream. If you specify an object in bothEXCLUDE and ONLY options, the object is not copied to the transport file.

Use the following format to specify the EXPORT function:

��──EXPORT──root-entity-type1──name────────────────────────────────────�

�─ ──┬ ┬───────────────────────────────────────── ───────────────────────�� │ │┌ ┐─────────────────────────────────────── └ ┘ ───� ┴──┬ ┬─ONLY──── ──┬ ┬─ALL──entity-type3── └ ┘─EXCLUDE─ └ ┘ ─entity-type2──name─

EXPORT(Required) Initiates the EXPORT function.

root-entity-type1(Required) The Datadictionary entity-type name of the Datadictionarydefinition or the PROGRAM entity-type that specifies the beginning of thestructure. For example, a table is the root of a structure that includesfields, keys, elements, and dataviews. The PROGRAM entity-typeidentifies all the plans referenced by the program.

Note: You cannot import PROGRAM entity-types with DDTRSLM;however, by exporting a program, the set of plans associated with theprogram is exported. You can import a PLAN entity-type.

Valid Entries: PLANPROCEDUREPROGRAMSYNONYMTABLETRIGGERVIEW


name(Required) The qualified SQL name of the plan, table, view, procedure,trigger, or synonym or the Datadictionary entity-occurrence name of theprogram. The qualified SQL name consists of the AUTHID and the SQLname of the object separated by a period (.) in the format authid.sqlname.


EXPORT Command

Valid Entries: Qualified SQL name of an existing object of theentity-typeDatadictionary entity-occurrence name of a program


ONLY(Optional) Introduces a specific entity-type or entity-occurrence within thestructure that is to be placed in the transport file. If you enter this option,you must specify either ALL entity-occurrences of an entity-type or aspecific entity-occurrence of the entity-type. You can enter as manyONLY options as you need.

By default, all other entity-occurrences in the structure are excluded.

ALL entity-type2(Required) All entity-occurrences of the entity-type within the structure tobe included.

Valid Entries: CONSTRAINTPLANPROCEDURESYNONYMTABLETRIGGERVIEW


entity-type3(Optional) The Datadictionary entity-type within the structure to beincluded.

Valid Entries: PLANPROCEDURESYNONYMTABLETRIGGERVIEW


name(Required) The qualified SQL name of the plan, table, view, procedure,trigger, or synonym. The qualified SQL name consists of the AUTHID andthe SQL name of the object separated by a period (.) in the formatauthid.sqlname.

Valid Entries: Qualified SQL name of an existing object of theentity-type



EXPORT Command

EXCLUDE(Optional) Introduces the entity-type or entity-occurrence within thestructure that is not to be placed in the transport file. If you enter thisoption, you must specify either ALL entity-occurrences of an entity-type ora specific entity-occurrence of the entity-type. You can enter as manyEXCLUDE options as you need.

ALL entity-type2(Optional) All entity-occurrences of the entity-type within thestructure to be excluded.

Note: If you exclude a plan that is the root of the EXPORT, nothingis copied to the transport file.

Valid Entries: CONSTRAINTPLANPROCEDURESYNONYMTABLETRIGGERVIEW


entity-type3(Optional) The Datadictionary entity-type within the structure to beexcluded.

Note: If you exclude a plan that is the root of the EXPORT, nothingis copied to the transport file.

Valid Entries: PLANPROCEDURESYNONYMTABLETRIGGERVIEW


name(Optional) The qualified SQL name of the plan, table, view,procedure, trigger, or synonym. The qualified SQL name consists ofthe AUTHID and the SQL name of the object separated by a period(.) in the format authid.sqlname.




IMPORT Command

IMPORT Command

The IMPORT command indicates the starting point of the structure to beimported. It can be the same as the one exported or a starting point within thestructure.

This section describes how to use the IMPORT command with the optionalcommands which change the result of the import process. As many IMPORTcommands as you need can appear in one execution, with the exception thatthe TRIAL IMPORT and IMPORT commands are mutually exclusive and youmust only submit one of these commands in the same execution.

The following describes how to use some of these optional commands to obtainspecific results. Detailed information about each command is described afterthe syntax diagram.

Importing a Specific Entity-Occurrence

If you specify a specific entity-occurrence, you can use the optional EXCLUDE,ONLY, or REPLACE commands to either:

■ Exclude the dependent entity-occurrences■ Only include a specific entity-occurrence■ Replace the entity-occurrence■ Only include dependent entity-occurrences, or■ Replace dependent entity-occurrences

Excluding Entity-Types or Entity-Occurrences

You can use the EXCLUDE option to exclude all entity-occurrences of aspecific entity-type or to exclude a specific entity-occurrence. If you specify thesame entity-type with both EXCLUDE and ONLY in the same command, theentity-type is not imported.

Importing Plans

Consider the following when using DDTRSLM to import plans. If the plan youare importing is associated with a procedure, be aware that when DDTRSLMimports a plan, part of the process involves a DROP PROCEDURE commandthat deletes the procedure and program associated with that plan.


IMPORT Command

Importing Only Plans

You can import only plan entity-occurrences in various ways by using theIMPORT ALL PLAN or IMPORT PLAN options to:

■ Import all plans in the transport file■ Import all plans in the transport file to a new SQL AUTHID■ Import all plans for rebind■ Import a specific plan to a new SQL AUTHID

Using the ONLY Option

The ONLY option allows import of all the constraints, import of allentity-occurrences of a specific entity-type, or import of a plan to a new SQLAUTHID. If you specify the same entity-type with both EXCLUDE and ONLY inthe same command, the entity-type is not imported.

Using the REPLACE Option

The REPLACE option specifies all the Datadictionary definitions imported withthe IMPORT command to be replaced, all entity-occurrences of a specificentity-type to be replaced, or a specific entity-occurrence to be replaced.

Listing Objects Exported

There is an additional IMPORT command which you can run to list the objectsin the transport file. For more information, see “IMPORT DIRECTORYCommand” on page 182.

Reporting

A report is included in the output of the IMPORT or TRIAL IMPORT commandthat includes a listing of errors, warnings and entity-occurrences (and theirdependencies) that are imported. You are responsible for correcting either theIMPORT or EXPORT commands to resolve any errors reported.

Use the following formats to specify the IMPORT command.


IMPORT Command

Syntax for IMPORT ALL Commands

��──IMPORT──ALL─ ──┬ ┬───────────────────────────────── ─;───────────────�� └ ┘ ─PLAN─ ──┬ ┬ ─NEWAUTHID──sql-authid─ └ ┘─FOR──REBIND───────────

IMPORT(Required) Initiates the IMPORT process. You must enter one of thecommands described below following the IMPORT command.

ALL PLANThis command imports all plans.

One of the following is required:

NEWAUTHID sql-authidSpecify NEWAUTHID and the new sql-authid if you want to importthe plans into a different AUTHID.

Valid Entries: 1 to 18 characters


FOR REBINDThis command rebinds the plans as opposed to importing orprecompiling a program. To use this command, the plans mustalready exist and be marked invalid.

Syntax for IMPORT or TRIAL IMPORT Commands

IMPORT Command (not PLAN entity-type)

��─ ──┬ ┬─────── ─IMPORT──root-entity-type1──name─────────────────────────� └ ┘─TRIAL─

�─ ──┬ ┬───────────────────────────────────── ─;─────────────────────────�� │ │┌ ┐─────────────────────────────────── ├ ┤───� ┴─EXCLUDE─ ──┬ ┬─ALL──entity-type2── │ │└ ┘ ─entity-type3──name─ │ │┌ ┐──────────────────────────────── ├ ┤───� ┴─ONLY─ ──┬ ┬─ALL──entity-type2── ─── │ │└ ┘ ─entity-type3──name─ │ │┌ ┐─────────────────────────────────── └ ┘───� ┴─REPLACE─ ──┬ ┬─ALL──entity-type2── └ ┘ ─entity-type3──name─

IMPORT Command (PLAN entity-type):

��─ ──┬ ┬─────── ─IMPORT──PLAN──name──ONLY────────────────────────────────� └ ┘─TRIAL─

�─ ──┬ ┬─ALL──PLAN──NEWAUTHID──sql-authid── ─;───────────────────────────�� └ ┘─PLAN──name──NEWAUTHID──sql-authid─


IMPORT Command

TRIAL(Optional) Only produces a report. The report displays a list of missingdependencies or conflicts in the data that result from executing theIMPORT command.

The DDTRSLM utility automatically executes the TRIAL option when youexecute the IMPORT command. If there are no missing dependencies orconflicts, the IMPORT is executed. For more information about thisoption, see “TRIAL IMPORT Command” on page 182.

Note: You cannot submit a TRIAL IMPORT command and an IMPORTcommand in the same execution.

IMPORT(Required) Initiates the IMPORT process. You must enter one of thecommands described below following the IMPORT command.

root-entity-type1Specify the Datadictionary entity-type name of the Datadictionary definitionentity-type that specifies the beginning of the structure. For example, aTABLE entity-type is the root of a structure that includes fields, elements,keys, and dataviews.

Valid Entries: PLAN PROCEDURESYNONYM TABLETRIGGER VIEW


nameSpecify the qualified SQL name of the object. The qualified SQL nameconsists of the AUTHID and the SQL name of the object separated by aperiod (.) in the format authid.sqlname.



Following the root-entity-type1 and name, specify one of the following:

EXCLUDEDesignates the entity-type or entity-occurrence within the structurenot to import from the transport file. If you enter this command, youmust specify either ALL entity-occurrences of an entity-type or aspecific entity-occurrence of the entity-type. You can enter as manyEXCLUDE options as you need in the same IMPORT command.

ALL entity-type2Specifies all entity-occurrences of the entity-type within thestructure to import.

Note: If you specify an EXCLUDE option for a plan that is theroot of an entity-occurrence, nothing is imported from thetransport file.


IMPORT Command

Valid Entries: PLAN PROCEDURESYNONYM TABLETRIGGER VIEWCONSTRAINT


entity-type3The Datadictionary entity-type within the structure to exclude.Follow entity-type3 with the name, see the following:



nameThe qualified SQL name of the plan, table, view, procedure,trigger, or synonym. The qualified SQL name consists of theAUTHID and the SQL name of the object separated by aperiod (.) in the format authid.sqlname.

Valid Entries: Qualified SQL name of an existing object ofthe entity-type


ONLYDesignates a specific entity-type or entity-occurrence within thestructure to import from the transport file.

You can enter as many ONLY options as you need in the sameIMPORT command. By default, all other entity-occurrences in thestructure are excluded.

If you enter this command, you must specify one of the following:

ALL entity-type2(Required) Specifies all entity-occurrences of the entity-typewithin the structure to import.

Note: If you specify an ONLY option for a plan that is the rootentity-occurrence, nothing is imported from the transport file.

Valid Entries: PLAN PROCEDURESYNONYM TABLETRIGGER VIEWCONSTRAINT



IMPORT Command

entity-type3Specifies the Datadictionary entity-type within the structure toinclude. This entry must be followed by the name, see below.



nameThe qualified SQL name of the plan, table, view or synonym.The qualified SQL name consists of the AUTHID and the SQLname of the object separated by a period (.) in the formatauthid.sqlname.

Valid Entries: Qualified SQL name of an existing object ofthe entity-type


REPLACEDesignates the entity-occurrences in the transport file that replace thesame entity-occurrences at the destination site. You can enter as manyREPLACE options as you need in the same IMPORT command. TheREPLACE option of the IMPORT command overrides the REPLACEoption of SET IMPORT COLLISION. For more information, see “SETIMPORT COLLISION - Handling Duplicates” on page 187.

Note: If you are importing a TABLE entity-occurrence with this optionand you are using the optional command, SET IMPORT MODE SQL, theentity-occurrence will be deleted with an SQL DROP TABLE commandand then added. The SQL DROP TABLE command deletes any data inthe table. Therefore, you should extract the data by using the DBUTLTYEXTRACT function prior to using this option if you want to retain the data.

If you specify the REPLACE command, it must be followed by one of thefollowing:

ALL entity-type2Specifies all the Datadictionary entity-occurrences of the specifiedentity-type to replace.

Valid Entries: CONSTRAINTPLAN PROCEDURESYNONYM TABLETRIGGER VIEW



IMPORT Command

entity-type3Specifies the Datadictionary entity-type within the structure toreplace. This entry must be followed by the name, see below.



nameSpecifies the qualified SQL name of the plan, table, view, procedure,trigger, or synonym. The qualified SQL name consists of theAUTHID and the SQL name of the object separated by a period (.)in the format authid.sqlname.



PLAN name ONLYSpecify this command and include the qualified SQL plan name when youwant to import a specific plan. The qualified SQL name consists of theAUTHID and the SQL name of the plan separated by a period (.) in theformat authid.sqlname.

Valid Entries: Qualified SQL name of an existing plan


Follow this command with one of the following:

ALL PLAN NEWAUTHID sql-authidSpecify the new sql-authid if you want to import a specific plan into adifferent AUTHID.



OR

PLAN name NEWAUTHID sql-authidSpecify the plan name and the new sql-authid if you want to importa specific plan into a different AUTHID.

For name, specify the qualified SQL name used in PLAN nameONLY.



For sql-authid, specify the new sql-authid.



IMPORT Command


IMPORT DIRECTORY Command

You can use the DIRECTORY option of the IMPORT command to create a listof the objects in the transport file created by the EXPORT command. Thiscommand does not import any data.

By checking the list of objects before submitting the IMPORT command, youcan decide whether to submit a TRIAL IMPORT command, or submit theIMPORT command.

For complete syntax information about the IMPORT command, see page 176.Use the following format to specify the IMPORT DIRECTORY command:

��──IMPORT─ ──DIRECTORY; ───────────────────────────────────────────────��

IMPORT DIRECTORY;Creates a list of the objects in the transport file created by the EXPORTcommand.

Note: You cannot submit an IMPORT DIRECTORY command and anIMPORT command in the same execution.

TRIAL IMPORT Command

The TRIAL IMPORT command checks the target Datadictionary to determine ifthere are any conflicts or missing dependencies based on the transport file andthe IMPORT commands. It must include the same specifications as theIMPORT command to provide a proper simulation. The command also checksthe syntax of the IMPORT command.

The main objective of this command is to determine whether the Datadictionaryentity-occurrences that are required by the imported entity-occurrences exist inthe new environment. It also identifies if any entity-occurrences beingtransported already exist at the destination site. If entity-occurrences alreadyexist, you can include REPLACE or EXCLUDE options in the IMPORTcommand or use the SET IMPORT COLLISION command. For moreinformation, see “SET IMPORT COLLISION - Handling Duplicates” onpage 187.

The TRIAL IMPORT command also detects an entity-occurrence or structurethat is not in the transport file. This includes substructures and rootentity-occurrences. If you export a view, it would not be appropriate to import aprogram, but it would be possible to only import its base table.

Dependencies Checked: The dependent objects checked by TRIALIMPORT vary based on the entity-type being transported. These dependenciesappear in the transport file as a list containing their SQL qualified name(authid.sqlname) followed by an indicator (Y or N) to signify whether the


IMPORT Command

dependency is in the transport file. The dependencies are checked in the inputstream and in the destination Datadictionary.

If the dependency is: Then:

In the transport file DDTRSLM checks it against the Datadictionary to ensurethere are no conflicts.

If the entity-occurrence does not exist in the destinationDatadictionary, it is to be imported. If it does exist in thedestination Datadictionary, a conflict error is issuedunless the occurrence is specified in the IMPORTREPLACE option or the optional SET IMPORTCOLLISION REPLACE command is specified.

Not in the transport fileIt must exist in the destination Datadictionary before theIMPORT command is executed. The DDTRSLM utilitychecks the Datadictionary for the dependency.

Not in the Datadictionary or the transport fileDDTRSLM returns an error indicating the dependencydoes not exist at the destination and does not appear inthe transport file.

The only exceptions are AUTHID for all SQL objects andthe parent areas for tables, which must already be at thedestination site before you execute the IMPORTcommand.

The following are dependencies by entity-type:

Entity-type Dependency

PLAN AUTHIDTABLE, VIEW, and SYNONYM entity-occurrences

PROCEDURE AUTHIDPLAN, PROGRAM, STATEMENT, and TABLE entity-occurrences

SYNONYM AUTHIDTABLE or VIEW entity-occurrence

TABLE AUTHIDDATABASE entity-occurrenceAREA entity-occurrenceTRIGGER entity-occurrencereferenced TABLE occurrences

TRIGGER AUTHIDSTATEMENT and TABLE entity-occurrences

VIEW AUTHIDVIEW entity-occurrencesTABLE entity-occurrencesSYNONYM entity-occurrences


IMPORT Command

Report Produced

A report is produced as a result of coding the TRIAL IMPORT command whichincludes a listing of errors, warnings and entity-occurrences (and theirdependencies) that will be imported for every entity-occurrence requested. Youare responsible for correcting either the IMPORT or EXPORT commands toresolve any errors reported.


SET USER - Establishing User Identification

SET USER - Establishing User Identification

The SET USER command identifies the Datadictionary PERSONentity-occurrence of the user. This is required and must be the first commandentered in the input stream.

Define the PERSON entity-occurrence at the destination Datadictionary site andauthorize the user to add and update Datadictionary definitions.

If security is in effect at the destination site, the user must also have authorityto create SQL objects. See the person responsible for Datadictionary and CADatacom/DB security at the destination site.

Use the following format to specify the SET USER function.

��──SET──USER──user-name─ ──pass-word; ─────────────────────────────────��

user-nameThe PERSON entity-occurrence name for the user defined inDatadictionary at the site where the utility is executed.

pass-word;The password assigned to the PERSON entity-occurrence. Leave thisoption blank if a password was not specified for this PERSONentity-occurrence in the Datadictionary where you are executing the utility.


SET EXPORT FORMAT PREV RELEASE - Convert Format

SET EXPORT FORMAT PREV RELEASE - Convert Format

This command converts any new or changed attribute definitions from thecurrent release format into the previous release format. Include this optionalcommand prior to the EXPORT commands.

Optional Command Prior to EXPORT Commands

��──SET──EXPORT──FORMAT──PREVIOUS──RELEASE──;─────────────────────────��

DDTRSLM cannot transport plans or views containing SQL DML statementsthat are only available in the current release. Therefore, if the SQL DMLsyntax is used in the data being imported, you cannot use this command toconvert them from the current release to the previous release. You mustchange the source SQL statements and recompile your programs or re-createthe views in the previous release environment, and not use DDTRSLM.


SET IMPORT COLLISION - Handling Duplicates

SET IMPORT COLLISION - Handling Duplicates

You can specify the optional SET IMPORT COLLISION command prior toIMPORT commands to indicate how to resolve adding duplicates of the sameentity-occurrence definition. You must specify one of the options, QUIT orREPLACE, if you use this command.

If you do not use this command or do not use the REPLACE option on theindividual IMPORT commands (see “IMPORT Command” on page 175), theutility stops processing if the IMPORT command adds a duplicateentity-occurrence. This produces the same result as the QUIT option.

This command affects all IMPORT commands in the input job stream. It can beentered only once in the same input job stream.

┌ ┐─QUIT────��──SET──IMPORT──COLLISION─ ──┼ ┼─REPLACE─ ─;────────────────────────────�� └ ┘─SKIP────

QUIT Processing stops when a duplicate entity-occurrence isencountered. QUIT is the default.

REPLACE Duplicate entity-occurrences at the destination are deleted and thetransported definitions are added. REPLACE options in anIMPORT command take precedence over this command. (See“IMPORT Command” on page 175.)

Note: If you are importing a TABLE entity-occurrence with thiscommand and you have coded the SET IMPORT MODE SQLoption, the entity-occurrence will be deleted with an SQL DROPTABLE command and then added. The DROP TABLE commanddeletes any data in the table. Therefore, you should extract thedata by using the DBUTLTY EXTRACT function prior to using thisoption if you want to retain the data.

SKIP Do no processing of the current entity-occurrence being importedand read the next entity-occurrence from the import file.


SET TRACE - Debugging the Utility

SET TRACE - Debugging the Utility

If instructed by Technical Support, you can use the optional SET TRACEcommand to produce problem determination information intermixed with therequested data in the transport file.

This command prints internal information which Technical Support uses toassist you with a problem.

��──SET──TRACE─ ──┬ ┬─ON───── ─;─────────────────────────────────────────�� ├ ┤─OFF──── ├ ┤─ALL──── └ ┘─DETAIL─

ONPerforms basic traces.

OFFTurns off all previously coded traces.

ALLTurns on all traces except for OFF.

DETAILProvides more detail than TRACE ON.


Sample Job Streams and Input



z/OS Example JCL


//jobname See the note above and page 19. // EXEC PGM=DDTRSLM,REGION=124K //STEPLIB See the note above and page 19. //TRANSF DD DSN=xx.xx.xx,DISP=(OLD,KEEP,KEEP), Transport file // DCB=(LRECL=8,BLKSIZE=8,RECFM=FB) Must be 8-byte fixed records//SYSOUT DD SYSOUT= //SYSPRINT DD SYSOUT= //SYSPUNCH DD SYSOUT= //SYSUDUMP DD SYSOUT= //SYSIN DD SET USER DEMOADM; Authorized user identification

. Place your input commands here.

. See the following pages for . examples.

z/VSE Example JCL


Disk Usage: $$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // DLBL TRANSF,...,SD Transfer file // EXTENT ,volser // EXEC DDTRSLM,SIZE=5K SET USER DEMOADM PASSWORD; Authorized user identification


. See the following pages for . examples. / /& $$ EOJ



Tape Usage: $$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // ASSGN SYS1,cuu Specify tape drive address // TLBL TRANSF,'dataset.name' See note below // EXEC DDTRSLM,SIZE=5K SET USER DEMOADM PASSWORD; Authorized user identification


. See the following pages for . examples. / /& $$ EOJ

Note: If you are a CA-DYNAM/T user, use the following TLBL for the IMPORTfunction of DDTRSLM:

// TLBL TRANSF,'dataset.name,S:1'

This will be in addition to having SYS010 assigned to a tape drive.


Exporting Programs

Exporting Programs

You can use the DDTRSLM utility to export PROGRAM entity-types. Theexported file includes PLAN, STATEMENT, SYNONYM, TABLE, and VIEWentity-occurrences used by the program. The TABLE entity-occurrencesinclude all entity-occurrence dependencies.

PROGRAM entity-types cannot be imported with this utility. Use the CAIdeal Object Transport Utility (IDUTOTRN) to transport the executable program.The CA Ideal Source Transport Utility (IDUTSTRN) transports the externalsource code. For more information about these utilities, see the CA Ideal BatchUtilities Guide.

Once the program is exported, the entity-occurrences associated with theprogram can be imported. See the following sections in this chapter totransport these entity-occurrences.

Procedure

This section is a step-by-step procedure which describes how to exportprograms.

Step 1: Run DDTRSLM with the EXPORT command to extract the PROGRAMentity-occurrence from the source environment. The EXCLUDE and ONLYoptions are not available for PROGRAM entity-types.

When the job completes, all the entity-occurrences which the PROGRAM useswill also be extracted.

Step 2: You can import the PLAN, PROCEDURE, STATEMENT, SYNONYM,TABLE, TRIGGER, and VIEW entity-occurrences exported with the program atthis point.

More Information

■ For more information about transporting PLAN entity-occurrences, see“Transporting Plans” on page 193.

■ For more information about transporting these entity-occurrences., see“Transporting Tables, Views, and Synonyms” on page 199.


Exporting Programs

Examples

This section illustrates executing DDTRSLM with the EXPORT command toextract a specific PROGRAM entity-occurrence from the source environmentand produce a transport file.

Example EXPORT Command: The following illustrates an example ofexecuting DDTRSLM with the EXPORT command to export a program:

EXPORT PROGRAM program-name

The transport file includes the PARAMETER-LIST, PLAN, PROCEDURE,STATEMENT, SYNONYM, TABLE, TRIGGER, and VIEW entity-occurrencesassociated with the program. See “Example Transport File for a Plan” onpage 194.


Transporting Plans

Transporting Plans

Transporting plans produces a transport file which includes all relateddependencies to the statements within the plan transported.

Procedure

This section is a step-by-step procedure which describes how to transportplans.

Step 1: Verify that the PLAN is executable. If the Datadictionary PLANattribute PLN-VALID does not equal Y, the PLAN may still be exported if alldependencies exist. Exporting invalid plans and reimporting them with the FORREBIND option provides a batch method for rebinding all the plans.

You may not want to transport invalid PLAN entity-occurrences to anotherenvironment since the programs may not execute at the destination.

Step 2: Obtain an Impact Analysis Report (for SQL Processing) usingDDUPDATE or DDUTLTY to see what objects are referenced by the plan youare transporting (see “Impact Analysis Report” on page 518).

Alternatively, you can run the IMPORT DIRECTORY command after you havesubmitted the EXPORT command (see “IMPORT DIRECTORY Command” onpage 182). See the following sample path definition for building the ImpactAnalysis Report.

-DEF PATH,TRANS -DEF TRACE,PLAN.STATEMENT.PLN-STM-CONTAIN -DEF TRACE,STATEMENT.TABLE,STM-TBL-DEPENDS -DEF TRACE,STATEMENT.VIEW,STM-VEW-DEPENDS -DEF TRACE,VIEW.TABLE,VEW-TBL-DEPENDS -DEF TRACE,VIEW.VIEW,VEW-VEW-DEPENDS -DEF TRACE,VIEW.SYNONYM,VEW-SYN-DEPENDS -DEF TRACE,SYNONYM.TABLE,SYN-TBL-REFERS -DEF TRACE,SYNONYM.VIEW,SYN-VEW-REFERS -DEF TRACE,VIEW.TABLE,VEW-TBL-DEPENDS -DEF TRACE,VIEW.VIEW,VEW-VEW-DEPENDS -DEF TRACE,VIEW.SYNONYM,VEW-SYN-DEPENDS -DEF TRACE,SYNONYM.TABLE,SYN-TBL-REFERS -DEF TRACE,SYNONYM.VIEW,SYN-VEW-REFERS -END

Step 3: Run DDTRSLM with the EXPORT command to extract the PLANobjects from the source environment.

When the job completes, all the SQL objects on which the PLAN is dependentwill also be extracted. Included are tables, views, statements, and synonyms.Also, the objects on which the views and synonyms are dependent will beextracted, to the base table level. All information associated with the table


Transporting Plans

occurrences will be exported for any tables exported as dependencies of theplan.

Note: You can choose to exclude some or all of the dependencies. Use theEXCLUDE clause or the ONLY clause on the EXPORT command.

Step 4: If the PLAN is being imported and you are also importing the tables,follow the instructions for transporting tables Steps 2 through 6 in “TransportingTables, Views, and Synonyms” on page 199.

Step 5: Transfer the resulting EXPORT file with any file transfer utility to thedestination site.

If the destination is another platform, ensure that the utility you use to downloadthe transport file translates EBCDIC to ASCII and converts binary zeros toblanks.

Step 6: Run DDTRSLM with the IMPORT command for those plans you wantto add to the destination site.

Examples

This section shows an example of executing DDTRSLM with the EXPORT andIMPORT commands to transport a plan.

Example EXPORT Command: The following is an example of using anEXPORT command to extract the TESTPLAN object from the source site:

EXPORT PLAN SYSADM.TESTPLAN;

The transport file includes the statements in the plan and all tables, procedures,triggers, synonyms, and views used by the statements in the plan.

Note: An alternate example to export only the plan and none of thedependencies is: EXPORT PLAN planname ONLY ALL PLAN; Only the planoccurences will appear in the transport file, the dependencies will appear onlyin the directory at the top of the file.

Example IMPORT Command: The following is an example of using theIMPORT command to indicate that the TESTPLAN object is to be added to thedestination site:

IMPORT PLAN SYSADM.TESTPLAN;

Note: An alternate example to import plans from the transport file is: IMPORTALL PLAN; This results in each plan in the transport file being imported withoutany dependencies that may appear in the file.

Example Transport File for a Plan: The following is an example of thetransport file generated by the EXPORT command used in the previousexample:


Transporting Plans

TRANSPORT UTILITY RELEASE 12. DD 12. DB 12.M FILE FORMAT 12. DATE 8/25/8 TIME 16.49.48 %%DIRECTORY %%DATABASE .CASQLDEFAULT Y %%AREA .CASQLDEFAULT Y %DEPSTART .CASQLDEFAULT DATABASE Y %DEPEND %%TABLE DEMOADM.DDAPTBL2 Y %DEPSTART .CASQLDEFAULT AREA Y %DEPEND %%PLAN SYSADM .TESTPLAN Y %DEPSTART DEMOADM .DDAPTBL2 TABLE Y %DEPEND %%ENDDIRECTORY %%DATABASE .CASQLDEFAULT %DDSUPSTART DESCRIPTION DEFAULT DATABASE FOR SQL DEMONSTRATIONS DATACOM-ID 16 DBMS-USED DATACOM SQL-SECURITY N %DDSUPEND %%END %%AREA .CASQLDEFAULT %DDSUPSTART DESCRIPTION DEFAULT AREA FOR SQL DEMONSTRATIONS SQLNAME CASQLDEFAULT DATACOM-NAME SQ1 BLOCK-SIZE 496 DBMS-USED DATACOM SPACE-MNGMNT 1 %DDSUPEND %%END %%TABLE DEMOADM.DDAPTBL2 %DDLSTART CREATE TABLE DEMOADM.DDAPTBL2 ( FIELD1 CHARACTER (2) NOT NULL , FIELD2 CHARACTER (1) ,FIELD3 DATE , UNIQUE (FIELD1) CONSTRAINT CONSTRAINT_8) IN CASQLDEFAULT DATACOM NAME B31; %DDLEND %DDSUPSTART ENTITY-NAME DEMOADM-DDAPTBL2 AUTHID DEMOADM SQLNAME DDAPTBL2 DBMS-USED DATACOM SQL-INTENT Y DATACOM-NAME B31 DATACOM-ID 231 DUPE-MASTER-KEY Y CHNG-MASTER-KEY Y %DDSUPEND %%FIELD FIELD1 %DDSUPSTART JUSTIFICATION L


Transporting Plans

TYPE C CLASS S SIGN N LENGTH 2 REPEAT 1 TYPE-NUMERIC C LEVEL 1 PARENT START AFTER START REDEFINES N SQLNAME FIELD1 NULL-INDICATOR N DEFAULT-INSERT N DBEDITS Y FORCEADD N FORCEUPD N UNCHANGEABLE N %DDSUPEND %%FIELD FIELD2 %DDSUPSTART JUSTIFICATION L TYPE C CLASS S SIGN N LENGTH 1 REPEAT 1 TYPE-NUMERIC C LEVEL 1 PARENT START AFTER FIELD1 REDEFINES N SQLNAME FIELD2 NULL-INDICATOR Y DEFAULT-INSERT N DBEDITS Y FORCEADD N FORCEUPD N UNCHANGEABLE N %DDSUPEND %%FIELD FIELD3 %DDSUPSTART JUSTIFICATION R TYPE B CLASS S SIGN N LENGTH 4 REPEAT 1 TYPE-NUMERIC C LEVEL 1 PARENT START AFTER FIELD2 REDEFINES N SEMANTIC-TYPE SQL-DATE SQLNAME FIELD3 NULL-INDICATOR Y DEFAULT-INSERT N DBEDITS Y FORCEADD N FORCEUPD N


Transporting Plans

UNCHANGEABLE N %DDSUPEND %%KEY SQ26 %DDSUPSTART RECORD-NAME DEMOADM-DDAPTBL2 SQLNAME SQ26_16 DATACOM-NAME SQ26 INCLUDE-NIL-KEY Y MASTER-KEY Y NATIVE-KEY Y UNIQUE Y FOREIGN N DATACOM-ID 26 DIRECT N %DDSUPEND %FIELDLIST FIELD1 N/A N/A A N %FIELDEND %%ELEMENT SQLEL %DDSUPSTART DATACOM-NAME SQLEL LENGTH 36 FIRST-FIELD FIELD1 LAST-FIELD FIELD3 %DDSUPEND %%END %%PLAN SYSADM .TESTPLAN %DDSUPSTART PLN-CBSIO PLN-PRTY 7 PLN-MIN PLN-SEC PLN-CLOSE R PLN-ISOLATION U PLN-COMPAT DATACOM PGM-IS-PROC N PROGRAM TESTPLAN MESSAGE JOIN-OVERRIDE P WORKSPACE TIMEFORM 1 DATEFORM 1 DECPOINT P STRINGDELIM A %DDSUPEND %STMTSTART TIMESTAMP = 7349877 STMTID = 1. DECLARE PEOPLE CURSOR FOR SELECT FLD2 , FLD3 FROM DEMOADM-DDAPTBL2 ; %STMTSTART TIMESTAMP = 7349877 STMTID = 1. OPEN PEOPLE ; %STMTSQLDA HOSTVARS %STMTEND %STMTSTART TIMESTAMP = 7349877 STMTID = 1. CLOSE PEOPLE ; %STMTSQLDA HOSTVARS


Transporting Plans

%STMTEND %STMTSTART TIMESTAMP = 7349877 STMTID = 1. FETCH PEOPLE INTO :FLD1 , :FLD2 ; %%END


Transporting Tables, Views, and Synonyms


A TABLE, VIEW, or SYNONYM entity-occurrence can be transportedindividually.

■ Transporting a table copies the table and its dependencies (elements, keys,fields, triggers, and constraints).

■ Transporting a synonym copies the synonym and the object (withdependencies) it references.

■ Transporting a view copies the view and all tables, synonyms, and viewsreferenced by the view (all with dependencies), either directly or indirectly.

The area and database for transported tables must already exist at thedestination site.

Procedure

This section is a step-by-step procedure which describes how to transporttables, views, and synonyms.

Step 1: Ensure that the version of the database you are transporting is inPRODuction status and that all the tables you are transporting have validAUTHIDs and SQLNAMEs.

Step 2: Run DDBTGLM on the database definition.

Step 3: Run DDTRSLM with an EXPORT command for each table in thedatabase. It is not necessary to migrate non-SQL tables or tables that do nothave constraints with DDTRSLM. The DDBTGLM output should be sufficient.

Transfer the result of the EXPORT with any file transfer utility to the destinationsite.

Step 4 (Optional, Recommended): Back up the destination site'sDatadictionary, including the DATA-DICT, DDD, Directory (CXX), and anyrequired data in existing copies of the table.

Step 5: Ensure that you are authorized to create SQL objects at thedestination site and that databases, areas, and AUTHIDs exist at thedestination.

■ If the AUTHIDs do not exist, then execute the SQL CREATE SCHEMAAUTHORIZATION statements to create them.

■ If the areas are missing from the destination, add them using theDDBTGLM output from Step 2 as input to DDUPDATE.

Note: Each area's SQLNAME must be the same as the one on the sourcesite to process the import of the table correctly.



Substep 1 Copy the database to PRODuction status.

Substep 2 Catalog the database.

Substep 3 Run DBUTLTY to INIT and LOAD the areas (NULL load if none ofthe tables in the -BTG transactions had any data).

Step 6: Run DDTRSLM with an IMPORT command for each of the tables youare transporting.

Examples

This section shows an example of executing DDTRSLM with EXPORT andIMPORT commands to transport a table.

Example EXPORT Command

The following is an example of using an EXPORT command to extract theTESTTBL object from the source site. In this example, the table TESTTBL hasan AUTHID of DEMOADM.

EXPORT TABLE DEMOADM.TESTTBL;

Example IMPORT Command

The following is an example of using an IMPORT command to indicate that theTESTTBL object is to be added to the destination site.

IMPORT TABLE DEMOADM.TESTTBL;



Example Transport File for a Table

The following is an example of the transport file generated by the EXPORTcommand in the example on “Example EXPORT Command” on page 200:

TRANSPORT UTILITY RELEASE 12. DD 12. DB 12.M FILE FORMAT 12. DATE 8/25/8 TIME 14.3.54 %%DIRECTORY %%DATABASE .ORDER-ENTRY Y %%AREA .ACCTS Y %DEPSTART .ORDER-ENTRY DATABASE Y %DEPEND %%ENDDIRECTORY %%DATABASE .ORDER-ENTRY %DDSUPSTART AUTHOR DEMO-ADMIN DATACOM-ID 1 BASE-TYPE RELATION DBMS-USED DATACOM SQL-SECURITY N DL1T-CONSTRAINT N %DDSUPEND %%END %%AREA .ACCTS %DDSUPSTART AUTHOR DEMO-ADMIN SQLNAME ACCTS DATACOM-NAME ACT BLOCK-SIZE 496 SLACK 5 RPS Y DBMS-USED DATACOM SPACE-MNGMNT 1 DATA-SET-NAME DEVICE 338 %DDSUPEND %%END %%TABLE SYSADM .ACCTS %DDLSTART CREATE TABLE SYSADM.ACCTS ( ORD_ID NUMERIC (5) NOT NULL , BILL_YR CHARACTER (2) NOT NULL , BILL_MO CHARACTER (2) NOT NULL , BILL_DAY CHARACTER (2) NOT NULL , ORD_AMT DECIMAL (9,2) NOT NULL , FRT_AMT DECIMAL (9,2) NOT NULL , DISC_AMT DECIMAL (9,2) NOT NULL , IND_CD CHARACTER (1) NOT NULL , CUST_NO CHARACTER (4) NOT NULL ) IN ACCTS DATACOM NAME ACT; CREATE INDEX ACSTI_1 ON SYSADM.ACCTS ( IND_CD, CUST_NO) DATACOM NAME ACSTI; CREATE INDEX ACTOR_1 ON SYSADM.ACCTS ( ORD_ID) DATACOM NAME ACTOR;



CREATE INDEX SQ5_1 ON SYSADM.ACCTS ( ORD_ID) DATACOM NAME SQ5; %DDLEND %DDSUPSTART ENTITY-NAME SYSADM-ACCTS AUTHID SYSADM SQLNAME ACCTS DBMS-USED DATACOM SQL-INTENT Y DATACOM-NAME ACT DATACOM-ID 169 DUPE-MASTER-KEY Y CHNG-MASTER-KEY Y COMPRESSION N LOGGING Y RECOVERY Y PIPELINE-OPTION Y DB-MASTER-KEY SQ5 DB-NATIVE-KEY SQ5 %DDSUPEND %%FIELD ORD_ID %DDSUPSTART JUSTIFICATION R TYPE N CLASS S SIGN Y LENGTH 5 REPEAT 1 TYPE-NUMERIC C LEVEL 1 PARENT START AFTER START REDEFINES N SQLNAME ORD_ID NULL-INDICATOR N BLANK-WHEN-ZERO N STORAGE A VARYING N DEFAULT-INSERT N DBEDITS Y FORCEADD N FORCEUPD N UNCHANGEABLE N %DDSUPEND %%FIELD BILL_YR %DDSUPSTART JUSTIFICATION L TYPE C CLASS S SIGN N LENGTH 2 REPEAT 1 TYPE-NUMERIC C LEVEL 1 PARENT START AFTER ORD_ID REDEFINES N SQLNAME BILL_YR



NULL-INDICATOR N BLANK-WHEN-ZERO N STORAGE A VARYING N DEFAULT-INSERT N DBEDITS Y FORCEADD N FORCEUPD N UNCHANGEABLE N %DDSUPEND %%FIELD BILL_MO %DDSUPSTART . . . %%KEY ACSTI %DDSUPSTART RECORD-NAME SYSADM-ACCTS SQLNAME ACSTI_1 DATACOM-NAME ACSTI INCLUDE-NIL-KEY Y MASTER-KEY N NATIVE-KEY N UNIQUE N FOREIGN N DATACOM-ID 6 DIRECT N %DDSUPEND %FIELDLIST IND_CD N/A N/A A N CUST_NO N/A N/A A N %FIELDEND %%KEY ACTO %DDSUPSTART RECORD-NAME SYSADM-ACCTS SQLNAME ACTOR_1 DATACOM-NAME ACTOR INCLUDE-NIL-KEY Y MASTER-KEY N NATIVE-KEY N UNIQUE N FOREIGN N DATACOM-ID 12 DIRECT N %DDSUPEND %FIELDLIST ORD_ID N/A N/A A N %FIELDEND %%KEY SQ5 %DDSUPSTART RECORD-NAME SYSADM-ACCTS SQLNAME SQ5_1 DATACOM-NAME SQ5 INCLUDE-NIL-KEY Y MASTER-KEY Y NATIVE-KEY Y UNIQUE N FOREIGN N DATACOM-ID 5



DIRECT N %DDSUPEND %FIELDLIST ORD_ID N/A N/A A N %FIELDEND %%ELEMENT SQLEL %DDSUPSTART DATACOM-NAME SQLEL LENGTH 31 FIRST-FIELD ORD_ID LAST-FIELD CUST_NO %DDSUPEND %%END


Chapter 8. DDUPDATE - UpdatingDatadictionary


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211-AUXIN Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

z/OS Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212z/VSE Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Processing -GRP Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 213Updating the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Generating DDUPDATE Transactions Using DDICF . . . . . . . . . . . . 215Processing -BTG Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Special Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Automatically Generated Reports . . . . . . . . . . . . . . . . . . . . . 219Requested Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220


Header Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Using the -ADD Header Transaction . . . . . . . . . . . . . . . . . . . 224Using the -CPY Header Transaction . . . . . . . . . . . . . . . . . . . 226Using the -DEL Header Transaction . . . . . . . . . . . . . . . . . . . 228Using the -UPD Header Transaction . . . . . . . . . . . . . . . . . . . 230Using the -UPG Header Transaction . . . . . . . . . . . . . . . . . . . 233Using the -GRP Header Transaction . . . . . . . . . . . . . . . . . . . 234-GRP END Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Using the Maintenance Transactions . . . . . . . . . . . . . . . . . . . . . 237Maintaining Support Data . . . . . . . . . . . . . . . . . . . . . . . . . . 237Maintaining the CA Datacom/DB and CA FILE Models . . . . . . . . . 238Maintaining Occurrence Attributes . . . . . . . . . . . . . . . . . . . . . 239Returning Attribute Values to Default . . . . . . . . . . . . . . . . . . . 240

1000 ALTER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Example Transaction Collection . . . . . . . . . . . . . . . . . . . . . . 242Relevant Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

1000 APPLY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2461000 CATALOG Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2481000 CONNECT Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2491000 DISABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2501000 ENABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2511000 MODEL Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Chapter 8. DDUPDATE - Updating Datadictionary 205

1000 NEWNAME Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 255Impact of Changing Names . . . . . . . . . . . . . . . . . . . . . . . . 255Changing Names of Tables Created in SQL . . . . . . . . . . . . . . . 256How To Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

1000 NEWPSWD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 258Assigning a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Changing a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Deleting a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

1000 OBSOLETE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 2601000 RESTORE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 261

How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

1000 SET Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264TABLE Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265KEY Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267ELEMENT Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . 268FIELD Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

1000 TRANSFER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 2701000 VERIFY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Verifying a DATABASE Structure . . . . . . . . . . . . . . . . . . . . . 272Verifying a FILE Structure . . . . . . . . . . . . . . . . . . . . . . . . . 274Verifying a TABLE Structure . . . . . . . . . . . . . . . . . . . . . . . . 275

1001 Author Controller Transaction . . . . . . . . . . . . . . . . . . . . . . 2761002 Description Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2771003 Relationship Transactions . . . . . . . . . . . . . . . . . . . . . . . . 278

1003 RELT Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2781003 UNRL Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2801003 DATA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 2811003 AFTER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 282

1101 Descriptor Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 2841103 Alias Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2861200 TEXT Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

1200 TEXT ADD Transaction . . . . . . . . . . . . . . . . . . . . . . . 2891200 TEXT CLS Transaction . . . . . . . . . . . . . . . . . . . . . . . . 2901200 TEXT DEL Transaction . . . . . . . . . . . . . . . . . . . . . . . . 2941200 TEXT INS Transaction . . . . . . . . . . . . . . . . . . . . . . . . 2951200 TEXT REP Transaction . . . . . . . . . . . . . . . . . . . . . . . 296

1500 Attribute Value Update Transaction . . . . . . . . . . . . . . . . . . . 3002000 Relationship Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 302

Using the -ADD Relationship Transaction . . . . . . . . . . . . . . . . 3022000 Relationship Transaction . . . . . . . . . . . . . . . . . . . . . . . 303

2900 to 2901 DATABASE Transactions . . . . . . . . . . . . . . . . . . . . 3062900 DATABASE Transaction . . . . . . . . . . . . . . . . . . . . . . . 3072901 DATABASE Transaction . . . . . . . . . . . . . . . . . . . . . . . 309

3001 to 3004 AREA Transactions . . . . . . . . . . . . . . . . . . . . . . . 3103001 AREA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3113002 AREA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3113004 AREA Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 313


3120 to 3122 FILE Transactions . . . . . . . . . . . . . . . . . . . . . . . . 3163120 FILE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3173121 FILE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3183122 FILE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

3150 to 3160 TABLE Transactions . . . . . . . . . . . . . . . . . . . . . . . 3213150 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3223151 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3253152 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3263153 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3283160 TABLE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 329

3200 RECORD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3314010 to 4020 FIELD Transactions . . . . . . . . . . . . . . . . . . . . . . . 332

4010 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3344011 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3354012 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3354013 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3394014 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3404015 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3414016 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3424017 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3434018 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3444020 FIELD Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 345

4099 Field Access Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 3485000 to 5100 KEY Transactions . . . . . . . . . . . . . . . . . . . . . . . . 351

5000 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3525010 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3555011 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3565012 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3565100 KEY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

5200 to 5203 PARTITION-COLUMN-VALUE Transactions . . . . . . . . . 3605200 PARTITION-COLUMN-VALUE Transaction . . . . . . . . . . . . 3605203 PARTITION-COLUMN-VALUE Transaction . . . . . . . . . . . . 361

6000 to 6011 ELEMENT Transactions . . . . . . . . . . . . . . . . . . . . 3676000 ELEMENT Transaction . . . . . . . . . . . . . . . . . . . . . . . . 3686010 ELEMENT Transaction . . . . . . . . . . . . . . . . . . . . . . . . 3696011 ELEMENT Transaction . . . . . . . . . . . . . . . . . . . . . . . . 370

6100 LIBRARY Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3726200 MEMBER Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3737011 to 7025 PARTITION-VALUE Transactions . . . . . . . . . . . . . . . 375

7011 to 7015 PARTITION-VALUE Transactions . . . . . . . . . . . . . 3757021 to 7025 PARTITION-VALUE Transactions . . . . . . . . . . . . . 376

7100 PANEL Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3777110 SYSTEM Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3797120 PROGRAM Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 3817130 MODULE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3837140 AUTHORIZATION Transaction . . . . . . . . . . . . . . . . . . . . . . 3857150 to 7156 PERSON Transactions . . . . . . . . . . . . . . . . . . . . . 386

7150 PERSON Job Transaction . . . . . . . . . . . . . . . . . . . . . . 3877155 PERSON Language Transaction . . . . . . . . . . . . . . . . . . 388


7156 PERSON Name Transaction . . . . . . . . . . . . . . . . . . . . 3907160 REPORT Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3917170 JOB Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3937180 STEP Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3957190 DATAVIEW Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 397

7210 NODE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 3987211 NODE Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 398

7999 Application Attribute Transaction . . . . . . . . . . . . . . . . . . . . 4009000 User-Defined Transactions . . . . . . . . . . . . . . . . . . . . . . . . 401

The DDUPDATE Utility provides a batch capability to define occurrences, toperform maintenance on occurrence definitions and to request reports.

This chapter is divided into sections which include:

OverviewA general description of when and how to use the utility, and specificinformation such as using DDICF to generate DDUPDATE transactionsand how DDUPDATE processes -BTG input.

ReportsA description of the types of reports produced automatically andrequested with the -RPT transaction.

Sample Job StreamsAn example of batch job streams and SYSIN files used to execute theutility.

Header TransactionsA description of the header transactions required in a transactioncollection.

Using Maintenance TransactionsA general description of the types of transactions that can be used tomaintain the CA Datacom/DB and CA FILE Model and a list of those thatare used to maintain specific entity-types.

The remainder of the chapter is divided into sections which describe each batchtransaction available with DDUPDATE, and the valid entries and default valuesfor each field in the transaction.


Overview

Overview

This section discusses the general information you need to run the DDUPDATEutility. Included is a section on when and how to use the utility, processing the-GRP transaction, updating the Directory, generating DDUPDATE transactionsusing DDICF, and how DDUPDATE processes -BTG input transactions.

Datadictionary also provides an online method for updating status andperforming maintenance on occurrences. For more information regarding theonline facilities, see the CA Datacom Datadictionary Online Reference Guide.


When to Use

When to Use

Use the DDUPDATE Utility to:

■ Update or copy the occurrence definitions in a TEST status to PRODuctionstatus

■ Update the occurrence definitions in PRODuction status to HISTory status

■ Restore the HISTory status or PRODuction status occurrence definitions toTEST

■ Perform maintenance on occurrence definitions or

■ Request reports.


How to Use

How to Use

To use DDUPDATE, include the appropriate transactions in your batch jobstream or SYSIN file. The first transaction must be the -USR transaction toverify authorization before the utility can execute. For more information, see“Establishing User Identification” on page 20.

You must be authorized by the person at your site responsible for securityadministration to run this utility.

Transaction Collection: Code a header transaction, numbered transactionsand an -END transaction next. For more information, see “Header Transactions”on page 223 and the numbered transactions chapters in this document.

If you do not include a 1001 Author Controller transaction in a collection oftransactions to add an occurrence, the author and controller default to the nameentered in the -USR transaction.

Continuation Capability: When setting up DDUPDATE transactions, you canuse a continuation capability to enter long transactions. Note the followingexample of a continued transaction:

-RPT DETAIL,FIELD,ACCOUNTS-RECEIVABLE. - CUSTOMER-ID-NUMBER(T3,OVRD)

The continuation is specified by a transaction start character (-) followedimmediately by one space.


-AUXIN Transaction

-AUXIN Transaction

You can use the -AUXIN transaction in your job stream to accept inputtransactions from an alternate input source. The job stream goes to end of filewhen these transactions complete. Therefore, the -AUXIN transaction mustappear after any other transactions. A -USR transaction in the auxiliary inputfile is not required since a -USR transaction must appear before all othertransactions.

z/OS Syntax

Use the following format for the -AUXIN transaction:

��──-AUXIN────────────────────────────────────────────────────────────��

For z/OSThe default block size is 4000. You can override this in the JCL. Specifyall other required information in the DDUPDATE JCL.

z/VSE Syntax

Use the following format for the -AUXIN transaction:

-AUXIN Transaction in z/VSE

��──-AUXIN─ ──UNIT=xxxx,BLKSIZE=nnnnn,SYSNUM=nnn ───────────────────────��

UNIT=Enter the unit on which the input file resides.

Valid Entries: TAPEDISK

Default Value: TAPE

BLKSIZE=Enter the block size of the sequential input file. The value must be lessthan or equal to the value of the BLKSIZE parameter for AUXIN in theROSFD macro in module DDVPEFT. For information on the ROSFDmacro, see the CA IPC Implementation Guide.


Default Value: 4000

SYSNUM=Enter logical unit number.


Default Value: 004


Processing -GRP Transactions

Processing -GRP Transactions

The -GRP transaction expedites FIELD occurrence maintenance processing bygrouping the -ADD, -UPD and -DEL FIELD maintenance transactions for agiven TABLE or RECORD substructure. With the -GRP transaction, verificationof FIELD maintenance transactions is done once for the entire group instead ofafter each individual FIELD maintenance transaction. For more information,see “Using the -GRP Header Transaction” on page 234.


Updating the Directory

Updating the Directory

Catalog the changes to a DATABASE structure to CA Datacom/DB using the1000 CATALOG transaction with an -UPD header or by running the DDCFBLDUtility. For more information about that transaction, see “1000 CATALOGTransaction” on page 248. For instructions about running this utility, seeChapter 3, “DDCFBLD - Cataloging Datadictionary Definitions.” You must beauthorized by the person at your site responsible for Datadictionary securityadministration to run this utility.


Note: If you are only updating specific attributes of a DATABASE or AREAoccurrence, you may be able to make these changes using the 1000 ALTERtransaction in DDUPDATE.


Generating DDUPDATE Transactions Using DDICF

Generating DDUPDATE Transactions Using DDICF

You can also generate DDUPDATE transactions by using the DatadictionaryInput Creation Facility (DDICF).

Use the DDICF to use source language statements to generate transactionswith which to populate your Datadictionary. DDICF takes COBOL sourcelanguage copybook statements and generates DDUPDATE transactions for aRECORD structure which you can modify to add a TABLE structure. For moreinformation, see Chapter 4, “DDICF - Generating Input Transactions.”


Processing -BTG Input


When DDUPDATE encounters a -BTG header transaction, the utility treats theentire transaction collection as either an -ADD or -UPD transaction collectiondepending on the entity-type, its status, and whether the entity-occurrencealready exists.

The -BTG transactions should not be used as general purpose -UPD headertransactions.

Other considerations include the following:

■ If a FILE entity-occurrence is not found, and the transaction collectioncontains a 1000 CONNECT transaction, a second try is made to read theoccurrence as a TABLE entity-occurrence.

■ If the -BTG transactions begin with an occurrence that is not the base of thestructure (such as AREA, TABLE, or RECORD), you must add theappropriate 1000 CONNECT transaction.

■ If the target status is PRODuction status, the update is allowed for -BTGtransactions, provided the user ID has authorization to update PRODuctionstatus occurrences.

■ DDUPDATE returns an error and continues processing if there is an attemptto duplicate existing aliases.

Entity Status How DDUPDATE treats -BTG

TABLERECORD

TEST -ADD if entity-occurrence does not exist

-UPD if entity-occurrence exists (TEXT, ifpresent, replaces TEXT for sameclassification)

KEYELEMENT

TEST -ADD if entity-occurrence does not exist

-UPD if entity-occurrence exists (TEXT, ifpresent, replaces TEXT for the sameclassification)

PROD -UPD, not rejected if it contains 5010 and6010 transactions for fields already in thestructure (TEXT, if present, replacesTEXT for the same classification)

Is not TABLERECORDKEYELEMENT

N/A -ADD if the entity-occurrence does notexist

-UPD if the entity-occurrence exists



■ DDUPDATE treats the 1000 CONNECT transaction as a TRANSFERtransaction if the occurrence already exists.

■ DDBTGLM does not generate unrelate or delete transactions. You cangenerate these with a user-written exit or add them manually to the -BTGgenerated transactions. For more information, see “-BTG USER - Preparingand Invoking a User-Written Exit” on page 50.




Updates to occurrences used in SQL processing is limited. You must use theSQL DROP statement to remove SQL accessible tables, views, synonyms,functions, procedures and triggers. For more information, See the CADatacom/DB Database and System Administration Guide and CA Datacom/DBSQL User Guide.

You cannot modify certain attribute-values of SQL accessible tables that haveconstraints. See Appendix C, “Maintaining Tables with Related Constraints” onpage 605. For more information about all attribute-types, see the CA DatacomDatadictionary Attribute Reference Guide.


Reports

Reports

DDUPDATE produces two types of reports:

■ Those that are automatically generated when you execute the utility■ Those that you can include in the execution batch job stream or SYSIN file

Automatically Generated Reports

DDUPDATE automatically generates a report made up of three parts:

■ Maintenance Report■ Detail Report■ Error Recap Report

Maintenance Report

A Maintenance Report is automatically generated for each Datadictionarytransaction collection submitted to Datadictionary through DDUPDATE. Thereport lists each transaction submitted and the outcome of Datadictionary'sattempt to process the transaction. For more information about this type ofreport, see “Maintenance Portion” on page 29.

Detail Report

DDUPDATE automatically generates a report which lists detailed informationabout the occurrences. It includes all attribute-types and the currentattribute-values for the entity-type used in the DDUPDATE transactions. Formore information and examples, see “Detail Report” on page 457

If you wish to suppress this report, enter -SET RPOF before coding thetransactions to be processed. To turn the report back on after it has beenturned off, enter -SET RPON before any transactions on which you wish aDetail Report to be generated. For more information about the -SETtransactions, see the CA Datacom/DB Database and System AdministrationGuide. If you are using a -UPG transaction, no Detail Report is generatedunless there is an error in which case, the occurrence in error is reported.

Error Recap Report



Reports

Requested Reports

In addition to the report automatically generated by executing DDUPDATE, youcan also process reports with the -RPT transaction. This means you can codea -RPT transaction in the same execution of DDUPDATE that adds or updatesoccurrence definitions. For more information, see “Obtaining a Report” onpage 407.

For example, you could code transactions to add an entire DATABASEstructure and after the last transaction you could request a report of the entirestructure. When you submit the transactions using DDUPDATE, theDATABASE structure would be added and then the requested report would beproduced.

Do not request a report in the middle of a transaction collection. The -RPTtransaction acts as an -END transaction.

An example transaction collection follows:

-UPD DATABASE,ORDER-ENTRY(T123) 29 12 -END -RPT INDEX,DATABASE,ORDER-ENTRY(ALL) -END

The -UPD transaction collection changes the DATACOM-ID to 012. Then the-RPT transaction collections request a report for all occurrences of theORDER-ENTRY in the DATABASE entity.

Datadictionary offers a wide variety of reporting possibilities. One possibility isto run a report without running an update transaction. You can do this by usingthe DDUTILTY -RPT transactions. For more information about coding reportrequests and the reports available, see “Obtaining a Report” on page 407.

If you submit several types of reports in the same job stream or SYSIN file, thepage numbers on the report are sequential. If you want individual pagenumbered reports, use separate execution steps in the JCL (EXEC).


Sample Job Streams

Sample Job Streams

The following are example JCL.

z/OS Example JCL

An z/OS example of DDUPDATE JCL follows. Enter your -UPD, -ADD, -CPY,and -DEL transactions after the -USR transaction.


//jobname See the note above and page 19. // EXEC PGM=DDUPDATE,REGION=6K //STEPLIB See the note above and page 19. //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //AUXIN DD DSN=dd.output,DISP=... Auxiliary input transactions // (OPTIONAL) //SYSIN DD Input transactions -USR ... Authorized user information -SET RPOF This stops the generation

. of the detail report. . . Your transactions . . /


Sample Job Streams

z/VSE Example JCL

A z/VSE example of DDUPDATE JCL follows. Enter your -UPD, -ADD, -CPY,and -DEL transactions after the -USR transaction.


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // EXEC DDUPDATE,SIZE=96K -USR ... Authorized user information -SET RPOF This stops the generation

. of the detail report. . . Your transactions . . / /& $$ EOJ


Header Transactions

Header Transactions

The first transaction you submit with a transaction collection is a headertransaction. The header transaction tells the system the type of maintenance toperform and which occurrence is affected.

There are two types of header transactions. The General Maintenance headertransactions perform the following functions:

■ -ADD■ -CPY■ -DEL■ -UPD■ -UPG

The Field Processing header transaction performs the following function.

■ -GRP

Each time the system encounters one of the general maintenance headertransactions, it issues a log checkpoint.

Note: For information about how the DDUPDATE utility handles transactionsgenerated by the DDBTGLM utility, see page 216.

Use the -GRP header transaction in processing field transactions to reduceprocessing time. For more information about this transaction, see “Using the-GRP Header Transaction” on page 234.

Whether you use general maintenance or field processing transactions, youfurther define the entity-occurrence you are maintaining by designating whichstatus or version the entity-occurrence is in, for example PRODuction orTEST, and whether there is a password or lock associated with theentity-occurrence. You can also use an override code to bypass password orlock levels. For more details about these parameters, see sections on statusand version, and protecting definitions in the CA Datacom Datadictionary UserGuide.


Header Transactions

Using the -ADD Header Transaction

Use the -ADD header transaction to indicate you are submitting batchtransactions to add information to Datadictionary. After entering the -ADDheader transaction, enter the appropriate numbered transaction or transactions.See the numbered transaction chapters for information on entering thesetransactions and the following formats and descriptions for entering the -ADDheader transaction:

��──-ADD──entity,─ ──┬ ┬────────────── ──occ-name(vrs ──┬ ┬──────────── ) ───�� └ ┘─parent-name.─ ├ ┤─,pswd,───── ├ ┤─,pswd,lock─ └ ┘─,,lock─────

entity,(Required) Enter the name of the entity to which the transactions apply.

Valid Entries: Existing entity-type


parent-name.(Optional) Only necessary when the entity-type is FIELD, KEY, orELEMENT. Enter name of the record or table with which the FIELD, KEY,or ELEMENT occurrence is associated. The concatenation of thisparameter to the occurrences provides the unique identification for FIELD,KEY, or ELEMENT occurrences. Separate the parent-name from theoccurrence name with a period.

Valid Entries: Existing RECORD or TABLE occurrence name


occ-name(Required) Enter name of the occurrence to which the maintenanceapplies. Alias names are not valid.

Valid Entries: 1- to 32-character alphanumeric name



Header Transactions

(vrs)(Optional) Enter the status or version within parentheses. For Modeloccurrences, you can use a TEST status/version. For non-Modeloccurrences, you can enter a version number.

If the occurrence is a FIELD, KEY, or ELEMENT, you must supply theversion of the RECORD or TABLE occurrence with which the occurrenceis associated.

Valid Entries: 1- to 4-character valid status or version

Default Value for CA Datacom/DB or CA FILE Model occurrences:T001

Default Value for non-Model occurrences:Next available version number (001 to 999)

,pswd(Optional) Enter a password if you want to restrict maintenance on theoccurrence definition you are adding. The password must appear insidethe same parentheses as the version number.

Valid Entries: Valid 1- to 4-character alphanumeric code


,lock(Optional) Enter a lock level to designate the level of security on theoccurrence definition. If you omit the password parameter, you mustprecede the lock level with two commas.

■ LOCK0 places no maintenance restrictions.

■ LOCK1 restricts an occurrence from update or deletion unless overridecode is specified.

■ LOCK2 restricts any access or update to the occurrence unlessoverride code is specified.

Valid Entries: LOCK0, LOCK1, or LOCK2

Default Value: LOCK0


Header Transactions

Using the -CPY Header Transaction

Use the -CPY header transaction to indicate you are submitting batchtransactions to copy a structure from one version to another. After entering the-CPY header transaction, enter the appropriate numbered transaction ortransactions.

See the numbered transaction chapters for information on entering thesetransactions and the following format and descriptions for entering the -CPYheader transaction.

Constraints: Constraints are copied along with the TABLE, AREA, orDATABASE entity-occurrence to which they are connected.

If you want to copy a TEST version of an occurrence to PRODuction status andthe PRODuction status occurrence has constraints, first restore the PRODuctionstatus occurrence to TEST, make the changes and copy the occurrence toPRODuction status; or make the changes to the PRODuction status occurrencethrough SQL.

When you execute an SQL ALTER TABLE statement against a table that has aCONSTRAINT attribute-value of Y, which adds a constraint to a table,Datadictionary sets the CONSTRAINT attribute-value to A on all TEST andHISTory versions of that table. If you later attempt to copy one of theseversions (or a structure containing one of these versions) to PRODuction status,Datadictionary prevents the copy, issues an error message, and identifies thetable which has been altered. For further instructions, see Appendix C,“Maintaining Tables with Related Constraints” on page 605.

-CPY Header Transaction

��──-CPY─ ──entity,occ-name(vrs ──┬ ┬──────────── ) ──┬ ┬───────── ──────────�� ├ ┤─,pswd,ovrd─ └ ┘ ─,target─ ├ ┤─,pswd────── └ ┘─,,ovrd─────

entity,(Required) Enter the entity-type of the occurrence that you are copying.



occ-name(Required) Enter the Datadictionary name of the occurrence that you arecopying. Alias names are not valid.

Valid Entries: Existing occurrence name



Header Transactions

(vrs)(Required) Enter the status or version of the existing occurrence withinthe parentheses. An existing status or version can be used.

Valid Entries for CA Datacom/DB or CA FILE Model occurrences:An existing TEST status/version (T001 to T999)PRODAn existing version number (001 to 999)An existing HISTory generation (H000 to H997)

Valid Entries for non-Model occurrences:An existing version number (001 to 999)


,pswd(Optional) Only required when the occurrence from which you arecopying has a password assigned.

Enter the password code to match the password established when theoccurrence was added or when it was updated with a 1000 NEWPSWDtransaction. Failure to match the password will cause the maintenancerequest to be rejected. Code the password inside the same parenthesesused for the version.

Valid Entries: Existing password


,ovrd(Optional) Only required if the occurrence from which you are copying isprotected by a Lock Level 1 or 2.

Enter the system override code. If you omit the password parameter, youmust precede the override code with two commas.



,target(Required) The target status is required for the transactions in the CADatacom/DB Model.

Enter the target status to which you want to copy the structure oroccurrence. All transactions which follow a -CPY header transaction witha target status option are applied to the new occurrence created.

Note: If you specify TEST as the target status, the definition of theexisting TEST status/version overwrites the definitions of all other existingTEST status/versions.


Header Transactions

For any entities that are not included in the CA Datacom/DB Model orFILE Model, leave this parameter blank. Datadictionary will copy theoccurrence to the next available version.

Valid Entries for CA Datacom/DB and FILE Model occurrences:PRODT001 to T999TEST

Default Value for CA Datacom/DB and FILE Model occurrences:(No default)

Valid Entries for non-Model occurrences:Blank

Default Value for non-Model occurrences:Next available version (001 - 999)

Using the -DEL Header Transaction

Use the -DEL header transaction to indicate that you are submitting batchtransactions to delete information from Datadictionary.

When you delete a PRODuction status occurrence it is not removed fromDatadictionary. Instead, it is changed to HISTory status. For more information,see the section about history status in the CA Datacom Datadictionary UserGuide for details. For example, if you are deleting a schema(AUTHORIZATION occurrence) you created through SQL and you do not issuethe delete for the HISTory status version, when you try to re-create that schemathrough SQL, you will receive a NOAE (occurrence already exists) condition.When you delete an occurrence in the other statuses (such as a TESTstatus/version, HISTory status or QUALified production status), the occurrenceis removed from Datadictionary.

Note: You must use the SQL DROP statement to delete SQL accessibletables, views, or synonyms. For information, see the CA Datacom/DB SQLUser Guide.

-DEL Header Transaction

��──-DEL─ ──entity, ──┬ ┬────────────── occ-name(vrs ──┬ ┬──────────── ) ─────�� └ ┘ ─parent-name.─ ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────


Header Transactions

entity,(Required) Enter the name which identifies the entity to which thetransactions apply.

Note: Certain constraint rules apply to deleting KEY, FIELD, and TABLEentity-occurrences. See the table below:

For entity-type: Use the following constraint rule:

KEY Cannot delete a FOREIGN KEY.Can delete UNIQUE KEYs not related to aCONSTRAINT.Cannot delete any key entity-occurrence that isrelated to a CONSTRAINT.

FIELD Cannot delete a field that has a CHECKCONSTRAINT.

TABLE Cannot delete a table if it has a CONSTRAINT.



parent-name.(Optional) Only valid if the entity-type is FIELD, KEY, or ELEMENT.Enter the name of the RECORD or TABLE occurrence with which theFIELD, KEY or ELEMENT occurrence is associated. The concatenationof this parameter to the occurrence provides the unique identification forFIELD, KEY, or ELEMENT. Separate the parent-name from theoccurrence name by a period.






(vrs)(Required) Enter the status or version of the occurrence you are deletingwithin parentheses.

You must supply the version of the RECORD or TABLE occurrence withwhich the FIELD, KEY, or ELEMENT occurrence is associated.

Note: The version is not required when using the OBSOLETE functionwith a -DEL header transaction. For more information, see “1000OBSOLETE Transaction” on page 260.



Header Transactions

Default Value for CA Datacom/DB or CA FILE Model occurrences:(No default)

Default Value for non-Model occurrences:Lowest version (001 to 999) associated with occurrence

,pswd(Optional) Enter the password code to match the password previouslyestablished when the occurrence was added or when it was updated witha 1000 NEWPSWD transaction. Failure to match the password will causethe maintenance request to be rejected. Code the password inside thesame parentheses used for version number.

Valid Entries: Assigned password


,ovrd(Optional) Enter the system override code if the occurrence was added orupdated with Lock Level 1 or 2. If you omit the password parameter, youmust precede the override code with two commas.



Using the -UPD Header Transaction

Use the -UPD header transaction to indicate you are submitting batchtransactions to update information in Datadictionary. The -UPD transaction canalso be used to return attribute values to the default. For more informationabout this function, see page 232.

Note: You cannot modify certain attribute-values of SQL accessible tables thathave constraints. For more information, see Appendix C, “Maintaining Tableswith Related Constraints” on page 605.

If the -UPD transactions begin with an occurrence that is not the base of thestructure (such as AREA, TABLE, or RECORD), you must add the appropriate1000 CONNECT transaction to the transaction collection.

After entering the -UPD header transaction, enter the appropriate numberedtransaction or transactions. See the numbered transaction chapter forinformation on entering these transactions and the following format anddescriptions for entering the -UPD header transaction.


Header Transactions

-UPD Header Transaction

��──-UPD──entity,─ ──┬ ┬────────────── ──occ-name(vrs ──┬ ┬──────────── ) ────� └ ┘─parent-name.─ ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────

�─ ──┬ ┬─────── ──┬ ┬───────── ────────────────────────────────────────────�� └ ┘─,lock─ └ ┘─,status─




parent-name.(Optional) Only valid if the entity-type is FIELD, KEY, or ELEMENT.Enter the name of the RECORD or TABLE occurrence with which theFIELD, KEY, or ELEMENT occurrence is associated. The concatenationof this parameter to the occurrence provides the unique identification forFIELD, KEY, or ELEMENT occurrences. Separate the parent-name fromthe occurrence name by a period.






(vrs)(Required) Enter the status or version of the occurrence you are updatingwithin parentheses. You must supply the version of the RECORD orTABLE occurrence with which the FIELD, KEY, or ELEMENT occurrenceis associated.



,pswd(Optional) Enter the password code to match the password previouslyestablished when the occurrence was added or updated. Failure to matchthe password will cause the maintenance request to be rejected. Codethe password inside the same parentheses used for the version number.




Header Transactions

,ovrd(Optional) Enter the system override code if the occurrence was added orupdated with a Lock Level 1 or 2. If you omit the password parameter,you must precede the system override code with two commas.



,lock(Optional) Enter a lock level to designate the level of security on anoccurrence. If you enter a lock level value, you cannot enter a statusvalue in the same transaction.

■ LOCK0 changes the assignment to no maintenance restrictions.

■ LOCK1 restricts an occurrence from update or deletion unless anoverride code is specified.

■ LOCK2 restricts any action to the occurrence.

Valid Entries: LOCK0, LOCK1, or LOCK2

Default Value: Lock level of existing occurrence

,status(Optional) Enter the status to move non-Model occurrences toPRODuction status. If you enter a status value, you cannot enter a locklevel value in the same transaction.

For more information about moving occurrences to PRODuction status,see the person responsible for administering Datadictionary at your site.

Valid Entries: PROD


Returning Attribute Values to Default: To reset an attribute-value to itsdefault value, code a -UPD header transaction to identify the occurrence towhich the change applies. Code the numbered transaction which contains thevalue to be changed back to its default, then place an ampersand (&) in the firstcharacter of the respective input field.

For example, the 3002 transaction contains the DBMS-USED attribute. Youoriginally entered IBM/IMS and now you want to return the DBMS-USED to thedefault. Code the -UPD header to identify the AREA entity and occurrencename. Enter 3002 as the transaction and in position 38 enter an ampersand(&). An example transaction collection follows:

-UPD AREA,PERSONNEL(T1) 32 & -END


Header Transactions

Using the -UPG Header Transaction

Only a user with Datadictionary Administrator security can use this transactionheader.

Use the -UPG header transaction to indicate you are submitting batchtransactions to update specific attribute information of a generic set ofentity-occurrences in Datadictionary.

Note: For the purpose of discussing the -UPG Header Transaction, the terms"generic" or "generic set" refer to a set of values that do not necessarily isolatea single occurrence. For example, using a partial occurrence name such asABC* or a non-specific status such as TEST.

The -UPG transaction can only be used with the 1500 transaction. Afterentering the -UPG header transaction, enter the appropriate 1500 transaction ortransactions. For more information, see the section about “1500 Attribute ValueUpdate Transaction” on page 300.

-UPG Header Transaction

��──-UPG──entity,─ ──┬ ┬────────────── ──occ-name(vrs) ───────────────────�� └ ┘─parent-name.─




parent-name.(Optional) Only valid if the entity-type is FIELD, KEY, or ELEMENT.Enter the full or generic name of the RECORD or TABLE occurrence withwhich the FIELD, KEY, or ELEMENT occurrence is associated or ALL.The concatenation of this parameter to the occurrence provides theidentification for FIELD, KEY, or ELEMENT occurrences to be updated.Separate the parent-name from the occurrence name by a period.

Valid Entries: Existing RECORD or TABLE occurrence name or ALL


occ-name(Required) Enter full or generic name of the occurrence to which themaintenance applies or ALL. Alias names are not valid.

Valid Entries: Existing full or generic occurrence name or ALL



Header Transactions

(vrs)(Required) Enter the status or version of the occurrence you are updatingwithin parentheses.




■ No occurrences in HISTory status can be updated. For this reason, youmust specify either TEST or PROD or a specific version (for example, 001)or status (T001).

■ This transaction header allows you to bypass password and lock levelsecurity. Therefore, you must have Datadictionary Administrator privileges.For more information and an example of how the -UPG Header Transactionis used, see “1500 Attribute Value Update Transaction” on page 300.

Using the -GRP Header Transaction

The -GRP header transaction simplifies coding field transactions by eliminatingthe need for each field transaction to contain the RECORD or TABLEoccurrence name or status. Datadictionary assumes each field -ADD, -DEL,and -UPD transaction applies to the RECORD or TABLE occurrence and statusyou specified in the -GRP START.

Processing for the RECORD or TABLE named continues until DDUPDATEencounters:

■ A -GRP END transaction■ A new -GRP START transaction■ A FIELD maintenance header for a different record or table■ A header transaction for an entity other than FIELD

With the -GRP transaction, verification of FIELD maintenance transactions isdone once for the entire group instead of after each individual FIELDmaintenance transaction. Verification occurs when the group is terminated bythe -GRP END transaction, another -GRP START transaction, a FIELDmaintenance header for a different TABLE or RECORD, or a header transactionfor an entity other than FIELD.

■ If the specified TABLE or RECORD occurrence does not exist,Datadictionary generates an error and flushes all transactions to the next-GRP END transaction, the next -GRP START transaction, a FIELDmaintenance header for a different TABLE or RECORD, or a headertransaction for an entity-type other than FIELD.

■ If an error is encountered on a field transaction during group processing,Datadictionary generates the error and flushes all transactions to the next-GRP END transaction, the next -GRP START transaction, a FIELD


Header Transactions

maintenance header for a different TABLE or RECORD, or a headertransaction for an entity-type other than FIELD.

In this case, any FIELD occurrences successfully processed prior to theerror will have 0 as the value for the level and displacement; additionally,any parent of a compound field will have a length of 0. Correct thetransactions in error and resubmit the transactions starting from the fieldwhere the error was encountered.

When all transactions, including the -GRP END are successfully processed,the level, displacement and length will be correctly calculated for the fieldswhere these values were previously 0. This will also be accomplished whenyou perform the VERIFY function for the RECORD or TABLE substructureor the DATABASE structure.

When you use a -GRP header, Datadictionary produces a Field Report at thebeginning of processing. This report gives you a before picture. WhenDatadictionary encounters the -GRP END transaction, Datadictionary generatesa revised Field Report which reflects the changes. If you do not enter a -GRPEND transaction, Datadictionary does not generate the Field Report. Theformat for the -GRP header transaction follows:

��──-GRP──START─ ──┬ ┬─,RECORD─ ──,occ-name(vrs ──┬ ┬──────────── ) ─────────�� └ ┘─,TABLE── ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────

,RECORD or ,TABLE(Required) Enter RECORD or TABLE as the entity.

,occ-name(Required) Enter the name of the RECORD or TABLE occurrence towhich the FIELD occurrences belong.



(vrs)(Required) Enter the version of the RECORD or TABLE occurrence towhich the FIELD occurrences belong.

Valid Entries: 1- to 4-character valid version


,pswd(Optional) Enter the password code to match the password previouslyestablished for the RECORD or TABLE occurrence to which the FIELDoccurrences belong. Code the password inside the same parenthesesused for version number.




Header Transactions

,ovrd(Optional) Enter the system override code if the RECORD or TABLEoccurrence was added or updated with a Lock Level 1 or 2. Place thecode inside the same parentheses used for version number. If you omitthe password parameter, you must precede the system override code withtwo commas.



-GRP END Transaction

You can use the -GRP END transaction to end processing of the record. Codethe transaction as follows:

-GRP END Transaction

��──-GRP──END─────────────────────────────────────────────────────────��

Note: For -RPT transactions, see Chapter 9, “DDUTILTY - Producing Reportsand Source Language Statements.”

For a complete Field Add transaction collection which uses the -GRPtransaction, see “Example Transaction Collection” on page 346.


Using the Maintenance Transactions


Some transactions can be used to maintain any occurrence. Other transactionsapply only to specific occurrences.

Maintaining Support Data

As you define your occurrence to Datadictionary, you can use transactions toadd data that does not necessarily affect the true definition, but supplements orsimplifies the definition process.

These transactions are nonspecific regarding entities. That is, you can usethese transactions to maintain any occurrence. These transactions are the1000 through 1500 transactions. A partial list of transactions and functionsfollows. These transactions perform a variety of functions, such as:

■ Changing a password (1000 NEWPSWD)

■ Specifying the author and controller of the occurrence (1001 AuthorController)

■ Adding a description to an occurrence (1002 DESCRIPTION)

■ Adding or deleting descriptors (1101 ADD DESCRIPTOR, 1101 DELDESCRIPTOR)

■ Adding or deleting aliases (1103 ADD alias, 1103 DEL alias )

■ Adding, deleting, inserting, or replacing text (1200 TEXT ADD, 1200 TEXTDEL, 1200 TEXT INS, 1200 TEXT REP)

You can continue to use the 1000 APPLY transaction to handle textinformation with the -CPY header transaction for an occurrence. However,you cannot use the 1000 APPLY and the 1200 TEXT transactions within thesame DDUPDATE transaction collection for the same occurrence.

■ Maintaining text classifications (1200 TEXT CLS)



Maintaining the CA Datacom/DB and CA FILE Models

Certain transactions only apply to the CA Datacom/DB Model and the CA FILEModel. A list of the CA Datacom/DB Model and CA FILE Model transactionsfollow with a brief description of each. See the person responsible foradministering Datadictionary at your site for complete instructions on the use ofthese models.

1000 ALTERUse this transaction to apply the values of certain attributes ofDATABASE or AREA occurrences to the CA Datacom/DB Directory (CXX)without having to close the database.

1000 CATALOGUse this transaction to catalog databases to CA Datacom/DB.

1000 CONNECTUse this transaction to identify the parent of an AREA, TABLE, orRECORD occurrence in a Model structure.

1000 DISABLEUse this transaction to mark a CA Datacom/DB Model or CA FILE Modelstructure or substructure as unavailable for use by other CA products.

1000 ENABLEUse this transaction to mark a CA Datacom/DB Model or CA FILE Modelstructure or substructure as available for use by other CA products.

1000 OBSOLETEUse this transaction to remove all versions and statuses of an entire CADatacom/DB or CA FILE Model structure or substructure with onetransaction. This transaction is only valid with the -DEL headertransaction.

1000 RESTOREUse this transaction to restore an entire structure or substructure to TESTstatus from PRODuction status or HISTory status using a -UPD headertransaction.

1000 SETFor occurrences in a DATABASE structure, use this transaction togenerate certain modifiable and non-modifiable attribute-values that werenot assigned at the time the occurrences were added.

1000 TRANSFERUse this transaction to move:

■ An AREA substructure from one DATABASE structure to another■ A TABLE substructure from one AREA substructure to another■ A RECORD substructure from one FILE structure to another

1000 VERIFYUse this transaction to confirm that additions and modifications to aDATABASE or FILE structure or substructure are valid. The entity in the



-UPD header can be the DATABASE, FILE, TABLE, RECORD,ELEMENT, or KEY entity-type.

Maintaining Occurrence Attributes

The 2900—7999 transactions apply to specific entities. A list of entities and thetransactions you can use to add or change information about them follows:

Entity-Type Transaction

DATABASE 2900—2901, 3000

AREA 3001—3004

TABLE 3150—3152

FILE 3120—3122

RECORD 3200

FIELD 4010—4018, 4020, 4099

KEY 5000, 5010—5012, 5100

ELEMENT 6000, 6010—6011

LIBRARY 6100

MEMBER 6200

PARTITION-VALUE 7011—7015, 7021—7025

PANEL 7100

SYSTEM 7110

PROGRAM 7120

MODULE 7130

AUTHORIZATION 7140

PERSON 7150, 7155—7156

REPORT 7160

JOB 7170

STEP 7180

DATAVIEW 7190

NODE 7210—7211



Returning Attribute Values to Default

To reset an attribute-value to its default value, code a -UPD header transactionto identify the occurrence to which the change applies. Code the numberedtransaction which contains the value to be changed back to its default, thenplace an ampersand (&) in the first character of the respective input field.

For example, the 3002 transaction contains the DBMS-USED attribute. Youoriginally entered IBM/IMS and now you want to return the DBMS-USED to thedefault. Code the -UPD header to identify the AREA entity and occurrencename. Enter 3002 as the transaction and in position 38 enter an ampersand(&). An example transaction collection follows:

-UPD AREA,PERSONNEL(T1) 32 & -END

Another method of accomplishing this same update would be to use the 1500Transaction:

-UPD AREA,PERSONNEL(T1) 15 DBMS-USED,& -END


1000 ALTER Transaction


The 1000 ALTER transaction is used to apply, to relevant attributes of certainentity-types, changes to the CA Datacom/DB CXX, without requiring thedatabase to be closed (if the database is found by the 1000 ALTER transactionto be closed, the database is opened).

You can use the 1000 ALTER transaction for system-defined databases (forexample, DATA-DICT, DDD-DATABASE, and so on), and also for user-defineddatabases.

The 1000 ALTER transaction is only valid for the DATABASE and AREAentity-types.

Processing of the 1000 ALTER only affects the CXX entry for theentity-occurrence specified in the header transaction.

The 1000 ALTER transaction is valid for CA Datacom/AD.

Restrictions

Consider the following restrictions to using 1000 ALTER:

■ The database must have been set or defaulted as ACCESS OPTIMIZEduring the enabling of the MUF.

■ The database must not be defined as VIRTUAL.

■ The MUF must currently be a single instance of the MUF and not part of aMUFplex with 2 or more MUFs currently enabled. It is acceptable, however,to have a Shadow MUF that is not enabled.

■ The occurrence to be altered must have been previously cataloged andmatch the identity information stored in the CXX. Specifically the followingfields must match:

CXX Datadictionary Attribute

DATACOM ID DATACOM-ID

DATACOM NAME DATACOM-NAME

ENTITY OCCURRENCE NAME ENTITY-NAME

STATUS STATUS

VERSION ENTITY-VER

SQL NAME SQLNAME

■ If modifying a database, the base must be FORMAT 2 in the CXX,indicating that a fallback from r12 to r11 is not likely to occur. Also, thefollowing data cannot be different from that currently in the CXX, that is tosay, the following data cannot be changed:



STAR REPLICATION STAR PARTITIONED SQL SECURITY

■ If modifying a data area, the DATACOM NAME must match, and the areamust be in URI format.

Format

The format for a 1000 ALTER transaction follows:

��──1 ALTER────────────────────────────────────────────────────────��

Example Transaction Collection

Following are examples of 1000 ALTER transactions.

Use a -UPD transaction to identify the DATABASE or AREA OCCURRENCEyou want to alter in the CXX. If the user is authorized to update occurrences inPRODuction status, the attribute or attributes can be updated in the sametransaction set as the 1000 ALTER transactions.

The following example transaction collection reads the ORDER-ENTRYdatabase and applies any changes to the CA Datacom/DB CXX. Notice thatthis example uses a database that is not changed in the transaction set. In thiscase, any changes made previously to relevant attributes are applied to theCXX. In the following, the database is in PRODuction status, the password isOR11, and the override code is represented by **** (four asterisks).

-UPD DATABASE,ORDER-ENTRY(PROD,OR11,) 1 ALTER -END

The following example transaction collection updates the ACCTS-REC areadynamic extend attribute and applies the change to the CA Datacom/DB CXX.In this case, any changes made previously to other relevant attributes areapplied to the CXX and also to the DYNAMIC-EXTEND attribute change. In thefollowing, the area is in PRODuction status, the password is OR11, and theoverride code is represented by **** (four asterisks).

-UPD AREA,ACCTS-REC(PROD,OR11,) 1 ALTER 15 DYNAMIC-EXTEND,C -END



Relevant Attributes

The DATABASE entity-type and AREA entity-type attributes, shown in thetables that follow, are passed from Datadictionary to CA Datacom/DB forcomparison to the CXX. Processing either does or does not take place, asnoted in the tables, depending on the results of that comparison.

DATABASE Entity-Type Attribute: Following are listed the attribute-values forthe DATABASE entity-type and processing possibilities.

Attribute: DATABASE entity-type(Datadictionary Attribute Name)

Update Processing

DATACOM ID(DATACOM-NAME)

NO The ALTER transaction fails if no databaseis located in the CXX with this DATACOMID. The ALTER transaction also fails if, fora database located in the CXX with thisDATACOM ID, the Datadictionaryentity-occurrence name, status, and versiondo not match those passed fromDatadictionary.

ENTITY OCCURRENCE NAME(ENTITY-NAME)

NO See DATACOM ID.

DATADICTIONARY STATUS(STATUS)

NO See DATACOM ID.

DATADICTIONARY VERSION NUMBER(ENTITY-VER)

NO See DATACOM ID.

CA DATACOM/DB STAR REPLICATED(no attribute, $REPLICATED relationship)

NO The ALTER transaction fails if thisattribute-value does not match the CXX.

CA DATACOM/DB STAR PARTITIONED(no attribute, $PARTITIONED relationship)


SQL SECURITY PROTECTION(SQL-SECURITY)


INDEX DYNAMIC EXTEND UNIT(DYNAMIC-EXTEND)

YES If this attribute-value does not match theCXX, the new value is stored in the CXXand takes affect with the next dynamicextend.

INDEX DYNAMIC EXTEND # UNITS(DYN-EXT-TRACKS)




AREA Entity-Type Attribute-Values: Following are listed the attribute-valuesfor the AREA entity-type and processing possibilities.

Attribute: AREA entity-type(Attribute Name)

Update Processing

DATACOM NAME(DATACOM-NAME)

NO The ALTER transaction fails if no area islocated in the CXX with this DATACOMNAME within the DATACOM ID of thedatabase. The ALTER transaction also failsif, for an area located in the CXX with thisDATACOM NAME within the DATACOM IDof this database, the Datadictionaryentity-occurrence name, status, version, andSQL name do not match those passed fromDatadictionary.

BLOCK SIZE(BLOCK-SIZE)

YES If this attribute-value does not match theCXX, the new value is stored in the CXXbut does not take affect until the data areais initialized using DBUTLTY.

OVERFLOW SLACK(SLACK)

YES If this attribute-value does not match theCXX, the new value is stored in the CXXand takes affect on the next overflow.

DEVICE TYPE(DEVICE)

NO This attribute is currently ignored.

RPS SUPPORT(RPS)

NO This attribute is currently ignored.

SPACE MANAGEMENT OPTION(SPACE-MNGMNT)

YES If this attribute-value does not match theCXX, the new value is stored in the CXXand takes affect on the next maintenancecommand to the area. It uses, however,what currently exists in the index and dataarea. Changing from clustered to notclustered does not delete the cluster index,which is not deleted until the next LOAD orRETIX that includes the area. Changingfrom not clustered to clustered has nocluster index for all existing data andtherefore starts the addition of cluster indexvalues with the next ADDIT. Changing fromspace option 0 to any other does not havea space map of existing blocks. Changingfrom any other space option to 0 ceasesusing space maps, but they are not deleteduntil the next LOAD or RETIX that includesthe area.



Attribute: AREA entity-type(Attribute Name)

Update Processing

ENTITY OCURRENCE NAME(ENTITY-NAME)

NO See DATACOM NAME.

DATADICTIONARY STATUS(STATUS)


DATADICTIONARY VERSION(ENTITY-VER)


DATA AREA DYNAMIC EXTEND UNIT(DYNAMIC-EXTEND)


DATA AREA DYNAMIC EXTEND # UNITS(DYN-EXT-TRACKS)


SQL NAME(SQLNAME)



1000 APPLY Transaction


The 1000 APPLY transaction is used to apply text maintenance when it is usedwith the -CPY header transactions. The 1200 TEXT CLS transaction isavailable which allows you to designate and maintain classifications of text.This transaction provides various options on maintaining text classifications notavailable with the 1000 APPLY transaction. For more information, see “1200TEXT Transactions” on page 288.

Datadictionary does not allow the 1200 TEXT transactions and the 1000APPLY transaction within the same DDUPDATE transaction collection forthe same occurrence.

To copy all text to a new version, code a transaction collection consisting of thefollowing:

■ A -CPY header transaction■ A 1000 APPLY transaction, with TEXT parameter■ An -END transaction

The -CPY header transaction specifies the occurrence being copied. All textclassifications associated with the text being copied are also copied with thistransaction collection.

To specify that no text will be copied while copying an occurrence to a newversion, code a transaction collection consisting of the following:

■ A -CPY header transaction■ A 1000 APPLY transaction, with NOTEXT parameter■ An -END transaction

To share text, use the -CPY header transaction without the 1000 APPLYtransaction.

You can also use the 1000 APPLY transaction while updating an occurrenceusing the -UPD header transaction to copy the text associated with theoccurrence you are updating. For more flexibility in updating the text, see“1200 TEXT Transactions” on page 288.

The generalized format for this transaction follows:


��──1──APPLY─ ──┬ ┬─,TEXT─── ─────────────────────────────────────────�� └ ┘─,NOTEXT─

,TEXTCopies all text to the new version. The new version of the occurrenceowns its copy of the text which can be maintained independent of theoriginal text.



,NOTEXTDoes not copy any text to the new version.

Example Transaction Collection:

The following is an example of the 1000 APPLY transaction:

-CPY MEMBER,PROG-A(3) 1 APPLY,TEXT -END

This transaction collection copies the occurrence Version 3 to a new TESTversion and includes all text.


1000 CATALOG Transaction


The 1000 CATALOG transaction catalogs databases to CA Datacom/DB. Usethis transaction for user-defined databases. The CATALOG function of theDDCFBLD Utility performs the same function as this transaction. For moreinformation about DDCFBLD, see Chapter 3, “DDCFBLD - CatalogingDatadictionary Definitions.”

The 1000 VERIFY and 1000 SET transactions are invoked during the executionof this transaction. Also, during the CATALOG process, all tables that are SQLaccessible are made accessible to CA Datacom SQL by posting the definitionto the DDD. One or more tables within a database may be disabled as a resultof the CATALOG. The structure must be enabled with the ENABLE command.


After a CATALOG, to get an Impact Report that shows you the impact of theCATALOG see the information about the CXX Report TYPE=I in the CADatacom/DB DBUTLTY Reference Guide.

Use a -UPD transaction to identify the database you are cataloging. The formatfor a CATALOG transaction follows:


��──1──CATALOG─────────────────────────────────────────────────────��


The following is an example of the 1000 CATALOG transaction:

-UPD DATABASE,ORDER-ENTRY(PROD,OR11,) 1 CATALOG -END

This transaction collection updates the ORDER-ENTRY database and catalogsit to CA Datacom/DB. In this example, the database is in PRODuction status,the password is OR11 and the override code is represented by ****.


1000 CONNECT Transaction


The 1000 CONNECT transaction is only valid for occurrences within theDATABASE and FILE structures. It establishes a connection between theDATABASE and AREA, the AREA and TABLE, and the FILE and RECORDoccurrences according to the rules of the $INTERNAL relationship.

In a connection, an object may only be connected to one subject. MultipleCONNECT transactions are not permitted for a single occurrence.

The CONNECT transaction deals only with the relationship named $INTERNAL.The connection of FIELD, KEY, and ELEMENT entities is implied by theirnaming method (RECORD or TABLE occurrence name and the occurrencename) and do not need a 1000 CONNECT transaction. The $INTERNALrelationship between the DATAVIEW and KEY and DATAVIEW and ELEMENTuses the 1003 RELT transaction. To relate a FILE occurrence to an AREAoccurrence, you must use the 1003 RELT transaction.

The 1000 CONNECT transaction is valid with TEST status occurrences only.Both occurrences must be in the same status/version.

If this transaction is used with -BTG transactions and the occurrence alreadyexists, the CONNECT transaction is treated like the TRANSFER transaction(see “1000 TRANSFER Transaction” on page 270). For complete details onusing -BTG transactions, see page 216.

Use the 1000 CONNECT transaction to connect the occurrence identified in theheader transaction to the occurrence identified in the 1000 CONNECTtransaction. The format for a CONNECT transaction follows:


��──1─ ──CONNECT,occ-name ───────────────────────────────────────────��

occ-nameThis is a 1- to 32-character alphanumeric name of the subject occurrenceto which the occurrence in the header transaction is to be connected.


The following is an example of the 1000 CONNECT transaction:

-ADD AREA,ACCTS-REC(T3) 1 CONNECT,ORDER-ENTRY -END

This transaction collection adds the ACCTS-REC area and connects it to theORDER-ENTRY database that has the same version as specified in the headertransaction.


1000 DISABLE Transaction


Use this function to mark CA Datacom/DB Model or CA FILE Model structure orsubstructure occurrence definitions as unavailable to other CA products.

For example you can disable a structure or substructure when it is beingmodified and is not available for use by CA Ideal or CA Dataquery. This isuseful if the Datadictionary definition of the structure no longer agrees with theCA Datacom/DB Directory definition or the physical data. The use of thisfacility by other CA products is dependent on the version level of the product.Check the product documentation.

Note: This function does not serve the same purpose as the ACCESS optionof the CA Datacom/DB Utility (DBUTLTY). Refer to the CA Datacom/DBDBUTLTY Reference Guide for more information.

A structure or substructure is automatically disabled (ENABLE attribute-valueset to N) when you perform a CATALOG, CREATE, ADD, DEFINE,TRANSFER, COPY, or RESTORE function, or when you update an occurrencein the structure through a MODIFY or attribute maintenance function. Disablinga structure does not affect the definition in the Directory.

When a primary structure (database) or substructure (area, table, element) isdisabled, Datadictionary also disables the associated substructures. When asecondary structure (dataview) is disabled, Datadictionary does not disable theassociated substructures.

To use the 1000 DISABLE transaction, code the -UPD header transaction toidentify the DATABASE structure or substructure to which the DISABLE applies.Code the 1000 DISABLE transaction as shown next:


��──1──DISABLE─────────────────────────────────────────────────────��


The following is an example of the 1000 DISABLE transaction:

-UPD DATABASE,ORDER-ENTRY(PROD) 1 DISABLE -END

This transaction collection disables the ORDER-ENTRY database that is inPRODuction status.


1000 ENABLE Transaction


Use this transaction to indicate that the data described by a structure orsubstructure is now in synchronization with the Directory (CXX) definition. Thetransaction marks the CA Datacom/DB Model and CA FILE Model structure orsubstructure available for use by other CA products.

You cannot enable a structure or substructure if it does not successfully pass averify. See the 1000 VERIFY transaction for more information.

When you enable a primary structure (database) or substructure (area, table,element), Datadictionary also enables the associated substructures. When youenable a secondary structure (dataview), Datadictionary does not enable theassociated substructures.

Code the -UPD header transaction to identify the DATABASE structure or thesubstructure to be enabled. Code the 1000 ENABLE transaction in thefollowing format:


��──1──ENABLE──────────────────────────────────────────────────────��


The following is an example of the 1000 ENABLE transaction:

-UPD DATABASE,ORDER-ENTRY(T3,OR11) 1 ENABLE -END

This transaction enables the TEST Version 3 of the ORDER-ENTRY database.In this example, this version of the database has a password of OR11.


1000 MODEL Transaction


You can define a new occurrence using the attribute-values of an existingoccurrence of the same entity-type 1000 MODEL transaction. The transactioncauses the attribute-values of the occurrence named in the -ADD headertransaction to be modeled after those of the existing occurrence specified in thefollowing 1000 MODEL transaction.

The 1000 MODEL copies the text from the existing occurrence to the targetoccurrence named in the header when you include the TEXT parameter. Textassociated with a universal field is shared unless you include the TEXTparameter or give the new field a different name.

Aliases and descriptors are not copied when the occurrence is modeled. Thesemust be defined in separate transactions.

Datadictionary does not carry forward any other occurrences within thestructure or substructure except when you model a record or table. However, ifTEXT is specified, only the text of the TABLE or RECORD are copied. Youmust delete the FIELD, KEY, and ELEMENT occurrences modeled initially, andthen model these occurrences individually if you want to copy the TEXTassociated with the occurrences.

User-defined relationships with occurrences outside the structure cannot becarried forward when the occurrence is modeled. Refer to the CA DatacomDatadictionary User Guide for more information on adding and maintainingrelationship definitions in Datadictionary.

Code the -ADD header transaction to identify the occurrence that will bemodeled after the existing occurrence. When modeling fields, code thepositional information for the new field, such as the AFTER and PARENTparameters, after the 1000 MODEL transaction. For more information aboutuniversal fields, see the CA Datacom Datadictionary User Guide.


��──1──MODEL,─ ──┬ ┬────────────── ──occ-name(vrs ──┬ ┬──────────── ) ─────� └ ┘─parent-name.─ ├ ┤─,pswd,ovrd─ ├ ┤─,pswd────── └ ┘─,,ovrd─────

�─ ──┬ ┬─────── ─────────────────────────────────────────────────────────�� └ ┘─,TEXT─

parent-name.(Optional) Only valid if the occurrence is a FIELD, KEY, or ELEMENTentity-type. Enter the name of the RECORD or TABLE occurrence withwhich the FIELD, KEY, or ELEMENT occurrence is related. Theconcatenation of this value to the occurrence name provides the unique



identification for the field, key, or element. Separate the record or tablename from the occurrence name with a period.



occ-name(Required) Enter name of the occurrence being modeled.



(vrs)(Required) Enter the 1- to 4-character status/version of the modeledentity-occurrence. HIST, TEST and ALL are not valid entries.

Valid Entries: T001—T999PROD or 001—999ASOF


,pswd(Optional) If the occurrence has been assigned a password, you mustenter it here.



,ovrd(Optional) If the occurrence has been assigned Lock Level 1 or 2, youmust enter the system override code.



,TEXT(Optional) If you code this parameter, Datadictionary creates a new copyof the text for the new occurrence. If you omit the parameter, the text isnot copied.

When modeling universal fields, use the TEXT parameter as follows:

■ If you include the parameter, the new field owns a copy of theuniversal field's text.

■ If you use the same name and omit the parameter, the new fieldshares the text of the universal field.

■ If you give the new field a different name in the -ADD transaction andomit the parameter, the new occurrence is created without text or onlywith the text you code following the -ADD header transaction.



The 1200 TEXT CLS transaction provides various options on maintainingtext classifications. However, Datadictionary does not allow the 1200TEXT transactions and the 1000 MODEL transaction within the sameDDUPDATE transaction collection for the same occurrence. For moreinformation, see “1200 TEXT Transactions” on page 288.

Valid Entries: TEXT



The following is an example of the 1000 MODEL transaction:

-ADD TABLE,CUSTOMERS(T1) 1 MODEL,CUST(T2) -END

A new table named CUSTOMERS is modeled after the existing table CUST.The text associated with the existing table is not copied because the TEXToption is not specified.


1000 NEWNAME Transaction


You can change the entity-occurrence name of many occurrences inPRODuction status or TEST status using the NEWNAME function. Use thisfunction to change the name of an occurrence without going through the stepsto model the occurrence and redefine the support data or additional data thatyou may have created for the occurrence.

Note: When you use the 1000 NEWNAME transaction, the ENTITY-NAMEattribute-value is changed. Other attributes, such as SQLNAME,COMPILER-NAME or ASSEMBLER-NAME are not updated with thistransaction.

Use the transaction applicable to the entity-occurrence you are updating tochange the COMPILER-NAME and ASSEMBLER-NAME attribute-values or usethe 1500 Attribute Value transaction.

The new name that you select must conform with the Datadictionary namingstandards for an occurrence. See the section on naming standards in the CADatacom Datadictionary User Guide for details.

You cannot change an occurrence name under the following circumstances.

■ You cannot change the name of a PRODuction status occurrence unlessyou are authorized to update PRODuction status occurrences.

■ You cannot change the name of an AUTHORIZATION occurrence when itrepresents a schema and is an authorization identifier (AUTHID) in the SQLprocessing mode. (Datadictionary assigns S for the AUTH-USAGEattribute-value of an authorization that is used as an AUTHID.)

■ You cannot rename a PRODuction status TABLE, FIELD or KEYoccurrence that has a CONSTRAINT related to it.

■ You cannot change the occurrence names of VIEW, SYNONYM, PLAN,STATEMENT, or CONSTRAINT occurrences.

Impact of Changing Names

When you change an occurrence name, the change applies only to thestatus/version of the occurrence you specify. If a program or facility outsideDatadictionary references the original occurrence name, you must also changethe name in that program or facility.

The name you specify with the NEWNAME function takes effect immediately.Therefore, when you use subsequent options or execute batch transactions,you must use the new name for the occurrence. For example, you must usethe new name of a table or record when specifying fields, keys and elements inthat TABLE or RECORD substructure in the transactions in the same jobstream.



Note: When you change the name of an occurrence in a CA Datacom/DBModel structure, you must CATALOG the database to update the CADatacom/DB Directory (CXX).

The renamed occurrence retains aliases, descriptors, relationships, and text asfollows:

■ All descriptors and relationships for an occurrence are changed to reflectthe new name.

■ If an alias is a timestamp starting with $19, or if the alias is unique for onlythis occurrence regardless of version number, then it will also be changedto reflect the new name. If this occurrence has an alias that is shared byother versions of the same occurrence, then the alias will be deleted for thisversion. The reason is that an alias must be unique for an entity-type.

■ Text is treated differently because text can be shared from one version toanother.

– If the renamed occurrence owns text that it shares with other versions ofthat occurrence, then that text is copied to the first occurrence thatshares the text and all other versions that share that text will bemodified to point at the new owned text. The original owned text isupdated to the occurrence with the new name.

– If the occurrence shares the text of another version that owns that text,then the text is copied to the renamed occurrence so that it owns acopy of the text.

– If a field has no text except the text that comes from a UNIVERSAL fieldwith the same original name, the UNIVERSAL text will be copied so thatthe field with the new name owns a copy of the text.

Changing Names of Tables Created in SQL

This transaction can be useful if you use SQL to create tables. The SQL namefor the table includes the specified or default authorization identifier of the user.The SQL name is in the format authid.tablename. Datadictionary creates anoccurrence name it can use by writing the Datadictionary name in theauthid-tablename format.

If the combination of the authorization identifier and table name is greater thanthe maximum allowed length of 32 characters, Datadictionary truncates theconcatenated name. If the truncated name already exists, Datadictionarytruncates it further and adds four zeros to the end of the name. Datadictionaryincrements the digits by one until the name is unique. See the section onnaming standards in the CA Datacom Datadictionary User Guide for examples.

The TABLE substructure that results from SQL processing is in PRODuctionstatus.



How To Use

To assign a new name to an occurrence, code a -UPD header transaction withappropriate parameters and follow it with a NEWNAME transaction. Thistransaction converts the version of the occurrence specified in the headertransaction to the occurrence name specified in the NEWNAME transaction.

Code the NEWNAME transaction using the following format:


��──1─ ──NEWNAME,occ-name ───────────────────────────────────────────��

,occ-nameThe new name of the occurrence specified in the -UPD transaction.

Valid Entries: 1- to 32-character occurrence name



The following is an example format of the 1000 NEWNAME transaction. In thefollowing example, the asterisks represent the override code.

-UPD TABLE,ACCTS(T1,MICK,) 1 NEWNAME,ACCOUNTS -END

This transaction collection changes the name of the ACCTS TABLE occurrenceto ACCOUNTS.


1000 NEWPSWD Transaction


One of the security features of Datadictionary is the use of passwords.Datadictionary allows a password to be assigned to an occurrence. Anymaintenance of these occurrences requires the use of the password.Additionally, Datadictionary provides a transaction through which the passwordmay be changed.

It should be noted that the -UPD transaction carries certain restrictions thatcannot be overridden by the use of the password and override codes. Forthese and other restrictions, see the section on protecting definitions in the CADatacom Datadictionary User Guide.

The password is an optional 1- to 4-character code. Maintenance of an existingoccurrence requires that the password entered exactly matches the passwordassigned to the occurrence. Failure to match the password causes themaintenance request to be rejected.

Assigning a Password

You assign a password at the time an occurrence is added or later. You canuse the same password for several or all occurrences or assign uniquepasswords, if desired.

To add a password when the occurrence is added, code the password in the-ADD transaction. For more information, see “Using the -ADD HeaderTransaction” on page 224.

To assign a password after an occurrence has been added without a password,use the following format:

-UPD entity,occ-name(vrs,,ovrd)1 NEWPSWD,pswd-END

Changing a Password

Once an occurrence has been assigned a password, it is possible through the1000 NEWPSWD transaction to change the password by processing the -UPDmaintenance transaction collection. The password change applies only to thespecific version of the occurrence coded in the version parameter of the headertransaction. Only occurrences in TEST or PRODuction status can have theirpasswords changed.

To change a password, code the -UPD header with the appropriate values.The override code is always required. Pay special attention to the versionparameter (vrs), as it designates which version is affected. Also, code thepresent password and any other applicable parameters, such as an override



code. Then code the 1000 NEWPSWD transaction after the -UPD headertransaction. An example follows:

-UPD entity,occ-name(vrs,pswd,ovrd)1 NEWPSWD,pswd-END

When an occurrence is copied, a new password can be applied to the copywith the 1000 NEWPSWD transaction. To give a new password to a copy, firstcode the -CPY header transaction with the appropriate values. Pay specialattention to the version parameter, as it designates which version is copied.Also, code the present password as well as any other applicable parameters,such as the override. Then code the 1000 NEWPSWD transaction with thenew password. The following is an example of the format for non-modeloccurrences: The format for CA Datacom/DB and CA FILE Model occurrencesincludes a target status/version.

-CPY entity,occ-name(vrs,pswd,ovrd)1 NEWPSWD,pswd-END

Note: If non-model occurrence Version 2 in TEST status is copied and TESTversions 3 and 4 already exist, then Version 5 receives the new password,since the copied version is given the next available version number.

Deleting a Password

To delete a password, first code the -UPD header with the appropriate values.Pay special attention to the version parameter (vrs), as it designates whichversion is affected. Also, code the present password and the override code ifrequired. Then code the 1000 NEWPSWD transaction and the headertransaction in the following format.

-UPD entity,occ-name(vrs,pswd,ovrd)1 NEWPSWD,&-END

The ampersand (&) resets the password to its default, which is no password.


1000 OBSOLETE Transaction


Use the 1000 OBSOLETE transaction to remove a structure or substructure inall statuses from Datadictionary. The OBSOLETE function is only valid for CADatacom/DB and CA FILE Model structures and substructures. TheOBSOLETE function has a greater impact than deleting each occurrence in thestructure or substructure individually. This transaction does not remove anysecondary structure related to an occurrence in a structure or substructure.

Note: You must use the SQL DROP statement to delete SQL accessibletables, views, or synonyms. For information, see the CA Datacom/DB SQLUser Guide.

Important: Due to the impact of the OBSOLETE function, we recommend thatthe authorization to use this function be restricted. See the person responsiblefor security administration on your system for information on restricting the useof functions.

Use the 1000 OBSOLETE transaction in conjunction with a -DEL headertransaction. Code the -DEL header transaction to identify the root of thestructure or substructure you wish to delete. Code the 1000 OBSOLETEtransaction as shown in the example following:


��──1──OBSOLETE────────────────────────────────────────────────────��


The following is an example of the 1000 OBSOLETE transaction:

-DEL DATABASE,ORDER-ENTRY 1 OBSOLETE -END

This example removes all occurrences of the ORDER-ENTRY DATABASEstructure. No status is specified in the -DEL header transaction since alloccurrences of this DATABASE structure will be deleted regardless ofstatus/version.


1000 RESTORE Transaction


Use the 1000 RESTORE transaction to reconstruct a CA Datacom/DB structureor substructure in a TEST status/version from the version of the structure orsubstructure in PRODuction or HISTory status.

Important: CA recommends that you restore the structure or substructurefrom PRODuction status immediately before you change it to avoid any loss ofinformation.

When you submit a RESTORE transaction, the DDD-SYNCH attribute value isset to N for all tables in the structure. If a subsequent COPY to PRODuctionstatus is issued at the database level, all tables will be DDD-SYNCH=N insteadof just the modified table(s). This results in all plans associated with the tablesbeing flagged invalid. All plans must then be rebound -- either manually orautomatically when next referenced. To eliminate unnecessary rebinds, copyonly the modified tables back to PRODuction status before you change them toavoid any loss of information.

How It Works

You can use the date/time stamp (ASOF) to construct a TEST version of whatyour PRODuction or HISTory status version looked like on that day. Using thedate/time stamp, you can determine which structures and substructures were inPRODuction status at a given time and re-create the structure or substructurein the specified TEST status. If you want to restore a HISTory version toPRODuction, you must first restore it to TEST and then use the -COPYtransaction to copy it to PRODuction status.

Note: If your time value includes seconds, round up to the nearest minute.

When you restore a TEST structure or substructure, Datadictionary replaces theentire structure or substructure with a copy of the one you specified in the -UPDheader transaction. Any occurrences or relationships are deleted or added asnecessary to make the restored structure or substructure the same as the onefrom which it is being restored.

Required Definitions

If you are restoring a substructure, the parent entity-occurrence definition mustexist in the same version to which you are restoring the occurrence. Forexample, if you are restoring a TABLE substructure to T001 status, theDATABASE and AREA entity-occurrence definitions for that TABLE must existin T001 status for the RESTORE to be successful.



From HISTory Status

When you restore a structure or substructure from HISTory status,Datadictionary returns an error message if any of the related occurrences havebeen deleted. The occurrences could be deleted because the maximumnumber of HISTory versions allowed has been exceeded. Datadictionaryreturns an error message if the structure is incomplete due to deletedoccurrences of this type.

Relationships

If the structure contains relationships with occurrences outside the structure, therelationships may not be restored with the structure or substructure. Thecopy-rule specified for the relationship will determine whether the relationship isrestored. For more information about relationship copy-rules, see the CADatacom Datadictionary User Guide.

Constraints

When a structure that has related constraints is restored, all constraints arecopied to the TEST status/version. However, subsequent maintenance of thestructure through SQL causes Datadictionary to change the CONSTRAINTattribute on the altered table to A for all TEST and HISTory versions of thetable. If you later attempt to copy one of these versions (or a structurecontaining one of these versions) to PRODuction status, Datadictionaryprevents the copy, issues an error message, and identifies the table which hasbeen altered. For further instructions, see Appendix C, “Maintaining Tableswith Related Constraints” on page 605.

How to Use

Code the -UPD header transaction, anchoring on the PRODuction status orHISTory status structure you want to restore. Code the 1000 RESTOREtransaction as shown in the following example:


��──1─ ──RESTORE,vrs ────────────────────────────────────────────────��

,vrs This is the TEST version to which you want the structure or substructurerestored.



Example Transaction Collections:

The following are examples of the 1000 RESTORE transaction:

-UPD DATABASE,ORDER-ENTRY(ASOF),19911211357 1 RESTORE,T123 -END

This example restores to Version T123 the ORDER-ENTRY DATABASEstructure that was in PRODuction status on December 1, 1991 at 1:57 PM.

-UPD DATABASE,ORDER-ENTRY(PROD) 1 RESTORE,T23 -END

This example restores the current PRODuction status version of theORDER-ENTRY database to TEST version T023.


1000 SET Transaction


The 1000 SET transaction is valid only with the DATABASE structure. Use it togenerate valid attribute-values that were not provided at the time theoccurrences were added in a DATABASE structure. This includesattribute-values for system-maintained attributes. The SET function alsocompletes certain attribute-values required by CA Dataquery.

The SET function is invoked during the execution of the COPY function (onlywhen copying an occurrence in the DATABASE structure to PRODuctionstatus) and the CATALOG and BUILD functions of DDCFBLD. Use the 1000SET transaction before you catalog CA Datacom/DB structures that are inTEST statuses.

If you add a database occurrence to Datadictionary and attempt to copy thestructure to PRODuction status without using the 1000 SET transaction toassign DATACOM-IDs to the substructure occurrences, you will receive thefollowing message. Datadictionary then assigns a unique DATACOM-IDattribute-value to the PRODuction status occurrence.

WARNING DATACOM-ID ZERO

Attributes are assigned values by the SET function according to the followingrules:

1. If no value has been previously assigned to the attribute, the SET functionwill ensure that a value is assigned.

2. If the attribute is a non-modifiable attribute (one which you cannot accessfor update purposes) and other changes have been made to the occurrencewhich affect the current value, then the SET function will ensure that a newvalue is assigned.

3. If the attribute is a modifiable attribute (one which you can access forupdate purposes) and a value has been previously assigned, the SETfunction will not change that value. You can manually modify the value, oryou can force assignment of a new value.

To force the SET function to assign a new value to modifiable attributeswhich previously had a value, reset the attribute-value to its default value,then submit a 1000 SET transaction against the DATABASE structure. Formore information about default values, see page 240.

4. If the FIELD attributes, AGR-AUTHID, AGR-SQLNAME, and SQLNAME donot exist, you can use the SET transaction to update the DATABASEstructure which updates the table in which the fields exist.



TABLE Occurrence

The following are the TABLE occurrence attributes that are assigned during theSET function:

CLUSTER-KEY-IDValue that is unique for all TABLE and KEY occurrences in theDATABASE structure. (Clustering is a space management option that youspecify in the AREA occurrence. See the CA Datacom/DB Database andSystem Administration Guide for information on clustering.)

CNS-DOMAINFor SQL processing, at least one field (column) in the table has aconstraint. For details, see the CA Datacom/DB SQL User Guide. Yindicates yes, N indicates no.

CNS-REFERENCEDFor SQL processing, the table contains a unique key which is the foreignkey of some other table. For details, see the CA Datacom/DB SQL UserGuide. Y indicates yes, N indicates no.

CNS-REFERSFor SQL processing, the table contains a foreign key. For details, see theCA Datacom/DB SQL User Guide. Y indicates yes, N indicates no.

CNS-SAME-BASEFor SQL processing, the constraint references are within the samedatabase related to this table. For details, see the CA Datacom/DB SQLUser Guide. Y indicates yes, N indicates no.

CNS-UNIQUEFor SQL processing, the table contains a unique key. For details, see theCA Datacom/DB SQL User Guide. Y indicates yes, N indicates no.

CONSTRAINTFor SQL processing, the table contains at least one field (column) or keythat is constrained. For details, see the CA Datacom/DB SQL UserGuide. Y indicates yes, N indicates no.

DATA-BASE-NAMEName of the DATABASE occurrence that is the root of the structure.

DATA-BASE-VERSVersion of the DATABASE occurrence that is the root of the structure.

DATACOM-IDValue that is unique for all TABLE occurrences in the DATABASEstructure.

DB-MASTER-KEYDATACOM-NAME attribute-value of the KEY occurrence specified as thetable's Master Key. For information about Master Keys, see the CADatacom/DB Database and System Administration Guide.



DB-NATIVE-KEYDATACOM-NAME attribute-value of the KEY occurrence specified as thetable's Native Key. For more information about Native Keys, see the CADatacom/DB Database and System Administration Guide.

DD-ENTITY-TABLEIndicates if this table defines an entity-type in the DATA-DICT database.

DD-MASTER-KEYOccurrence name of the KEY specified as the table's Master Key.

DD-NATIVE-KEYOccurrence name of the KEY specified as the table's Native Key.

SQL-SECURITYContains the SQL-SECURITY attribute-value of the DATABASEoccurrence. This attribute-value is enforced only when security is enabledin the CA Datacom/DB Master List.

Y indicates that the SQL security of GRANT and REVOKE will be used.N indicates that the CA Datacom/DB Security Facility rules will be usedfor the SQL objects (TABLE, VIEW, SYNONYM or FIELD (columns)occurrences) in the DATABASE structure.

You cannot use a view based on tables from databases with differentSQL-SECURITY attribute-values. For more information about the CADatacom/DB Security Facility and SQL security, see the CA Datacom/DBDatabase and System Administration Guide.



KEY Occurrence

The following are the KEY occurrence attributes that are assigned during theSET function:

AGR-SQLNAMEThe SQL name of the table containing this key.

AUTHIDThe authorization identification (AUTHID) of the table.

SQLNAMEIf not previously assigned or if previously assigned SQLKEY,Datadictionary constructs this value as follows:

■ The name consists of the 5-character DATACOM-NAMEattribute-value of the key, followed by an underscore character,followed by the concatenation of the DATACOM-NAME attribute-valueof the table and the DATACOM-ID attribute-value of the databasecontaining the key. For example, a key with a DATACOM-NAME ofABCDE in table INV in database 00016 would have an SQLNAME ofABCDE_INV00016.

■ Any dashes or trailing blanks in the DATACOM-NAME are changed tounderscores. For example, a key in the previous example with aDATACOM-NAME of AB-CD would have an SQLNAME ofAB_CD_INV00016.

DATACOM-IDValue that is unique for all KEY occurrences in the DATABASE structure.

DATACOM-NAMEFor keys created through SQL processing, the value is created in theformat SQnnn where nnn are three digits selected for uniqueness.

For keys for user-defined entity definitions in the DATA-DICT database,the value is created in the format aaaKb, where aaa is theDATACOM-NAME of the table containing the key, K is a constant, and bis a single-character distinguishing code.

MAX-KEY-LENGTHLargest value of either the LENGTH or MAX-KEY-LENGTH attributes ofall KEY occurrences in the DATABASE structure with the sameDATACOM-ID attribute-value.



ELEMENT Occurrence

The following is the ELEMENT occurrence attribute that is assigned during theSET function:

DATACOM-NAMEOnly for DATA-DICT database for a user-defined entity:

Datadictionary constructs the attribute-value in the format aaacc, whereaaa is the DATACOM-NAME of the TABLE occurrence, and cc is RQ(required), ST (statistics) or US (user element).

FIELD Occurrence

If the TABLE occurrence is marked SQL-INTENT=Y or SQL-INTENT=R, thefollowing attribute-values are assigned during the SET function:

AGR-SQLNAMEThe SQL name of the table containing this field.

AUTHIDThe authorization identification (AUTHID) of the table.

SQLNAMEIf not previously assigned, Datadictionary constructs the name as follows:

1. The first 18 characters of the FIELD occurrence name are used.

2. Any dashes are changed to underscores.

3. If the FIELD occurrence name starts with a digit, Datadictionaryreplaces the first character with the character A, since an SQL namecannot start with a digit.

4. If the resulting name already exists in the table, the name is right filledwith character zeros (X'F0'), up to 18 bytes. If the name was 18 bytesor longer, then the last 3 characters are overlayed with zeros (X'F0').

5. The last three bytes of zeros are then used as a counter that isincremented until the SQL name generated is unique within the table.



How to Use

To use the 1000 SET transaction, code the -UPD header transaction to identifythe structure or substructure to which the transaction applies. Code the 1000SET as shown following:


��──1──SET─────────────────────────────────────────────────────────��


The following is an example of the 1000 SET transaction:

-UPD DATABASE,ORDER-ENTRY(T1,OR11) 1 SET -END


1000 TRANSFER Transaction


Use the 1000 TRANSFER transaction to move:

■ AREA substructure from one DATABASE structure to another■ TABLE substructure from one AREA substructure to another■ RECORD substructure from one FILE structure to another

The transfer implies disconnecting an occurrence from one subject andconnecting it to another. Transfers must be within the same status/version.Code the -UPD transaction to identify the structure or substructure.

The following is the format for the 1000 TRANSFER transaction.


��──1─ ──TRANSFER,parent-name ───────────────────────────────────────��

,parent-nameEnter the 1- to 32-character occurrence name to which the AREA, TABLEor RECORD occurrence in the header transaction is being transferred.

Valid Entries: 1- to 32-character occurrence name of a DATABASE,AREA or FILE



The following is an example of the 1000 TRANSFER transaction:

-UPD TABLE,ACCTS-REC(T1,OR11) 1 TRANSFER,ACCOUNTS -END

This transaction collection transfers the ACCTS-REC table in version T001 tothe area named ACCOUNTS (parent).


1000 VERIFY Transaction


Use the 1000 VERIFY transaction to check the validity of attribute-valueadditions and modifications to CA Datacom/DB DATABASE or FILE structures.You can also use this transaction with TABLE, RECORD, ELEMENT, and KEYsubstructures.

The VERIFY function checks errors such as a duplicate FILENAME andDATACOM-NAME, invalid DATACOM-ID, BLOCK-SIZE, and element LENGTH.The function checks for invalid or unacceptable data, but does not makecorrections. At the table and record level, it reestablishes the length ofcompound fields and offsets of every field in the table or record. It alsoreestablishes the length and offsets of the elements and keys.

For more information and a list of the attribute-values Datadictionary verifies,see “Verifying a DATABASE Structure” on page 272 and “Verifying a FILEStructure” on page 274.

The VERIFY function is invoked during the execution of the CATALOG function,the copy to PRODuction status function and the -CXX CATALOG function ofDDCFBLD. If the VERIFY function detects an error, Datadictionary generatesan error report. For information about the attribute-values assigned byDatadictionary, see “1000 SET Transaction” on page 264.

Code the -UPD header transaction to identify the occurrence. Place the 1000VERIFY transaction within the transaction collection.


��──1──VERIFY──────────────────────────────────────────────────────��


The following is an example of the 1000 VERIFY transaction:

-UPD DATABASE,ORDER-ENTRY(T1) 1 VERIFY -END

This transaction collection checks that the attribute-values defined foroccurrences in the ORDER-ENTRY database are valid.



Verifying a DATABASE Structure

The VERIFY function checks the following attribute-values of the followingoccurrences in a CA Datacom/DB Model structure.

DATABASE Occurrence

DATACOM-IDThe identifier is unique for all DATABASE occurrences in the same statusand is less than or equal to 5000.

AREA Occurrence

BLOCK-SIZESpecifies a value greater than or equal to the length of the largest table tobe stored in the area, including the CA Datacom/DB control information(bytes for recovery and overhead).

DATACOM-NAMEName is unique among the AREA occurrences within the DATABASEstructure. The first byte must be alphabetic and the other two bytes canbe alphanumeric. If the last two bytes are XX, the VERIFY will generate awarning, but you can still catalog the database.

DEVICESpecifies a valid device type.

TABLE Occurrence

CLUSTER-KEY-IDValue is greater than 0 only if the SPACE-MNGMNT attribute of the areahas a value of 3.

CLUSTER-KEY-LENValue is less than or equal to the LENGTH attribute-value of the NativeKey.

DATACOM-IDValue is unique among the TABLE occurrences within the DATABASEstructure.

DATACOM-NAMEName is unique among the TABLE occurrences in the DATABASEstructure. The first byte must be alphabetic and the other two bytes canbe alphanumeric. If the last two bytes are XX, the VERIFY will generate awarning, but you can still catalog the database.

ElementAt least one element is defined. No more than 255 elements are definedto the table.



ENTY-TYPEValue is valid.

KeyAt least one key is defined. At least one Master Key and one Native Keyare defined (can be same key). No more than 99 keys are defined to thetable and no more than 999 keys are defined to the database.

LengthSum of the lengths of the fields defined to the table does not exceed thevalue of the MAX-RECORD-SIZE attribute. The value is at least 1 andless than or equal to 32719.

MAX-RECORD-SIZEIf specified, value is at least 1 and less than or equal to 32719 bytes. Itmust also be consistent with the BLOCK-SIZE attribute-value of therelated AREA occurrence. (CA Datacom/DB uses this attribute-value forthe physical records on disk. If not specified, Datadictionary uses the sumof the lengths of the FIELD occurrences defined to the TABLEsubstructure.)

SQL-INTENTIf specified Y or R and the following entries are verified, SQL-ACCESSattribute-value is set to Y and the table will be accessible in SQLprocessing.

■ Valid SQL name for the table■ Valid authorization identifier name for the table■ FIELD occurrences in the table with valid SQL names

Note: The AUTHID and SQLNAME attribute-values of FIELDoccurrences can be set by Datadictionary. For more information, see“1000 SET Transaction” on page 264.

KEY Occurrence

DATACOM-IDKEY occurrences with the same DATACOM-ID value have the same dataformat for the length of the shorter key. The VERIFY generates a warningif there is a conflict in data types. You can still catalog the DATABASEstructure.

The DATACOM-ID for a key cannot match the CLUSTER-KEY-ID for atable in the same DATABASE structure.

DATACOM-NAMEName is valid and is unique for all KEY occurrences in the same table.

Key TypesOne Master Key and one Native Key are defined for the table (can besame key).



LengthIs greater than zero and less than or equal to 180 (maximum key length).

Note: If you create a key longer than 160 bytes, it will not be used byCBS or SQL, which uses CBS, under the following conditions:

■ In SQL for ORDER BY, GROUP BY, SELECT DISTINCT, UNION(without ALL), or index-merge. (SQL will use a sort, or a nested loopjoin.)

■ In a FOR statement for ORDER BY.

■ In RAAT SELFR when the length of columns in the RQA "K" section isgreater than 160 bytes.

ELEMENT Occurrence

DATACOM-NAMEName is valid and is unique for all elements in the same table.

LengthIs greater than zero.

Verifying a FILE Structure

The VERIFY function verifies the following occurrences in a CA FILE Modelstructure.

FILE Occurrence

LengthValue of BLOCK-SIZE attribute is a multiple of the MAX-RECORD-SIZEattribute.

RECORD Occurrence

ElementsReestablishes length and offsets.

FieldsReestablishes lengths and offsets. The SEQNO (sequence number)attribute-value is calculated and the REDEFINES attribute-value is set toC for a child of a REDEFINES=P or S field.

KeysReestablishes length and offsets.

LengthValue is at least 1 and less than or equal to 65535 bytes. Sum of thelengths of the fields defined to the record does not exceed the value ofthe MAX-RECORD-SIZE attribute for the related FILE occurrence.



ELEMENT Occurrence (If Any)


KEY Occurrence (If Any)


Verifying a TABLE Structure

The VERIFY function verifies the following occurrences in a CA Datacom/DBModel structure.

TABLE Occurrence

ElementsAt least one element is defined. No more than 255 elements are definedto the table. Reestablishes length and offsets.

FieldsAt least one field is defined. Reestablishes lengths and offsets. TheSEQNO (sequence number) attribute-value is calculated and theREDEFINES attribute-value is set to C for a child of a REDEFINES=P orS field.

KeysAt least one key is defined. At least one Master Key and one Native Keyare defined (can be same key). No more than 99 keys are defined to thetable. Reestablishes length and offsets.

LengthSum of the lengths of the fields defined to the table does not exceed thevalue of the MAX-RECORD-SIZE attribute. The value is at least 1 andless than or equal to 32719.

ELEMENT Occurrence (If Any)

LengthIs greater than zero and sets it.

KEY Occurrence (If Any)

LengthIs greater than zero and sets it.


1001 Author Controller Transaction

1001 Author Controller Transaction

Descriptive data (names of the author and controller) about an occurrence isprovided to Datadictionary by means of the 1001 transaction. The descriptivetransactions may accompany an -ADD, -CPY, or a -UPD header transactionwhen adding, copying or changing an occurrence. This transaction does notaffect the true definition of the occurrence. You supply this information forinternal documentation only.

If you do not code this transaction, the author and controller default to the nameentered in the -USR transaction.

Single quote marks must enclose the author or controller entries when theycontain delimiters — embedded punctuation (such as a comma or slash) orblanks.

The format for using the 1001 transaction follows:

��──11──author──controller──────────────────────────────────────────��

The parameters for the 1001 transaction follow:

authorThis 1- to 32-character alphanumeric parameter identifies the author ofthe information being stored for the occurrence.

controllerThis 1- to 32-character alphanumeric parameter identifies theorganizational group or person responsible for control of the occurrence.


The following is an example of the 1001 transaction:

-UPD TABLE,ACCTS-REC(18) 11 'RYDER, MIKE' BOSS -END

This transaction collection updates occurrence Version 18 to add the authorand controller names. The author's name is RYDER, MIKE and the controller isBOSS. Single quote marks enclose an author name since it includes both acomma and a blank. There are no delimiters used with the controller name, sosingle quotes are not required.


1002 Description Transaction

1002 Description Transaction

The 1002 Description transaction is used to provide a 1- to 36-characteralphanumeric description of an occurrence. This descriptive phrase appears onvarious Datadictionary reports. This transaction can be used with the -ADD,-CPY, or -UPD header transaction.

Single quote marks must enclose the description when it contains a delimiter --embedded punctuation (such as a comma or slash) or blanks.

Use the 1200 TEXT transactions for longer or additional comments about theoccurrence. For more information, see “1200 TEXT Transactions” on page 288.

The description transaction format follows:

��──12──description─────────────────────────────────────────────────��


The following is an example of the 1002 transaction:

-UPD DATABASE,ORDER-ENTRY(T123) 12 'DEMONSTRATION BASE, EDUCATION' -END

This transaction collection adds a description to the ORDER-ENTRY databasein status/version T123. The description is enclosed in single quotes since thereare embedded delimiters (blanks and a comma).


1003 Relationship Transactions


The 1003 Relationship transactions are used with the -ADD, -CPY, or -UPDheader transactions to perform the following functions:

1003 RELTImplements relationships between occurrences for both user-defined andpredefined relationships. Implements $INTERNAL relationships betweenELEMENT and DATAVIEW and between KEY and DATAVIEW.

1003 UNRLRemoves a defined relationship between a subject and object occurrencefor a given occurrence.

1003 DATASupplies information about the relationship.

1003 AFTEROrders the relationship.

Note: You can relate a person to a specific SQL authorization identifier byusing the 1003 RELT transaction. This transaction creates aPER-ATZ-AUTHID relationship which is a many-to-one relationship.

1003 RELT Transaction

Any two occurrences of the same or different entities may be logically relatedby a RELT transaction as long as the relationship has been defined toDatadictionary. Prior to using a 1003 RELT transaction for user-definedrelationships, the named entity relationships and the characteristics of theserelationships must be defined. For instructions about how to produce a reportof the relationship-types, see “Definitions Report” on page 446.

When implementing relationships where the subject entity and the object entityare the same, the position indicator must be coded on the 1003 RELTtransaction. This indicator specifies whether the occurrence being related tothe occurrence in the header transaction is the subject or object.

You can add data when you relate occurrences by including a 1003 DATAtransaction. For more information, see “1003 DATA Transaction” on page 281.

The format and descriptions for the 1003 RELT transaction parameters follow:

��──13─ ──RELT,entity, ──┬ ┬────────────── ──────────────────────────────� └ ┘─parent-name.─

�──occ-name(vrs),relationship-name─ ──┬ ┬────── ─────────────────────────�� └ ┘─,pos─



,entity,(Required) This parameter denotes the entity of the occurrence to whichthe header occurrence is being related.

Valid Entries: Existing entity-type name


parent-name.(Optional) Only valid if the occurrence is a FIELD, KEY, or ELEMENTentity. The occurrence name of the field, key, or element must beconcatenated with the RECORD or TABLE occurrence name andseparated from the occurrence name by a period.

Valid Entries: Valid RECORD or TABLE occurrence name


occ-name(Required) This parameter denotes the occurrence name being related.



(vrs)(Required) This parameter identifies the applicable version of theoccurrence named in the occurrence parameter.

Valid Entries: Valid 1- to 4-character alphanumeric version


,relationship-name(Required) This parameter denotes the name of the relationship definitionwhich represents the logical association between the header occurrenceand the related occurrence. The relationship-type must exist inDatadictionary before submitting this transaction.

The occurrence named in the 1003 transaction must already exist with thefollowing exception: if the relationship-type was defined as AUTOMATICand the occurrence is the object of the relationship, the occurrence neednot exist at the time it is used in the 1003 transaction. This is inanticipation of the addition of the occurrence at some later time. Whenthe occurrence is added, the relationship is automatically established.

Valid Entries: Valid relationship name




,pos (Optional) The position indicator is only required when the entity specifiedin the 1003 RELT transaction is the same as the entity in the headertransaction.

Specify that the occurrence being related to the occurrence in the headertransaction is the subject (S) or the object (O).

Valid Entries: S or O


1003 UNRL Transaction

Use the 1003 UNRL transaction to remove a defined relationship between asubject and object occurrence for a given occurrence. The format anddescription of parameters follows:

1003 UNRL Transaction

��─ ──UNRL,entity, ──┬ ┬────────────── ─occ-name(vrs),relationship-name────� └ ┘─parent-name.─

�─ ──┬ ┬────── ──────────────────────────────────────────────────────────�� └ ┘─,pos─

,entity,(Required) This parameter denotes the entity of the occurrence fromwhich the header occurrence is being unrelated.



parent-name.(Optional) Valid only if the occurrence is a FIELD, KEY, or ELEMENTentity. The occurrence name of the field, key, or element must beconcatenated with the record or table name and separated from theoccurrence name by a period.



occ-name(Required) This parameter denotes the name of the occurrence beingunrelated.





(vrs)(Required) This parameter identifies the applicable version of theoccurrence named in the occurrence parameter.



,relationship-name(Required) This parameter denotes the name of the relationship definitionwhich represents the logical association between the header occurrenceand the related occurrence.

Valid Entries: Existing relationship name


,pos(Optional) The position indicator is only required when the entity of the1003 UNRL transaction is the same as the entity in the headertransaction.

Specify whether the occurrence being unrelated to the occurrence in theheader transaction is the subject (S) or the object (O).

Valid Entries: S or O


1003 DATA Transaction

Use this transaction after the 1003 RELT transaction to add an explanationabout how the occurrences relate. This is called the intersection data.

You are limited to 60 bytes of information in this transaction. When you arespecifying your data using the online facilities or a DSF program, you can enterup to 72 bytes. The format and description of the 1003 DATA transactionparameters follow:

1003 DATA Transaction

��──13─ ──DATA,'user-data' ───────────────────────────────────────────��

,'user-data'Enter data as you intend Datadictionary to store it and expect it to appearon output reports. Enclose the text in single quotes. Datadictionary doesnot edit this data.

Valid Entries: Up to 60 bytes




1003 AFTER Transaction

This transaction relates two occurrences in an ordered manner and requiresthat the relationship be previously defined as an ordered relationship. Only usethis transaction after a 1003 DATA or a 1003 RELT transaction. The format anddescription of the 1003 AFTER transaction parameters follow:

1003 AFTER Transaction

��──13─ ──AFTER, ──┬ ┬────────────── occ-name(vrs) ──────────────────────�� └ ┘ ─parent-name.─

parent-name.(Optional) Only valid if the occurrence is a FIELD, KEY, or ELEMENTentity. The occurrence name of the field, key, or element must beconcatenated with the record or table name and separated from theoccurrence name by a period.



occ-name(Required) Enter whether you are relating the occurrence specified in theheader transaction at the beginning of an ordered chain or at the end ofan ordered chain or identify the occurrence after which the occurrencespecified in the header transaction will follow.

Valid Entries: Existing occurrence name$FIRST - beginning of chain$LAST - end of chain


(vrs)(Required) This parameter identifies the applicable version of theoccurrence named in the occurrence parameter of the header transaction.It is not required if you specify $FIRST or $LAST instead of an occurrencename.






The following is an example of the 1003 transactions:

-ADD DATAVIEW,ACCOUNTS-DVW(T1) 13 RELT,ELEMENT,ACCTS-REC.ACCTS-REC-ELM(T1),$INTERNAL 13 AFTER,$FIRST 13 RELT,ELEMENT,ACCTS-REC.ORD-ID-ELM(T1),$INTERNAL 13 AFTER,ACCTS-REC.ACCTS-REC-ELM(T1) 13 RELT,ELEMENT,ACCTS-REC.CUST-ID-ELM(T1),$INTERNAL 13 AFTER,$LAST 719 ACCOUNTS Y -END

This transaction collection adds dataview ACCOUNTS-DVW with the elementsACCTS-REC-ELM, ORD-ID-ELM and CUST-ID-ELM. It assigns an Assemblername of ACCOUNTS and specifies UPDATE-INTENT as Y for yes.


1101 Descriptor Transactions


The 1101 Descriptor transactions are used together with the -ADD, -CPY, or-UPD header transaction to establish or delete descriptors for the occurrencespecified in the header transaction. Each occurrence can have up to eightdescriptors. The descriptors can be added or deleted one at a time or all atonce.

You can add a descriptor to an occurrence or delete a descriptor from anoccurrence that is in any status except HISTory status. Before you can modifyan occurrence in PRODuction status, your user profile must specify that you areauthorized to do so.

The generalized formats for the 1101 transactions follow:

1101 ADD descriptor[,descriptor,...]Adds up to eight descriptors to the occurrence named in the headertransaction (-ADD, -CPY, or -UPD). Each descriptor is delimited from thenext by a comma or a blank.

1101 DEL descriptor[,descriptor,...]Deletes up to eight descriptors from the occurrence named in the -UPDtransaction. Each descriptor is delimited from the next by a comma or ablank.

The descriptor name can be from 1 to 32 alphanumeric characters. Forrestrictions, see the section on naming standards in the CA DatacomDatadictionary User Guide.




The following are examples of the 1101 transaction.

-UPD DATABASE,ORDER-ENTRY 111 ADD ACCOUNTS,BILLING-INFO,CUSTOMER-NAME,CUSTOMER-CREDIT -END

This transaction collection adds the descriptors ACCOUNTS, BILLING-INFO,CUSTOMER-NAME and CUSTOMER-CREDIT to the ORDER-ENTRYdatabase.

-UPD TABLE,ACCTS-REC(T1,OR11) 111 ADD ACCOUNTS BILLING-INFO -END

This transaction adds the descriptors ACCOUNTS and BILLING-INFO to theACCTS-REC table.

-UPD DATABASE,ORDER-ENTRY 111 DEL CUSTOMER-NAME -END

This transaction deletes the CUSTOMER-NAME descriptor from theORDER-ENTRY database.


1103 Alias Transaction


Each occurrence can have an alternative name or alias, which, like the primaryname for the occurrence, also uniquely identifies it. There is no limit to thenumber of aliases which can be recorded for an occurrence. Each alias mustbe unique within the entity-type of the occurrence.

Before you can modify an occurrence in PRODuction status, such as to add ordelete an alias, your user profile must specify that you are authorized to do so.See the person responsible for administering Datadictionary security at your sitefor authorization to perform this function. You cannot add or delete an aliasfrom a HISTory status occurrence.

The 1103 transactions, together with the appropriate header transactions, addor delete aliases for the occurrence specified in the header transaction. Aliasesare added or deleted one at a time.

The generalized formats for the 1103 transactions follow:

1103 ADD aliasAdds an alias to the occurrence named in the header transaction (-ADD,-CPY, or -UPD).

1103 DEL aliasDeletes an alias from the occurrence named in the -UPD headertransaction.

The alias name can be from 1 to 32 alphanumeric characters. It is a uniquealternate name for the occurrence named in the header transaction. See thesection on naming standards in the CA Datacom Datadictionary User Guide forrestrictions.

Aliases for occurrences need only be unique in their entity-type. For example,the PROGRAM entity and SYSTEM entity could each have an occurrence withthe alias of MASTER.

Each alias is maintained separately without regard to other aliases for the sameoccurrence. The alias can be the same as the primary name. Using thistechnique the alias becomes a secondary reference entry point.

The following example illustrates that different aliases can apply to only oneoccurrence, but may apply to more than one version of that occurrence:




The following are examples of the 1103 ADD alias transaction.

-UPD TABLE,ACCTS-REC(T1) 113 ADD ACCOUNTS -END -UPD TABLE,ACCTS-REC(T2) 113 ADD ACCOUNTS 113 ADD ORDERS 113 ADD RECEIVABLES -END

This example adds the alias ACCTS-REC for the existing TABLE occurrenceACCOUNTS version T1 in the first transaction collection. The aliasesACCOUNTS, ORDERS and RECEIVABLES for the existing TABLE occurrenceACCTS-REC version T2 are added in the second transaction collection.


1200 TEXT Transactions


Use the 1200 TEXT transactions with the -ADD, -CPY, or -UPD headertransactions to maintain text that is associated with an occurrence. Text isassociated with the occurrence in a particular version. It is not associated withthe entity-type.

You can specify several different types of text with an occurrence and classifyeach type of text with a text classification name. Text lines can be added,deleted, inserted, or replaced. Shared text cannot be updated.

Each 1200 TEXT transaction collection is ended with a 1200 TEXT ENDtransaction. The following lists the types of 1200 TEXT transactions:

1200 TEXT ADDAdds text to a specific occurrence. See “1200 TEXT ADD Transaction” onpage 289.

1200 TEXT CLSSpecifies a text classification for a specific occurrence. See “1200 TEXTCLS Transaction” on page 290.

1200 TEXT DELDeletes existing text lines. See “1200 TEXT DEL Transaction” onpage 294.

1200 TEXT INSInserts text lines. See “1200 TEXT INS Transaction” on page 295.

1200 TEXT REPReplaces existing text lines. See “1200 TEXT REP Transaction” onpage 296.

1200 TEXT ENDSignals the end of a 1200 TEXT transaction collection.

Text is stored and reported in the format it is entered. Datadictionary does notperform any editing or reformatting. Each line of text can contain up to 80bytes.

The 1200 TEXT transactions designate the specific action for Datadictionary toperform as well as the range of text lines being changed. You can add text toan occurrence or delete text from an occurrence in a specified text classificationthat is in any status except HISTory status.

When you delete all the lines of text associated with a text classification, theclassification is also deleted.

Before you can modify an occurrence in PRODuction status, your user profilemust specify that you are authorized to do so.



Important: Do not use the 1000 APPLY or the 1000 MODEL transactions andthe 1200 TEXT transactions in the same DDUPDATE transaction collection foran occurrence. Doing this will generate an error.

1200 TEXT ADD Transaction

Use the 1200 TEXT ADD transaction to add text lines for the occurrencespecified in the header transaction. Text information for the occurrence andversion identified must not already exist prior to submitting this transaction.

You can specify a specific classification name with a 1200 TEXT CLStransaction. If this transaction is not included or if the text classificationparameter is not coded, the Datadictionary will use STANDARD (the systemdefault) for the text class name. For details on coding the 1200 TEXT CLStransaction, see “1200 TEXT CLS Transaction” on page 290.

The format for the 1200 TEXT ADD transaction follows. Use the 1200 TEXTEND transaction to signal the end of all 1200 TEXT transactions for theoccurrence being maintained.

1200 TEXT ADd Transaction (TEXT ADD, Step 1)

��──12──TEXT──ADD───────────────────────────────────────────────────��

1200 TEXT ADD Transaction (TEXT ADD, Step 2)

��──text──────────────────────────────────────────────────────────────��

1200 TEXT ADD Transaction (TEXT ADD, Step 3)

��──12──TEXT──END───────────────────────────────────────────────────��

textEnter the text you are adding as you intend Datadictionary to store it andas you expect it to appear on output reports. All text entered between the1200 TEXT ADD transaction and the 1200 TEXT END transaction isadded as text for the occurrence identified in the header transaction.

Note: If you plan to maintain text online that you are adding through thebatch transactions, limit text characters to 72 characters per line for textpanels with a TEXT MAINT session status of NUM (numbered margins) orto 79 characters per line for text panels with a TEXT MAINT sessionstatus of NONUM (no numbered margins).

Do not code a header transaction or a 1200 transaction as the leftmostcharacters in any line.

Valid Entries: Up to 80 bytes per line




1200 TEXT CLS Transaction

Use the 1200 TEXT CLS transaction with the -ADD or -UPD header transactionand the appropriate 1200 TEXT ADD, DEL, INS or REP transactions tomaintain text in a specific text classification. You can also use the 1200 TEXTCLS transaction after a 1200 TEXT ADD transaction with the -BTG headertransaction. See Chapter 2, “DDBTGLM - Generating Batch Transactions” forinformation on using this header transaction.

You can use the 1200 TEXT CLS transaction to rename the classification oftext for a specific occurrence with an -UPD header transaction.

Use the -CPY header transaction with the 1200 TEXT CLS transaction to copytext classification and associated text from one version of an occurrence toanother. You can specify whether the text is owned or shared by the format ofthe transaction that you use.

Naming a Text Classification

To name a text's classification for an occurrence, use the following transactionwith an -ADD or -UPD header transaction.

Naming a Text Classification

��──12──TEXT──CLS──txtclass1────────────────────────────────────────��

txtclass1(Required) Enter the text classification of the text you are adding.

Valid Entries: New text classification name


Renaming a Text Classification

To rename a text's classification for an occurrence, use the followingtransaction with the -UPD header transaction. You can rename the text whileinserting or replacing text.

Renaming a Text Classification

��──12──TEXT──CLS─ ──txtclass1 ──┬ ┬──────────── ───────────────────────�� └ ┘ ─,txtclass2─

txtclass1(Required) Enter the text classification of the text you are renaming.

Valid Entries: Existing text classification name




,txtclass2(Optional) Only required if you are assigning a name other thanSTANDARD. Use the naming conventions established for Datadictionary.For more information, see the section about naming standards in the CADatacom Datadictionary User Guide.

Valid Entries: 1- to 32-character text classification

Default Value: STANDARD

Copying Text Classifications

A -CPY header transaction without a 1200 TEXT CLS transaction results inshared text classifications of the source occurrence with the target occurrence.Except where noted in the following sections, the result of the 1200 TEXT CLStransactions is a copy of the text that is owned by the target occurrence.

If you enter a text classification name that already exists for the targetoccurrence, Datadictionary returns an error message. You must delete theexisting text classification (owned or shared) before you can copy it to this textclassification or you must specify a new text classification.

You can use the -CPY header transaction and a combination of 1200 TEXTCLS transactions to specify the following:

■ Copying a specific text classification to a new text classification

■ Copying a specific text classification to the same text classification

■ Copying all text classifications to the same text classifications

■ Copying all text classifications to a new single text classification

■ Copying all text classifications to the same text classifications with specificexceptions

■ No text copied

Each type of copy function is described in the following sections:

Copying Text to a New Text Classification

Use the following transaction to copy the text classification of the sourceoccurrence to new text classification for the target occurrence specified in the-CPY header transaction.

Copying Text to New Text Classification

��──12──TEXT──CLS─ ──txtclass1 ──┬ ┬──────────── ───────────────────────�� └ ┘ ─,txtclass2─



txtclass1(Required) Enter the text classification of the source occurrence you arecopying.

Valid Entries: Existing text classification


,txtclass2(Optional) Enter the new text classification of the target occurrence beingcreated. Use the naming conventions established for Datadictionary. Formore information, see the section on naming standards in the CADatacom Datadictionary User Guide.



Copying Text to the Same Text Classification (Sharing)

Use the following transaction to share a specific text classification or all textclassifications of the source version of the occurrence with the target versionspecified in the -CPY header transaction.

Copying Text to Same Text Classification (Sharing)

��──12──TEXT──CLS──txtclass1────────────────────────────────────────��

txtclass1Enter the text classification of the source occurrence.

Valid Entries: Existing text classification of the source occurrenceALL

Default Value: ALL

Copying All Text to the Same Text Classifications

Use the following transaction to copy all text classifications of the sourceoccurrence to the target occurrence. The source occurrence and targetoccurrence are specified in the -CPY header transaction. The resulting textclassifications are owned by the target occurrence.

Copying All Text to Same Text Classification

��──12──TEXT──CLS──ALL,ALL──────────────────────────────────────────��



Copying All Text to a New Text Classification

Use the following transaction when you want to copy all text classifications ofan occurrence to a single new text classification for the new occurrence. Theoccurrences are specified in the -CPY header transaction, the text classificationis specified as follows:

Copying All Text to New Text Classification

��──12──TEXT──CLS─ ──ALL,txtclass1 ───────────────────────────────────��

,txtclass1(Required) Enter the new text classification name. Use the namingconventions established for Datadictionary. For more information, see thesection about naming standards in the CA Datacom Datadictionary UserGuide.



Excluding a Specific Text Classification from Copy or Share

You can exclude specific text classifications from being copied or shared byusing the following transaction collection:

■ -CPY header transaction

■ 1200 TEXT CLS ALL,ALL transaction

■ 1200 TEXT CLS with the name of the text classification being excluded,followed by NOTEXT

■ -END transaction

The NOTEXT parameter following the text classification indicates toDatadictionary that this text classification is not being copied or shared. Theformat for this function follows:

Text Classification Not Being Copied or Shared

��──12──TEXT──CLS─ ──txtclass1,NOTEXT ────────────────────────────────��

txtclass1(Required) Specifies the text classification being excluded from the copyfunction.



The following example illustrates copying all text classifications to the same textclassifications, with specific exceptions. Assume that text exists inclassifications SYSPROG, GENERAL, and DEVPROG.



12 TEXT CLS ALL,ALL 12 TEXT CLS SYSPROG,DBA 12 TEXT CLS DEVPROG,NOTEXT 12 TEXT END

All text classifications (SYSPROG, GENERAL, and DEVPROG) of the sourceoccurrence are being copied to the target occurrence, with the exception ofSYSPROG and DEVPROG.

SYSPROG of the source occurrence is being copied into DBA of the targetoccurrence, GENERAL of the source occurrence is being shared by the targetoccurrence and DEVPROG is neither being copied or shared by the targetoccurrence, indicated with the NOTEXT parameter.

No Text Copied

You can exclude all text from being copied or shared by using the -CPY headertransaction and the following 1200 TEXT CLS transaction:

No Text Copied

��──12──TEXT──CLS──NOTEXT───────────────────────────────────────────��

1200 TEXT DEL Transaction

Use the 1200 TEXT DEL transaction to delete lines in text for the occurrencespecified in the -UPD header transaction and in the text classification specifiedin the 1200 TEXT CLS transaction.

If the 1200 TEXT CLS transaction is not included or if the text classificationparameter is not coded, the classification defaults to STANDARD. For moreinformation, see “1200 TEXT CLS Transaction” on page 290.

The following is the format for a 1200 TEXT DEL transaction collection.

1200 TEXT CLS Transaction (TEXT DEL, Step 1)

��──12──TEXT──CLS─ ──┬ ┬─────────── ───────────────────────────────────�� └ ┘ ─txtclass1─

1200 TEXT DEL Transaction (TEXT DEL, Step 2)

��──12──TEXT─ ──DEL,begin-sequence ──┬ ┬─────────────── ────────────────�� └ ┘ ─,end-sequence─

1200 TEXT END Transaction (TEXT DEL, Step 3)

��──12──TEXT──END───────────────────────────────────────────────────��



txtclass1(Optional) Enter the text classification associated with the text you aredeleting.



,begin-sequence(Required) Enter this parameter to designate the beginning line numberof text being deleted. If only one line of text is being deleted, only thebegin-sequence parameter is needed.

Obtain line numbers by running the Text Report For more information,about running this report, see “Text Report” on page 553.

Valid Entries: 1- to 6-digit sequence number


,end-sequence(Optional) Enter this parameter to designate the ending line number oftext you are deleting. You can obtain line numbers by running the TextReport. For more information about running this report, see “Text Report”on page 553. If only one line of text is being deleted, omit thisparameter.


Default Value: Sequence number specified in begin-sequenceparameter

1200 TEXT INS Transaction

Use the 1200 TEXT INS transaction to insert text lines for the occurrencespecified in the -UPD header transaction and the text classification specified inthe 1200 TEXT CLS transaction.


The following is the format for a 1200 TEXT INS transaction collection:

1200 TEXT CLS Transaction (TEXT INS, Step 1)


1200 TEXT INS Transaction (TEXT INS, Step 2)

��──12──TEXT─ ──INS,begin-sequence ───────────────────────────────────��



Text (TEXT INS, Step 3)

��──text──────────────────────────────────────────────────────────────��

1200 TEXT END Transaction (TEXT INS, Step 4)

��──12──TEXT──END───────────────────────────────────────────────────��

txtclass1(Optional) Enter the text classification associated with the text you areupdating.



,begin-sequence(Required) Enter this parameter to designate the line number after whichyou want to insert text. You can enter LAST to indicate that the text willbe appended to the end of the existing text or if no text exists for thespecified class, the text will be added.

Obtain line numbers by running the Text Report. For more informationabout running this report, see “Text Report” on page 553.

Valid Entries: LAST or 000001—999999


text(Required) Enter the text you are inserting as you intend Datadictionaryto store it and as you expect it to appear on output reports.

Note: If you plan to maintain text online that you are inserting throughthe batch transactions, limit text characters to 72 characters per line fortext panels with a TEXT MAINT session status of NUM (numberedmargins) or to 79 characters per line for text panels with a TEXT MAINTsession status of NONUM (no numbered margins).

Do not code a header transaction or a 1200 transaction as the leftmostcharacters in any line.

Valid Entries: Up to 80 bytes per line


1200 TEXT REP Transaction

Use the 1200 TEXT REP transaction to replace text lines for the occurrencespecified in the -UPD header transaction and in the text classification specifiedin the 1200 TEXT CLS transaction.




The following is the format for a 1200 TEXT REP transaction collection.

1200 TEXT CLS Transaction (TEXT REP, Step 1)


1200 TEXT REP Transaction (TEXT REP, Step 2)

��──12──TEXT─ ──REP,begin-sequence ──┬ ┬─────────────── ────────────────�� └ ┘ ─,end-sequence─

Text (TEXT REP, Step 3)

��──text──────────────────────────────────────────────────────────────��

1200 TEXT END Transaction (TEXT REP, Step 4)

��──12──TEXT──END───────────────────────────────────────────────────��

txtclass1(Optional) Enter the text classification associated with the text you arereplacing.



,begin-sequence(Required) Enter this parameter to designate the beginning line of thetext you want to replace. If only one line of text is being replaced, onlythe begin-sequence parameter is needed.




,end-sequence(Optional) Enter this parameter to designate the ending line number oftext you want to replace. If only one line of text is being replaced, omitthis parameter.



Default Value: Sequence number specified in begin-sequenceparameter



text(Required) Enter the text you are replacing as you intend Datadictionaryto store it and as you expect it to appear on output reports.

Note: If you plan to maintain text online that you are replacing throughthe batch transactions, limit text characters to 72 characters per line fortext panels with a TEXT MAINT session status of NUM (numberedmargins) or to 79 characters per line for text panels with a TEXT MAINTsession status of NONUM (no numbered margins).

Do not code a header transaction or the 1200 transaction as the leftmostcharacters in any line.

Valid Entries: Up to 80 text characters per line


You can code multiple 1200 DEL, 1200 INS and 1200 REP transactions at onetime, as long as you use only one 1200 TEXT END transaction.


The following is an example of an -ADD transaction collection with a 1200TEXT CLS, 1200 TEXT ADD and a 1200 TEXT END transaction:

-ADD DATABASE,ORDER-ENTRY 11 'MORNING, RUTH' ACCOUNTS-RECEIVABLES 12 TEXT CLS ACCOUNTS 12 TEXT ADD THE ORDER-ENTRY DATABASE CONTAINS THE INFORMATION RELATED TO ACCOUNTS, ORDERS and RECEIVABLES. IT IS MAINTAINED BY THE VARIOUS SUBSYSTEMS THAT MAKE UP THE ORDER ENTRY APPLICATION SYSTEM. IT IS USED FOR REPORTING BY THESE SAME SUBSYSTEMS AS WELL AS THE MANAGEMENT REPORTING SYSTEM AND ACCOUNTING REPORT SYSTEM. 12 TEXT END 29 3 -END

This transaction collection adds:

■ Database of ORDER-ENTRY with an ID of 003■ Author, Ruth Morning■ Controller, ACCOUNTS-RECEIVABLES■ Text classification of ACCOUNTS■ Text

An example of a -UPD transaction collection with a 1200 TEXT CLS and a1200 TEXT REP transaction follows:

-UPD DATABASE,ORDER-ENTRY 12 TEXT CLS ACCOUNTS,DBA 12 TEXT REP,6 SYSTEM AND ACCOUNTING REPORTING SYSTEM. 12 TEXT END -END



This transaction collection renames the text classification from ACCOUNTS toDBA for this occurrence and replaces line 6 of the text.


1500 Attribute Value Update Transaction


Use the 1500 transaction with the -ADD, -CPY, -UPD, or -UPG headertransaction to change an updatable attribute-value. The 1500 transaction isespecially useful if you only need to change one or two attribute-values for theoccurrence since you can enter multiple 1500 transactions in a transactioncollection.

Restrictions: If you update an attribute-value that changes the physical layoutor length of a record, see the section on modifying Datadictionary definitions inthe CA Datacom/DB Database and System Administration Guide.

There are restrictions to updating certain attributes of an occurrence related toa constraint, see Appendix C, “Maintaining Tables with Related Constraints” onpage 605. For details about all attribute-values, see the CA DatacomDatadictionary Attribute Reference Guide.

The following is the format for the 1500 Attribute Value Update transaction:


��──15─ ──attribute,value ────────────────────────────────────────────��

attributeEnter the name of the attribute as it appears on the Field Report of theTABLE occurrence for the entity-type in the DATA-DICT database.

,valueEnter the value you wish the attribute to have. If the attribute has adefault value, you can enter an ampersand (&) to return the attribute-valueto the default.


The following are examples of the 1500 transaction.

-UPD DATABASE,ORDER-ENTRY(T123) 15 DATACOM-ID,31 -END

This transaction collection changes the existing DATACOM-ID of the databaseto 031.

-ADD TABLE,ACCTS-REC(T12) 15 DATACOM-ID,41 15 DATACOM-NAME,ACT -END

This transaction collection adds the TABLE occurrence ACCTS-REC VersionT102 with the DATACOM-ID of 041 and the DATACOM-NAME of ACT.



-UPG PROGRAM,ABC(TEST) 15 AUTHOR,SMITH -END -UPG PROGRAM,ABC(PROD) 15 AUTHOR,SMITH -END

These transaction collections change the AUTHOR attribute of all PROGRAMoccurrences whose occurrence-name begins with ABC to SMITH in both TESTand PRODuction status.


2000 Relationship Transaction


Datadictionary not only provides predefined entities, such as FIELD and KEY,but also predefined relationships between the entities. The relationships depictthe structure between the various entities.

In addition to the standard relationship definitions provided with Datadictionary,you can define other relationships to tailor Datadictionary to specificrequirements.

Use the -ADD RELATIONSHIP header transaction and the 2000 Relationshiptransaction to describe the characteristics of the relationship. End thetransaction collection with an -END transaction. This transaction collection iscalled a relationship definition.

Important: Only use this transaction with prior approval of the personresponsible for administering Datadictionary at your site.

Using the -ADD Relationship Transaction

The -ADD Relationship header transaction defines the subject and object,optionally defines a password, defines a system override code and establishesa name for the relationship. The format for the -ADD Relationship headertransaction follows:

��──-ADD─ ──RELATIONSHIP,subject.object(, ──┬ ┬────── ,ovrd),name ─────────�� └ ┘ ─pswd─

,subject.(Required) Identifies the entity which is the subject of the relationship.



object(Required) Identifies the entity which is the object of a relationship.

Valid Entries: Exiting entity-type name


pswd(Optional) Assigns a password to the relationship definition. Thepassword provides protection against unauthorized access. Omit this fieldif this protection is not desired.

Valid Entries: 1- to 4-character password




,ovrd(Required) Identifies the system override code which allows you to addthe relationship definition. If you do not assign a password, you mustprecede the override code with two commas.



,name(Required) Establishes the name for the relationship being defined.




The 2000 Relationship transaction defines the characteristics of the relationship.The format for this portion of the relationship definition transaction follows. Inthe description of parameters that follows the format, words in parentheses arethe attribute names and the names that appear on Datadictionary panels orreports.


��──2──map──req──aut──ord──cpy──mdl────────────────────────────────��

Words in parentheses are names that appear on reports or panels.

StartingPosition

Length Description

1 4 Enter 2000 as the transaction code.(DDMAINT-REC-TYP)

6 2 Enter the mapping mode. (OCC-MAP-RULE-MAP)

Valid Entries: 11 - One-to-one1M - One-to-manyM1 - Many-to-oneMM - Many-to-many

Default Value: MM

9 1 Specify if the relationship is required.(REQUIRED-RULE-REQ)

Valid Entries: N or Y

Default Value: Y




The following is an example of the relationship transaction collection:

-ADD RELATIONSHIP,SYSTEM.REPORT(,,),SYS-RPT-GENERATE 2 1M N N Y B B -END

StartingPosition

Length Description

11 1 Specify if the relationship is automatic.(AUTO-RULE-AUT)


Default Value: Y

13 1 Specify if the relationship is ordered.(ORDERED-RULE-ORD)


Default Value: N

15 1 Specify the copy option. (COPY-RULE-CPY)

This option defines the relationship processing which isperformed when an occurrence is copied to either anew version or status.

The M attribute-value of the COPY-RULE has specialimplications for relationships between occurrences inthe CA Datacom/DB or CA FILE Model structures andnon-Model occurrences. For more information, see theCA Datacom Datadictionary User Guide.

Valid Entries: B, M, N, O, or S

Default Value: B

17 1 Specify the model option. (MODEL-RULE-MDL)

This option defines the relationship processing to beperformed when an occurrence is used as a model tocreate a new occurrence.

Note: The model-rule does not apply to relationshipsbetween occurrences in the CA Datacom/DB or CAFILE Model structures and other occurrences. Refer tothe CA Datacom Datadictionary User Guide for details.

Valid Entries: B, N, O, or S

Default Value: N



This transaction collection creates the SYS-RPT-GENERATE relationshipbetween the SYSTEM entity and the REPORT entity. The 2000 transactionspecifies the following:

■ The relationship mapping allows one SYSTEM occurrence to be related tomany REPORT occurrences.

■ It is not a required nor an automatic relationship for the occurrences.

■ When either occurrence is copied, the relationship is also copied.

■ When either occurrence is modeled, the relationship is also modeled.



2900 to 2901 DATABASE Transactions


Use the 2900-2901 DATABASE transactions to define and maintain a CADatacom/DB database.

Note: The 3000 DATABASE Transaction is replaced by 2900-2901DATABASE Transactions in this version.

To maintain a DATABASE occurrence use a transaction collection consisting ofthe following:

■ -ADD, -CPY, or -UPD header transaction■ Optional 1000 through 1500 transactions■ 2900 transaction■ Optional 2901 transaction■ -END transaction

The following are the transaction codes:

2900Specifies the database ID and characteristics with the following attributes:

DATABASE-ID BASE-TYPE DBMS-USED DDD-BASE-ID DL1T-CONSTRAINT DYNAMIC-EXTEND DYN-EXT-TRACKS

2901Describes the security and name with the following attributes:

SQL-SECURITY SQLNAME



2900 DATABASE Transaction

Use the 2900 DATABASE transaction to specify the database identificationnumber, the type of Database Management System used, the specific DBMSused, the database ID for the DDD, CA Datacom DL1 Transparency integrityprocessing and the selection of dynamic extension of the Index Area. It is onlyused to maintain DATABASE occurrences.

The format for the 2900 transaction follows. Words in parentheses are namesthat appear on reports or panels.

StartingPosition

Length Description


6 5 (Required) Enter a unique 5-digit database ID.Database IDs 1 through 20 are reserved for CA.(DATACOM-ID)

Database IDs over 999 have a few specialconsiderations:

■ We request that you reserve database IDs 1through 20, 1000 through 1020, 2000 through 2020,3000 through 3020, 4000 through 4020, and 5000through 5020 for CA to avoid conflict with systemdatabases now and in the future.

■ For CA Dataquery, if you have tables in databaseswith IDs greater than 999 that need to be secured,you must use external security for CA Dataquery.

■ The CA Datacom CICS Services supports UserRequirements Table (URT) numbers of 0 through999. Therefore, if you use database IDs greaterthan 999, you cannot match URT numbers withthose database IDs.



12 8 (Optional) Identify the type of database system withany code indicating the Database Management System,such as RELATION, NETWORK, HIER, INV-LIST. Usefor documentation purposes only when identifying auser-defined structure. (BASE-TYPE)





StartingPosition

Length Description

21 8 (Optional) Enter the type of Database ManagementSystem you are using to process this database.(DBMS-USED)


Default Value: DATACOM

30 5 (Optional) Enter a unique 5-digit database ID for theData Definition Directory. This parameter is ignored forall databases except DATA-DICT. When Datadictionaryis installed, this attribute-value is set to 00015. Werecommend that you use 00015. (DDD-BASE-ID)



36 1 (Optional) Indicate if the database is eligible for CADatacom DL1 Transparency integrity processing.(DL1T-CONSTRAINT)


Default Value: N

38 1 (Optional) This field allows CA Datacom/DB to extendthe Index Area (IXX) dynamically when it would havegiven a return code of 08 during an ADDIT command.(DYNAMIC-EXTEND)

When you code C instead of Y, you specify that theDYN-EXT-TRACKS value is the number of cylindersinstead of tracks in addition to the dynamic extend. Tochange back to tracks, code T. The change tocylinders allows CA Datacom to take advantage of anenhancement to z/OS environments so that dynamicextend in CA Datacom/DB and Datadictionary can begreater than 64K tracks.

Specifying Y, T, or C for this attribute does not implythat any areas in the database will be extendeddynamically. This only applies to the IXX for thisdatabase.

Specifying N indicates that no automatic extension ofthe index areas is to take place and normal 08 returncode processing will occur.

Valid Entries: C, N, T, or Y

Default Value: N



StartingPosition

Length Description

40 5 (Optional) Enter a 5-digit value for the number of tracksor cylinders by which CA Datacom/DB is to extend theIndex Area (IXX). (DYN-EXT-TRACKS)

This field is valid only when DYNAMIC-EXTEND is notspecified as N for this DATABASE occurrence. Youmust specify a non-zero value for DYN-EXT-TRACKS ifDYNAMIC-EXTEND is not N and you are running in az/VSE environment. A value of zero withDYNAMIC-EXTEND=Y on z/OS uses the data set'ssecondary extent amount. This value only applies to theIndex Area for this database.


Default Value: 0

2901 DATABASE Transaction

Use the 2901 DATABASE transaction to specify the SQL name and type ofsecurity. It is only used to maintain DATABASE occurrences.

Example Transaction Collection: The following is an example of theDATABASE occurrence transaction:

-ADD DATABASE,ORDER-ENTRY 29 1 -END

StartingPosition

Length Description


6 1 (Optional) Indicate if the database can be secured bySQL rules. (SQL-SECURITY)


Default Value: N

8 32 (Optional) This field is only required for SQLprocessing. Enter the SQL name for the DATABASEoccurrence. (SQLNAME)




3001 to 3004 AREA Transactions


Use the 3001 through 3004 transactions to identify the AREA occurrence'sDATACOM-NAME and characteristics. These transactions are only used tomaintain CA Datacom/DB AREA occurrences.

To maintain an AREA occurrence use a transaction collection consisting of thefollowing:

■ -ADD, -CPY, or -UPD header transaction■ Optional 1000 through 1500 transactions■ 3001 - 3004 transactions■ -END transaction

When adding an AREA occurrence, include a 1000 CONNECT transaction toconnect the AREA occurrence to a DATABASE occurrence.


3001Specifies the DATACOM-NAME attribute and the area's physical data setname with the following attributes:

DATACOM-NAME DATA-SET-NAME

3002Describes the area's characteristics with the following attributes:

ACCESS-MTHD BLOCK-SIZE DBMS-USED DD-NAME DEVICE RPS SLACK SPACE-MNGMNT

3004Identifies the DATA-DICT database ID, the SQL name of the area, andthe selection of dynamic extension of the data area with the followingattributes:

DATA-DICT-ID SQLNAME DYNAMIC-EXTEND DYN-EXT-TRACKS



3001 AREA Transaction

Use the 3001 transaction to add the CA Datacom/DB short name and the dataset name. The format for the 3001 transaction follows. Words in parenthesesare names that appear on reports or panels.

StartingPosition

Length Description


6 3 (Required) Enter a 3-character CA Datacom/DB shortname for the area. (DATACOM-NAME)

Valid Entries: Unique 3-character name


10 44 (Optional) Enter the physical data set name of thearea. (DATA-SET-NAME)




Use this transaction to describe the area's access method, data definitionname, maximum block size, type of device, type of Database ManagementSystem, the use of rotational position sensing, Space Management Options,and slack.


StartingPosition

Length Description


6 5 (Optional) Identify the access method used for anon-CA Datacom/DB area. Leave this attribute-valueblank for a CA Datacom/DB area. (ACCESS-MTHD)





StartingPosition

Length Description

12 8 (Optional) Enter the data definition name. (DD-NAME)



21 1 (Optional) Indicate if rotational position sensing isused. (RPS)


Default Value: Y

23 2 Reserved for use by CA Datacom products.

25 6 (Optional) Enter the disk device type where the arearesides. (DEVICE)

Valid Entries: MDISK, 3340, 3350, 3370, 3375,3380, 3390, 9345, 6421, 3330, 3330II

Default Value: 3380

32 5 (Required) Enter the area's physical block size inbytes. (BLOCK-SIZE)

Valid Entries: 512 - track size or 32767, whicheveris less


38 8 (Optional) Enter the type of Database ManagementSystem you are using. (DBMS-USED)



47 1 (Optional) Enter the CA Datacom/DB SpaceManagement Option. (SPACE-MNGMNT)

Valid Entries: 0, 1, 2, or 3

Default Value: 1

49 4 (Optional) Enter the number of bytes to be reserved ineach block of an area for the expansion of compressedrecords. (SLACK)






Use the 3004 transaction to identify the DATA-DICT database ID and the area'sSQL name. The format for the 3004 transaction follows. Words in parenthesesare names that appear on reports or panels.

StartingPosition

Length Description


6 5 (Optional) Enter a numeric ID for the DATA-DICTdatabase. When Datadictionary is installed, thisattribute-value is set to 00002. This attribute is ignoredfor all areas except the DDD-AREA. (DATA-DICT-ID)



12 32 (Required) This field is only required for SQLprocessing. Enter the AREA's SQL name.(SQLNAME)

See the section on naming standards in the CADatacom Datadictionary User Guide and the CADatacom/DB SQL User Guide for information.

Valid Entries: 1 to 18 characters if SQL Precompileroption SQLMODE=ANSI orSQLMODE=FIPS

1 to 32 characters if SQL Precompileroption SQLMODE=DATACOM




Example Transaction Collections: The following is an example of an AREAoccurrence transaction:

StartingPosition

Length Description

45 1 (Optional) This field allows CA Datacom/DB to extendthe data area dynamically when it would have given areturn code of 07 during an ADDIT command to a tablein that area. (DYNAMIC-EXTEND)

When you code C instead of Y, you specify that theDYN-EXT-TRACKS value is the number of cylindersinstead of tracks in addition to the dynamic extend. Tochange back to tracks, code T. The change tocylinders allows CA Datacom to take advantage of anenhancement to z/OS environments so that dynamicextend in CA Datacom/DB and Datadictionary can begreater than 64K tracks.

Do not code a Y, T, or C on the TTM-AREA area (forSQL) or the DQW area (for CA Dataquery).

Valid Entries: C, N, T, or Y

Default Value: N

47 5 (Optional) Enter a 5-digit value for the number of tracksby which CA Datacom/DB is to extend the data area.(DYN-EXT-TRACKS)

Specifying Y or T indicates the data area will beexpanded by the number of tracks specified in theDYN-EXT-TRACKS attribute. Specifying C indicates thedata area will be expanded by the number of cylindersspecified in the DYN-EXT-TRACKS attribute. SpecifyingN indicates that no extension of the data area is to takeplace and normal 07 return code processing will occur.

Do not code a C, T, or Y for DYNAMIC-EXTEND on theTIM-AREA or the DQW area for SQL and CADataquery, respectively. You should not code a C, T, orY for this attribute for any area containing one or moretables programmatically being filled up until a DB returncode 07 is reached.


Default Value: 0



-ADD AREA,ACCTS-REC(T1) 1 CONNECT,ORDER-ENTRY 31 ACR32 ACR1 Y 335 24 DATACOM 3 34 ACCTS_REC_ORD_ENTRY -END


3120 to 3122 FILE Transactions


Use the 3120 to 3122 transactions to maintain FILE occurrences. Issue atransaction collection consisting of the following:

■ -ADD, -CPY, or -UPD header transaction■ Optional 1000 through 1500 transactions■ Applicable 3120 to 3122 transactions■ -END transaction


3120Describes the occurrence's basic characteristics, including the DatabaseManagement System used, its device type, block size and record length,with the following attributes:

BLOCK-SIZE DBMS-USED DEVICE LABEL MAX-RECORD-SIZE RECORD-FORMAT RPS SLACK

3121Identifies the access method used, the operating system data definitionname and the file's physical data set name with the following attributes:

ACCESS-MTHD DATA-SET-NAME MONITOR-NAME

3122Identifies the type of record in the file with the REC-TYP-NAME attribute.



3120 FILE Transaction

Use the 3120 FILE transaction to describe the occurrence's basiccharacteristics, including the database management system used, its devicetype, block size and record length. The format for the 3120 transaction follows.Words in parentheses are names that appear on reports or panels.

StartingPosition

Length Description


6 8 (Optional) Code the Database Management Systemused. (DBMS-USED)

Valid Entries: IBM/DL1, IBM/IMS, TOTAL, NONE

Default Value: NONE

15 6 (Optional) Enter the 1- to 6-character name of thedevice type on which the file resides. (DEVICE)

Valid Entries: FBA, MDISK, PRT, PUNCH,READER, TAPE, 2311, 2314, 3340,3350, 3370, 3380, 3390, 6421, 9345,3330, 3330II

Default Value: 3380

22 5 (Required) Enter the number indicating the maximumblock size of the file. (BLOCK-SIZE)

This value must be a multiple of theMAX-RECORD-SIZE value.



28 5 (Required) Enter a value indicating the maximum size arecord defined to the FILE structure can reach beforeexpanding the physical record on disk.(MAX-RECORD-SIZE)



34 4 (Optional) Enter the record format for the file.(RECORD-FORMAT)

Valid Entries: FBLK, FUNB, VBLK, VUNB, UNDF

Default Value: FBLK



StartingPosition

Length Description

39 1 (Optional) Enter Y (yes) if standard labels are used, N(no) if they are not used. (LABEL)


Default Value: Y

41 1 (Optional) Specify Y (yes) if rotational position sensingis used and N (no) if it is not used. (RPS)


Default Value: Y

43 4 (Optional) Enter the number of bytes to be reserved ineach block of the file for expansion. The value must bea number smaller than the block size. (SLACK)


Default Value: 0


Use the 3121 FILE transaction to identify the access method used, theoperating system data definition name and the file's physical data set name.


StartingPosition

Length Description


6 5 (Optional) Identify the access method used with thisfile. Datadictionary does not edit your entry.(ACCESS-MTHD)



12 8 (Optional) Enter the JCL data definition name if yoursite is z/OS, or the DLBL name if your site is z/VSE.





StartingPosition

Length Description

21 44 (Optional) Enter the file's physical data set name.(DATA-SET-NAME)




Use the 3122 FILE transaction to identify the Datadictionary occurrence nameof the field which defines the record type for the file structure. The format forthe 3122 transaction follows. Words in parentheses are names that appear onreports or panels.

Example Transaction Collection: The following is an example of the FILEoccurrence transaction:

-ADD FILE,PER-REC-HISTORY 312 NONE 335 8 24 FBLK Y 3121 BDAM PERSON PER-REC-HIST-FILE 3122 PER-REC-RECTYPE -END

This transaction collection adds the PER-REC-HISTORY file. The 3120transaction identifies the following:

■ NONE as the Database Management System■ 3350 as the device■ 800 as the block size■ 24 as the maximum record size■ A record format of fixed blocked■ Standard labels are used■ Rotational position sensing defaults to yes

The 3121 transaction identifies BDAM as the access method used, PERSON asthe data definition name, and PER-REC-HIST-FILE as the physical data setname.

StartingPosition

Length Description


6 32 (Optional) Identify the record type. (REC-TYP-NAME)





The 3122 Transaction identifies the field PER-REC-RECTYPE as the fieldwhich identifies the record type.


3150 to 3160 TABLE Transactions


Use the 3150 to 3160 transactions to maintain TABLE occurrences. Issue atransaction collection consisting of the following:

■ -ADD, -CPY, or -UPD header transaction■ Optional 1000 through 1500 transactions■ Applicable 3150 through 3160 transactions■ -END transaction

Constraints: If you want to copy a TEST version of a TABLE occurrence toPRODuction status and the PRODuction status occurrence has constraintsdefined, first restore the PRODuction status version to TEST, make thechanges and copy the occurrence to PRODuction status; or make the changesto the PRODuction status version through SQL processing.

Transactions and descriptions follow:

3150Identifies the physical CA Datacom/DB attributes for the table as follows:

CHNG-MASTER-KEY CLUSTER-KEY-ID CLUSTER-KEY-LEN COMPRESS-EXIT COMPRESSION DATACOM-ID DATACOM-NAME DBMS-USED DUPE-MASTER-KEY ENCRYPTION-KEY LOGGING MOVE-ROW-TO-NEW-PARTITION PARTITION PIPELINE-OPTION RECOVERY

3151Identifies the maximum sum of the lengths of the fields defined to thetable, whether the table defines an entity in the Datadictionary and jobcontrol language definition name with the following attributes:

DD-ENTITY-TABLE ENTY-HIST-VERS ENTY-NAME-LEN MAX-RECORD-SIZE MONITOR-NM



3152Identifies if the table is intended for SQL processing and the necessaryspecifications with the following attributes:

AUTHID SQL-INTENT SQLNAME

3153Specifies the DATACOM-NAME and SQLNAME values to be used toaccess a partitioned table even if all partitions of the table are notavailable. (All partitions must be available when using the occurrencenames.)

ANY-PARTITION-AUTHID ANY-PARTITION-DATACOM-NAME ANY-PARTITION-SQLNAME

3160Provides the occurrence names of the partitioned table and partitioningkey for which the table specified in the header transaction is a partition.

3150 TABLE Transaction

Use the 3150 transaction to identify the physical CA Datacom/DB attributes forthe table. The format for the 3150 transaction follows. Words in parenthesesare names that appear on reports or panels.

StartingPosition

Length Description


6 3 (Required) Enter the table's 3-character CADatacom/DB short name. (DATACOM-NAME)

Valid Entries: A unique set of 3 characters wherethe first character is alphabetic


10 3 (Optional) Enter the 1- to 3-digit CA Datacom/DB tableidentification number. (DATACOM-ID)


Default Value: An available table ID determinedduring a SET of the database



StartingPosition

Length Description

14 1 (Optional) Specify if the data in a Master Key must beunique. (DUPE-MASTER-KEY)


Default Value: N

16 1 (Optional) Specify if the data in the Master Key can beupdated. (CHNG-MASTER-KEY)


Default Value: N

Note: The CHNG-MASTER-KEY andDUPE-MASTER-KEY attributes of the TABLEoccurrence are set to Y when the table is the result ofthe CREATE TABLE statement in SQL. For moreinformation, see the CA Datacom/DB SQL User Guide.

18 1 (Optional) Enter Y (yes) to indicate that maintenance tothis table is to be logged in the CA Datacom/DB LogArea. (LOGGING)


Default Value: Y

20 1 (Optional) Enter Y (yes) if standard CA Datacom/DBdata compression is used for the table. Compressionremoves three or more consecutive blanks, characterzeros, or binary zeros. (COMPRESSION) If thisattribute is Y, the value of the COMPRESS-EXITattribute must be blank.

See the COMPRESS-EXIT attribute at starting position43.


Default Value: N

22 1 (Optional) If you plan to use CA Datacom/DB recoveryfacilities, enter Y (yes). If you do not intend to use therecovery facilities of CA Datacom/DB, enter N (no).(RECOVERY)


Default Value: Y



StartingPosition

Length Description

24 8 (Optional) Code the Database Management Systemused. (DBMS-USED)

Valid Entries: DATACOM or IBM/DB2


33 1 (Optional) Specify if the Pipeline Option of CADatacom/DB is to be used. (PIPELINE-OPTION)


Default Value: Y

35 3 (Optional) Code the number of high-order characters ofthe Native Key to be used for the Cluster Key of the CADatacom/DB table. (CLUSTER-KEY-LEN)


Default Value: 0

39 3 (Optional) Code an identification number if the tableuses the clustering space management option(SPACE-MNGMNT attribute for AREA is equal to 3).(CLUSTER-KEY-ID)


Default Value: If clustering is used, a unique ID

If clustering is not used, 0

43 8 (Optional) Identify the compression routine used for thetable. (COMPRESS-EXIT) If a non-blank value isspecified for this attribute, the value for theCOMPRESSION attribute must be N.

See the COMPRESSION attribute at starting position20.

Valid Entries: 1 to 8 character program name


52 8 (Optional) Enter the user-assigned key used forencryption of CA Datacom/DB tables. The entry mustcontain no embedded blanks (X'40') unless for use withCA Datacom Presspack. (ENCRYPTION-KEY)

Valid Entries: 8 characters which contain noembedded blanks




StartingPosition

Length Description

61 1 (Optional) Enter the value indicating the role of thetable in partitioning: the table is not involved inpartitioning (N); the table is partitioned (Y); the table ispartitioned but with restricted access, that is, no accessto the individual partitions (R); or the table is a partitionof a partitioned table (P). (PARTITION)

Valid Entries: N, P, R, or Y

Default Value: N

63 1 (Optional) Enter the value indicating whether a row isto be moved to a new partition (Y) if the value of one ofthe columns comprising the partitioning key is updated.(MOVE-ROW-TO-NEW-PARTITION)


Default Value: N


Use the 3151 transaction to specify the following:

■ The maximum sum of the lengths of the FIELD occurrences expected to bedefined to the table

■ Whether the entity is an entity defined to Datadictionary in the DATA-DICTdatabase

■ The maximum length of the occurrence names in Datadictionary when thetable defines the occurrence in the DATA-DICT database

■ The maximum number of HISTory status versions of an occurrence that canexist simultaneously in Datadictionary when the table defines theoccurrence in the DATA-DICT database

■ The job control language definition name used


StartingPosition

Length Description




StartingPosition

Length Description

6 5 (Optional) Enter the number indicating the maximumsize a table can reach before expanding the physicalrecord on disk. (MAX-RECORD-SIZE)


Default Value: 0

12 1 (Optional) Specify whether the table defines aDatadictionary entity-type in the DATA-DICT database.(DD-ENTITY-TABLE)


Default Value: N

14 2 (Optional) Use this attribute to specify the 1- to 2-digitmaximum length of occurrence names within theentity-type defined by this TABLE occurrence.(ENTY-NAME-LEN)



17 3 (Optional) Use this attribute to specify the maximumnumber of versions of an occurrence that can existsimultaneously in HISTory status in Datadictionary forthe entity-type defined by this TABLE occurrence.(ENTY-HIST-VERS)



21 8 (Optional) Enter the JCL data definition name if yoursite is z/OS, or the DLBL name if your site is z/VSE.




The 3152 transaction to specify if the table is intended for SQL processing.The transaction includes an authorization identifier and the table's SQL name.The format for the 3152 transaction follows. Words in parentheses are namesthat appear on reports or panels.



StartingPosition

Length Description


6 1 (Optional) Enter Y (yes) to indicate the table isintended for SQL processing. Enter R to indicate thetable is intended for SQL read-only processing.(SQL-INTENT)

If changing from one valid entry to another, see the CADatacom/DB Database and System AdministrationGuide for information about modifying SQL accessibleobjects.

Specifying N means that no SQL access is allowed.

Valid Entries: N or Y or R

Default Value: N

8 32 (Required if a value is entered for the SQLNAME.)Enter a valid authorization identifier for a table you wantto designate accessible by SQL processing. (AUTHID)

Do not use SYSADM for the AUTHID.



41 32 (Required if SQL-INTENT is Y or R.) Enter the SQLname for the table. (SQLNAME)







Use the 3153 TABLE transaction to specify the names to be used to access apartitioned table even if all partitions of the table are not available. The formatfor the 3153 transaction follows. Words in parentheses are names that appearon reports or panels.

StartingPosition

Length Description


6 3 (Optional, but Required if ANY-PARTITION-AUTHID orANY-PARTITION-SQLNAME is specified.) Enter theDATACOM-NAME to be used to access the partitionedtable even if all partitions are not available.(ANY-PARTITION-DATACOM-NAME)

Valid Entries: A set of three characters. The firstbyte must be alphabetic. The secondand third bytes can be alphanumeric.If the last two bytes are XX, awarning will be created at VERIFYand CATALOG time, but this does notstop a database from beingcataloged.


10 32 (Optional, but Required if ANY-PARTITION-SQLNAMEis specified.) Enter a valid authorization identifier for apartitioned table you want to designate as accessible bySQL processing when all partitions may not beavailable. (ANY-PARTITION-AUTHID)

Do not use SYSADM for the ANY-PARTITION-AUTHID.

Valid Entries: 1 to 32 characters adhering to SQLrules for Authorization IDs




StartingPosition

Length Description

43 32 (Optional) Enter a valid SQL Name for a partitionedtable you want to designate as accessible by SQLprocessing when all partitions may not be available.(ANY-PARTITION-SQLNAME)





Use the 3160 TABLE transaction to provide the occurrence names of thepartitioned table and partitioning key for which the table specified in the headertransaction is a partition. (This establishes the relationships between theoccurrences.) The format for the 3160 transaction follows.

StartingPosition

Length Description


6 32 (Required) Enter the occurrence name of the TABLEoccurrence that is the Parent of the TABLE occurrencespecified in the header.

39 32 (Required) Enter the relative position of the partitionnamed in the header transaction within the chain ofpartitions from lowest partition key value to highestpartition key value. $FIRST indicates the TABLEoccurrence specified in the header transaction is to bethe first partition in the chain and $LAST indicates it isto be the last partition in the chain.



Example Transaction Collection: The following is an example of the TABLEoccurrence transactions:

-ADD TABLE,RECEIPTS 1 CONNECT,RECEIPTS-AREA 315 A1 11 Y Y Y N Y DATACOM Y 5 3151 16 RECEIPTS 3152 Y JONES RECEIPTS -END

This transaction collection adds the RECEIPTS table. Transaction 3150identifies the following characteristics for the table:

■ The DATACOM-NAME is A01.■ The DATACOM-ID is 11.■ The Master Key can have duplicate values and the values can be modified.■ Logging is specified.■ Compression is not in effect.■ Recovery is specified.■ The Database Management System is DATACOM.■ Pipeline Option is active.■ The first 5 bytes of the Native Key are used for the Cluster Key.■ Datadictionary will assign a key ID for the Cluster Key when the occurrence

is updated to PRODuction status or when a 1000 SET transaction isprocessed.

Transaction 3151 identifies the following characteristics for the table:

■ 16000 is the table's maximum record size.■ RECEIPTS is the JCL data definition name.

Transaction 3152 identifies the following characteristics for the table:

■ The table is intended to be accessible with SQL processing.■ The authorization identifier is JONES.■ The SQL name is RECEIPTS.


3200 RECORD Transaction

3200 RECORD Transaction

Maintenance of record occurrences is simple because the only mandatory datafor a record occurrence is its name. The name is provided by the -ADD or-UPD header transaction. A RECORD occurrence is described by the sum ofall its associated FIELD, ELEMENT, and KEY occurrences.

A RECORD transaction collection includes:

■ -ADD, -CPY, or -UPD header transaction■ 1000 CONNECT transaction with the -ADD or -CPY header transactions■ Optional 1000 through 1500 transactions■ 3200 RECORD transaction■ -END transaction

The 1000 CONNECT transaction connects the RECORD occurrence to a FILEoccurrence. The format for the 3200 transaction follows. Words in parenthesesare names that appear on reports or panels.

Example Transaction Collection: The following is an example of theRECORD occurrence transaction:

-ADD RECORD,ACCTS-REC(T1) 1 CONNECT,ACCTS-FIL 32 DETL -END

This transaction collection adds the ACCTS-REC record to the ACCTS-FIL filestructure with a record type of DETL.

Note: The occurrence names of the record and file are for example only.

StartingPosition

Length Description


6 4 (Optional) For multi-record files, enter a user-definedcode indicating the type of record. (TYPE)




4010 to 4020 FIELD Transactions


Use the 4000 FIELD transactions to maintain FIELD occurrences. Toaccomplish this, use a transaction collection consisting of:

■ -ADD or -UPD header transactions■ Optional 1000 through 1500 transactions■ Desired 4010 - 4099 transactions■ -END transaction

Use the -GRP START header to describe the record or table to which you areadding the fields or changing the definition of the fields. For more informationabout processing field transactions using the -GRP header, see “Using the-GRP Header Transaction” on page 234.

Note: If you are defining a field that is to be accessible by SQL, the field(FIELD occurrences in Datadictionary define columns) must meet the conditionsnoted in this section.


4010Positions the field in the table or record and provides the parent namewith the following attributes:

AFTER PARENT

4011Provides comments for the field in any generated copybook of which thefield is a member with the LANG-COMNT attribute.

4012Adds information about the characteristics of the field such as its type,length, justification, value, class, and other field edit information with thefollowing attributes:

CLASS DBEDITS DECIMALS DEFAULT-INSERT FORCEADD FORCEUPD JUSTIFICATION LENGTH NULL-INDICATOR PRECISION REDEFINES REPEAT SIGN TYPE TYPE-NUMERIC



UNCHANGEABLE VALUE

4013Adds headings used by other CA products for column titles in reports andpanels with the following attributes:

HEADING-1 HEADING-2

4014Maintains the edit pattern of the field and the profile code used by CADataquery security with the following attributes:

EDIT-PATTERN PROFILE-CODE

4015Adds valid range values and a short attribute name with the followingattributes:

HIGH-RANGE LOW-RANGE SHORT-ATTR-NAME

4016Adds information used in COBOL copybook generation with the followingattributes:

BLANK-WHEN-ZERO DEPENDING-ON

4017Maintain information used in PL/I copybooks with the following attributes:

STORAGE VARYING

4018Adds additional information about the data in the field with the followingattributes:

SEMANTIC-MASK SEMANTIC-TYPE

4020Adds an SQL name for the field with the SQLNAME attribute.



4010 FIELD Transaction

Use the 4010 transaction to position the field and provide the parent name. Theformat for the 4010 transaction follows. Words in parentheses are names thatappear on reports or panels.

StartingPosition

Length Description


6 32 (Required) Describe the position of a field within arecord or table or a compound field. (AFTER)

For details, see the CA Datacom DatadictionaryAttribute Reference Guide.

Valid Entries: STARTPreceding field's nameREMOVE* (asterisk)


39 32 Enter the name of the compound field within which thisfield resides. For index, value, and redefines fieldsenter the name of the field to which this field refers.(PARENT)

For more information, see the CA DatacomDatadictionary Attribute Reference Guide.

Valid Entries: A valid field nameSTART* (asterisk)

Default Value: START for simple, compound, or fillerfields.

Previous field for index, value, orredefines field.




Use the 4011 transaction to add comments for the field in any generatedcopybook of which the field is a member. The format for the 4011 transactionfollows. Words in parentheses are names that appear on reports or panels.

StartingPosition

Length Description


6 36 (Optional) Enter a language comment to be used in agenerated data definition for the field. (LANG-COMNT)




Use the 4012 transaction to add information about the characteristics of a fieldsuch as its type, length, justification, value, class, and other field editinformation. Following is the format of the 4012 transaction. Words inparentheses are names that appear on reports or panels.

StartingPosition

Length Description


6 1 (Optional) Enter the field class. The field classes are:simple (S), compound (C), value or qualifier (V), filler(F), and index (I). See the CA Datacom DatadictionaryAttribute Reference Guide for requirements. (CLASS)

Valid Entries: S, C, V, F, or I

Default Value: S



StartingPosition

Length Description

8 1 (Optional) Specify the type of data stored in the field.(TYPE)

See the CA Datacom Datadictionary AttributeReference Guide for SQL and CA Datacom/DBrestrictions, and for a chart of valid entries, definition ofthe type, and the SQL equivalent where applicable. Inthis version, the data types K and Z are replaced by Gand type Y (double-byte character set) is replaced by Cwith SEMANTIC-TYPE=MIXED. Use the DDCNVLMutility to update all existing fields of these types to thenew types. For information about the DDCNVLM utility,see the CA Datacom/DB Database and SystemAdministration Guide.

Valid Entries: B, C, D, E, G, H, L, N, S, T, V, W, 2,4, or 8

Default Value: C

10 1 (Optional) Enter L (left) to specify if the data is storedleft justified. Enter R (right) to specify if the data isstored right justified. (JUSTIFICATION)

Valid Entries: L or R

Default Value: L if the field type is C, G, H, T, V, orWR for all other field types

12 1 (Optional) Indicate if the field contains signed numericdata. (SIGN)


Default Value: Y

14 5 (Optional) Specify the physical length of the field inbytes. (LENGTH)

Note: See the CA Datacom Datadictionary AttributeReference Guide for details about LENGTH.

Valid Entries: A 1- to 5-digit value that cannotexceed the maximum record or tablesize.

Default Value: 1



StartingPosition

Length Description

20 2 (Optional) For data types B, D, or N, enter the numberof decimal positions for a numeric field with an implieddecimal point. (DECIMALS)

See the CA Datacom Datadictionary AttributeReference Guide for information on the requirementsthis entry must meet based on data type.

Valid Entries: The number of decimals must beconsistent with the data type.

Default Value: 0

23 5 (Optional) Specify if this is a repeating field.(REPEAT)

During SQL processing, repeating fields are handled asa character field with a length equal to the length of alloccurrences.

Valid Entries: 1 to 5 digits representing the numberof repetitions

Default Value: 1

29 20 (Optional) Enter the literal value if this is a value field.(VALUE)

For requirements and restrictions, see the CA DatacomDatadictionary Attribute Reference Guide.



50 1 (Optional) Specify if this field redefines another field.(REDEFINES)

For restrictions, see the CA Datacom DatadictionaryAttribute Reference Guide.

Valid Entries: N, P, or S

Default Value: N

52 1 (Optional) If the field is signed numeric, specify thesigning convention for the field. (TYPE-NUMERIC)

For a detailed description of the valid entries,requirements, and considerations, see the CA DatacomDatadictionary Attribute Reference Guide.

Valid Entries: C, P, Q, or U

Default Value: C



StartingPosition

Length Description

54 1 (Optional) Specify if a 1-byte null-indicator is toprecede this field. (NULL-INDICATOR)


Default Value: N

56 1 (Optional) This field invokes data editing and defaultprocessing in CA Datacom/DB for ADDITs, UPDATs,and LOADs. (DBEDITS)

For detailed information on requirements andrestrictions, see the CA Datacom DatadictionaryAttribute Reference Guide.


Default Value: N

58 1 (Optional) This field forces the field's default value tobe applied during ADDIT/INSERT when you specify Y(yes). Use this field to ensure that the field's values areaccurate, not just a product of an application program.(FORCEADD)

See the CA Datacom Datadictionary AttributeReference Guide for requirements.


Default Value: N

60 1 (Optional) This field forces the field's default value tobe applied during UPDAT/UPDATE when you specify Y(yes). Use this field to ensure that the field's values areaccurate, not just a product of an application program.(FORCEUPD)



Default Value: N

62 1 (Optional) Specify Y (yes) to declare fieldsunchangeable after an add. (UNCHANGEABLE)



Default Value: N



StartingPosition

Length Description

64 1 (Optional) Specify the type of default value that CADatacom/DB uses during ADDIT, INSERT, or UPDATprocessing. (DEFAULT-INSERT)

See the CA Datacom Datadictionary AttributeReference Guide for details about valid entries and forrestrictions and requirements.

Valid Entries: D, N, O, S, or U

Default Value: N

66 5 (Optional) Specify the maximum number of displayabledigits allowed in the data stored in the field. See theCA Datacom Datadictionary Attribute Reference Guidefor details. (PRECISION)

Valid Entries: Greater than 0 and less than or equalto LENGTH based on the field'sTYPE

Default Value:

For type D (2x LENGTH) minus 1

For type G ½ LENGTH

For type N LENGTH

For type V LENGTH minus 2

For type W (LENGTH minus 2)divided by 2


Use the 4013 transaction to add headings which the CA Datacom/DB ReportingFacility, CA Ideal, CA Dataquery, and CA Dataquery for PC use as columntitles in reports and panels. The format for the 4013 transaction follows. Wordsin parentheses are names that appear on reports or panels.

StartingPosition

Length Description




StartingPosition

Length Description

6 32 (Optional) Enter the first line of the column heading.(HEADING-1)



39 32 (Optional) Enter the second line of the columnheading. (HEADING-2)




Use the 4014 transaction to add or change the edit pattern of the field. Theformat for the 4014 transaction follows. Words in parentheses are names thatappear on reports or panels.

StartingPosition

Length Description


6 24 (Optional) Enter an edit pattern that will be used withthe field by other CA products in your system.(EDIT-PATTERN)



31 4 (Optional) Enter the profile code used by CADataquery security. For more information, see theperson responsible for administering CA Dataquery onyour system. (PROFILE-CODE)

Valid Entries: 1- to 4-character code





Use the 4015 transaction to add valid range values and a short attribute name.The format for the 4015 transaction follows. Words in parentheses are namesthat appear on reports or panels.

StartingPosition

Length Description


6 20 (Optional) If the field has a range of valid values, enterthe lowest valid value. (LOW-RANGE)



27 20 (Optional) If the field has a range of valid values, enterthe highest valid value. (HIGH-RANGE)



48 15 (Optional) When defining a Datadictionaryattribute-type which has a name longer than 15 bytes,you can specify a short attribute name.(SHORT-ATTR-NAME)






Use the 4016 transaction to add the DEPENDING-ON name and theBLANK-WHEN-ZERO information. Use this transaction to input informationwhich is used in COBOL copybook generation.


StartingPosition

Length Description


6 32 (Optional) Enter the name of another field referred towith the DEPENDING-ON verb in COBOL tablehandling. (DEPENDING-ON)

Valid Entries: 1- to 32-character occurrence name


39 1 (Optional) Indicate if you want a COBOL“BLANK-WHEN-ZERO” clause generated when acopybook is created. (BLANK-WHEN-ZERO)


Default Value: N




Use the 4017 transaction to add or change the storage method and the variablefield parameter. The format for the 4017 transaction follows. Words inparentheses are names that appear on reports or panels.

StartingPosition

Length Description


6 1 (Optional) Enter the storage option for the field.(STORAGE)

Valid Entries: A, B, C, or S

Default Value: A

8 1 (Optional) Specify if the field can contain variablelength data. (VARYING)


Default Value: N




Use the 4018 transaction to further define the data in the field. You canindicate if the field is to contain dates in special format supported by other CAproducts.


StartingPosition

Length Description


6 8 (Optional) Use this 8-byte attribute to further define thedata in the field. (SEMANTIC-TYPE)

You can indicate if the field is to contain dates in aspecial format supported by SQL or other CA products.Datadictionary edits your entry for compatibility withdata type and length if it is one of the following:BIT-DATA, CA-DATE, SQL-DATE, SQL-STMP, andSQL-TIME.

See the CA Datacom Datadictionary AttributeReference Guide for information on defining this valuefor CA Dataquery, CA Ideal, and SQL. You can alsosee the CA Datacom/DB Database and SystemAdministration Guide for more information.



15 20 For future use. Other CA products will establish theuse of this attribute in further defining the content of afield. (SEMANTIC-MASK)




Use the 4020 transaction to add an SQL name for the FIELD occurrence. Theformat for the 4020 transaction follows. Words in parentheses are names thatappear on reports or panels.

StartingPosition

Length Description


6 32 (Optional) Enter the SQL name for the field. See thesection on naming standards in the CA DatacomDatadictionary User Guide. (SQLNAME)

You cannot change this attribute-value if the tableentity-occurrence is in PRODuction status.

For more information about this attribute, see the CADatacom Datadictionary Attribute Reference Guide.




If the following conditions exist for theTABLE to which this FIELD belongs,Datadictionary assigns a uniqueSQLNAME for the field during SET,COPY, or CATALOG processing:

■ SQLINTENT=Y■ A defined AUTHID■ A defined SQLNAME



Example Transaction Collection: The following transaction collection addsfields to the ACCTS TABLE occurrence. The transaction collection also addsinformation which describes and delimits each field.

-GRP START,TABLE,ACCTS(T2) -ADD FIELD,ORD-ID 11 'DEMO ADMIN' 12 'ACCOUNTS RECORD TABLE' 12 TEXT CLS ORDER 12 TEXT ADD THIS IS A UNIQUE NUMBER USED TO IDENTIFY AN ORDER. 12 TEXT END 41 START START 412 S N R Y 5 1 N P N N N N N N 413 ORDER ID 415 1 5999 416 N 417 A N 42 ORD_ID -END -ADD FIELD,BILL-DT 11 'DEMO ADMIN' 12 'BILLING DATE' 41 ORD-ID START 412 C C L N 1 N C N N N N N N 413 BILLING DATE 416 N 417 A N 42 BILL_DT -END -ADD FIELD,BILL-YR 11 'DEMO ADMIN' 12 'BILLING YEAR' 41 BILL-DT BILL-DT 412 S C L N 2 1 N C N N N N N N 413 BILLING YEAR 416 N 417 A N 42 BILL_YR -END -ADD FIELD,BILL-MO 11 'DEMO ADMIN' 12 'BILLING MONTH' 41 BILL-YR BILL-DT 412 S C L N 2 1 N C N N N N N N 413 BILLING MONTH 416 N 417 A N 42 BILL_MO -END -ADD FIELD,BILL-DAY 11 'DEMO ADMIN' 12 'BILLING DAY' 41 BILL-MO BILL-DT 412 S C L N 2 1 N C N N N N N N 413 BILLING DAY 416 N 417 A N 42 BILL_DAY



-END -GRP END

This transaction collection adds five fields (ORD-ID, BILL-DT, BILL-YR,BILL-MO, and BILL-DAY) to Version T002 of the ACCTS table. Because thetable name is identified in the -GRP START transaction, each field ADDtransaction does not need to identify the table to which the field is being added.


4099 Field Access Transaction


Use the 4099 transaction to perform attribute maintenance to DATA-DICT fieldoccurrences, such as, ATTRIBUTES. Do not use this transaction to changeCA-installed attributes.

Note: To produce a report showing your entries, you must supply the systemoverride code with a Detail Report for the FIELD occurrence. For moreinformation, see “FIELD Detail Report” on page 464.

Only use this transaction with approval of your Database Administratorand your Datadictionary Administrator.

To accomplish this, use a transaction collection consisting of the following:

■ -ADD or -UPD header transactions■ Optional 1000 through 1500 transactions■ 4099 transaction■ -END transaction

Note: To complete implementation of changes, you must run DDCFBLD withthe -HSD RESET transaction. For more information, see page 95.


StartingPosition

Length Description


6 1 (Optional) Indicate the attribute can be updatedthrough standard Datadictionary facilities such asDDUPDATE or Datadictionary online.(MEDIA-ACCESS)

If you code this parameter with N (no) and you codethe retrieval parameter, DATA-ACCESS, as Y (yes),this attribute cannot be displayed or updated throughnormal Datadictionary batch and online facilities.


Default Value: Y



StartingPosition

Length Description

8 1 (Optional) Indicates if the attribute can be retrievedonly by the facilities which have update capability of theattribute. (DATA-ACCESS)


Default Value: N

10 1 (Optional) Indicates if the attribute can be updated byCA products other than Datadictionary.(INTERNAL-ACCESS)

Caution: Do not use this parameter to change theattributes installed with the product. If you change thisparameter, it renders the attributes unusable by otherCA products and the results are unpredictable.


Default Value: N

12 1 (Optional) Indicates if the attribute can be updated by auser-written Datadictionary Service Facility (DSF)program. (USER-ACCESS)


Default Value: N

14 1 (Optional) Indicates if the attribute can be updated onlyby the Datadictionary Service Facility (DSF).(DSF-ACCESS)

Caution Do not use this parameter to change theattributes installed with the product. If you change thisparameter, the attribute cannot be updated by any user,only by Datadictionary.


Default Value: N

16 3 (Optional) Enter the character length of the attribute fordisplay or update purposes. (MEDIA-LENGTH)

Valid Entries: 1- to 3-character numeric length




Example Transaction Collection: The following transaction collectionupdates the access codes for a Datadictionary attribute for a user-definedentity-type.

-UPD FIELD,TERMINAL.TYPE(1) 499 N N N Y -END

The above transaction disallows update by Datadictionary batch, online andother CA products, but allows update by user DSF programs. All facilities canread the attribute data.


5000 to 5100 KEY Transactions


Use the 5000 KEY transactions to maintain KEY occurrences. To accomplishthis, use a transaction collection consisting of the following:

■ -ADD or -UPD header transaction■ Optional 1000 through 1500 transactions■ 5000 transactions■ -END transaction


5000Identifies the information needed by CA Datacom/DB. Contains thefollowing attributes:

DATACOM-ID DATACOM-NAME INCLUDE-NIL-KEY KEY-ASM-NAME KEY-CMP-NAME KEY-INDEX-NAME KEY-TYPE MASTER-KEY MAX-KEY-LENGTH NATIVE-KEY

5010Identifies field maintenance with the following attributes:

KEY-FIELD-LENGTH KEY-FIELD-NAME MAINT-ACT

5011Positions the field in the key with the AFTER-FIELD attribute.

5012Performs maintenance of a field's compiler or Assembler name, specifiesascending or descending sequence order and specifies if the key field isdata sensitive during sorting. Contains the following attributes:

ASM-NAME COMPILER-NAME DATA-SENSITIVE ORDER



5100Indicates the SQL name of the key, that the data in the field or fields inthe key are unique within the table, and specifies if CA Datacom/DB is touse the key for direct record access. Contains the following attributes:

SQLNAME UNIQUE DIRECT

5000 KEY Transaction

Use the 5000 KEY transaction to specify:

■ The DATACOM-NAME and ID for the key■ The Master Key status■ The Native Key status■ The Assembler and compiler labels for referencing the key's start■ The maximum length of the key■ The name of the index data set into which the values for this key are to be

stored.■ Whether blanks or binary zeros are to be included in the CA Datacom/DB

index■ The type of key: whether an index or a partitioning key

The format for the 5000 KEY transaction follows. Words in parentheses arenames that appear on reports or panels.

StartingPosition

Length Description


6 5 (Required) Enter the CA Datacom/DB short name forthe KEY occurrence. (DATACOM-NAME)



12 3 (Optional) Enter the 3-digit CA Datacom/DB key ID.(DATACOM-ID)


Default Value: Datadictionary assigns an availablenumber during execution of the SETfunction if you do not enter a value.



StartingPosition

Length Description

16 1 (Optional) Specify if this KEY occurrence is the table'sMaster Key. A table can have only one Master Key.(MASTER-KEY)


Default Value: N

18 1 (Optional) Specify if this KEY occurrence is the table'sNative Key. A table can have only one Native Key.(NATIVE-KEY)


Default Value: N

20 3 (Optional) Enter the maximum length of the longestkey if you have keys of unequal lengths with shared IDsin a CA Datacom/DB database. (MAX-KEY-LENGTH)


Default Value: Length of longest key

Note: If you create a key longer than 160 bytes, it willnot be used by CBS or SQL, which uses CBS, underthe following conditions:

■ In SQL for ORDER BY, GROUP BY, SELECTDISTINCT, UNION (without ALL), or index-merge.(SQL will use a sort, or a nested loop join.)

■ In a FOR statement for ORDER BY.

■ In RAAT SELFR when the length of columns in theRQA "K" section is greater than 160 bytes.

24 1 (Optional) Enter the value indicating the role of thekey, whether as an index (I) or as a partitioning key (P).(KEY-TYPE)

Valid Entries: I or P

Default Value: I



StartingPosition

Length Description

26 - 28 3 (Optional) Specifies into which index dataset the valuesof this key are to be stored. This attribute is also usedto indicate the first three characters of the DDNAME inz/OS or the DTFNAME in z/VSE. (KEY-INDEX-NAME)

Note: The index IXX data set always exists and isalways used for the space management index entriesand URI index entries.

Valid Entries: IXX or Inn where nn (00 - 99)

Default Value: IXX

32 1 (Optional) Indicate if key values that are all blanks(X'40') or all binary zeros (X'00') are to be included in orexcluded from the CA Datacom/DB index.(INCLUDE-NIL-KEY)

Specify Y to include these key values or N to excludethem. This value must be Y if the value of theMASTER-KEY, NATIVE-KEY, or UNIQUE attribute is Y.


Default Value: Y

34 8 (Optional) If you use Datadictionary to createAssembler data definitions, enter the Assembler name.(KEY-ASM-NAME)

Valid Entries: 1 to 8 characters left justified, noembedded blanks or nulls


43 30 (Optional) If you use Datadictionary to generateCOBOL or PL/I data definitions, enter the compilername. This name overrides the occurrence name.(KEY-CMP-NAME)

Valid Entries: 1- to 30-characters left justified, noembedded blanks or nulls





Use the 5010 transaction to designate the maintenance action and the name ofthe field in the key to which the action indicated applies. The format for the5010 transaction follows. Words in parentheses are names that appear onreports or panels.

StartingPosition

Length Description


6 3 (Required) Enter the maintenance action.(MAINT-ACT)

If you specify UPD, a 5011 or 5012 transaction or bothmust follow. If you do not follow an ADD maintenancefunction with a 5011, the added field defaults to the lastfield in the key.

Valid Entries: UPD, DEL, or ADD


10 32 (Required) Enter the occurrence name of the field towhich the action applies. (KEY-FIELD-NAME)

The field must be class C (compound) or S (simple).

Valid Entries: Name of existing field in the key or,for ADD, in the record or table


43 2 (Optional) Enter the length of the column used in thekey. This attribute is only valid for columns of type C(character). It specifies the number of characters to beused in defining the key, beginning with the firstcharacter of the column. For all other types, the entirecolumn must be used in the key definition.(KEY-FIELD-LENGTH)


Default Value: Length of the column




Use the 5011 transaction with -ADD and -UPD headers only. The 5011transaction adds or changes the position of the field in the key. If you add afield to the key identified in the header transaction with a 5010 transaction andno 5011 transaction, the field is placed at the end of the key. A 5011transaction must follow a 5010 transaction which identifies the maintenancefield.


StartingPosition

Length Description


6 32 (Required) Specify the field placement.(AFTER-FIELD)

Valid Entries: $FIRST, $LAST, or name of existingfield in the key

Default Value: $LAST


Use the 5012 transaction to add or change a field's compiler or Assemblername, to indicate ascending or descending sequence order, and to indicate ifthe key is treated as data sensitive during sorting. You can only code thistransaction after a 5010 transaction or after both a 5010 transaction and a 5011transaction.


StartingPosition

Length Description


6 30 (Optional) Enter the compiler name for the field namedin the 5010 transaction. (COMPILER-NAME)





StartingPosition

Length Description

37 8 (Optional) Enter the Assembler name for the fieldnamed in the 5010 transaction. (ASM-NAME)



46 1 (Optional) Use this field to indicate whether CADatacom/DB is to sequence the field in the key inascending or descending order. (ORDER)

Valid Entries: A or D

Default Value: A

48 1 (Optional) Enter a Y to have CA Datacom/DB sortsigned, numeric fields defined to a key in the correctorder. (DATA-SENSITIVE)


Default Value: N


Use the 5100 transaction to indicate that the value of the field or fields in theKEY are unique within the table and to specify the SQL name. You can alsouse this transaction to indicate the key be used for direct record access. Theformat for the 5100 KEY transaction follows. Words in parentheses are namesthat appear on reports or panels.

StartingPosition

Length Description


6 1 (Optional) Specify if the value of the key must beunique. (UNIQUE)

The RECOVERY attribute for all the tables in the areacontaining this key must have RECOVERY=Y. See“3150 TABLE Transaction” on page 322.


Default Value: N



Example Transaction Collections: The following are examples of the KEYoccurrence transactions.

-ADD KEY,ACCTS.CUST-ID-KEY(T2) 11 'DEMO ADMIN' 12 'CUST-ID SECONDARY KEY' 12 TEXT CLS CUSTOMER 12 TEXT ADD THIS KEY UNIQUELY IDENTIFIES A CUSTOMER. 12 TEXT END 5 ACSTI 1 N N 1 Y ACTCUSKY ACCTS-CUST-ID-KEY 51 ADD CUST-ID 511 $FIRST 512 ACT-CUST-ID-KEY CUSTID A N 51 Y CUST_ID_KEY N -END

This transaction collection defines CUST-ID-KEY and adds the field CUST-ID.Since columns 26-28 do not specify an index dataset, the value will default toIXX.

-ADD KEY,ACCTS.IND-CD-KEY(T2) 11 'DEMO ADMIN' 12 'IND-CD KEY' 51 ADD IND-CD 511 CUST-ID 512 ACT-IND-ID-KEY INDCD 51 ADD CUST-NO

StartingPosition

Length Description

8 32 (Optional) Enter the SQL name for the key.(SQLNAME)




41 1 (Optional) Enter Y in this field to indicate the key isused for direct relative record access. (DIRECT)

This type of key can increase performance whenaccessing a table.

For additional information, see the CA Datacom/DBDatabase and System Administration Guide and the CADatacom Datadictionary Attribute Reference Guide.


Default Value: N



511 IND-CD 512 ACT-CUST-NO-KEY CUSTNO A N 51 Y IND_CD_KEY N -END

This transaction collection adds the IND-CD-KEY. IND-CD is added as the firstfield in the key and CUST-NO is added as the second field.


5200 to 5203 PARTITION-COLUMN-VALUE Transactions


Use the 5200 and 5203 PARTITION-COLUMN-VALUE transactions to maintainPARTITION-COLUMN-VALUE occurrences. To accomplish this, use atransaction collection consisting of the following:

■ -ADD or -UPD header transaction■ Optional 1000 through 1500 transactions■ 5200 transactions■ -END transaction


5200Identifies the Parent (partitioned) table and the partitioning column (field)for the PARTITION-COLUMN-VALUE occurrence.

5203Provides the data describing the high value for a partitioning column forthe PARTITION-COLUMN-VALUE occurrence specified in the headertransaction.

HIGH-RANGE-SIGN HIGH-RANGE-VALUE

5200 PARTITION-COLUMN-VALUE Transaction

Use the 5200 PARTITION-COLUMN-VALUE transaction to provide the name ofthe Parent (partitioned) table and the partitioning column for thePARTITION-COLUMN-VALUE occurrence specified in the header transaction.

StartingPosition

Length Description

1 4 Enter 5200 as the Transaction Code(DDMAINT-REC-TYP)

6 32 (Required) Enter the Datadictionary name of theTABLE occurrence that represents the Parent(partitioned) table for the table partition with which thisPARTITION-COLUMN-VALUE occurrence isassociated.

Valid Entries: A 1- to 32-character Datadictionaryoccurrence name of a tableoccurrence with a PARTITIONattribute-value of Y




StartingPosition

Length Description

39 32 (Required) Enter the Datadictionary name of a FIELDoccurrence of the specified table that is also defined toa KEY occurrence of that table that is specified as apartition key.

Valid Entries: A 1- to 32-character Datadictionaryoccurrence name of a column with aRECORD-NAME attribute-valuematching the TABLE occurrencename specified above that is alsodefined as part of a KEY occurrenceof the same table with a KEY-TYPEattribute-value of P


5203 PARTITION-COLUMN-VALUE Transaction

Use the 5203 Transaction to provide the data describing the high value for apartitioning column for the PARTITION-COLUMN-VALUE occurrence specifiedin the header transaction.

StartingPosition

Length Description

1 4 Enter 5203 as the Transaction Code(DDMAINT-REC-TYP).

6 1 (Optional) Enter the sign value (plus (+) or minus (-))or none (N) for a numericPARTITION-COLUMN-VALUE occurrence.(HIGH-RANGE-SIGN)

Valid Entries: +, -, or N

Default Value: For a signed numeric value, +.For all others, N.



StartingPosition

Length Description

8 63 (Required) Enter the high range value for the partitioncolumn or the reserved term HIGH-VALUES.(HIGH-RANGE-VALUE)

Contains

Valid Entries: A character value, the format of whichis dependent on the TYPE andLENGTH of the partition column(LENGTH being the length of the dataas it is stored or, for charactercolumns, the length used forpartitioning purposes), as follows:

TYPE

LENGTH Valid Value

Character 1-60 1 to 60 characters

If the value is to containunprintable characters or beginwith one of the reserved terms,the value can be entered usinghexadecimal notation (X'). Forexample, ABc could be enteredas X'C1C2 83'. If this form isused, the entire value must beentered in this format with the X'beginning in column 8 and theclosing single quote no later thancolumn 70. This limits themaximum physical length of thedata to 30 bytes.

In either form, blanks (X'40') fillany trailing positions.



StartingPosition

Length Description

TYPE

LENGTH Valid Value

SmallInteger(binaryhalfword)

2 Signed:

0 to 32767 if sign is +1 to 32768 if sign is -

Unsigned:

0 to 65535

Note: SQL does not supportunsigned integers.

Data entered will be right justifiedand zero filled if required. Dataentered must be no longer than 5characters including leadingzeros.

Integer(binaryfullword)

4 Signed:

0 to 2147483647 if sign is +1 to 2147483648 if sign is -

Unsigned:

0 to 4294967295

Note: SQL does not supportunsigned integers)

Data entered will be right justifiedand zero filled if required. Dataentered must be no longer than10 characters including leadingzeros.

Numeric(zoneddecimal)

1-15 1 to 15 digits (signed orunsigned)




StartingPosition

Length Description

TYPE

LENGTH Valid Value

Decimal(packeddecimal)

1-8 1 to 15 digits (signed orunsigned)


Date 4 Date in ccyymmdd format where:

cc = 00 to 99 centuriesyy = 00 to 99 yearsmm = 01 to 12 monthsdd = 01 to 31 days

Data entered must be 8characters.

Time 3 Time in hhmmss format where:

hh = 00 to 24 hoursmm = 00 to 59 minutesss = 00 to 59 seconds

Data entered must be 6characters.




The following are examples of the PARTITION-COLUMN-VALUE occurrencetransactions:

-ADD PARTITION-COLUMN-VALUE,PART-TABLE-1.PART-1-COL1(T1) 11 'DEMO ADMIN' 12 'PARTITION-COLUMN-VALUE FOR PART-TABLE-1' 52 PART-TABLE COLUMN-1 523 499 -END

This transaction collection defines PART-1-COL1.

StartingPosition

Length Description

TYPE

LENGTH Valid Value

Timestamp 10 Date and time inccyyMMddhhmmssnnnnnn formatwhere:

cc = 00 to 99 centuriesyy = 00 to 99 yearsMM = 01 to 12 monthsdd = 01 to 31 dayshh = 00 to 23 hoursmm = 00 to 59 minutesss = 00 to 59 secondsnnnnnn = 0 to 999999microseconds

Data entered must be at least 14characters. If less than 20characters are entered, the final,unfilled positions will be zerofilled.

Valid entries also includes the term HIGH-VALUES.

For all unsigned columns (including character anddate/time columns):HIGH-VALUES = Hexadecimal 15's (x'FF')

For all signed columns:HIGH-VALUES = the highest positive value possible forthe column




-ADD PARTITION-COLUMN-VALUE,PART-TABLE-2.PART-2-COL2(T1) 11 'DEMO ADMIN' 12 'PARTITION-COLUMN-VALUE FOR PART-TABLE-2' 52 PART-TABLE COLUMN-2 523 HIGH-VALUES -END

This transaction collection defines PART-2-COL2.


6000 to 6011 ELEMENT Transactions


Use the 6000 ELEMENT transactions to maintain ELEMENT occurrences. Toaccomplish this, use a transaction collection consisting of the following:

■ -ADD or -UPD header transaction■ Optional 1000 through 1500 transactions■ Desired 6000 to 6011 transactions■ -END transaction


6000Assigns the DATACOM-NAME, describes the security code and providesthe Assembler and compiler labels with the following attributes:

ASM-NAME COMPL-NAME DATACOM-NAME SECURITY-CODE

6010Performs field maintenance with the following attributes:

FIELD-NAME MAINT-ACT

6011Performs maintenance on a field's compiler or Assembler name with thefollowing attributes:

ASM-NAME COMPILER-NAME



6000 ELEMENT Transaction

Use the 6000 transaction to assign a DATACOM-NAME to the element,describe the security code required to access the element, and provide theAssembler and compiler labels.

The DATACOM-NAME is used by the Source Language Generation Facility(SLG) to name the group of statements it produces. For a CA Datacom/DBtable, the DATACOM-NAME attribute-value also serves as the element nameby which data is accessed in the database.

Following is the format for the 6000 transaction. Words in parentheses arenames that appear on reports or panels.

StartingPosition

Length Description


6 5 (Required) Enter the CA Datacom/DB short name forthe element. (DATACOM-NAME)



12 2 (Optional) Enter a CA Datacom/DB security code. Thissymbol will be required to access the element.(SECURITY-CODE)

Valid Entries: 00 to FF (hexadecimal)


15 8 (Optional) Enter the Assembler name for the element.(ASM-NAME)



24 30 (Optional) Enter the complier name for the element.(COMPL-NAME)

Valid Entries: 1 to 30 characters, left justified, noembedded blanks or nulls





Use the 6010 transaction to add, delete, or update a field in an element. Thistransaction designates the maintenance action and field name to which themaintenance action applies. If you plan to code a 6011 transaction you mustcode the 6010 transaction.


StartingPosition

Length Description


6 3 (Required) Enter the maintenance action to beperformed on a field in an element. For example, codeUPD to update the Assembler or compiler name usingthe 6011 transaction. (MAINT-ACT)

Valid Entries: ADD, DEL, or UPD


10 32 (Required) Enter the field name on which themaintenance is to be performed. (FIELD-NAME)

For an ADD maintenance action, enter any 1- to32-character field name not already in the element butcontained in the RECORD or TABLE substructure.

For an UPD or DEL maintenance action, enter any 1- to32-character field that already exists in the element.






Use the 6011 transaction to add or change a field's compiler or Assemblername. If you code this transaction, it must follow the 6010 transaction thatspecifies an ADD or UPD maintenance action.


Example Transaction Collections: The following are examples of theELEMENT occurrence transactions:

-ADD ELEMENT,ACCTS.ACCTS-REC(T1) 11 'DEMO ADMIN','DEMO ADMIN' 12 'FULL RECORD ELEMENT' 12 TEXT ADD THIS IS THE ACCOUNTS RECORD ELEMENT IN THE ACCTS TABLE OCCURRENCE. 12 TEXT END 6 ACTFL ACCTREC ACCTS 61 ADD ORD-ID 611 ACT-ORD-ID ORDID -END

This transaction collection adds the ACCTS element in status T001 with thefollowing:

■ Author is DEMO ADMIN.■ Controller is DEMO ADMIN.■ The element is described as FULL RECORD ELEMENT.■ Text describes the element in greater detail.■ It has a short name of ACTFL.■ 00 is the security code.

StartingPosition

Length Description


6 30 (Optional) Enter the compiler name for the fieldidentified in the 6010 transaction. (COMPILER-NAME)



37 8 (Optional) Enter the Assembler name for the fieldidentified in the 6010 transaction. (ASM-NAME)





■ Compiler name is ACCTS.■ Assembler name is ACCTS.

The 6010 transaction adds the field ORD-ID to the ACCTS element.

The 6011 transaction adds the compiler name of ACT-ORD-ID and Assemblername of ORDID.

The following example transaction collections add single-field elements:

-ADD ELEMENT,ACCTS-REC.CUST-ID(T1) 11 'DEMO ADMIN','DEMO ADMIN' 12 'CUST-ID ELEMENT' 6 ACTCS ACTCUST ACCTS-REC.CUST-ID 61 ADD CUST-ID 611 ACT-CUST-ID CUSTID -END

-ADD ELEMENT,ACCTS-REC.ORD-ID(T1) 11 'DEMO ADMIN','DEMO ADMIN' 12 'ORD-ID ELEMENT' 6 ACTOR ACTORDID ACCTS-REC-ORD-ID 61 ADD ORD-ID 611 ACT-ORD-ID ORDID -END


6100 LIBRARY Transaction

6100 LIBRARY Transaction

The 6100 transaction identifies the type of library the occurrence uses. It is onlyused to maintain LIBRARY occurrences. To accomplish this, use a transactioncollection consisting of:

■ -ADD, -CPY, and -UPD header transaction■ Optional 1000 through 1500 transactions■ 6100 transaction■ -END transaction


Example Transaction Collections: The following are examples of the 6100LIBRARY transactions:

-ADD LIBRARY,SYS1-MACLIB 61 VOLLIE -END

This transaction collection adds the SYS1-MACLIB occurrence to the LIBRARYentity and identifies the occurrence's library system as VOLLIE.

-UPD LIBRARY,SYS1-MACLIB(1) 61 ROSCOE -END

This -UPD transaction collection updates the occurrence added in the above-ADD transaction collection. The library system is changed from VOLLIE toROSCOE.

StartingPosition

Length Description


6 8 (Optional) Identify the library system used.(LIBRARY-TYPE)




6200 MEMBER Transaction


The 6200 transaction identifies the occurrence's library name, the languageused, and the library in which it resides. It is only used to maintain MEMBERoccurrences. Use for documentation purposes. Datadictionary does not edityour entries.

To maintain a MEMBER occurrence, use a transaction collection consisting ofthe following:



StartingPosition

Length Description


6 8 (Optional) Enter the library member name.(MEMBER-ID)



15 5 (Optional) Identify the language of the member.(MEMBER-LANG)



21 8 (Optional) Enter the name of the library used.(LIBRARIAN-NAME)





Example Transaction Collections: The following are examples of the 6200MEMBER transactions:

-ADD MEMBER,PROG-A 62 MOD-ID-A -END

This transaction collection adds the PROG-A occurrence to the MEMBER entityand identifies the MOD-ID-A library member.

-UPD MEMBER,PROG-A(1) 62 MOD-ID-B -END

This transaction collection updates the occurrence added in the previous -ADDtransaction collection. The member ID is changed from MOD-ID-A toMOD-ID-B.


7011 to 7025 PARTITION-VALUE Transactions


Use the 7011 to 7025 transactions to define the lower and upper bounds thatCA Datacom STAR will use to partition a database.

CA Datacom STAR uses a conditional expression consisting of a maximum of250 bytes to determine the lower and upper boundaries when it partitions atable in a database. For more information, see the CA Datacom STARdocumentation.

To maintain a PARTITION-VALUE occurrence, use a transaction collectionconsisting of the following:

■ -ADD, -CPY, and -UPD header transaction■ Optional 1000 through 1500 transactions■ One to five transactions, 7011 through 7015■ One to five transactions, 7021 through 7025■ -END transaction


Use the 7011 through 7015 transactions to specify the LOWER-BOUNDS-1through LOWER-BOUNDS-5 attribute-values. When you specify more than oneof these attributes, CA Datacom STAR concatenates them in sequential orderto form a conditional expression.

The format for the transaction collection follows. Words in parentheses arenames that appear on reports or panels.

StartingPosition

Length Description

1 4 Enter one of the transaction codes 7011 to 7015.(DDMAINT-REC-TYP)

6 50 Enter the conditional expressions that sets the lowestvalue for the PARTITION-VALUE range.(LOWER-BOUNDS-1 through LOWER-BOUNDS-5)

Valid Entries: $LOW or a 50-character segment of aconditional expression





Use the 7021 through 7025 transactions to specify the UPPER-BOUNDS-1through UPPER-BOUNDS-5 attribute-values. When you specify more than oneof these attributes, CA Datacom STAR concatenates them in sequential orderto form a conditional expression.

The format for the transactions follows. Words in parentheses are names thatappear on reports or panels.

Example Transaction Collections: The following are valid transactions todefine PARTITION-VALUE occurrences.

-USR DDA,DDA,2 -ADD PARTITION-VALUE,LO-ORDERS(1) 711 $LOW 721 ORD-ID=33333 -END -ADD PARTITION-VALUE,MID-ORDERS(1) 711 ORD-ID=33334 721 ORD-ID=66666 -END -ADD PARTITION-VALUE,HI-ORDERS(1) 711 ORD-ID=66667 721 $HIGH -END

The -ADD transaction provides the entity-type, the occurrence name and theoccurrence status/version. The 7011 transactions provide the conditionalexpressions that establish the lowest value for the partitions. The 7021transactions provide the conditional expressions that establish the highest valuefor the partitions.

StartingPosition

Length Description

1 4 Enter one of the transaction codes 7021 to 7025.(DDMAINT-REC-TYP)

6 50 Enter the conditional expressions that sets the highestvalue for the PARTITION-VALUE range.(UPPER-BOUNDS-1 through UPPER-BOUNDS-5).

Valid Entries: $HIGH or a 50-character segment ofa conditional expression



7100 PANEL Transaction


Use the 7100 transaction to identify the occurrence's panel ID. This transactionis only used to maintain PANEL occurrences. Use for documentation purposes.Datadictionary does not edit your entries.

To maintain a PANEL occurrence, use a transaction collection consisting of thefollowing:



Example Transaction Collections: The following are examples of the 7100PANEL transactions:

-ADD PANEL,LOGOSCREEN 71 S1 -END

This transaction collection adds the LOGOSCREEN occurrence to the PANELentity and instructs that it be identified as the S01 panel.

-CPY PANEL,LOGOSCREEN(2) 11 'GEORGE DICKENS' 'HR DESIGNER' -END

StartingPosition

Length Description


6 3 (Optional) Enter the panel identifier. (PANEL-ID)





This example requests that PANEL LOGOSCREEN Version 2 be copied to thenext available version. It additionally specifies that the author, George Dickensand the controlling authority, the HR Designer, be assigned to the new version.

-UPD PANEL,LOGOSCREEN(1) 71 S2 -END

This transaction collection updates the occurrence added in the previous -ADDtransaction collection. The panel ID is changed from S01 to S02.


7110 SYSTEM Transaction


Use the 7110 transaction to describe a data processing system's name, designand implementation dates, and user department. This transaction is only usedto maintain SYSTEM occurrences. Use for documentation purposes.Datadictionary does not edit your entries.

To maintain a SYSTEM occurrence, use a transaction collection consisting ofthe following:


Datadictionary supports 15-character application names in this transaction. Toadd a longer application name, use the 7999 transaction. See “7999Application Attribute Transaction” on page 400.


StartingPosition

Length Description


6 15 (Optional) Code the name of the application.(APPLICATION)

To add an application name greater than 15 characters,use the 7999 transaction.



22 8 (Optional) Enter the date the system was designed.(DATE-DESIGN)



31 8 (Optional) Enter the date the system was implemented.(DATE-IMPLEM)





Example Transaction Collections: The following are examples of the 7110transactions:

-ADD SYSTEM,RESOURCES 711 RESOURCES-IDENT 12/11/1 1/13/2 TOP-MANAGEMENT -END

This transaction collection adds the resources occurrence to the SYSTEM entityand indicates that the application be named RESOURCES-IDENT. The systemwas designed (or finished) December 11, 2001 and was implemented January13, 2002. The end user is TOP-MANAGEMENT.

-UPD SYSTEM,RESOURCES(1) 711 5/12/2 -END

This transaction collection updates the occurrence added in the previoustransaction collection. Only the design date is updated in the occurrence. Notethe correct positioning of the attribute-value.

StartingPosition

Length Description

40 15 (Optional) Enter the end-user name. (SYSTEM-USER)



56 3 (Optional) Enter the CA Ideal short system ID.(SHORT-SYSTEM-ID)




7120 PROGRAM Transaction


Use the 7120 transaction to describe a program by name, language, operatingsystem, category, creation date, modification date, and precompilation date.This transaction is only used to maintain PROGRAM occurrences. Use fordocumentation purposes. Datadictionary does not edit your entries.

To maintain a PROGRAM occurrence, use a transaction collection consisting ofthe following:


In addition, the program can be assigned an APPLICATION-NAME using the7999 transaction. For more information, see “7999 Application AttributeTransaction” on page 400.


StartingPosition

Length Description


6 8 (Optional) Code the name of the program. It isrecommended that the name be the same as the nameassigned on the Source Statement Library. (IDENT)



15 5 (Optional) Code the language in which the program iswritten. (LANGUAGE)



21 6 (Optional) Code the operating system under which theprogram operates. (OP-SYS)






-ADD PROGRAM,INVENTORY-UPD 712 INVUPD COBOL z/VSE UPDATE 12/11/1 1/13/2 -END

This transaction collection adds the INVENTORY-UPD occurrence to thePROGRAM entity. The program is named INVUPD, is a COBOL program, andruns under z/VSE. The type of program is UPDATE. It was written (orfinished) on December 11, 2001, and was modified on January 13, 2002.

-UPD PROGRAM,INVENTORY-UPD(1) 712 5/12/2 -END

This transaction collection updates the occurrence added in the previoustransaction. Only the modification date is updated in the INVENTORY-UPDoccurrence. Note the correct positioning of the attribute-value.

StartingPosition

Length Description

28 15 (Optional) Code any program type that may helpidentify or categorize the program. (TYPE-PROGRAM)



44 8 (Optional) Code the date the program was written.(DATE-WRITTEN)



53 8 (Optional) Code the date the program was modified.(DATE-MODIFIED)



62 8 (Optional) Code the date the program wasprecompiled. (DATE-PRECOMP)




7130 MODULE Transaction


Use the 7130 transaction to describe a module's name, language, operatingsystem, category, creation date, modification date, and precompilation date.This transaction is only used to maintain MODULE occurrences. Use fordocumentation purposes. Datadictionary does not edit your entries.

To maintain a MODULE occurrence, use a transaction collection consisting ofthe following:



StartingPosition

Length Description


6 8 (Optional) Code the name of the module. Make thename the same as the name assigned on the SourceStatement Library. (IDENT)



15 5 (Optional) Code the language of the module.(LANGUAGE)



21 6 (Optional) Code the name of the operating systemunder which the module operates. (OP-SYS)



28 15 (Optional) Code any data that might further identify orclassify the module. (TYPE-MODULE)






-ADD MODULE,RSCE-PGM-MOD-UP 713 RCPGMUPD COBOL z/VSE UPDATES PSC PGM 12/11/1 -END

This transaction collection adds the RCSE-PGM-MOD-UP occurrence to theMODULE entity. The module name is RCPGMUPD, the value for theTYPE-MODULE attribute is UPDATES PSC PGM, and the module was written(or finished) on December 11, 2001. The language used is COBOL and themodule runs under z/VSE.

-UPD MODULE,RCSE-PGM-MOD-UPD(1) 713 1/13/2 -END

This transaction collection udpates the occurrence added in the previoustransaction. Only the modification date is updated in the occurrence. Note thecorrect positioning of the attribute-value.

StartingPosition

Length Description

44 8 (Optional) Code the date that the module was written.(DATE-WRITTEN)



53 8 (Optional) Code the date that the module was lastmodified. (DATE-MODIFIED)



62 8 (Optional) Code the date that the module wasprecompiled. (DATE-PRECOMP)




7140 AUTHORIZATION Transaction

7140 AUTHORIZATION Transaction

Use the 7140 transaction to identify the classification name of the authorizationassigned to the occurrence. This transaction is only used to maintainAUTHORIZATION occurrences. Use for documentation purposes.Datadictionary does not edit your entries. See the CA Datacom SecurityReference Guide for information on Datadictionary security and authorizingusers.

To maintain an AUTHORIZATION occurrence, use a transaction collectionconsisting of the following:




-ADD AUTHORIZATION,PAYROLL 714 LEVEL-ONE -END

This transaction collection adds the PAYROLL occurrence to theAUTHORIZATION entity and describes its authorization to be LEVEL-ONE.

-UPD AUTHORIZATION,PAYROLL(1) 714 LEVEL-TWO -END

This transaction collection updates the occurrence added in the previoustransaction. The authorization level for the payroll department is updated toLEVEL-TWO.

StartingPosition

Length Description


6 12 (Optional) Enter the security classification code thathas been established to identify authorization assignedto the occurrence. (CLASS-CODE)




7150 to 7156 PERSON Transactions


Use the 7150, 7155, and 7156 transactions to identify a person's job, language,and full name. For information about Datadictionary security and authorizingusers, see the CA Datacom Security Reference Guide.

To maintain a PERSON occurrence, use a transaction collection consisting ofthe following:

■ -ADD, -CPY, and -UPD header transaction■ Optional 1000 through 1500 transactions■ 7150, 7155, and 7156 transactions■ -END transaction


7150Identifies the job characteristics of a person with the following attributes:

EMPLOYEE-IDENT JOB-GRADE JOB-TITLE ORGANIZATION

7155Identifies the person's language with the following attributes:

LANGUAGE LANGUAGE-CODE

7156Identifies the person's full name with the NAME attribute.



7150 PERSON Job Transaction

The format for the 7150 transaction follows. Use for documentation purposes.Datadictionary does not edit your entries. Words in parentheses are namesthat appear on reports or panels.


-ADD PERSON,DICKENS 715 DOCMNT 54377 WRITER GS-1 -END

StartingPosition

Length Description


6 6 (Optional) Enter an identification of the organization,department, or section with which the person isassociated. (ORGANIZATION)



13 9 (Optional) Code the alphanumeric identification numberof the person. (EMPLOYEE-IDENT)



23 20 (Optional) Code the person's job title. (JOB-TITLE)



44 6 (Optional) Code the person's alphanumeric job grade.(JOB-GRADE)





This transaction collection adds the DICKENS occurrence to the PERSONentity and indicates that the person is associated with the document section, isa writer, and is a GS-10.

-UPD PERSON,DICKENS(1) 715 EDITOR -END

This transaction updates information added with the previous transaction. Onlythe job title is updated for the occurrence. Note the correct positioning of theattribute-value.

7155 PERSON Language Transaction


StartingPosition

Length Description


6 3 Reserved.

10 10 (Optional) Enter the person's language. (LANGUAGE)

Valid Entries: ARABICDANISHDUTCHENGLISHFRENCHGERMANGERMAN2ITALIANJAPANESEKOREANNORWEGIANPORTUGUESESPANISHSWEDISH

Default Value: ENGLISH



Example Transaction Collection: Following is an example of an -UPDtransaction collection that uses the 7155 transaction. The PERSON occurrenceis updated to change the person's language.

-UPD PERSON,DICKENS(1) 7155 ENGLISH -END

Only the person's language is updated for the occurrence. Note the correctpositioning of the attribute-value.

StartingPosition

Length Description

21 1 (Optional) Enter the code for the person's language.(LANGUAGE-CODE)

Datadictionary does not edit your entry and does notverify that the code matches the language specified inthe LANGUAGE attribute-value.

Arabic=BDanish=9Dutch=6English=1Finnish=4French=5German=2German2=3Italian=8Japanese=CKorean=DNorwegian=FPortuguese=ESpanish=7Swedish=A

Valid Entries: 1 to 9, A—F




7156 PERSON Name Transaction



-ADD PERSON,JONES 7156 PAT JONES -END

This transaction collection adds the JONES occurrence to the PERSON entityand describes the full name as Pat Jones.

-UPD PERSON,JONES(1) 7156 PATRICK JONES -END

This transaction collection updates the occurrence added with the previoustransaction by changing the name.

StartingPosition

Length Description


6 60 (Optional) Code the full name of the person. (NAME)




7160 REPORT Transaction


Use the 7160 transaction to describe reports that can be generated by aninstallation. This transaction is only used to maintain REPORT occurrences.Use for documentation purposes. Datadictionary does not edit your entries.

To maintain a REPORT occurrence, use a transaction collection consisting ofthe following:


Application names of 1 to 15 characters can be entered using this transaction.To add a longer application name, use the 7999 transaction. For moreinformation, see “7999 Application Attribute Transaction” on page 400.

The format of the 7160 transaction follows. Words in parentheses are namesthat appear on reports or panels.

StartingPosition

Length Description


6 8 (Optional) Code an identification that conforms to theuser's report naming conventions. (IDENT)



15 15 (Optional) Code the name of the application thatproduces the report. (APPLICATION)



31 8 (Optional) Code the date the report was written.(DATE-WRITTEN)



40 8 Reserved for future use.




-ADD REPORT,RESOURCES 716 RSC-POOL RSC-PGM-UP 12/11/1 RFM-1 5 -END

This transaction collection adds the RESOURCES occurrence to the REPORTentity and describes the report name as RSC-POOL. It is produced by theprogram RSC-PGM-UP, was written December 11, 2001, and uses the formRFM-01. Five copies are made.

-UPD REPORT,RESOURCES(1) 716 3 -END

This transaction collection updates the occurrence added with the previoustransaction. Only the number of copies is updated for the occurrence. Notethe correct positioning of the attribute-value.

StartingPosition

Length Description

49 6 (Optional) Code the form number used to print thereport. (FORM-NBR)



56 4 (Optional) Code the number of copies to printed.(NBR-COPIES)



61 8 (Optional) Code the type of carriage control used withthe report. (CARR-CNTL)




7170 JOB Transaction


Use the 7170 transaction to describe batch jobs by name, the operatingsystem, accounting information, memory requirements, class, message classand level, priority, and processing time. This transaction is only used tomaintain JOB occurrences. Use for documentation purposes. Datadictionarydoes not edit your entries.

To maintain a JOB occurrence, use a transaction collection consisting of thefollowing:



StartingPosition

Length Description


6 8 (Optional) Code the job identification. (IDENT)

Conform to your site's job naming conventions.



15 6 (Optional) Code the operating system under which thejob operates. (OP-SYS)



22 20 (Optional) Code any accounting information applicableto the job. (ACCOUNTING-INFO)



43 4 (Optional) Code the number of 1024-byte blocks ofmain memory to be allocated for the job.(REGION-SIZE)

Valid Entries: 1 to 4 digits





-ADD JOB,SALE-PROCESS 717 UPD-SOP6 z/OS 4 -END

This transaction collection adds the SALE-PROCESS occurrence to the JOBentity and describes the job name as UPD-SOP6. The operating environmentis z/OS and 400 1024-byte blocks are allocated for the job.

-UPD JOB,SALE-PROCESS(1) 717 5 -END

This transaction collection updates the occurrence added with the previoustransaction. Only the block allocation is updated. Note the correct positioningof the attribute-value.

StartingPosition

Length Description

48 1 (Optional) Code the job class. (CLASS)

Valid Entries: 1 character


50 1 (Optional) Code the message class which reflects therouting of the job. (MSGCLASS)

Valid Entries: 1 character A to Z


52 2 (Optional) Code the message level indicating whatoutput is to be written as part of the output listing.(MSGLEVEL)

Valid Entries: 1 or 2 characters


55 2 (Optional) Code the job priority. (PRIORITY)

Valid Entries: 1 or 2 digits


58 6 (Optional) Code the amount of time the job uses whileexecuting. (RUN-TIME)

The suggested format is mmmsss where mmm isminutes and sss is seconds.

Valid Entries: 1 to 6 digits



7180 STEP Transaction


Use the 7180 transaction to describe a job step by ID, accounting information,blocks of memory allocated, priority, and execution time. This transaction isonly used to maintain STEP occurrences. Use for documentation purposes.Datadictionary does not edit your entries.

To maintain a STEP occurrence, use a transaction collection consisting of thefollowing:



StartingPosition

Length Description


6 8 (Optional) Code the identification of the step within thejob based upon user naming conventions. (IDENT)



15 20 (Optional) Code any accounting information that is tobe used with the step. (ACCOUNTING-INFO)



36 4 (Optional) Code the number of 1024-byte blocks ofmain memory to be allocated for the step.(REGION-SIZE)



41 2 (Optional) Code the internal dispatching priority of thestep. (DISP-PRIOR)

Valid Entries: 1 or 2 characters





-ADD STEP,LIBRARY-UPDATE 718 LIBUPD 45 -END

This transaction collection adds the LIBRARY-UPDATE occurrence to the STEPentity, describes the step name as LIBUPD, and allocates 450 1024-byte blocksfor the step.

-UPD STEP,LIBRARY-UPDATE(1) 718 52 -END

This transaction collection updates the occurrence added with the previoustransaction. Only the block allocation is updated for the occurrence. Note thecorrect positioning of the attribute-value.

StartingPosition

Length Description

44 6 (Optional) Code the time the step uses whileexecuting. (RUN-TIME)

The suggested format is mmmsss where mmm isminutes and sss is seconds.




7190 DATAVIEW Transaction


Use the 7190 transaction to identify the DATAVIEW occurrence by theDATAVIEW's Assembler and compiler names, security code, and updatecapability. This transaction is only used to maintain DATAVIEW occurrences.Use for documentation purposes. Datadictionary does not edit your entries.

To maintain a DATAVIEW occurrence, use a transaction collection consisting ofthe following:



StartingPosition

Length Description


6 8 (Optional) Enter the Assembler name for the dataview.(ASSEMBLER-NAME)



15 30 (Optional) Enter the compiler name for the dataview.(COMPILER-NAME)



46 6 Updateable only at the direction of CA personnel.

53 1 (Optional) Indicate if CA Ideal is to use this dataviewfor updating purposes or if the data is to be used forread only. (UPDATE-INTENT)

To allow updating, enter Y. For read only purposes,enter N or accept the default.


Default Value: N




-ADD DATAVIEW,DV1 719 ELNAME -END

This transaction collection adds the DV1 occurrence to the DATAVIEW entityand specifies that it be identified as having the Assembler name of ELNAME.

-ADD DATAVIEW,ACCOUNTS-DVW(T1) 13 RELT,ELEMENT,ACCTS-REC.ACCTS-REC-ELM(T1),$INTERNAL 13 AFTER,$FIRST 13 RELT,ELEMENT,ACCTS-REC.ORD-ID-ELM(T1),$INTERNAL 13 AFTER,ACCTS-REC.ACCTS-REC-ELM(T1) 13 RELT,ELEMENT,ACCTS-REC.CUST-ID-ELM(T1),$INTERNAL 13 AFTER,$LAST 719 ACCOUNTS N -END

This transaction collection adds ACCOUNTS-DVW with the elementsACCTS-REC-ELM, ORD-ID-ELM, and CUST-ID-ELM with UPDATE-INTENTspecified as Y for yes.

-UPD DATAVIEW,DV1(1) 719 ELNAME2 -END

This -UPD transaction collection updates the occurrence added in the first -ADDtransaction collection above. The Assembler name is changed from ELNAMEto ELNAME2.

7210 NODE Transaction

The 7210 NODE Transaction is replaced by the 7211 NODE Transaction in thisversion.

7211 NODE Transaction

Use the 7211 NODE transaction to identify the DD-BASEID and physicallocation. This transaction is only used to maintain NODE occurrences.

To maintain a NODE occurrence, use a transaction collection consisting of thefollowing:

■ -ADD, -CPY, or -UPD header transaction (Note: The occurrence name forNODE cannot exceed eight characters.)

■ Optional 1000 through 1500 transactions■ 7211 transaction■ -END transaction




Example Transaction Collection: The following is an example of the 7211transaction:

-ADD NODE,TESTNODE(1) 7211 426 DALLAS -END

This transaction collection adds the TESTNODE(1) occurrence to the NODEentity, specifies that the DATA-DICT DATABASE-ID for the node is 00426, andthat its location is Dallas.

StartingPosition

Length Description


6 5 (Optional) Enter the DATACOM-ID of the DATA-DICTdatabase for the node. (DD-BASE-ID)



12 30 (Optional) Enter the physical location of the node.(LOCATION)




7999 Application Attribute Transaction

7999 Application Attribute Transaction

Use the 7999 transaction to add an APPLICATION attribute-value to aPROGRAM occurrence or to add an APPLICATION attribute-value longer than15 characters to a REPORT or SYSTEM occurrence. Application names of upto 15 characters can be added on the appropriate maintenance transactionspreviously documented for REPORT and SYSTEM occurrences. Use fordocumentation purposes. Datadictionarydoes not edit your entries.

To add an APPLICATION attribute to a PROGRAM, REPORT, or SYSTEMoccurrence, use a transaction collection consisting of the following:

■ -ADD, -CPY, or -UPD header transaction■ Optional 1000 through 1500 transactions■ 7999 transaction■ -END transaction


Example Transaction Collection: The following is an example of the 7999transaction:

-UPD SYSTEM,TEST-SYSTEM(1) 7999 TEST-SYSTEM-PAYROLL-APPLICATION -END

This transaction collection updates Version 1 of the TEST-SYSTEM occurrenceof the SYSTEM entity-type and specifies that it be identified as having theapplication name of TEST-SYSTEM-PAYROLL-APPLICATION.

StartingPosition

Length Description


6 32 (Optional) Enter the application name of thePROGRAM, REPORT or SYSTEM occurrence.(APPLICATION)




9000 User-Defined Transactions


User-defined entity-types are unique to specific needs. You maintainoccurrences of user-defined entities with the header transactions and themaintenance transactions described in previous chapters and your owncustom-designed transaction in the 9000 series. For more information abouthow to define a user-defined entity, see the CA Datacom Datadictionary UserGuide.

The examples given in this chapter are for demonstration purposes only. Thefollowing example is for a user-defined TERMINAL entity and the transactioncode for the example is 9060.

To maintain a user-defined transaction, use a transaction collection consistingof the following:

■ -ADD, -CPY, or -UPD header transaction■ Optional 1000 through 1500 transactions■ The user-defined transactions in the 9000 series■ -END transaction

The format for an example 9000 transaction follows. Words in parentheses arenames that appear on reports or panels.

StartingPosition

Length Description


6 8 (Optional) The terminal name.



15 8 (Optional) The terminal manufacturer



24 3 (Optional) The ID of the terminal.

Valid Entries: 3 characters


28 6 (Optional) The controller of the terminal.





Example Transaction Collections: The following are examples of auser-defined entity transaction:

The TERMINAL entity example is used. The 9060 Terminal transaction, asdefined in this example, is used to describe selected characteristics about thelocal use of terminals.

-ADD TERMINAL,DATA-ENTRY 96 227-D TELEX 28 271 ROOM-144 -END

This transaction collection adds the DATA-ENTRY occurrence to theTERMINAL entity and describes the attribute-values of the occurrence.

-UPD TERMINAL,DATA-ENTRY(1) 96 3 -END

This transaction collection updates the occurrence added with the previoustransaction. Only the terminal ID is updated for the occurrence. Note thecorrect positioning of the attribute-value.

StartingPosition

Length Description

35 16 (Optional) The physical location of the terminal.




Chapter 9. DDUTILTY - ProducingReports and Source LanguageStatements


Obtaining a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Requesting the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Report Heading Content . . . . . . . . . . . . . . . . . . . . . . . . . . 409Maintenance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Error Recap Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Using the Authorization Transaction . . . . . . . . . . . . . . . . . . . 410Coding Multiple Line Transactions . . . . . . . . . . . . . . . . . . . . . 411Pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Coding the Basic Report Request . . . . . . . . . . . . . . . . . . . . . . . 412Specifying the Report Type . . . . . . . . . . . . . . . . . . . . . . . . 413Restricting Entity-Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Restricting Entity-Occurrences . . . . . . . . . . . . . . . . . . . . . . . 413Requesting Generic Selection . . . . . . . . . . . . . . . . . . . . . . . 414Restricting Version or Status . . . . . . . . . . . . . . . . . . . . . . . . 414Using the Override Code . . . . . . . . . . . . . . . . . . . . . . . . . . 416Using Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416Ending the Report Request . . . . . . . . . . . . . . . . . . . . . . . . 416Example Requests for Basic Reports . . . . . . . . . . . . . . . . . . . 416

Using Pathing in Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Coding the Path Request . . . . . . . . . . . . . . . . . . . . . . . . . . 418Defining the Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419Defining Trace Statements . . . . . . . . . . . . . . . . . . . . . . . . . 419TRACEF Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421TRACEB Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Returning Multiple Levels of a Relationship . . . . . . . . . . . . . . . 422Coding the -END Transaction . . . . . . . . . . . . . . . . . . . . . . . 422Using the STANDARD Path . . . . . . . . . . . . . . . . . . . . . . . . 422DATABASE Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422FILE Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423Using Nested Pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423-RPT NEST Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . 423-RPT NESTEND Transaction . . . . . . . . . . . . . . . . . . . . . . . 425Processing Nested Report Requests . . . . . . . . . . . . . . . . . . . 425Designating the Report Start . . . . . . . . . . . . . . . . . . . . . . . . 425Coding Modifiers When Using Pathing . . . . . . . . . . . . . . . . . . 428


Chapter 9. DDUTILTY - Producing Reports and Source Language Statements 403

Example Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433Single Report Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 433Grouping Reports in a Request . . . . . . . . . . . . . . . . . . . . . . 435Using a Nested Path in a Request . . . . . . . . . . . . . . . . . . . . 438

Alias Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

Definitions Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Descriptors Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457Report Heading Content . . . . . . . . . . . . . . . . . . . . . . . . . . 458Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459AREA Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459AUTHORIZATION Detail Report . . . . . . . . . . . . . . . . . . . . . . 460CONSTRAINT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . 461DATABASE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . 461DATAVIEW Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 462ELEMENT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 464FIELD Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464FILE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469JOB Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471KEY Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471LIBRARY Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 473MEMBER Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 474MODULE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 475NODE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476PANEL Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476PARAMETER-LIST Detail Report . . . . . . . . . . . . . . . . . . . . . 477PARTITION-COLUMN-VALUE Detail Report . . . . . . . . . . . . . . 478PARTITION-VALUE Detail Report . . . . . . . . . . . . . . . . . . . . . 478PERSON Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 479PLAN Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481PROCEDURE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . 483PROGRAM Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 484RECORD Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 486REPORT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 487STATEMENT Detail Report . . . . . . . . . . . . . . . . . . . . . . . . 488STEP Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489SYNONYM Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 489SYSTEM Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 490TABLE Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490


TRIGGER Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . 495VIEW Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497DETAIL Report - No Modifiers . . . . . . . . . . . . . . . . . . . . . . . 498

Field Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501KEY and ELEMENT Field Reports . . . . . . . . . . . . . . . . . . . . 504Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504FIELD Report - STANDARD Path . . . . . . . . . . . . . . . . . . . . . 505

Indented Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510INDENTED Report - No Path . . . . . . . . . . . . . . . . . . . . . . . 511INDENTED Report - STANDARD Path . . . . . . . . . . . . . . . . . . 514Impact Analysis Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 518INDENTED Report - Impact Analysis - For CA Ideal . . . . . . . . . . 520INDENTED Report - Impact Analysis - For a Dataview . . . . . . . . 521

Index Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525INDEX REPORT - No Path . . . . . . . . . . . . . . . . . . . . . . . . 526INDEX Report - STANDARD Path . . . . . . . . . . . . . . . . . . . . 528

Relationship Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531RELATIONSHIP Report - No Path . . . . . . . . . . . . . . . . . . . . 532RELATIONSHIP Report - With Modifiers . . . . . . . . . . . . . . . . . 537RELATIONSHIP Report - Ordered Relationships . . . . . . . . . . . . 538

Schema Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541SCHEMA Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

SQL Column Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544Report Request Transactions . . . . . . . . . . . . . . . . . . . . . . . 544Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553Report Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554TEXT Report - Without ALIGN Option . . . . . . . . . . . . . . . . . . 556TEXT Report - With ALIGN Option . . . . . . . . . . . . . . . . . . . . 559TEXT Report - STANDARD Path with ALIGN Option . . . . . . . . . . 560

Generating Source Language Statements . . . . . . . . . . . . . . . . . . 562Datacom View Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Using the Source Language Generation . . . . . . . . . . . . . . . . . . . 563-UTL LIBRARY - Specifying the Library Type . . . . . . . . . . . . . . 563-UTL MODE - Specifying SQL-Compatible Copybooks . . . . . . . . . 564-UTL LANGUAGE - Specifying the Language . . . . . . . . . . . . . . 565-RPT START - Specifying the Starting Point in the Path . . . . . . . . 568-UTL COPY - Specifying the Entity-Occurrence . . . . . . . . . . . . . 569Defining a Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572


Source Language Generation Facility Output . . . . . . . . . . . . . . 574Sample Job Streams and Output . . . . . . . . . . . . . . . . . . . . . . . . 577

Output from the Datacom View Generator . . . . . . . . . . . . . . . . 587Additional Comment Lines . . . . . . . . . . . . . . . . . . . . . . . . . 591

DDUTILTY supports printing batch reports and generating source languagestatements. These functions are accomplished by including a transactioncollection in your DDUTILTY batch job stream or DDUTILTY SYSIN file.

The transaction collection for printing a batch report specifies the requirementsof the report. Several reports may be processed in the same run of theDDUTILTY or the DDUPDATE utilities.


Obtaining a Report

Obtaining a Report

Datadictionary, through its batch reporting facility, produces numerous reportsto satisfy Datadictionary management information needs. Most reports can beproduced for both standard and user-defined entity-types. The followingsections detail the tasks to request a report.

Report Types

You can produce the following reports with the reporting capabilities ofDatadictionary in the DDUPDATE and DDUTILTY utilities:

Type Description See

Alias Report Lists all occurrences associatedwith selected aliases.

“Alias Report” onpage 441

Definitions Report Lists relationships and theirdefinitions for a specifiedentity-type or all entity-types.

“Definitions Report”on page 446

Descriptors Report Lists occurrences associated withselected descriptor words.

“DescriptorsReport” onpage 452

Detail Report Lists detailed information aboutoccurrences. Optional selectorsare available to modify the reportto include aliases, descriptors, ortext information.

“Detail Report” onpage 457

Field Report Lists all FIELD occurrencesassociated with an element, key,record, table, or view.

“Field Report” onpage 501

Indented Report Lists summary information aboutoccurrences including pertinentCA Datacom/DB information andthe SQL name and AUTHIDwhen assigned. When used witha path, presents the data in anindented format based uponoccurrence relationships. Thereport can be produced with orwithout headings.

“Indented Report”on page 509

Index Report Lists summary information aboutoccurrences, including status,version, password (optional), locklevel, and description.

“Index Report” onpage 524


Obtaining a Report

Type Description See

RelationshipReport

Lists related occurrences,showing the nature of eachrelationship.

“RelationshipReport” onpage 530

Schema Report Lists summary information aboutAUTHORIZATION occurrencesused as schemas in SQLprocessing and lists the relatedoccurrences in indented format.The report includes descriptiveand status information and theSQL name and AUTHID of theoccurrences.

“Schema Report”on page 540

SQL ColumnReport

Lists fields in a TABLE orRECORD sub-structure indicatingthe accessibility of these fields ifthey wre defined as columns ineither an SQL table orDATACOM VIEW.

“SQL ColumnReport” onpage 544

Text Report Lists text information foroccurrences. Prints individualclasses of text or all text for anoccurrence regardless of class. Itcan be produced with or withoutheadings.

“Text Report” onpage 553

Requesting the Report

Datadictionary batch reports are requested through a group of transactionswhich you submit using the Datadictionary utility (DDUTILTY) or maintenance(DDUPDATE) programs. These transactions specify the requirements of thereport. Several reports may be processed in the same run of DDUTILTY orDDUPDATE. Each request is processed separately. Errors in one reportrequest do not affect processing of subsequent reports. In DDUPDATE, youcan intersperse your report requests with your maintenance transactions.

Optional comment lines can be submitted in a report collection. A commentline must begin with the word -COM in columns 1-4. DDUTILTY does notprocess these comment lines nor do they ever appear anywhere in the report.

Spaces are used only between the first and second word of a request. Allother parameters are separated by punctuation.

The report requests must conform to the following:


Obtaining a Report

Column Description

1-71 Contains the request

72 Must be blank

73-80 Unused

Report Heading Content

The following information is contained in each report heading.

DATEDate of the report request

TIMETime of the report request

USERName of the person requesting the report

SECURITY LEVELLevel of DD security being enforced

PAGEPage number of the report

RELSDatadictionary release and maintenance level being used

MUF NAMEName of the CA Datacom/DB Multi-User Facility being accessed.

BASEDatabase ID of the DATA-DICT database on which you are reporting

Note: You can alter the heading date format by changing the SystemResource Table DDSYSTBL DATEFOR= parameter. For more information, seethe CA Datacom/DB Database and System Administration Guide.

Maintenance Report

Datadictionary produces a maintenance or process portion at the beginning ofeach report produced by DDUTILTY which documents each transactionsubmitted, the outcome of processing and any errors encountered. For moreinformation, see “Maintenance Portion” on page 29.

Error Recap Report

Datadictionary prints an Error Recap Report as the last page of the report yourequest. This report prints the page number of the report on which the erroroccurred, the error message number, and a brief description for each error. Formore information, see “Error Recap Portion” on page 31.


Obtaining a Report

Using the Authorization Transaction

The authorization (-USR) transaction performs the same function as the Signonpanel in Datadictionary online. Just as you must enter your name andpassword on the online panel to identify yourself, you enter a -USR transactionin batch to identify yourself. When Datadictionary encounters the -USRtransaction, your Authorization Profile is established using the PERSONentity-type indicated in the Datadictionary database.

Enter the -USR transaction as the first transaction in a batch input stream. Youmust have at least one -USR transaction for each execution of DDUTILTY;however, you can enter multiple -USR transactions per run. You can enter adifferent -USR transaction to change users or databases against which youwish to process.

Note: The -USR transaction is invalid if your site has selected to use the userID from a security package such as CA Top Secret, CA ACF2, or RACF as theDatadictionary user name. For more information about the SAFSEC= parameterof the DDSYSTBL macro, see the CA Datacom/DB Database and SystemAdministration Guide.

Enter the -USR transaction immediately before the transactions which use theauthorization and database indicated in the -USR transaction. The transactionformat follows:

-USR Transaction

��──-USR─ ──name,user-access-code ──┬ ┬───────────── ─────────────────────────────�� └ ┘ ─,datacom-id─

name (Required) Enter your name as it appears in the PERSON occurrence.

,user-access-code(Required) Enter your 1- to 12-character password as it appears in thePERSON occurrence.

,datacom-id(Optional) Enter the DATACOM-ID of the DATA-DICT database whichcontains the definitions you wish to access. If you do not enter thisparameter, Datadictionary uses the DATACOM-ID established as thedefault on your system.


Obtaining a Report

Coding Multiple Line Transactions

Due to the possible length of the entity-type and the occurrence names, youmay need to use multiple lines to enter all needed information for a reportHeader transaction. To continue a transaction, enter a hyphen and a space (-)at the beginning of the next line and continue entering information.

For example, if you entered a 32-character record name and a 32-characteroccurrence, you would need to continue the transaction on the next line tospecify the version, password, override code, or lock code.

Insert a hyphen (-) in the first column of the continued transaction. Follow thehyphen with at least one space and continue coding the transaction. Thefollowing rules apply to continued transactions.

■ You can only divide a transaction after a delimiter comma, period, or rightparenthesis.

■ A comma, parenthesis, or period cannot be the first non-blank characterfollowing the hyphen.

■ Use the continuation character only with header transactions.

A valid example transaction collection which uses the continuation characterfollows:

-RPT DETAIL,FIELD,ACCOUNTS-RECEIVABLE. - CUSTOMER-ID-NUMBER(T3,OVRD) -END

Pathing

Two types of selection and presentation are available in Datadictionary. Basicbatch reporting presents information alphabetically. Pathing is used to selectand present occurrences according to relationships. For more information, see“Using Pathing in Reporting” on page 418.

A report produced by pathing presents occurrences according to a logical orphysical relationship structure of entity-types and occurrences. Datadictionaryalso allows nested pathing, which provides a means of redirecting dataselection along as many as two nested paths before returning to the originalpath.


Coding the Basic Report Request


A basic Datadictionary batch report is requested with a transaction collectionthat includes a -RPT transaction and a -END transaction. Several reports maybe requested in a single execution of DDUTILTY. If you submit severaldifferent types of reports in the same job stream, the page numbers on thereport are sequential. If you want individual page numbered reports, useseparate execution steps in the JCL (EXEC).

The collection of transactions in the execution of the utility must be preceded bythe -USR transaction. Requests are processed individually, so errorsencountered in one request do not affect other requests in the transactioncollection.

The full report request is as follows:


��──-RPT──rpt-type─────────────────────────────────────────────────────────────�

�─ ──┬ ┬────────────────────────────────────────────────────────── ───────────────� └ ┘ ─,entity,─ ──┬ ┬────────────── ──┬ ┬────────── ──┬ ┬──────────── └ ┘ ─parent-name.─ └ ┘ ─occ-name─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

�─ ──┬ ┬──────────── ────────────────────────────────────────────────────────────�� └ ┘ ─,modifiers─

The only required parameter in the report request is the report type (rpt-type).Other parameters are optional and are used to limit the scope of the reportrequest. The commas are used both as separators and as indicators ofomission. Each parameter is discussed next.

Note: While the meaning of each parameter remains the same throughoutDatadictionary batch reporting, not all reports use all of the parameters. Validparameters for basic reporting and for pathing are discussed for each report inlater sections of this document.



Specifying the Report Type

The report type is specified in the rpt-type parameter of the -RPT request.Each report type can be spelled out or abbreviated by coding at least the firstfive letters of the report type. Valid report types are: ALIAS, DEFINITIONS,DESCRIPTORS, DETAIL, FIELD, INDENTED, INDEX, RELATIONSHIP,SCHEMA, and TEXT.

The rpt-type parameter is separated from the word -RPT by a space. Both theword -RPT and the rpt-type are required for a report request. If you do not codeany other parameters, Datadictionary assumes ALL and attempts to producethe type of report for the entire Datadictionary.

��──-RPT──rpt-type────────────────────────────────────────────────────────────��

Restricting Entity-Types

The basic report can be limited to occurrences within one entity-type by codingan entity-type name in the entity parameter. For example, to include only theoccurrences of the DATABASE entity-type, the word DATABASE would becoded in the entity parameter.

If this parameter is omitted or if the word ALL is coded, Datadictionary selectsoccurrences in all entity-types.

When coded, the entity parameter is separated from the rpt-type parameter bya comma. If other parameters follow the rpt-type parameter, the comma mustbe coded even if the entity parameter is not used. The following examplesshow valid coding formats for the entity parameter.

-RPT rpt-type,entity

-RPT rpt-type,,occ-name

Restricting Entity-Occurrences

The selection of occurrences can be limited by coding the occ-name parameterand, where appropriate, the parent-name parameter. Entity-occurrences in theKEY, ELEMENT, or FIELD entity-types are identified by an occurrence nameconcatenated to a parent occurrence name: a RECORD, TABLE, or VIEWoccurrence. All other occurrences are identified by an occurrence name only.

Coding an occurrence name limits the basic report to the named occurrence.Omitting the occurrence name or coding the word ALL causes Datadictionary toinclude all occurrences in the selected entity-types. Generic words can also beused. For more information, see “Requesting Generic Selection” on page 414.

When coding a FIELD, KEY, or ELEMENT occurrence name, the parent-nameand the occ-name parameters must both be coded. However, the word ALL ora generic word can be coded in one or both positions.



When coded, the occ-name parameter is separated from the entity parameterby a comma. The comma must be coded if the modifiers parameter is coded.The following examples show valid coding formats:

-RPT rpt-type,entity,occ-name

-RPT rpt-type,entity,rec-name.occ-name

-RPT rpt-type,entity,tbl-name.occ-name

-RPT rpt-type,entity,vew-name.occ-name

-RPT rpt-type,entity,,modifiers

Requesting Generic Selection

A generic selection can be requested by using an asterisk in the occ-name,parent-name, or modifier parameter. (Modifiers are discussed later in thischapter.) A generic selection is requested by coding the first character orcharacters of a name, followed by an asterisk (*). Datadictionary selects allnames in the category that begin with the characters preceding the asterisk.For example, to include the ACCTS AREA occurrence and the ACCTS TABLEoccurrence, the generic word ACC* could be coded in the occ-name parameter.Since both occurrences begin with these three letters (and an entity parameterwas omitted), both would be included on the report.

Restricting Version or Status

The report can be limited to a specific version or status of selected occurrencesby coding a 1- to 4-character version number or status code in the vrsparameter. If this parameter is omitted or if ALL is coded, Datadictionaryincludes all versions of the occurrences. If the ovrd (override) parameter isused, the version is followed by a comma. If the override parameter is notused, the version is followed by a right parenthesis.

Valid status codes are T001 to T999 (zeros are optional), H000 to H997 (zerosare optional), I001 to I999 (zeros are optional), PROD, INCO, HIST, TEST, andQUAL. Valid versions are 001 to 999 (zeros are optional).

If you enter the ALLV keyword, the PRODuction status occurrence is displayed.When you specify ALLV with pathing, the PRODuction status occurrence andall related occurrences, regardless of status, are processed for the reportrequest. For example, HISTory status occurrences would appear on a report ifthey are related to a PRODuction status occurrence specified in the reportrequest.

If TEST is coded all test versions are returned. You can also specify a specificstatus/version for incomplete by coding Innn where I indicates incomplete andnnn indicates the version number in the INCOmplete status. Historygenerations can be specified in a similar manner. For example, H000 is themost recently created HISTory status version of an occurrence and H001 is thenext most recent. This number does not equate to the version number of the



occurrence. For more information, see the section on history status in the CADatacom Datadictionary User Guide.

ASOF You can use the ASOF version to report on a PRODuction statusnon-model occurrence as it appeared at a specific time in the past. Touse the ASOF version, code ASOF in the vrs position and place thedate and time at the end of the transaction.

If you code the vrs parameter as ASOF, the date/time alias must be thefirst modifier. This modifier is only valid for Detail, Field, Indented, andIndex reports. Enter the date/time alias in the following format:

yyyymmddhhmm

yyyy Is the full year, such as 2008.

mm Is the two-digit month identification. For example, 01 is January.

dd Is the two-digit day of the month, such as 01.

hhmm Is the time in the 24-hour clock format. For example, use 1357 toindicate 1:57 PM.


When you specify the date/time alias to display a PRODuction statusoccurrence as it appeared on a given day and time, Datadictionary left justifiesyour entry and uses as much of the option value as you enter. For example,you can specify the full date and time or a partial date, such as 200806 for theyear and month or 20080614 for the year, month, and day.

-RPT INDEX,entity,(ASOF),281211357

This example produces an Index Report of all database occurrences as theyappeared in PRODuction status on December 1, 2008 at 1:57 PM. Whencoded, the ASOF parameter is separated from preceding words by a leftparenthesis.

The vrs parameter can follow the rpt-type, entity, or name parameters. Thefollowing examples show valid coding formats:

-RPT rpt-type(vrs)

-RPT rpt-type,entity(vrs)

-RPT rpt-type,entity,occ-name(vrs)

-RPT rpt-type,entity,parent-name.occ-name(vrs)



Using the Override Code

The ovrd parameter is used to access occurrences protected by a Lock Level 2restriction. If at least one occurrence is protected by a Lock Level 2, a validoverride code must be coded in the ovrd parameter. If this parameter isomitted, the report only includes occurrences that are not protected by a LockLevel 2. If you need to access occurrences protected by a Lock Level 2, seethe person responsible for security administration on your system.

When used, the override code is preceded by a comma and followed by a rightparenthesis. The following examples show valid coding formats.

-RPT rpt-type,entity,occ-name(vrs,ovrd)

-RPT rpt-type,entity,occ-name(,ovrd)

Using Modifiers

Some reports allow modifier words that affect the selection of occurrences orthe format of the report. When coded, this parameter is preceded by a commaand individual modifiers are separated by commas. Modifiers are discussed foreach report type in other sections of this document.

Ending the Report Request

To end the report request, code the -END transaction on its own line after thelast transaction in the transaction collection.

Example Requests for Basic Reports

The following example transaction collections show valid report requests andtheir descriptions:

-RPT INDEX -END

The previous example requests an Index Report listing all occurrences that arenot protected by a Lock Level 2 restriction. The report presents informationalphabetically by entity-type.

-RPT TEXT,AREA -END

The previous example requests a Text Report for all AREA occurrences for allversions that are not protected by a Lock Level 2 restriction. The reportpresents information alphabetically by entity-type.

-RPT DETAIL,DATABASE,ORDER-ENTRY -END



The previous example requests a Detail Report for each version of theORDER-ENTRY occurrence of the DATABASE entity-type that is not protectedby a Lock Level 2 restriction.

-RPT DETAIL,DATABASE,ORDER-ENTRY(1) -END

The previous example requests a Detail Report for Version 1 of theORDER-ENTRY occurrence of the DATABASE entity-type. The report lists theoccurrence if it is not protected by a Lock Level 2 restriction.

-RPT DETAIL,DATABASE,ORDER-ENTRY(TEST,OVRD) -END

The previous example requests a Detail Report for each TEST version of theORDER-ENTRY occurrence of the DATABASE entity-type. This exampleassumes that an occurrence is protected by a Lock Level 2 restriction and thatthe valid override code is OVRD.

-RPT TEXT,,ACC(,OVRD) -END

The previous example requests a Text Report listing all occurrences that beginwith the letters ACC. The override code is provided to access occurrencesprotected by a Lock Level 2 restriction.

-RPT INDEX,ELEMENT,ACC.ALL -END

The previous example requests an Index Report listing all ELEMENToccurrences belonging to records or tables that begin with the letters ACC.Note that the word ALL is coded in the occ-name parameter. The occ-nameparameter cannot be omitted if the parent-name qualifier is coded.

-RPT INDEX,DATABASE,ALL(ASOF),2861 -END

This example requests an Index Report for all DATABASE occurrences as theyappeared in PRODuction status on June 1, 2008.


Using Pathing in Reporting


The basic Datadictionary report request results in a report that includesselected occurrences within one entity-type or all entity-types and presents theinformation alphabetically.

Pathing defines the scope and sequence of a report according to relationships,thus allowing associated occurrences for several related entity-types to beincluded on one report and to be sequenced according to their relationships.

Reports can be produced for any existing entity-types, as long as the pathwhich has been established reflects how the occurrences to be listed arerelated in Datadictionary.

Note: Pathing is not used for the Alias, Descriptor, or Definitions reports.

Coding the Path Request

Path reporting requires a path definition, a START transaction, one or morereport requests, and a -END statement.

A path definition names and describes a sequence of entity-types along whichDatadictionary is to search for occurrences. Once a path has been defined andnamed, it remains valid for the duration of the DDUTILTY execution or until thepath is redefined. Multiple path definitions can be included in one reporttransaction collection.

The START transaction specifies the point along the path where the reportselection is to begin and specifies the path to be used. This path must havebeen defined previously in the DDUTILTY execution. Any or all occurrences ofany "from" entity-type along the path can be designated as the starting point forthe report.

Report requests are coded in a simplified format when used with a path. Also,when more than one report is requested, Datadictionary produces all requestedreports for one occurrence before proceeding to the next occurrence along thepath.



Defining the Path

Three steps are required when defining a path in a report transaction collection.These steps are as follows:

1. -DEF PATH,path-name2. -DEF TRACE,from-entity.to-entity,relationship-name3. -END

The only exception to the three-step requirement is the STANDARD path, whichis discussed later in this section. Each of the following three steps arediscussed:

-DEF PATH Transaction: This transaction designates the beginning of a pathdefinition and assigns a path name. This name uniquely identifies a path in amultiple path report. During report processing, Datadictionary uses the pathname to identify the path's definition. If the same path name is assigned tomore than one path definition in a single execution of DDUTILTY,Datadictionary uses the last definition coded before the report being processed.Datadictionary uses the path name STANDARD to define a set of $INTERNALrelationships.

The first word of the transaction must be -DEF. The second word must bePATH. The path name must be separated from the word PATH by a comma.The name must begin with an alpha character and can be up to 32alphanumeric characters long. In the following example, the path is namedPATH1:

-DEF PATH,PATH1

Defining Trace Statements

The TRACE, TRACEF and TRACEB transactions each name a pair of relatedentity-types and the relationship that connects them. Datadictionary searchesthe named entity-types for occurrences that are associated by the namedrelationship.

The TRACEF and TRACEB transactions are useful when you are definingpaths using relationships between occurrences of the same entity-type.

The TRACE transaction causes Datadictionary to return all occurrences whichare associated by the named relationship. The transaction follows this format:

TRACE Transaction

��──-DEF─ ──TRACE,from-entity.to-entity,relationship-name ──┬ ┬───────── ─────────�� └ ┘ ─,──SKIP─



The "from-entity" and "to-entity" parameters refer to entity-types rather thanspecific occurrence names. In the report, occurrences within the "from"entity-type are sequenced before the occurrences in the "to" entity-type.

If more than two entity-types are to be included in the path, multiple TRACEtransactions can be used. The number of trace cards allowed in a single reportrun is determined by the value for the MAXLVLS= parameter in the SystemResource Table (SRT). The value for this parameter when Datadictionary isinstalled is 20. For more information, see the CA Datacom/DB Database andSystem Administration Guide.

The "from" entity-type of each additional TRACE transaction must be the "from"or "to" entity-type of a previous TRACE transaction. The resulting path is a setof related entity-types along which Datadictionary can search for associatedoccurrences.

The entity-types coded in a TRACE transaction must be paired in the namedrelationship's definition. If the two entity-types are not a subject-object pair oran object-subject pair in the relationship definition, the report stops at the "from"entity-type's occurrences and any lower level occurrences in the path areignored. Also, the occurrences to be included on the reports must beassociated by the named relationship. If they are not associated, the reportstops at the "from" entity-type's occurrences and any lower level occurrences inthe path are ignored.

Coding the -DEF TRACE Transaction: The first word of the transaction mustbe -DEF. The second word must be TRACE. The third word is a "from"entity-type, which must be separated from the word TRACE by a comma. Thisentity-type can be the subject or the object of the named relationship'sdefinition. Placing the "from" entity-type first in the transaction establishes thedirection of presentation in the report.

The fourth word is a "to" entity-type, which must be separated from the "from"entity-type by a period. This entity-type must be paired with the "from"entity-type in the named relationship's definition. The fifth word must be arelationship name, which must be preceded by a comma.

In the following example, the path traces associated occurrences from theDATABASE entity-type to the AREA entity-type and then from the AREAentity-type to the TABLE entity-type, using the $INTERNAL relationshipbetween the occurrences:

-DEF PATH,PATH1 -DEF TRACE,DATABASE.AREA,$INTERNAL -DEF TRACE,AREA.TABLE,$INTERNAL -END

In the following example, the path traces associated occurrences from TABLEto AREA to DATABASE:



-DEF PATH,PATH2 -DEF TRACE,TABLE.AREA,$INTERNAL -DEF TRACE,AREA.DATABASE,$INTERNAL -END

Using SKIP in a TRACE Transaction: You can use the SKIP parameter in thepath trace to return information about occurrences that are indirectly related.The SKIP option accomplishes this by not processing the entity-types specifiedin the "to-entity" parameter. The "to" entity-types are used only as a bridge to arelated entity-type. The following example defines a path that would return theSYSTEM occurrence and PROGRAM occurrence information only, using thefollowing relationships:

SYSTEM is connected to JOB by the SYS-JOB-CONTAINS relationship. JOBis connected to STEP by the JOB-STEP-CONTAINS relationship. STEP isconnected to PROGRAM by the STP-PGM-EXECUTE relationship.

-DEF PATH,P1 -DEF TRACE,SYSTEM.JOB,SYS-JOB-CONTAINS,SKIP -DEF TRACE,JOB.STEP,JOB-STEP-CONTAINS,SKIP -DEF TRACE,STEP.PROGRAM,STP-PGM-EXECUTE -END

A SKIP parameter should not be placed on the last -DEF TRACE statement orany other -DEF TRACE statement where the "to" entity is not the "from" entityon a subsequent -DEF TRACE statement.

TRACEF Transaction

The TRACEF (Trace Forward) transaction causes Datadictionary to return onlythose occurrences found on the path from the subject to the object. Use theTRACEF transaction with relationships of the same entity-type (recursiverelationships). The transaction follows this format:

��──-DEF─ ──TRACEF,from-entity.to-entity,relationship-name ─────────────────────��

The parameters for the TRACEF transaction are the same as those for TRACE,which were described earlier in this chapter. For example:

-DEF TRACEF,PROGRAM1,PROGRAM2,PGM-PGM-CALLS

TRACEB Transaction

The TRACEB (Trace Backward) transaction causes Datadictionary to returnonly those occurrences found on the path from the object to the subject. Usethe TRACEB transaction with relationships of the same entity-type (recursiverelationships). The transaction follows this format:

��──-DEF─ ──TRACEB,from-entity.to-entity,relationship-name ─────────────────────��



The parameters for the TRACEB transaction are the same as those for theTRACE transaction, described earlier in this chapter.

Note: The TRACEF and TRACEB transactions are only used when the subjectand object entity-types are the same.

Returning Multiple Levels of a Relationship

To return multiple levels of a relationship path you must use multiple -DEFTRACE transactions. For example, the following transaction would return thefirst level of the structure:

-DEF TRACEF,PROGRAM.PROGRAM,PGM-PGM-CALL

The following example would return two levels:

-DEF TRACEF,PROGRAM.PROGRAM,PGM-PGM-CALL -DEF TRACEF,PROGRAM.PROGRAM,PGM-PGM-CALL

Coding the -END Transaction

The last step in the path definition is to code the word -END on the next lineafter the last TRACE transaction. Datadictionary does not process a pathdefinition if the -END statement is missing.

Using the STANDARD Path

The STANDARD path provided with Datadictionary follows a predefinedsequence of entity-types within the CA Datacom/DB Model and CA FILE Modelstructures. Since the STANDARD path is defined within the system, the TRACEtransactions can be omitted when defining the path in a report transactioncollection. For more information, see “Using Predefined Paths” on page 22.

To use the STANDARD path, you must supply the following transactions beforeyour report transactions.

-DEF PATH,STANDARD -END

DATABASE Structure

The following is the STANDARD path for reporting a DATABASE structure.:

-DEF PATH,STANDARD -DEF TRACE,DATABASE.AREA,$INTERNAL -DEF TRACE,AREA.TABLE,$INTERNAL -DEF TRACE,TABLE.KEY,$INTERNAL -DEF TRACE,TABLE.ELEMENT,$INTERNAL -DEF TRACE,TABLE.FIELD,$INTERNAL -END

Note: For the DDBTGLM utility, the TABLE.FIELD transaction is placed beforekeys and elements in the STANDARD path. For more information, see “UsingPredefined Paths” on page 22.



FILE Structure

The following is the STANDARD path for reporting a FILE structure.

-DEF PATH,STANDARD -DEF TRACE,FILE.RECORD,$INTERNAL -DEF TRACE,RECORD.KEY,$INTERNAL -DEF TRACE,RECORD.ELEMENT,$INTERNAL -DEF TRACE,RECORD.FIELD,$INTERNAL -END

Using Nested Pathing

Nested pathing redirects report output to a different path.

The NEST transaction, if coded, must appear after a report request within agroup following a START transaction. Datadictionary traces associatedoccurrences from the START transaction to the entity-type named in the NESTtransaction. Then Datadictionary follows the nested path for report requestsaccompanying the NEST transaction and then returns to the original path.

When Datadictionary is distributed, as many as two nested paths may be usedafter a START transaction. This limit can be modified. If you need more levelsthan are currently available, see the person responsible for administeringDatadictionary on your system.

-RPT NEST Transaction

A nested path requires three components:

1. The NEST transaction2. At least one report request3. The NESTEND transaction

The NEST transaction designates which entity-type along a secondary path isto be used as the starting point for nested reports and specifies the name of thenested path. The entity-type named in this transaction must be a “from”entity-type in the nested path and a “from” or a “to” entity-type in the main path.

The following is the format of a NEST transaction:

��──-RPT──NEST─ ──┬ ┬────────────────────────────────────────────────────── ─────�� └ ┘ ─,entity─ ──┬ ┬─(vrs)────── ─,path-name─ ──┬ ┬───────────── ├ ┤─(vrs,ovrd)─ └ ┘ ─,as-of-date─ └ ┘─(,ovrd)────

The first word must be -RPT. The second word must be NEST. See thefollowing descriptions for the other parameters.

,entity The entity-type named in the transaction must be a “from” or “to”entity-type in the START transaction's path and a “from” entity-type inthe nested path, or ALL for all entity-types in the path. If this



parameter is omitted, Datadictionary begins nested reports at the firstentity-type in the nested path.

When coded, the entity parameter is separated from the word NESTby a comma.

(vrs,ovrd)Coding a version or status limits nested reports to occurrences thathave a specific version number or status. If this parameter is omitted,Datadictionary includes versions specified in the START transaction.Valid entries for this parameter are a 1- to 4-digit version number, astatus code or ALL. Valid status codes are TEST (T001 to T999),INCO, ASOF, PROD, or HIST.

Use the ovrd parameter to supply the override code specified on yoursystem to access occurrences within the nested entity-type that areprotected by a Lock Level 2 restriction.

When coded, the parameter is separated from the previous word by aleft parenthesis, the override code is separated from the version by acomma, and the parameter is closed by a right parenthesis. If theoverride code is used, the comma must be coded. If ASOF is coded,a comma and the date/time modifier must be entered immediately afterthe right parenthesis.

,path-nameThis parameter names the nested path along which Datadictionary isto search for occurrences. The path must already have been definedwithin the transaction collection.

The comma preceding the path-name parameter is required. If theentity parameter is not used, you must include two commas before thepath-name parameter.

-RPT NEST,,path-name

,as-of-dateIf ASOF is coded in the vrs parameter, it specifies that a date and timewill be used to retrieve the PRODuction status version of theoccurrences on the specified date and time. If the full date and time isnot known, a partial date/time can be given. Any of the date/timepositions not entered default to zero or the earliest period of thedate/time provided. For example, 20010601 is the beginning of theday June 1, 2001, whereas 200106012359 is the end of the same day.




-RPT NESTEND Transaction

The NESTEND transaction designates the end of nested report requests. Thefirst word of the statement must be -RPT. The second word must beNESTEND. You must include one -RPT NESTEND transaction for each -RPTNEST transaction.

Processing Nested Report Requests

Report requests submitted with a nested path are processed in the same wayas those submitted with a path. Datadictionary processes nested reports forone occurrence along the nested path before proceeding to the next associatedoccurrence.

The following shows an example of a nested report request:

-DEF PATH,PATH1 -DEF TRACE,ELEMENT.TABLE,$INTERNAL -DEF TRACE,TABLE.AREA,$INTERNAL -END -DEF PATH,STANDARD -END -RPT START,ELEMENT,ALL(ALL),PATH1 -RPT NEST,ALL(INCO),STANDARD -RPT INDENT,ALL -RPT NESTEND -END

This request produces a report which returns substructures in the CADatacom/DB Model structure that have root occurrences in INCOmplete statusin your Datadictionary. First, a path is defined which traces backward from theelement to the area using the $INTERNAL relationship. A TRACEB is not usedsince the trace involves different entity-types. Next, the STANDARD path isdefined. The request then starts the report at the ELEMENT entity-type. Whenan incomplete occurrence is encountered, an indented report is produced. Ifthe occurrence is not in INCOmplete status, it is ignored.

Designating the Report Start

The START transaction designates the point along the defined path where thereport is to begin. The transaction follows this format:

��──-RPT──START─ ──┬ ┬────────── ──┬ ┬────────────── ──┬ ┬────────── ─────────────────� └ ┘ ─,entity,─ └ ┘ ─parent-name.─ └ ┘ ─occ-name─

�─ ──┬ ┬──────────── ──┬ ┬──────────── ──┬ ┬───────────── ───────────────────────────�� ├ ┤─(vrs)────── └ ┘ ─,path-name─ └ ┘ ─,as-of-date─ ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

The first word of a START transaction must be -RPT. The second word mustbe START. The other parameters define the start point for the report requeststhat follow the transaction and designate the path to follow when searching for



associated occurrences. Following is a discussion of each parameter and validcoding formats.

,entity,This parameter designates the entity-type along the defined path thatDatadictionary begins searching for associated occurrences. If thisparameter is omitted, Datadictionary begins with the first entity-typenamed in the defined path. Any “from” entity-type named in the pathdefinition may be used as the starting point for the report.

When coded, the entity parameter is separated from the word START bya comma. The comma must be coded even if the entity parameter is notused. The only exception to this requirement is when no parameters arecoded. The following examples show valid coding formats:

-RPT START,entity,occ-name,path-name

-RPT START,,occ-name,path-name

parent-name.The parent-name parameter designates whether the search for relatedoccurrences is to proceed from a specific record, table, or view; fromrecords, tables, or views selected by a generic search; or all records,tables or views along the path. This parameter is used when theentity-type is KEY, ELEMENT, or FIELD.

If this parameter is omitted or if the word ALL is coded, the report includesoccurrences for all records, tables and views along the path. If theparent-name is coded, the occ-name parameter must also be coded. Theocc-name parameter is described after the following examples.

When coded, the parent-name parameter is separated from the entityparameter by a comma. If the path-name parameter is used without the(vrs,ovrd) parameter, the comma must be coded, even if the parent-nameparameter is not used.

The following examples show valid coding formats for the parent-nameparameters:

-RPT START,entity,parent-name.occ-name,path-name

-RPT START,entity,,path-name

occ-nameThis parameter designates whether the search for associated occurrencesis to proceed from one specific occurrence, from occurrences selected bya generic search, or from all applicable occurrences within the STARTtransaction entity-type. If this parameter is omitted or if the word ALL iscoded, Datadictionary begins with the first occurrence along the path andtraces associated occurrences for all occurrences in the STARTtransaction entity-type that qualify for the path.

If an occurrence name is coded, the report is limited to occurrences alongthe path that are associated with the named occurrence. Any occurrence



within a “from” entity-type named in the path definition can be used as thestarting point.

When coded, the occ-name parameter is separated from the entity-typeparameter by a comma. The comma must be coded if the path-nameparameter is coded without the (vrs,ovrd) parameter, even if the occ-nameparameter or the parent-name parameters are not used. The followingexamples show valid coding formats:

-RPT START,entity,occ-name,path-name

-RPT START,entity,,path-name

(vrs)This parameter limits report output to a specific version or status. If thisparameter is omitted, Datadictionary includes all versions.

If you code ALLV (all versions) as the version when anchored on aPRODuction status CA Datacom/DB or CA FILE Model structure, allrelated structure occurrences in HISTory status and PRODuction statusare returned. If both occurrences are non-Model entity-types or theanchor is a non-Model entity-type and is related to a Model entity-type,you receive all related occurrences regardless of their status. Examplesof the relationships that demonstrate this are program-to-program orprogram-to-dataview relationships.

When coded, the parameter is separated from previous parameters by aleft parenthesis. If the override parameter is not used, the versionparameter must be closed by a right parenthesis. The following examplesshow valid coding formats:

-RPT START,entity(vrs),path-name

-RPT START,,occ-name(vrs),path-name

-RPT START,entity,occ-name(vrs),path-name,as-of-date

(,ovrd)Use the ovrd parameter to supply the override code specified on yoursystem. If at least one occurrence defined by the START transaction isprotected by a Lock Level 2 restriction, you must supply the overridecode. Also, if other occurrences along the path are protected by a LockLevel 2 restriction, use the override code in the report requests.

When used, the override code is separated from the version parameter bya comma and is followed by a right parenthesis. The comma must becoded even if the version parameter is not used. The following examplesshow valid coding formats:

-RPT START,entity,occ-name(vrs,ovrd),path-name

-RPT START,entity,occ-name(,ovrd),path-name

,path-nameThis parameter designates which path Datadictionary is to follow whensearching for related occurrences. The path must have been previously



defined in the report transaction collection. The path name is separatedfrom other words by a comma.

,as-of-dateIf ASOF is coded in the vrs parameter, it specifies that a date and timewill be used to retrieve the PRODuction status version of the occurrenceson the specified date and time. If the full date and time is not known, apartial date/time can be given. Any of the date/time positions not entereddefault to zero or the earliest period of the date/time provided. Forexample, 20080601 is the beginning of the day June 1, 2008, whereas200806012359 is the end of the same day. This modifier is only valid forDetail, Field, Indented, and Index reports.


Coding Modifiers When Using Pathing

Report requests are coded in an alternate format when combined with a path.The following format applies to all reports that use pathing:

��──-RPT──rpt-type─ ──┬ ┬─────────────────────────── ──┬ ┬──────────── ────────────�� └ ┘ ─,──entity─ ──┬ ┬─(vrs)────── └ ┘ ─,modifiers─ ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

Report requests can be grouped under one START transaction. Datadictionaryproduces all requested reports for one occurrence before proceeding to thenext occurrence along the path. If no request is made for a report for a givenentity-type either specifically or generically, any occurrences of that entity-typeare skipped during reporting. Any occurrences at a lower level in the path arereported if requested.

Note: Reports that do not skip to the top of a new page between occurrences(Index, Text with the ALIGN option, Indent, and Relationship) may appear tocombine with other reports that do page, such as Detail, Field and TEXT (whenALIGN is specified). When a non-paging report combines with a paging report,the result can be undesirable. As a rule, do not combine non-paging reportswith paging reports. A discussion of each parameter follows:

rpt-typeThe rpt-type parameter indicates the type of report which you arerequesting. You can specify any of the report types presented in thismanual except Alias, Descriptor, and Definitions reports which do not usepathing.

entityThe entity parameter indicates the entity-type on which to report. Omitthis parameter if all entity-types along the path are to be included on thereport. Coding an entity-type name limits the report output to occurrencesalong the path that are within the named entity-type.



When coded, the entity parameter is separated from the rpt-typeparameter by a comma. If the modifiers parameter is used without the(vrs,ovrd) parameter, the comma must be coded, even if the entityparameter is not used. The following examples show valid codingformats:

-RPT rpt-type,entity

-RPT rpt-type,,modifiers

vrs,ovrdThe vrs,ovrd parameter limits the report's output to a specific version orstatus or accesses occurrences protected by a Lock Level 2 restriction.When coded, the parameter is separated from preceding words by a leftparenthesis, the override code is separated from the version by a commaand the parameter is closed by a right parenthesis. The followingexamples show valid coding formats:

-RPT rpt-name,entity(vrs,ovrd)

-RPT rpt-name,entity(vrs)

-RPT rpt-name,entity(,ovrd)

Modifiers

Some reports allow a modifiers parameter that can be used to modify theselection of occurrences or the format of the report. Valid modifiers arediscussed for each report type in later sections of this document. When coded,the modifiers parameter is separated from other words by a comma, andmodifiers are separated from each other by commas.

Ending the Report Request

A report group must be followed by an -END statement coded in columns 1-4.Any report requests after the START transaction but preceding the -ENDstatement are processed with the path. Any report requests after the -ENDstatement are processed separately.

Example Modified Report Requests

The following examples show various ways to code Datadictionary reportrequests:

-RPT START,DATABASE,DATA-DICT(PROD),STANDARD -RPT INDENT,DATABASE -RPT INDENT,AREA -RPT INDENT,TABLE -END

The previous request reports on the PRODuction status version of theDATA-DICT database using the STANDARD path. Datadictionary produces anIndented Report for the DATABASE, AREA and TABLE occurrences.



-DEF PATH,STANDARD -END -RPT START,DATABASE,DATA-DICT(ASOF),STANDARD, - 2861 -RPT FIELD,TABLE -END

The previous request generates a Field Report for all TABLE occurrences inPRODuction status on June 1, 2008. Note the use of the continuationcharacter before the as-of-date. The continuation character was not necessaryfor this report request but is used for example only.

Reporting Valid Entity-Types

To list all valid entity-types, use the following path report:

-DEF PATH,STANDARD -END -RPT START,DATABASE,DATA-DICT(PROD),STANDARD -RPT INDEX,TABLE -END


Sample Job Streams

Sample Job Streams

The function of DDUTILTY is to process the -USR, -RPT, -DEF and -UTLtransactions within Datadictionary.

z/OS Example JCL

An z/OS example JCL for DDUTILTY follows. Enter the -USR, -RPT, -DEF, or-UTL transactions where indicated.


//jobname See the note above and page 19. // EXEC PGM=DDUTILTY,REGION=6K //STEPLIB See the note above and page 19. //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR ... Authorized user information . . . Your transactions . . /


Sample Job Streams

z/VSE Example JCL

A z/VSE example JCL for DDUTILTY follows. Enter the -USR, -RPT, -DEF, or-UTL transactions where indicated.


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // EXEC DDUTILTY,SIZE=6K -USR ... Authorized user information . . . Your transactions . . / /& $$ EOJ


Example Reports

Example Reports

The examples on the following pages show report transaction collections thatuse pathing and nested pathing. Sample report output is shown for eachtransaction collection.

The following example shows an Index Report listing occurrences associatedalong the STANDARD path of relationships. Associated occurrences are tracedfrom the ACCTS area.

Single Report Request









-DEF PATH,STANDARD ;-END




-RPT START,AREA,ACCTS(T1),STANDARD ;-RPT INDEX ;-END ;


Example Reports



User: SAMPLE-USER DD Base: 2ENTITY-TYPE..................... OCCURRENCE...................... VRSN STS LK PSWD DESCRIPTION.......................... RECORD.......................... ELEMENT.........................

AREA ACCTS T1 T ORDER-ENTRY ACCTS AREATABLE ACCTS T1 T ORDER-ENTRY ACCTS TABLEKEY CUST-ID-KEY T1 T CUST-ID SECONDARY KEY ACCTSKEY ORD-ID-KEY T1 T ORD-ID MASTER KEY ACCTSELEMENT ACCTS T1 T ACCTS FULL TABLE ELEMENT ACCTSELEMENT CUST-ID T1 T CUST-ID ELEMENT ACCTSELEMENT ORD-ID T1 T ORD-ID ELEMENT ACCTSFIELD ORD-ID T1 T ACCTS ORD-ID FIELD ACCTSFIELD BILL-DT T1 T ACCTS BILL-DT FIELD ACCTSFIELD BILL-YR T1 T ACCTS BILL-YR FIELD ACCTSFIELD BILL-MO T1 T ACCTS BILL-MO FIELD ACCTSFIELD BILL-DAY T1 T ACCTS BILL-DAY FIELD ACCTSFIELD ORD-AMT T1 T ACCTS ORD-AMT FIELD ACCTSFIELD FRT-AMT T1 T ACCTS FRT-AMT FIELD ACCTSFIELD DISC-AMT T1 T ACCTS DISC-AMT FIELD ACCTSFIELD CUST-ID T1 T ACCTS CUST-ID FIELD ACCTSFIELD IND-CD T1 T ACCTS IND-CD FIELD ACCTS




FIELD CUST-NO T1 T ACCTS CUST-NO FIELD ACCTS

END OF JOB


Example Reports

Grouping Reports in a Request

The following example requests a combination Indented and Text Report listingoccurrences associated along the STANDARD path. Associated occurrencesare traced from the ACCTS area.











Example Reports




-RPT START,AREA,ACCTS(T1),STANDARD ;-RPT INDENT,,ALIGN ;-RPT TEXT,,ALIGN ;-END ;ARA ACCTS T T1

ORDER-ENTRY ACCTS AREA ACCTS_AREA NO TEXT DATA FOR ENTITY TYPE..AREA NAME..ACCTS

TBL ACCTS T T1ORDER-ENTRY ACCTS TABLE

The ACCTS table consists of the order-id; billing date (YYMMDD format);the order, freight and discount amounts; and customer identification

information.

KEY ACCTS.CUST-ID-KEY T T1CUST-ID SECONDARY KEY

NO TEXT DATA FOR ENTITY TYPE..KEY NAME..CUST-ID-KEY

KEY ACCTS.ORD-ID-KEY T T1ORD-ID MASTER KEY

NO TEXT DATA FOR ENTITY TYPE..KEY NAME..ORD-ID-KEY

ELM ACCTS.ACCTS T T1ACCTS FULL TABLE ELEMENT

The ACCTS element of the ACCTS table consists of the order-id;billing date (in YYMMDD format); the order, freight and discountamounts; and customer identification information.All fields in the ACCTS table are included in this element.

ELM ACCTS.CUST-ID T T1 CUST-ID ELEMENT

The CUST-ID element of the ACCTS table consists of information whichidentifies the customer (customer-id, customer number, etc.).

ELM ACCTS.ORD-ID T T1 ORD-ID ELEMENT

The ORD-ID element of the ACCTS table consists of the single field ORD-ID (order-id).

FLD ACCTS.ORD-ID T T1ACCTS ORD-ID FIELD

ORD_ID NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..ORD-ID

FLD ACCTS.BILL-DT T T1ACCTS BILL-DT FIELD

BILL_DT NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..BILL-DT

FLD ACCTS.BILL-YR T T1ACCTS BILL-YR FIELD

BILL_YR


Example Reports



User: SAMPLE-USER DD Base: 2 NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..BILL-YR

FLD ACCTS.BILL-MO T T1ACCTS BILL-MO FIELD

BILL_MO NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..BILL-MO

FLD ACCTS.BILL-DAY T T1ACCTS BILL-DAY FIELD

BILL_DAY NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..BILL-DAY

FLD ACCTS.ORD-AMT T T1ACCTS ORD-AMT FIELD

ORD_AMT NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..ORD-AMT

FLD ACCTS.FRT-AMT T T1ACCTS FRT-AMT FIELD

FRT_AMT NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..FRT-AMT

FLD ACCTS.DISC-AMT T T1ACCTS DISC-AMT FIELD

DISC_AMT NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..DISC-AMT

FLD ACCTS.CUST-ID T T1ACCTS CUST-ID FIELD

CUST_ID NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..CUST-ID

FLD ACCTS.IND-CD T T1ACCTS IND-CD FIELD

IND_CD NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..IND-CD

FLD ACCTS.CUST-NO T T1ACCTS CUST-NO FIELD

CUST_NO NO TEXT DATA FOR ENTITY TYPE..FIELD NAME..CUST-NO

END OF JOB


Example Reports

Using a Nested Path in a Request

In this example, the nested path is used to change the report output from acombination Indented and Text Report to an Indented Report only.









-DEF PATH,MAINPATH ;-DEF TRACE,DATABASE.AREA,$INTERNAL ;-DEF TRACE,AREA.TABLE,$INTERNAL ;-END ;




-DEF PATH,ELM-FLDS ;-DEF TRACE,TABLE.ELEMENT,$INTERNAL ;-DEF TRACE,ELEMENT.FIELD,$INTERNAL ;-END ;


Example Reports




-RPT START,AREA,ACCTS(T1),MAINPATH ;-RPT INDENT,,ALIGN ;-RPT TEXT,,ALIGN ;-RPT NEST,TABLE,ELM-FLDS ;-RPT INDENT,ELEMENT,ALIGN ;-RPT INDENT,FIELD,ALIGN ;-RPT NESTEND ;-END ;ARA ACCTS T T1

ORDER-ENTRY ACCTS AREA ACCTS_AREA NO TEXT DATA FOR ENTITY TYPE..AREA NAME..ACCTS

TBL ACCTS T T1ORDER-ENTRY ACCTS TABLE

The ACCTS table consists of the order-id; billing date (YYMMDD format);the order, freight and discount amounts; and customer identification

information.

ELM ACCTS.ACCTS T T1ACCTS FULL TABLE ELEMENT


ORD_ID FLD ACCTS.BILL-DT T T1

ACCTS BILL-DT FIELD BILL_DT FLD ACCTS.BILL-YR T T1

ACCTS BILL-YR FIELD BILL_YR FLD ACCTS.BILL-MO T T1

ACCTS BILL-MO FIELD BILL_MO FLD ACCTS.BILL-DAY T T1

ACCTS BILL-DAY FIELD BILL_DAY FLD ACCTS.ORD-AMT T T1

ACCTS ORD-AMT FIELD ORD_AMT FLD ACCTS.FRT-AMT T T1

ACCTS FRT-AMT FIELD FRT_AMT


Example Reports





DISC_AMT FLD ACCTS.CUST-ID T T1

ACCTS CUST-ID FIELD CUST_ID FLD ACCTS.IND-CD T T1

ACCTS IND-CD FIELD IND_CD FLD ACCTS.CUST-NO T T1

ACCTS CUST-NO FIELD CUST_NO ELM ACCTS.CUST-ID T T1 CUST-ID ELEMENT FLD ACCTS.CUST-ID T T1

ACCTS CUST-ID FIELD CUST_ID FLD ACCTS.IND-CD T T1

ACCTS IND-CD FIELD IND_CD FLD ACCTS.CUST-NO T T1

ACCTS CUST-NO FIELD CUST_NO ELM ACCTS.ORD-ID T T1 ORD-ID ELEMENT FLD ACCTS.ORD-ID T T1

ACCTS ORD-ID FIELD ORD_ID

END OF JOB


Alias Report

Alias Report

The Alias Report lists all occurrences selected by the report request that havealiases. Occurrences are sorted alphabetically by alias name.

The Alias Report differs from other reports in that the report request includes analias parameter instead of an occurrence parameter. Also, pathing is not usedwith an Alias Report request.

Report Content

Only occurrences that have aliases will appear on the report. The Alias Reportlists the following information in left-to-right order. If the actual attribute namesare different from the printed headings on the reports, they appear inparentheses.

ALIASEntity-occurrence's alias name

ENTITY-TYPEEntity-type to which the occurrence belongs

OCCURRENCE (ENTITY-NAME)Entity-occurrence name

VERSION (ENTITY-VER)Version number of the occurrence

STATUSStatus of the occurrence

DESCRIPTIONEntity-occurrence description

Request Format

Use the following format for an Alias Report request:

��──-RPT──ALIAS─ ──┬ ┬───────────────────────────────────────── ─────────────────�� └ ┘ ─,──entity─ ──┬ ┬────────── ──┬ ┬─(vrs)────── └ ┘ ─,──alias─ ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

,entityThe entity parameter can be used to limit the report to occurrences withinone entity-type. If this parameter is omitted or if the word ALL is coded,Datadictionary includes all occurrences that have aliases.

,aliasCoding an alias name limits the report to a specific alias name. The aliasparameter can be left blank or the word ALL can be coded to signify that


Alias Report

all aliases or all aliases within the specified entity-type are to be includedin the report.

You can use an asterisk (*) for a generic selection of all aliases that beginwith the string of characters preceding the asterisk.

(vrs)The version parameter limits report output to a specific version or status.If the parameter is omitted, the report includes occurrences that meet allother specified criteria regardless of version or status.

(,ovrd)The override code must be coded in the report request if all occurrencesthat are protected by a Lock Level 2 restriction are to be considered forthe report.

Example

In the following example, the request results in a report that includes alloccurrences which have an alias that begins with the letters CUST.

-RPT ALIAS,,CUST -END

ALIAS Report - By Entity-Type









-RPT ALIAS,FIELD,ALL(T1) ;-END ;


Alias Report


Security Level: 1 Alias Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ALIAS........................... ENTITY-TYPE................... OCCURRENCE....................................................... VERSION STATUS DESCRIPTION.........................

ACCTS-BILL-DAY FIELD ACCTS.BILL-DAY T1 TEST

ACCTS BILL-DAY FIELDACCTS-BILL-DT FIELD ACCTS.BILL-DT T1 TEST

ACCTS BILL-DT FIELDACCTS-BILL-MO FIELD ACCTS.BILL-MO T1 TEST

ACCTS BILL-MO FIELDACCTS-BILL-YR FIELD ACCTS.BILL-YR T1 TEST

ACCTS BILL-YR FIELDACCTS-CUST-ID FIELD ACCTS.CUST-ID T1 TEST

ACCTS CUST-ID FIELDACCTS-CUST-NO FIELD ACCTS.CUST-NO T1 TEST

ACCTS CUST-NO FIELDACCTS-DISC-AMT FIELD ACCTS.DISC-AMT T1 TEST

ACCTS DISC-AMT FIELDACCTS-FRT-AMT FIELD ACCTS.FRT-AMT T1 TEST

ACCTS FRT-AMT FIELDACCTS-IND-CD FIELD ACCTS.IND-CD T1 TEST

ACCTS IND-CD FIELDACCTS-ORD-AMT FIELD ACCTS.ORD-AMT T1 TEST

ACCTS ORD-AMT FIELD




ACCTS-ORD-ID FIELD ACCTS.ORD-ID T1 TEST

ACCTS ORD-ID FIELD END OF JOB


Alias Report

ALIAS Report - By Alias Name









-RPT ALIAS,,ACCT(PROD) ;-END ;


Alias Report




ACCTS-AREA AREA ACCTS 3 PROD

ORDER-ENTRY ACCTS AREAACCTS-BILL-DAY FIELD ACCTS.BILL-DAY 3 PROD

ACCTS BILL-DAY FIELDACCTS-BILL-DT FIELD ACCTS.BILL-DT 3 PROD

ACCTS BILL-DT FIELDACCTS-BILL-MO FIELD ACCTS.BILL-MO 3 PROD

ACCTS BILL-MO FIELDACCTS-BILL-YR FIELD ACCTS.BILL-YR 3 PROD

ACCTS BILL-YR FIELDACCTS-CUST-ID FIELD ACCTS.CUST-ID 3 PROD

ACCTS CUST-ID FIELDACCTS-CUST-NO FIELD ACCTS.CUST-NO 3 PROD

ACCTS CUST-NO FIELDACCTS-DISC-AMT FIELD ACCTS.DISC-AMT 3 PROD

ACCTS DISC-AMT FIELDACCTS-ELEMENT ELEMENT ACCTS.ACCTS 3 PROD

ACCTS FULL TABLE ELEMENTACCTS-FRT-AMT FIELD ACCTS.FRT-AMT 3 PROD

ACCTS FRT-AMT FIELD




ACCTS-IND-CD FIELD ACCTS.IND-CD 3 PROD

ACCTS IND-CD FIELDACCTS-ORD-AMT FIELD ACCTS.ORD-AMT 3 PROD

ACCTS ORD-AMT FIELDACCTS-ORD-ID FIELD ACCTS.ORD-ID 3 PROD

ACCTS ORD-ID FIELDACCTS-TABLE TABLE ACCTS 3 PROD

ORDER-ENTRY ACCTS TABLE END OF JOB


Definitions Report

Definitions Report

The Definitions Report lists relationship definition information for a specifiedsubject entity-type or for all entity-types. This report is useful when building arelationship-type among a set of occurrences. The report can also be usedwhen designing a report path, since entity-types paired in a TRACE transactionmust be the subject and object of a relationship.

Report Content

The Definitions Report lists the following information in left-to-right order. If theactual attribute names are different from the printed headings on the reports,they appear in parentheses.

RELATIONSHIP NAMERelationship name

SUBJECT TYPESubject entity-type

OBJECT TYPEObject entity-type

AUTO (AUTO-RULE)Automatic relationship: Y indicates yes, N indicates no

REQ (REQUIRED-RULE)Required relationship: Y indicates yes, N indicates no

ORD (ORDERED-RULE)Ordered relationship: Y indicates yes, N indicates no

MAP (OCC-MAP-RULE)Relationship mapping:

1M Indicates one-to-many

MM Indicates many-to-many

11 Indicates one-to-one

M1 Indicates many-to-one

C (COPY-RULE)COPY-RULE designates if the occurrence's relationships are copied to thenew occurrence.

B All occurrences of the relationship are copied whether theoccurrence you are copying is the subject or the object.

M See the CA Datacom Datadictionary User Guide for an explanationof this attribute-value.

N No occurrences of the relationship are copied.


Definitions Report

O If the occurrence you are copying is the object of the relationship, alloccurrences of this relationship are copied.

S If the occurrence you are copying is the subject of the relationship,all occurrences of the relationship are copied.

M (MODEL-RULE)MODEL-RULE designates if the occurrence's relationships are copied tothe modeled occurrence.

B All occurrences of the relationship are copied whether theoccurrence you are copying is the subject or the object.

N No occurrences of the relationship are copied.

O If the occurrence you are copying is the object of the relationship, alloccurrences of this relationship are copied.

S If the occurrence you are copying is the subject of the relationship,all occurrences of the relationship are copied.

Request Format

Use the following format for a Definitions Report request:

��──-RPT──DEFINE─ ──┬ ┬───────── ────────────────────────────────────────────────�� └ ┘ ─,entity─

The entity parameter can be coded with a valid entity-type or ALL. If anentity-type is coded, the report is limited to relationships using the namedentity-type as the subject.

Example

The following are examples of the Definitions Report.

DEFINITIONS Report - By Entity-Type







Definitions Report




-RPT DEFIN,TABLE ;


Security Level: 1 Definitions Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2RELATIONSHIP NAME............... SUBJECT TYPE.................... OBJECT TYPE..................... AUTO REQ ORD MAP C M

$INTERNAL TABLE ELEMENT NO NO NO 1M B N$INTERNAL TABLE KEY NO NO NO 1M B N

END OF JOB

DEFINITIONS Report - For All Entity-Types

The report produced by this transaction lists all the relationships defined in theDatadictionary. The following are selected pages.









-RPT DEFIN ;




$INTERNAL AREA FILE NO NO NO MM B N$INTERNAL AREA TABLE NO YES NO 1M B N


Definitions Report




$DD-ATZ-ENT-P AUTHORIZATION TABLE NO NO NO MM M N$DD-ATZ-ENT-SEC AUTHORIZATION FILE NO NO NO MM M N$DD-ATZ-ENT-SEC AUTHORIZATION TABLE NO NO NO MM M N$DD-ATZ-ENT-T AUTHORIZATION FILE NO NO NO MM M N$DD-ATZ-ENT-T AUTHORIZATION TABLE NO NO NO MM M N$DD-ATZ-SYS-SEC AUTHORIZATION SYSTEM NO NO NO MM B NATZ-PLN-OWNS AUTHORIZATION PLAN NO YES NO 1M B NATZ-SYN-OWNS AUTHORIZATION SYNONYM NO YES NO 1M B NATZ-TBL-OWNS AUTHORIZATION TABLE NO NO NO 1M B NATZ-VEW-OWNS AUTHORIZATION VIEW NO YES NO 1M B N




$INTERNAL DATABASE AREA NO YES NO 1M B N$PARTITIONED DATABASE DATABASE NO NO YES MM M N$REPLICATED DATABASE DATABASE NO NO YES MM M N$RESIDES DATABASE NODE NO NO NO MM B N

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .




$INTERNAL DATAVIEW ELEMENT NO NO YES MM B N$INTERNAL DATAVIEW KEY NO NO YES MM B NDVW-SQL-ACCESS DATAVIEW SYNONYM NO NO NO M1 B NDVW-SQL-ACCESS DATAVIEW TABLE NO NO NO M1 B NDVW-SQL-ACCESS DATAVIEW VIEW NO NO NO M1 B N

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .




FLD-FLD-DEPENDS FIELD FIELD NO NO NO MM B N


Definitions Report




JOB-STP-CONTAIN JOB STEP NO NO NO 1M B N




LIB-FIL-RESIDE LIBRARY FILE NO NO NO MM M NLIB-MEM-CONTAIN LIBRARY MEMBER YES NO NO 1M B N




MEM-ELM-COPY MEMBER ELEMENT YES NO NO MM M NMEM-MEM-INCLUDE MEMBER MEMBER YES NO NO MM B N




MOD-PGM-CONTAIN MODULE PROGRAM NO NO NO MM B N




$ACCESS NODE DATABASE NO NO NO MM M NNOD-BAS-ACCESS NODE DATABASE NO NO NO MM M NNOD-FIL-ACCESS NODE FILE NO NO NO 1M M N


Definitions Report




PER-ATZ-AUTH PERSON AUTHORIZATION NO NO NO MM B BPER-ATZ-AUTHID PERSON AUTHORIZATION NO NO NO 11 B NPER-ATZ-SQL-ACCESS PERSON AUTHORIZATION NO NO NO MM B NPER-MEM-ACCESS PERSON MEMBER YES NO NO 1M B NPER-PGM-ACCESS PERSON PROGRAM NO NO NO MM B NPER-PNL-ACCESS PERSON PANEL NO NO NO MM B NPER-RPT-ACCESS PERSON REPORT NO NO NO MM B NPER-SYS-ACCESS PERSON SYSTEM NO NO NO MM B B




PGM-DVW-USE PROGRAM DATAVIEW YES NO NO MM M NPGM-MEM-CONTAIN PROGRAM MEMBER YES NO NO MM B NPGM-PGM-CALL PROGRAM PROGRAM YES NO NO MM S SPGM-PLN-USES PROGRAM PLAN NO NO NO 11 B NPGM-PNL-USE PROGRAM PANEL YES NO NO MM S NPGM-RPT-PRODUCE PROGRAM REPORT YES NO NO MM S NPGM-STM-CONTAIN PROGRAM STATEMENT NO NO NO 1M B N

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .




STM-KEY-DEPENDS STATEMENT KEY NO NO NO MM B NSTM-SYN-DEPENDS STATEMENT SYNONYM NO NO NO MM B NSTM-TBL-DEPENDS STATEMENT TABLE NO NO NO MM B NSTM-VEW-DEPENDS STATEMENT VIEW NO NO NO MM B N

END OF JOB


Descriptors Report

Descriptors Report

The Descriptors Report lists all occurrences selected by the report request thathave descriptors. Entity-occurrences are sorted alphabetically by descriptorname.

The Descriptors Report differs from other reports in that the report requestincludes a descriptor parameter instead of an occurrence parameter. Also,pathing is not used with a Descriptors Report request.

Report Content

Only occurrences that have descriptors appear on the report. The DescriptorsReport lists the following information in left-to-right order.

DESCRIPTOREntity-occurrence's descriptor name

ENTITY-TYPEEntity to which the occurrence belongs

OCCURRENCE (ENTITY-NAME)Entity-occurrence name

VERSION (ENTITY-VER)Version number of the occurrence

STATUSStatus of the occurrence

DESCRIPTIONEntity-occurrence description

Request Format

Use the following format for a Descriptors Report request:

��──-RPT──DESCRS─ ──┬ ┬────────────────────────────────────────── ────────────────� └ ┘ ─,entity─ ──┬ ┬───────────── ──┬ ┬──────────── └ ┘─,descriptor─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

�─ ──┬ ┬──────────── ────────────────────────────────────────────────────────────�� └ ┘─,modifiers─

Following is a discussion of each parameter and valid entry formats:

,entityThe entity-type parameter can be used to limit the report to descriptors foroccurrences within a specific entity-type. If this parameter is omitted,Datadictionary includes all occurrences that have descriptors.


Descriptors Report

,descriptorCoding a descriptor name limits the report to a specific descriptor name.If the parameter is omitted or the word ALL is coded, Datadictionaryincludes all occurrences that have descriptors or all occurrences within thespecified entity-type(s) that have descriptors.

You can use an asterisk (*) for a generic selection of all descriptors thatbegin with the string of characters preceding the asterisk.

(vrs)The version parameter limits report output to a specific version or status.If the parameter is omitted, the report includes occurrences that meet allother specified criteria regardless of version or status.

(,ovrd)The override code must be coded in the report request if all occurrencesthat are protected by a Lock Level 2 restriction are to be considered forthe report.

,modifiersUse this parameter to produce a report of occurrences that have morethan one descriptor. Datadictionary selects occurrences that have all ofthe descriptor words entered. You can enter as many as four descriptorwords. Each optional descriptor word must be preceded by a comma.

Example

In the following example, the request results in a report that includes alloccurrences which have both one or more descriptors that begin with the lettersPAY and one or more descriptors that begin with the letters PER:

-RPT DESCRS,,PAY,PER -END

DESCRIPTORS Report - By Entity-Type









-RPT DESCR,TABLE,ORDER-ENTRY(T1) ;-END ;


Descriptors Report


Security Level: 1 Descriptors Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2DESCRIPTOR...................... ENTITY-TYPE................... OCCURRENCE....................................................... VERSION STATUS DESCRIPTION.........................

ORDER-ENTRY TABLE ACCTS T1 TEST

ORDER-ENTRY ACCTS TABLEORDER-ENTRY TABLE CUST T1 TEST

ORDER-ENTRY CUST TABLEORDER-ENTRY TABLE DETAIL T1 TEST

ORDER-ENTRY DETAIL TABLEORDER-ENTRY TABLE ORDERS T1 TEST

ORDER-ENTRY ORDERS TABLEORDER-ENTRY TABLE ITEMS T1 TEST

ORDER-ENTRY ITEMS TABLEORDER-ENTRY TABLE ORD-NO T1 TEST

ORDER-ENTRY ORDER-NUMBERS TABLEORDER-ENTRY TABLE RCPTS T1 TEST

ORDER-ENTRY RECEIPTS TABLEORDER-ENTRY TABLE SHIPTO T1 TEST

ORDER-ENTRY SHIP-TO TABLEORDER-ENTRY TABLE SLSHST T1 TEST

ORDER-ENTRY SALES-HIST TABLE END OF JOB









-RPT DESCR,,ACCTS(TEST) ;-END ;


Descriptors Report




ACCTS TABLE ACCTS T1 TEST

ORDER-ENTRY ACCTS TABLEACCTS FIELD ACCTS.ORD-ID T1 TEST

ACCTS ORD-ID FIELDACCTS FIELD ACCTS.BILL-DT T1 TEST

ACCTS BILL-DT FIELDACCTS FIELD ACCTS.BILL-YR T1 TEST

ACCTS BILL-YR FIELDACCTS FIELD ACCTS.BILL-MO T1 TEST

ACCTS BILL-MO FIELDACCTS FIELD ACCTS.BILL-DAY T1 TEST

ACCTS BILL-DAY FIELDACCTS FIELD ACCTS.ORD-AMT T1 TEST

ACCTS ORD-AMT FIELDACCTS FIELD ACCTS.FRT-AMT T1 TEST

ACCTS FRT-AMT FIELDACCTS FIELD ACCTS.DISC-AMT T1 TEST

ACCTS DISC-AMT FIELDACCTS FIELD ACCTS.CUST-ID T1 TEST

ACCTS CUST-ID FIELD




ACCTS FIELD ACCTS.IND-CD T1 TEST

ACCTS IND-CD FIELDACCTS FIELD ACCTS.CUST-NO T1 TEST

ACCTS CUST-NO FIELD END OF JOB







Descriptors Report




-RPT DESCR,,ORDER-ENTRY(TEST),ACCTS ;-END ;




ORDER-ENTRY TABLE ACCTS T1 TEST

ORDER-ENTRY ACCTS TABLEORDER-ENTRY FIELD ACCTS.ORD-ID T1 TEST

ACCTS ORD-ID FIELDORDER-ENTRY FIELD ACCTS.BILL-DT T1 TEST

ACCTS BILL-DT FIELDORDER-ENTRY FIELD ACCTS.BILL-YR T1 TEST

ACCTS BILL-YR FIELDORDER-ENTRY FIELD ACCTS.BILL-MO T1 TEST

ACCTS BILL-MO FIELDORDER-ENTRY FIELD ACCTS.BILL-DAY T1 TEST

ACCTS BILL-DAY FIELDORDER-ENTRY FIELD ACCTS.ORD-AMT T1 TEST

ACCTS ORD-AMT FIELDORDER-ENTRY FIELD ACCTS.FRT-AMT T1 TEST

ACCTS FRT-AMT FIELDORDER-ENTRY FIELD ACCTS.DISC-AMT T1 TEST

ACCTS DISC-AMT FIELDORDER-ENTRY FIELD ACCTS.CUST-ID T1 TEST

ACCTS CUST-ID FIELD




ORDER-ENTRY FIELD ACCTS.IND-CD T1 TEST

ACCTS IND-CD FIELDORDER-ENTRY FIELD ACCTS.CUST-NO T1 TEST

ACCTS CUST-NO FIELD END OF JOB


Detail Report

Detail Report

The Detail Report provides itemized information about an entity-occurrence.The basic report includes a heading that lists identification information, followedby a listing of descriptive information about the entity-occurrence. Thedescriptive information consists of attribute-types, which are listed on the leftand their assigned attribute-values, which are listed to the right. You can addmodifiers to your request that can expand the report to include alias, descriptorword, or text information.

Request Format

Use the following format for a Detail Report request:

��──-RPT──DETAIL───────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ──┬ ┬──────────── ───────────────────────────────────────────�� └ ┘ ─,as-of-date─ └ ┘ ─,modifiers─

When submitting with a path, use the following format for a Detail Reportrequest:

Detail Report When Submitting with a Path (Step 1)

��──-RPT──START────────────────────────────────────────────────────────────────�

�─ ──┬ ┬────────────────────────────────────────────────────────── ─,path-name────� └ ┘ ─,entity,─ ──┬ ┬────────────── ──┬ ┬────────── ──┬ ┬──────────── └ ┘ ─parent-name.─ └ ┘ ─occ-name─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

Detail Report When Submitting with a Path (Step 2)

��──-RPT──DETAIL─ ──┬ ┬───────────────────────── ──┬ ┬──────────── ────────�� └ ┘ ─,entity─ ──┬ ┬──────────── └ ┘ ─,modifiers─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

For more information and discussions of the parameters, see “Coding theBasic Report Request” on page 412 and “Using Pathing in Reporting” onpage 418.


Detail Report

,modifiersUse the modifiers parameter to modify the report to include moreinformation or to suppress the printing of the attribute-types andattribute-values. You can code any combination of modifiers in any order.Each modifier coded must be preceded by a comma.

Note: If you code ASOF as the version, you must code the date/time alias(,as-of-date in the above syntax) before the first modifier. Use theyyyymmddhhmm format. For more information, see 415.

Note: If your time value includes seconds, round up to the nearest minute.

The following are the modifiers:

ALIAS or ACauses the occurrence's aliases to be included on the report.

DESC or DCauses the entity-occurrence's descriptors to be included.

TEXT or TCauses all the text (all text classes) associated with the occurrence to beprinted. If an occurrence has text in multiple text classes, the classes willbe printed in alphabetical order.

NODETAILor N

Suppresses the printing of attributes and their values. This modifiershould be used in combination with at least one of the above modifiers.

Report Heading Content

The report heading contains the following information listed in left-to-right order.If the actual attribute names are different from the printed headings on thereport, they appear in parentheses.

ENTITY-TYPEEntity-occurrence's entity-type

DESC (DESCRIPTION)Entity-occurrence description

NAME (ENTITY-NAME)Entity-occurrence name

STATUSThe status of the occurrence

AUTHORAuthor's identification

CONTROLLERController identification


Detail Report

COPY-VERSION (PREVIOUS-VERS)Number of the version that was copied to produce this version of theentity-occurrence

DATE-ADDEDDate the entity-occurrence was added

DATE-LAST-CHANGED (DATE-LAST-CHG)Date the entity-occurrence was last updated

TIME-OF-CHANGE (TIME-LAST-CHG)Time of day that the entity-occurrence was changed or if no updates haveoccurred, this shows the time the entity-occurrence was added

NUMBER-OF-CHANGES (COUNT)Number of times the entity-occurrence has been updated

Report Content

Reports can be produced for both standard entity-types and user-definedentity-types. The attribute-types listed in the report body for standardentity-types are discussed in the following sections.

The aliases, descriptors, and text for each occurrence are displayed whenthose modifiers are specified in your transaction. The attributes and theirvalues are not displayed when the NODETAIL modifier is entered.

Note: If you select a FIELD occurrence that has no text and has the samename as a FIELD occurrence in the UNIVERSAL record, Datadictionary usesthe text associated with the universal field for the selected field.

AREA Detail Report

This report lists all attribute-types and the current attribute-values for the AREAoccurrence.

ACCESS-MTHDAccess method used, such as: BDAM, DAM, BPAM, QSAM, SAM,BSAM, ISAM, EXCP, VSAM, QISAM, or BISAM.

BLOCK-SIZEThe area's maximum physical block size in bytes.

DATA-DICT-IDThe database ID of the DATA-DICT database.

DATA-SET-NAMEThe area's physical data set name.

DATACOM-NAMEDATACOM-NAME attribute for the area.


Detail Report

DBMS-USEDDatabase Management System used, such as: DATACOM, IBM/DB2,IBM/DL1, IBM/IMS, TOTAL, or NONE.

DD-NAMEData definition name.

DEVICEDevice type used, such as: FBA, MDISK, 2314, 3340, 3350, 3370, 3375,3380, 3390, or 9345.

DYNAMIC-EXTENDIndicates whether CA Datacom/DB will extend the data area dynamically.Y indicates yes, N indicates no.

ENABLEIndicates whether the definition is in synchronization with the Directory(CXX) and is available for use by other CA products. Y indicates yes, Nindicates no.

RPSIndicates whether rotational position sensing is used. Y indicates yes, Nindicates no.

SLACKThe number of bytes to be reserved in each block of an area forexpansion during an update of a compressed record.

SPACE-MNGMNTThe CA Datacom/DB space management option in effect for this area.

SQLNAMEThe SQL name for the area.

AUTHORIZATION Detail Report

This report lists the attribute-types and the current attribute-values for theAUTHORIZATION occurrence.

AUTH-USAGEIndicates if the occurrence is used as an authorization identifier for aschema in SQL processing. S indicates yes, blank indicates no. For moreinformation, see the CA Datacom/DB SQL User Guide.

CLASS-CODEThe security classification code that has been established to identify theauthorization granted.

PRODUCT-IDThe product identifier of the product to which the authorization applies.


Detail Report

CONSTRAINT Detail Report

This report lists the attribute-types and the current attribute-values for theCONSTRAINT occurrence.

AUTHIDAuthorization identifier of the constraint.


FILENAMEN/A

LENGTHN/A

SQL-ACCESSIndicates whether the table associated with this constraint is accessibleduring SQL processing (internally maintained when the table is cataloged).Y indicates yes, R indicates SQL read-only, N indicates no.

SQLNAMEThe SQL name of the constraint.

DATABASE Detail Report

This report lists all attribute-types and the current attribute-values for theDATABASE occurrence.

BASE-TYPEType of Database Management System used, such as: RELATION,NETWORK, HIER or INV-LIST.

CATALOGED-DATEDate that the database structure was last cataloged to the CADatacom/DB Directory (CXX) or the BUILD function of DDCFBLD wasperformed.

CATALOGED-TIMETime that the database structure was last cataloged to the CADatacom/DB Directory (CXX) or the BUILD function of DDCFBLD wasperformed.

DATACOM-IDThe 5-digit DATACOM-ID attribute of the database.

DBMS-USEDDatabase Management System used, such as: DATACOM, IBM/DB2,CA/SQL, IBM/DL1, IBM/IMS, or TOTAL.


Detail Report

DDD-BASE-IDThe 5-digit DATACOM-ID attribute of the Data Definition Directory of theDatadictionary.

DL1T-CONSTRAINTIndicates if the database is eligible for CA Datacom DL1 Transparencyintegrity processing. Y indicates yes, N indicates no.

DYNAMIC-EXTENDIndicates whether CA Datacom/DB will extend the index area for thisdatabase dynamically. Y indicates yes, N indicates no.


SQL-ACCESSIndicates whether the table associated with this constraint is accessibleduring SQL processing (internally maintained when the table is cataloged).

SQLNAMEThe SQL name of the database.

SQL-SECURITYIndicates if the database can be secured by SQL rules. Thisattribute-value is enforced only when security is enabled in the CADatacom/DB Master List. Y indicates SQL security of GRANT andREVOKE will be used. N indicates only CA Datacom/DB Security Facilityrules will be used.

Note: You cannot base a view on tables from databases with differentSQL-SECURITY values. For more information, see the CA DatacomSecurity Reference Guide.

DATAVIEW Detail Report

This report lists all attribute-types and the current attribute-values for theDATAVIEW occurrence.

ACCESS-CODEReserved for CA use.

ACCESS-METHODIdentifies the access method used.

ASSEMBLER-NAMEDataview's Assembler name.

CATALOGED-DATEDate that the dataview was last cataloged with the CA Ideal CATALOGfunction.


Detail Report

CATALOGED-TIMETime that the dataview was last cataloged with the CA Ideal CATALOGfunction.

COMPILED-DATEDate the dataview was last compiled.

COMPILED-TIMETime the dataview was last compiled.

COMPILER-NAMEDataview's compiler name.

DBMS-USEDIdentifies the Database Management System used. DATACOM (this isthe value if the dataview is created using Datadictionary online orDatadictionary batch)IBM/DB2, CA/SQL, NONE (one of these values is set by CA Ideal)


IMPORTED-DATEDate the dataview was imported.

IMPORTED-TIMETime the dataview was imported.

KEY-USAGEReserved for CA use.

MEMBER-NAMEMember name of the dataview in a library.

NUMBER-CHANGESNumber of times this dataview has been changed.

NUMBER-COMPILESNumber of times this dataview has been compiled.

NUMBER-RUNSNumber of times this dataview has been used to access data.

RESOURCE-DATEDate the dataview was last resourced.

RESOURCE-TIMETime the dataview was last resourced.

STRUCT-CHNG-DTDate that the DATAVIEW structure was last changed.

STRUCT-CHNG-TMTime that the DATAVIEW structure was last changed.


Detail Report

UPDATE-INTENTIndicates whether the dataview has update capability. Y indicates yes, Nindicates no.

ELEMENT Detail Report

This report lists the attribute-types and the current attribute-values for theELEMENT occurrence.

ASM-NAMEElement's Assembler name.

COMPL-NAMEElement's Compiler name.

DATACOM-NAMEDATACOM-NAME attribute for the element.

DISP-IN-TABLEDisplacement from the beginning of the physical record (internallymaintained).


FIRST-FIELDOccurrence name of the first field of the element.

LAST-FIELDOccurrence name of the last field of the element.

LENGTHElement length (internally maintained).

SECURITY-CODECA Datacom/DB element security code.

SYNCH-CODEElement synchronization code (internally maintained during verificationprocessing).

FIELD Detail Report

This report lists the attribute-types and the current attribute-values for theFIELD occurrence. In Datadictionary, the FIELD occurrences also representthe columns defined to a table in the SQL Mode. For more information aboutSQL processing, see the CA Datacom/DB SQL User Guide.

AFTERField which physically precedes this field.


Detail Report

AGR-SQLNAMESQL name of the table to which this field was defined.

ASM-NAMEField's Assembler name.

AUTHIDFor SQL processing, authorization identifier of the table to which this fieldwas defined.

BLANK-WHEN-ZEROIndicates whether to generate a COBOL BLANK-WHEN-ZERO clauseduring copybook generation. Y indicates yes, N indicates no.

CLASSField's class: S indicates simple, C indicates compound, V indicatesvalue qualifier, F indicates filler and I indicates index.

COMPL-NAMEField's compiler name.

DATACOM-NAMEDATACOM-NAME attribute for the element if this field is designated as aone-field element.

DATA-ACCESSOnly displayed when override code is provided in report request.Indicates if the attribute can be retrieved only by the facilities which haveupdate capability of the attribute. Y indicates yes, N indicates no.

DATA-SENSITIVEIndicates that this field is a signed, numeric field that is defined to somekey in the table. If defined as a Y, CA Datacom/DB sorts the fieldcorrectly by sign and number.

This attribute-value is set during the definition of a key. To display thecorrect value, you must define a path from the key to the field. If you donot, the default value for the attribute is displayed.

DBEDITSIndicates that additional editing and processing will occur in CADatacom/DB, and that additional information about the field will be sent toCA Datacom/DB during catalog processing.

DECIMALSNumber of decimal positions in the field.

DEFAULT-INSERTIndicates the type of default value CA Datacom/DB uses for ADDIT,INSERT, UPDAT, and UPDATE processing. If TYPE=O, the VALUE fieldmust have a valid value for that data type.

DEPENDING-ONName of another field referred to with the DEPENDING-ON verb inCOBOL table handling.


Detail Report

DISP-ELEMENTDisplacement from the beginning of the element (internally maintained).

DISP-IN-TABLEDisplacement from the beginning of the record or table (internallymaintained).

DSF-ACCESSOnly displayed when override code is provided in report request.

Indicates if the attribute can be updated only by the DatadictionaryService Facility (DSF).

EDIT-PATTERNEdit pattern used with the field by products other tha CA Datacom/DB andDatadictionary.

For example, by CA Dataquery and CA Ideal.

ELM-NAMEName of the element to which the field is defined (internally maintained).

ELM-SEC-CODESecurity code for the element to which the field is defined (internallymaintained).


FORCEADDForces CA Datacom/DB to apply the field's default value duringADDIT/INSERT processing. Y indicates yes, N indicates no.

FORCEUPDForces CA Datacom/DB to apply the field's default value duringUPDAT/UPDATE processing. Y indicates yes, N indicates no.

HEADING-1Heading that can be used in columnar reports and screens generated byCA Datacom/DB Reporting Facility, CA Dataquery, CA Dataquery for PC,or CA Ideal.

HEADING-2Second line of heading that can be used in columnar reports/screens.

HIGH-RANGEHighest value if the field has a range of values. (Documentation only)

INTERNAL-ACCESSOnly displayed when override code is provided in report request.Indicates if the attribute can be updated by other CA products.

JUSTIFICATIONL indicates left justified, R indicates right justified.


Detail Report

LANG-COMNTLanguage comment used in generated data definitions for the field.

LENGTHField length in bytes. For fields defined with a V data type (VARCHAR),this value includes the automatically generated two-byte field whichdefines the data's length. For more information, see the CA Datacom/DBDatabase and System Administration Guide.

LEVELCOBOL level number assigned to the field.

LONGAn SQL-created field with a data type of LONG VARCHAR.

LOW-RANGELowest value if the field has a range of values. (Documentation only)

MEDIA-ACCESSOnly displayed when override code is provided in report request.Indicates if the attribute is updateable through standard Datadictionaryfacilities such as DDUPDATE or Datadictionary online.

MEDIA-LENGTHOnly displayed when override code is provided in report request. Displaysthe character length of the attribute for display or update purposes.

NULL-INDICATORIndicates if a one-byte null-indicator is to precede this field. Enter Y forthe null-indicator. Enter N for no null-indicator.

For fields defined with NULL-INDICATOR=Y, Datadictionary increases thelength of the table and any keys using the field by one byte. The lengthof the field, however, is not affected.

ORDERIndicates that the field in the key is to be sequenced in ascending ordescending order. A indicates ascending; D indicates descending.

This attribute-value is set during the definition of a key. To display thecorrect value, you must define a path from the key to the field. If you donot, the default value for the attribute is displayed.

PARENTThe parent field to which the field belongs.

PRECISIONSpecifies the maximum number of displayable digits allowed for datastored in fields whose TYPE is D (decimal), N (numeric), G (graphic), V(varchar), or W (vargraphic).

PROFILE-CODECA Dataquery security code. See the person responsible for CADataquery on your system for details.


Detail Report

REDEFINESN indicates no redefines. P indicates the field redefines the previous fieldat the same level. S indicates the field redefines the same field as theprevious field at the same level. C indicates the field is a child of a parentthat redefines another field.

REPEATNumber of times the field is repeated. In COBOL, this is the number oftimes the field OCCURS.

REQUIREDIndicates whether data is required in this field when a record is added. Yindicates yes, N indicates no. (Documentation only)

SEMANTIC-MASKReserved for future use.

SEMANTIC-TYPEFurther defines the data in the field. For SQL processing, entry isSQL-DATE, SQL-TIME, or SQL-STMP. For CA Dataquery and CA Ideal,entry is CA-DATE.

Another valid value is BIT-DATA. This value is used when you use a'FOR BIT DATA' clause in an SQL column definition. It can also be usedwhen you define fields in Datadictionary and is valid only with the datatypes C and V.

SHORT-ATTR-NAMELists the short attribute name for the FIELD occurrence. Datadictionaryuses this name on online panels and in batch reports. If you leave thisparameter blank, Datadictionary uses the first 15 characters of theoccurrence name.

SIGNY (yes) indicates a signed numeric field, N (no) indicates the field is notsigned.

SIGNIFICANT-CHGDatadictionary uses this attribute to notify that a change has been madeto a field such as length, displacement, data type, or sign. Y indicatesyes, N indicates no.

SQLNAMEThe SQL name of the field.

STORAGEPL/1 storage option, such as: A for auto, S for static, C for controlled,and B for based.

TYPEField type. Such as: C for character, N for zoned decimal, B for binary, Dfor packed decimal, and Y for double-byte character set. For moreinformation, and a description of the field types available, see “4012FIELD Transaction” on page 335.


Detail Report

TYPE-NUMERICType of sign convention being used for a numeric field. These are: C forconventional, P for conventional but always positive, Q for unconventionalbut always positive, and U for unconventional.

UNCHANGEABLEDeclares the field unchangeable after it has been added. Is onlyapplicable if DBEDITS=Y. Specify N if you specify FORCEUPD=Y. Yindicates yes, N indicates no.

VALUELiteral value for a value (qualifier) field.

VARYINGIndicates if this is a field which contains variable data. Y indicates yes, Nindicates no.

FILE Detail Report

This report lists the attribute-types and current attribute-values for the FILEoccurrence.

ACCESS-MTHDThe access method used with the file.

ANCHOR-POINTSReserved for use by CA.

BLOCK-SIZEMaximum block size for the file.

CI-INSERTReserved for use by CA.

CI-ROOTReserved for use by CA.

DATA-BASE-NAMEReserved for use by CA.

DATA-SET-NAMEFile's physical data set name.

DBMS-USEDDatabase Management System used, such as: IBM/DB2, IBM/IMS,TOTAL, and NONE.

DD2-NAMEReserved for use by CA.

DEVICEDevice type on which the file resides, such as: FBA, MDISK, PRT,PUNCH, READER, TAPE, 2311, 2314, 3340, 3350, 3370, 3380, 3390, or9345. processing. Y indicates yes, N indicates no.


Detail Report


FREE-SPACEReserved for use by CA.

LABELIndicates whether standard labels are used. Y indicates yes, N indicatesno.

MAX-BLCK-SIZEReserved for use by CA.

MAX-RECK-SIZEReserved for use by CA.

MAX-RECORD-SIZEMaximum size for the file's records.

MONITOR-NAMEJCL data definition name if on z/OS, or the D-Label name if on z/VSE.

RANDOM-NAMEReserved for use by CA.

REC-TYP-NAMEIf the file contains multiple record types, this attribute contains theDatadictionary name of the field in the record that distinguishes onerecord type from another. (Documentation only)

RECORD-FORMATIdentifies the record format.

■ FBLK indicates fixed, blocked■ FUNB indicates fixed, unblocked■ VBLK indicates variable, blocked■ VUNB indicates variable, unblocked■ UNDF indicates undefined

RPSIndicates whether the Rotational Position Sensing (RPS) feature of theDASD device where the file resides is available or used. Y (yes) indicatesit is available or is used, N (no) indicates it is not.

SCANReserved for use by CA.

SKIP-NTHReserved for use by CA.

SLACKNumber of bytes to be reserved in each block of the file for expansion.


Detail Report

SYSINReserved for use by CA.

SYSOUTReserved for use by CA.

JOB Detail Report

This report lists the attribute-types and current attribute-values for the JOBoccurrence.

ACCOUNTING-INFOAccounting information applicable to the job.

CLASSJob class.

IDENTJob identification.

MSGCLASSJob message class.

MSGLEVELMessage level.

OP-SYSOperating system used.

PRIORITYJob priority.

REGION-SIZENumber of 1024-byte blocks of main memory to be allocated for the job.

RUN-TIMEJob runtime.

KEY Detail Report

This report lists the attribute-types and current attribute-values for the KEYoccurrence.

AGR-SQLNAMESQL name of the table to which this key was defined.

AUTHIDFor SQL processing, authorization identifier of the table to which this keywas defined.

DATACOM-IDKey's CA Datacom/DB numeric ID.

DATACOM-NAMECA Datacom/DB name for the key.


Detail Report

DIRECTIndicates that CA Datacom/DB can use the key for direct relative recordaccess. Y indicates yes, N indicates no.


FOREIGNIndicates if the key is a foreign key. See the CA Datacom/DB SQL UserGuide for details on foreign keys. Y indicates yes, N indicates no.

INCLUDE-NIL-KEYIndicates if keys with blanks or binary zeros are to be included in the CADatacom/DB index. Y indicates yes, N indicates no.

KEY-ASM-NAMEKey's Assembler name.

KEY-CMP-NAMEKey's Compiler name.

KEY-FIELD-LENGTHIdentifies the length of the column used in the key used for partitioning ofa table. This attribute is only valid for columns of type C (character). Itspecifies the number of characters to be used in defining the key,beginning with the first character of the column. For all other types, theentire column must be used in the key definition.

KEY-INDEX-NAMEIdentifies the index dataset into which the values for the named key are tobe stored.

KEY-TYPEIdentifies whether the key is an index (I) or a partitioning (P) key.

LENGTHThe length of the key in bytes (internally maintained during FIELDmaintenance).

The sum of the lengths of the fields, plus one byte for each field definedwith NULL-INDICATOR=Y.

This does not include the two-byte field that defines the data's length forfields defined with a data type of V (VARCHAR). Therefore, this valuewill not match the sum of the fields length. For more information, see theCA Datacom/DB Database and System Administration Guide.

MASTER-KEYIndicates whether this is a Master Key. Y (yes) indicates yes, N (no)indicates no.

MAX-KEY-LENGTHThe maximum length of this key in the record or table.


Detail Report

NATIVE-KEYIndicates whether this is a Native Key. Y indicates yes, N indicates no.

SQLNAMEThe SQL name of the key.

UNIQUEIndicates whether the value of the key must be unique within the table towhich it is defined. Y indicates yes, N indicates no.

Note: If this attribute-value is Y, then the INCLUDE-NIL-KEYattribute-value must be Y and the field or fields defined to the key cannothave a NULL-INDICATOR attribute-value of Y.

LIBRARY Detail Report

This report lists the attribute-types and current attribute-values for the LIBRARYoccurrence.

ARCHIE-LEVELSNumber of levels of archiving allowed for a CA Librarian Master file.

BACKUP-EXECSAutomatic backup interval for a CA Librarian Master file.

COMPRESSIONCompression option for a CA Librarian Master file.

DEFAULT-EXECDefault execute option for a CA Librarian Master file.

DEFAULT-LISTDefault list option for a CA Librarian Master file.

DEFAULT-SEQDefault sequence option for a CA Librarian Master file.

DISK-BACKUP-OPTVolume serial number for disk backup facility of a CA Librarian Master file.

GROUP-PROCESSDefault group processing option for a CA Librarian Master file.

INVOKE-VARDefault source-load audit trail option for a CA Librarian Master file.

LIBRARY-TYPEType of library used: CA Librarian, CA Vollie, CA Roscoe IE, SSL, orPDS.

NAME-LNGMaximum length of the name of a member in a library.

NEW-SEQ-NUMBERSDefault resequence option for a CA Librarian Master file.


Detail Report

NUMBER-DIR-BLKNumber of directory blocks for a system library.

PAGE-CHANGE-OPTDefault page separator option for a CA Librarian Master file.

PASSWORD-OPTIONPassword option for a CA Librarian Master file.

PUNCH-OPTIONDefault punch option for a CA Librarian Master file.

UPDATE-PRINT-OPDefault update print option for a CA Librarian Master file.

MEMBER Detail Report

This report lists the attribute-types and current attribute-values for the MEMBERoccurrence.

DATE-MODIFIEDDate the member was last modified.

DATE-PRECOMPILEDate the member was last precompiled.

DATE-WRITTENDate the member was written.

LIBRARIAN-NAMEName of the library used.

MEMBER-IDName as stored in a library.

MEMBER-LANGLanguage of the member.

MEMBER-TYPEType of member.

NUMBER-CHANGESNumber of times the member has been changed.

NUMBER-COMPILESNumber of times the member has been compiled.

NUMBER-RUNSNumber of times the member has been executed.

OPERAT-SYSTEMOperating system in which the member executes.

PROD-DATESDate the member was last run in PRODuction status.


Detail Report

PROD-TIMETime the member was last run in PRODuction status.

PRODUCT-IDThe product identifier of the product to which the member belongs.

TEST-DATEDate the member was last run in TEST status.

TEST-TIMETime the member was last run in TEST status.

MODULE Detail Report

This report lists the attribute-types and the current attribute-values for theMODULE occurrence.

COMPILED-DATEDate the program was last compiled.

COMPILED-TIMETime the program was last compiled.

DATE-MODIFIEDLast modification date.

DATE-PRECOMPPrecompiled date.

DATE-WRITTENDate the module was written.

IDEAL-RESERVEDReserved for CA Ideal use.

IDENTName stored on the Source Statement Library.

LANGUAGELanguage used.

NUMBER-CHANGESNumber of times the module has been changed.

NUMBER-COMPILESNumber of times the module has been compiled.

NUMBER-RUNSNumber of times the module has been run.

OP-SYSOperating system used.

PRODUCT-IDIdentifier of the product to which the module belongs.

TYPE-MODULEClassification which further identifies the module.


Detail Report

NODE Detail Report

This report lists the attribute-types and the current attribute-values for theNODE occurrence.

DD-BASE-IDThe 5-digit DATACOM-ID of the Datadictionary database for the NODE.

LOCATIONNode's physical location. (Documentation only)

PANEL Detail Report

This report lists the attribute-types and the current attribute-values for thePANEL occurrence.

COMPILED-DATEDate the panel was last compiled.

COMPILED-TIMETime the panel was last compiled.


IMPORTED-DATEDate the panel was imported to this system.

IMPORTED-TIMETime the panel was imported to this system.

MEMBER-NAMEMember name of the panel in a library.

MODIFIED-DATEDate the panel was last modified.

MODIFIED-TIMETime the panel was last modified.

NUMBER-CHANGESNumber of changes to the panel.

NUMBER-COMPILESNumber of times the panel has been compiled.

PANEL-IDPanel ID.

PREFIX-PANELPanel ID of the prefix panel.

PRODUCT-IDProduct identifier of the product to which the panel belongs.


Detail Report

RESOURCE-DATEDate the panel was last resourced.

RESOURCE-TIMETime the panel was last resourced.

RUN-STATUSLoad status of the program at runtime:

■ R indicates resident■ S indicates shared■ N indicates nonshared■ C indicates conversational

SHORT-TITLEShort title for the panel.

WRITE-CONTROLWrite control indicator.

PARAMETER-LIST Detail Report

This report lists the attribute-types and the current attribute-values for thePARAMETER-LIST occurrence. Some attributes are specifically for use in theSQL Mode. See the CA Datacom/DB SQL User Guide for information on SQLprocessing.

AUTHIDAuthorization identifier (schema) of the view.

CREATORContains the user-ID of the person that created this view (internallymaintained).

The default is UNKNOWNPARMOWNER.

ENABLEN/A

FILENAMEN/A

FIPSIndicates if the view is valid in FIPS processing (internally maintained).

Y indicates yes, N indicates no, and S indicates no because of syntax.

SQL-ACCESSN/A

SQLNAMEThe SQL name of the view.


Detail Report

PARTITION-COLUMN-VALUE Detail Report

This report lists the attribute-types and the current attribute-values for thePARTITION-COLUMN-VALUE (PCV) occurrence.

HIGH-RANGE-SIGNIf the data type of the column is numeric, this attribute contains the sign ofthe data contained in the HIGH-RANGE-VALUE attribute. This attribute isonly valid for numeric columns. The valid values are "+", "-", and "N" (forNo sign). This attribute is defined on the initial addition of theentity-occurrence.

HIGH-RANGE-VALUEContains, in character format, the highest value for the defined columnthat is allowed in the specified partition. If the column is of a numericdata type, leading zeros must be defined. For example, if the column'sdata type is SMALLINT and the highest value for that column in thepartition is "5", then the value of the data portion of this attribute is"00005" and the length portion of the attribute is x'05'. This attribute isdefined on the initial addition of the entity-occurrence.

HIGH-RANGE-VALUE- LENGTHThe actual length of the data in HIGH-RANGE-VALUE. This attribute isdefined on the initial addition of the entity-occurrence.

PARTITION-VALUE Detail Report

This report lists the attribute-types and the current attribute-values for thePARTITION-VALUE occurrence.

COMPILE-DATEDate the occurrence was compiled by the CA Datacom STAR DMUTLTYutility.

COMPILE-TIMETime the occurrence was compiled by the CA Datacom STAR DMUTLTYutility.

COMPILE-VERSIONVersion number assigned by the CA Datacom STAR DMUTLTY utility.

LOWER-BOUNDS-1Value to form a conditional expression for the lower range to partition atable in a partitioned database.

LOWER-BOUNDS-2Value concatenated to LOWER-BOUNDS-1 to form the conditionalexpression.



Detail Report



LOWER-VALUE-LENTotal length of the LOWER-BOUNDS attribute-values (supplied by the CADatacom STAR DMUTLTY utility).

UPPER-BOUNDS-1Value to form a conditional expression for the higher range to partition atable in a partitioned database.

UPPER-BOUNDS-2Value concatenated to UPPER-BOUNDS-1 to form the conditionalexpression.




UPPER-VALUE-LENTotal length of the UPPER-BOUNDS attribute-values (supplied by the CADatacom STAR DMUTLTY utility).

PERSON Detail Report

This report lists the attribute-types and the current attribute-values for thePERSON occurrence.

EMPLOYEE-IDENTEmployee identification code.

JOB-GRADEEmployee's job grade.

JOB-TITLEEmployee's job title.

LANGUAGEThe person's language:

ARABIC DANISH DUTCH


Detail Report

ENGLISH FINNISH FRENCH GERMAN GERMAN2 ITALIAN JAPANESE KOREAN NORWEGIAN PORTUGUESE SPANISH SWEDISH

LANGUAGE-CODECode for the person's language:

1 (English) 2 (German) 3 (German2) 4 (Finnish) 5 (French) 6 (Dutch) 7 (Spanish) 8 (Italian) 9 (Danish) A (Swedish) B (Arabic) C (Japanese) D (Korean) E (Portuguese) F (Norwegian)

NAMEPerson's full name.

ORGANIZATIONOrganization, department, or section with which the person is associated.

PASS-WORDUser's password for access to CA product facilities.

This attribute is only displayed if the override code is provided. See theperson responsible for security administration on your system forinformation.

PRODUCT-IDThe product identifier of the product that added the person to the system.

USERIDSignon for Datadictionary.

See the person responsible for security administration on your system forinformation.


Detail Report

PLAN Detail Report

This report lists the attribute-types and the current attribute-values for the PLANoccurrence. See the CA Datacom/DB SQL User Guide for information on plansand SQL processing.

AUTHIDAuthorization identifier of the plan.

DATEFORMIdentifies the format of the date the plan was precompiled.

DECPOINTOptions for decimal points in SQL statements for a plan.

C indicates commas, P indicates periods.

JOIN-OVERRIDEIdentifies the join optimization sequence.

M indicates that the tables are to be joined as they are listed in the fromclause which results in a nested loop join. P indicates normal joinoptimization.

MESSAGEIdentifies the message type.

PLN-CBSIOLists the I/O limit interrupt for all SQL commands.

This option allows application environments to establish their ownmaximums in I/O and set processing relative to their own requirements. Avalue of 0 means no limit. The PLN-CBSIO attribute-value is divided by 8and stored internally as a binary halfword. The display is the valueentered divided by 8.

PLN-CLOSEIndicates when the plan and the User Requirements Table are closed:

■ R indicates that the plan and the User Requirements Table closewhen the run unit ends. The R option is recommended for batchprograms.

■ T indicates that the plan and the User Requirements Table close whenthe transaction ends. The T option is recommended for a CICSenvironment.

PLN-COMPATLists the mode in which to process the program:

■ ANSI indicates that the program will run in ANSI mode.

■ DATACOM indicates that the program will run in extended mode.

■ FIPS indicates that the program will run in FIPS mode.


Detail Report

■ DB2 indicates that CA Datacom/DB treat the plan as having DB2syntax and internal constructs. For use with CA-DB2:Transparencyand CA Ideal for DB2.

PLN-ISOLATIONLists the isolation level:

■ U indicates that no locks are acquired for rows accessed for read-onlypurposes.

■ C (for cursor stability) indicates that a unit of work holds locks only onits uncommitted changes and the current row of its cursors.

■ R indicates a repeatable read.

PLN-MINLists the exclusive control wait time limit in minutes.

This option allows a program to either wait or not wait for an explicitamount of time when another job is holding a requested record underexclusive control.

PLN-PRTYLists the priority of the SQL requests from the plan.

The lowest priority is 1, while 15 is the highest priority.

PLN-SECLists the exclusive control wait time limit in seconds.

This option allows a program to either wait or not wait for an explicitamount of time when another job is holding a requested record underexclusive control.

PLN-VALIDIndicates whether the plan is valid.

Y indicates yes, N indicates no.

PROGRAMIdentifies the program used that resulted in this plan.

SQLNAMEThe SQL name of the plan.

STRINGDELIMSpecifies the delimiters for literals.

A indicates apostrophes, Q indicates quotation marks.

TIMEFORMIdentifies the format of the time the plan was precompiled.

WORKSPACELists the length of the workspace during plan execution.


Detail Report

PROCEDURE Detail Report

This report lists the attribute-types and the current attribute-values for thePROCEDURE occurrence. See the CA Datacom/DB SQL User Guide forinformation on procedures and SQL processing.

AUTHIDAuthorization identifier of the procedure.

CHECK-TIMESTAMPIndicates to the SQL processor either to check that the associatedexternal module has not been modified since the procedure was created(Y) or not to make such a check (N).


The default is UNKNOWNPROCOWNER.

DETERMINISTICIndicates whether a procedure always provides the same results, giventhe same data (Y), or if a procedure can provide different results due tofactors other than the data (N).

EXTERNALIf the procedure causes an external module to be executed, this attributeis set to Y. Otherwise, if the procedure directly executes SQL statements,this attribute is set to N.

FIPSIndicates if the procedure is valid in FIPS processing (internallymaintained).


LANGUAGEThe language of the procedure.

PARM-LIST-STYLESpecifies the style of parameter list to be passed when defining an SQLprocedure.

PRC-VALIDWhen a change is made to a program referenced by a procedure, thisattribute is set to N. Otherwise, it is set to Y.

REENTRANTIndicates if the procedure code is reentrant (Y) or not reentrant (N).

RELEASE-CREATEDIndicates the version of SQL that was in effect when the procedure wascreated. For example, RELEASE-CREATED is 1000 for Version 10.0.


Detail Report

SQLNAMEThe SQL name of the procedure.

SQL-ACCESSIndicates whether the table associated with this procedure is accessibleduring SQL processing (internally maintained when the table is cataloged).Y indicates yes, R indicates SQL read-only, N indicates no.

SQL-CATAL-DATEThe date (mm/dd/yy) when the procedure was cataloged as part of thesuccessful SQL CREATE PROCEDURE execution.

SQL-CATAL-TIMEThe time (hhmmss) when the procedure was cataloged as part of thesuccessful SQL CREATE PROCEDURE execution.

SQL-TIMESTAMPDetects when a program referenced by a procedure has been modified. Itis cross-referenced to the date stored in the PROGRAM entity-type by theSQL preprocessor.

SVC-PCK-CREATEDIndicates the CA Service Pack of SQL that was in effect when theprocedure was created. For example, SVC-PCK-CREATED would be 01for Service Pack 1.

PROGRAM Detail Report

This report lists the attribute-types and the current attribute-values for thePROGRAM occurrence.

ACTUAL-DATEActual compilation date of the program.

APPLICATIONApplication to which this program belongs.

COMPILED-DATEDate the program was last compiled.

COMPILED-TIMETime the program was last compiled.

DATA-COMP-DATEDate the dataview for this program was last compiled.

DATA-COMP-TIMETime the dataview for this program was last compiled.

DATA-DATEDate the local data was entered.

DATA-MDFD-DATEDate the local data was last modified.


Detail Report

DATA-MDFD-TIMETime the local data was last modified.

DATA-TIMETime the local data was entered.

DATE-MODIFIEDDate the program was last modified.

DATE-PRECOMPDate the program was last precompiled.

DATE-WRITTENDate the program was written.


IDENTName assigned in the Source Statement Library.

IMPORTED-DATEDate the program was imported to this system.

IMPORTED-TIMETime the program was imported to this system.

LANGUAGELanguage used in the program.

MEMBER-NAMEMember name of the program in a library.

MODIFIED-DATEDate the program was last modified.

MODIFIED-TIMETime the program was last modified.

NUMBER-CHANGESNumber of times the program has been changed.

NUMBER-COMPILESNumber of times the program has been compiled.

NUMBER-RUNSNumber of times the program has been run.

OP-SYSOperating system used by the program.

PARM-COMP-DATEDate the parameters were last compiled.

PARM-COMP-TIMETime the parameters were last compiled.


Detail Report

PARM-MDFD-DATEDate the parameters were last modified.

PARM-MDFD-TIMETime the parameters were last modified.

PRODUCT-IDProduct identifier of the product to which the program belongs.

PROGRAM-NUMBERProgram identification number.

REFRESHUsed only in non-CA Ideal programs called from CA Ideal in batch.

If REFRESH is Y, a new copy of the subprogram is loaded on each call.If REFRESH is N, the same copy of the program is called each time.

RESOURCE-DATEDate the program was last resourced.

RESOURCE-TIMETime the program was last resourced.

RUN-STATUSLoad status of the program at runtime:

■ C indicates conversational■ N indicates nonshared■ R indicates resident■ S indicates shared

TARGET-DATETarget date for completion of the program.

TYPE-PROGRAMProgram classification.

UPDATE-DBIndicates whether the program updates CA Datacom/DB.


UPDATE-DB2Indicates whether the program updates IBM/DB2 (DB2 is an abbreviationfor IBM Database 2).


RECORD Detail Report

This report lists the attribute-types and the current attribute-values for theRECORD occurrence.

COMPRESS-RTNReserved for use by CA.


Detail Report


FILENAMEOccurrence name of the file that contains this record.

INIT-PARMReserved for use by CA.

LENGTHThe length, in bytes, of the record (internally maintained during FIELDmaintenance).

For example, the sum of the lengths of the fields.

SEGMENT-NMReserved for use by CA.

TYPEType of record.

For files containing multiple record types, this attribute is used to specifywhich type of record is defined by the current entity-occurrence beingreported. (For documentation purposes only.)

REPORT Detail Report

This report lists the attribute-types and the current attribute-values for theREPORT occurrence.

APPLICATIONApplication that produces the report.

CARR-CNTLType of carriage control used.

COMPILED-DATEDate the report was last compiled.

COMPILED-TIMETime the report was last compiled.

DATE-WRITTENDate the report was written.

FORM-NBRForm number used to print the report.

IDENTReport identification.

IMPORTED-DATEDate the report was imported to this system.


Detail Report

IMPORTED-TIMETime the report was imported to this system.

MEMBER-NAMEThe member name of the report in a library.

MODIFIED-DATEDate the report was last modified.

MODIFIED-TIMETime the report was last modified.

NBR-COPIESNumber of copies to be made.

NUMBER-CHANGESNumber of times the report has been changed.

NUMBER-COMPILESNumber of times the report has been compiled.

NUMBER-RUNSNumber of times the report has been run.

PRODUCT-IDProduct identifier of the product to which the report belongs.

REPORT-IDIdentifier of the report.

RESOURCE-DATEDate the report was last resourced.

RESOURCE-TIMETime the report was last resourced.

STATEMENT Detail Report

This report lists the attribute-types and the current attribute-values for theSTATEMENT occurrence. For information about plans, statements and SQLprocessing, see the CA Datacom/DB SQL User Guide.

AUTHIDAuthorization identifier of the plan that contains this statement.

FIPSIndicates if the statement is valid in FIPS processing.

Y indicates yes, N indicates no and S indicates no because of syntax.

PLANNAMESQL name of the plan that contains this statement.

STATEMENT-IDIdentification number for this statement.


Detail Report

STM-VALIDIndicates whether the statement is valid.


STEP Detail Report

This report lists the attribute-types and the current attribute-values for the STEPoccurrence.

ACCOUNTING-INFOAccounting information applicable to the step.

DISP-PRIORThe step's dispatching priority.

IDENTStep identification.

REGION-SIZENumber of 1024-byte blocks of main memory to be allocated for the step.

RUN-TIMEStep's runtime in the format (mmmsss).

SYNONYM Detail Report

This report lists the attribute-types and the current attribute-values for theSYNONYM occurrence. For information about synonyms and SQL processing,see the CA Datacom/DB SQL User Guide.

AUTHIDAuthorization identifier of the synonym.

CREATORContains the user-ID of the person that created this synonym (internallymaintained).

The default is UNKNOWNSYNOWNER.

ENABLEIndicates that the table was cataloged and was in synch when thesynonym was created.

FILENAMEN/A

LENGTHN/A

SQLNAMEThe SQL name of the synonym.

SQL-ACCESSIndicates whether the table associated with this synonym is accessibleduring SQL processing (internally maintained when the table is cataloged).


Detail Report

SQL-SECURITYIndicates if the database containing the table or view can be secured bySQL rules (internally maintained).

Y indicates SQL security of GRANT and REVOKE will be used. Nindicates CA Datacom/DB Security Facility rules will be used.

SYSTEM Detail Report

This report lists the attribute-types and the current attribute-values for theSYSTEM occurrence.

APPLICATIONSystem application.

DATE-DESIGNDesign date.

DATE-IMPLEMImplementation date.

PRODUCT-IDIdentifier of the product to which the system belongs.

RELEASEThe version level of the system.

SHORT-SYSTEM-IDShort identifier for the system.

SYSTEM-TYPEType of system.

SYSTEM-USERName of the end user, such as ENGINEERING, PERSONNEL, and soforth.

TABLE Detail Report

This report lists the attribute-types and the current attribute-values for theTABLE occurrence. Some attributes are specifically for use in the SQL Mode.For more information about SQL processing, see the CA Datacom/DB SQLUser Guide.

ANY-PARTITION-AUTHIDIdentifies the authorization identifier (schema) of the partitioned table youwant accessible to SQL processing when all partitions of the table maynot be available at the time.

ANY-PARTITION- DATACOM-NAMEIdentifies the DATACOM-NAME of the partitioned table you wantaccessible to record-at-a-time or set-at-a-time processing when allpartitions of the table may not be available at the time.


Detail Report

ANY-PARTITION-SQLNAMEIdentifies the SQL name of the partitioned table you want accessible toSQL processing when all partitions of the table may not be available atthe time.

AUTHIDAuthorization identifier (schema) of the table.

BASE-NAMEDatadictionary entity-occurrence name of the DATABASE occurrencerelated to the table (internally maintained during the SET or CATALOGfunction).

BASE-VERVersion number of the related database (internally maintained during theSET or CATALOG function).

CHNG-MASTER-KEYIndicates that the value of the Master Key can be modified.


CLUSTER-KEY-IDThe CA Datacom/DB Key identification to be used for the Cluster Key ifclustering is requested.

CLUSTER-KEY-LENLists the number of high-order bytes of the Native Key to be used as theCluster Key.

CNS-DOMAINIndicates if at least one column in the table has a constraint (internallymaintained).

For more information, see CA Datacom/DB SQL User Guide. Y indicatesyes, N indicates no.

CNS-REFERENCEDIndicates that the table contains a unique key which is the foreign key ofsome other table (internally maintained).


CNS-REFERSIndicates that the table contains a foreign key (internally maintained).


CNS-SAME-BASEIndicates that the constraint references are within the same databaserelated to this table (internally maintained).



Detail Report

CNS-UNIQUEIndicates if the table contains a unique key (internally maintained).


COMPRESS-EXITName of the compression routine exit.

COMPRESS-RTNReserved for use by CA.

COMPRESSIONIndicates whether compression is used for the table.


CONSTRAINTIndicates that the table contains at least one column (field) or key that isconstrained (internally maintained).


DATABASE-IDDATACOM-ID attribute of the database that contains the table.

DATACOM-IDDATACOM-ID attribute for the table.

DATACOM-NAMECA Datacom/DB name for the table.

DB-MASTER-KEYDATACOM-NAME attribute-value of the Master Key for the table(internally maintained during the SET or CATALOG function).

DB-NATIVE-KEYDATACOM-NAME attribute-value of the Native Key for the table (internallymaintained during the SET or CATALOG function).

DBMS-USEDDatabase Management System used, such as: DATACOM or IBM/DB2.

DD-ENTITY-TABLEIndicates if the table defines an entity-type in the DATA-DICT database.

DD-MASTER-KEYDatadictionary occurrence name of the Master Key for the table (internallymaintained during the SET or CATALOG function).

DD-NATIVE-KEYDatadictionary occurrence name of the Native Key for the table (internallymaintained during the SET or CATALOG function).

DDD-SYNCHIndicates if the table definition is consistent with the definition in the DataDefinition Directory (internally maintained).


Detail Report


DL1T-CONSTRAINTIndicates if the table is eligible for CA Datacom DL1 Transparencyintegrity processing (internally maintained during the SET or CATALOGfunction).


DUPE-MASTER-KEYIndicates whether the value of the Master Key is allowed to be duplicated.



ENCRYPTION-KEYThe 8-character user-assigned key used for the encryption (encoding) oftables.

ENTY-NAME-LENMaximum length of occurrence names within the entity-type.

ENTY-HIST-VERSMaximum number of HISTory status versions of an occurrence that canexist simultaneously in Datadictionary.

FALLBACKReserved for use by CA.

FIPSIndicates if the table is valid in FIPS processing.

Y indicates yes, N indicates no and S indicates no because of syntax.

FILENAMERepeats the table occurrence name.

INIT-PARMReserved for use by CA.

LENGTHThe length of the table in bytes (internally maintained during FIELDmaintenance).

The sum of the lengths of the fields, plus one byte for each field definedwith NULL-INDICATOR=Y.

LOGGINGIndicates whether logging is used. Y indicates yes, N indicates no.

MAX-RECORD-SIZEMaximum size for the physical records of the table.


Detail Report

MONITOR-NMReserved for use by CA.

MOVE-ROW-TO-NEW-PARTITIONIndicates whether a row is to be moved to a new partion if the value ofone of the columns comprising the partitioning key is updated.

PARTITIONIndicates if the table is involved in partitioning (N means not involved) andwhether it is the partitioned table (Y), the partitioned table but withrestricted access, that is, no access to the individual partitions (R), or atable partition (P).

PIPELINE-OPTIONIndicates whether the Pipeline option of CA Datacom/DB will be in effectfor this table.


RECOVERYIndicates whether the Recovery facilities of CA Datacom/DB will be usedfor this table.


SEGMENT-NMReserved for use by CA.

SQL-ACCESSIndicates whether the table is accessible during SQL processing (internallymaintained when the table is cataloged).

Y indicates yes, R indicates SQL read-only, N indicates no.

SQL-CATAL-DATEDate the SQL accessible table was last cataloged (internally maintainedwhen the table is cataloged).

SQL-CATAL-TIMETime the SQL accessible table was last cataloged (internally maintainedwhen the table is cataloged).

SQL-INTENTIndicates that the table is intended for SQL processing.

Y indicates yes, R indicates SQL read-only, N indicates no.(SQL-ACCESS must be Y or R for the table to be accessible during SQLprocessing.)

SQLNAMESQL name of the table.

SQL-SECURITYIndicates if the database containing the table can be secured by SQLrules (internally maintained).


Detail Report

Y indicates SQL security of GRANT and REVOKE will be used. Nindicates CA Datacom/DB Security Facility rules will be used for the SQLobjects (TABLE, VIEW, SYNONYM, or FIELD (columns) occurrences) inthe DATABASE structure.

Note: You cannot base a view on tables from databases with differentSQL-SECURITY values. The attribute-value is enforced only whensecurity is enabled in the CA Datacom/DB Master List. For moreinformation about the CA Datacom/DB Security Facility and SQL security,see the CA Datacom Security Reference Guide.

TABLEKINDReserved for use by CA.

TRIGGER Detail Report

This report lists the attribute-types and the current attribute-values for theTRIGGER occurrence. For information about views and SQL processing, seethe CA Datacom/DB SQL User Guide.

ACTION-LEVELIndicates whether the trigger is to be invoked for each row (R) processedor for each SQL statement (S), when a trigger is created.

AFTER-DELETEWhen a trigger is created, you can specify when it should be invoked.These switches indicate these options. One or more of these switchesmust be set to Y for the trigger to be valid.

AFTER-INSERTWhen a trigger is created, you can specify when it should be invoked,based on the action taking place on the table. These switches indicatethese options. One or more of these switches must be set to Y for thetrigger to be valid.

AUTHIDAuthorization identifier (schema) of the trigger.

BEFORE-DELETEWhen a trigger is created, you can specify when it should be invoked,based on the action taking place on the table. These switches indicatethese options. One or more of these switches must be set to Y for thetrigger to be valid.

BEFORE-INSERTWhen a trigger is created, you can specify when it should be invoked,based on the action taking place on the table. These switches indicatethese options. One or more of these switches must be set to Y for thetrigger to be valid.

BEFORE-UPDATEWhen a trigger is created, you can specify when it should be invoked,based on the action taking place on the table. These switches indicate


Detail Report

these options. One or more of these switches must be set to Y for thetrigger to be valid.

CREATORIndicates the user-ID of the person that created this synonym.

FIPSIndicates if the trigger is valid in FIPS processing (internally maintained).


NEW-ROW-CORR-NAMESQL statements that refer to both the table or row images before andafter the changes have been made. These attributes allow you to specifyalternative names for the before and after images.

NEW-TABLE-ALIASSQL statements that refer to both the table or row images before andafter the changes have been made. These attributes allow you to specifyalternative names for the before and after images.

OLD-ROW-CORR-NAMESQL statements that refer to both the table or row images before andafter the changes have been made. These attributes allow you to specifyalternative names for the before and after images.

OLD-TABLE-ALIASSQL statements that refer to both the table or row images before andafter the changes have been made. These attributes allow you to specifyalternative names for the before and after images.

RELEASE-CREATEDIndicates the version that was in effect when the trigger was created. Forexample, RELEASE-CREATED would be 1000 for Version 10.0.

SQL-CATAL-DATEThe date (mm/dd/yy) when the trigger was cataloged as part of thesuccessful SQL CREATE PROCEDURE execution.

SQL-CATAL-TIMEThe time (hhmmss) when the trigger was cataloged as part of thesuccessful SQL CREATE PROCEDURE execution.

SQLNAMEThe SQLNAME of the trigger specified in the CREATE PROCEDUREstatement.

SQL-TIMESTAMPThe ANSI Standard specifies that triggers are to be invoked in the orderthey are created, with the oldest being invoked first. The SQL Timestampensures that triggers are invoked in that order.

SVC-PCK-CREATEDIndicates the CA Service Pack of SQL that was in effect when the triggerwas created. For example, SVC-PCK-CREATED would be 01 for ServicePack 1.


Detail Report

TRIGGER-VALIDWhen a change is made to a table referenced by a trigger and thatchange might affect the ability of the trigger to function correctly, thisattribute is set to N. Otherwise, it is set to Y. This attribute is also set toN if there is a recognized change to a procedure called by the trigger.

UPDATE-TRIGGERIndicates, in conjunction with the BEFORE-UPDATE and AFTER-UPDATEattributes, whether the trigger is invoked only when certain columns areupdated (EXPLICIT) or when any column in the table is updated(IMPLICIT).

VIEW Detail Report

This report lists the attribute-types and the current attribute-values for the VIEWoccurrence. See the CA Datacom/DB SQL User Guide for information on viewsand SQL processing.

AUTHIDAuthorization identifier (schema) of the view.


The default is UNKNOWNVIEWOWNER.

ENABLEN/A

FILENAMEN/A

FIPSIndicates if the view is valid in FIPS processing (internally maintained).


LENGTHThe length, in bytes, of the view (internally maintained).

For example, the sum of the lengths of the columns (FIELD occurrences)identified in the view definition.

SQL-ACCESSN/A

SQLNAMEThe SQL name of the view.

SQL-SECURITYIndicates if the database containing the table or view can be secured bySQL rules (internally maintained).

Y indicates SQL security of GRANT and REVOKE will be used. Nindicates CA Datacom/DB Security Facility rules will be used for the SQL


Detail Report

objects (TABLE, VIEW, SYNONYM, or FIELD (columns) occurrences) inthe DATABASE structure.

Note: You cannot base a view on tables from databases with differentSQL-SECURITY values. For more information about the CA Datacom/DBSecurity Facility and SQL security, see the CA Datacom SecurityReference Guide.

DETAIL Report - No Modifiers









-RPT DETAIL,ELEMENT,ACCT(T1) ;


Security Level: 1 Detail Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ENTITY-TYPE: ELEMENT DESC: ACCTS FULL TABLE ELEMENTNAME: ACCTS.ACCTS (T1)TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION:DATE-ADDED: 9/29/89 DATE-LAST-CHANGED: 5/21/9 TIME-OF-CHANGE: 15.3.42 NUMBER-OF-CHANGES: 8

ATTRIBUTE....................... ..................................(ATTRIBUTE VALUE)...................................

ENABLE NASM-NAME ACCTRECCOMPL-NAME ACCTSDATACOM-NAME ACTFLSECURITY-CODE LENGTH 31DISP-IN-TABLE FIRST-FIELD ORD-IDLAST-FIELD CUST-NOSYNCH-CODE

END OF JOB


Detail Report









-RPT DETAIL,DATABASE,ORDER-ENTRY(T1),A,D,T ;-END ;



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: DATABASE DESC: ORDER-ENTRY DEMO DATABASENAME: ORDER-ENTRY (T1)TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION:DATE-ADDED: 3/1/9 DATE-LAST-CHANGED: 3/1/9 TIME-OF-CHANGE: 17.5.11 NUMBER-OF-CHANGES: 8


ENABLE NDATACOM-ID 1BASE-TYPE RELATIONCATALOGED-DATECATALOGED-TIMEDBMS-USED DATACOMDDD-BASE-ID DL1T-CONSTRAINT NSQLNAMESQL-SECURITY NDYNAMIC-EXTEND DESCRIPTORSORDER-ENTRY .... ALIAS .... .... ALIAS .... .... ALIAS .... ORDER-ENTRY-DATABASE ..................................... TEXT CLASS-STANDARD OWNED LINE NO .

The Application Demonstration System is a generic representation 1 of a customer order-entry system as it may appear in the business 2 world. 3

The overall system is designed modularly so that it may be enhanced 4 without adversely affecting the basic design of the system. Modularity 5 allows the system to be expanded or enhanced for demonstration purposes 6 or for the actual use of the system in a production environment. The 7 ORDER-ENTRY database consists of nine tables, each of which has 8 minimally a primary key. The database, as it is conceptualized, is 9 fully normalized. The actual physical database is a one-for-one 1 implementation of the conceptualized model. 11 ..................................... TEXT CLASS-STRUCTURE OWNED LINE NO .

The ORDER-ENTRY database consists of nine tables defined to eight 1 areas. The areas and tables are as follows: 2 3 Area Name Table Name 4


Detail Report



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: DATABASE DESC: ORDER-ENTRY DEMO DATABASENAME: ORDER-ENTRY (T1)TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION:DATE-ADDED: 3/1/9 DATE-LAST-CHANGED: 3/1/9 TIME-OF-CHANGE: 17.5.11 NUMBER-OF-CHANGES: 8


--------- ---------- 5 6 ACCTS ACCTS 7 CUST CUST 8 DETAIL DETAIL 9 ORDERS 1 ITEMS ITEMS 11 ORD-NO ORD-NO 12 RCPTS RCPTS 13 SHIPTO SHIPTO 14 SLSHST SLSHST 15

-------- E N D O F J O B -----------


Field Report

Field Report

The Field Report provides itemized information about FIELD occurrencesassociated with a TABLE, VIEW, RECORD, KEY, or ELEMENT occurrence.

Report Content

The report heading contains the following information, listed in left-to-right order.If the actual attribute names are different from the printed headings on thereport, they appear in parentheses.

ENTITY-TYPETABLE, VIEW, RECORD, KEY, or ELEMENT.

DESC (DESCRIPTION)Entity-occurrence description.

NAME (ENTITY-NAME)The occurrence name of the table, view, record, key, or element.

STATUSStatus of the occurrence.

AUTHORAuthor's ID.

SQLThe full SQL name (authid.sqlname) of the table. This line is only printedif the Field Report is for a TABLE occurrence and the SQLNAME attributeof the table is not empty.

CONTROLLERController ID.

COPY-VERSION (PREVIOUS-VERS)Number of the version that was copied to produce this version.

DATE-ADDEDDate the entity-occurrence was added.

DATE-LAST-CHANGED (DATE-LAST-CHG)Date the entity-occurrence was last updated.

TIME-OF-CHANGE (TIME-LAST-CHG)Time of day the entity-occurrence was changed.

If no updates have been processed, the time that the entity-occurrencewas added.

NUMBER-OF-CHANGES (COUNT)Number of times the entity-occurrence has been updated.


Field Report

The report body lists the following information:

LV (LEVEL)The two-digit field level number.

C (CLASS)Code representing the field class.

Codes for the valid classes are:

C Compound - or parent - field

F Filler field

I Fndex field

S Simple field

V Value - or qualifier - field

FIELD-NAMEDatadictionary occurrence name of the field.

PARENT-NAME (RECORD-NAME)Datadictionary occurrence name of the parent field.

Applies to compound fields only.

DISPL (DISP-IN-TABLE)Displacement of the field in the record or table.

LNGTH (LENGTH)Length of the field in bytes.

For fields defined with a V data type (VARCHAR), this value includes theautomatically generated two-byte field which defines the data's length.For more information, see the CA Datacom/DB Database and SystemAdministration Guide.

T (TYPE)Code representing the data type of the field.

Codes for the valid data types are:

B Binary field

C Character field

D Packed decimal field

E Extended-precision floating-point

G Graphics character set

H Hexadecimal with 2 characters per entry

K Kanji

L Long-precision floating-point

N Numeric field zoned decimal


Field Report

S Short-precision floating-point

T PL/I bit representation

V Variable length character

Y Pure DBCS Double-Byte Character Set

Z Mixed DBCS and EBCDIC

2 Halfword binary

4 Fullword binary

8 Doubleword binary

J (JUSTIFICATION)Justification.

L indicates left justified, R indicates right justified.

N (NULL-INDICATOR)Null indicator.

N indicates no null-indicator, a one-byte indicator preceding this field. Yindicates the null-indicator is present.

S (SIGN)Sign.

N indicates no sign, Y indicates signed.

DEC (DECIMALS)Decimal places for numeric, packed decimal, and binary fields.

RPFAC (REPEAT)Repetition factor.

VALUEValue attribute.

This is either the field's default value or the value associated with aqualifier (CLASS=V) field.

DESCRIPTIONFIELD entity-occurrence's description.

PRECISIONSpecifies the maximum number of displayable digits allowed for datastored in fields whose TYPE is D (decimal), N (numeric), G (graphic), V(varchar), or W (vargraphic).


Field Report

KEY and ELEMENT Field Reports

The KEY and ELEMENT Field Reports also list the following information:

LANGUAGE-COMMENT (LANG-COMNT)A 36-character comment for the FIELD occurrence.

ALC-NAME (ASM-NAME)Assembler name.

COMPILER-NAME (COMPL-NAME)FIELD entity-occurrence's alternate compiler name if different from theoccurrence name.

O (ORDER)Sequencing order.

Sequencing order within the key. A indicates ascending; D indicatesdescending.

DS (DATA-SENSITIVE)Indicates that the field is a signed, numeric field that CA-DATACOM/DBwill sort in numeric collation sequence. See the chapter on DesigningKeys in the CA-DATACOM/DB Database and System Administrator Guidefor more information.

Request Format

Use the following format for a Field Report request:

��──-RPT──FIELD────────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

When submitting with a path, use the following format for a Field Reportrequest:

Field Report When Submitting with a Path (Step 1)

��──-RPT──START────────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─


Field Report

Field Report When Submitting with a Path (Step 2)

��──-RPT──FIELD─ ──┬ ┬───────────────────────── ─────────────────────────�� └ ┘ ─,entity─ ──┬ ┬──────────── ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

For discussions of the parameters, see “Coding the Basic Report Request” onpage 412 and “Using Pathing in Reporting” on page 418.

Note: If the entity parameter is used, it must be coded TABLE, VIEW,RECORD, KEY, or ELEMENT.

FIELD Report - STANDARD Path




----------------------------------------------------------------------------------- CODE USER-NAME,PSWD,DATABASE-ID -USR DATACOM-INSTALL, ; PROC -----------------------------------------------------------------------------------




-RPT START,TABLE,ACCTS(PROD,),STANDARD ;-RPT FIELD,TABLE ;-RPT FIELD,KEY ;-RPT FIELD,ELEMENT ;-END ;


Field Report


Security Level: 1 Field Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ENTITY-TYPE: TABLE DESC: ORDER-ENTRY ACCTS TABLENAME: ACCTS (1)PRODSQL: SYSADM.ACCTSAUTHOR: DEMO-ADMIN CONTROLLER: DEMO-ADMIN COPY-VERSION: 1DATE-ADDED: 1/3/9 DATE-LAST-CHANGED: 6/2/91 TIME-OF-CHANGE: 17.34.32 NUMBER-OF-CHANGES: 21

LV C FIELD-NAME...................... PARENT-NAME..................... DISPL LNGTH T J N S DEC RPFAC VALUE.............DESCRIPTION......................... LANGUAGE-COMMENT................. PRECIALC-NAME COMPILER-NAME................. O DS

1 S ORD-ID 5 N R N N 1ACCTS ORD-ID FIELD 5

1 C BILL-DT 5 6 C L N N 1ACCTS BILL-DT FIELD

2 S BILL-YR BILL-DT 5 2 C L N N 1ACCTS BILL-YR FIELD 2

2 S BILL-MO BILL-DT 7 2 C L N N 1ACCTS BILL-MO FIELD 2

2 S BILL-DAY BILL-DT 9 2 C L N N 1ACCTS BILL-DAY FIELD 2

1 S ORD-AMT 11 5 D R N Y 2 1ACCTS ORD-AMT FIELD 9

1 S FRT-AMT 16 5 D R N Y 2 1ACCTS FRT-AMT FIELD 9

1 S DISC-AMT 21 5 D R N Y 2 1ACCTS DISC-AMT FIELD 9

1 C CUST-ID 26 5 C L N N 1ACCTS CUST-ID FIELD

2 S IND-CD CUST-ID 26 1 C L N N 1ACCTS IND-CD FIELD 1

2 S CUST-NO CUST-ID 27 4 C L N N 1ACCTS CUST-NO FIELD 4



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: KEY DESC: CUST-ID SECONDARY KEYNAME: ACCTS.CUST-ID-KEY (1)PRODAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION: 1DATE-ADDED: 1/3/9 DATE-LAST-CHANGED: 1/3/9 TIME-OF-CHANGE: 17.56.2 NUMBER-OF-CHANGES: 1



CUSTID ACT-CUST-ID-KEY A N2 S IND-CD CUST-ID 26 1 C L N N 1

ACCTS IND-CD FIELD INDCD ACT-IND-CD-KEY A N 12 S CUST-NO CUST-ID 27 4 C L N N 1

ACCTS CUST-NO FIELD CUSTNO ACT-CUST-NO-KEY A N 4


Field Report



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: KEY DESC: ORD-ID MASTER KEYNAME: ACCTS.ORD-ID-KEY (1)PRODAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION: 1DATE-ADDED: 1/3/9 DATE-LAST-CHANGED: 1/3/9 TIME-OF-CHANGE: 17.56.2 NUMBER-OF-CHANGES: 1



ORDID ACT-ORD-ID-KEY A N



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: ELEMENT DESC: ACCTS FULL TABLE ELEMENTNAME: ACCTS.ACCTS (1)PRODAUTHOR: DEMO-ADMIN CONTROLLER: DEMO-ADMIN COPY-VERSION: 1DATE-ADDED: 1/3/9 DATE-LAST-CHANGED: 6/2/91 TIME-OF-CHANGE: 17.34.33 NUMBER-OF-CHANGES: 8



ORDID ACT-ORD-ID1 C BILL-DT 5 6 C L N N 1

ACCTS BILL-DT FIELD BILLDT ACT-BILL-DT2 S BILL-YR BILL-DT 5 2 C L N N 1

ACCTS BILL-YR FIELD BILLYR ACT-BILL-YR 22 S BILL-MO BILL-DT 7 2 C L N N 1

ACCTS BILL-MO FIELD BILLMO ACT-BILL-MO 22 S BILL-DAY BILL-DT 9 2 C L N N 1

ACCTS BILL-DAY FIELD BILLDAY ACT-BILL-DAY 21 S ORD-AMT 11 5 D R N Y 2 1

ACCTS ORD-AMT FIELD ORDAMT ACT-ORD-AMT 91 S FRT-AMT 16 5 D R N Y 2 1

ACCTS FRT-AMT FIELD FRTAMT ACT-FRT-AMT 91 S DISC-AMT 21 5 D R N Y 2 1

ACCTS DISC-AMT FIELD DISCAMT ACT-DISC-AMT 91 C CUST-ID 26 5 C L N N 1

ACCTS CUST-ID FIELD CUSTID ACT-CUST-ID2 S IND-CD CUST-ID 26 1 C L N N 1

ACCTS IND-CD FIELD INDCD ACT-IND-CD 12 S CUST-NO CUST-ID 27 4 C L N N 1

ACCTS CUST-NO FIELD CUSTNO ACT-CUST-NO 4


Field Report



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: ELEMENT DESC: CUST-ID ELEMENTNAME: ACCTS.CUST-ID (1)PRODAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION: 1DATE-ADDED: 1/3/9 DATE-LAST-CHANGED: 6/2/91 TIME-OF-CHANGE: 17.34.33 NUMBER-OF-CHANGES: 4



CUSTID ACT-CUST-ID2 S IND-CD CUST-ID 26 1 C L N N 1

ACCTS IND-CD FIELD INDCD ACT-IND-CD 12 S CUST-NO CUST-ID 27 4 C L N N 1

ACCTS CUST-NO FIELD CUSTNO ACT-CUST-NO 4



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: ELEMENT DESC: ORD-ID ELEMENTNAME: ACCTS.ORD-ID (1)PRODAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION: 1DATE-ADDED: 1/3/9 DATE-LAST-CHANGED: 6/2/91 TIME-OF-CHANGE: 17.34.33 NUMBER-OF-CHANGES: 3



ORDID ACT-ORD-ID


Indented Report

Indented Report

The Indented Report uses sorting and indentations to show the logical structureof entity-occurrences. The report can be produced with or without headings,depending upon whether the optional ALIGN parameter is used.

When a path is specified in the request transaction, entity-occurrences arepresented in an indented format that reflects entity-occurrence relationships. Ifan SQL name exists for an occurrence, the SQL name is indented below thedescription line. When a path is not specified, the report is presentedalphabetically by entity-type and no indentations are produced.

Report Content

The report heading contains the following information, listed in left-to-right order.If the actual attribute names are different from the printed headings on thereport, they appear in parentheses.

ENTITY-TYPEEntity-type name.

OCCURRENCE (ENTITY-NAME)Entity-occurrence name.

S (STATUS)Status of the occurrence.

VER (ENTITY-VER)Version number.

DESCRIPTIONDescription you added.

SQLNAMEThe SQL name of the occurrence.

The following information is listed under the heading, DATACOM/DB.

NAME (DATACOM-NAME)DATACOM-NAME of the AREA, TABLE, KEY, or ELEMENTentity-occurrences.

ID (DATACOM-ID)CA Datacom/DB ID number for the DATABASE, TABLE, and KEYentity-occurrences.

USEFor KEY occurrences:

M Indicates the key is the Master Key.

N Indicates this key is the Native Key.


Indented Report

M and NIndicate this key is both the Master and Native Key.

D Indicates the key is used for direct relative record access.

For TABLE occurrences:

I Indicates that the SQL-INTENT attribute-value is coded Y or R.

A Indicates that SQL processing can access this table.

For PLAN occurrences:

V Indicates that the plan is valid.

Request Format

Use the following format for an Indented Report request:

��──-RPT──INDENT───────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ──┬ ┬──────── ───────────────────────────────────────────────�� └ ┘ ─,as-of-date─ └ ┘ ─,ALIGN─

When submitting with a path, use the following format for an Indented Reportrequest:

Indented Report When Submitting with a Path

��──-RPT──START────────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ─-RPT──INDENT─ ── ──┬ ┬───────────────────────── ──┬ ┬──────── ──�� └ ┘ ─,as-of-date─ └ ┘ ─,entity─ ──┬ ┬──────────── └ ┘ ─,ALIGN─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

For discussions of the parameters, see “Coding the Basic Report Request” onpage 412 and “Using Pathing in Reporting” on page 418

If the optional ALIGN parameter is omitted, the report produces page headings.If ALIGN is coded, the page headings, the three-digit DATACOM-IDattribute-values, and the five-character DATACOM-NAME attribute-values arenot produced.


Indented Report

INDENTED Report - No Path





-USR DATACOM-INSTALL, ; PROC -----------------------------------------------------------------------------------




-RPT INDENT,FIELD,ACCTS.ALL ;


Indented Report





FLD ACCTS.BILL-DAY H 1 SYSADM.BILL_DAYFLD ACCTS.BILL-DT H 1 SYSADM.BILL_DTFLD ACCTS.BILL-MO H 1 SYSADM.BILL_MOFLD ACCTS.BILL-YR H 1 SYSADM.BILL_YRFLD ACCTS.CUST-ID H 1 SYSADM.CUST_IDFLD ACCTS.CUST-NO H 1 SYSADM.CUST_NOFLD ACCTS.DISC-AMT H 1 SYSADM.DISC_AMTFLD ACCTS.FRT-AMT H 1 SYSADM.FRT_AMTFLD ACCTS.IND-CD H 1 SYSADM.IND_CDFLD ACCTS.ORD-AMT H 1 SYSADM.ORD_AMTFLD ACCTS.ORD-ID H 1 SYSADM.ORD_IDFLD ACCTS.BILL-DAY H 2 ACCTS SYSADM.BILL_DAYFLD ACCTS.BILL-DT H 2 ACCTS SYSADM.BILL_DTFLD ACCTS.BILL-MO H 2 ACCTS SYSADM.BILL_MOFLD ACCTS.BILL-YR H 2 ACCTS SYSADM.BILL_YRFLD ACCTS.CUST-ID H 2 ACCTS SYSADM.CUST_IDFLD ACCTS.CUST-NO H 2 ACCTS SYSADM.CUST_NOFLD ACCTS.DISC-AMT H 2 ACCTS SYSADM.DISC_AMTFLD ACCTS.FRT-AMT H 2 ACCTS SYSADM.FRT_AMTFLD ACCTS.IND-CD H 2 ACCTS SYSADM.IND_CDFLD ACCTS.ORD-AMT H 2 ACCTS SYSADM.ORD_AMTFLD ACCTS.ORD-ID H 2 ACCTS SYSADM.ORD_ID


Indented Report





FLD ACCTS.BILL-DAY P 3ACCTS BILL-DAY FIELD

SYSADM.BILL_DAYFLD ACCTS.BILL-DT P 3

ACCTS BILL-DT FIELD SYSADM.BILL_DTFLD ACCTS.BILL-MO P 3

ACCTS BILL-MO FIELD SYSADM.BILL_MOFLD ACCTS.BILL-YR P 3

ACCTS BILL-YR FIELD SYSADM.BILL_YRFLD ACCTS.CUST-ID P 3

ACCTS CUST-ID FIELD SYSADM.CUST_IDFLD ACCTS.CUST-NO P 3

ACCTS CUST-NO FIELD SYSADM.CUST_NOFLD ACCTS.DISC-AMT P 3

ACCTS DISC-AMT FIELD SYSADM.DISC_AMTFLD ACCTS.FRT-AMT P 3

ACCTS FRT-AMT FIELD SYSADM.FRT_AMTFLD ACCTS.IND-CD P 3

ACCTS IND-CD FIELD SYSADM.IND_CDFLD ACCTS.ORD-AMT P 3

ACCTS ORD-AMT FIELD SYSADM.ORD_AMTFLD ACCTS.ORD-ID P 3

ACCTS ORD-ID FIELD SYSADM.ORD_IDFLD ACCTS.BILL-DAY T T1

ACCTS BILL-DAY FIELD SYSADM.BILL_DAYFLD ACCTS.BILL-DT T T1

ACCTS BILL-DT FIELD SYSADM.BILL_DTFLD ACCTS.BILL-MO T T1

ACCTS BILL-MO FIELD SYSADM.BILL_MOFLD ACCTS.BILL-YR T T1

ACCTS BILL-YR FIELD SYSADM.BILL_YRFLD ACCTS.CUST-ID T T1

ACCTS CUST-ID FIELD SYSADM.CUST_IDFLD ACCTS.CUST-NO T T1

ACCTS CUST-NO FIELD SYSADM.CUST_NO


Indented Report






SYSADM.DISC_AMTFLD ACCTS.FRT-AMT T T1

ACCTS FRT-AMT FIELD SYSADM.FRT_AMTFLD ACCTS.IND-CD T T1

ACCTS IND-CD FIELD SYSADM.IND_CDFLD ACCTS.ORD-AMT T T1

ACCTS ORD-AMT FIELD SYSADM.ORD_AMTFLD ACCTS.ORD-ID T T1

ACCTS ORD-ID FIELD SYSADM.ORD_ID

END OF JOB

INDENTED Report - STANDARD Path





-USR DATACOM-INSTALL, ; PROC -----------------------------------------------------------------------------------








-RPT START,DATABASE,ORDER-ENTRY(PROD,),STANDARD ;-RPT INDENT ;-END ;


Indented Report





BAS ORDER-ENTRY P 1 1ORDER-ENTRY DEMO DATABASE

ARA ACCTS P 1 ACTORDER-ENTRY ACCTS AREA

ACCTSTBL ACCTS P 1 ACT 6

ORDER-ENTRY ACCTS TABLE SYSADM.ACCTS I A

KEY ACCTS.CUST-ID-KEY P 1 ACSTI 1CUST-ID SECONDARY KEY

SYSADM.ACSTI_1KEY ACCTS.ORD-ID-KEY P 1 ACTOR 4 M N

ORD-ID MASTER KEY SYSADM.ACTOR_1

ELM ACCTS.ACCTS P 1 ACTFLACCTS FULL TABLE ELEMENT

ELM ACCTS.CUST-ID P 1 ACTCS CUST-ID ELEMENT

ELM ACCTS.ORD-ID P 1 ACTOR ORD-ID ELEMENT FLD ACCTS.ORD-ID P 1

ACCTS ORD-ID FIELD SYSADM.ORD_ID FLD ACCTS.BILL-DT P 1

ACCTS BILL-DT FIELD SYSADM.BILL_DT FLD ACCTS.BILL-YR P 1

ACCTS BILL-YR FIELD SYSADM.BILL_YR FLD ACCTS.BILL-MO P 1

ACCTS BILL-MO FIELD SYSADM.BILL_MO FLD ACCTS.BILL-DAY P 1

ACCTS BILL-DAY FIELD SYSADM.BILL_DAY FLD ACCTS.ORD-AMT P 1

ACCTS ORD-AMT FIELD SYSADM.ORD_AMT FLD ACCTS.FRT-AMT P 1

ACCTS FRT-AMT FIELD SYSADM.FRT_AMT FLD ACCTS.DISC-AMT P 1

ACCTS DISC-AMT FIELD SYSADM.DISC_AMT


Indented Report





FLD ACCTS.CUST-ID P 1ACCTS CUST-ID FIELD

SYSADM.CUST_ID FLD ACCTS.IND-CD P 1

ACCTS IND-CD FIELD SYSADM.IND_CD FLD ACCTS.CUST-NO P 1

ACCTS CUST-NO FIELD SYSADM.CUST_NO

ARA CUST P 1 CUSORDER-ENTRY CUST AREA

CUSTTBL CUST P 1 CUS 1

ORDER-ENTRY CUST TABLE SYSADM.CUST I A

KEY CUST.CRED-IND-KEY P 1 CRED 3CRED-IND KEY (SECONDARY KEY - NULL)

SYSADM.CRED_1KEY CUST.CUST-ID-KEY P 1 CUSID 1 M N

CUST-ID KEY (MASTER KEY) SYSADM.CUSID_1

KEY CUST.CUST-IDNO-KEY P 1 IDNO 13IDNO KEY (SECONDARY KEY)

SYSADM.IDNO_1KEY CUST.NAME-KEY P 1 NAME 2

NAME KEY (SECONDARY KEY) SYSADM.NAME_1

ELM CUST.CRED-IND P 1 CRED CRED-IND ELEMENT

ELM CUST.CUST-ADDR P 1 CUSAD CUST-ADDR-ELEMENT

ELM CUST.CUST-ID P 1 CUSID CUST-ID ELEMENT

ELM CUST.CUSTOMERS P 1 FULLCUST FULL TABLE ELEMENT

FLD CUST.CUST-ID P 1 SYSADM.CUST_ID FLD CUST.IND-CD P 1 SYSADM.IND_CD FLD CUST.CUST-NO P 1 SYSADM.CUST_NO FLD CUST.NAME P 1 SYSADM.NAME


Indented Report





FLD CUST.ADDR-1 P 1 SYSADM.ADDR_1 FLD CUST.ADDR-2 P 1 SYSADM.ADDR_2 FLD CUST.CITY P 1 SYSADM.CITY FLD CUST.STATE P 1 SYSADM.STATE FLD CUST.ZIP P 1 SYSADM.ZIP FLD CUST.CRED-IND P 1 SYSADM.CRED_IND FLD CUST.PHONE P 1 SYSADM.PHONE FLD CUST.AREA-CD P 1 SYSADM.AREA_CD FLD CUST.PH-EXCH P 1 SYSADM.PH_EXCH FLD CUST.PH-NO P 1 SYSADM.PH_NO FLD CUST.OPEN-$ P 1 OPEN-$ FIELD SYSADM.OPEN_$ FLD CUST.YTD-SALES P 1 SYSADM.YTD_SALES FLD CUST.ACT-DT P 1

CUST ACT-DT FIELD SYSADM.ACT_DT FLD CUST.ACT-YR P 1

CUST ACT-YR FIELD SYSADM.ACT_YR FLD CUST.ACT-MO P 1

CUST ACT-MO FIELD SYSADM.ACT_MO FLD CUST.ACT-DAY P 1

CUST ACT-DAY FIELD SYSADM.ACT_DAY FLD CUST.SLMN-ID P 1 SYSADM.SLMN_ID

. . P 1 DTL .

. . . . . .

. . . . .


Indented Report

Impact Analysis Report

When you plan to modify an occurrence, you should run an impact analysisreport to determine if the planned modification will affect other occurrences andrequire you to modify those occurrences. You can use the results of the reportto determine how many occurrences are impacted and estimate the time youwill spend in making modifications to each.

For CA Ideal

An impact analysis report is especially helpful if you are a CA Ideal user andplan to modify an ELEMENT occurrence related to a DATAVIEW occurrence orif you plan to modify a DATAVIEW occurrence. You may discover after runningthe report that changes to the ELEMENT and DATAVIEW occurrences requireyou to modify a number of applications which use the DATAVIEW. On thebasis of the report, you can determine how many applications are impacted andthe specific applications requiring modification.

The format of the transactions to run a batch Indented Report showing whichoccurrences are impacted by a change to an ELEMENT occurrence are asfollows:

-DEF PATH,path-name-DEF TRACE ELEMENT.DATAVIEW,$INTERNAL-DEF TRACE DATAVIEW.PROGRAM,PGM-DVW-USE-DEF TRACE PROGRAM.PANEL,PGM-PNL-USE-DEF TRACE PROGRAM.REPORT,PGM-RPT-PRODUCE-DEF TRACE PROGRAM.SYSTEM,SYS-PGM-CONTAIN-DEF TRACEF PROGRAM.PROGRAM,PGM-PGM-CALL-END-RPT START,ELEMENT,element-name(stat),path-name-RPT INDENT-END

The path this report traces starts with a specified ELEMENT occurrence andidentifies each DATAVIEW, PANEL, REPORT, and SYSTEM occurrencerelated along the defined path, as well as any PROGRAM occurrences of calledapplications.

If you are modifying a DATAVIEW occurrence, you can start an impact analysisreport with the DATAVIEW occurrence and define the path to identify eachPANEL, REPORT, SYSTEM, and called PROGRAM occurrence.

The impact analysis can help you identify the database associated with aDATAVIEW occurrence. For example, you modify a DATAVIEW occurrenceand determine you need to add a field to one of the related elements. You arenot certain which database contains the element, so you run an impact analysisreport to determine which database you must modify.


Indented Report

The format of the transactions for this report follow:

-DEF PATH,path-name-DEF TRACE DATAVIEW.ELEMENT,$INTERNAL-DEF TRACE ELEMENT.TABLE,$INTERNAL-DEF TRACE TABLE.AREA,$INTERNAL-DEF TRACE AREA.DATABASE,$INTERNAL-END-RPT START,DATAVIEW,dataview-name(stat),path-name-RPT INDENT-END

For CA MetaCOBOL+

Using the above examples, you can design impact analysis reports starting withany occurrence and tracing a logical path to related occurrences to determinethe impact of the modification. For example, if you use CA MetaCOBOL+, theimpact analysis report helps you to determine the impact of modifications to aKEY occurrence related to a DATAVIEW occurrence. You can trace a pathfrom the KEY occurrence to DATAVIEW and PROGRAM occurrences in yourreport.

For CA Datacom STAR

If you use CA Datacom STAR, you can use an impact analysis report todetermine which DATABASE occurrence is related to a NODE occurrencethrough the $ACCESS and $RESIDES relationships. You can trace a pathfrom the NODE occurrence to the DATABASE occurrence or you can trace apath from the DATABASE occurrence to NODE occurrences.

For SQL Processing

If you have the SQL option installed on your system, you can use pathdefinitions to determine the impact of changes to tables, views, or synonyms.These changes can invalidate the CA Datacom/DB access plan for the programcontaining embedded SQL. You can use the impact report to identify theprograms you must precompile again to update the plan.

The following path shows the programs impacted if access to the table is withSQL:

-DEF PATH,IMPACT1 -DEF TRACE,TABLE.STATEMENT,STM-TBL-DEPENDS -DEF TRACE,STATEMENT.PLAN,PLN-STM-CONTAIN -DEF TRACE,PLAN.PROGRAM,PGM-PLN-USES -END


Indented Report

The following path shows the programs impacted if access to the table is doneusing views:

-DEF PATH,IMPACT2 -DEF TRACE,TABLE.VIEW,VEW-TBL-DEPENDS -DEF TRACEB,VIEW.VIEW,VEW-VEW-DEPENDS -DEF TRACE,VIEW.STATEMENT,STM-VEW-DEPENDS -DEF TRACE,STATEMENT.PLAN,PLN-STM-CONTAIN -DEF TRACE,PLAN.PROGRAM,PGM-PLN-USES -END

The following path shows the programs impacted if the table is accessed usingsynonyms:

-DEF PATH,IMPACT3 -DEF TRACE,TABLE.SYNONYM,SYN-TBL-REFERS -DEF TRACE,SYNONYM.VIEW,VEW-SYN-DEPENDS -DEF TRACEB,VIEW.VIEW,VEW-VEW-DEPENDS -DEF TRACE,VIEW.STATEMENT,STM-VEW-DEPENDS -DEF TRACE,SYNONYM.STATEMENT,STM-SYN-DEPENDS -DEF TRACE,STATEMENT.PLAN,PLN-STM-CONTAIN -DEF TRACE,PLAN.PROGRAM,PGM-PLN-USES -END

For complete information about SQL processing, see the CA Datacom/DB SQLUser Guide.

INDENTED Report - Impact Analysis - For CA Ideal









-DEF PATH,IMPACT1 ;-DEF TRACE,FIELD.ELEMENT,$INTERNAL ;-DEF TRACE,ELEMENT.DATAVIEW,$INTERNAL ;-DEF TRACE,DATAVIEW.PROGRAM,PGM-DVW-USE ;-DEF TRACE,PROGRAM.SYSTEM,SYS-PGM-CONTAIN ;-DEF TRACE,PROGRAM.REPORT,PGM-RPT-PRODUCE ;-DEF TRACE,PROGRAM.PANEL,PGM-PNL-USE ;-DEF TRACE,PROGRAM.PROGRAM,PGM-PGM-CALL ;-END ;


Indented Report




-RPT START,FIELD,ACT-A3.SDATE(T1),IMPACT1 ;-RPT INDENT ;-END ;




DESCRIPTION................................... NAME ID USE

FLD ACT-A3.SDATE T T1ELM ACT-A3.SDATE T T1 SDATE

DATE DVW ACT-DVW-A3 T T1

SAMPLE DATAVIEW FOR TABLE A3 DVW SAMP-ACCTG-DVW T T1

SAMPLE USER DVW FOR TABLE A3 PGM SPRG3 T 1

SAMPLE PROGRAM 3 SYS SAMP-SYS T 1 SAMPLE-USER SYSTEM RPT SRPT4 T 1

SAMPLE REPORT 4 PNL SPNL3 T 1

SAMPLE PANEL 3 PGM SPRG6 T 1

SAMPLE PROGRAM 6 PGM SPRG1 T 1

SAMPLE PROGRAM 1 END OF JOB

INDENTED Report - Impact Analysis - For a Dataview









-DEF PATH,IMPACT2 ;-DEF TRACE,DATAVIEW.ELEMENT,$INTERNAL ;-DEF TRACE,ELEMENT.TABLE,$INTERNAL ;-DEF TRACE,TABLE.AREA,$INTERNAL ;-DEF TRACE,AREA.DATABASE,$INTERNAL ;-END ;


Indented Report




-RPT START,DATAVIEW,SAMP(PROD),IMPACT2 ;-RPT INDENT ;-END ;





DVW SAMP-ACCTG-DVW P 3SAMPLE USER DVW FOR TABLE A3

ELM ACT-A3.TABLE P 1 TABLE TABLE

TBL ACT-A3 P 1 A3 4SAMPLE ACCOUNTING RECORD A3

ARA ACT-A3 P 1 A3SAMPLE ACCOUNTING AREA A3

BAS SAMP-ACT-DB P 1 5ACCOUNTING SAMPLE DATABASE

ELM ACT-A3.COMND P 1 COMND COMMAND




ELM ACT-A3.KNAME P 1 KNAME KEY NAME




ELM ACT-A3.BASE P 1 BASE DATABASE NAME




Indented Report






ELM ACT-A3.UID6 P 1 UID6USER ID BLOCK




ELM ACT-A3.SDATE P 1 SDATE DATE




ELM ACT-A3.LOGIO P 1 LOGIO LOGICAL I/O




ELM ACT-A3.REQS P 1 REQSNUMBER OF REQUESTS








ELM ACT-A3.SETCT P 1 SETCTNUMBER OF RECORDS FOR CBS REQUESTS




END OF JOB


Index Report

Index Report

The Index Report provides a summary listing of selected entity-occurrences. Ifa path is specified in the transaction, the report is presented according toentity-occurrence relationships. If no path is specified, the report is presentedalphabetically by entity-type.

Report Content

The Index Report contains the following information, listed in left-to-right order.If the actual attribute names are different from the printed headings on thereport, they appear in parentheses.

ENTITY-TYPEEntity-type name.


VRSN (ENTITY-VER)Version number.

STS (STATUS)The status of the occurrence.

LK (LOCK)Lock level (if this is blank, the Lock Level is 0).

PSWD (PASSWORD)The four-character password (if the override code was provided in thereport request).

DESCRIPTIONEntity-occurrence description you added. (For documentation purposesonly.)

RECORD (RECORD-NAME)Datadictionary name for the record associated with a KEY, ELEMENT, orFIELD entity-occurrence.

ELEMENT (ELM-NAME)The name of the element to which a FIELD entity-occurrence belongs.


Index Report

Request Format

Use the following format for an Index Report request:

��──-RPT──INDEX────────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

When submitting with a path, use the following format for an Index Reportrequest:

Index Report When Submitting with a Path (Step 1)

��──-RPT──START────────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

Index Report When Submitting with a Path (Step 2)

��──-RPT──INDEX─ ──┬ ┬───────────────────────── ─────────────────────────�� └ ┘ ─,entity─ ──┬ ┬──────────── ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

For discussions about the parameters, see “Coding the Basic Report Request”on page 412 and “Using Pathing in Reporting” on page 418.

Note: To print passwords in the report, use the override code in the reportrequest.


Index Report

INDEX REPORT - No Path









-RPT INDEX,FIELD,ACCTS.ALL ;


Security Level: 1 Index Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx


FIELD BILL-DAY 1 H ACCTSFIELD BILL-DT 1 H ACCTSFIELD BILL-MO 1 H ACCTSFIELD BILL-YR 1 H ACCTSFIELD CUST-ID 1 H ACCTSFIELD CUST-NO 1 H ACCTSFIELD DISC-AMT 1 H ACCTSFIELD FRT-AMT 1 H ACCTSFIELD IND-CD 1 H ACCTSFIELD ORD-AMT 1 H ACCTSFIELD ORD-ID 1 H ACCTSFIELD BILL-DAY 2 H ACCTS ACCTSFIELD BILL-DT 2 H ACCTS ACCTSFIELD BILL-MO 2 H ACCTS ACCTSFIELD BILL-YR 2 H ACCTS ACCTSFIELD CUST-ID 2 H ACCTS ACCTS


Index Report




FIELD CUST-NO 2 H ACCTS ACCTSFIELD DISC-AMT 2 H ACCTS ACCTSFIELD FRT-AMT 2 H ACCTS ACCTSFIELD IND-CD 2 H ACCTS ACCTSFIELD ORD-AMT 2 H ACCTS ACCTSFIELD ORD-ID 2 H ACCTS ACCTSFIELD BILL-DAY 3 P ACCTS BILL-DAY FIELD ACCTSFIELD BILL-DT 3 P ACCTS BILL-DT FIELD ACCTSFIELD BILL-MO 3 P ACCTS BILL-MO FIELD ACCTSFIELD BILL-YR 3 P ACCTS BILL-YR FIELD ACCTSFIELD CUST-ID 3 P ACCTS CUST-ID FIELD ACCTSFIELD CUST-NO 3 P ACCTS CUST-NO FIELD ACCTSFIELD DISC-AMT 3 P ACCTS DISC-AMT FIELD ACCTSFIELD FRT-AMT 3 P ACCTS FRT-AMT FIELD ACCTSFIELD IND-CD 3 P ACCTS IND-CD FIELD ACCTSFIELD ORD-AMT 3 P ACCTS ORD-AMT FIELD ACCTS

. . . . . . . .

. . . . . . . .

. . . . . . . .


Index Report

INDEX Report - STANDARD Path









-DEF PATH,PARTIAL ;-DEF TRACE,TABLE.ELEMENT,$INTERNAL ;-DEF TRACE,ELEMENT.FIELD,$INTERNAL ;-END ;




-RPT START,TABLE,ACCTS(PROD),PARTIAL ;-RPT INDEX ;


Index Report




TABLE ACCTS 3 P ORDER-ENTRY ACCTS TABLEELEMENT ACCTS 3 P ACCTS FULL TABLE ELEMENT ACCTSFIELD ORD-ID 3 P ACCTS ORD-ID FIELD ACCTS ACCTSFIELD BILL-DT 3 P ACCTS BILL-DT FIELD ACCTS ACCTSFIELD BILL-YR 3 P ACCTS BILL-YR FIELD ACCTS ACCTSFIELD BILL-MO 3 P ACCTS BILL-MO FIELD ACCTS ACCTSFIELD BILL-DAY 3 P ACCTS BILL-DAY FIELD ACCTS ACCTSFIELD ORD-AMT 3 P ACCTS ORD-AMT FIELD ACCTS ACCTSFIELD FRT-AMT 3 P ACCTS FRT-AMT FIELD ACCTS ACCTSFIELD DISC-AMT 3 P ACCTS DISC-AMT FIELD ACCTS ACCTSFIELD CUST-ID 3 P ACCTS CUST-ID FIELD ACCTS ACCTSFIELD IND-CD 3 P ACCTS IND-CD FIELD ACCTS ACCTSFIELD CUST-NO 3 P ACCTS CUST-NO FIELD ACCTS ACCTSELEMENT CUST-ID 3 P CUST-ID ELEMENT ACCTSFIELD CUST-ID 3 P ACCTS CUST-ID FIELD ACCTS CUST-IDFIELD IND-CD 3 P ACCTS IND-CD FIELD ACCTS CUST-ID




FIELD CUST-NO 3 P ACCTS CUST-NO FIELD ACCTS CUST-IDELEMENT ORD-ID 3 P ORD-ID ELEMENT ACCTSFIELD ORD-ID 3 P ACCTS ORD-ID FIELD ACCTS ORD-ID

END OF JOB


Relationship Report

Relationship Report

The Relationship Report presents a list of occurrences and describes theirrelationship to one another.

Each occurrence requested in the report transaction is grouped in an indentedformat with its related occurrences. When a path is specified in the transaction,occurrences are listed in the order defined by the path. Occurrences related byemulated relationships, such as $INTERNAL between TABLE and FIELDoccurrences, do not appear on the report. For more information aboutemulated relationships, see the CA Datacom Datadictionary AdministratorGuide.

If the occurrence is the subject of an ordered relationship, the object occurrenceor group of occurrences are listed in indented format and indicated bySTART-OF-CHAIN and END-OF-CHAIN on the report. The order of therelationships are identified on the report with NEXT IS. See the sample of areport of ordered relationships on 538.

Report Content

The Relationship Report contains the following information, listed in left-to-rightorder. If the actual attribute names are different from the printed headings onthe report, they appear in parentheses.

ENTITY-TYPEThe occurrence entity-type.


STATVersion number and status of the occurrence.

DESCRIPTIONThe description of the occurrence.

RELATIONSHIP NAMEName of the relationship existing between the first occurrence and theindented occurrence.

ROLEThe nature of the relationship between the occurrence in the indented lineto the occurrence in the preceding line.

S indicates subject, O indicates object.

LINKEDDesignates whether the indented occurrence is linked (connected) to thefirst occurrence.



Relationship Report

Note: This relates most often to automatic relationships and to historyversions where occurrences have aged off Datadictionary.

ORDERED (ORDERED-RULE)Designates whether the relationship is ordered.


VERSION (ENTITY-VER)The version number of the connected occurrence.

STATUSThe status of the connected occurrence.

Request Format

Use the following format for a Relationship Report request:

��──-RPT──RELAT────────────────────────────────────────────────────────────────�


�─ ──┬ ┬──────────── ────────────────────────────────────────────────────────────�� └ ┘ ─,modifiers─

When submitting with a path, use the following format for a Relationship Reportrequest:

Relationship Report, Submitting with a Path (Step 1)

��──-RPT──START────────────────────────────────────────────────────────────────�

�─ ──┬ ┬────────────────────────────────────────────────────────── ─,path-name────� └ ┘ ─,entity,─ ──┬ ┬────────────── ──┬ ┬────────── ──┬ ┬──────────── └ ┘ ─parent-name.─ └ ┘ ─occ-name─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─,ovrd)─────

�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

Relationship Report, Submitting with a Path (Step 2)

��──-RPT──RELAT─ ──┬ ┬───────────────────────── ──┬ ┬──────────── ─────────�� └ ┘ ─,entity─ ──┬ ┬──────────── └ ┘ ─,modifiers─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────



Relationship Report

The modifiers parameter is discussed next:

,modifiersThis parameter can be coded with one to four entity-type names to furtherqualify the relationship selection. The report is limited to occurrences thatare associated with occurrences in any of the entity-types coded in thisparameter. In the following example, the report is limited to occurrencesthat have associated occurrences in the AREA or DATABASEentity-types:

-RPT RELAT,,,AREA,DATABASE

RELATIONSHIP Report - No Path









-RPT RELAT,DATABASE,ORDER-ENTRY(HIST) ;


Relationship Report


Security Level: 1 Relationship Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ENTITY-TYPE..................... OCCURRENCE....................................................... VERSION STATUS DESCRIPTION......................... RELATIONSHIP NAME............... ENTITY-TYPE.....................

OCCURRENCE....................................................... VERSN/STAT ROLE LINKED ORDERED DESCRIPTION.........................

DATABASE ORDER-ENTRY (1) HISTORDER-ENTRY DEMO DATABASE

$INTERNAL AREAACCTS (1)HIST OBJ YES NO

ORDER-ENTRY ACCTS AREACUST (1)HIST OBJ YES NO

ORDER-ENTRY CUST AREADETAIL (1)HIST OBJ YES NO

ORDER-ENTRY DETAIL AREAITEMS (1)HIST OBJ YES NO

ORDER-ENTRY ITEMS AREAORD-NO (1)HIST OBJ YES NO

ORDER-ENTRY ORDER-NUMBERS AREARCPTS (2)HIST OBJ YES NO

ORDER-ENTRY RECEIPTS AREASHIPTO (2)HIST OBJ YES NO

ORDER-ENTRY SHIP-TO AREASLSHST (1)HIST OBJ YES NO

ORDER-ENTRY SALES-HIST AREADATABASE ORDER-ENTRY (2) HIST

ORDER-ENTRY DEMO DATABASE $INTERNAL AREA

ACCTS (2)HIST OBJ YES NOORDER-ENTRY ACCTS AREA

CUST (2)HIST OBJ YES NOORDER-ENTRY CUST AREA

DETAIL (2)HIST OBJ YES NOORDER-ENTRY DETAIL AREA

ITEMS (2)HIST OBJ YES NOORDER-ENTRY ITEMS AREA

ORD-NO (2)HIST OBJ YES NOORDER-ENTRY ORDER-NUMBERS AREA

RCPTS (3)HIST OBJ YES NOORDER-ENTRY RECEIPTS AREA

SHIPTO (3)HIST OBJ YES NOORDER-ENTRY SHIP-TO AREA

SLSHST (2)HIST OBJ YES NOORDER-ENTRY SALES-HIST AREA

END OF JOB


Relationship Report

RELATIONSHIP Report - STANDARD Path













-RPT START,TABLE,ACCTS(T1),STANDARD ;-RPT RELAT ;


Relationship Report





TABLE ACCTS (T1) TESTORDER-ENTRY ACCTS TABLE

$INTERNAL AREAACCTS (T1)TEST SUB YES NO

ORDER-ENTRY ACCTS AREATABLE ACCTS (T1) TEST

ORDER-ENTRY ACCTS TABLE $INTERNAL ELEMENT

ACCTS.ACCTS (T1)TEST OBJ YES NOACCTS FULL TABLE ELEMENT

ACCTS.CUST-ID (T1)TEST OBJ YES NO CUST-ID ELEMENT

ACCTS.ORD-ID (T1)TEST OBJ YES NO ORD-ID ELEMENTTABLE ACCTS (T1) TEST

ORDER-ENTRY ACCTS TABLE $INTERNAL KEY

ACCTS.CUST-ID-KEY (T1)TEST OBJ YES NOCUST-ID SECONDARY KEY

ACCTS.ORD-ID-KEY (T1)TEST OBJ YES NOORD-ID MASTER KEY

KEY ACCTS.CUST-ID-KEY (T1) TESTCUST-ID SECONDARY KEY

$INTERNAL TABLEACCTS (T1)TEST SUB YES NO

ORDER-ENTRY ACCTS TABLEKEY ACCTS.ORD-ID-KEY (T1) TEST

ORD-ID MASTER KEY $INTERNAL TABLE

ACCTS (T1)TEST SUB YES NOORDER-ENTRY ACCTS TABLE

ELEMENT ACCTS.ACCTS (T1) TESTACCTS FULL TABLE ELEMENT

$INTERNAL DATAVIEWACCOUNTS (T1)TEST SUB YES YES

ELEMENT ACCTS.ACCTS (T1) TESTACCTS FULL TABLE ELEMENT


Relationship Report





$INTERNAL TABLEACCTS (T1)TEST SUB YES NO

ORDER-ENTRY ACCTS TABLEELEMENT ACCTS.CUST-ID (T1) TEST CUST-ID ELEMENT $INTERNAL DATAVIEW

ACTCUSID (T1)TEST SUB YES YESELEMENT ACCTS.CUST-ID (T1) TEST CUST-ID ELEMENT $INTERNAL TABLE


ELEMENT ACCTS.ORD-ID (T1) TEST ORD-ID ELEMENT $INTERNAL DATAVIEW

ACTORDID (T1)TEST SUB YES YESELEMENT ACCTS.ORD-ID (T1) TEST ORD-ID ELEMENT $INTERNAL TABLE


END OF JOB


Relationship Report

RELATIONSHIP Report - With Modifiers









-RPT RELAT,TABLE,ACCTS(T1),KEY,ELEMENT ;





TABLE ACCTS (T1) TESTORDER-ENTRY ACCTS TABLE

$INTERNAL KEYACCTS.CUST-ID-KEY (T1)TEST OBJ YES NO

CUST-ID SECONDARY KEYACCTS.ORD-ID-KEY (T1)TEST OBJ YES NO

ORD-ID MASTER KEYTABLE ACCTS (T1) TEST

ORDER-ENTRY ACCTS TABLE $INTERNAL ELEMENT

ACCTS.ACCTS (T1)TEST OBJ YES NOACCTS FULL TABLE ELEMENT

ACCTS.CUST-ID (T1)TEST OBJ YES NO CUST-ID ELEMENT

ACCTS.ORD-ID (T1)TEST OBJ YES NO ORD-ID ELEMENT

END OF JOB


Relationship Report

RELATIONSHIP Report - Ordered Relationships









-RPT RELAT,DATAVIEW,SAMP-ACCTG-DVW(T1) ;


Relationship Report





DATAVIEW SAMP-ACCTG-DVW (T1) TESTSAMPLE USER DVW FOR TABLE A3

$INTERNAL ELEMENT START-OF-CHAIN

ACT-A3.BASE (T1)TEST OBJ YES YES DATABASE NAME

NEXT IS ... ACT-A3.UID6 11ACT-A3.COMND (T1)TEST OBJ YES YES

COMMANDNEXT IS ... ACT-A3.KNAME 11

ACT-A3.KNAME (T1)TEST OBJ YES YES KEY NAME

NEXT IS ... ACT-A3.BASE 11ACT-A3.LOGIO (T1)TEST OBJ YES YES

LOGICAL I/ONEXT IS ... ACT-A3.REQS 11

ACT-A3.REQS (T1)TEST OBJ YES YESNUMBER OF REQUESTS

NEXT IS ... ACT-A3.SETCT 11ACT-A3.SDATE (T1)TEST OBJ YES YES

DATENEXT IS ... ACT-A3.LOGIO 11

ACT-A3.SETCT (T1)TEST OBJ YES YESNUMBER OF RECORDS FOR CBS REQUESTS

NEXT IS ... END-OF-CHAINACT-A3.TABLE (T1)TEST OBJ YES YES

TABLENEXT IS ... ACT-A3.COMND 11

ACT-A3.UID6 (T1)TEST OBJ YES YESUSER ID BLOCK

NEXT IS ... ACT-A3.SDATE 11 END OF JOB


Schema Report

Schema Report

If the SQL processing mode is installed on your system, you can obtain aSchema Report. A schema defines all objects owned by the individual orindividuals associated with the authorization identifier (AUTHID) of the schema.For more information about SQL processing, see the CA Datacom/DB SQLUser Guide.

The report lists the AUTHORIZATION occurrences that are valid authorizationidentifiers. The CREATE SCHEMA statement in SQL processing produces theAUTHID. Datadictionary either creates an AUTHORIZATION occurrencerepresenting the authorization ID or uses an existing AUTHORIZATIONoccurrence if the name exactly matches the AUTHID.

The related occurrences of the TABLE, FIELD, KEY, VIEW, SYNONYM, PLAN,and STATEMENT entity-types are listed in indented format below eachAUTHORIZATION occurrence. Occurrences are sorted within each entity-typealphanumerically by their Datadictionary occurrence names.

The Schema Report differs from other reports in that the report request caninclude only an AUTHORIZATION occurrence name as a parameter. Also,pathing is not used with a Schema Report request.

Report Content

The Schema Report contains the following information, listed in left-to-rightorder. If the actual attribute names are different from the printed headings onthe report, they appear in parentheses.

ENTITY-TYPEEntity-type in alphabetical order for each occurrence.

OCCURRENCE (ENTITY-NAME)Datadictionary name of the occurrence.

STATUSStatus of the occurrence.

VERSION (ENTITY-VER)Version number of the occurrence.

SQLNAMESQL name of the occurrence.

DESCRIPTIONEntity-occurrence description.


Schema Report

The following information is listed under the heading DATACOM/DB:

NAME (DATACOM-NAME)The DATACOM-NAME attribute-value of the TABLE or KEY occurrence.

ID (DATACOM-ID)The DATACOM-ID attribute-value of the TABLE or KEY occurrence.

USEFor TABLE occurrences:

A Indicates that SQL processing can access the table

I Indicates that the SQL-INTENT attribute-value is coded Y

For PLAN occurrences:

V Indicates that the plan is valid.

Only occurrences that are related to a PRODuction status AUTHORIZATIONoccurrence that is an authorization identifier (AUTHID) for a schema areincluded in the report.

Request Format

Use the following format for a Schema Report request:

��──-RPT──SCHEMA─ ──┬ ┬───────────────────────── ────────────────────────────────�� └ ┘ ─,authorization-occ-name─

,authorization-occ-nameThis parameter can be used to limit the report to a specific authorizationoccurrence. If you omit this parameter, all AUTHORIZATION occurrencesthat are used as schemas are listed. You can enter ALL or a genericselection using an asterisk (*). For example, SMI* processes allAUTHORIZATION occurrences with SMI as the first three characters inthe name.

Valid Entries: 1- to 32-character name of an existingAUTHORIZATION occurrenceGeneric selectionALL

Default Value: ALL


Schema Report

SCHEMA Report









-RPT SCHEMA,SAMPLE_USER ;


Schema Report


Security Level: 1 Schema Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ENTITY-TYPE.... OCCURRENCE....................................................... S VERS DATACOM/DB

SQLNAME.......................................................... NAME ID USE DESCRIPTION...................................

ATZ SAMPLE_USER P 1 PLN SAMPLE_USER-SMPUSRPG P 1 V SAMPLE_USER.SMPUSRPG SYN SAMPLE_USER-SAMP_ACCT_NAME_VEW P 1 SAMPLE_USER.SAMP_ACCT_NAME_VEW SYN SAMPLE_USER-SAMP_NAME_ADDR_TBL P 1 SAMPLE_USER.SAMP_NAME_ADDR_TBL

TBL SAMPLE_USER-SAMP_TBL P 1 A61 161 I A SAMPLE_USER.SAMP_TBL FLD SAMPLE_USER-SAMP_TBL.ACCT_NO P 1 SAMPLE_USER.ACCT_NO FLD SAMPLE_USER-SAMP_TBL.NAME P 1 SAMPLE_USER.NAME FLD SAMPLE_USER-SAMP_TBL.ADDRESS P 1 SAMPLE_USER.ADDRESS FLD SAMPLE_USER-SAMP_TBL.CITY P 1 SAMPLE_USER.CITY FLD SAMPLE_USER-SAMP_TBL.STATE P 1 SAMPLE_USER.STATE FLD SAMPLE_USER-SAMP_TBL.ZIP P 1 SAMPLE_USER.ZIP

KEY SAMPLE_USER-SAMP_TBL.SQ13 P 1 SQ13 13 SQLKEY FLD SAMPLE_USER-SAMP_TBL.ACCT_NO P 1 SAMPLE_USER.ACCT_NO VEW SAMPLE_USER-SAMP_VIEW_1 P 1 SAMPLE_USER.SAMP_VIEW_1 FLD SAMPLE_USER-SAMP_VIEW_1.ACCT_NO P 1 SAMPLE_USER.ACCT_NO FLD SAMPLE_USER-SAMP_VIEW_1.NAME P 1 SAMPLE_USER.NAME VEW SAMPLE_USER-SAMP_VIEW_2 P 1 SAMPLE_USER.SAMP_VIEW_2 FLD SAMPLE_USER-SAMP_VIEW_2.ACCT_NO P 1 SAMPLE_USER.ACCT_NO FLD SAMPLE_USER-SAMP_VIEW_2.ZIP P 1 SAMPLE_USER.ZIP FLD SAMPLE_USER-SAMP_VIEW_2.CITY P 1 SAMPLE_USER.CITY

END OF JOB


SQL Column Report

SQL Column Report

Users such as database designers can employ the Datadictionary SQL ColumnReport to help convert existing CA Datacom/DB tables, that is, legacy tables,for use with the CA Datacom SQL. see “Report Request Transactions.”

■ accessible to standard SQL,■ accessible to DATACOM VIEWs, or■ not accessible, and why.

DATACOM VIEWs can be defined using the SQL CREATE VIEW statement. ADATACOM VIEW is a special view of tables that allows access to data storedin tables not normally accessible with standard SQL, for example, data such asrepeating groups and redefined data. For more information about DATACOMVIEWs see the CA Datacom/DB SQL User Guide. see “Report RequestTransactions.” For the format of the input transactions that generate the report,see “Report Request Transactions.” For the format itself, see “Report Format”on page 547.

Report Request Transactions

The first request syntax is used when requesting the report for one or moreoccurrences to be accessed only as specified in the request.

SQL Column Report Request Syntax

��──-RPT─ ──COLUMN,entity ──┬ ┬─────────────────────────────── ──┬ ┬────── ──� └ ┘ ──┬ ┬─────────── ──┬ ┬──────────── ├ ┤─,ord─ └ ┘─,occ-name─ ├ ┤─(vrs)────── └ ┘─,──── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

�─ ──┬ ┬────── ──────────────────────────────────────────────────────────�� └ ┘─,ron─

The second request format is used when generating the report for occurrencesaccessed during Datadictionary Path Processing.

SQL Column Report Request Syntax (Path Processing)

��──-RPT─ ──COLUMN,entity ──┬ ┬──────────────── ──┬ ┬────── ──┬ ┬────── ──────�� └ ┘ ──┬ ┬──────────── ├ ┤─,ord─ └ ┘─,ron─ ├ ┤─(vrs)────── └ ┘─,──── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

,entity,(Required) The Datadictionary entity-type of the entity-occurrence(s) forwhich the report is to be generated.

Valid Entries: TABLE or RECORD


SQL Column Report


,occ-name(Optional) Specifies the entity-occurrence-name of the TABLE orRECORD occurrence for which you want the report to be generated.

Specifying ALL for occ-name indicates you want all occurrences that meetthe remaining criteria.

To specify a “generic” name for occ-name, specify any number of leadingcharacters followed by an asterisk (*). This generates a report thatincludes all occurrences of the specified type with an occurrence namebeginning with the specified characters and meeting the other criteria.

You can also specify a full entity-occurrence name for occ-name togenerate a report for that specific entity-occurrence alone.

Valid Entries: Any full or generic entity-occurrence name, or ALL

Default Value: ALL

vrs(Optional) Specifies the Datadictionary version or status of the occurrencefor which you want the report to be generated.

Specifying ALL means that you want all occurrences, regardless of status,that meet the remaining criteria.

Valid Entries: Any valid Datadictionary version or status designation,or ALL

Default Value: ALL

ovrd(Optional) Specifies the Site Override Code chosen when the DDSYSTBLmacro was used to assemble the Datadictionary System Resource Table.

Note: Specifying a value for ovrd is only required if reporting onoccurrences with a Lock Code of 2.

Valid Entries: A valid Site Override Code


,ord(Optional) Specifies the sequence and format of the report. For moreinformation about the format of the report, see page 547.

Specifying NAME or N indicates the report is to be generated inalphabetic sequence by name. The name used is the name designated inthe next parameter (ron).

Specifying COPYBOOK or C indicates the report is to be generated in“copybook” sequence, which is in the same sequence as the FIELDReport.

Valid Entries: NAME or N, or COPYBOOK or C

Default Value: COPYBOOK


SQL Column Report

,ron(Optional) This “Report on Name” option specifies which name is to bereported for the columns.

Specifying OCCURRENCE or O indicates that you want the report toshow the occurrence names of the columns.

Specifying SQLNAME or S indicates that you want the SQLNAME to beused in the report.

Note: If you specified NAME for the report order (ord as previouslyshown) the value you specify here for ron is used to sequence the report.

Valid Entries: OCCURRENCE or O, or SQLNAME or S

Default Value: OCCURRENCE


SQL Column Report

Report Format

There are two report formats depending on the order option selected. Forordering by selected name (NAME) see the following example. For ordering bydisplacement (COPYBOOK), see page 550. Each sample report is followed bydescriptions of the fields in the reports.

Example — Order Is NAME: The following requests a report with NAME forthe order. SQLNAME is specified to request the report show the SQL name.

-RPT COLUMN,TABLE,CUST(PROD),NAME,SQLNAME ;

Following is a sample report generated by the previously shown specifications.Descriptions of the report follow the sample.


Security Level: n SQL Column Report in NAME Order Release: 12 Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: xxxxxxx DD Base: 2 �A� �B� �C� �D�ENTITY-TYPE: TABLE OCCURRENCE: CUST (1)PROD �E� �F�AUTHID: SYSADM SQLNAME: CUST �G� �H� �I�DATE-ADDED: 1/16/4 DATE-LAST-CHANGED: 1/16/4 TIME-OF-CHANGE: 17.32.19�J� SQL ACCESS DATACOM

SQL Name..................... STD. DATACOM SQL TYPE.. CLASS TYPE SIGN LNGTH NULL REPEAT REDEF DISPL�L� �M� �N� �O� �P� �Q� �R� �S� �T� �U��V� �W� �X� �Y�

ACT_DAY YES YES CHARACTER SIMPLE C N 2 N 1 N 146ACT_DT NO (CMP)YES CHARACTER COMPOUND C N 6 N 1 N 142ACT_MO YES YES CHARACTER SIMPLE C N 2 N 1 N 144ACT_YR YES YES CHARACTER SIMPLE C N 2 N 1 N 142ADDR_1 YES YES CHARACTER SIMPLE C N 3 N 1 N 35ADDR_2 YES YES CHARACTER SIMPLE C N 3 N 1 N 65AREA_CD YES YES CHARACTER SIMPLE C N 3 N 1 N 122CITY YES YES CHARACTER SIMPLE C N 15 N 1 N 95CRED_IND YES YES CHARACTER SIMPLE C N 1 N 1 N 121CUST_ID NO (CMP)YES CHARACTER COMPOUND C N 5 N 1 N CUST_NO YES YES CHARACTER SIMPLE C N 4 N 1 N 1IND_CD YES YES CHARACTER SIMPLE C N 1 N 1 N NAME YES YES CHARACTER SIMPLE C N 3 N 1 N 5OPEN_$ YES YES DECIMAL SIMPLE D Y 5 N 1 N 132PH_EXCH YES YES CHARACTER SIMPLE C N 3 N 1 N 125PH_NO YES YES CHARACTER SIMPLE C N 4 N 1 N 128PHONE NO (CMP)YES CHARACTER COMPOUND C N 1 N 1 N 122SLMN_ID YES YES CHARACTER SIMPLE C N 5 N 1 N 148STATE YES YES CHARACTER SIMPLE C N 2 N 1 N 11YTD_SALES YES YES DECIMAL SIMPLE D Y 5 N 1 N 137ZIP YES YES CHARACTER SIMPLE C N 9 N 1 N 112

Description:

�A� This is the entity-type for which the report is being generated.

�B� This is the Datadictionary occurrence-name of the reportedentity-occurrence.

�C� This is the Version of the reported occurrence.

�D� This is the Status of the reported occurrence.

�E� This is the SQL AUTHID of the reported entity-occurrence.

�F� This is the SQL Name of the reported entity-occurrence.


SQL Column Report

�G� This is the date the reported entity-occurrence was added toDatadictionary.

�H� This is the date the reported entity-occurrence was last updated.

�I� This is the time the reported entity-occurrence was last updated.

�J� This field is based on the “Report on Name” (ron) option specified onthe input transaction (see page 546). Values are “SQL Name” or“Occurrence.”

�L� This field is based on the “Report on Name” (ron) option specified onthe input transaction. If “SQLNAME” is specified for ron, this field is theSQLNAME attribute-value. If “OCCURRENCE” is specified for ron, thisfield is the ENTITY-NAME attribute-value.

�M� This standard SQL access field indicates whether the column isaccessible using standard SQL. Possible values are YES and NO.

�N� If the value of the previous field is NO, meaning there is no SQLaccess, this field indicates the reason SQL access is NO. The valuesare:

CMP The column is compound (CLASS=C), and it is not arepeating group (REPEAT>1).

FIL The column is filler (CLASS=F).

RDF The column is a redefinition of another (REDEF ne N), or it isa child of another column that is a redefinition.

RPC The column is the child of a repeating column.

RPT The column is a repeating column (REPEAT>1).

Valid Entries: The column is a value definition (CLASS=V).

�O� This SQL access field indicates whether the column is accessible usingCA Datacom/DB SQL extensions. Possible values are YES and NO.

�P� If the value of the previous field is NO, meaning there is no access toCA Datacom/DB SQL extensions, this field indicates the reason for noSQL access. The values are:



Valid Entries: The column is a value definition (CLASS=V).

�Q� SQL Type. This field displays the SQL Data Type for the column, if it isSQL accessible. The possible values are:

CHARACTER DATE DECIMAL FLOAT GRAPHIC INTEGER


SQL Column Report

L VARCHAR L VARGRAPH NUMERIC SMALLINT TIME TIMESTAMP VARCHAR VARGRAPH

�R� This field contains the expanded Datadictionary CLASS attribute-value.The possible values are:

COMPOUND FILLER SIMPLE VALUE

�S� This field contains the Datadictionary TYPE attribute-value. The valuesare defined in the CA Datacom Datadictionary Attribute ReferenceGuide.

�T� This field contains the Datadictionary SIGN attribute-value. The valuesare defined in the CA Datacom Datadictionary Attribute ReferenceGuide.

�U� This field contains the Datadictionary LENGTH attribute-value.

�V� This field contains the Datadictionary NULL-INDICATOR attribute-value,indicating is nulls are allowed. The values are defined in the CADatacom Datadictionary Attribute Reference Guide.

�W� This field contains the Datadictionary REPEAT attribute-value.

�X� This field contains the Datadictionary REDEFINES attribute-value. Thevalues are defined in the CA Datacom Datadictionary AttributeReference Guide.

�Y� This field contains the Datadictionary DISP-IN-TABLE attribute-valueindicating the displacement in table row.


SQL Column Report

Example — Order is COPYBOOK: The following requests a report withCOPYBOOK for the order. SQLNAME is specified to request the report showthe SQLNAME.

-RPT COLUMN,TABLE,CUST(PROD),COPYBOOK,SQLNAME ;

Following is a sample report generated by the previously shown specifications.Descriptions of the report follow the sample.

Date: dd/mm/ccyy Time: hh.mm.ss Page: 3 CA Datacom Datadictionary

Security Level: n SQL Column Report in COPYBOOK Order Release: 12 Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: DATACOM-INSTALL DD Base: 2ENTITY-TYPE: TABLE OCCURRENCE: CUST (1)PRODAUTHID: SYSADM SQLNAME: CUSTDATE-ADDED: 1/16/4 DATE-LAST-CHANGED: 1/16/4 TIME-OF-CHANGE: 17.32.19

�A� SQL ACCESS DATACOM LEVEL..... SQL Name............... STD. DATACOM SQL TYPE.. CLASS TYPE SGN LNGTH NULL REPEAT REDEF DISPL�B� �C� �D� �E� �F� �G� �H� �I� �J� �L� �M��N� �O� �P� �Q�1 CUST_ID NO (CMP)YES CHARACTER C C N 5 N 1 N 2 IND_CD YES YES CHARACTER S C N 1 N 1 N 2 CUST_NO YES YES CHARACTER S C N 4 N 1 N 11 NAME YES YES CHARACTER S C N 3 N 1 N 51 ADDR_1 YES YES CHARACTER S C N 3 N 1 N 351 ADDR_2 YES YES CHARACTER S C N 3 N 1 N 651 CITY YES YES CHARACTER S C N 15 N 1 N 951 STATE YES YES CHARACTER S C N 2 N 1 N 111 ZIP YES YES CHARACTER S C N 9 N 1 N 1121 CRED_IND YES YES CHARACTER S C N 1 N 1 N 1211 PHONE NO (CMP)YES CHARACTER C C N 1 N 1 N 1222 AREA_CD YES YES CHARACTER S C N 3 N 1 N 1222 PH_EXCH YES YES CHARACTER S C N 3 N 1 N 1252 PH_NO YES YES CHARACTER S C N 4 N 1 N 1281 OPEN_$ YES YES DECIMAL S D Y 5 N 1 N 1321 YTD_SALES YES YES DECIMAL S D Y 5 N 1 N 1371 ACT_DT NO (CMP)YES CHARACTER C C N 6 N 1 N 1422 ACT_YR YES YES CHARACTER S C N 2 N 1 N 1422 ACT_MO YES YES CHARACTER S C N 2 N 1 N 1442 ACT_DAY YES YES CHARACTER S C N 2 N 1 N 1461 SLMN_ID YES YES CHARACTER S C N 5 N 1 N 148

Description:

Top of ReportFor descriptions of the top portion of the report, see the descriptions of�A� through �I� as shown on the report example on page 547 and thedescriptions of that report that begin on that same page.

�A� This field is based on the “Report on Name” (ron) option specified onthe input transaction (see page 546). Values are “SQL Name” or“Occurrence.”

�B� This field contains the Datadictionary LEVEL attribute-value. The valueis limited to one character and is indented one position for eachincrement of the value from 1 up to and including 9. If the valueexceeds 9, then a greater-than symbol (>) is placed in the 10th position.

�C� This field is based on the “Report on Name” (ron) option specified onthe input transaction. If “SQLNAME” is specified for ron, this field is theSQLNAME attribute-value. If “OCCURRENCE” is specified for ron, thisfield is the ENTITY-NAME attribute-value.


SQL Column Report

�D� This standard SQL access field indicates whether the column isaccessible using standard SQL. Possible values are YES and NO.

�E� If the value of the previous field is NO, meaning there is no SQLaccess, this field indicates the reason SQL access is NO. The valuesare:

CMP The column is compound (CLASS=C), and it is not arepeating group (REPEAT>1).


RDF The column is a redefinition of another (REDEF ne N), or it isa child of another column that is a redefinition.


RPT The column is a repeating column (REPEAT>1).

Valid Entries:

The column is a value definition (CLASS=V).

�F� This SQL access field indicates whether the column is accessible usingCA Datacom/DB SQL extensions. Possible values are YES and NO.

�G� If the value of the previous field is NO, meaning there is no access toCA Datacom/DB SQL extensions, this field indicates the reason for noSQL access. The values are:



Valid Entries:

The column is a value definition (CLASS=V).

�H� SQL Type. This field displays the SQL Data Type for the column, if it isSQL accessible. The possible values are:

CHARACTER DATE DECIMAL FLOAT GRAPHIC INTEGER L VARCHAR L VARGRAPH NUMERIC SMALLINT TIME TIMESTAMP VARCHAR VARGRAPH


SQL Column Report

�I� This field contains the Datadictionary CLASS attribute-value. Thevalues are defined in the CA Datacom Datadictionary AttributeReference Guide.

�J� This field contains the Datadictionary TYPE attribute-value. The valuesare defined in the CA Datacom Datadictionary Attribute ReferenceGuide.

�L� This field contains the Datadictionary SIGN attribute-value. The valuesare defined in the CA Datacom Datadictionary Attribute ReferenceGuide.

�M� This field contains the Datadictionary LENGTH attribute-value.

�N� This field contains the Datadictionary NULL-INDICATOR attribute-value,indicating is nulls are allowed. The values are defined in the CADatacom Datadictionary Attribute Reference Guide.

�O� This field contains the Datadictionary REPEAT attribute-value.

�P� This field contains the Datadictionary REDEFINES attribute-value. Thevalues are defined in the CA Datacom Datadictionary AttributeReference Guide.

�Q� This field contains the Datadictionary DISP-IN-TABLE attribute-valueindicating the displacement in table row.


Text Report

Text Report

The Text Report presents the text contained in a single text classification or allclassifications for a given occurrence or occurrences. If a classification name isnot specified, the default is ALL classifications. If an occurrence has text inmultiple text classes, the classes will be printed in alphabetical order.

The report can be produced with or without headings. When headings areincluded, the report pages after each occurrence and prints text line numbers.When headings are omitted, the report lists occurrences together in paragraphformat.

Report Content

The Text Report contains the following information, listed in left-to-right order. Ifthe actual attribute names are different from the printed headings on the report,they appear in parentheses.

ENTITY-TYPEEntity-type to which the occurrence belongs.

DESC (DESCRIPTION)Entity-occurrence description.

NAME (ENTITY-NAME)Entity-occurrence name.

STATUSThe status of the entity-occurrence.

AUTHORAuthor's ID.

CONTROLLERController ID.

COPY-VERSION (PREVIOUS-VERS)The number of the version that was copied to produce this version.

DATE-ADDEDDate the occurrence was added.

DATE-LAST-CHANGED (DATE-LAST-CHG)Date the occurrence was last updated.

TIME-OF-CHANGE (TIME-LAST-CHG)Time the occurrence was changed or, if no updates have been processed,time the occurrence was added.

NUMBER-OF-CHANGES (COUNT)Number of times the occurrence has been updated.


Text Report

TEXTThe actual text associated with this entity-occurrence displays in the bodyof the report below this heading.

TEXT-CLASSThe class name associated with the displayed text. Valid textclassifications include:

OWNED Indicates that the text is owned by another entity-occurrence.

SHARED Indicates that the text is shared by another entity-occurrence.

NOTEXT Indicates that there is no text.

LINEIndicates the line number of the text.

Request Format

Use the following format for a Text Report request:

��──-RPT──TEXT─ ──┬ ┬────────────────────────────────────────────────────────── ──� └ ┘ ─,entity,─ ──┬ ┬────────────── ──┬ ┬────────── ──┬ ┬──────────── └ ┘ ─parent-name.─ └ ┘ ─occ-name─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────

�─ ──┬ ┬──────────── ────────────────────────────────────────────────────────────�� └ ┘ ─,modifiers─

When submitting with a path, use the following format for a Text Reportrequest:

Text Report When Submitting with a Path (Step 1)

��──-RPT──START────────────────────────────────────────────────────────────────�


�─ ──┬ ┬───────────── ───────────────────────────────────────────────────────────�� └ ┘ ─,as-of-date─

Text Report When Submitting with a Path (Step 2)

��──-RPT──TEXT─ ──┬ ┬───────────────────────── ──┬ ┬──────────── ──────────�� └ ┘ ─,entity─ ──┬ ┬──────────── └ ┘ ─,modifiers─ ├ ┤─(vrs)────── ├ ┤─(vrs,ovrd)─ └ ┘─(,ovrd)────



Text Report

,modifiersYou can include the ALIGN, CLASS, and text-classification-namemodifiers in your Text Report transaction. Examples of the allowedcombination of these modifiers are shown following the descriptionspresented.

,ALIGNIf you include the optional ALIGN keyword, the report lists textinformation in paragraph form without line numbers and no headingsare produced. Without the ALIGN keyword, the report pagesbetween each occurrence and page headings and line sequencenumbers are produced. The ALIGN keyword must be first, if used.

,CLASSTo produce a Text Report containing only the text in a specifiedclassification without including the ALIGN parameter, you mustinclude the CLASS keyword before the class-name. Otherwise, theCLASS keyword is optional.

,class-nameYou can optionally specify the text classification name to produce areport containing only the text in the specified classification. If theclass-name parameter is omitted, the report contains all textclassifications associated with the occurrences.

You can produce a Text Report without line numbers or headings and all thetext classifications. Enter the ALIGN keyword preceded by a comma in place ofmodifiers in the preceding transaction formats.

,ALIGN

You can produce a Text Report without line numbers or headings and only fortext with a specified classification name. Enter the ALIGN keyword precededby a comma followed by a classification name preceded by a comma in placeof modifiers in the preceding transaction formats. You can also include theCLASS keyword.

,ALIGN,class-name

,ALIGN,CLASS,class-name

To produce a Text Report with line numbers and headings for text with aspecified classification name enter the CLASS keyword preceded by a commafollowed by a classification name preceded by a comma in place of modifiers inthe preceding transaction formats.

,CLASS,class-name

Note: If you select a FIELD occurrence that has no text and has the samename as a FIELD occurrence in the UNIVERSAL record, Datadictionary usesthe text associated with the universal field for the selected field.


Text Report

TEXT Report - Without ALIGN Option









-RPT TEXT,FIELD,POSTAL,CLASS,ALL ;-END ;


Security Level: 1 Text Report Release: 12 SPnn Copyright © 29 CA. All rights reserved. MUF Name: xxxxxxxx

User: SAMPLE-USER DD Base: 2ENTITY-TYPE: FIELD DESC:NAME: UNIVERSAL.POSTAL-CODE ()TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION:DATE-ADDED: 4/3/8 DATE-LAST-CHANGED: 4/3/8 TIME-OF-CHANGE: 1.8.11 NUMBER-OF-CHANGES:

TEXT......TEXT-CLASS-STANDARD OWNED ..................... LINE......

THIS IS THE UNIVERSAL TEXT FOR A FIELD WITH THE NAME OF POSTAL-CODE 1THAT DOES NOT HAVE OWNED OR SHARED TEXT 2



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: FIELD DESC:NAME: MAIL.POSTAL-CODE (T1)TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION:DATE-ADDED: 4/3/8 DATE-LAST-CHANGED: 4/3/8 TIME-OF-CHANGE: 11.22.5 NUMBER-OF-CHANGES:

TEXT......TEXT-CLASS-DESCRIPTION OWNED ..................... LINE......

THIS FIELD DESCRIBES THE POSTAL-CODE USED FOR THE MAIL 1FILE. IT IS FIVE CHARACTERS LONG AND IS THE FIRST FIELD IN 2THE FILE. 3


Text Report




TEXT......TEXT-CLASS-STANDARD OWNED ..................... LINE......

THIS IS TEXT THAT DESCRIBES THE FUNCTION OF THE FIELD 1POSTAL-CODE THAT IS OWNED BY VERSION-STATUS T1 2



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: FIELD DESC:NAME: MAIL.POSTAL-CODE (T2)TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION: 1DATE-ADDED: 4/3/8 DATE-LAST-CHANGED: TIME-OF-CHANGE: 11.22.51 NUMBER-OF-CHANGES:

TEXT......TEXT-CLASS-DESCRIPTION SHARED .................... LINE......

THIS FIELD DESCRIBES THE POSTAL-CODE USED FOR THE MAIL 1FILE. IT IS FIVE CHARACTERS LONG AND IS THE FIRST FIELD IN 2THE FILE. 3



User: SAMPLE-USER DD Base: 2ENTITY-TYPE: FIELD DESC:NAME: MAIL.POSTAL-CODE (T2)TESTAUTHOR: DEMO ADMIN CONTROLLER: DEMO ADMIN COPY-VERSION: 1DATE-ADDED: 4/3/8 DATE-LAST-CHANGED: TIME-OF-CHANGE: 11.22.51 NUMBER-OF-CHANGES:

TEXT......TEXT-CLASS-STANDARD SHARED .................... LINE......

THIS IS TEXT THAT DESCRIBES THE FUNCTION OF THE FIELD 1POSTAL-CODE THAT IS OWNED BY VERSION-STATUS T1 2


Text Report




TEXT......TEXT-CLASS-STANDARD UNIVERSAL ................. LINE......

THIS IS THE UNIVERSAL TEXT FOR A FIELD WITH THE NAME OF POSTAL-CODE 1THAT DOES NOT HAVE OWNED OR SHARED TEXT. 2

-------- E N D O F J O B -----------


Text Report

TEXT Report - With ALIGN Option









-RPT TEXT,ELEMENT,ACC.ALL(T1),ALIGN ;-END ;

The ACCTS element of the ACCTS table consists of the order-id;billing date (in YYMMDD format); the order, freight, and discountamounts; and customer identification information.All fields in the ACCTS table are included in this element.


The ORD-ID element of the ACCTS table consists of the single fieldORD-ID (order-id).

NO TEXT DATA FOR ENTITY TYPE..ELEMENT NAME..ORD-ID



-------- E N D O F J O B -----------


Text Report

TEXT Report - STANDARD Path with ALIGN Option









-DEF PATH,STANDARD ;-END ;


Text Report




-RPT START,TABLE,ACCTS(T1),STANDARD ;-RPT INDENT,,ALIGN ;-RPT TEXT,,ALIGN ;-END ;TBL ACCTS T T1

ORDER-ENTRY ACCTS TABLE SYSADM.ACCTS I

The ACCTS table consists of the order-id; billing date (in YYMMDDformat); the order, freight, and discount amounts; and customer identifi-cation information.

KEY ACCTS.CUST-ID-KEY T T1CUST-ID SECONDARY KEY

NO TEXT DATA FOR ENTITY TYPE..KEY NAME..CUST-ID-KEY

KEY ACCTS.ORD-ID-KEY T T1ORD-ID MASTER KEY

NO TEXT DATA FOR ENTITY TYPE..KEY NAME..ORD-ID-KEY ELM ACCTS.ACCTS T T1

ACCTS FULL TABLE ELEMENT

The ACCTS element of the ACCTS table consists of the order-id;billing date (in YYMMDD format); the order, freight, and discountamounts; and customer identification information.All fields in the ACCTS table are included in this element.

ELM ACCTS.CUST-ID T T1 CUST-ID ELEMENT


ELM ACCTS.ORD-ID T T1 ORD-ID ELEMENT

The ORD-ID element of the ACCTS table consists of the single field ORD-ID (order-id).


SYSADM.ORD_ID


Generating Source Language Statements

Generating Source Language Statements

The Source Language Generation (SLG) Facility allows you to reproduce thefield definitions of TABLE, RECORD, KEY, or ELEMENT occurrences ashigh-level language statements suitable for Assembler, COBOL, the CADatacom/DB Reporting Facility, PL/I, or for SQL-compatible copybooks. Youcan only reproduce the field definitions of VIEW occurrences for COBOL.

Datacom View Generator

The Datacom View Generator facility is used to assist in the creation of SQLviews. The facility reads the TABLE sub-structure and generates a viewtemplate containing all of the columns in the table. This template can then beedited to provide the specific SQL views required. Though the template isalways generated as a DATACOM VIEW, the generator can process any tabledefined as eligible for SQL processing.


Using the Source Language Generation


To use the Source Language Generation Facility, you place the appropriatetransactions in the DDUTILTY job stream. This prepares the TABLE, VIEW,RECORD, KEY, or ELEMENT occurrence for inclusion in the appropriatesource library.

The information you include in the transactions is as follows:

■ Informs the Source Language Generation Facility of the library type intowhich the copybooks are to be stored.

■ Instructs the Source Language Generation Facility to generateSQL-compatible copybooks.

■ Indicates the language for which the copybooks are produced.

■ Specifies the name and status/version of the TABLE, VIEW, RECORD,KEY, or ELEMENT occurrence which is to be used to produce thecopybook.

Note: If you have a FIELD occurrence that has the same name as theTABLE occurrence, although the SLG facility generates the appropriatelevel number, you will have duplicate names that can produce errors if youuse the copybook as input.

The utility produces library control cards, copybook member, and a printedreport showing the processing results.

The Source Language Generation statements are documented in the sectionsthat follow in the order you need to code them.

-UTL LIBRARY - Specifying the Library Type

You can use the optional -UTL LIBRARY control statement to inform the SourceLanguage Generation Facility of the library type for which the copybooks areproduced. If this statement is not present, Datadictionary defaults to the librarytype of the operating system (z/OS, or z/VSE) specified at Datadictionaryinstallation. The following is the format for this control statement:

-UTL LIBRARY Transaction

��──-UTL─ ──LIBRARY,library-ident ──────────────────────────────────────────────��

,library-identSpecify the library type for which the copybooks are to be produced.

Entry Library

DR CA Datacom/DB Reporting Facility Library



LIB CA Librarian

OS z/OS Source Statement Library

SRC Operating system source library (z/OS, or z/VSE)

PAN CA Panvalet

SP z/VSE Source Statement Library

Valid Entries: DRLIBOSPANSPSRC

Default Value: Source library of the operating system (z/OS, or z/VSE)specified at Datadictionary installation

-UTL MODE - Specifying SQL-Compatible Copybooks

You can use the optional -UTL MODE control statement to generateSQL-compatible copybooks. If you omit this statement, the Source LanguageGeneration Facility generates copybooks compatible for access by CADatacom/DB commands. If you use this statement, refer to the -UTLLANGUAGE parameters source-label and groupname to specify optionalinformation.

The following is the format for this control statement:

-UTL MODE Transaction

��──-UTL─ ──MODE, ──┬ ┬─SQL────────── ────────────────────────────────────────────�� └ ┘─DATACOM-VIEW─

SQLindicates that SQL Data Definition language statements are to begenerated for the selected occurrence.

DATACOM-VIEWIndicates that the feature is to generate SQL statements defining aDATACOM View based on the selected TABLE odccurrence. IfDATACOM-VIEW is specified, the language must be SQL and theentity-type selected must be TABLE.

Valid Entries: SQLDATACOM-VIEW



-UTL LANGUAGE - Specifying the Language

You can use the optional -UTL LANGUAGE control statement to indicate thelanguage for which the copybooks are produced. You can also use this controlstatement to specify whether comments are desired and the source of thecomments. The following is the format for this control statement:

-UTL LANGUAGE Transaction

��──-UTL──LANGUAGE─ ──┬ ┬───────────────── ──┬ ┬────────── ──┬ ┬─────────────── ──────� └ ┘ ─,language-ident─ └ ┘ ─,comment─ └ ┘ ─,source-label─

�─ ──┬ ┬──────────── ──┬ ┬───── ───────────────────────────────────────────────────�� └ ┘ ─,groupname─ └ ┘ ─SQL─

,language-ident(Optional) Specify the language for which the copybooks are to beproduced. Copybooks can be generated for Assembler (ALC), COBOL,COBOL2, COBOL85, or PL/I. You can also a generate copybooksource-label parameter for the CA Datacom/DB Reporting Facility (DR).

Valid Entries: ALCCOBOLCOBOL2COBOL85DRPLIPL1

Default Value: COBOL

,comment(Optional) Specify if language comments for each FIELD occurrence areto be produced. If the designated source for the comment is blank, nocomment is produced.

Specify COMMENT to use the value in the LANG-COMNT attribute for theFIELD occurrence as the source of the comment.

Specify DESCRIPTION to use the value in the DESCRIPTION attribute forthe FIELD occurrence as the source of the comment.

Specify NONE to generate no comments.

Valid Entries: COMMENTDESCRIPTIONNONE

Default Value: NONE

,source-label(Optional) Use this parameter to specify which name is to be used for theFIELD occurrence.



■ If the language is Assembler and you do not specify -UTLMODE,SQL, you can specify ASSEMBLER to use the FIELDoccurrence Assembler name or accept the default of the FIELDoccurrence Assembler name. If there is not an Assembler name forthe field, it is treated as unlabeled storage.

If the language is Assembler and you specify -UTL MODE,SQL, youcan specify ASSEMBLER, or you can specify SQLNAME to use theFIELD occurrence SQL name, or accept the default of the FIELDoccurrence SQL name.

Valid Entries: ASSEMBLER, SQLNAME (see qualificationspreviously discussed)

Default Value: Assembler name or unlabeled storage, unless -UTLMODE,SQL, then SQLNAME

■ If the language is COBOL and you do not specify -UTL MODE,SQL,you can specify COMPILER, OCCURRENCE, or GENERATE=x. Ifthe language is COBOL and you specify -UTL MODE,SQL, you canspecify COMPILER, OCCURRENCE, GENERATE=x, or SQLNAME.If you accept the default of the FIELD occurrence Compiler name andthere is not a Compiler name, the Datadictionary FIELD occurrencename is used.

– If you specify COMPILER, Datadictionary uses the FIELDoccurrence Compiler name. If there is not a Compiler name,FILLER is used.

– If you specify OCCURRENCE, Datadictionary uses the FIELDoccurrence name.

– If you specify GENERATE=x and do not specify -UTL MODE,SQL,Datadictionary adds the 1- to 27-character value you specify as aprefix to the FIELD occurrence Compiler name. For example, ifyou have fields ABC and XYZ and you specify GENERATE=DEF,Datadictionary creates the field names in the copybook asDEFABC and DEFXYZ.

– If you specify GENERATE=x and specify -UTL MODE,SQL,Datadictionary adds the 1- to 27-character value you specify and 1to 3 digits in sequence for uniqueness to create the field name inthe copybook. For example, if you have fields ABC and XYZ andyou specify GENERATE=DEF, Datadictionary creates the fieldnames in the copybook as DEF1 and DEF2.

– If you specify SQLNAME and -UTL MODE,SQL, Datadictionaryuses the FIELD occurrence SQL name.

Valid Entries: COMPILER, OCCURRENCE, SQLNAME,GENERATE=x (see qualifications previouslydiscussed)

Default Value: Compiler name or Datadictionary FIELD occurrencename



■ If language is specified for the CA-DATACOM/DB Reporting Facility(DR), you can specify ASSEMBLER (to use the FIELD occurrenceAssembler name), COMPILER (to use the Datadictionary FIELDoccurrence Compiler name), or OCCURRENCE (to use theDatadictionary FIELD occurrence name). If an Assembler or Compilername was not defined, the Datadictionary FIELD occurrence name willbe used.

You can accept the default of the Assembler name, or if none, theDatadictionary occurrence name.

Valid Entries: ASSEMBLER, COMPILER, OCCURRENCE

Default Value: Assembler name (or Datadictionary FIELDoccurrence name)

■ If the language is PL/I and you do not specify -UTL MODE,SQL, youcan specify COMPILER or OCCURRENCE. If the language is PL/Iand you specify -UTL MODE,SQL, you can specify COMPILER,OCCURRENCE, SQLNAME, or GENERATE=x. If you accept thedefault of the Compiler name and there is not a Compiler name,Datadictionary uses the FIELD occurrence name.

– If you specify COMPILER, Datadictionary uses the FIELDoccurrence Compiler name. If there is not a Compiler name,Datadictionary uses the word FILLER.

– If you specify OCCURRENCE, Datadictionary uses the FIELDoccurrence name.

– If you specify SQLNAME and -UTL MODE,SQL, Datadictionaryuses the FIELD occurrence SQL name.

– If you specify GENERATE=x and -UTL MODE,SQL, Datadictionaryadds the 1- to 27-character value you specify and 1 to 3 digits insequence for uniqueness to create the field name in the copybook.For example, if you have fields ABC and XYZ and you specifyGENERATE=DEF, Datadictionary creates the field names in thecopybook as DEF1 and DEF2.

Note: Any hyphens used in either a Compiler name or an occurrencename are translated to underscores.

Valid Entries: COMPILER, OCCURRENCE, SQLNAME,GENERATE=x (see qualifications previouslydiscussed)

Default Value: Compiler name or Datadictionary FIELD occurrencename

,groupname(Optional) For COBOL and PL/I SQL-compatible copybooks onlyUse this parameter to specify a name for the group-level item produced inthe copybook.



Valid Entries: 1- to 31-character name beginning with an alphacharacter

Default Value: The table or view SQLNAME attribute-value prefixed byDCL

SQL(Optional) Indicates that SQL Data Definition language statements are tobe generated for the selected occurrence. If SQL is specified, no otherparameter is allowed.

-RPT START - Specifying the Starting Point in the Path

To designate the point along the defined path where processing is to begin, youuse a -RPT START transaction. This transaction must precede the -UTL COPYtransaction if pathing is used. The following is the format for this transaction:

-RPT START — Specifying Starting Point in Path

��──-RPT─ ──START,entity-type ──┬ ┬─,occ-name────────── ──┬ ┬───────────── ──────────� ├ ┤─,rec-name.occ-name─ ├ ┤─(stat)────── └ ┘─,tbl-name.occ-name─ ├ ┤─(stat,ovrd)─ └ ┘─(,ovrd)─────

�─ ──┬ ┬─────────── ─────────────────────────────────────────────────────────────�� └ ┘ ─path-name─

,entity-typeSpecify the entity-type of the occurrence where you want to beginprocessing along the path.

Valid Entries: Any valid entity-type defined as a “from-entity” in thepath definition


,tbl-name. or ,rec-name.If you specified KEY or ELEMENT in the entity-type parameter, you mustspecify the name of the TABLE or RECORD occurrence which containsthe KEY or ELEMENT. Do not use this parameter if you specified TABLEor RECORD in the entity-type parameter.


Your entry must be followed by a period (.) to concatenate the TABLE orRECORD occurrence name with the name of the KEY or ELEMENToccurrence.

Valid Entries: 1- to 32-character occurrence nameGeneric selectionALL

Default Value: ALL



,occ-nameSpecify the name of occurrences on which path processing is to begin.You can enter a generic selection or ALL for all occurrences of thespecified entity-type that meet your other criteria.


Default Value: ALL

(stat)Specify the status/version of the occurrences.

Valid Entries: T001 to T999TEST001 to 999PRODH000 to H997HISTALL

Default Value: ALL

(,ovrd)Specify the override code defined on your system if the occurrence isprotected by Lock Level 2. The override code must be separated fromthe status/version entry by a comma (,).

path-nameSpecify the name of the path from the -DEF PATH transaction.

-UTL COPY - Specifying the Entity-Occurrence

Use the -UTL COPY control statement to specify the name and version of theTABLE, VIEW, RECORD, KEY, or ELEMENT occurrence which is used toproduce the copybook. There is no limit to the number of occurrences whichyou can request in the same run of the Source Language Generation Facility.

Use the following control statement format when you are producing a copybookfor a single occurrence:

-UTL COPY — Specifying Entity-Occurrence

��──-UTL─ ──COPY,entity-type ──┬ ┬─,occ-name────────── ──┬ ┬───────────── ───────────� ├ ┤─,rec-name.occ-name─ ├ ┤─(stat)────── └ ┘─,tbl-name.occ-name─ ├ ┤─(stat,ovrd)─ └ ┘─(,ovrd)─────

�──,member-name───────────────────────────────────────────────────────────────��

You can specify a path if you are producing copybooks for multiple TABLE,VIEW, RECORD, KEY, and ELEMENT occurrences. Use the following controlstatement format when using a path:



-UTL COPY Transaction — Specifying a Path

��──-UTL─ ──COPY,entity-type ──┬ ┬───────────── ─,member-name─────────────────────�� ├ ┤─(stat)────── ├ ┤─(stat,ovrd)─ └ ┘─(,ovrd)─────

,entity-typeSpecify the entity-type of the occurrence for which you are producing thecopybook.

Note: For PL/I processing, if a field in a KEY occurrence has beenredefined, the redefining field is ignored unless it is specifically named asa field in the KEY occurrence. For all other structures containingredefined fields, the redefining fields are extracted and a 01 leveldefinition is generated for each redefining field in the structure.

When -UTL MODE,DATACOM-VIEW is specified, the only validentity-type is TABLE.

Valid Entries: TABLEVIEWRECORDKEYELEMENT


,tbl-name. or ,rec-nameIf you specified KEY or ELEMENT in the entity-type parameter, you mustspecify the name of the RECORD or TABLE occurrence which containsthe KEY or ELEMENT. If you specified TABLE or RECORD in theentity-type parameter, do not use this parameter.


Your entry must be followed by a period (.) to concatenate the RECORDor TABLE occurrence name with the name of the KEY or ELEMENToccurrence.

Valid Entries: Existing RECORD or TABLE occurrence nameGeneric selectionALL


,occ-nameSpecify the name of the TABLE, VIEW, RECORD, KEY, or ELEMENToccurrence which the Source Language Generation Facility is to process.You can enter a generic selection or ALL for all occurrences of thespecified entity-type that meet your other criteria.





(stat)Specify the status/version of the occurrence the Source LanguageGeneration facility is to process.

Valid Entries: T001 to T999TEST001 to 999PRODH000 to H997HISTALL

Default Value: ALL

(,ovrd)Specify the override code defined for your system if the occurrence isprotected by Lock Level 2. The override code must be separated fromthe status/version entry by a comma (,).

,member-nameSpecify the copybook member name.





Defining a Path

You can use more than one occurrence to create a single copybook member.To include multiple occurrences in a copybook, you must define a path to selectthose occurrences which are related. See “Using Predefined Paths” onpage 22.

You can specify STANDARD if you are using the predefined path for theTABLE or RECORD substructure. If you use the STANDARD path, you do notneed to include -DEF TRACE transactions, however, you must designate in the-UTL COPY transaction that processing will start at the TABLE, RECORD,KEY, or ELEMENT occurrence level.

You cannot use STANDARD for a VIEW occurrence. However, you can definea path using SYNONYM occurrence to VIEW occurrence with theSYN-VEW-REFERS relationship. See the CA Datacom/DB SQL User Guide formore information on synonyms and views.

Use the -DEF TRACE transaction to name a pair of related entity-types and therelationship which connects them. You can use -DEF TRACE transactions totrace a path between occurrences related by user-defined relations. Themaximum number of -DEF TRACE transactions allowed in a path definition isset by the MAXLVLS= parameter in the System Resource Table (SRT). Seethe person responsible for administering Datadictionary on your system.

It is possible that your system has user-defined relationships between TABLE,RECORD, KEY, or ELEMENT occurrences. For example, you might havedefined an ordered relationship named BOOK to relate two ELEMENToccurrences for copybook purposes. You can define a path from ELEMENT toELEMENT using the BOOK relationship to produce a copybook containingrelated elements.

Examples

The following example uses the STANDARD path and produces a COBOLcopybook member for all elements contained in a PRODuction status databasenamed ORDER-ENTRY.

-DEF PATH,STANDARD -END -UTL LANGUAGE,COBOL -RPT START,DATABASE,ORDER-ENTRY(PROD),STANDARD -UTL COPY,ELEMENT(ALL),OUT -END

The following example uses a path named PATH1 and produces a COBOLcopybook member for all elements contained in a PRODuction status tablenamed ACCTS-TBL:



-DEF PATH,PATH1 -DEF TRACE,DATABASE.AREA,$INTERNAL -DEF TRACE,AREA.TABLE,$INTERNAL -DEF TRACE,TABLE.ELEMENT,$INTERNAL -END -UTL LANGUAGE,COBOL -RPT START,TABLE,ACCTS-TBL(PROD),PATH1 -UTL COPY,ELEMENT(PROD),ABC -END

In the following example, a user-defined relationship named BOOK has beenimplemented between elements to be combined by the Source LanguageGeneration facility. This relationship is defined as ordered. The first element inthe ordered relationship is ACCTS-REC, which is in PRODuction status.

-DEF PATH,PATH2 -DEF TRACEF,ELEMENT.ELEMENT,BOOK -END -UTL LANGUAGE,COBOL -RPT START,ELEMENT,ACCTS-REC(PROD),PATH2 -UTL COPY,ELEMENT(PROD),ABC -END

The following example uses a path named PATH3 and produces a COBOLcopybook member for all elements related to a PRODuction status dataviewnamed ACCTS-DVW:

-DEF PATH,PATH3 -DEF TRACE,DATAVIEW.ELEMENT,$INTERNAL -END -UTL LANGUAGE,COBOL -RPT START,DATAVIEW,ACCTS-DVW(PROD),PATH3 -UTL COPY,ELEMENT(PROD),ABC -END



Source Language Generation Facility Output

After you run the Source Language Generation facility, Datadictionary producesa report showing the control statements you used and the results of the sourcelanguage generation.

Printed Output

The printed report which is produced lists the input control statements alongwith any errors encountered, followed by a list of the copybooks produced bythe Source Language Generation Facility. This report can help you inconfirming actions taken during copybook production since it shows theresulting data descriptions.

Punched Output

The copybook punched by DDUTILTY contains control statements appropriatefor adding the data description statements directly to the specified library. Thefollowing table shows the arrangements for supported library types:

Library Punched Output

z/OSLIBRARY=OS

./ ADD NAME=namedata description statements generated

CA LibrarianLIBRARY=LIB

-ADD namedata description statements generatedEMOD

z/VSELIBRARY=SP

CATALOG member-name.ldata description statements generated /+

CA PanvaletLIBRARY=PAN

++ADD namedata description statements generated

CA Datacom/DBReporting FacilityLIBRARY=DR

LOAD namedata description statements generated



CATALOG Statement for z/VSE

In the case of the z/VSE source statement library, the control statementgenerated must identify the language sublibrary in which the module will reside.Following is the format of the CATALOG statement for z/VSE.

CATALOG Statement (z/VSE)

��──CATALOG──member-name.sublibrary───────────────────────────────────────────��

member-nameSpecify the copybook member name.



sublibrarySpecifies the language sublibrary where the module will reside. You canspecify COBOL (C), PL/I (P), Assembler (P), or CA Datacom/DB ReportingFacility (D).

Valid Entries: A, C, D, or P

Default Value: C

The punched output also contains any records that you provided with theSystem Resource Table (SRT) parameter UTLPRE= in the input transactionstream.

You can include the generated copybook in a stream of relevant job controlstatements to place the copybook in the appropriate source statement library.

Level Numbers: Datadictionary, through the compound field feature in theFIELD entity-type, allows group items to be readily defined. The utilityreproduces the groupings, automatically assigning level numbers as appropriatefor the language.

The starting level number and increment are System Resource Table (SRT)installation options for the DDSYSTBL macro. The copybook generated startswith the first entry at the level set by the CPYLVST= parameter of the SystemResource Table. All subsequent level numbers are incremented by the valuespecified in the CPYLVIN= parameter.

Levels are indented by four positions, unless the maximum number ofindentation levels set by the CPYNDLM= parameter of the System ResourceTable is reached or the capacity of the output statements is exceeded.



CA Datacom/DB Reporting Facility Considerations

Two factors require your special consideration when generating datadescriptions for the CA Datacom/DB Reporting Facility. These factors arereport headings and controlling beginning displacement.

Report Headings

Data description statements define the headings used in the reports producedby the Reporting Facility. You can specify none, one, or two report headinglines for each data description statement. The specifications are supported bythe Source Language Generation facility using the HEADING-1 andHEADING-2 attribute-values of the FIELD entity.

Controlling Beginning Displacement

The syntax of the Reporting Facility data description statements requires thatthe beginning and ending displacements of each field be defined. Since therecord I/O z/OS area used to request CA Datacom/DB access includes a300-byte reserved area, the data area for CA Datacom/DB starts at position301. For Reporting Facility members not used for CA Datacom/DB access, thecopybook is automatically started at a displacement of 001.




z/OS Example JCL:

You can use the following sample JCL for Source Language Generation Facilityexecution:


//jobname See the note above and page 19. // EXEC PGM=DDUTILTY,REGION=6K //STEPLIB See the note above and page 19. //SYSPRINT DD SYSOUT=a Print output //SYSPUNCH DD SYSOUT=b Punch output//SNAPER DD SYSOUT=a CA Datacom/DB dumps //SYSDUMP DD SYSOUT=a System dumps //SYSIN DD Input transactions -USR SAMPLE-USER Authorized user information -UTL LIBRARY,OS Library type -COM PLACE THE OTHER CONTROL TRANSACTIONS HERE . . . . /

z/VSE Example JCL:

You can use the following sample JCL for Source Language Generation Facilityexecution.


$$ JOB ... See the note above and page 19. $$ LST ... // JOB name // EXEC PROC=procname Whether you use PROCs or LIBDEFs, see page 19. // EXEC DDUTILTY,SIZE=6K-USR SAMPLE-USER Authorized user information

-UTL LIBRARY,SP Library type -COM PLACE THE OTHER CONTROL TRANSACTIONS HERE. . . . . / /& $$ EOJ



Sample Transactions: COBOL -UTL LANGUAGE,COBOL,NONE -UTL COPY,TABLE,CUST(PROD),CUST-TBL -END

Sample Generated COBOL Copybook









-UTL LIBRARY,OS ;




-UTL LANGUAGE,COBOL ;






-UTL COPY,TABLE,CUST(PROD),CUST-TBL ; -END ; ./ ADD NAME=CUST-TBL 2 CUST. 3 CUST-ID. 4 IND-CD PICTURE X(1). 4 CUST-NO PICTURE X(4). 3 NAME PICTURE X(3). 3 ADDR-1 PICTURE X(3). 3 ADDR-2 PICTURE X(3). 3 CITY PICTURE X(15). 3 STATE PICTURE X(2). 3 ZIP PICTURE X(9). 3 CRED-IND PICTURE X(1). 3 PHONE. 4 AREA-CD PICTURE X(3). 4 PH-EXCH PICTURE X(3). 4 PH-NO PICTURE X(4). 3 OPEN-$ PICTURE S9(7)V9(2) COMPUTATIONAL-3. 3 YTD-SALES PICTURE S9(7)V9(2) COMPUTATIONAL-3. 3 ACT-DT. 4 ACT-YR PICTURE X(2). 4 ACT-MO PICTURE X(2). 4 ACT-DAY PICTURE X(2). 3 SLMN-ID PICTURE X(5).

END OF JOB



Sample Transactions: PL/I -UTL LANGUAGE,PL1,NONE -UTL COPY,RECORD,CUST(PROD),CUST-TBL -END

Sample Generated PL/I Copybook









-UTL LIBRARY,OS ;




-UTL LANGUAGE,PL1 ;






-UTL COPY,TABLE,CUST(PROD),CUST-TBL ; -END ; ./ ADD NAME=CUST-TBL 2 CUST, 3 CUST_ID, 4 IND_CD CHAR(1), 4 CUST_NO CHAR(4), 3 NAME CHAR(3), 3 ADDR_1 CHAR(3), 3 ADDR_2 CHAR(3), 3 CITY CHAR(15), 3 STATE CHAR(2), 3 ZIP CHAR(9), 3 CRED_IND CHAR(1), 3 PHONE, 4 AREA_CD CHAR(3), 4 PH_EXCH CHAR(3), 4 PH_NO CHAR(4), 3 OPEN_$ FIXED(9,2), 3 YTD_SALES FIXED(9,2), 3 ACT_DT, 4 ACT_YR CHAR(2), 4 ACT_MO CHAR(2), 4 ACT_DAY CHAR(2), 3 SLMN_ID CHAR(5),

END OF JOB



Sample Transactions: SQL -UTL MODE,SQL -UTL COPY,TABLE,JOHN-EMPTBL,EMPLTBL -END

Note: In this example, the -UTL LANGUAGE statement was not included, thesystem used the defaults.

Sample Generated SQL Copybook




:/ ADD NAME=EMPLTABL 2 DCLEMPTBLE. 3 EMPNUM PIC X(5). 3 NAME PIC X(18). 3 JOB-CODE PIC X(2). 3 CITY PIC X(8). 3 STATE PIC X(2).

3 SALARY PIC S9(5) COMP-3.3 YTD-COMM PIC S9(7) COMP-3.3 YTD-COMM-NI PIC S9(4) COMP.

3 DEPT PIC X(2). 3 M-STAT PIC X(1).

3 M-STAT-NI PIC S9(4) COMP.3 PHONE PIC S9(11) COMP-3.3 PHONE-NI PIC S9(4) COMP.

3 STATUS PIC X(1). END OF JOB



Sample Transactions: Assembler -UTL LANGUAGE,ASM,NONE -UTL COPY,RECORD,CUST(PROD),CUST-TBL -END

Sample Generated Assembler Copybook









-UTL LIBRARY,OS ;




-UTL LANGUAGE,ALC ;






-UTL COPY,TABLE,CUST(PROD),CUST-TBL ; -END ; ./ ADD NAME=CUST-TBL DS CL153 DS CL5 DS CL1 DS CL4 DS CL3 DS CL3 DS CL3 DS CL15 DS CL2 DS CL9 DS CL1 DS CL1 DS CL3 DS CL3 DS CL4 DS PL5 DS PL5 DS CL6 DS CL2 DS CL2 DS CL2 DS CL5

END OF JOB

Note: The TABLE occurrence used for this example has noASSEMBLER-NAME attribute-values.



Sample Transactions: CA Datacom/DB Reporting Facility -UTL LANGUAGE,DR,NONE -UTL COPY,RECORD,CUST(PROD),CUST-TBL -END

Sample Generated CA Datacom/DB Reporting Facility Copybook









-UTL LIBRARY,OS ;




-UTL LANGUAGE,DR ;






-UTL COPY,TABLE,CUST(PROD),CUST-TBL ; -END ; ./ ADD NAME=CUST-TBL DEF CUST 31-453 X DEF CUST-ID 31-35 X 'CUSTOMER' 'ID' DEF IND-CD 31-31 X 'INDUSTRY' 'CODE' DEF CUST-NO 32-35 X 'CUSTOMER' 'NUMBER' DEF NAME 36-335 X 'CUSTOMER' 'NAME' DEF ADDR-1 336-365 X 'ADDRESS' DEF ADDR-2 366-395 X DEF CITY 396-41 X 'CITY' DEF STATE 411-412 X 'STATE' DEF ZIP 413-421 X 'ZIP' DEF CRED-IND 422-422 X 'CREDIT' 'INDICATOR' DEF PHONE 423-432 X 'PHONE' 'NUMBER' DEF AREA-CD 423-425 X DEF PH-EXCH 426-428 X DEF PH-NO 429-432 X F OPEN-$ 433-437 P2 'OPEN' 'DOLLARS' PIC 'Z,ZZZ,ZZ9.99' DEF YTD-SALES 438-442 P2 'YEAR TO DATE' 'SALES' PIC 'Z,ZZZ,ZZ9.99' DEF ACT-DT 443-448 X 'ACTIVITY' 'DATE' DEF ACT-YR 443-444 X 'ACTIVITY' 'YEAR' DEF ACT-MO 445-446 X 'ACTIVITY' 'MONTH' DEF ACT-DAY 447-448 X 'ACTIVITY' 'DAY' DEF SLMN-ID 449-453 X 'SALESMAN' 'ID'

END OF JOB



Output from the Datacom View Generator

Output from the Datacom View Generator is a printed copy of the generatedstatements (120 characters wide) and a set of records (80 columns wide)suitable for input to the selected library format. The format of these statementsis described as follows, based on the following z/OS example output.Characters in bold type in the example are generated as shown. Non-boldtype characters in the example are generated either based on the inputstatements or the TABLE definition being processed.

z/OS Example Output for the Datacom View Generator:

1. ./ ADD member-name2. CREATE DATACOM VIEW

3. view-name 4. ( 5. column 1, 6. column 2, 7. . 8. . 9. . 1. column_redefined, 11. . 12. . 13. . 14. -- START REDEFINE: column_redefines 15. -- REDEFINES: column_redefined 16. column_redefines, 17. . 18. . 19. . 2. -- END REDEFINE: column_redefines 21. -- REDEFINES: column_redefined 22. . 23. . 24. . 25. -- START ARRAY: column_occurring 26. column_occurring_1, 27. column_occurring_2, 28. . 29. . 3. . 31. column_occurring_nn, 32. -- END ARRAY: column_occurring 33. column_n 34. ) 35. AS 36. SELECT 37. column_1, 38. column_2, 39. column_redefined, 4. . 41. . 42. . 43. column_redefines, 44. .



45. . 46. . 47. column_occurring[1], 48. column_occurring[2], 49. . 5. . 51. . 52. column_occurring[nn], 53. column_n 54. FROM 55. table_name 56. WHERE Enter WHERE clause here to clarify redefines 57. ;

Line 1Line 1 contains the library control statement based upon the -UTLLIBRARY input statement and the member-name specified on the -UTLCOPY statement.

Line 2Line 2 is the beginning of the SQL CREATE statement. For moreinformation about DATACOM VIEWS, see the information aboutDATACOM VIEWS in the CA Datacom/DB SQL User Guide.

Line 3On line 3, the view-name is the fully qualified name in SQL(authid.sqlname) and is derived from the TABLE occurrence specifiedeither in the -UTL COPY statement or in the currently anchored tablewhen using path processing. The authorization ID (authid) used isobtained from the AUTHID attribute of the referenced TABLE occurrence.The SQL name (sqlname) is generated using the SQLNAME attribute ofthe table and appending “_VIEW” after it. No attempt is made to limit thesqlname to the maximum SQL Name length of 32 characters. If thegenerated SQL name is greater than 32 characters, a comment line isgenerated as follows:

-- GENERATED SQL NAME GREATER THAN 32 CHARACTERS

Line 4On line 4, the open parenthesis marks the beginning of the column-list forthe view.

Line 5 - line 9Lines 5 through 9 are “normal” columns that do not require any specialhandling.

Line 10 - line 13Lines 10 through 13 are columns that are redefined by a later column(column_redefined) and intervening columns, up to the redefining column(column_redefining). These columns can be consecutive with nointervening columns. The redefined column can be a single-dimensionarray or a group column with columns under it that are themselvessingle-dimension arrays, in which case the columns would be also notedand constructed as one or more arrays (see Lines 22 through 29).



Line 14 - line 15Lines 14 and 15 are comment lines in the comment format for the SQLStatement Processor (DBSQLPR). They mark the beginning of theredefinition of the column named column_redefined by the column namedcolumn_redefines.

Line 16 - line 19Lines 16 through 19 contain the column(s) that redefine the earlier column(column_redefined). The redefining column can be a single-dimensionarray or a group column with columns under it that are themselvessingle-dimension arrays, in which case the columns would also be notedand constructed as one or more arrays (see lines 22 through 29).

Line 20 - line 21Lines 20 and 21 are comment lines in the comment format for the SQLStatement Processor (DBSQLPR). They mark the end of the redefinitionof the column named column_redefined by the column namedcolumn_redefines.

Line 22 - line 24Lines 22 through 24 are “normal” columns that do not require any specialhandling.

Line 25Line 25 is a comment line in the comment format for the SQL StatementProcessor (DBSQLPR). It marks the beginning of a single-dimensionarray (column_occurring). Only single-dimension arrays are supported ina DATACOM VIEW.

Line 26 - line 31Lines 26 through 31 provide individual columns for each entry in asingle-dimension array with nn entries. The SQL name is generated byappending the SQL Name of the column with an underscore, followed bythe relative number of the entry. The number has the number ofcharacters necessary to support the highest numbered array member.For example, if the REPEAT attribute-value is 2 - 9, the number requiresonly one character, but two characters are required if the REPEATattribute-value is 10 - 99. The numerals are right justified and leadingzeros are used when the length is more than one character (for example,_01, _02, and so on). No attempt is made to limit this name to themaximum SQL Name length of 32 characters. If the generated SQLname is greater than 32 characters, a comment line is generated for thefirst column in the array as follows:

-- BEGIN GENERATED SQL NAMES GREATER THAN 32 CHARACTERS

Another comment line is generated after the last column in the array asfollows:

-- END GENERATED SQL NAMES GREATER THAN 32 CHARACTERS

Line 32Line 32 is a comment line in the comment format for the SQL StatementProcessor (DBSQLPR). It marks the end of a single-dimension array



(column_occurring). Only single-dimension arrays are supported in aDATACOM VIEW.

Line 33Line 33 is a “normal” column that does not require any special handling.

Line 34On line 34, the closed parenthesis marks the end of the column-list for theview.

Line 35 - line 36Lines 35 and 36 contain the SQL syntax to begin the SELECT from thetable that generates the data for the view.

Line 37 - line 53Lines 37 through 53 are the selected columns from the table. They matchup in sequence with the column list of the CREATE DATACOM VIEW.

The column SQL names are the same as the SQL names in the columnlist, except in the case of arrays, where the -nn- designation is generated,instead of the _nn designation that is used in the view column list.

Line 54Line 54 contains the SQL syntax to specify the table for which the view isbeing generated.

Line 55On line 55, the table-name is the fully qualified name in SQL(authid.sqlname). The authid and sqlname used are from the AUTHIDand SQLNAME attributes, respectively, of the TABLE occurrence specifiedeither in the -UTL COPY statement or in the currently anchored tablewhen using path processing.

Line 56Line 56 is generated only if there are one or more instances of aredefinition within the table structure. If the final view to be processed bySQL after editing contains a redefinition, the WHERE clause must becompleted to ensure that only the rows matching the redefinition data areselected.

Line 57Line 57 the semicolon (;) is generated to specify the end of the CREATEDATACOM VIEW statement.



Additional Comment Lines

There are certain structures that are not supported by DATACOM VIEWs.When one of those structures are encountered, the following comment lines aregenerated, where nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn is the SQLNAME ifpresent or the Datadictionary entity-occurrence name if no SQLNAME isavailable:

-- COLUMN nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn NOT GENERATED.

Following is another example comment line:

-- REASON: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In the example comment line just shown, thexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is one of the following:

■ COLUMN IS FILLER

This indicates that the column has a CLASS attribute-value of “F.”

■ COLUMN IS VALUE

This indicates that the column has a CLASS attribute-value of “V.”

■ COMPOUND ARRAY

This indicates that the column is the Child of a column with REPEATattribute-value value greater than 1.

Example Table Definition in COBOL: The following example table definitionin COBOL format defines a table with two row types. Those of type 'C' definecourses with the course description. Those of type 'S' define the individualstudents in the courses, with allowance for up to 20 numeric grades.

2 COURSE-TABLE. 3 RECORD-TYPE PIC X(1). 88 REC-C VALUE 'C'. 88 REC-S VALUE 'S'. 3 COURSE-TITLE PIC X(2). 3 COURSE-DESC PIC X(1). 3 STUDENT-DATA REDEFINES COURSE-DESC. 4 STUDENT-NAME PIC X(3). 4 STUDENT-SSN PIC 9(1). 4 STUDENT-GRDS

OCCURS 2 TIMES PIC 9(3).

Following the example definitions just shown, an example of the transactioninput to the batch utility is as follows. For the purposes of this sample, theCOBOL names and the Datadictionary entity-occurrence names are the same.

+UTL LIBRARY,OS +UTL LANGUAGE,SQL +UTL MODE,DATACOM-VIEW +UTL COPY,TABLE,COURSES(T1),COURSES



An example of the resulting output follows:

./ ADD NAME=COURSESCREATE DATACOM VIEW

SYSUSR.COURSES_VIEW ( COURSE_TABLE, RECORD_TYPE, -- COLUMN REC_C NOT GENERATED. -- REASON: COLUMN IS VALUE -- COLUMN REC_S NOT GENERATED. -- REASON: COLUMN IS VALUE COURSE_TITLE, COURSE_DESC, -- START REDEFINE: STUDENT_DATA -- REDEFINES: COURSE-DESC STUDENT_DATA, STUDENT_NAME, STUDENT_SSN, -- START ARRAY: STUDENT_GRDS STUDENT_GRDS_1, STUDENT_GRDS_2, STUDENT_GRDS_3, . . . STUDENT_GRDS_18, STUDENT_GRDS_19, STUDENT_GRDS_2 -- END ARRAY: STUDENT_GRDS ) AS SELECT COURSE_TABLE, RECORD_TYPE, COURSE_TITLE, COURSE_DESC, STUDENT_DATA, STUDENT_NAME, STUDENT_SSN, STUDENT_GRDS[1], STUDENT_GRDS[2], STUDENT_GRDS[3], . . . STUDENT_GRDS[18], STUDENT_GRDS[19], STUDENT_GRDS[2] FROM SYSUSR.COURSES

WHERE Enter WHERE clause here to clarify redefines ;

Once edited, the foregoing would yield two DATACOM VIEWs, the first forcourses and the second for students, as shown in the following examples:

Datacom View 1 (Courses):



CREATE DATACOM VIEW SYSUSR.COURSE_LIST ( RECORD_TYPE, COURSE_TITLE, COURSE_DESC ) AS SELECT RECORD_TYPE, COURSE_TITLE, COURSE_DESC FROM SYSUSR.COURSES

WHERE RECORD_TYPE = 'C' ;

Datacom View 2 (Students): CREATE DATACOM VIEW SYSUSR.STUDENT_LIST ( RECORD_TYPE, COURSE_TITLE, STUDENT_DATA, STUDENT_NAME, STUDENT_SSN, STUDENT_GRDS_1, STUDENT_GRDS_2, STUDENT_GRDS_3, . . . STUDENT_GRDS_18, STUDENT_GRDS_19, STUDENT_GRDS_2 ) AS SELECT RECORD_TYPE, COURSE_TITLE, STUDENT_DATA, STUDENT_NAME, STUDENT_SSN, STUDENT_GRDS[1], STUDENT_GRDS[2], STUDENT_GRDS[3], . . . STUDENT_GRDS[18], STUDENT_GRDS[19], STUDENT_GRDS[2] FROM SYSUSR.COURSES

WHERE RECORD_TYPE = 'S' ;




Appendix A. Sample User-Written Exitfor DDBTGLM (COBOL)

The following sample program is a user exit written for the Batch TransactionGenerator utility (DDBTGLM). The program retrieves all the dataviews andtheir related elements for a particular database. The transactions to be usedwith the user exit are as follows:

-USR user-name,user-password -DEF PATH,DVWTOELM -DEF TRACE,DATABASE.AREA,$INTERNAL,SKIP -DEF TRACE,AREA.TABLE,$INTERNAL,SKIP -DEF TRACE,TABLE.ELEMENT,$INTERNAL,SKIP -DEF TRACE,ELEMENT.DATAVIEW,$INTERNAL -DEF TRACE,DATAVIEW.ELEMENT,$INTERNAL -END -BTG USER=pgm-name -BTG START,DATABASE,occ-name(vrs),DVWTOELM -END

In the transaction collection:

pgm-name The name of load module for the exit program.

occ-name The name of the database occurrence.

vrs The status/version of the database.

This program causes the 1003 RELT transactions to be suppressed for theactual add of the dataview itself. It also causes any duplicate sets oftransactions for either a dataview or its associated elements to be suppressed.

Appendix A. Sample User-Written Exit for DDBTGLM (COBOL) 595

User-Written Exit for DDBTGLM (COBOL): DDBTGLM - SAMPLE USER EXIT - COBOL IDENTIFICATION DIVISION. SKIP3 PROGRAM-ID. DDBTGEX1. SKIP1 AUTHOR. ALEXANDER PATCHES SKIP1 DATE-WRITTEN. JUNE,28 SKIP2 ENVIRONMENT DIVISION. SKIP1 CONFIGURATION SECTION. SKIP1 SOURCE-COMPUTER. IBM-37. SKIP1 OBJECT-COMPUTER. IBM-37. SKIP1 INPUT-OUTPUT SECTION. SKIP1 FILE-CONTROL. SKIP1 DATA DIVISION. SKIP1 FILE SECTION. SKIP1 WORKING-STORAGE SECTION. SKIP2 1 BTG- PIC S9 COMP VALUE +.

1 BTG-NDX PIC S999 COMP VALUE +1. 1 BTG-TBL-SW PIC X VALUE SPACE. 88 BTG-ADD-OCCURANCE VALUE 'A'. 88 BTG-NEW-SET VALUE 'N'. 88 BTG-DUP-SET VALUE 'D'. 88 BTG-SUPRESS VALUE 'S'. 1 BTG-TBL-END-SW PIC X VALUE SPACE. 88 BTG-TBL-END VALUE 'Y'. 1 BTG-FIRST-TIME-SW PIC X VALUE SPACE. 88 FIRST-TIME VALUE 'Y'. 1 BTG-SUPRESS-NEXT PIC X VALUE SPACE. 88 SUPRESS-THIS-ONE VALUE 'Y'. 1 WS-BTG-TBL. 12 WS-BTG-DVW-TBL.

16 WBDT-OCCURANCE-TBL OCCURS 5 TIMES. 2 WBDT-DVW-OCCURANCE PIC X(32).

1 WS-TBL-INIT PIC X(16) VALUE SPACES. LINKAGE SECTION. 1 CARD-BUFFER. 3 CARD-TYPE.


5 CARD-FIRST PIC X. 5 FILLER PIC X(3). 3 FILLER PIC X(76).

1 CD-CARD REDEFINES CARD-BUFFER. 3 CD-HEADER-TYPE PIC X(13). 3 FILLER PIC X(67).

1 CD-13-CARD REDEFINES CARD-BUFFER. 3 CD-CARD-RELT PIC X(18). 3 FILLER PIC X(62). 1 HEADER-BUFFER. 3 HD-HEADER-TYPE. 5 HD-TRAN-TYPE PIC X(4). 5 FILLER PIC X. 5 HD-TRAN-ENTITY PIC X(8). 3 FILLER PIC X. 3 HD-DVW-OCCURANCE PIC X(32). 3 FILLER PIC X(114). EJECT

PROCEDURE DIVISION USING CARD-BUFFER HEADER-BUFFER. SKIP3

IF FIRST-TIMEMOVE WS-TBL-INIT TO WS-BTG-DVW-TBLMOVE 'N' TO BTG-FIRST-TIME-SW.

IF CARD-TYPE = ''GO TO END-RETURN.

IF HD-HEADER-TYPE = '-BTG DATAVIEW' PERFORM BTG-SET-SWITCH.

IF HD-HEADER-TYPE = '-BTG ELEMENT,'GO TO BTG-PROCESS-SET.

GO TO END-RETURN. BTG-SET-SWITCH.

IF BTG-TBL-SW IS EQUAL TO SPACEMOVE SPACE TO BTG-TBL-END-SW

PERFORM CHECK-TBL-DATAVIEW-OCCURANCEVARYING BTG-NDX FROM 1 BY 1

UNTIL BTG-TBL-END.GO TO BTG-PROCESS-SET.

BTG-PROCESS-SET. IF BTG-ADD-OCCURANCE PERFORM BTG-SET-ADD ELSE IF BTG-NEW-SET PERFORM BTG-PROCESS-NEW ELSE IF BTG-DUP-SET PERFORM BTG-SET-DUP ELSE IF BTG-SUPRESS PERFORM BTG-PROCESS-DUP.

GO TO END-RETURN.

CHECK-TBL-DATAVIEW-OCCURANCE.IF BTG-NDX GREATER 5DISPLAY 'TABLE OVERFLOW - MORE THAN 5 DVW OCCURANCES'EXHIBIT NAMED BTG-NDXMOVE 'Y' TO BTG-TBL-END-SW

Appendix A. Sample User-Written Exit for DDBTGLM (COBOL) 597

COMPUTE BTG-NDX = BTG-NDX / BTG- ELSE

IF HD-DVW-OCCURANCE = WBDT-DVW-OCCURANCE (BTG-NDX)MOVE 'Y' TO BTG-TBL-END-SWMOVE 'D' TO BTG-TBL-SW

ELSEIF WBDT-DVW-OCCURANCE (BTG-NDX) = LOW-VALUES

MOVE 'Y' TO BTG-TBL-END-SWMOVE 'A' TO BTG-TBL-SW

ELSEIF WBDT-DVW-OCCURANCE (BTG-NDX) = SPACES

MOVE 'Y' TO BTG-TBL-END-SWMOVE 'A' TO BTG-TBL-SW.

BTG-SET-ADD.COMPUTE BTG-NDX = BTG-NDX - 1MOVE HD-DVW-OCCURANCE TO WBDT-DVW-OCCURANCE (BTG-NDX)MOVE 'N' TO BTG-TBL-SWGO TO END-RETURN.

BTG-SET-DUP.MOVE 'S' TO BTG-TBL-SWMOVE LOW-VALUES TO CARD-FIRSTGO TO END-RETURN.

BTG-PROCESS-NEW.

IF HD-HEADER-TYPE = '-BTG DATAVIEW'IF CD-CARD-RELT = '13 RELT,ELEMENT,'

MOVE LOW-VALUES TO CARD-FIRSTMOVE 'Y' TO BTG-SUPRESS-NEXTGO TO END-RETURN

ELSEIF CARD-TYPE = '13'

MOVE LOW-VALUES TO CARD-FIRSTGO TO END-RETURN

ELSE IF SUPRESS-THIS-ONE

MOVE LOW-VALUES TO CARD-FIRSTMOVE SPACE TO BTG-SUPRESS-NEXTGO TO END-RETURN

ELSEIF CD-HEADER-TYPE = '-BTG DATAVIEW'

MOVE SPACE TO BTG-TBL-SWGO TO BTG-SET-SWITCH.

GO TO END-RETURN.

BTG-PROCESS-DUP.IF CD-HEADER-TYPE = '-BTG DATAVIEW'

MOVE SPACE TO BTG-TBL-SWGO TO BTG-SET-SWITCH.

MOVE LOW-VALUES TO CARD-FIRSTGO TO END-RETURN.

END-RETURN. GOBACK. EJECT


Appendix B. Sample User-Written Exitsfor DDRMFLM (Assembler)

This appendix contains the following topics:

Input User-Written Exit for DDRMFLM . . . . . . . . . . . . . . . . . . . . . 600Output User-Written Exit for DDRMFLM . . . . . . . . . . . . . . . . . . . . 602

The following sample user-written exits can be used with Chapter 5,“DDRMFLM - Converting Field Definitions” on page 125. The first exit pointallows a user-written program to gain control after each record has been readfrom the input file and before the conversion takes place. See the followingInput User-Written Exit.

With the second exit point, you can direct the Record Migration Facility to passcontrol to a user-written program after each record conversion takes place andbefore the converted record is written to the output sequential file. See “OutputUser-Written Exit for DDRMFLM” on page 602.

Appendix B. Sample User-Written Exits for DDRMFLM (Assembler) 599

Input User-Written Exit for DDRMFLM


--------------------------------------------------------------------- D D R X 1 P R - GENERAL PROGRAM DESCRIPTION THIS PROGRAM IS A SAMPLE ALC USER EXIT CALLED BY THE RECORD MIGRATION FACILITY (DDRMFLM). THE EXIT IS CALLED AFTER A RECORD HAS BEEN READ FROM RMFIN, BUT BEFORE THE MIGRATION TO THE NEW RECORD FORMAT HAS TAKEN PLACE. THEREFORE, THE RECORD'S FIELDS STILL HAVE THE TYPE, LENGTH, AND DISPLACEMENT ATTRIBUTES DEFINED IN THE "INPUT" DEFINITION. THE USER CAN INSPECT THE INPUT RECORD AT THIS POINT AND ALTER DATA VALUES IN EXISTING FIELDS OR INSTRUCT RMF TO SKIP THE RECORD. --------------------------------------------------------------------- LINKAGE - STANDARD IBM LINKAGE WITH R1 CONTAINING ADDR OF PARM LIST. PARM 1: ADDR OF BUFFER CONTAINING INPUT RECORD. PARM 2: ADDR OF BUFFER CONTAINING OUTPUT RECORD (FOR USE OF USER EXIT 2 - CHANGES TO THIS BUFFER IN USER EXIT 1 WILL BE IGNORED.) PARM 3: ADDR OF A 119 CHARACTER BUFFER WHERE THE USER CAN PLACE A MESSAGE TO BE PRINTED BY RMF. PARM 4: ADDR OF A FULL-WORD AREA FOR THE RETURN CODE RETURN CODES - ASSOCIATED RMF ACTION RC = - NORMAL RETURN - CONTINUE PROCESSING RC > - PRINT ANY MESSAGE IN MESSAGE AREA RC = 4 - SKIP RECORD AND PRINT ANY MESSAGE IN MESSAGE AREA RC > 4 - TERMINATE RUN AND PRINT ANY MESSAGE IN MESSAGE AREA --------------------------------------------------------------------- REGISTER USAGE STANDARD IBM REGISTER CONVENTIONS APPLY. R13 POINTS TO AN 18 WORD SAVE AREA WHERE THE CALLING PROGRAM'S REGISTERS SHOULD BE SAVED. THE CALLING PROGRAM'S REGISTERS MUST BE RESTORED BEFORE RETURNING. ANY ROUTINES CALLED FROM THIS SUBROUTINE ARE THE RESPONSIBILITY OF THE USER. --------------------------------------------------------------------- NAMING CONVENTIONS THE USER EXIT LOAD MODULE MAY HAVE ANY NAME THE USER CHOOSES. THE LOAD MODULE NAME IS MADE KNOWN TO DDRMFPR ON THE -RMF OPTIONS CONTROL CARD. --------------------------------------------------------------------- SAMPLE USER EXIT SOURCE CODE USERS SHOULD FEEL FREE TO PLAGARIZE THE FOLLOWING CODE TO MEET THEIR PARTICULAR NEEDS. GOOD RESULTS CAN BE ACHIEVED BY COPYING THE ENTRY AND EXIT CODE VERBATIM AND MODIFYING THE CODE BETWEEN THE ASTERISKS TO MEET INDIVIDUAL USER REQUIREMENTS. --------------------------------------------------------------------- EJECT--------------------------------------------------------------------- PROGRAM ENTRY CODE ---------------------------------------------------------------------DDRX1PR CSECT (USER MAY USE ANY NAME IN PLACE OF DDRX1PR)

STM 14,12,12(13) SAVE CALLING PROGRAM'S REGISTERSBALR 12, LOAD R12 WITH ADDR OF NEXT INST



USING ,12 NAME R12 AS BASE REGISTERST 13,SAV+4 SAVE CALLING PROGRAM'S R13LA 13,SAV POINT R13 AT THIS PROGM'S SAVE AREALM 3,6,(1) R3 = ADDR OF INPUT RECORD

R4 = NOT USED IN USER EXIT 1 R5 = ADDR OF RMF MESSAGE AREA R6 = ADDR OF RETURN CODE AREA------------ REPLACE FOLLOWING SAMPLE CODE AS DESIRED --------------- SAMPLE USER EXIT TO SKIP RECORDS WITH A FIRST FIELD OF C'ABC' AND ALTER ALL WITH A FIRST FIELD OF C'XYZ' TO 'YYZ'. ------------ REPLACE FOLLOWING SAMPLE CODE AS DESIRED ---------------

LA 15, DEFAULT RETURN CODECLC (3,3),=C'ABC' Q-RECORD FIRST FIELD = ABC

BE RX1PR1 Y-SKIP ITCLC (3,3),=C'XYZ' Q-RECORD FIRST FIELD = YYZ

BE RX1PR2 Y-ALTER ITB RX1PRX THAT'S ALL FOR THIS CARD

SPACE 1RX1PR1 DS H

MVC (L'SKIPMSG,5),SKIPMSG SET SKIPPED RECORD MESSAGELA 15,4 SET SKIP RECORD RETURN CODEB RX1PRX THAT'S ALL FOR THIS CARD

SPACE 1RX1PR2 DS H

MVI (3),C'Y' ALTER THE RECORDMVC (L'ALTERMSG,5),ALTERMSG SET ALTERED RECORD MESSAGELA 15,1 SET DISPLAY MESSAGE RETURN CODEB RX1PRX THAT'S ALL FOR THIS CARD

SPACE 1------------ REPLACE PRECEDING SAMPLE CODE AS DESIRED ------------------------------------------------------------------------------------ PROGRAM EXIT CODE ---------------------------------------------------------------------RX1PRX DS H

ST 15,(6) SET RETURN CODEL 13,SAV+4 RESTORE CALLING PROGRAM'S R13LM 14,12,12(13) RESTORE CALLING PROGRAM'S REGISTERSLA 15, ZERO R15 FOR VPE INTERFACEBR 14 RETURN TO CALLER

SPACE 1SKIPMSG DC C'SKIPPED AN INPUT RECORD'ALTERMSG DC C'ALTERED AN INPUT RECORD' SPACE 1SAV DS 18F THIS ROUTINE'S SAVE AREA (USED IF THIS ROUTINE CALLS ANY USER-WRITTEN SUBROUTINES) END


Output User-Written Exit for DDRMFLM


--------------------------------------------------------------------- D D R X 2 P R - GENERAL PROGRAM DESCRIPTION THIS PROGRAM IS A SAMPLE ALC USER EXIT CALLED BY THE THE RECORD MIGRATION FACILITY (DDRMFLM). THE EXIT IS CALLED AFTER A RECORD HAS BEEN READ FROM RMFIN AND AFTER THE CONVERSION TO THE NEW RECORD FORMAT HAS TAKEN PLACE, BUT BEFORE THE RECORD HAS BEEN WRITTEN TO THE OUTPUT FILE. NOW, THE RECORD S FIELDS HAVE THE TYPE, LENGTH AND DISPLACEMENT ATTRIBUTES DEFINED IN THE "OUTPUT" DATADICTIONARY DEFINITION. THE USER CAN INSPECT THE INPUT RECORD AT THIS POINT AND ALTER DATA VALUES IN EXISTING FIELDS OR INSTRUCT RMF TO SKIP THE RECORD ENTIRELY. --------------------------------------------------------------------- LINKAGE - STANDARD IBM LINKAGE WITH R1 CONTAINING ADDR OF PARM LIST. PARM 1: FOR USE IN USER EXIT 1 - CHANGES TO THIS BUFFER IN USER EXIT 2 WILL BE IGNOTED. PARM 2: ADDR OF BUFFER CONTAINING CONVERTED RECORD. PARM 3: ADDR OF A 119 CHARACTER BUFFER WHERE THE USER CAN PLACE A MESSAGE TO BE PRINTED BY RMF. PARM 4: ADDR OF A FULL-WORD AREA FOR THE RETURN CODE RETURN CODES - ASSOCIATED RMF ACTION RC = - NORMAL RETURN - CONTINUE PROCESSING RC > - PRINT ANY MESSAGE IN MESSAGE AREA RC = 4 - SKIP RECORD AND PRINT ANY MESSAGE IN MESSAGE AREA RC > 4 - TERMINATE RUN AND PRINT ANY MESSAGE IN MESSAGE AREA --------------------------------------------------------------------- REGISTER USAGE STANDARD IBM REGISTER CONVENTIONS APPLY. R13 POINTS TO AN 18 WORD SAVE AREA WHERE THE CALLING PROGRAM'S REGISTERS SHOULD BE SAVED. THE CALLING PROGRAM'S REGISTERS MUST BE RESTORED BEFORE RETURNING. ANY ROUTINES CALLED FROM THIS SUBROUTINE ARE THE RESPONSIBILITY OF THE USER. --------------------------------------------------------------------- NAMING CONVENTIONS THE USER EXIT LOAD MODULE MAY HAVE ANY NAME THE USER CHOOSES. THE LOAD MODULE NAME IS MADE KNOWN TO DDRMFPR ON THE -RMF OPTIONS CONTROL CARD. --------------------------------------------------------------------- SAMPLE USER EXIT SOURCE CODE USERS SHOULD FEEL FREE TO PLAGARIZE THE FOLLOWING CODE TO MEET THEIR PARTICULAR NEEDS. GOOD RESULTS CAN BE ACHIEVED BY COPYING THE ENTRY AND EXIT CODE VERBATIM AND MODIFYING THE CODE BETWEEN THE ASTERISKS TO MEET INDIVIDUAL USER REQUIREMENTS. --------------------------------------------------------------------- EJECT



Output User-Written Exit for DDRMFLM (Continued)--------------------------------------------------------------------- PROGRAM ENTRY CODE ---------------------------------------------------------------------DDRX2PR CSECT (USER MAY USE ANY NAME IN PLACE OF DDRX2PR)

STM 14,12,12(13) SAVE CALLING PROGRAM'S REGISTERSBALR 12, LOAD R12 WITH ADDR OF NEXT INSTUSING ,12 NAME R12 AS BASE REGISTERST 13,SAV+4 SAVE CALLING PROGRAM'S R13LA 13,SAV POINT R13 AT THIS PROGM'S SAVE AREALM 3,6,(1) R3 = NOT USED IN USER EXIT 1

R4 = ADDRESS OF CONVERTED RECORD R5 = ADDR OF RMF MESSAGE AREA R6 = ADDR OF RETURN CODE AREA------------ REPLACE FOLLOWING SAMPLE CODE AS DESIRED --------------- SAMPLE USER EXIT TO EXAMINE CONVERTED RECORDS. IF SECOND FIELD IN RECORD CONTAINS '8431' THEN A VALUE OF 44433 WILL BE PLACED IN THE NEWLY ADDED FIELD. IF THE SECOND FIELD CONTAINS ANY OTHER VALUE, THEN A VALUE OF 12345 WILL BE PLACED IN THE NEW FIELD. ------------ REPLACE FOLLOWING SAMPLE CODE AS DESIRED ---------------

LA 15, DEFAULT RETURN CODECLC 3(5,4),=C'8431' IS SECOND FIELD = 8431

BNE RX1MOVEMVC 14(5,4),=C'44433' YES, FILL NEW FIELD WIHT 44433

B RX1MSG CONTINUERX1MOVE MVC 14(5,4),=C'12345' OTHERWISE, FILL WITH 12345RX1MSG MVC (L'ALTERMSG,5),ALTERMSG SET ALTERED RECORD MESSAGE

LA 15,1 SET DISPLAY MESSAGE RETURN CODEB RX1PRX THAT'S ALL FOR THIS CARD

SPACE 1------------ REPLACE PRECEDING SAMPLE CODE AS DESIRED ------------------------------------------------------------------------------------ PROGRAM EXIT CODE ---------------------------------------------------------------------RX1PRX DS H

ST 15,(6) SET RETURN CODEL 13,SAV+4 RESTORE CALLING PROGRAM'S R13LM 14,12,12(13) RESTORE CALLING PROGRAM'S REGISTERSLA 15, ZERO R15 FOR VPE INTERFACEBR 14 RETURN TO CALLER

SPACE 1ALTERMSG DC C'DATA HAS BEEN PLACED IN THE NEW FIELD' SPACE 1SAV DS 18F THIS ROUTINE'S SAVE AREA (USED IF THIS ROUTINE CALLS ANY USER-WRITTEN SUBROUTINES) END



Appendix C. Maintaining Tables withRelated Constraints

This appendix contains the following topics:

Impact of ALTER TABLE on TEST and HISTory Status Versions . . . . . 606Preventing ALTER TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 607Impact of Changing Structure Definitions on Constraints . . . . . . . . . . 608

Adding a Column to a Table . . . . . . . . . . . . . . . . . . . . . . . . 608Deleting a Column from a Table . . . . . . . . . . . . . . . . . . . . . . 608Adding a Column to a Key . . . . . . . . . . . . . . . . . . . . . . . . . 609Deleting a Column from a Key . . . . . . . . . . . . . . . . . . . . . . . 609Deleting Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610Updating Table Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 610Updating Key Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 611Updating Field Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 612

This section describes:

■ The impact of ALTER TABLE on specific Datadictionary status versions■ How to prevent the use of ALTER TABLE■ The impact of Datadictionary maintenance on constraints

Appendix C. Maintaining Tables with Related Constraints 605

Impact of ALTER TABLE on TEST and HISTory Status Versions

Impact of ALTER TABLE on TEST and HISTory Status Versions

When an SQL ALTER TABLE statement adds a constraint to a table,Datadictionary sets the CONSTRAINT attribute to A on all TEST and HISTorystatus versions of that table. If you later attempt to copy one of these versions(or a structure containing one of these versions) to PRODuction status,Datadictionary prevents the copy, issues an error message, and identifies thetable which has been altered. To recover, do one of the following:

■ If you were copying a structure to PRODuction status and the tableidentified in the Datadictionary message as having been altered was notone of the tables you modified in the TEST status version of the structure,copy only the modified tables from TEST to PRODuction status.

■ If the table altered through SQL is the table you modified in TEST status inDatadictionary, use one of the following procedures:

1. Restore the TABLEentity-occurrence fromPRODuction status to TEST.

2. Reapply any changes you hadmade through Datadictionary.

3. Copy the entity-occurrence toPRODuction status.

1. Drop the constraints.

2. Copy the entity-occurrence toPRODuction status.

3. Re-add the constraints.


Preventing ALTER TABLE

Preventing ALTER TABLE

To prevent anyone else from altering a table which you are modifying inDatadictionary, do one of the following:

■ If SQL security is implemented for the database containing the tables, issuethe following SQL command:

REVOKE ALTER ON table-name FROM PUBLIC

This prevents anyone from issuing an ALTER TABLE against the namedtable (or tables). However, after you have made your changes inDatadictionary and copied the table back to PRODuction status, you mustGRANT ALTER to each accessor-ID individually.

■ Instead of using SQL security, you can:

1. Use online or batch Datadictionary to assign a password to thePRODuction status version of any TABLE entity-occurrence which youintend to modify. (The password prevents anyone from performing anSQL ALTER TABLE on a table.)

2. Restore the structure containing the tables you want to modify fromPRODuction status to a TEST status version.

3. Use Datadictionary to make the modifications you need to make to theTEST status version of these TABLE entity-occurrences.

4. Copy these TABLE entity-occurrences to PRODuction status.

5. Use online or batch Datadictionary to remove the passwords youassigned in Step 1.


Impact of Changing Structure Definitions on Constraints


Certain Datadictionary activity, such as adding columns (FIELDentity-occurrences) to a table, or updating attributes of fields, keys, and tables,affects a constraint. These changes affect different types of constraints indifferent ways. For example, they could invalidate the constraint or the data ineither the modified or a related table.

The following sections are organized by the action you are performing anddescribe the type of effect the action has on Check, Foreign, and Uniqueconstraints. For Unique constraints, the Foreign keys that reference them canalso be affected and when they are, it is so noted in the following discussions.

Adding a Column to a Table

If you add a column to a table that has constraints defined, the constraintsbecome invalid. This applies only if the column is not in a Unique or ForeignKey (see “Adding a Column to a Key” on page 609).

Type of Constraint Effect on Constraint

Check and Foreign Constraints become invalid because offsets stored in theobject will change. The constraints are rebound by SQLthe next time the table is accessed.

Unique Constraints become invalid because the length of thetable changes as well as the offsets. The constraints arerebound by SQL the next time the table is accessed.

The referencing constraints also become invalid and arerebound by SQL the next time the table is accessed.

Deleting a Column from a Table

If you delete a column from a table that has constraints defined, the resultvaries depending on the type of constraint. This applies only if the column isnot in a Unique or Foreign Key (see “Deleting a Column from a Key” onpage 609). For example, Check constraints become obsolete, and Foreignconstraints become invalid.


Check Constraints become obsolete if the constraint is definedto the column being deleted, so the delete is not allowed.Datadictionary generates a DSF return code CON whenthis attempt is made. Drop the constraint before deletingthe column from the table.

If the constraint is not defined to the column, theconstraints become invalid because the offsets of othercolumns could change and therefore change the length of



the table. The constraints are rebound by SQL the nexttime the table is accessed.

Foreign Constraints become invalid because offsets stored in theobject change. The constraints are rebound by SQL thenext time the table is accessed.

Unique Constraints become invalid because the offsets stored inthe object change and because the length of the tablealso changes. The constraints are rebound by SQL thenext time the table is accessed.

The referencing constraints also become invalid and arerebound by SQL the next time the table is accessed.

Adding a Column to a Key

If you are adding a column to a key, the results vary depending on the type ofconstraint. This action has no effect on Check constraints. However, Foreignand Unique constraints cannot be updated this way.


Check Not applicable.

Foreign and UniqueConstraints are not allowed because the rebind willre-create the key as it was before causing a new KEY tobe added since the source of the constraints reflects theold column list.

Datadictionary generates a DSF return code CON whenyou attempt to add a column to a key defined with theseconstraints. Drop the constraint before adding thecolumn to the key.

Deleting a Column from a Key

If you delete a column from a key, the result varies depending on the type ofconstraint. This action has no effect on Check constraints. However, Foreignand Unique constraints cannot be updated in this way.



Foreign and UniqueThis action is not allowed because the rebind willre-create the key as before resulting in a new KEY sincethe source of the constraints reflects the old column list.

Datadictionary generates a DSF return code CON whenyou attempt to delete a column from a key defined with



these constraints. Drop the constraint before deleting thecolumn from the key.

Deleting Keys

If you delete a key with constraints defined, there is no effect on Checkconstraints, however, Foreign and Unique constraints become obsolete.



Foreign and UniqueDatadictionary generates a DSF return code CON whenyou attempt to delete a key related to one of these typeof constraints. Drop the constraint before deleting thekey.

Updating Table Attributes

When you update TABLE entity-occurrence attributes, changing AUTHID,SQLNAME or DATACOM-NAME attribute-values will affect constraints.Updating other attributes does not affect constraints.

Attribute Type ofConstraint

Effect on Constraint

DATACOM-NAME

Check,Foreign,andUnique

Not allowed if the table has constraints.

Datadictionary generates a DSF return codeCON when you attempt to update thisattribute for a table with these constraints.Drop the constraint before updating thisattribute.

AUTHID orSQLNAME


An SB9 error is returned if the change isattempted in PRODuction status.

If the change is attempted in TEST status, aCON error occurs if any constraints exist onthis table.



Updating Key Attributes

When you update KEY entity-occurrence attributes, changing theDATACOM-ID, DATACOM-NAME, MASTER-KEY, NATIVE-KEY, and UNIQUEattribute-values will affect constraints. All other KEY attributes not listed in thefollowing table may be changed.



DATACOM-ID Check Not applicable.

Foreign When you attempt to change thisattribute-value, Datadictionary clears thevalue.

Unique Not applicable.

DATACOM-NAME


Foreign When you attempt to change thisattribute-value, Datadictionary clears thevalue.

Unique Constraints become invalid because CADatacom/DB names of keys are stored inthe object. The constraints are rebound bySQL the next time the table is accessed.

The referencing constraints also becomeinvalid and are rebound by SQL the nexttime the table is accessed.

MASTER-KEY Check Not applicable.

Foreign When you attempt to change thisattribute-value, Datadictionary sets thevalue to N.


NATIVE-KEY Check Not applicable.

Foreign When you attempt to change thisattribute-value, Datadictionary sets thevalue to N.






UNIQUE Check Not applicable.

Foreign It is meaningless to update a Foreign Key.

When you attempt to change thisattribute-value, Datadictionary sets thevalue to N.

Unique Not allowed if a constraint exists on thiskey.

Datadictionary generates a DSF returncode CON when you attempt to change thevalue of this attribute from Y to N. Dropthe constraint before you make thischange.

Updating Field Attributes

When you update FIELD entity-occurrence attributes, changing the followingattribute-values will affect constraints:

AFTER CLASS DECIMALS LENGTH NULL-INDICATOR OFFSET REDEFINES REPEAT SIGN SQLNAME TYPE TYPE-NUMERIC

Updating other attributes does not affect constraints.





LENGTH Check andForeign

Constraints become invalid because theoffsets stored in the object will change.The constraints are rebound by SQL thenext time the table is accessed.

Unique Constraints become invalid because theoffsets stored in the object change andbecause the length of the table alsochanges. The constraints are rebound bySQL the next time the table is accessed.

The referencing constraints also becomeinvalid because the offsets stored in theobject change. The constraints arerebound by SQL the next time the table isaccessed.

OFFSET Check andForeign




AFTER Check andForeign


Unique Constraints become invalid because theoffsets stored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.






REPEAT Check andForeign




NULL-INDICATOR

Check andForeign

Constraints become invalid because theoffsets stored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.



TYPE Check andForeign

Constraints become invalid because theoffsets stored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.


The referencing constraints also becomeinvalid. The constraints are rebound bySQL the next time the table is accessed.





DECIMALS Check,Foreign,andUnique

Constraints become invalid because thedata stored in the object may need to beupdated as a result of this change. Theconstraints are rebound by SQL the nexttime the table is accessed.


REDEFINES(updating from Nto S or P forconstraint field)

Check Datadictionary generates a DSF returncode CON when you attempt to change thevalue of this attribute from N to S or P. Itis the same as deleting a field from thetable. Drop the constraint before makingthe change.

ForeignandUnique

This action is not allowed because therebind will re-create the key as beforeadding a new key since the source of theconstraints reflects the old column list.

Datadictionary generates a DSF returncode CON when you attempt to change thevalue of this attribute from N to S or P.Drop the constraint before making thechange.

REDEFINES(updating from Nto S or P forother fields)

Check andForeign

Constraints become invalid because offsetsstored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.

Unique Constraints become invalid because offsetsstored in the object change and becausethe length of the table also changes. Theconstraints are rebound by SQL the nexttime the table is accessed.






REDEFINES(updating from Sor P to N)

Check Constraints become invalid because offsetsstored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.

Foreign Datadictionary generates a DSF returncode CON when you attempt to changethis value from S or P to N, if the field is ina key representing a Foreign constraint.

If the field being updated is not in theForeign key, all Foreign constraints becomeinvalid.


Since this action is the same as adding afield, it is not allowed if the field is in a keythat represents a Unique constraint.Datadictionary generates a DSF returncode CON if you attempt to change a fieldin this manner.


CLASS(updating from Sto another valuefor constraintfield)

Check Datadictionary generates a DSF returncode CON when you attempt to change thevalue of this attribute to another value fromS, since this is the equivalent of deleting acolumn for SQL. Drop the constraintbefore making the change.

ForeignandUnique

This action is not allowed because therebind will re-create the key as it wasbefore adding a new key since the sourceof the constraints reflects the old columnlist.

Datadictionary generates a DSF returncode CON when you attempt to change thevalue of this attribute from S to anothervalue. Drop the constraint before makingthe change.





CLASS(updating from Sto another valuefor other fields)

Check andForeign

Constraints become invalid because offsetsstored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.



CLASS(updating to S)

Check Constraints become invalid because offsetsstored in the object change. Theconstraints are rebound by SQL the nexttime the table is accessed.

Foreign Datadictionary generates a DSF returncode CON when you attempt to changethis value to an S if the field is in a keyrepresenting a Foreign constraint. If thefield being updated is not in the Foreignkey, all Foreign constraints become invalid.


Since this action is the same as adding afield, it is not allowed if the field is in a keythat represents a Unique constraint.Datadictionary generates a DSF returncode CON if you attempt to change a fieldin this manner.






SIGN or TYPE-NUMERIC(for constraintfield)


Constraints become invalid because thedata stored in the object may need to beupdated as a result of this change.


SQLNAME Check,Foreign,andUnique

Not allowed in PRODuction status.Datadictionary generates an error (SB9).

Not allowed in TEST status if the field isrelated to a constraint of any type.Datadictionary generates a DSF returncode CON.


Index

Special Characters-ADD header transaction 224-AUXIN transaction 212-BTG TABLE transaction 48-BTG transaction 216

-BTG - initiating the Batch TransactionGenerator 53

-BTG START - initiating the Batch TransactionGenerator with a path 56

-BTG TABLE - special transactions for partitionedtables 48

-BTG TRACE - printing diagnostic information 49-BTG USER - user-written exit 50-BTG VERSION - specifying version/status 52

-COM transactionDDCFBLD utility example 82, 88DDUTILTY utility 408entering comments 28

-CPY header transaction 226-CXX BUILD transaction 77-CXX CATALOG transaction 77

DDRTVCAT utility 149-DEF PATH

-DEF TRACE transaction 24, 419-DEF TRACEB transaction 26, 421-DEF TRACEF transaction 26, 421

modifiers in report requests 428starting the report 425transaction format 24

-DEL header transaction 228-END transaction 220-GRP header transactions

-GRP START and -GRP END 234impact on Field Report 235

-HSD RESET transaction 77-NEST transaction 423-RMF EXITS transactions 141-RMF INPUT transactions 137-RMF OUTPUT transactions 139-RPT ALIAS transaction 441-RPT COLUMN transaction 544-RPT DEFIN transaction 446-RPT DESCRS transaction 452-RPT DETAIL transaction 457

-RPT FIELD transaction 501-RPT INDENT transaction 509-RPT INDEX transaction 524-RPT NESTEND transaction 425-RPT RELAT transaction 530-RPT SCHEMA transaction 540-RPT START transaction

in report requests 425in Source Language Generation 568, 572

-RPT TEXT transaction 553-SET RPOF and -SET RPON transactions to control

Detail Report in DDUPDATE 219-SET tranactions

See the CA Datacom/DB Database and SystemAdministration Guide

-UPD header transaction 230-UPG header transaction 233-USR transaction

establishing user authorization 20using in coding DDUTILTY transactions 410

-UTL AREA transaction 108-UTL COPY transaction 569-UTL ICF transaction 110-UTL LANGUAGE transactions

in generating DDICF transactions 108in generating Source Language Generation

statements 564-UTL LIBRARY transactions

in generating DDICF transactions 107in generating Source Language Generation

statements 563-UTL MODE transaction 564$FIRST

parameter value for KEY entity-occurrences 356$LAST

parameter value for KEY entity-occurrences 356&, returning attribute-value to default 232, 240

Numerics1000 ALTER transaction 2411000 APPLY transaction 246

See also Text1000 CATALOG transaction 2481000 CONNECT transaction 249

Index 619

1000 DISABLE transaction 2501000 ENABLE transaction 2511000 MODEL transaction 2521000 NEWNAME transaction 2551000 NEWPSWD transaction 2581000 OBSOLETE transaction 2601000 RESTORE transaction 2611000 SET transaction 2641000 TRANSFER transaction 2701000 VERIFY transaction 2711001 Author Controller transaction 2761002 Description transaction 2771003 AFTER transaction

See AFTER attribute-type1003 DATA transaction 2811003 Relationship transactions

1003 AFTER transaction 277, 2821003 DATA transaction 2811003 RELT transaction 2781003 UNRL transaction 280

1101 Descriptor transactions1101 ADD Descriptor transaction 2841101 DEL Descriptor transaction 284

1103 Alias Transactions1103 ADD 2861103 DEL 286

1200 TEXT transactions1200 TEXT ADD 2891200 TEXT CLS 2891200 TEXT DEL 2941200 TEXT END 288, 2981200 TEXT INS 2951200 TEXT REP 296

1500 Attribute Value Update transaction 3002000 Relationship transaction 3022900 DATABASE transaction 306, 3072901 DATABASE transaction 306, 3093000 DATABASE transaction 3063000 Tranactions

See 2900 Transactions3001 to 3004 AREA transactions

3001 AREA transaction 3113002 AREA transaction 3113004 AREA transaction 310, 313

3003 TranactionsSee 3004 Transactions

3120 to 3122 FILE transactions 3163120 FILE transaction 3173121 FILE transaction 3183122 FILE transaction 319

3150 to 3160 TABLE transactions3150 TABLE transaction 3223151 TABLE transaction 3253152 TABLE transaction 3263153 TABLE transaction 3283160 TABLE transaction 329

3160 TABLE Transaction 3293200 Record transaction 3304010 to 4020 FIELD transactions 331

4010 FIELD transaction 3344011 FIELD transaction 3354012 FIELD transaction 3354013 FIELD transaction 3394014 FIELD transaction 3404015 FIELD transaction 3414016 FIELD transaction 3424017 FIELD transaction 3434018 FIELD transaction 3444020 FIELD transaction 345

4099 Field Access transaction 3475000 to 5100 KEY transactions 351

5000 KEY transaction 3525010 KEY transaction 3555011 KEY transaction 3565012 KEY transaction 3565100 KEY transaction 358

5200—5203 PARTITION-COLUMN-VALUEtransactions 360

5200—5203 PARTITION-COLUMN-VALUEtransctions

5200 transaction 3605203 transaction 361

6000 to 6011 ELEMENT transactions 3676000 ELEMENT transaction 3686010 ELEMENT transaction 3686011 ELEMENT transaction 370

6100 LIBRARY transaction 3726200 MEMBER transaction 3737011 to 7025 PARTITION-VALUE transactions 3757100 PANEL transaction 3777110 SYSTEM transaction 3797120 PROGRAM transaction 3817130 MODULE transaction 3837140 AUTHORIZATION transaction 3857150 to 7156 PERSON transactions

7150 PERSON Job transaction 3877155 PERSON Language transaction 3887156 PERSON Name transaction 390

7160 REPORT transaction 3917170 JOB transaction 393


7180 STEP transaction 3947190 DATAVIEW transaction 3977211 NODE transaction 3987999 Application Attribute transaction 4009000 User-defined transactions 401

AAbbreviations in formats 28ACCESS-CODE attribute-type

for DATAVIEW entity-occurrences 397on DATAVIEW Detail Report 462

ACCESS-METHOD attribute-typeon DATAVIEW Detail Report 462

ACCESS-MTHD attribute-typefor AREA entity-occurrences 311for FILE entity-occurrences 318on AREA Detail Report 459on FILE Detail Report 469

ACCOUNTING-INFO attribute-typefor JOB entity-occurrences 393for STEP entity-occurrences 395on JOB Detail Report 471

ACTUAL-DATE attribute-typeon PROGRAM Detail Report 484

ADSee CA Datacom/AD

ADD Alias transaction (1103) 286ADD Descriptor transaction (1101) 284AFTER attribute-type

constraint validation concerns 613for FIELD entity-occurrences 334on FIELD Detail Report 464

AFTER-FIELDattribute for KEY entity-occurrences 356

AGR-SQLNAME attribute-type referenced onFIELD Detail Report 465KEY Detail Report 471

ALIAS attribute-typeon Alias Report 441

Alias Report 441example reports 442request format 441

Aliases1103 transaction 286adding and deleting 286deleting 286example transactions 287impact of renaming the entity-occurrence 256

ALIGN parameterfor Indented Report 510

ALIGN parameter (continued)for Text Report 555

ALLV (all versions) 414, 427ALTER TABLE (SQL statement)

impact on TEST and HISTory statusversions 606

revoking 607Ampersand (&), returning attribute-value to

default 232, 240ANCHOR-POINT attribute-type, on FILE Detail

Report 469ANY-PARTITION-AUTHID attribute-type

for TABLE entity-occurrences 328on TABLE Detail Report 490

ANY-PARTITION-DATACOM-NAME attribute-typefor TABLE entity-occurrences 328on TABLE Detail Report 490

ANY-PARTITION-SQLNAME attribute-typefor TABLE entity-occurrences 328on TABLE Detail Report 491

APPLICATION attribute-type7999 transaction 400adding with 7999 transaction 400for REPORT entity-occurrences 391for SYSTEM entity-occurrences 379on PROGRAM Detail Report 484on REPORT Detail Report 487on SYSTEM Detail Report 490

APPLY transaction (1000) 241to specify NOTEXT 246to specify TEXT 246

ARCHIE-LEVELS attribute-type, on LIBRARY DetailReport 473

Archiving batch transactions-BTG AUXOUT - specifying an auxiliary output

device 47DDBTGLM 47

AREA entity-occurrences3001 AREA transaction 3113001 to 3004 AREA transaction 3103002 AREA transaction 311AREA Detail Report 459example transactions 314

AREA entity-type 244Arithmetic symbols in syntax diagrams 33As-of-date

in -BTG START transaction 58in DDBTGLM utility 58

in -BTG transaction 54in DDBTGLM utility 54

in -RPT NEST transaction 424

Index 621

As-of-date (continued)in -RPT NESTEND transaction 428in 1000 RESTORE transaction 261in DDUTILTY report transactions 415in Detail report 458

ASM-NAME attribute-typefor ELEMENT entity-occurrences 368for FIELD entity-occurrences in a key 356for FIELD entity-occurrences in elements 370on ELEMENT Detail Report 464on FIELD Detail Report 465

ASOF keywordSee As-of-date

ASOF keyword, in report transactions 415Assembler

copybooks 563ELEMENT entity-occurrence compiler name on

Detail Report 464sample copybook 583

ASSEMBLER-NAME attribute-typefor DATAVIEW entity-occurrences 397on DATAVIEW Detail Report 462on Field Report 504

Asterisk (*)in -BTG USER transaction 50in report requests 414

Attribute Value Update transaction (1500) 300Attribute-values

automatic generation with SET transaction 264returning to default 232, 240updating 300

AUTH-USAGE attribute-typeon AUTHORIZATION Detail Report 460

AUTHID attribute-typeconstraint validation concerns 610for CONSTRAINT entity-occurrences 461for PARAMETER entity-occurrences 477for PLAN entity-occurrences 481for PROCEDURE entity-occurrences 483for TABLE entity-occurrences

in 3152 TABLE transaction 327on FIELD Detail Report 465on Key Detail Report 471

for TRIGGER entity-occurrences 495for VIEW entity-occurrences 497on PLAN Detail Report 481on PROCEDURE Detail Report 483on Schema Report 540on STATEMENT Detail Report 488on SYNONYM Detail Report 489on TABLE Detail Report 491

Authoradding 276Controller transaction (1001) 276

AUTHOR attribute-typeon Detail Report 458on Field Report 501on Text Report 553

AUTHORIZATION entity-occurrences7140 transaction 385Detail Report 460security classification code 385

Authorization for Datadictionary transactionsSee -USR transaction

AUTO-RULE (AUT) for relationshipsdefining with 2000 Relationship Transaction 303on Definitions Report 446

Auxiliaryinput DDUPDATE 212output

DDRMFLM 143Auxiliary output

DDICF 112

BBACKUP-EXECS attribute-type, on LIBRARY Detail

Report 473BASE-NAME attribute-type

on TABLE Detail Report 491value assigned with SET DATABASE 265

BASE-TYPE attribute-typefor DATABASE entity-occurrences 307on DATABASE Detail Report 461

BASE-VER attribute-typeon TABLE Detail Report 491value assigned with SET DATABASE 265

Batch Transaction Generator (BTG)See DDBTGLM utility

Begin-sequence1200 TEXT DEL transaction 2951200 TEXT INS transaction 2961200 TEXT REP transaction 297

Beginning the report request, -RPT START 425BLANK-WHEN-ZERO attribute-type

for FIELD entity-occurrences 342on FIELD Detail Report 465

BLOCK-SIZE attribute-typefor AREA entity-occurrences 312for FILE entity-occurrences 317on AREA Detail Report 459on FILE Detail Report 469


BLOCK-SIZE attribute-type (continued)verified by VERIFY transaction 272

BTG TABLE Transaction 60BUILD function

-CXX BUILD transaction 80SET function invoked during 264

CCA Datacom STAR

DATABASE to NODE path using Impact AnalysisReport 519

CA Datacom/ADcataloging definitions to the Directory (-CXX

CATALOG) 152DDRTVCAT utility 149in cataloging Datadictionary definitions

(DDCFBLD) 78in cataloging definitions to the Directory (-CXX

CATALOG) 87in updating the CA Datacom/DB Directory

(DDUPDATE) 214in using the 1000 CATALOG Transaction 248

CA Datacom/DB1000 CATALOG transaction 2481000 SET transaction 264Cluster Key ID for a table 491DATABASE Detail Report 461DATACOM-ID attribute-type

for a database 492for a key 471for a table 492of database, table, or key on Indented

Report 509of table or key on Schema Report 541

DATACOM-NAME attribute-typefor a key 471for a one-field element 465for a table 492for an area 459

date and time database cataloged toDirectory 461

generating descriptions for CA Datacom/DBReporting Facility 576

SECURITY-CODE for an element 464SPACE-MNGMNT, the space management option

for an area 460UPDATE-DB attribute-type of PROGRAM

entity-occurrences 486CA Datacom/DB and CA FILE Models, maintenance

transactions 238

CA Datacom/DB Reporting Facilitycolumn headings, 4013 FIELD transaction 339copybooks 563DR value in Source Language Generation control

statement 565generating data descriptions 576library type for Source Language Generation of

copybooks 563sample copybook 585

CA Datacom/DB short nameSee DATACOM-NAME attribute-type

CA Dataquery1000 SET transaction 264column headings, 4013 FIELD transaction 339date value using SEMANTIC-TYPE attribute-type

for FIELD entity-occurrences 344disabling a structure or substructure 250

CA Dataquery for PC, column headings, 4013 FIELDtransaction 339

CA Ideal7110 SYSTEM transaction 3807190 DATAVIEW transaction 397column headings, 4013 FIELD transaction 339date value using SEMANTIC-TYPE attribute-type

for FIELD entity-occurrences 344disabling a structure or substructure 250EDIT-PATTERN attribute-type for FIELD

entity-occurrences 340FIELD entity-occurrence change notification

(SIGNIFICANT-CHG) on Detail Report 468Impact Analysis Report 518reserved use in MODULE Detail Report

(IDEAL-RESERVED) 475reserved use in PANEL Detail Report

(IDEAL-RESERVED) 476reserved use in PROGRAM Detail Report

(IDEAL-RESERVED) 485CA IPC

ROSFD macro 212CA Librarian 473, 574

library type for Source Language Generation ofcopybooks 563

CA MetaCOBOL+, Impact Analysis Report 519CA Panvalet 574

library type for Source Language Generation ofcopybooks 563

CA Roscoe IE, library type on LIBRARY DetailReport 473

CA Vollie, library type on LIBRARY DetailReport 473

Index 623

CA-DATE for SEMANTIC-TYPE attribute-value forFIELD entity-occurrences 344

CARR-CNTL attribute-type, for REPORTentity-occurrences 392

CATALOG functionDDCFBLD transaction 77, 95DDRTVCAT transaction 149DDUPDATE 1000 CATALOG transaction 248SET function invoked 264

CATALOGED-DATE attribute-typeon DATABASE Detail Report 461on DATAVIEW Detail Report 462

CATALOGED-TIME attribute-typeon DATABASE Detail Report 461on DATAVIEW Detail Report 463

CHAIN, start-of and end-of 530, 538CHNG-MASTER-KEY attribute-type


CI-INSERT attribute-type, on FILE DetailReport 469

CI-ROOT attribute-type, on FILE Detail Report 469CLASS attribute-type

constraint validation concerns 617for FIELD entity-occurrences 335for JOB entity-occurrences 393on FIELD Detail Report 465on Field Report 502on JOB Detail Report 471Record Migration Facility special

considerations 128CLASS on Field Report 502CLASS-CODE attribute-type

for AUTHORIZATION entity-occurrences 385on AUTHORIZATION Detail Report 460

Classification name parameter for Text Report 555CLUSTER-KEY-ID attribute-type

for TABLE entity-occurrences 324on TABLE Detail Report 491value assigned with SET DATABASE 265verified by VERIFY transaction 272

CLUSTER-KEY-LEN attribute-typefor TABLE entity-occurrences 324on TABLE Detail Report 491verified by VERIFY transaction 272

CNS-DOMAIN attribute-typeon TABLE Detail Report 491value assigned with SET DATABASE 265

CNS-REFERENCED attribute-typeon TABLE Detail Report 491value assigned with SET DATABASE 265

CNS-REFERS attribute-typeon TABLE Detail Report 491value assigned with SET DATABASE 265

CNS-SAME-BASE attribute-typeon TABLE Detail Report 491value assigned with SET DATABASE 265

CNS-UNIQUE attribute-typeon TABLE Detail Report 492value assigned with SET DATABASE 265

COBOLcopybooks 563level numbers assigned by Source Language

Generation 575sample copybook 578Source Language Generation example

transactions 572value in Source Language Generation 565

Coding thepath request 22, 418report request

ending the report request 416using modifiers 416using the override code 416

Commarepeat symbol, use in 36

CommentsDDTRSLM utility 170in batch utilities 28in report requests 408

COMPILE-DATE attribute-typeon PARTITION-VALUE Detail Report 478

COMPILE-TIME attribute-type onPARTITION-VALUE Detail Report 478

COMPILE-VERSION attribute-type onPARTITION-VALUE Detail Report 478

COMPILED-DATE attribute-typeon DATAVIEW Detail Report 463on MODULE Detail Report 475on PANEL Detail Report 476on PROGRAM Detail Report 484on REPORT Detail Report 487

COMPILED-TIME attribute-type onDATAVIEW Detail Report 463PANEL Detail Report 476PROGRAM Detail Report 484

Compiler5012 KEY transaction 3566000 ELEMENT transaction 3686011 ELEMENT transaction 3707190 DATAVIEW transaction 397ELEMENT entity-occurrence compiler name on

Detail Report 464


Compiler (continued)FIELD entity-occurrence compiler name on Detail

Report 465FIELD entity-occurrence compiler name on Field

Report 504for KEY entity-occurrences 354KEY entity-occurrence compiler name on Detail

Report 472on DATAVIEW Detail Report 463value in Source Language Generation 566

COMPILER-NAME attribute-typefor DATAVIEW entity-occurrences 397for FIELD entity-occurrences in a key 356for FIELD entity-occurrences in elements 370on DATAVIEW Detail Report 463on Field Report 504

COMPL-NAME attribute-typefor ELEMENT entity-occurrences 368on ELEMENT Detail Report 464on FIELD Detail Report 465

Compound FIELD entity-occurrences 335COMPRESS-EXIT attribute-type


COMPRESS-RTN attribute-typeon RECORD Detail Report 486on TABLE Detail Report 492

COMPRESSION attribute-typefor TABLE entity-occurrences 323on LIBRARY Detail Report 473on TABLE Detail Report 492

CONSTRAINT attribute-typeon TABLE Detail Report 492value assigned with SET DATABASE 265

CONSTRAINT entity-occurrences 461Constraint validation

keysadding and deleting columns 609deleting 610

tablesadding and deleting columns 608updating attributes 610

Constraint validation (same chapter in all identifiedbooks) 608—618

CONTROLLER attribute-typeon Detail Report 458on Field Report 501on Text Report 553

Controller, adding 276COPY-RULE (CPY) for relationships

defining with 2000 Relationship Transaction 303

COPY-RULE (CPY) for relationships (continued)on Definitions Report 446

COPY-VERSION headerSee PREVIOUS-VERS attribute-type

Copybookscreating 561—593level numbers assigned by Source Language

Generation 575punched output from Source Language

Generation 574COUNT attribute-type

on Detail Report 459on Field Report 501on Text Report 553

CPYLVIN= (DDSYSTBL parameter) 575CPYLVST= (DDSYSTBL parameter) 575CPYNDLM= (DDSYSTBL parameter) 575CREATOR attribute-type

on PARAMETER-LIST Detail Report 477on PROCEDURE Detail Report 483on SYNONYM Detail Report 489on VIEW Detail Report 497

DData Definition Directory (DDD)

DBCFBLD utility 80DDD-BASE-ID attribute-type for DATABASE

entity-occurrences 308DDD-BASE-ID on DATABASE Detail Report 462DDD-SYNCH on TABLE Detail Report 492do not use -CXX CATALOG 87

Data Group Table (DGT)on -HSD RESET transaction report 97Record Migration Facility special

consideration 128Data types for FIELD entity-occurrences

on 4012 FIELD transaction 335on Field Report 502

DATA-ACCESS attribute-typefor FIELD entity-occurrences 348on FIELD Detail Report 465

DATA-BASE-NAME attribute-type, on FILE DetailReport 469

DATA-COMP-DATE attribute-type, on PROGRAMDetail Report 484

DATA-COMP-TIME attribute-type, on PROGRAMDetail Report 484

DATA-DATE attribute-type, on PROGRAM DetailReport 484

Index 625

DATA-DICT-ID attribute-typefor AREA entity-occurrences 313on AREA Detail Report 459

DATA-DICT, rebuildingSee DDBTGLM and DDCFBLD utilities

DATA-MDFD-DATE attribute-type, on PROGRAMDetail Report 484

DATA-MDFD-TIME attribute-type, on PROGRAMDetail Report 485

DATA-SENSITIVE attribute-type5100 KEY transaction 357for FIELD entity-occurrences in a key 357on Field Report 504

DATA-SET-NAME attribute-typefor AREA entity-occurrences 311for FILE entity-occurrences 318on AREA Detail Report 459on FILE Detail Report 469

DATA-TIME attribute-type, on PROGRAM DetailReport 485

DATABASE entity-occurrences2900 transaction 306, 3072901 transaction 306, 3093000 transaction 306Detail Report 461structure STANDARD path for reporting 422

DATABASE entity-type 243DATACOM VIEW 544, 562Datacom View Generator 562

z/OS sample output 587DATACOM-ID attribute-type

constraint validation concerns 611for DATABASE entity-occurrences 307for KEY entity-occurrences 352, 471for TABLE entity-occurrences 322on DATABASE Detail Report 461on Indented Report 509on Schema Report 541on TABLE Detail Report 492value assigned with SET DATABASE 265VERIFY transaction validates 272

DATACOM-ID attribute-valuein -USR transaction 21

DATACOM-NAME attribute-typeconstraint validation concerns 610, 611for AREA entity-occurrences 311for ELEMENT entity-occurrences 368for KEY entity-occurrences 352, 471for one-field ELEMENT entity-occurrences 465on AREA Detail Report 459on ELEMENT DETAIL Report 465

DATACOM-NAME attribute-type (continued)on Indented Report 509on Schema Report 541on TABLE Detail Report 492VERIFY transaction validates 272

Datadictionary1000 ALTER transaction 241APPLY transaction (1000) 241AREA entity-type 244DATABASE entity-type 243

DATAQUERYSee CA Dataquery

DATAVIEW entity-occurrences7190 transaction 397Detail Report 462

DATE-ADDED attribute-typeon Detail Report 459on Field Report 501on Text Report 553

DATE-DESIGN attribute-typefor SYSTEM entity-occurrences 379on SYSTEM Detail Report 490

DATE-IMPLEM attribute-typefor SYSTEM entity-occurrences 379on SYSTEM Detail Report 490

DATE-LAST-CHG attribute-typeon Detail Report 459on Field Report 501on Text Report 553

DATE-MODIFIED attribute-typefor MODULE entity-occurrences 384for PROGRAM entity-occurrences 382on PROGRAM Detail Report 485

DATE-PRECOMP attribute-typefor MODULE entity-occurrences 384for PROGRAM entity-occurrences 382on PROGRAM Detail Report 485

DATE-PRECOMPILE attribute-type, on MEMBERDetail Report 474

DATE-WRITTEN attribute-typefor MODULE entity-occurrences 383for PROGRAM entity-occurrences 382for REPORT entity-occurrences 391on MEMBER Detail Report 474on PROGRAM Detail Report 485

Date/time alias - Date/time stamp 415DATEFORM attribute-type, on PLAN Detail

Report 481DB-MASTER-KEY attribute-type

on TABLE Detail Report 492value assigned with SET DATABASE 265


DB-NATIVE-KEY attribute-typeon TABLE Detail Report 492value assigned with SET DATABASE 265

DBEDITS attribute-type, for FIELDentity-occurrences 338

DBMODEL path 22DBMS-USED attribute-type

for AREA entity-occurrencesin 3002 transaction 312

for DATABASE entity-occurrencesin 3000 transaction 307

for FILE entity-occurrencesin 3120 transaction 317on FILE Detail Report 469

for TABLE entity-occurrencesin 3150 transaction 323on Detail Report 492updated by SET function 264

on AREA Detail Report 459on DATABASE Detail Report 461on DATAVIEW Detail Report 463

DD-BASE-ID attribute-type, for NODEentity-occurrences 399

DD-ENTITY-TABLE attribute-typefor TABLE entity-occurrences 326on TABLE Detail Report 492

DD-MASTER-KEY attribute-typeon TABLE Detail Report 492value assigned with SET DATABASE 265

DD-NAME attribute-type, on AREA DetailReport 460

DD-NATIVE-KEY attribute-typeon TABLE Detail Report 492value assigned with SET DATABASE 265

DD2-NAME attribute-type, on FILE DetailReport 469

DDBTGLMpartitioned tables 60

DDBTGLM utility-BTG transaction 53-BTG transaction used by DDUPDATE 216adding transactions 44archiving batch transactions 41—76continuation capability 44END transaction 59Error Recap Report 31exit, disabling 50generating batch transactions 41—76indicating a starting point 56modifying transactions 44printing diagnostic information 49

DDBTGLM utility (continued)report generated 30resolving DDBTGLM problems 49sample output

database 68dataview 75

sample reportdatabase 63dataview 73

special transactions for partitioned tables 48specifying

auxiliary output device 47status/version 52

START transaction 56trace facility 49user-written exit 50, 595—598VERSION transaction 52z/OS sample JCL 62z/VSE sample JCL 62

DDCFBLD utility-CXX BUILD transaction 80-CXX CATALOG transaction 87-HSD RESET transaction 951000 SET transaction 264building batch transactions 80cataloging

batch transactions 214Datadictionary definitions 77, 87

report generated 30resetting Datadictionary High-Speed Directory

(HSD) 77, 95sample report

(-CXX BUILD) 84(-CXX CATALOG) 91(-HSD RESET) 97

transaction formats 80VERIFY function 77, 271z/OS sample JCL

-CXX BUILD 82-CXX CATALOG 88-HSD RESET 96

z/VSE sample JCL-CXX BUILD 83-CXX CATALOG 90-HSD RESET 97

DDD-BASE-ID attribute-typefor DATABASE entity-occurrences 308on DATABASE Detail Report 462

DDD-SYNCH attribute-type, on TABLE DetailReport 492

Index 627

DDICF utility-UTL AREA transaction 109-UTL ICF transaction 110-UTL LANGUAGE transaction 108-UTL LIBRARY transaction 107Error Recap Report 31generated transactions used in DDUPDATE 215invoking 107report generated 30sample

output transactions 116, 121reports 'for a file' 119reports 'for a table' 115

specifyingarea and table information 109the copybook member 110the input language 108

z/OS sample JCL 112z/VSE sample JCL 113

DDRMFLM utility-RMF EXITS transactions 141-RMF INPUT transactions 137-RMF OUTPUT transactions 139changing

records to a new format 125tables to a new format 125

invoking user-written exits 141report generated 30sample

report 144sample report with error messages 148user-written exits 599—603z/OS sample JCL 143z/VSE sample JCL 143

DDRTVCAT utility-CXX CATALOG transaction 152-RTV BASIS transaction 154cataloging

Datadictionary definitions 152sample report

CXX CATALOG 157VERIFY function 149z/OS sample JCL 155z/VSE sample JCL 156

DDTRSLM utilitycontinuation capability 170converting format 186debugging the utility 188dependencies between entity-occurrences 182duplicate entity-occurrences, handling 180, 187example JCL or EXEC

z/OS sample JCL 189

DDTRSLM utility (continued)example JCL or EXEC (continued)

z/VSE sample JCL 189example transport file

for a plan 194for a table 200

exporting programs 191—192how to use 170report generated 30special considerations 166transport commands

comments in commands 170continuation capability 170EXPORT 172IMPORT 175SET EXPORT FORMAT PREVIOUS

RELEASE 186SET IMPORT COLLISION 187SET TRACE 188SET USER 185TRIAL IMPORT 175, 182

transportingplans 193tables, views, synonyms 199

DDUPDATE utility-AUXIN transaction (auxiliary input) 212accepting input from an alternate source 212continuation capability 211Detail Report 219Error Recap Report 31, 219maintaining entity-occurrences 208—402Maintenance Report 219modifying status of entity-occurrences 208—402processing -BTG input 216report generated 30reports 219requesting reports 208transactions

-ADD Header 224-CPY Header 226-DEL Header 228-GRP Header 234-UPD Header 230-UPG Header 233using to maintain entity-occurrences 237

z/OS sample JCL 221z/VSE sample JCL 222

DDUTILTY utilityDatacom View Generator

z/OS sample datvgen output 587Error Recap Report 31


DDUTILTY utility (continued)report generated 30reporting

coding the report request 412continuation capability 411Error Recap Report 409example job streams 431Maintenance Report 409path request for a report 418restricting entity-occurrences in the report 413specifying report type 413STANDARD path 422z/OS sample JCL 431z/VSE sample JCL 432

Source Language GenerationCA Datacom/DB Reporting Facility

considerations 576control statements 563copybook punched output from Source

Language Generation 574defining a path 572example transactions 572generated copybooks 578—593output 574z/OS sample JCL 577z/VSE sample JCL 577

DECIMALS attribute-typeconstraint validation concerns 615for FIELD entity-occurrences 336on FIELD Detail Report 465on Field Report 503

DECPOINT attribute-type, on PLAN DetailReport 481

Default values in syntax diagrams 37DEFAULT-EXEC attribute-type, on LIBRARY Detail

Report 473DEFAULT-INSERT attribute-type


DEFAULT-LIST attribute-type, on LIBRARY DetailReport 473

DEFAULT-SEQ attribute-type, on LIBRARY DetailReport 473

Defaults, returning attribute-values to 232, 240Definitions Report 446, 447DEL Alias transaction (1103) 286DEL Descriptor transaction (1101) 284Delimiters

syntax diagrams, use in 34DEPENDING-ON attribute-type

for FIELD entity-occurrences 342

DEPENDING-ON attribute-type (continued)on FIELD Detail Report 465

Descriptiontransaction (1002) 277

Description adding 277DESCRIPTION attribute-type

on Alias Report 441on Detail Report 458on Field Report 501on Indented Report 509, 524on Schema Report 540on Text Report 553

DESCRIPTION entry in -UTL Language ControlStatement 565

Descriptors1101 transaction 284ADD parameter 284DEL parameter 284impact of renaming the entity-occurrence 256name parameter 284

Descriptors Report 452, 453Detail Report 457

AREA report content 459AUTHORIZATION report content 460automatic in DDUPDATE 219CONSTRAINT report content 461DATABASE report content 461DATAVIEW report content 462ELEMENT report content 464example reports 498, 500FIELD Detail report content 464FILE report content 469JOB report content 471KEY report content 471LIBRARY report content 473MEMBER report content 474modifiers 458MODULE report content 475NODE report content 476PANEL report content 476PARAMETER-LIST report content 477PARTITION-COLUMN-VALUE report

content 478PARTITION-VALUE report content 478PERSON report content 479PLAN report content 481PROCEDURE report content 483PROGRAM report content 484RECORD report content 486REPORT report content 487request format 457

Index 629

Detail Report (continued)STATEMENT report content 488STEP report content 489SYNONYM report content 489SYSTEM report content 490TABLE report content 490TRIGGER report content 495VIEW report content 497

DEVICE attribute-typefor FILE entity-occurrences 317on AREA Detail Report 460on FILE Detail Report 469verified by VERIFY transaction 272

DIRECT attribute, for KEY entity-occurrences 358Directory (CXX)

DISABLE transaction 250ENABLE transaction 251

Directory maintenance utilitySee DDCFBLD utility

DISK-BACKUP-OPT attribute-type, on LIBRARYDetail Report 473

DISP-ELEMENT attribute-type, on FIELD DetailReport 466

DISP-IN-TABLE attribute-typeon ELEMENT Detail Report 464on FIELD Detail Report 466on Field Report 502

DISP-PRIOR attribute-type, for STEPentity-occurrences 395

DL1T-CONSTRAINT attribute-typefor DATABASE entity-occurrences 308on DATABASE Detail Report 462on TABLE Detail Report 493

DSF-ACCESS attribute-typefor FIELD entity-occurrences 349on FIELD Detail Report 466

DUPE-MASTER-KEY attribute-typefor TABLE entity-occurrences 322on TABLE Detail Report 493

DYN-EXT-TRACKS attribute-typefor AREA entity-occurrences 314for DATABASE entity-occurrences 308

DYNAMIC-EXTEND attribute-typefor AREA entity-occurrences 313for DATABASE entity-occurrences 308on AREA Detail Report 460on DATABASE Detail Report 462

EEDIT-PATTERN attribute-type


ELEMENT entity-occurrences6000 transaction 3686010 ELEMENT transaction 3686011 ELEMENT transaction 370attribute-values assigned by SET function 268Detail Report 464example transactions 370transactions 367

ELM-NAME attribute-typeon FIELD Detail Report 466on Indented Report 524

ELM-SEC-CODE attribute-type, on FIELD DetailReport 466

EMPLOYEE-IDENT attribute-typefor PERSON entity-occurrences 387on PERSON Detail Report 479

ENABLE1000 ENABLE transaction 251

ENABLE attribute-typeon AREA Detail Report 460on CONSTRAINT Detail Report 461on DATABASE Detail Report 462on DATAVIEW Detail Report 463on ELEMENT Detail Report 464on FIELD Detail Report 466on FILE Detail Report 470on KEY Detail Report 472on PARAMETER-LIST Detail Report 477on RECORD Detail Report 487on SYNONYM Detail Report 489on TABLE Detail Report 493on VIEW Detail Report 497

ENCRYPTION-KEY attribute-typefor TABLE entity-occurrences 324on TABLE Detail Report 493

END transaction 416END-OF-CHAIN 530, 538End-sequence

1200 TEXT DEL transaction 2951200 TEXT REP transaction 297

Ending a report request 416Entity

header parameter 224, 229ENTITY-NAME attribute-type

on Alias Report 441on Detail Report 458


ENTITY-NAME attribute-type (continued)on Field Report 501on Indented Report 509on Schema Report 540on Text Report 553

ENTITY-TYPE attribute-typeon Alias Report 441on Detail Report 458on Field Report 501on Indented Report 509on Index Report 524on Schema Report 540on Text Report 553

Entity-types, specifying in requestsrequesting generic selection 414restricting entity-occurrences 413, 414restricting entity-types 413

ENTITY-VER attribute-typeon Alias Report 441on Indented Report 509, 524on Schema Report 540

ENTY-HIST-VERS attribute-typefor TABLE entity-occurrences 326on TABLE Detail Report 493

ENTY-NAME-LEN attribute-typefor TABLE entity-occurrences 326on TABLE Detail Report 493

ENTY-TYPE verified by VERIFY transaction 272Error checking with VERIFY transaction 271Error Recap Reports for Datadictionary utilities 31Exits

Batch Transaction Generator exit 50DDBTGLM sample (COBOL) 595—598DDRMFLM samples (Assembler) 599—603inspecting/modifying transactions 50Record Migration Facility

contents of the Exit Program 142editing fields before/after converting

records 141sample job streams and reports 143samples of user-written 599—603

user-written 50EXPORT command (DDTRSLM) 172Exporting programs with DDTRSLM

utility 191—192Extending dynamically

See DYNAMIC-EXTEND attribute-type

FFALLBACK attribute-type

on TABLE Detail Report 493Pipeline option for a table 494Recovery option for a table 494

Field Access transaction (4099) 347FIELD entity-occurrences

4010 transaction 3344011 transaction 3354012 transaction 3354013 transaction 3394014 transaction 3404015 transaction 3414016 transaction 3424017 transaction 3434018 transaction 3444020 transaction 345attribute-values

assigned by SET function 268verified for SQL accessible tables 273

coding, using -GRP header transactions 234converting with DDRMFLM Utility 125data types 335Detail Report 464example transactions 346level numbers assigned by Source Language

Generation 575transactions 331

Field Report 501example reports 505

FIELD-NAME attribute-typefor ELEMENT entity-occurrences 369on Field Report 502

FILE entity-occurrences3120 FILE transaction 3173121 FILE transaction 3183122 FILE transaction 319Detail Report 469example transactions 319transactions 316

FILENAME attribute-typeon CONSTRAINT Detail Report 461on PARAMETER-LIST Detail Report 477on RECORD Detail Report 487on SYNONYM Detail Report 489on TABLE Detail Report 493on VIEW Detail Report 497

Filler FIELD entity-occurrences 335FIPS attribute-type

on PARAMETER-LIST Detail Report 477

Index 631

FIPS attribute-type (continued)on PROCEDURE Detail Report 483on STATEMENT Detail Report 488on TABLE Detail Report 493on TRIGGER Detail Report 496on VIEW Detail Report 497

FIRST-FIELD attribute-type, on ELEMENT DetailReport 464

FLSHin DDUPDATE utility report 29in DDUTILTY utility report 29

FORCEADD attribute-type, for FIELDentity-occurrences 338

FORCEUPD attribute-type, for FIELDentity-occurrences 338

Foreign keyon KEY Detail Report 472on TABLE Detail Report (CNS-REFERS

attribute-type) 491FORM-NBR attribute-type, for REPORT

entity-occurrences 391

GGENERATE=x

value in Source Language Generation 566Generated reports 30Generic selection for Datadictionary

entity-occurrencesin generating batch transactions 45in report requests 414

GROUP-PROCESS attribute-type, on LIBRARYDetail Report 473

HHeader transaction parameters

entityusing -ADD transaction 224using -CPY transaction 226using -DEL transaction 229using -UPD transaction 231using -UPG transaction 233

lockusing -ADD transaction 225using -UPD transaction 232

occ-nameusing -ADD transaction 224using -CPY transaction 226using -DEL transaction 229using -GRP transaction 235using -UPD transaction 231

Header transaction parameters (continued)occ-name (continued)

using -UPG transaction 233ovrd

using -CPY transaction 227using -DEL transaction 230using -GRP transaction 236using -UPD transaction 232

pswdusing -ADD transaction 225using -CPY transaction 227using -DEL transaction 230using -GRP transaction 235using -UPD transaction 231

rec-nameusing -ADD transaction 224using -DEL transaction 229using -UPD transaction 231using -UPG transaction 233

status, using -UPD transaction 232target, using -CPY transaction 227tbl-name, using -DEL transaction 229vrs

using -ADD transaction 225using -CPY transaction 227using -DEL transaction 229using -GRP transaction 235using -UPD transaction 231using -UPG transaction 234

Heading content 409HEADING-1 attribute-type

for FIELD entity-occurrences 339on FIELD Detail Report 466used by Source Language Generation 576

HEADING-2 attribute-typefor FIELD entity-occurrences 340on FIELD Detail Report 466used by Source Language Generation 576

HIGH-RANGE attribute-typefor FIELD entity-occurrences 341on FIELD Detail Report 466

HIGH-RANGE-SIGN attribute-typefor PARTITION-COLUMN-VALUE

entity-occurrences 361on PARTITION-COLUMN-VALUE Detail

Report 478HIGH-RANGE-VALUE attribute-type

for PARTITION-COLUMN-VALUEentity-occurrences 362

on PARTITION-COLUMN-VALUE DetailReport 478


HIGH-RANGE-VALUE-LENGTH attribute-typeon PARTITION-COLUMN-VALUE Detail

Report 478High-Speed Directory (HSD)

-HSD RESET transaction in DDCFBLD utility 95-HSD RESET transaction report 97DDCFBLD utility 77Record Migration Facility special

consideration 128

IICF transaction

See DDICF utilityIDEAL

See CA IdealIDEAL-RESERVED attribute-type, on PROGRAM

Detail Report 485IDENT attribute-type

for JOB entity-occurrences 393for MODULE entity-occurrences 383for PROGRAM entity-occurrences 381for REPORT entity-occurrences 391for STEP entity-occurrences 395on JOB Detail Report 471on PROGRAM Detail Report 485

Impact Analysis Report 518—520IMPORT command (DDTRSLM) 175IMPORTED-DATE attribute-type

for MEMBER entity-occurrences 485for REPORT entity-occurrences 487on DATAVIEW Detail Report 463on PANEL Detail Report 476

IMPORTED-TIME attribute-typefor MEMBER entity-occurrences 485for REPORT entity-occurrences 488on DATAVIEW Detail Report 463on PANEL Detail Report 476

Importing plans 175INCLUDE-NIL-KEY attribute-type

for KEY entity-occurrences 354on KEY Detail Report 472

Indented Report 509example reports 510—517

Index FIELD entity-occurrences 335Index Report 524—529

example reports 526—529INIT-PARM attribute-type

on RECORD Detail Report 487on TABLE Detail Report 493

Input Creation Facility (DDICF)See DDICF utility

Inter-Product ComponentsSee CA IPC

INTERNAL-ACCESS attribute-typefor FIELD entity-occurrences 349on FIELD Detail Report 466

Inverted dataSee EDIT-PATTERN attribute-type, of FIELD

entity-occurrencesINVOKE-VAR attribute-type, on LIBRARY Detail

Report 473

JJCL requirements 19JOB entity-occurrences

7170 transaction 393Detail Report 471

JOB-GRADE attribute-typefor PERSON entity-occurrences 387on PERSON Detail Report 479

JOB-TITLE attribute-typefor PERSON entity-occurrences 387on PERSON Detail Report 479

JOIN-OVERRIDE attribute-type, on PLAN DetailReport 481

JUSTIFICATION attribute-typefor FIELD entity-occurrences 336on FIELD Detail Report 466on Field Report 503

KKEY entity-occurrences

5000 KEY transaction 3525010 KEY transaction 3555011 KEY transaction 3565012 transaction 3565100 KEY transaction 357attribute-values assigned by SET function 267change master key option 323Cluster Key 352CLUSTER-KEY-ID attribute-type for TABLE

entity-occurrences 324CLUSTER-KEY-LEN attribute-type for TABLE

entity-occurrences 324Detail Report 471duplicate master key option 322example transactions 358key IDs, shared 352

Index 633

KEY entity-occurrences (continued)Master Key 352Native Key 352transactions 351verified by VERIFY transaction 272, 273

KEY-ASM-NAME attribute-typefor KEY entity-occurrences 354on FIELD Detail Report 472

KEY-CMP-NAME attribute-typefor KEY entity-occurrences 354on KEY Detail Report 472

KEY-FIELD-LENGTH attribute-typefor KEY entity-occurrences 355on KEY Detail Report 472

KEY-FIELD-NAME attribute-type for KEYentity-occurrences 355

KEY-INDEX-NAME attribute-typefor KEY entity-occurrences 353on KEY Detail Report 472

KEY-TYPE attribute-typeon KEY Detail Report 472

KEY-USAGE attribute-type.

reserved for CA use 463Keywords in syntax diagrams 33

LLABEL attribute-type

for FILE entity-occurrences 317on FILE Detail Report 470

LANG-COMNT attribute-typefor FIELD entity-occurrences 335on FIELD Detail Report 466on Field Report 504used in Source Language Generation 565

LANGUAGE attribute-typefor MODULE entity-occurrences 383for PERSON entity-occurrences 388for PROGRAM entity-occurrences 381on PERSON Detail Report 479on PROCEDURE Detail Report 483on PROGRAM Detail Report 485

Language identification of a copybook produced bySource Language Generation 565

Language sublibrary 575LANGUAGE-CODE attribute-type

for PERSON entity-occurrences 388on PERSON Detail Report 480

LAST-FIELD attribute-type, on ELEMENT DetailReport 464

LENGTH attribute-typeconstraint validation concerns 613edit for CLUSTER-KEY-LEN attribute-value 324edit for MAX-RECORD-SIZE attribute-value 317for FIELD entity-occurrences 336for FIELD entity-occurrences VARYING

attribute-value 343for KEY entity-occurrences MAX-KEY-LENGTH

attribute-value 353on CONSTRAINT Detail Report 461on ELEMENT Detail Report 464on FIELD Detail Report 467on Field Report 502on KEY Detail Report 472on RECORD Detail Report 487on SYNONYM Detail Report 489on TABLE Detail Report 493on VIEW Detail Report 497used to assign the MAX-KEY-LENGTH

attribute-value 267verified by VERIFY transaction 272

LEVEL attribute-typeon FIELD Detail Report 467on Field Report 502

Level numbers assigned by Source LanguageGeneration 575

LIBRARIANSee CA-LIBRARIAN

LIBRARIAN-NAME attribute-typefor MEMBER entity-occurrences 373on MEMBER Detail Report 474

Libraries for CA Datacom products 19LIBRARY entity-occurrences

6100 transaction 372Detail Report 473, 474

LIBRARY-TYPE attribute-typefor LIBRARY entity-occurrences 372on LIBRARY Detail Report 473

Listing valid entity-type(s) 430LOCATION attribute-type, on NODE Detail

Report 476LOCK attribute-type

on Indented Report 524Lock levels

See also header transaction parameter, lockusing -ADD transaction 225using -UPD transaction 232

Lock, header parameter 225, 232LOGGING attribute-type for TABLE

entity-occurrences 323


LONG attribute-type, on FIELD Detail Report 467LOW-RANGE attribute-type


LOWER-BOUNDS attribute-typefor PARTITION-VALUE entity-occurrences 375on PARTITION-VALUE Detail Report 478

LOWER-VALUE-LEN attribute-type, onPARTITION-VALUE Detail Report 479

MMAINT-ACT attribute-type

for ELEMENT entity-occurrences 369for KEY entity-occurrences 355

Maintenance Reportfor DDUPDATE 219transaction collection 29

MASTER-KEY attribute-typechange option 323constraint validation concerns 611duplicate option 322for KEY entity-occurrences 352on KEY Detail Report 472

MAX-BLCK-SIZE attribute-type, on FILE DetailReport 470

MAX-KEY-LENGTH attribute-typefor KEY entity-occurrences 353on KEY DETAIL Report 472value assigned with SET DATABASE 267

MAX-RECK-SIZE attribute-type, on FILE DetailReport 470

MAX-RECORD-SIZE attribute-typefor FILE entity-occurrences 317for TABLE entity-occurrences 325on FILE Detail Report 470on TABLE Detail Report 493verified by VERIFY transaction 273, 275

MEDIA-ACCESS attribute-typefor FIELD entity-occurrences 348on FIELD Detail Report 467

MEDIA-LENGTH attribute-typefor FIELD entity-occurrences 349

MEMBER entity-occurrences6200 transaction 373Detail Report 474

MEMBER-ID attribute-typefor MEMBER entity-occurrences 373on MEMBER Detail Report 474

MEMBER-LANG attribute-typefor MEMBER entity-occurrences 373

MEMBER-LANG attribute-type (continued)on MEMBER Detail Report 474

MEMBER-NAME attribute-typeon DATAVIEW Detail Report 463on PANEL Detail Report 476on PROGRAM Detail Report 485

MEMBER-TYPE attribute-type, on MEMBER DetailReport 474

MESSAGE attribute-type, on PLAN DetailReport 481

MetaCOBOLSee CA-MetaCOBOL+

MODEL transaction (1000) 252MODEL-RULE (MDL) for relationships

defining with 2000 Relationship Transaction 303on Definitions Report 446

MODIFIED-DATE attribute-typeon PANEL Detail Report 476on PROGRAM Detail Report 485on REPORT Detail Report 488

MODIFIED-TIME attribute-typeon PANEL Detail Report 476on PROGRAM Detail Report 485on REPORT Detail Report 488

Modifiersfor Descriptors Report 453for Detail Report 458for Relationship Report 532in coding report request using pathing 428in coding the basic report 416

MODULE entity-occurrences7130 transaction 383Detail Report 475

MONITOR-NAME attribute-typefor FILE entity-occurrences 318on FILE Detail Report 470

MONITOR-NM attribute-typefor TABLE entity-occurrences 326on TABLE Detail Report 494

MOVE-ROW-TO-NEW-PARTITIONon TABLE Detail Report 494

MOVE-ROW-TO-NEW-PARTITION attribute-typefor TABLE entity-occurrences 325

MSGCLASS attribute-typefor JOB entity-occurrences 394on JOB Detail Report 471

MSGLEVEL attribute-typefor JOB entity-occurrences 394on JOB Detail Report 471

MSGNin DDUPDATE utility report 29

Index 635

MSGN (continued)in DDUTILTY utility report 29

Multiple levels of a relationship 422Multiple line transactions

coding 411continuation capability 27specifying report type 413

NNAME attribute-type

for PERSON entity-occurrences 390on PERSON Detail Report 480

NAME-LNG attribute-type, on LIBRARY DetailReport 473

Naming standards 167NATIVE-KEY attribute-type

constraint validation concerns 611for KEY entity-occurrences 353on KEY Detail Report 473

NBR-COPIES attribute-typefor REPORT entity-occurrences 392

Nested pathing-RPT NEST transaction 423-RPT NESTEND transaction 425

NEW-SEQ-NUMBERS attribute-type, on LIBRARYDetail Report 473

NEWNAME transaction (1000) 255NEWPSWD transaction (1000) 258NEXT IS . . . 530, 538NOD-BAS-ACCESS relationship used in impact

analysis 519NOD-FIL-ACCESS relationship used in impact

analysis 519NODE entity-occurrences

7211 transaction 398Datadictionary DATACOM-ID attribute-value 399Detail Report 476location 399

NULL-INDICATOR attribute-typeconstraint validation concerns 614for FIELD entity-occurrences 337on FIELD Detail Report 467on Field Report 503

NUMBER-CHANGES attribute-typeon DATAVIEW Detail Report 463on MEMBER Detail Report 474on PANEL Detail Report 476on PROGRAM Detail Report 485

NUMBER-COMPILES attribute-typeon DATAVIEW Detail Report 463

NUMBER-COMPILES attribute-type (continued)on MEMBER Detail Report 474on PANEL Detail Report 476on PROGRAM Detail Report 485

NUMBER-DIR-BLK attribute-type, on LIBRARYDetail Report 474

NUMBER-RUNS attribute-typeon DATAVIEW Detail Report 463on MEMBER Detail Report 474on PROGRAM Detail Report 485

OObjects, transporting (DDTRSLM utility) 159—204OBSOLETE

function 260OCC-MAP-RULE

relationship attributes 446OCC-MAP-RULE (MAP) for relationships

defining with 2000 Relationship Transaction 303Occurrences (entity-occurrences)

occ-namein -ADD transaction 224in -CPY transaction 226in -DEL transaction 229in -UPD transaction 231in -UPG transaction 233

specifying in requests 413OFFSET attribute-type

constraint validation concerns 613OP-SYS attribute-type

for JOB entity-occurrences 393for MODULE entity-occurrences 383for PROGRAM entity-occurrences 381on JOB Detail Report 471on PROGRAM Detail Report 485

OPERAT-SYSTEM attribute-type, on MEMBERDetail Report 474

ORDER attribute-typeon FIELD Detail Report 467on Field Report 504

Orderedchain 282relationship 278

ORDERED-RULE (ORD) for relationshipsdefining with 2000 Relationship Transaction 303on Definitions Report 446

ORGANIZATION attribute-typefor PERSON entity-occurrences 387on PERSON Detail Report 480


PPAGE-CHANGE-OPT attribute-type, on LIBRARY

Detail Report 474PANEL entity-occurrences


PANEL ID attribute-typeon PANEL Detail Report 476

PANEL-ID attribute-typefor PANEL entity-occurrences 377

PANVALETSee CA-PANVALET

PARAMETER-LIST entity-occurrencesDetail Report 477

PARENT attribute-typefor FIELD entity-occurrences 334on FIELD Detail Report 467on Field Report 502

Parenthesessyntax diagrams, use in 34

PARM-COMP-DATE attribute-type, on PROGRAMDetail Report 485

PARM-COMP-TIME attribute-type, on PROGRAMDetail Report 485

PARM-MDFD-DATE attribute-type, on PROGRAMDetail Report 486

PARM-MDFD-TIME attribute-type, on PROGRAMDetail Report 486

PARTITION attribute-typefor TABLE entity-occurrences 324on TABLE Detail Report 494

PARTITION path 22PARTITION-COLUMN-VALUE entity-occurrences

5200 PARTITION-COLUMN-VALUEtransaction 360

5203 PARTITION-COLUMN-VALUEtransaction 361

Detail Report 478example transactions 365transactions 360

PARTITION-VALUE entity-occurrences7011 to 7025 transactions 375Detail Report 478

partitioned tables 23, 453153 TABLE Transaction 3283160 TABLE Transaction 329DDBTGLM 60DDBTGLM transaction 45PARTITION predefined path 23

PASS-WORD attribute-type, on PERSON DetailReport 480

PASSWORD attribute-typeon Indented Report 524

PASSWORD-OPTION attribute-type, on LIBRARYDetail Report 474

Passwordsassigning 258changing 258deleting 259

Pathdefinition

-DEF TRACE transaction 419for Batch Transaction Generator 56for DDUTILTY reports 418for Source Language Generation 572nested pathing 423nested pathing -NEST transaction 423nested pathing -NESTEND transaction 425STANDARD path 422

Path definition 22—26-DEF TRACE transaction

-DEF TRACEB transaction 26-DEF TRACEF transaction 26in defining a path 25

transaction format 24PERSON entity-occurrences

7150 Job transaction 3877155 Language transaction 3887156 Name transaction 390Detail Report 479transactions 386

PIPELINE-OPTION attribute-typefor TABLE entity-occurrences 324on TABLE Detail Report 494

PL/Icopybooks 563sample copybook 580value in Source Language Generation 565

PLAN entity-occurrencesDetail Report 481

Plan importation consideration 175PLANNAME attribute-type, on STATEMENT Detail

Report 488PLN-CBSIO attribute-type, on PLAN Detail

Report 481PLN-CLOSE attribute-type, on PLAN Detail

Report 481PLN-COMPAT attribute-type, on PLAN Detail

Report 481

Index 637

PLN-ISOLATION attribute-type, on PLAN DetailReport 482

PLN-MIN attribute-type, on PLAN Detail Report 482PLN-PRTY attribute-type, on PLAN Detail

Report 482PLN-SEC attribute-type, on PLAN Detail

Report 482PLN-VALID attribute-type, on PLAN Detail

Report 482PRECISION attribute-type

for FIELD entity-occurrences 339on FIELD Detail Report 467on Field Report 503

PREFIX-PANEL attribute-type, on PANEL DetailReport 476

PREVIOUS-VERS attribute-typeon Detail Report 459on Text Report 553

PRIORITY attribute-typefor JOB entity-occurrences 394on JOB Detail Report 471

PROCin DDUPDATE utility report 29in DDUTILTY utility report 29

PROCEDURE entity-occurrencesDetail Report 483

PROD-DATES attribute-type, on MEMBER DetailReport 474

PROD-TIME attribute-type, on MEMBER DetailReport 475

PRODUCT-ID attribute-typeon AUTHORIZATION Detail Report 460on MEMBER Detail Report 475on PANEL Detail Report 476on PERSON Detail Report 480on PROGRAM Detail Report 486

PRODuction statusspecifying with -CPY header transaction 227specifying with -DEL header transaction 229specifying with -UPD header transaction 232

PROFILE-CODE attribute-typefor FIELD entity-occurrences 340on FIELD Detail Report 467

PROGRAM attribute-type, on PLAN DetailReport 482

PROGRAM entity-occurrences7120 transaction 381Detail Report 484

PROGRAM-NUMBER attribute-type, on PROGRAMDetail Report 486

Programscomma

repeat symbol, use in 36parentheses

syntax diagrams, use in 34punctuation

syntax diagrams, use in 33PUNCH-OPTION attribute-type, on LIBRARY Detail

Report 474Punctuation marks in syntax diagrams 33

RRANDOM-NAME attribute-type, on FILE Detail

Report 470REC-TYP-NAME attribute-type

for FILE entity-occurrences 319on FILE Detail Report 470

RECORD entity-occurrences3200 transaction 330Detail Report 486

RECORD-FORMAT attribute-typefor FILE entity-occurrences 317on FILE Detail Report 470

RECORD-NAME attribute-typeon Indented Report 524

RECOVERY attribute-typefor TABLE entity-occurrences 323on TABLE Detail Report 494

REDEFINES attribute-typeconstraint validation concerns 615for FIELD entity-occurrences 337from DDICFLM utility 119on FIELD Detail Report 467

REFRESH attribute-type, on PROGRAM DetailReport 486

REGION-SIZE attribute-typefor JOB entity-occurrences 393for STEP entity-occurrences 395on JOB Detail Report 471

Relationshipsadding definition 302characteristics 303impact of renaming the entity-occurrence 256implementing 277name 279Report 530Report, example 532—539transaction (2000) 302

RELEASE attribute-type, on SYSTEM DetailReport 490


REPEAT attribute-typeconstraint validation concerns 614for FIELD entity-occurrences 337on FIELD Detail Report 468on Field Report 503

REPORT entity-occurrences7160 transaction 391Detail Report 487

REPORT-ID attribute-type, on SYSTEM DetailReport 488

Reporting valid entity-type(s) 430Reports

adding comments in requests 408Alias Report 441automatic using DDUPDATE Utility 219DDBTGLM 63—76DDCFBLD

(-CXX BUILD) 84(-CXX CATALOG) 91(-HSD RESET) 97

DDICF 115DDRMFLM 144DDRTVCAT

CXX CATALOG 157DDUPDATE Maintenance 219Definitions Report 446Descriptors Report 452Detail Report 457ending a request 416Error Recap Report 409Field Report 501generic selection in request 414headings 409Indented Report 509Index Report 524Maintenance Report 409modifiers 416path request 418Relationship Report 530request 412requesting

using DDUPDATE Utility 220using DDUTILTY 408

restricting status/version 414Schema Report 540Source Language Generation

Assembler example 583COBOL example 578PL/I example 580Reporting Facility example 585

SQL Column Report 544

Reports (continued)starting the report 425Text Report 553types of 407types, specifying 413using the override code 416

REQUIRED attribute-type, on FIELD DetailReport 468

REQUIRED-RULE (REQ)for relationships on Definitions Report 446

REQUIRED-RULE (REQ) for relationshipsdefining with 2000 Relationship Transaction 303

RESOURCE-DATE attribute-typeon DATAVIEW Detail Report 463on PANEL Detail Report 477on PROGRAM Detail Report 486

RESOURCE-TIME attribute-typeon DATAVIEW Detail Report 463on PANEL Detail Report 477on PROGRAM Detail Report 486

RESTOREtransaction (1000) 261

Reversed dataSee EDIT-PATTERN attribute-type, of FIELD

entity-occurrencesROSCOE

See CA Roscoe IEROSFD macro

See BLKSIZE= parameterRPS attribute-type

for AREA entity-occurrences 312for FILE entity-occurrences 318on AREA Detail Report 460on FILE Detail Report 470

RTV BASIS transaction 154RUN-STATUS attribute-type

on PANEL Detail Report 477on PROGRAM Detail Report 486

RUN-TIME attribute-typefor JOB entity-occurrences 394for STEP entity-occurrences 395on JOB Detail Report 471on STEP Detail Report 489

SSCAN attribute-type, on FILE Detail Report 470Schema Report 540

example report 542—543SECURITY-CODE attribute-type

for FIELD entity-occurrences 368

Index 639

SECURITY-CODE attribute-type (continued)on ELEMENT Detail Report 464

SEGMENT-NM attribute-typeon RECORD Detail Report 487on TABLE Detail Report 494

Selection, generic 414SEMANTIC-MASK attribute-type


SEMANTIC-TYPE attribute-typefor FIELD entity-occurrences 344on FIELD Detail Report 468

SET EXPORT FORMAT PREVIOUS RELEASEcommand (DDTRSLM) 186

SET IMPORT COLLISION command(DDTRSLM) 187

SET TRACE command (DDTRSLM) 188SET transaction (1000) to generate

attribute-values 264SET USER command (DDTRSLM) 185SHORT-ATTR-NAME attribute-type


SHORT-SYSTEM-ID attribute-typefor SYSTEM entity-occurrences 380on SYSTEM Detail Report 490

SHORT-TITLE attribute-type, on PANEL DetailReport 477

SIGN attribute-typeconstraint validation concerns 618for FIELD entity-occurrences 336on FIELD Detail Report 468on Field Report 503

SIGNIFICANT-CHG attribute-type, on FIELD DetailReport 468

Simple FIELD entity-occurrences 335SKIP-NTH attribute-type, on FILE Detail Report 470SKIP, in -DEF TRACE transactions 421SLACK attribute-type

for AREA entity-occurrences 312for FILE entity-occurrences 318on AREA Detail Report 460on FILE Detail Report 470

Source label of a FIELD entity-occurrence 565Source Language Generation

-RPT START 568-UTL COPY 569-UTL LANGUAGE 564-UTL LIBRARY 563-UTL MODE 564CA Datacom/DB Reporting Facility

considerations 576

Source Language Generation (continued)control statements

Assembler example 583COBOL example 578PL/I example 580Reporting Facility example 585

defining a path 572example transactions 572generated copybooks

sample Assembler copybook 583sample COBOL copybook 578sample PL/I copybook 580sample Reporting Facility copybook 585

outputlevel numbers 575printed 574punched 574

using 561—593z/OS sample JCL 577z/VSE sample JCL 577

SPACE-MNGMNT attribute-typefor AREA entity-occurrences 312for TABLE entity-occurrences 324on AREA Detail Report 460

SQLviews

Datacom View Generator 562SQL attribute-type

on Field Report 501SQL Column Report 544

example reports 547—552SQL Indented Report for impact analysis 519SQL Precompiler option impact on SQLNAME

for AREA entity-occurrences 313for DATABASE entity-occurrences 309for TABLE entity-occurrences 327, 328

SQL processingAGR-SQLNAME attribute-type 465, 471attribute-values verified for SQL accessible

tables 273AUTHID

on CONSTRAINT Detail Report 461on PARAMETER-LIST Detail Report 477on PLAN Detail Report 481on PROCEDURE Detail Report 483on SYNONYM Detail Report 489on TABLE Detail Report 491on TRIGGER Detail Report 495on VIEW Detail Report 497

Column Report 544databases with SQL tables, cataloging 80, 87


SQL processing (continued)objects, transporting 159—204Schema Report 540tables accessible, making 107values assigned with SET DATABASE 268

SQL reserved words 167SQL-ACCESS

on DATABASE Detail Report 462SQL-ACCESS attribute-type

attribute-value assigned with VERIFYDATABASE 273

for TABLE entity-occurrences 494on CONSTRAINT Detail Report 461on PARAMETER-LIST Detail Report 477on PROCEDURE Detail Report 484on SYNONYM Detail Report 489on VIEW Detail Report 497

SQL-CATAL-DATE attribute-type, on TABLE DetailReport 494

SQL-CATAL-TIME attribute-type, on TABLE DetailReport 494

SQL-DATE, SQL-TIME, SQL-STMP forSEMANTIC-TYPE attribute-value 344

SQL-INTENT attribute-typefor TABLE entity-occurrences 327impact on FIELD entity-occurrence

attribute-values 268impact on SQL-ACCESS attribute-type 273on TABLE Detail Report 494verify with VERIFY transaction 273

SQL-SECURITY attribute-typefor DATABASE entity-occurrences 309on DATABASE Detail Report 462on SYNONYM Detail Report 490on TABLE Detail Report 494on VIEW Detail Report 497value assigned with SET DATABASE 265

SQLNAMEvalue in Source Language Generation 566

SQLNAME attribute-typeAGR-SQLNAME on FIELD Detail Report 465constraint validation concerns 610for AREA entity-occurrences 313for DATABASE entity-occurrences 309for FIELD entity-occurrences 345for KEY entity-occurrences 357for TABLE entity-occurrences 327

referenced on FIELD Detail Report 465referenced on KEY Detail Report 471

on AREA Detail Report 460on CONSTRAINT Detail Report 461

SQLNAME attribute-type (continued)on DATABASE Detail Report 462on FIELD Detail Report 468on Indented Report 509on KEY Detail Report 473on PARAMETER-LIST Detail Report 477on PLAN Detail Report 482on PROCEDURE Detail Report 484on Schema Report 540on SYNONYM Detail Report 489on TABLE Detail Report 494on VIEW Detail Report 497verify with VERIFY transaction 273

STANDARD pathusing 22, 422

STARSee CA Datacom STAR

START 425START-OF-CHAIN 530, 538Starting point in a path 425STATEMENT

Detail Report 488STATEMENT-ID attribute-type, on STATEMENT

Detail Report 488Status

header transaction parameter 232specifying in requests 414

restricting version or status 414, 416using modifiers 416using the override code 416

STATUS attribute-typeon Alias Report 441on Detail Report 458on Field Report 501on Indented Report 509on Index Report 524on Schema Report 540on Text Report 553

STEP entity-occurrences7180 transaction 394Detail Report 489

STM-VALID attribute-type, on STATEMENT DetailReport 489

STORAGE attribute-typefor FIELD entity-occurrences 343on FIELD Detail Report 468

STRINGDELIM attribute-type, on PLAN DetailReport 482

STRUCT-CHNG-DT attribute-type, on DATAVIEWDetail Report 463

Index 641

STRUCT-CHNG-TM attribute-type, on DATAVIEWDetail Report 463

SYNCH-CODE attribute-type, on ELEMENT DetailReport 464

SYNONYM entity-occurrencesDetail Report 489

Syntaxcoding multiple line transactions 27defining a path 22entering comments 28establishing user identification 20general 20using abbreviations 28

Syntax diagramsreading, how to 33—38

SYSIN attribute-type, on FILE Detail Report 471SYSOUT attribute-type, on FILE Detail Report 471SYSTEM entity-occurrences


System Resource Table (SRT)CPYLVST= parameter impact on Source

Language Generation 575CPYNDLM= parameter impact on Source

Language Generation 575MAXLVLS= impact on path definition 572Record Migration Facility special

consideration 128UTLPRE= parameter impact on Source Language

Generation 575SYSTEM-TYPE attribute-type, on SYSTEM Detail

Report 490SYSTEM-USER attribute-type

for SYSTEM entity-occurrences 379on SYSTEM Detail Report 490

TTABLE entity-occurrences

3150 TABLE transaction 3223151 TABLE transaction 3253152 TABLE transaction 3263153 TABLE transaction 3283160 TABLE transaction 329attribute-values assigned by SET function 265attribute-values verified for SQL 273cataloging databases with SQL accessible 87Detail Report 490example transactions 330SQL accessible, making 107transactions 321

TABLEKIND attribute-type, on TABLE DetailReport 495

TARGET-DATE attribute-type, on PROGRAM DetailReport 486

Target, header parameter 227TEST-DATE attribute-type, on MEMBER Detail

Report 475TEST-TIME attribute-type, on MEMBER Detail

Report 475Text

APPLY transaction (1000) 246applying with the 1000 APPLY transaction 246copying 291copying classification 291

all text class to same text class 292all text to a new text class 293excluding all text 294excluding specific text classification 293sharing text 292to a new text class 291

deleting 294example reports 556—561example transactions 298impact of renaming the entity-occurrence 256inserting 295naming 290renaming 290replacing 296Report 553

TEXT transactions (1200)1200 TEXT ADD 2891200 TEXT CLS 2891200 TEXT DEL 2941200 TEXT INS 2951200 TEXT REP 296introduction 288

TIME-LAST-CHG attribute-typeon Detail Report 459on Field Report 501on Text Report 553

TIMEFORM attribute-type, on PLAN DetailReport 482

Trace statements-DEF TRACEB 421-DEF TRACEF 421defining 419

Transaction collections, processing 20TRANSFER transaction (1000) 270TRIAL IMPORT command (DDTRSLM) 175, 182TRIGGER entity-occurrences

Detail Report 495


TYPE attribute-typeconstraint validation concerns 614for FIELD entity-occurrences 335for RECORD entity-occurrences 331on FIELD Detail Report 468on RECORD Detail Report 487

TYPE-MODULE attribute-type, for MODULEentity-occurrences 383

TYPE-NUMERIC attribute-typeconstraint validation concerns 618for FIELD entity-occurrences 337on FIELD Detail Report 468

TYPE-PROGRAM attribute-typefor PROGRAM entity-occurrences 381on PROGRAM Detail Report 486

UUNCHANGEABLE attribute-type


UNIQUE attribute-typeconstraint validation concerns 612for KEY entity-occurrences 357on KEY Detail Report 473

Universal FIELD entity-occurrences, modeling 252Unlabeled storage, indicated by Source Language

Generation Facility 566UPDATE-DB attribute-type, on PROGRAM Detail

Report 486UPDATE-DB2 attribute-type, on PROGRAM Detail

Report 486UPDATE-INTENT attribute-type

for DATAVIEW entity-occurrences 397on DATAVIEW Detail Report 464

UPDATE-PRINT-OP attribute-type, on LIBRARYDetail Report 474

UPPER-BOUNDS attribute-typeon PARTITION-VALUE Detail Report 479

UPPER-BOUNDS attribute-typesfor PARTITION-VALUE entity-occurrences 376

UPPER-VALUE-LEN attribute-type, onPARTITION-VALUE Detail Report 479

USER-ACCESS attribute, for FIELDentity-occurrences 349

User-access-code 410User-defined

transactions (9000) 401User-written exits

DDRMFLM samples (Assembler) 599—603

USERID attribute-type, on PERSON DetailReport 480

UtilitiesDDBTGLM utility 41—76DDCFBLD utility 77—100DDICF utility 101—123DDRMFLM utility 125—148DDRTVCAT utility 149—158DDTRSLM utility 159—204DDUPDATE utility 208—402DDUTILTY utility 406—593

UTLPRE=, for FIELD entity-occurrences 575

VValid entity-type(s), reporting 430VALUE attribute-type

for FIELD entity-occurrences 337on FIELD Detail Report 469on Field Report 503

Value FIELD entity-occurrences 335Variables in syntax diagrams 33VARYING attribute-type


VERIFY functionDDRTVCAT utility 149with DDCFBLD utility 77

VERIFY transaction (1000) 271Version (vrs)

header transaction parameter 225specifying in requests 414

VIEW entity-occurrencesDetail Report 497

View Generator 562

WWORKSPACE attribute-type, on PLAN Detail

Report 482WRITE-CONTROL attribute-type, on PANEL Detail

Report 477

Index 643

Documents

CA Datacom Datadictionary · CA Product References This document references the following CA products: CA Datacom®/DB (CA Datacom/DB) CA Datacom® CICS Services (CA Datacom CICS