Working with automatic modification functions

The following 3 types of modifications are possible for the fields of a file:

  1. E - Extension of field length: You indicate the number of extension (or reduction) characters to be implemented for each impacted field.

    By default, the length modification of a file field will lead to the same modification being made to all the derived program fields.

  2. A - Addition of a file field (or even 2 fields): This is the addition of a new field called a 2nd field (just before, just after, or at the end of a record) for each impacted file field. This new field can have the same characteristics (Type/Length) as the reference field, or you can create a particular type and length for the field (Field $$F2).

    The name for the new fields will possibly be proposed before the actual addition which is carried out automatically; you should check this and if necessary, correct the new field names.

    You can include a dependent link at file key level (physical or logical).

    You can include the duplication of program code lines that use the propagated field, in order to obtain a similar line to the new file field (line duplication by imitation for an associated field).

    It is also possible to simultaneously add another file field, called a 3rd field. (Field $$F3).

  3. D - Deletion of a file field: The goal of this type of modification is to eradicate the fields which have become obsolete in the files and following that, remove the program code lines related to them.

For any type of modification chosen (A, E, D) you can include the insertion of routines in the programs (placed just after reading the file, or before writing the file).

Important!

There can be an absence or presence of reference file fields in the impacted file fields.

Normally, the reference file fields are never used in a program; they are there only to allow the descriptions of file fields by external reference to fields in reference files.

  • If you place the reference file fields in the list of fields to be processed:

    • The description of reference file fields will be modified (field extension or addition).
    • The PF fields referring to a reference file field will not be modified in the case of field extension (there will just be a flag put in).
    • In the case of field addition, these will refer to a new reference file field.

  • If you leave out the reference file fields from the list of fields to be processed:

    • The reference file will not be modified.

    • The PF fields referring to a reference file field will be relatively modified in the case of field extension.

      Example

      Before FIELDFI R REFFLD
      After FIELDFI R +3 REFFLD

  • The newly-added fields will be defined directly in the source of the PF.

Newly-added fields

Don’t be surprised, but these files sometimes need to be modified too (directly re-declared fields, newly-added fields, added keys).

The ACVTPGMFLD (Step 3) carries out this modification and not the ACVTDBFFLD which is only used with the physical files. The reason for this is that it is the ACVTPGMFLD (Step 1) which propagates the physical file fields to the logical file fields.

Here is a summary of the main automatic modifications which can be carried out on the programs by using ARCAD Transformer Field.

Automatic modification of programs - ACVTPGMFLD

In the case of a field extension, this process:

  • extends all the propagated program fields (either in the default way, if the field has an external description in relation to the file or by modifying the field definition length.
  • it recalculates the field positions (in the case of internal file descriptions) so that they correlate with the files.
  • inserts routines, if necessary.

Process before writing and after reading D.B. files

In the case of field deletion, this process:

  • deletes the lines of codes containing the entirely propagated fields.
  • shortens the fields containing the deleted fields among other things.

However, in this case a manual verification of modified sources is obligatory to ensure the correct logic of line deletions, notably in the case of a test instruction deletion (the ENDIF is not deleted).

In the case of internal file descriptions, the process recalculates the field positions in order for them to be in correlation with the files.

In the case of field addition, this process:

  • duplicates by imitating the field process lines (either just the allocations or all the code lines).
  • If requested in the configuration (similar function for 2 fields), it duplicates by imitating the field process lines (either just the allocations or all the code lines).
  • The imitation used for naming the new program files tries to analyze the logical file that was adapted for the field names between:
    • The original field (z11) which already has a new associated field name (z12).
    • The original field (z11) and the field to which it is propagated (z21).

The synthesis of these 2 logical rules can allow you to correctly name the field associated with the new propagated field (z22).

Example

File: OFNBH (z11) OFNBJ (z12)

Program: W1NBH (z21) W1NBJ (z22)

Code lines: MOVE W1NBH TO OFNBH

Added line: MOVE W1NBJ TO OFNBJ

It should be noted that the imitation doesn’t function in every case. The new field is, therefore, named with a number (9, 8, 7, 99, 98, 97, etc...) overwriting the last characters. For clarity in your program, you will need to rename these new fields using more explicit names.

  • If a dependent link is defined for the new field, it is added (in RPG, RPGLE) to the list of keys. If necessary, a KLIST is added: a key from a single item (previous field) is replaced by a new KLIST containing the previous field and the new field.
  • In the case of internal descriptions for files, it recalculates the field positions in order for them to be in correlation with the files. It also declares the new fields in the programs (when the previous field is present).
  • If necessary, it can insert the routines:
    • Process before writing, after reading the D.B. files (active on the original field, new field and 3rd file field).
    • Process before writing, after reading the D.B. files to separate or switch the original field and the new field to one whole field (if you requested the file field name to be replaced in the programs).

The programs undergoing a second modification process for each field linked to the fields processed by the ACVTDDSFLD command (Display/Printer fields):

  • Add a routine before Display / after Input.
  • But sometimes need to rename the display field in the program.
  • Or also need to declare the Display/Printer fields directly in the program (notably for the fields in O card printout without PRTF, or for the internal descriptions of the display and printer fields).

The propagation in the LSTDDSFLD list results gives all the display or printer fields that are linked to the propagated fields (and also the PF/LF fields).

This list is the base of the display and printer field modification process.

Automatic modification of DSPFs/PRTFs

It is possible to request the following modifications for the display fields (according to the modification at file level).

Example

3-character extension of quantity fields (shown here on ZQT1 4,0):

________________________________
Before:      ! Qty : ZQT1  Unit Pr : xxxx,xx !
!_______________________________

Here are the field length extension parameters:

*ALWAYS: Always visible

The display/printer fields visible by the user will directly mirror the field’s length extension. If more space is needed, the line on which the field is present will be slightly re-organized (deletion of blanks and shortening of text).

If even more space is needed, the display field is enlarged anyway; a “warning” is placed on the DDS of the display/printer field indicating a field overlap. No new display field is created (neither visible, nor hidden). 

_________________________________
After:         ! Qty ZQT1___ Unit Pr : xxxx,xx !
!_______________________________!
*NEVER: Never visible

You do not wish the user to be affected by the field extension. However, the display field was considered as enlarged in the program; it is, therefore, necessary to carry out specific processes to ensure the correct functioning of the display (or printer) file:

  • The field visible by the user will be renamed but will stay at the same position on the screen.  (Field $$F2)
  • The field having the previous name will no longer be visible (either declared on the screen in a hidden field or declared in the program). It will have the new length (Field $$F1).
  • It will be necessary to insert processes to change the $$F1 values to $$F2 before the screen display or from $$F2 to $$F1 after input; you will define these by using one or two display/printer routines.
_________________________________
After: ! Qty : XQT1 Unit Pr : xxxx,xx ! ZQT1 7,0 hidden field
!_______$$F2____________________! $$F1
*IFFITS: If it fits

*IFFITS corresponds to *ALWAYS as long as you can extend the field, otherwise this becomes *NEVER when there is not enough room in the line.

*ALWAYS: Always visible is automatically established if the field is still present on a screen.

Two different cases must be distinguished, and also the addition of a 3rd display field:

You have requested a behavior similar to the newly-added file field and the functioning by imitation has allowed you to reach right up to screen level; the display field ($$F1) therefore already has an associated field name for the new field in the program ($$A1).

Example

Propagated unitary price; the addition of a file field of the same length.

ZPXU P(6,2) propagated

And associated field ZPAU loaded in the program

_______________________________
Before:      ! Unit Pr : ZPXU  !
!______________________________!

Here are the parameters for screen modifications for an associated display field

*ALWAYS: Screen modification always visible

The newly-added field is placed in the screen, just before or just after the propagated field.

If there is not enough room, the field will be placed as a hidden field.

_________________________________
After:     ! Unit Pr : ZPXU   ZPAU  !
!___________$$F1____$$A1_________!
*NEVER: Screen modification not visible for the user

A new field is managed, but the screen must not be modified visually; the value displayed will either be that of the previous field ($$F1), or of the newly associated field ($$A1). To avoid any risk of program error, the display field will have a new name ($$F2).

It is by the intermediary of a routine inserted before display or after reading, that either the previous field value ($$F1) or the new field’s value ($$A1) will be sent to the screen in the $$F2 field.

________________________________
After: ! Unit Pr : XPXU__     ! Hidden fields ZPXU($$F1)
!___________$$F2________________!      and ZPAU. ($$A1)

You have not requested a behavior similar to the newly-added file field, or the functioning by imitation did not allow you to reach the screen; the display field ($$F1), therefore, has no associated field name in the program for the new field ($$A1 is blank).

In this case, you should only begin a screen modification if you can simulate the value of the new field (for example, with a conversion before the display carried out by a routine).

Example

A propagated unitary price, addition of a file field with the same length.

ZPXU P(6,2) propagated and no associated field

________________________________
Before:  ! Unit Pr : ZPXU       !
!_______________________________!

Here are the parameters for screen modifications where associated display field is blank:

*ALWAYS: Screen modification “Always visible”

The newly-added field is placed in the screen, just before or just after the propagated field.

If there is not enough room, the field will be placed as a hidden field.

Its name will be generated at the last moment.

________________________________
After:  ! Unit Pr : ZPXU   XPXU !
!___________$$F1____$$F2________!

*NEVER: Screen modification not visible for the user

No new field is managed, and the screen must not visually be modified; the value displayed will either be that of the previous field ($$F1) or the value calculated from $$F1 simulating the value of a new field. To avoid any risk of program error, the display field will have a new name ($$F2).

It is by the intermediary of a routine inserted before display or after reading that it will either be the value of the previous field ($$F1) or a value calculated from $$F1 which will be sent to the screen in the $$F2 field.

________________________________
After:   ! Unit Pr : XPXU       ! Hidden field ZPXU
!___________$$F2________________!

The objective of this 3rd display field is particular; it has nothing in common with a possible 3rd field added to the PF files.

This is a field for which the value should be allocated by one way or another just before the display or tested just after the input (using one or two standard routines).

Whether you previously put *NEVER or *ALWAYS will have no impact on this addition.

If requested, this 3rd field will be systematically added (either visibly if there is enough room, or as a hidden field if not).

Example

In the previous case, add a 3-character Currency Code field.

With an associated field, at *ALWAYS:

____________________________CPXU_
After:     ! Unit Pr : ZPXU    ZPAU    Eur !
!___________$$F1____$$A1____$$F3!

With an associated field, at *NEVER:

________________    CPXU________
After:! UnitPr:XPXU Eur! Hidden fields ZPXU ($$F1)
!___________$$F2____$$F3________! and  ZPAU ($$A1)

Without an associated field, at *ALWAYS:

____________________________CPXU_
After:      ! Unit Pr : ZPXU    XPXU    Eur !
!___________$$F1____$$F2____$$F3!

Without an associated field, at *NEVER:

____________________CPXU________
After: ! Unit Pr : XPXU  Eur ! Hidden field ZPXU
!___________$$F2____$$F3________!

The propagation results give you the LSTDDSFLD list in which the display or printer fields linked to the propagated fields (and also the PF/LF fields) are present.

In this list, a certain number of PF-LF fields are considered anomalies:

List of other database fields where the propagation ended.

This list can sometimes serve as a base for the automatic insertion of a process (via ACVTDDSFLD).

However, it is necessary that this list only contains the interface file fields, that is, the file fields that you do not wish to modify (no field addition or extension) but for which you wish to simulate after each reading of (or before each writing of) the field extension or addition carried out previously in other files.

This is also only possible if you possess the different ways to define a functionally suitable conversion process through a standard routine.

With these routines, we can also insert a voluntarily erroneous conversion process, but which indicates to the programmer that this program should be adapted.