Propagation types – AWRKPRPTYP

The objective of propagation types is to define the behavior of the propagation and automatic modifications by ARCAD Transformer Field. A propagation type is characterized by:

  • Its identifier which is a letter from A to Z; you will allocate its properties.
  • The propagation types are regrouped in the propagation groups.

The propagation groups are coded in 3 characters. There is no relation between these and application codes.

The propagation group allows you to regroup one or several types of propagation. You can then use the same letter for the propagation type as the one used by someone else in another group. There can be no risk of confusion because you must specify the propagation group for each execution.

To define a propagation type, you must fill in different information; however, it is not necessary to correctly fill in everything from the beginning. You can always come back later to complete some information (notably for the automatic modifications).

The different screens displayed are divided as follows:

  • Identification of the propagation type and behavior of the propagation.
  • Definition of automatic modifications at data file level.
  • Definition of automatic modifications at screen and printer level.

The group, the letter, and the title identify the propagation type. Only the 5 following parameters have an effect on the propagation’s behavior.

When you start just one propagation without modification, concentrate only on these parameters.

All the parameters at the bottom of the 1st screen and the other screens concern the automatic modifications. Before starting the propagation with modifications, you must configure all the necessary parameters which follow.

AWRKPRPTYP          Work with propagation types           10/12/1 06:51:25
CSPWTRN1
Group. . . . . . . . . . : AAA                                         1/5
Identification letter. . : A
 
Type or modify, then press ENTER.
Title. . . . . . . . . . : For ACVTPGMFLD *DFT PRPMODE(*DBR/*ALLFLD/*RNMOBJ)
Propagation parameters
Type of propagation (Alpha. or Numer.) . . . . : A       A, N, C
Number of characters to propagate. . . . . . . :     1   1...65535
Propagation in the multiplications/divisions . : N       Y, P, N
Propagation in the *LIKE DEFINE  . . . . . . . : Y       Y, N
Propagation between programs via LDA . . . . . : N       Y, N

Here are the propagation parameters and other details:

Propagation group

The propagation group is a 3-character code allowing you to regroup several types of propagations, which can be used simultaneously, into one group.

It will be asked for when running the propagation engines.

Identification letter

Required field. A letter from A to Z.

The identification letter completes the propagation group in order to obtain the propagation type.

This identification letter must be specified in the list of fields to propagate, in the field format as well as each of the fields to which the list will be attached giving the behavior to follow for the propagation and inherent modifications.

Title
The title corresponds to the title associated with the propagation type.
Type of propagation
Note

A or N as a type of propagation is not totally synonymous with a numeric or alphanumeric field.

A : Alphanumeric. The propagation follows the pathway of all the characters to propagate. The derived fields will be impacted in the exact positions corresponding to the characters propagated. However, if a field in contact does not keep all the characters to propagate, it is not considered as a derived field. For more information, refer to Outlining propagation behavior.

N : Numeric. The propagation follows the pathway of the number of characters to propagate. The derived fields are entirely propagated if they are numeric. (They receive a field format equivalent to their length). The derived alphanumeric fields will be impacted to the exact positions corresponding to the propagated characters. For more information, refer to Outlining propagation behavior

C : By character. The propagation is done independently for each character in the propagated field. In such a case, put 1 at the Number of characters to propagate. You indicate this value when doing transformation from alphanumeric to Unicode.

Number of characters to propagate

Enter the number of characters that follow the path to the core of the programs.

For a numeric propagation, enter at least 1 or 2. Only those fields containing 1 or 2 digits of a field in contact will be considered as being derived fields. You can also enter a higher number (Ex. 5): in this case a field in contact that keeps 4 characters will not be propagated.

Propagation in multiplications/divisions

Specify if the propagation must be made in the calculating instructions: multiplication or division.

Y: In multiplications and divisions, there is propagation of the factors to the results field (or vice-versa).

P: There is propagation in the multiplications and divisions when it can be made without ambiguity, that is, towards the “product”. In multiplications, it will propagate from one of the factors to the product (results) but not vice-versa. In divisions, it will propagate from the results factor to the numerator only. Attention! The propagation is done from the divider to the numerator.

N: In multiplications and divisions, there is no propagation of factors to the results field (or vice-versa).

The choice between P and N is important according to the problem you are dealing with:

  • If you only want to carry out a propagation on the unitary prices, you should put ‘N’.

    • Also with ‘UP MULT QTY AMOUNT’ -> AMOUNT will not be propagated by UP.

  • If you want to carry out a propagation on everything given in amount, you should put ‘P’:

    • Also with ‘UP MULT QTY AMOUNT’ -> AMOUNT will be propagated by UP.

  • However, QTY will not be propagated (unless you put ‘Y’).
Propagation in the *LIKE DEFINE

Specifies if the RPG, RPGLE, CBL, or CBLLE instruction *LIKE DEFINE is cause for propagation or not.

Y: The definitions of a field in relation to another are cause for propagation (from factor 2 to the results factor or vice-versa). This means that this instruction is used to define the fields with the same length, and also the same nature concerning their contents.

N: There is no direct propagation on the instructions *LIKE DEFINE between Factor 2 and the results Factor. This means that this instruction is used to define fields with the same length but whose contents are not necessarily of the same nature.

Propagation between programs via LDA

The LDA is, sometimes, used as a method for parameter passage between called and calling programs.

Y: There will be propagation via the LDA between the callers and the called (in both directions). The LDA division must be similar between the two calling programs.

N: The propagated fields belonging to the LDA description do not set off propagation towards the callers (or the called).

The parameters situated at the bottom of screen 1/5, screen 2/5, and possibly 3/5 are linked to the automatic modifications you wish to carry out on the file fields. However, this will also cause modifications in the programs:

  • In the case of field length extension, the working fields in the programs will also be extended.
  • In the case of added file fields, you can ask for the insertion of routines for each read or write in the file.
  • Also, if the file is described as internal in the programs, all the file descriptions will be modified.

You must first choose between the 4 types of modifications (Addition, Change type, Extension, or Deletion), then configure these modifications.

Reference

For more information about the functions concerning this subject, refer to Working with automatic modification functions.

Below, you will find the 3 parts of the screen concerned.

D.B. file field's modification parameters
Type of modif. (Add, Chg.type, Extension, Del.): E       A, C, E, D
New field length / Extension length  . . . . . :     2   0..65535 (-nn..-1)
# decimals new / # decimals for extension  . . :         0..9 (or -9..-1)
Type of new field (if different) . . . . . . . :         Blank or Type valid
Position of the modif. inside the field  . . . :         0=End,-1=Str,1-65535
More...
F3=Exit     F12=Cancel      F21=Command line

The above information concerns either the field extension values or the values of the newly-added file field. If you do not wish to carry out any file modification, leave the values at E=Extension and 0.

Here are the details of the DB file field's modification parameters.

Type of modif. (Add, Chg.type, Extension, Del.)

The modification to be carried out by the propagation on a database field (and the derived fields) can be of 4 different types:

A: The Addition of one (or two) fields in the files with correspondence to each field in the list of initial fields. To name the new fields, you need to first run the command to process the PF fields (ACVTDBFFLD) with the option *NEWFLD.

C: The Change type for fields.

E: The Extension of the length of each field from the list of initial fields.

D: The Deletion of the field in the files, but also the deletion suggestions for the associated working fields as well as the display fields.

New field length / Extension length

In the case of field addition, specify the total length the new field will have. Leave this value at 0 so that the new field has the same length as the previous one.

When extending the length of a field, specify the extension length (increment) to add to the current length of the field. You can also place a negative value here if you wish to reduce a field.

# decimals new / # decimals for extension

In the case of a field addition specify the number of decimals for the new field. If the length of the new field is set at zero, its number of decimals will be identical to that of the previous field.

When extending the length of a field, specify the number of decimals to add to the current number of decimals in the field.

To only extend the decimal part of a field, specify the same value at the “Extension length and Nbr of decimals” parameters.

Position of the modif. inside the field

When extending this allows you to specify the exact position in the field where the extension must be. This can be useful if the modified field is divided into several sub-fields (not propagated independently).

0 = End: The extension is made on the last character of the field. When adding a field to a structure, the field is added after.

-1 = Start: The extension is made on the first character of the field. When adding a field to a structure, the field is added before.

1-65535: You specify the exact position after which the new extension characters are inserted. A value from 1 to 65535 is incorrect here when adding a field.

Type of new field (if different)

When adding a field or changing the type of field, enter the type of the new field in the physical files only if it is different from the type of analyzed fields.

If indicated, the type must be a valid field type in the DDS and PF. (A (Alpha) S (Extended) P (Packed) )

On the following screen all the parameters concern a field addition, except the routine which can also be used in extension of the field’s length.

AWRKPRPTYP          Work with propagation types               10/08/18 08:50:28
CSPWTRN1
Group. . . : AAA    Identification letter . . . . : A                     2/5
 
Type or modify, then press ENTER.
In case of new field file . . . :
Position of addition in record . . . . . . : *EOR      *AFTER, *BEFORE, *EOR
Dependent link with old field. . . . . . . : *NONE     *AFTER, *BEFORE, *NONE
Similar functioning of the 2 fields. . . . : N         N=No,Y=Yes,A=Assign
Replace file field name in pgms. . . . . . : N         Y, N
Routine inserted before writing file . . . : *NONE     Routine, *NONE (F4)
Routine inserted after writing file. . . . : *NONE     Routine, *NONE (F4)
 
If addition of the files from a 3rd field .:
Create a third field . . . . . . . . . . . : N         Y, N
Third field length (if different). . . . . :           0..65535
Decimals # in third field. . . . . . . . . : 0         0..9
Type of third field (if different) . . . . :           Blank or Type valid

Here are the parameters of field addition.

Position of addition in the record

When adding a field, specify the exact position in the record where the new field must be added:

*AFTER: The new field is added just after the analyzed field.

*BEFORE: The new field is added just before the analyzed field.

*EOR: The new field is added at the end of record.

If several are processed for only one file, the added fields will be in the alphabetical order of the analyzed fields at the end of the recording.

Dependent link with old field

When adding a field, specify if a hierarchical dependent link exists when the analyzed field is defined as a key for a file (physical or logical).

*AFTER: The new field is added to the keys after the analyzed field.

*BEFORE: The new field is added to the keys before the analyzed field.

*NONE: No hierarchical link exists between the two fields. The new field is not added to the keys.

This parameter has an impact on:

  • The automatic modifications of PF sources (by ACVTDBFFLD).
  • The automatic modifications of LF sources (by ACVTPGMFLD).
  • The automatic modifications of RPG or RPGLE sources (when the field is in key).

Similar functioning of the 2 fields

When adding a field, indicate if the propagation must try to keep a similar type of functioning in the program processes.

Three possible values:

N: No similar functioning. The processing instructions are not copied.

Y: Functions completely similarly. All the processing instructions are copied in the programs. The derived working fields will then receive the names of the associated fields in relation to each new field. Attention! The program will need to be modified.

A: Similar functions for the assignment instructions only. Only the assignment instructions are copied in the programs. The derived working fields receive the names of the fields associated in relation to the new field.

Note: In RPG, the following are considered as assignment instructions: MOVE, MOVEL, MOVEA, Z_ADD, Z_SUB, PARM, DEFN.

Replace file field name in pgms

When adding a field, indicate if in the programs, you will use another field name in place of the analyzed field and added field. Processes will be added each time a file is accessed, in order to regroup the two fields after reading or to divide them before writing.

This parameter is incompatible with similar functioning of two fields.

Also, in this specific case, enter the appropriate parameters in screen 3/5.

Routine inserted before writing file

Specify the name of the standard code routine that will be added before each write to the file, to process the analyzed field.

Reference

For more information about standard routines, refer to Standard routines

Leave *NONE if no process needs to be added before writing to the file.

The following names can be used in the source of the routine:

$$F1: Indicates the name of the current analyzed field.

$$F2: Indicates the name of the newly added field.

$$F3: Indicates the name of the third field added to the files, or the name of the field group used.

Routine inserted after reading file

Specify the name of the standard code routine that will be added after each read of the file to process the analyzed field.

Addition of the files from a 3rd field

Specifying ‘Y’ in ‘Create a third field’ allows you to indicate that another field (3rd field) must be also be added to the files. To name this field, use the ACVTDBFFLD command with the option NEWFLD and the parameter THIRDFLD(YES).

Note

The utilization of this 3rd field is limited to file access; it can only be updated using routines inserted after reading or before writing.

It is not concerned by similar functioning.

Third field length (if different)

Specify the total length for the new field. Leave this value at 0 so that the new field has the same length as the analyzed field.

Decimals # in third field

Specify the number of decimals for this new field. If the length of the new field is set at zero, its number of decimals will be identical to the analyzed field.

Type of third field (if different)

Enter the type of 3rd field in your physical files, only if it is different to the type of fields analyzed.

If entered, the type must be valid for a PF DDS type field. (A (Alpha) S (Zoned) P (Packed) ).

AWRKPRPTYP          Work with propagation types               10/08/18 09:11:32
CSPWTRN1
Group. . . : AAA    Identification letter . . . . : A              3/5
 
Type or modify, then press ENTER.
 
For the replacement of the file field names in the programs :
Prefix . . . . . . . . . . . . . . . . . . :       Valid character(s)
or Suffix. . . . . . . . . . . . . . . . . :       Valid character(s)
# of recovery characters . . . . . . . . . :       0..3
Maximum field length limitation. . . . . . :       0 or 5..10
 
For non-modifiable interface files :
Routine inserted before writing file . . . : *NONE     Routine, *NONE (F4)
Routine inserted after writing file. . . . : *NONE     Routine, *NONE (F4)

The first 4 parameters of this screen are only useful if you indicated Y at the replacement of file field names in the programs.

It allows you to enter the logic the ACVTPGMFLD (Step 3) is to follow at the automatic modification of programs, for giving a new name to the field file in the programs.

Example

The analyzed field is called ARCOD. A field was added to the ARCOD2 files.

You want the 2 fields (after the file reading) to be placed end to end in a working field entitled XPCOD (the routine after reading will do this).

ARCOD will be renamed XPCOD throughout the program.

You just need to set up a rule to determine the name of these new program fields.

Here are the parameters for replacement of file field names.

Pgm replacement field Prefix or Suffix

Enter either the prefix or suffix but not both.

# of recovery characters

Enter if the prefix (or suffix) must precede (or follow) the entire name of the analyzed field or overlap it.

By using a value other than 0, you indicate the number of characters for the prefix or suffix that must overlap the start (or the end) of the analyzed field name.

Maximum field length limitation

To build the name of the new field of the replacement fields in the pgms, enter the maximum length that the built field name can have.

Specify a value from 5 to 10 for the maximum or enter 0: in this case the maximum possible length will be determined by the language of the programs that use this field. This will be 6 for RPG, RPG36, RPG38 and 10 for COBOL, CLP, RPGLE.

If the built field name crosses this limit, there will be an overlay for the number of characters in excess.

Routine inserted for the non-modifiable interface files

Specify here, the name of a standard code routine that will be added before each interface file write, to process the analyzed field.

Reference

For more information about standard routines, refer to Standard routines.

Leave *NONE if no process is to be added before writing the file.

These routines are only used by ACVTDDSFLD.

The following names are to be used in the routine source:

  • $$F1: Indicates the name of the renamed program field.
  • $$F2: Indicates the name of the file field.
Reference

For more information about this subject, refer to Working with automatic modification functions.

In the screen 4/5 and 5/5 you will set the behavior of automatic modifications for the DSPF/PRTF fields.

These parameters will be used by ACVTDDSFLD.

For more information on the functionalities concerning these modifications, first consult the automatic modifications of display and printer fields, and then refer to the following for learning how to set up the configuration.

AWRKPRPTYP          Work with propagation types               10/08/18 09:14:31
CSPWTRN1
Group. . . : AAA    Identification letter . . . . : A              4/5
 
 Type or modify, then press ENTER.
 
For screens and printouts    :
Modification visible to the users  . . . . : *ALWAYS   *ALWAYS, *IFFITS,
                                             *NEVER
Position of addition (if new field visible): *AFTER    *AFTER, *BEFORE
Routine inserted before screen display . . : *NONE     Routine, *NONE (F4)
Routine inserted after screen entry. . . . : *NONE     Routine, *NONE (F4)
Position of the hidden field in the format : *EOR      *EOR, *BOR, *NONE
For the name of the new field visible screen/status:
Prefix . . . . . . . . . . . . . . . . . . :       Valid character(s)
or Suffix. . . . . . . . . . . . . . . . . :       Valid character(s)
# of recovery characters . . . . . . . . . :       0..3
Maximum field length limitation. . . . . . :       0 or 5..10

Here are the screen/printer-level modifications parameters:

Modification visible for the users

Specify if the modification carried out on the database and in the programs should be visible to the users on their screens and in their printers.

*ALWAYS: In this case the propagated display or printer field visually undergoes the same modification as the one for the file fields. If you are using field extension, the display field is enlarged in the same way. If you are using field addition, a new field is added next to each display field. The added field is either a similar field whose name was determined by the propagation ($$A1 in the routines), or a new field whose name was built when the ACVTDDSFLD was run using the indications specified later on ($$F2 in the routines).

*NEVER: In this case propagated display or printer field does not visually undergo any modification. However, it is renamed and has a name made up for it when ACVTDDSFLD is run, from the indications specified later on ($$F2 in the routines).

Note

However, despite this *NEVER, the displays can still undergo visual modification if you use Add another field to the display/report.

*IFFITS: This is a mixed option where the choice between *NEVER or *ALWAYS is only made at the last moment according to the space available on the line. Note that this option is not available when adding a field as the routines to insert can be different between *NEVER and *ALWAYS.

Position of addition (if new field visible)

*BEFORE: If a new field is added visually to the display or printer it is placed before the propagated field.

*AFTER: If a new field is added visually to the display or printer it is placed after the propagated field.

Routine inserted before screen display

Specify the name of a standard code routine that will be added before each screen display (or output of the printer format) to process the analyzed field, if it is in Output or Input-Output.

Reference

For more information about standard routines, refer to Standard routines

Leave *NONE if no process is to be added before the screen display.

The following names can be used in the routine source:

$$F1: Indicates the name of the current analyzed field. This field will disappear from the screen when using the option *NEVER.

$$A1: Indicates the name of the field associated to the analyzed field, when using the option “similar functioning of two fields” that are allowed to reach the display field (for field addition in the files).

$$F2: Indicates the name of the newly added field in the screen, if generated by ACVTDDSFLD. This field is visible to the user. 

$$F3: Indicates the name of the third field added to the screens, if it is defined.

Routine inserted after screen entry

Specify the name of the standard code routine that is added after each display reading to process the analyzed field, if it is in Input or Input-Output.

Position of the hidden field in the format

Specify the position where the hidden fields must be added to the screen format.

*EOR: The hidden field is added at the end of the format.

*BOR: The hidden field is added at the beginning of the format, after the other hidden fields. In this way it remains in place if, in SDA, you request the rearranging of the field format.

*NONE: No hidden field is added to the format. The analyzed field is then defined in the usage program (on the added lines or on a code line already existing). This is the same for the associated field when it comes from propagation by similar processing.

Note

For PRTFs, the option *NONE is used as default no matter what value was indicated here (because you cannot define a hidden field in a PRTF).

Name of the new field visible screen/status

ACVTDDSFLD will create a new display/printer field name using option *NEVER.

Note

Even when using the option *ALWAYS for field addition, it is useful to anticipate this field as the name of this field cannot always be generated during the propagation.

You should simply give a rule to determine the name of these new fields.

Prefix or Suffix for the new visible field

Enter either the prefix or the suffix, but not both.

# of recovery characters

Enter if the prefix (or suffix) must precede (or follow) the entire name of the analyzed field or overlap it.

By using a value other than 0, you indicate the number of characters of the prefix or suffix that must overlap the start or the end of the analyzed field.

Maximum field length limitation

To build the name of the new field visible in the displays/printouts, indicate the maximum length the built field name can have.

Specify a value from 5 to 10 for setting the maximum or indicate 0. In this case the maximum possible length will be determined by the program languages which use this display (or printout).

In this way, it will be 6 for RPG, RPG36, RPG38 and 10 for COBOL, CLP, RPGLE.

If the built name exceeds this limit, there will be a recovery for the number of characters in excess.

AWRKPRPTYP          Work with propagation types               10/08/18 09:17:59
CSPWTRN1
Group. . . : AAA    Identification letter . . . . : A                     5/5 
Type or modify, then press ENTER.
 
To add another field to the screen/status
 
Condition the addition of other field  . . . . : N    N, I, O, B
 
Prefix . . . . . . . . . . . . . . . . . . . . :      Valid character(s)
or Suffix. . . . . . . . . . . . . . . . . . . :      Valid character(s)
# of recovery characters . . . . . . . . . . . :      0..3
Maximum field limitation for field name. . . . :      0 or 5..10
Third field length (if different). . . . . . . :      0..65535
Decimals # in third field. . . . . . . . . . . : 0    0..9
Type of third field (if different) . . . . . . :      Blank or Type valid
 
DDS Keywords for this field . :

You can ask ACVTDDSFLD to automatically add another field in the screens and printers (for each propagated field found).

Therefore, you must specify the following parameters as given below:

Condition the addition of other field

Allows you to specify if you must add a new display for each display field (just before or just after), of a different format. (This field will be indicated by $$F3 in the routines.)

For example, you can associate the currency code to each amount field.

N: No "other fields" are added.

I: One "other field" is added if the field is used in input (Input, Input-Output or Hidden Field).

O: One "other field" is added if the field is used in output (Output, Input-Output or Hidden Field).

B: One "other field" is systematically added.

Name of the other field added in the screen/printer

You simply need to give a rule to determine the name of these new fields.

Reference

For more information about the new visible field’s name, refer to the IBM i help. The principle here for naming this other field is the same.

Characteristics of the added other field in the screen/printer

Generally, it is necessary to specify the type and length of this other field, and to possibly assign DDS keywords to it:

Other field length

Specify the complete length this field will have. Leave the value 0 so that the new field has the same length as the analyzed field.

Nb. of decimals in other field

Specify the number of decimals this new field will have. If the length of the new field is set to zero, its number of decimals will be identical to the analyzed field.

Other field type

Enter the type of this field in the screens/printers, only if it is different than the type of the analyzed fields.

Note

Be careful, if indicated, the type must be valid as a field type in the DDS of DSPF, PRTF. (A (Alpha) S (Signed) Y(Numeric), etc...).

DDS keywords for this field

You can define the keywords DDS of DSPF or PRTF which will be taken ‘as is’ in the DDS source for the newly added field.

The syntax of these keywords must be correct.

Only specify one keyword per line.

The keyword will not be added if it is incompatible with the field utilization. Example: keyword VALUES(...) with a field in Output only.

Note

You can specify a REFFLD(file field) keyword in order to indicate that the new field must be defined in relation to the reference file. This allows you to externalize certain checks.