Dependencies Properties

A dependency in the dependency graph links a source (a file or an object) to a target and carries a type (see Link Types). Some dependencies also carry properties: additional facts about the link that do not fit in the type, such as the symbolic expression a dataset name was resolved from, or the DD statements a JCL step allocates to a program.

This page lists every property the dependency analysis can produce.

Where properties appear

Properties are attached to the dependency, inside the dependencies array of the source node in the graph JSON. They form a flat map of string keys to string values.

{
   "name": "CARDJOB.jcl",
   "path": "jcl/CARDJOB.jcl",
   "type": "JCL",
   "dependencies": [
       {
           "dependencyType": "Control card; Resolved Symbol",
           "name": "CARDMBR",
           "path": "cards/CARDMBR",
           "type": "CTL",
           "properties": {
               "symbolic": "&RUNPARM",
               "JCL.PartitionedDataSet": "APP.CTRL.CARDLIB",
               "lineNo": "12"
           }
       }
   ]
}

Rules that apply to all properties:

• A property is present only when it applies. There are no empty values.
• Properties are carried by resolved dependencies, by dependencies typed "System" and by "Missing …" dependencies alike.
• Nodes (files and objects) carry no properties; only dependencies do.
• When several statements produce the same dependency (same source, same target, same type), the dependencies are merged into one. Most properties then keep one value. The properties marked accumulating below keep every value instead: the values are separated by ;, sorted and de-duplicated.
• The order of the keys inside properties is not significant.

Common properties

Available for every language whose statements are analyzed line by line.

lineNo

Line of the source file where the statement creating the dependency was found (first line is 1).

When the dependency type has several parts separated by ; (for example "Exec program; Program Specification Block"), lineNo has as many parts, separated by ; and in the same order: "14;14". A part is empty when no line was recorded for that type (";22"). A statement type found on several lines gives a bracketed, space-separated list of lines: "[5 21]".

"dependencyType": "Call; [Dynamic] Call",
"properties": { "lineNo": "[120 187];[120 187]" }

lineIndex

Position of the statement within its line when several statements share one source line ("0" for the first). Present only when lineNo is a single line number.

JCL properties

Produced by the analysis of JCL and PROC files. See the JCL page for the statements involved.

symbolic — accumulating

The dependency target was written with symbolic parameters (&NAME) and the name was resolved from the SET statements, EXEC overrides and PROC defaults visible from the calling JCL. symbolic keeps the expression as written in the source, before resolution; the dependency name holds the resolved value and the dependency type gains "Resolved Symbol".

When several expressions resolve to the same target (&FIXLIB(CARD2) and &JOBLIB(CARD2) with SET FIXLIB=LIB.DATA.TEST,JOBLIB=LIB.DATA.TEST), the expressions are accumulated.

"dependencyType": "PDS use; Resolved Symbol",
"name": "LIB.DATA.TEST",
"properties": { "symbolic": "&FIXLIB;&JOBLIB" }

JCL.PartitionedDataSet

On a "Control card" dependency created from DSN=pds-name(member): the name of the PDS, so that the fully qualified dataset name can be rebuilt when the control card is missing from the project.

"dependencyType": "Control card",
"name": "MYCTL",
"properties": { "JCL.PartitionedDataSet": "MY.LIB.AWS" }

JCL.ddnameToDataset — accumulating

On the "Exec program" dependency of an EXEC PGM= step: the datasets allocated to the program by the DD statements of the step. Each entry is STEP.DDNAME=DSN (DDNAME=DSN when the step has no name). Entries are sorted alphabetically; a concatenated DD repeats its STEP.DDNAME once per dataset; when the same program runs in several steps or several JCLs the entries are accumulated on the single dependency.

Not listed: DD *, DD DATA, DD DUMMY, SYSOUT=, NULLFILE, temporary datasets (&&), names containing %% and names with unresolved symbolic parameters. Dependencies created by EXEC PROC= do not carry this property.

"dependencyType": "Exec program",
"name": "CBTRN02C",
"properties": { "JCL.ddnameToDataset": "STEP1.ACCTFL=AWS.M2.CARDDEMO.ACCTDATA.PS;STEP1.INPUT=AWS.M2.CARDDEMO.FIRST.PS;STEP1.INPUT=AWS.M2.CARDDEMO.SECOND.PS" }

JCL.gdgOperation

On a dataset dependency written with a relative generation, DSN=name(+1), (0), (-1): the relative generation, without parentheses. The dependency type gains "GDG increment", "GDG latest" or "GDG decrement" and the target is the GDG base.

"dependencyType": "GDG latest; Read Dataset",
"name": "AWS.M2.CARDDEMO.SYSTRAN",
"type": "GDG BASE",
"properties": { "JCL.gdgOperation": "0" }

JCL.db2Plan — accumulating

On the "Exec program" dependency of a step that attaches to DB2 through a DDITV02 control card: the DB2 plan name(s) read from the card. Several plans are accumulated.

"dependencyType": "Exec program",
"name": "APPLPGM1",
"properties": { "JCL.db2Plan": "RBXPD01;RBXPD03" }

FTP.RemoteHost

On an "FTP put" or "FTP get" dependency created from the in-stream commands of an EXEC PGM=FTP step: the remote host, taken from the PARM= of the EXEC statement or from the first in-stream line that is not an FTP subcommand. The target dataset is typed "FTP Dataset" when it is not in the project.

"dependencyType": "FTP put",
"name": "PROD.OUT.DAILY",
"type": "FTP Dataset",
"properties": { "FTP.RemoteHost": "192.168.10.5" }

Cobol and PL/I properties

variableName

On a dynamic call — CALL variable, EXEC CICS LINK/XCTL/LOAD PROGRAM(variable) — the name of the variable holding the program name. Present whether the call was resolved from a value found by the analysis (type "[Dynamic] Call", target = the program) or not (target typed "Missing Dynamic Call Value", name = the variable). When several variables lead to the same target they are listed, separated by , .

"dependencyType": "Call; [Dynamic] Call",
"name": "PGM-VAR",
"type": "Missing Dynamic Call Value",
"properties": { "variableName": "PGM-VAR" }

See the Cobol page, "Dynamic dependency".

RPG properties

procedureName

On a "Call procedure" dependency (fixed or free form): the name of the procedure called, as declared in the target file. The dependency itself points to the file declaring the procedure.

"dependencyType": "Call procedure",
"name": "define-proc.sqlrpgle",
"properties": { "procedureName": "ControlCpt" }

RPG.fileUsage, RPG.fileAddition, RPG.fileDelete

On an "F line", "Declare file" or "Declare printer file" dependency: how the program opens the file.

• RPG.fileUsage: one of Input, Output, Update, Combined (F specification column 17, or usage(...) of dcl-f).
• RPG.fileAddition: present with the value Add when records can be added (fixed form: A in position 20 of an input or update file; free form: *output listed in usage(...) together with *input, *update or *delete, except on a WORKSTN file where *input *output is Combined).
• RPG.fileDelete: present with the value Delete when records can be deleted (fixed form: every U file, as IBM defines Update as delete-capable; free form: *delete listed in usage(...)).

"dependencyType": "Declare file",
"name": "ADDF",
"type": "Missing DDS",
"properties": { "RPG.fileUsage": "Update", "RPG.fileAddition": "Add", "RPG.fileDelete": "Delete" }

Scheduler properties

Produced by the CA7, TWS and Control-M analyses on "Exec Next Scheduled Task" dependencies between scheduled tasks. See the scheduler support summary.

schedulerDependencyType

UNCONDITIONAL when the successor task always follows the predecessor, CONDITIONAL when it is triggered by a condition (TWS ADCNS/ADCNC, Control-M ON … DO COND / DO FORCEJOB). CA7 dependencies are always UNCONDITIONAL.

schedulerDependencyDescription — accumulating

On CONDITIONAL dependencies: the condition, in a compact colon-separated form.

• TWS: ADCNS:::, for example ADCNS:RC:EQ:0004 (return code equals 4) or ADCNS:ST:EQ:E (status is Error).
• Control-M: DOCOND: or DOFORCEJOB:.

Several conditions between the same two tasks are accumulated.

"dependencyType": "Exec Next Scheduled Task",
"name": "ZPSFWK-ENDED",
"type": "Missing Scheduled Task",
"properties": { "schedulerDependencyType": "CONDITIONAL", "schedulerDependencyDescription": "DOCOND:ZPSFWK-ENDED" }

Summary