Connect CDC SQData

Apply Engine scripts must be successfully parsed before they can be used by the actual engine executable program. Historically parsing an Apply Engine script was performed independently from the execution of the Engine and occurred while an engine script was under development and a final time as part of the migration from one environment to another, for example from Test to Production. The idea was and still is to eliminate the need for changes to the engine script itself during migration while providing the means to modify critical elements using a "parameter" during migration.

Occasionally there was a need to provide a parameter at run-time and while that could be accommodated by either a two step parse/run shell script (or zOS JCL) or by reading a control file at startup, it is now possible to perform them both in a single step using the SQDENG program. Today, SQDPARSE and SQDATA are merely alias names for SQDENG with slightly different control parameters. You can choose which method you prefer however there are some things to consider:

•The Apply Engine script often "includes" various parts files like relational DDL describing tables or COBOL copybooks describing IMS DBDs/Segments or VSAM files. Those parts files must be accessible when parsing. That precludes parsing an engine on one platform, even one running a different operating system, and then merely moving the parser output file, typically referred to as a .prc file to another platform for execution.

•Apply Engines started using a local Engine Controller SQDaemon only require the .prc file name in the daemon's sqdagents.cfg file when the SQDATA entry point to SQDENG is used. That means no changes to the Engine Controller daemon configuration file is required as part of migration.

•Apply Engines started directly at the command line or using a shell script that includes the parms required during the Parse step are easy to run, making SQDENG a good option while testing or when running without an Engine Controller SQDaemon as is typical for a "containerized" Apply Engine.

Remember, SQDENG does the same thing as a two step SQDPARSE/SQDATA process and the two can both be used at different stages of development and testing. The decision regarding which to use in production is best made after considering how the production environment will be managed and migration will be performed.

Finally, consider that the Apply Engine script must be successfully parsed before it can be executed. An SQDPARSE return code of 0 indicates that the script parsed successfully. A return code of 4 indicates that one or more target fields were not mapped. A return code of 8 indicates syntax or consistency check in the source Apply Engine script or "included" parts files.

The following syntax is used for executing the Parser in all environments. Examples of invoking the Parser on specific platforms are provided later in this section.

 

Syntax

SQDPARSE  <script_in>|<engine>.sqd  <script_out>|<engine>.prc [<parm1>  <parm2> …<parmn>] [LIST=ALL|SCRIPT] [>  <report_output>|<engine>.prt]

 

Keyword and Parameter Descriptions

<script_in> |<engine>.sqd  The name of the Apply Engine script file used as input to the Parser. The suggested file extension for this file in the Multiplatforms environment is sqd.

<script_out>|<engine>.prc  The name of the file created during the parse process. This file will be used as input to the SQDATA/SQDENG program. The suggested file extension for the parsed script file is in the Multiplatforms environment is prc.

[ <parm1>  <parm2> …<parmn>]  One or more optional parameters passed to the parser. See section Substitution Parameters in the Parser Directives section above for an explanation of the two types of parameters supported: Named and Positional. The following examples will use the recommend Named parameter syntax.

[LIST=ALL|SCRIPT]  Specifies the amount of information written in the Parser report. LIST=ALL  (default) specifies that all of the expanded descriptions and the script source are to be written to the report. LIST=SCRIPT specifies that the script source is to be written to the report.

[>  <report_output>|<engine>.prt] The name of the Parser report file created during the Parser process. If this parameter is not specified, the report output will be written to the screen/terminal in the Multiplatform environment and to SYSOUT in the z/OS environment. The suggested file extension for this file is in the Multiplatforms environment is prt.

The following table lists the options available for executing the Parser based on the operating system platform.