The Connect CDC SQData installation guide for UNIX* recommends using one of two locations for the base product and <SQDATA_DIR> as the Environmental Variable Name, if they choose to use one:
/opt/sqdata or /home/<sqdata_user>/sqdata
While either location works fine for the product installation, Script development typically requires a different structure to accommodate the organization of development into areas of responsibility, including the associated "application" and Testing or Production environments. This document will refer to the locations most commonly used on Linux and Windows and <SQDATA_VAR_DIR> as the Environmental Variable Name, if they choose to use one:
/var/opt/sqdata/<application>/<environment>
For customers that choose to install the base product in the home directory of a special user account:
/home/<sqdata_user>/<application>/<environment>
The nature of Apply Engine scripts also requires a structure accommodating similar items from dissimilar platforms such as DDL from DB2 and Oracle. For that reason the following directory nodes are recommended at the next level for script development and parts management:
| ./<directory_name> | Description |
|---|---|
| ENGINE | Main 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 Document Type 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 |
| rpts | Optional Report archive directory on linux, managed by local shell scripts |
| logs | Optional Log archive directory on linux, managed by local shell scripts |
Notes:
- While it may be more convenient to user lower case directory names, if your environment includes the z/OS Platform, consideration should be given to re-usability as some z/OS references must be in Upper Case.
- 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 atypical 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.
- Development on a Windows Platform is very similar to UNIX and we recommend using the same directory structure described for UNIX. See the $Start_Here_Windows for more details regarding Installation directories.
- Engine reports will all have the same name. While infrequently used they and corresponding logs can be timestamped and archived using shell scripts at startup.