Internal descriptions

1. The case of a complete database programming.

   FLDDCT gives you the list of LSTDBFFLD fields.

   A propagation not requiring an examination of the internal description (*).

2. The case of actual database files, but with programs directly re-describing them.

   FLDDCT gives you the list of LSTDBFFLD fields.

   A propagation requiring an examination of the internal description (*).

3. The case of non-database files (containing just one field (BUFFER) or two fields KEY and OTHER).

   FLDDCTS36 gives you the list of LSTDBFS36 fields.

   A propagation requiring an examination of the internal description (*).

4. The case of non-database files in mode 36.

   FLDDCTS36 gives you the list of LSTDBFS36 fields (with a file link in OCL36).

   The propagation examines the internal descriptions by default (*).

5. Files absent from the programs (buffer transmitted a file read/write program).

   AFLDDCTINT and AFLDDCTIN2 simulate the buffer descriptions compared to the external files.

   A propagation not requiring an examination of the internal description (*).

(*) Display/printer files

Whichever way the files are described, the display and printer files can be described as such:

1. External description in the programs (of DSPF and PRTF).

   Purely external description programming.

2. DSPF, DSPF36, PRTF exist but the buffer re-description is directly in the programs.

   Examination required for internal descriptions.

3. Printer Output described directly in the programs without any corresponding PRTF.

   (Printout Card O in RPG...)

   In the Transformer suite, this is compared to a fictive type PRTF36.

To sum up, if the data files and/or the display or printouts can be internally described, you must indicate Examine internal descriptions = *YES at the propagation.

When there are internal file descriptions, the processes are carried out in the following ways at the propagation and automatic modifications:

1. ACVTPGMFLD – Step 1 (Propagation: Entry in the programs)

   For each program where the files are used in internal descriptions (in RPG, RPG36, RPGLE, CBL, CBLLE, CLP, OCL36), a correspondence is established between:

   • The description of file fields (D.B. = PF, LF or non-D.B. = PF36)
   • The description of file fields in the Program (Card I and Card O in RPG…, Buffer descriptions in CBL, Sort Cards in OCL36, Sort Cards in the FMTDTA, utilization of record position in INCCHAR with CPYF in CLP…)

   With this, the impacted program fields are only found from the position of the field in the record.

   The internal descriptions are either in the main source, or in an included source.

   In the case of PF, the positions in the LF can be different if the LF only takes a few file fields or if it takes fields from several physical files.

   In the case of PF36, the files and index have the same description (except the keys).

   Note

   The new modified files must not have already been compiled. The files online (in the case of PF, LF) must be the old files.

2. ACVTPGMFLD – Step 2 (Propagation and Flagging)

   Just as the normal processes, this step also flags (without modification):

   • The definitions of fields that are the internal descriptions of files in the sources.

     (Card I and O in RPG, buffer descriptions in COBOL, …)

   • Detects the fields not supposed to be in the data files (and places them in the anomaly list of the non-initial file fields; in this list, they are each given a file type, “PF36” if the file is unknown, or PF or LF if it was found in the repository).

3. ACVTPGMFLD – Step 3 (Automatic modifications in the programs)

   In addition to the standard processes, this step carries out the following modifications:

   For the initial file fields:

   • In RPG..., position modifications at the beginning and end of extended fields (Card I or O).
   • In CBL..., length modifications of extended file fields.
   • In RPG…, possible addition of new fields (with beginning and end positions) (Card I or O).
   • In CBL..., addition of new fields in the file buffers.
   • In RPG.…, shifting of all beginning and end positions in the I or O cards if there was a field addition or extension in the lower positions.
   • In RPG..., record length modification, key position and length in Card F.
   • In CLP.…, record positions modifications (CPYF order with INCCHAR…), position modifications in the FMTDTA sort cards (however, no line addition in the case of field addition).
   • In OCL36…, position and length modifications in the BLDFILE, BLDINDEX orders, and the OCL36 sort cards (in the case of field addition, the positions are shifted but no line is created for the new fields).
   Important!

   Of course, if no fields to propagate are already present in cards I and O, the positions of the other fields are shifted anyway if a modified field exists in the file.

When working with a multi-format file, there are no modifications for the internal descriptions at this level:

• Display/printer file fields.
• Non-anticipated fields (present in the anomaly list).

1. ACVTDDSFLD – Modification of DSPF/PRTF

   The display fields and printouts are modified in the usual manner.

   However, the internal descriptions of these are also modified in order to correspond with the modifications made in the display fields and printouts (position shifts, field extensions, field additions).

   The routines inserted before display or after input, use the names of fields present in the new internal descriptions of these files.

2. ACVTDDSFLD – Modification of interface files

   If requested, this option only carries out a process of inserting routines before write or after read (by using the names of fields present in the program).

3. ACVTDBFFLD – Modification of PF sources

   This engine does not concern the internal descriptions. However, if your files exist as PF you should run it anyway to modify the D.D.S, otherwise it is of no use.

One of the most important characteristics of internal descriptions is that the file name in the program (visible from the outside) is not the same in all the programs that use one same file.

What really matters is the actual file name, even when in the programs, it is not the same.

With ARCAD Transformer Field, you will only use the file PCLIENT and a link must be found to the internal file names in each program.

D.B or non-D.B files

There are file substitution orders in CLP which call the programs:

OVRDBF FILE (file name in pgm) TOFILE (actual file name on disk)

These OVRDBF are often situated in the CLP that directly calls the program.

There are sometimes several call levels between the two:

• CLP1 carries out the OVRDBF
• CLP1 calls CLP2
• CLP2 calls PG1
• PG1 calls PG2
• PG2 uses the file from CLP1

To successfully find the actual name of the file on disk, it is recommended to place a pre-compilation command in the program:

H* %EXEC OVRDBF FILE (file name in pgm) TOFILE (actual file name on disk).

Non-D.B. files in mode 36

With ARCAD Transformer Field, you will only begin with the file named $.CLI and a link to the internal names of this file in each program must be found. (The $ replaces the variable characters of the file name.)

There are file substitution orders in the OCL36 that call the programs:

• // LOAD PG1
• // FILE NAME-CLIENTS, LABEL-?4?.CLI, DISP-SHR
• // RUN

These substitutions are often situated in the OCL36 that directly calls the program.

Sometimes, there may be several levels between the two:

• OCL1 carries out the FILE NAME
• OCL1 calls OCL2
• OCL2 calls PG2
• PG2 uses the file from OCL1.

To successfully find the actual name of the file on disk, it is recommended to place a pre-compilation command in the program:

H* %EXEC OVRDBF FILE (file name in pgm) TOFILE (actual file name on disk).

Example:

H* %EXEC OVRDBF FILE(CLIENTS)  TOFILE($.CLI).

This concept is used when you refer to a file while re-describing its positional record and while re-dividing the fields. These are internal descriptions of files.

The positional reference is made up of a 10-character name, written like this ‘XppppLgggg’:

• 1 character shows the type of buffer:

  • P - for a physical or logical file field
  • I - for a field declared as Input
  • O - for a field declared as Output
• 4 numbers (0000 to 9999) show the starting position of the field in the record.
• 1 character ‘L’ = Length.

• 4 numbers (0000 to 9999) show the number of characters used in the record to store the field.

  • For an alphanumeric field: it is the field length.
  • For a packed numeric field: it is the number of bytes taken to store the field.

Examples of positional reference

Field name	Field type	Description
P0025L0012	A(12)	Alpha file Field of 12 Char. Position 25 to 36
P0036L0008	P(15,2)	Packed numeric file field of 15 digits but 8 chars. Position 36 to 43.
I0075L0004	A(4)	Input buffer file field
O0045L0004	A(4)	Output buffer file field

This concerns the following case of files existing as PF(38) or LF(38) with the fields described separately.

However, in certain programs, the files are re-described internally. In this case, only the following operations need to be carried out also:

1. Process, if necessary, the names of files in the programs.
2. Indicate Examine the internal descriptions = *YES when running the propagation.