Appel de programmes en langage assembleur

Les programmes d'application en langage assembleur peuvent être invoqués par COBOL, C®, C++, PL/I ou par des programmes d'application en langage assembleur à l'aide des commandes LINK ou XCTL.

mode d'adressage 64 bits

Les programmes d'application en langage assembleur AMODE (64) qui contiennent des commandes peuvent avoir leur propre définition de programme RDO. Ces programmes peuvent être invoqués par des programmes d'application en langage COBOL, C, C++, PL/I ou assembleur à l'aide des commandes LINK ou XCTL.

mode d'adressage 24 bits et 31 bits

Les programmes d'application en langage assembleur AMODE(24) et AMODE(31) qui contiennent des commandes peuvent avoir leur propre définition de programme RDO. Ces programmes peuvent être invoqués par des programmes d'application en langage COBOL, C, C++, PL/I ou assembleur à l'aide des commandes LINK ou XCTL. Cependant, comme les programmes AMODE(24) et AMODE(31) qui contiennent des commandes sont invoqués par un appel standard du système, ils peuvent également être invoqués par une instruction COBOL, C, C++ ou PL/I CALL, ou par une macro CALL en langage assembleur.

Un programme d'application CICS® unique, tel que défini dans une définition de programme RDO, peut être constitué de CSECT distincts compilés ou assemblés séparément, mais liés entre eux.

Un programme d'application en langage assembleur qui contient des commandes peut être lié à d'autres programmes en langage assembleur ou à des programmes écrits dans un ou plusieurs langages de haut niveau ( COBOL, C, C++ ou PL/I ). Pour plus d'informations sur le mélange des langues dans un module de chargement d'application, voir Mélange des langues sur Language Environment. Pour plus d'informations sur les programmes ayant des modes d'adressage différents, voir Utilisation de modes d'adressage mixtes.

Si un programme en langage assembleur (qui est édité séparément) contient des appels de niveau commande et est appelé à partir d'un programme en langage de haut niveau, il nécessite son propre stub d'interface CICS. Si le programme assembleur est édité en lien avec le programme en langage de haut niveau qui l'appelle, le programme assembleur n'a pas besoin d'un stub. Si vous en fournissez un, le message MSGIEW024I est émis, mais il peut être ignoré.

Étant donné que les programmes d'application en langage assembleur contenant des commandes reçoivent toujours les paramètres EIB et COMMAREA lorsqu'ils sont invoqués, l'instruction ou la macro CALL doit transmettre ces deux paramètres, éventuellement suivis d'autres paramètres.

Par exemple, le programme PL/I du fichier PLITEST PLI appelle le programme en langage assembleur ASMPROG, qui se trouve dans le fichier ASMTEST ASSEMBLE. Le programme PL/I transmet trois paramètres au programme en langage assembleur : l'EIB, la COMMAREA et une chaîne de messages.

Figure 1 : PLITEST PLI

 PLIPROG:PROC OPTIONS(MAIN);
DCL ASMPROG ENTRY EXTERNAL;
DCL COMA CHAR(20), MSG CHAR(14) INIT('HELLO FROM PLI');
CALL ASMPROG(DFHEIBLK,COMA,MSG);
EXEC CICS RETURN;
END;

Le programme en langage assembleur exécute une commande EXEC CICS SEND TEXT , qui affiche la chaîne de messages transmise par le programme PL/I.

Figure 2. ASMTEST ASSEMBLE

DFHEISTG DSECT
MSG DS CL14
MYRESP DS F
ASMPROG CSECT
L 5,8(1)
L 5,0(5)
MVC MSG,0(5)
EXEC CICS SEND TEXT FROM(MSG) LENGTH(14) RESP(MYRESP)
END

Vous pouvez utiliser les procédures JCL fournies par CICS pour compiler et lier l'application, comme suit :

Assembler et relier ASMTEST à l'aide de la procédure DFHEITAL :

//ASMPROG EXEC DFHEITAL
//TRN.SYSIN DD *
.... program source ...
/*
//LKED.SYSIN DD *
NAME ASMTEST(R)
/*

Compiler et lier PLITEST à l'aide de la procédure DFHYITPL, et fournir des instructions de contrôle de l'éditeur de liens qui incluent le module de chargement ASMTEST créé par la procédure DFHEITAL :
```
//PLIPROG EXEC DFHYITPL
//TRN.SYSIN DD *
.... program source ...
/*
//LKED.SYSIN DD *
INCLUDE SYSLIB(ASMTEST)
ENTRY CEESTART
NAME PLITEST(R)
/*
```
Remarque : l 'étape 2 suppose que le module de chargement ASMTEST créé par DFHEITAL est stocké dans une bibliothèque incluse dans la concaténation de l'ensemble de données SYSLIB.

Le module de chargement créé par la procédure DFHYITPL comprend à la fois le stub DFHEAI (inclus par DFHEITAL) et le stub DFHELII (inclus par DFHYITPL). L'éditeur de liens ou le programme de liaison émet un message d'avertissement car les deux stubs contiennent un point d'entrée nommé DFHEII. Ce message peut être ignoré.

Si vous écrivez votre propre JCL, vous devez inclure le stub DFHELII, car il contient les points d'entrée nécessaires pour tous les langages.

Un programme d'application en langage assembleur peut commencer par la macro DFHEIENT et se terminer par la macro DFHEIRET. Le traducteur CICS les insère pour vous, donc si le programme contient des commandes EXEC CICS et qu'il est transmis au traducteur, comme dans l'exemple précédent, vous n'avez pas besoin de coder ces macros. Notez que DFHEIRET permet l'adressage relatif. S'il n'y a pas de registre de base, l'expansion de la macro ne génère plus de LTORG. Normalement, lorsque la fin est atteinte, l'assembleur génère un LTORG automatique pour rassembler les VCON restants. Si vous avez un code qui aboutit à un code privé CSECT au début de la concaténation CSECT, cela peut poser des problèmes. Lorsque l'instruction END est atteinte, l'assembleur revient à votre premier CSECT et ne peut pas résoudre le VCON à partir de celui-ci. Il est recommandé de vérifier les listes d'assembleurs et d'éliminer ce type de section de contrôle privée. Pour plus de détails, voir la section Unnamed dans la référence du langage High Level Assembler.