Propagation layout

Steps, Files, and Lists used in propagation
Step 1 (Entry in the programs)	Step 2 (Propagation)
Input: LSTxxxxx: List of Fields to propagate and possibly LSTPGM - List of Programs to be processed	Input: LSTPRPSTP: List of stoppers and possibly LSTPGM ... List of Programs to be processed
Input/Output: LSTDRVFLD: List of derived fields
Output: LSTDDSFLD: List of D.D.S. fields LSTDRVFLD: List of derived fields Other ARD files	Output: LSTDDSFLD: List of D.D.S. fields AARFCHSF1: Flagged source lines file Other ARD files

Propagating lists of fields – LSTxxxxx

Another possible denomination is the list of impacted fields.

This list is the starting point for the propagation and the modification engines (except the ACVTDDSFLD).

This is a list of fields to be processed (file or program or display/printer field) and is often the result of the 1st level impact.

Propagating lists of programs to be processed – LSTPGM

This list is not indispensable for the propagation; by default, all the programs in the application can be processed.

If you wish to carry out the propagation for one program, it is not necessary to create a list; simply indicate the name of the program to process when starting the propagation.

However, to define a specific domain for the propagation on a set of programs you must use this list (after choosing the name); this list must be a list of source members (type M) created by one of the following:

an ACRTMBRLST
an ACRTXRFLST
an extraction from another list of source members.

When run with this list i.e. LSTPGM, the propagation will be limited to programs in this list only, possibly with the COPY clause sources included.

Each parameter entry between a program on this list and one not on the list will fill in the list of fields of components outside propagation.

In the case of propagation with internal descriptions, do not forget to include the calling CLP (when these substitute the file names) or the OCL36 in this list.

Propagating lists of propagation stoppers – LSTPRPSTP

This list contains the propagation stoppers that you defined with ASETPRPSTP.

In step 2, it is used at the beginning of a program field process to verify if this field is part of an *EXCLUDE stopper. If it is at YES, the field will not be processed.

In step 2, the propagation to a field for which you enabled a *VIAFLD type stopper triggers the search for a field, loading or using this field or the associated field (propagation to a field with what may be described as having a “leap-frog” behavior).

The *LDA type stoppers (LDA re-organization) are used in the 3 stages of the propagation (Steps 1, 2, and 3).

Reference

For more information about Step 3 (Automatic modifications in the programs), refer to Internal descriptions

Propagating lists of D.D.S. fields – LSTDDSFLD

This list can also be called the list of DB and DSPF/PRTF fields to be impacted.

This output list from the propagation contains all the external references of a field propagated to a file (physical, logical, display, printer).

It is built by the propagation in the following way:

In Step 1 (Entry in the programs):

Physical file fields in the starting list of fields to propagate.
Logical file fields that depend on these physical files.

These are stored as follows:

LST_JOBJ File field name
LST_JLIB File format name
LST_JSRCF File name (physical or logical)
LST_CATR File attribute (PF, PF38, LF, LF38)
LST_CTYPE Field type
LST_CTXT Extended field format
LST_JZSEL2 Blank

In addition, if you have the internal descriptions of files (in RPG, COBOL) you will also find the following in this list:

All the references (program + code line n°) that correspond to the definition of the file field in the program (stored this time by the position and length in the record, and not by the field name).
LST_JOBJ Positional reference to file field
LST_JLIB File format name
LST_JSRCF File name (physical or logical)
LST_CATR File attribute (PF, PF38, LF, LF38)
LST_JZSEL2 Program name + : + line n° + : + abbreviated program type
LST_CTYPE Field type
LST_CTXT Extended field format

If a file field is described under several field names in a program, there will be those many items in this list (one for each line).

In Step 2 (Propagation):

New fields from physical and logical files found by the propagation (these are the other database fields in which the propagation ended).

Field for the Printer/Display files found by the propagation
LST_JOBJ File field name
LST_JLIB File format name
LST_JSRCF File name (physical or logical, display, print)
LST_CATR File attribute (PF, PF38, LF, LF38, DSPF, DSPF38, PRTF, PRTF38)
LST_CTYPE Field type
LST_CTXT Extended field format
LST_JZSEL2 If an unexpected new PF/LF field: Program name and program line where it came from.

In addition, if you have the internal descriptions (in RPG, COBOL) of new file fields, the name of the field added to the list is: Positional reference to file field.

If this is a DSPF, DSPF38, DSPF36, PF, PF38, PF36, LF, LF38, LF36 field, the file name is placed in LST_JSRCF (as this external file does exist).

However, if it is fields in card O (RPG) or on an Output Buffer (COBOL) for a Print for which no external PRTF… file exists, the information is stored as follows:

LST_JOBJ Positional reference to file field (OxxxxLyyyy)
LST_JLIB Program name
LST_JSRCF Program name
LST_CATR Fictive attribute PRTF36
LST_JZSEL2 Program name + ‘:’ + line n° + ‘:’ + Abbreviated program type
LST_CTYPE Field type
LST_CTXT Extended field format

Propagating lists of derived fields – LSTDRVFLD

This is also known as the list of fields impacted in the programs or the list of propagation follow up.

This propagation output list includes all the fields of the programs concerned by the propagation.

It contains 3 records at the beginning of the file, whose objective is to visualize the progress of the ACVTPGMFLD processes in Steps 1, 2, and 3.

It is built by the propagation in the following way:

In Step 1 (Entry in the programs):

Name in the program for the physical or logical file’s field.
FILE.FIELD name for the fields of the files used in the SQL queries in the SQLRPG(LE), SQLCBL(LE) program.
FILE.FIELD name for the fields of the files used in OPNQRYF or CPYF in CLP.
LST_JOBJ Program field name if its name has a maximum of 10 characters.
Fictive name of the field CB00000001, CB00000002 in the opposite case.
LST_JZSEL2 Program field name
LST_JLIB Program name
LST_JSRCF Program name
LST_CATR Program source type (RPG, RPGLE, CBL, CLP, etc...)
LST_CTYPE Field type
LST_CCPLT Field format code
LST_CTXT Text with: file name, format and field causing the propagation
LST_CSTS ‘ ‘

If getting the program field is obtained from the internal descriptions of files, the information is the same except for the text:

LST_CTXT "Fld:·xxxxx·Fmt:xxxxxx Fii: xxxxx,PF(xxxxx"

Fld = The file field in question

Fmt = The file format

Fii = External name of file, its type and its internal name in the program.

Reference

For more information, refer to Interpreting the nature of a source line.

In Step 2 (Propagation):

The propagation process of a program field will create new items in this list for each new propagated field. The only differences in the contents are:
- LST_CTXT - Part of a source line that triggered the propagation (in which the original field can be seen).

However, the LST_CSTS status will have the following values:

[blank]: non-processed field
X: processed field
S: field not processed as it is being subject to a propagation stopper
N: field outside propagation
R: field whose process triggers an access error to a source
B: DB field present in a non-propagated file
C: previously-enlarged field
D: ambiguous field
E: DB field present both in a propagated file and another non-propagated file
F: DB field present both in a propagated file and in a DSPF or PTRF!
G: DB field present both in a propagated file and another non-propagated file, and also in a DSPF or PRTF.

When the process is active in Step 2, the percentage displayed corresponds to the number of items on this list that were already processed. You can see them by typing DSPPFM LSTDRVFLD.

Column 81 corresponds to LST_CSTS (not blank, if processed); the records are processed in the order of their entries to this list, as seen by the DSPPFM.

Propagating source line files – AARFCHSF1

This ARCAD-based file contains the flagged source lines first, then those modified by the propagation and the automatic modifications. Consider that it contains the source modification propositions.

Its primary key is the following:

Application code
Development environment
Source lines destination version
Source member name
Source member type
Line N°
Sub-line N°

Note

This is the only file that is not necessarily purged when it needs to start a propagation. This is why it can be purged as follows:

For the version in question, use the command AWRKFRMCHG and F17=Delete all.
Or possibly a CLRPFM of this AARFCHSF1 file only if you are sure you are the only person using ARCAD Transformer Field and also, that you have the authorizations required for such an operation!

Important!

As it refers to the source lines of the principal component, it is important that the reference source is not modified between the propagation and the automatic modifications that fill this file, and applying it towards a new source in the version. If not, the modifications will be off (in relation to the source line) and result in complete disorder!

Propagating other AARF… files

The propagation also updates other files in the ARCAD database. There is no need to go into any details of these files.

Important!

These files as a principal key, each has the Library and the Name of the list of derived fields (normally, the version library + LSTDRVFLD).
When you begin a propagation step, all the records concerning the list of derived fields processed, are deleted beforehand.

However, they keep the information of the last propagation; that is why, when you no longer need this information, it will be necessary to purge these files through ACLRDRVFLD - Delete the info. generated by the propagation.

Propagating source lines

In the LSTDRVFLD list and by the display screen for derived fields (ADSPDRVFLD), you can find an explication for the reason of the propagation for each propagated field (in LST_CTXT).

This information can contain:

Items resulting from Step 1: Entry in the programs

* Propagation by the external descriptions of the file field to the file field in the program.
- File:xxxxxx,xxx Fld:xxxxxx Fmt:xxxxxx
- File = Name of file in question, file type
- Fld = The file field in question
- Fmt = The file format
* Propagation by the external descriptions of the file field to a program field used as a key.
- KFLD-->File:xxxxx,xxx Fld:xxxxxx or
- KLIST-->File:xxxxx,xxx Fld:xxxxxx
* Propagation by the internal descriptions of the file field to the file field in the program.
- Fld: xxxxx Fmt:xxxxxx Fii: xxxxx,PFxx(xxxxx)
- Fld = The file field in question
- Fmt = The file format
- Fii = External File name, its type and its internal name in the program.
* Propagation by the internal descriptions for a key field.
- Key:·xxxxx Fmt:xxxxxx Fii: xxxxx,PFxx(xxxxx)
- Key = The key field in question
- Fmt = The file format
- Fii = External File name, its type and its internal name in the program.
* Propagation from a program field indicated in the starting list.
- Direct-->program, field
Items resulting from Step 2: Propagation – Source line

In most cases, an extract of the source line in the program that caused the propagation can be seen here. The line is “compressed and then possibly truncated.” Also, the name of the field in question is present in this line.

In the case of parameter transfer, you also have:

* The propagation of a parameter to the called program:
- Calling pgm: call instruction or
- Calling pgm-->called ILE pgm: call instruction if the call is from the principal module of a pgm.
* The propagation of a parameter to a calling program:

Called pgm: call instruction or
Called pgm<-calling ILE pgm: call instruction if the call was from the principal module of a pgm.

Items resulting from Step 2: Propagation – Special cases

* Propagation between an internal D.S. and another external part (in RPG...)
- External D.S.: Field
* Propagation between the external fields and the internal fields for the file buffers (in COBOL)
- External Record Fmt: Field
* Propagation between the Input and Output buffers in a COBOL program for which the display descriptions are internal:
- Field->I/O DSPF

Propagating lists of other D.B. fields

This list of anomalies does not exist as a list file on the drive:

It is a visualization of the LSTDDSFLD by the AEDTLST command with the filter STDCVTPGMD.
Set of fields in external reference to a data file that was detected by the propagation in Step 2.

This is the essential anomaly list for refining the quality of the propagation by allowing you to detect the following cases:

oversights in the original list of fields to propagate.
interface file fields that you don’t want propagated but which are linked to certain propagated fields.
additional unnecessary fields placed in the list of fields to be propagated (which then detect other DB fields).
propagation quality problems which need to be refined.
field cross-references not up to date in relation to the sources.

A high-quality propagation should only contain the interface file fields.

How to analyze the fields in this list

In order to determine which case this is, you must:

find the name of the field in this list (LST_JOBJ) and the name of the program (and the program line in the case of an internal description),
go in and read the derived fields in order to visualize the path followed by the propagation, and
consult the source(s) concerned.

What to do next:

Oversight of field in the original list. For a field oversight, add it to the list of fields to propagate.

Reference
For more information, refer to the Recovering data

You might also need to take a look back at the extraction macro.
Detection of an interface file field. It is normal that they are present in this list. This can be processed by ACVTDDSFLD.
One field appears too many times in the list of fields to propagate. Simply remove them from the list of fields to propagate.
Propagation quality problems often resulting from programming techniques that differ from ARCAD Transformer Field principles.
- A field must always contain information of the same nature. In this case, you can either use stoppers, or adapt the sources in question.
Cross-reference update problems.

Propagating lists of anomalies

This section presents the anomalies that do not exist as a list file on the hard disk.

Propagate lists of components outside propagation

This list of anomalies doesn’t exist as a list file on the hard disk:

It is a visualization of the LSTDRVFLD using the command AEDTLST with the STDCVTPGMN filter.
A set of program fields that cannot or should not be processed. These can be:
- a field as an input parameter of a program present in an application, but which won’t be processed as you defined a propagation stopper to an application or a specific list of programs to be processed (however, this program is called by one of the processed programs).
- a field situated in a program, present in an application, but which won’t be processed as you have defined a propagation limited to one application or a specific list of programs to be processed; everything outside this field will be transferred as parameters when calling a processed program.
- the call indication by a processed program from a program that doesn’t have any cross-reference fields.

In this case, the type of program indicated is *PGM and the field name is the name of the calling program.

The analysis of this list allows you to verify the impacts outside an application, or outside the list of components to be processed. This can lead you to:

look back over the list of components to be processed,
load the overlooked component cross-references,
or above all, highlight the links with the components outside the application.

The propagation layout