The Connect CDC (SQData) installation guide for z/OS recommends a PDS naming structure something like this:
SQDATA.<major_version>.<content_type> e.g: SQDATA.V400.CNTL
While that structure works well for the product installation, Script development typically requires a different structure to accommodate the organization of development into areas of responsibility, e.g: Test and Production. The nature of the product will also require some adjustment to accommodate similar items from dissimilar platforms such as DDL from DB2 and Oracle. For that reason the following PDS suffix nodes are recommended for script development facilitating organization specific, higher level nodes:
PDS .suffix | Description |
---|---|
ENGINE | Main Engine scripts |
SQDOBJ | Parsed Engine scripts |
CDCPROC | CDC Engine Called Procedures referenced by #INCLUDE |
LOADPROC | Load (UnLoad) Engine Called Procedures referenced by #INCLUDE |
DSDEF | Datastore Definition referenced by #INCLUDE |
<TYPE>DDL | RDBMS specific DDL, eg DB2DDL, ORADDL, MSSQLDDL, etc |
IMSDBD | IMS DBD |
IMSSEG | IMS Segment Copybooks |
<TYPE>COB | System specific COBOL copybooks, eg: VSAMCOB, SEQCOB (sequential files) |
XMLDTD | XML DTD definitions that will be used in a DESCRIPTION command |
<TYPE>CSR | RDBMS specific Cursors, eg DB2CSR, ORACSR,etc |
<TYPE>LOAD | RDBMS specific Load Control, eg DB2LOAD, ORALOAD ,etc |
<TYPE>JCL | SYSTEM specific Engine / Capture JCL, eg IMSJCL, DB2JCL |
Notes:
- Engine scripts are typically Platform specific in that they cannot be used on another type of Platform, eg z/OS and UNIX without at least minor modification.
- Called Procedures can frequently be used with little or no changes on another platform, even when they contain platform specific Functions, unless they require direct access to a datastore on another platform, an uncommon requirement.
- Throughout the remainder of this document, part locations will usually refer only to the last node of standard z/OS Partitioned Datasets and UNIX or Windows directory hierarchy.