Directory Hierarchy |
Scroll |
Linux is the most common platform for Engine development and execution. For that reason only we start with a recommended Directory Hierarchy for Linux. These will also apply with little or no change on Windows and AIX.
The Connect CDC SQData installation guide for UNIX (Linux and AIX) recommends using one of two locations for the base product and <SQDATA_DIR> as the Environmental Variable Name, if you choose to use one:
/opt/sqdata or /home/<sqdata_user>/sqdata
While either location works fine for the product installation, Apply Engine 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:
1.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.
2.Engine scripts are typically Platform specific but can typically be executed on another type of Platform, eg z/OS and UNIX without modification as long as Source and Target connectivity is supported.
3.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.
4.Throughout the remainder of this document, part locations will usually refer only to the last node of a standard UNIX or Windows directory hierarchy or z/OS Partitioned Dataset.
5.Development on a Windows Platform is very similar to UNIX and we recommend using the Variable Directories structure described for UNIX. See the Windows Installation Guide for more details regarding Installation and Variable directories.
6.Engine reports names will be reused at runtime. While infrequently used they and corresponding logs can be timestamped and archived using shell scripts at startup.