Troubleshooting
In certain cases, it is necessary to modify the sources before propagation and automatic modifications.
Sometimes it can be useful to manually modify the sources before propagation so that the propagation can allow you to validate the modifications (by detecting the inconsistencies on the nature of fields and by obtaining high quality automatic modifications), instead of carrying out these modifications after the propagation.
There are 3 distinct methods to carry this out:
-
Modification by a version that will be transferred to production.
The transfer to production restarts the
AUPDXREF
. -
Modification directly in the repository.
Only if ARCAD Skipper is not used on your machine.
You should restart the
AUPDXREF
for each modified component. -
Modification in the version where you use ARCAD Transformer Field.
You can check out the components to be modified, modify them and then compile them. However, ensure that you run an
AUPDXREF
with VERSION(*CURRENT) having been placed in the version. The source and the cross-references taken into account will be those of the version.
When you apply the changes (AAPYFRMCHG
), the manually-modified source will be replaced by the automatically-modified source, based on the manually-modified source. You therefore lose the intermediate source.
For all ARCAD Transformer Field processes, the cross-references of each component are taken into account. But it is possible to have several levels of cross-references for one component.
The cross-reference (and source) level present in the version is taken into account if the component was checked out and modified, with the cross-references updated and *CURRENT in the version. The *LASTPRD cross-reference level, the level corresponding to the last version transferred to production for each component (or the initial version if the component was never checked out) is also taken into account.
Certain cross-references can be present without affecting ARCAD Transformer Field, such as cross-references made on other open versions (not transferred to production) and that have a higher or lower version number than the version for ARCAD Transformer Field or old versions of component cross-references conserved despite the transfer to production of a new, more recent version for the component.
It is possible to propagate several applications at the same time, starting from the files of one or several applications. First, open a version in each application then specify the version numbers when running the ACVTPGMFLD
command.
All the other ARCAD Transformer Field commands are single-application. To work on multiple applications with other commands, go in to each corresponding version and run the other engines (ACVTDBFFLD
and ACVTDDSFLD
) or the application modification commands (AAPYFRMCHG
).
Issues that arise when using RPT, RPT38 or RPT36 language often lead to an incorrect or incomplete operations in ARCAD Transformer Field. This language uses a pre-compiler that gives you the possibility to re-arrange the included specifications:
PG1 in RPT - Contains /COPY WSRCALC found anywhere in the program.
WSRCALC (type RPT or RPG) - Contains I cards and C cards.
The RPT pre-compiler includes the I cards and C cards in two different places in the program.
Problem: When loading cross-references in ARCAD (AUPDXREF
), you cannot use the RPT pre-compiler because it doesn’t offer the possibility of giving the cross-references of program field-lines. It is, therefore, the RPG compiler that is used. It includes all the COPY clause cards in one place which leads to compilation errors and, by consequence, incomplete or erroneous cross-references (field lengths changed to 4A, for example).
Consequence: In ARCAD Transformer Field, the propagation and automatic modifications are incomplete or incorrect.
Solution: Before loading the repository of your application, use the ARCAD command ASCNRPLRPT
to analyze the RPT. It will indicate if it is a COPY of multi-card specifications, or even single-cards but incorrectly placed in the source.
This command also allows you to automate a process that removes this inconvenience in the RPT:
- Split the included COPY into several distinct sources (same name with card I or C, etc... at the beginning or end of the name).
- Modify the main sources by implementing COPY clauses where they belong in the new sources.
You can leave the RPT-type on the main source as long as the compilation doesn’t rearrange anything. The COPY/ clause must be situated in the place corresponding to its contents.
Problem: Programs called in SBMJOB by RTGDTA or QCMDEXC often leads to an incorrect or incomplete operations in ARCAD Transformer Field.
The repository loading detects these program calls where the CALL PGxx is placed in a character string. You can see them by consulting the program-to-program cross-references.
Loading the cross-references also memorizes the parameters used in the calling program. In this specific case, it is a character string that is used to execute the call.
CHGVAR VAR(&CMD) VALUE(‘CALL PGXX PARM(‘ *CAT &VAR1 *BCAT &VAR2 *CAT ‘)’.
CALL QCMDEXC PARM(&CMD 100)
Here, the field cross-references cannot find the names of the variables which were used for the call.
Solution: If you want complete cross-references (ensuring a propagation from program-to-program via the parameters), add a bit of code in this program. The code will never be executed but it will simulate a standard call.
GOTO AFTERCALL
CALLPGXX PARM(&VAR1 &VAR2)
AFTERCALL: ...
You can find all the programs in this case by asking ARCAD for all the programs that call the QCMDEXC or by using ACRTXRFLST...
or:
ADSPXRF REFTYPE(*PMPGM) REFOBJ(QCMDEXC) MBRTYP(*PGM) APPID(XXX)
Problem: Whatever the language, it is sometimes useful to transfer a data structure in one single parameter which is broken up according to the transmitted parameters. Transferring parameters by DS for multi-use often leads to an incorrect or incomplete operations in ARCAD Transformer Field.
Solution: To propagate and modify correctly, verify and modify the programs so that they respect this rule: use a different DS when you use a list of different parameters.
In this example there is no ambiguity between the 2 D.S. The propagation will give the correct results.
DS1: CLICOD1 from 1 to 10 and NOFAC from 11 to 18.
DS2: CLICOD2 from 1 to 10 and ARTCOD from 11 to 30.
CALL PG1 PARM(DS1)
MOVEL CLICOD1 CLICOD2(To retrieve the client code)
MOVEL XXX ARTCOD
CALL PG2 PARM(DS2)
CALL PG1 PARM(DS1)
Because the MOVEL DS1 DS2, the 2 DS are superimposed for the propagation, this example will lead to several incorrect derived fields (ARTCOD assimilated to NOFAC).
DS1: CLICOD1 from 1 to 10 and NOFAC from 11 to 18.
DS2: CLICOD2 from 1 to 10 and ARTCOD from 11 to 30.
CALL PG1 PARM(DS1)
MOVEL DS1 DS2(To retrieve the client code)
MOVEL XXX ARTCOD
CALL PG2 PARM(DS2)
CALL PG1 PARM(DS1)
The data structure in this example has contents of a different nature according to the situation. This will lead to several incorrect derived fields (ARTCOD assimilated to NOFAC).
DS1: CLICOD from 1 to 10 and NOFAC from 11 to 18 and ARTCOD from 11 to 30.
CALL PG1 PARM(DS1)
MOVEL XXX ARTCOD
CALL PG2 PARM(DS1)
CALL PG1 PARM(DS1)