Reviewing Dependency Analysis
This section discusses:
-
Understanding Dependency Analysis
-
Reviewing Data Conversion Runtime Rules
Understanding Dependency Analysis
The table usage information identified in the Initial Analysis is subsequently used to determine the dependencies between AE Steps. The Step Dependency Information is then aggregated to the “Root Section” level where a Root Section is defined as a row in the PS_PTIA_DCAEPGMS table (PTIA_UPG_PATH, PTIA_UPG_GROUP, SEQ_NUM, AE_APPLID, AE_SECTION, ACTIVE_FLAG, PTIA_CONV_TYPE, PTIA_UPG_GROUP_LVL).
Reviewing Data Conversion Runtime Rules
The following rules are the data conversion runtime rules:
-
Dependencies are derived from tables referenced in SQL or PeopleCode actions in Upgrade Sections.
-
Dependencies follow the Upgrade Group sequencing. If Section ABC in Upgrade Group 1 updates a given table, then any Section assigned a higher sequence than ABC that updates or queries that same table cannot run until Section ABC is complete.
-
Upgrade groups are further grouped into levels. For example, objects defined in Level 2 are dependent on objects defined in Level 1. Additionally, objects defined in Level 3 are dependent on objects defined in Level 1 and Level 2.
-
Upgrade groups within the same level do not depend on each other. If Section QWE in Upgrade Group 2 updates table FFF and Section ASD in Upgrade Group 3 also updates table FFF and Upgrade Groups 2 and 3 are at the same level, there is no dependency created.
-
Upgrade groups create dependencies on sections within their own upgrade group and upgrade groups of lower levels. If Section ABC in Upgrade Group 1 updates table FFF and Section QWE in Upgrade Group 2 also updates table FFF, and Upgrade Group 1 is in a lower level than Upgrade Group 2, then Section QWE becomes dependent on Section ABC.
-
Tables as sources do not create dependencies. If Section ZXC in Upgrade Group 1 selects from table FFF, and then Section BNM in Upgrade Group 1 also selects from table FFF, no dependency is created.
-
If a Section has a SQL statement that PTIAANALYSIS cannot understand, the SQL is flagged as non parsable from the parser point of view (the Data Conversion will still run fine) and a hard dependency is created. This means for every Section with a query that cannot be parsed, it becomes dependent on every Section sequentially above it in its Upgrade Group, and on every Section in Upgrade Group 1. Furthermore, every Section sequentially afterward becomes dependent on it.
-
Usage of the PS_PTIA_DUAL, PS_PTIA_COMMON_AET, or PS_PTIA_NORECNAME tables never results in a dependency.
Example 31-1 Example of Dependency Rules Calculation
In the following example, the highlighted row (with values in italics) would be dependent on itself and all items in Level’s MAIN-1 and MAIN-2, but not the other items in Level MAIN-3 nor items in Level DDL-1.
| PATH | GROUP | SEQ_NUM | AE_APPLID | AE_SECTION | PTIA_CONV_TYPE | GROUP_LEVEL |
|---|---|---|---|---|---|---|
|
HC89 |
1 |
260 |
UPG_HR89 |
HCHRS01 |
MAIN |
1 |
|
HC89 |
1 |
265 |
UPG_FG89 |
FGHCS01 |
MAIN |
1 |
|
HC89 |
3 |
230 |
UPG_BN89 |
HCBNS06 |
MAIN |
2 |
|
HC89 |
4 |
165 |
UPG_GPBR90 |
HCBRP040 |
MAIN |
2 |
|
HC89 |
7 |
40 |
UPG_EP89 |
HCEPS25 |
MAIN |
2 |
|
HC89 |
7 |
50 |
UPG_EP89 |
HCEPS30 |
MAIN |
2 |
|
HC89 |
10 |
20 |
UPG_TL89 |
HCTLK01 |
MAIN |
2 |
|
HC89 |
80 |
140 |
UPG_TL90 |
HCTLP04 |
MAIN |
3 |
|
HC89 |
80 |
160 |
UPG_TL90 |
HCTLP06 |
MAIN |
3 |
|
HC89 |
85 |
170 |
UPG_PY90 |
HCPYM01 |
MAIN |
3 |
|
HC89 |
85 |
180 |
UPG_PY90 |
HCPYP01 |
MAIN |
3 |
|
HC89 |
10 |
200 |
UPG_PY90 |
HCPYP09 |
DDL |
1 |
|
HC89 |
10 |
210 |
UPG_PY90 |
HCPYP10 |
DDL |
1 |