| 
I L E La phase traditionnelle d'un compilateur est la traduction de code source en instructions machines. Puis, dans un deuxième temps intervient une phase de liage, intégrant plusieurs modules déja compilés et gérant les liens entre ces modules(appels, points de retour et partage des variables) L'une des particularités de l'AS/400 est (était) de générer en une seule phase des pgms directement exécutables et autonomes. Le lien avec d'autres pgms se faisant à l'exécution, c'est à dire : - recherche du pgm appelé (liste de bibliothèques, contrôle des autorisations, résolution de l'adresse), - réservation mémoire et chargement, gestion du point de retour - transmission des paramètres (passage d'adresse) Ce type de pgm est appelé aujourd'hui OPM (Original Program Model), les liens générés à l'exécution étant des liens dynamiques |
|
IBM nous propose aujourd'hui le concept ILE : Integrated Language Environment Environnement commun SAA (compilateurs et CPI communs) Apportant : des liens statiques ET dynamiques des routines communes de gestion - d'erreurs - de messages - de mémoire du débogage avec visualisation de source l'optimisation du code généré des routines générales - mathématiques - dates et heures - gestion dynamique d'écran en V2R30 par l'intermédiaire de ILE C/400 en V3R10 ILE/RPG-IV , ILE/COBOL et CL ce sont de nouveaux compilateurs, de nouveaux produits, un nouveau type de source (RPGLE par ex.) |
|
Quelques particularités des compilateurs ILE : - optimisation améliorée : + code plus granulaire + élimination des sous-expressions communes 1 x = B * C 2 y = (B * C) + (D * E) ==> B * C éliminé + élimination des redondances 1 A = B + C ... ... A non utilisé 99 A = E + F ==> instruction 1 éliminée CRTxxxMOD OPTIMIZE(*NONE,*BASIC,*FULL) - débogage avec visualisation du source CRTxxxMOD DBGVIEW(*STMT=instructions, *SOURCE=visu du source, *LIST=liste de compil, *NONE (dft) ,*ALL) |
|
LIEN STATIQUE: unité d'utilisation = procédure - partie de code à point d'entrée unique - réalise une fonction, une action - n'est PAS un objet OS/400 V3r10 + RPG : une procédure par source V3r60 : x procédures par source + COBOL : x procédures par source + C/400 : x procédure(s) par source Appel d'une procédure = "call bound" (CALLB en RPG, CALL PROCEDURE en COBOL, CALLPRC en CL) les procédures apparaissent dans la liste d'invocation (DSPJOB/opt 11) unité de compilation = module - résultat d'une compil. (base = un membre source) - contient une ou plusieurs procédures (code compilé) - c'est un objet OS/400 *MODULE - n'est PAS EXECUTABLE |
|
LIEN STATIQUE: unité d'exécution = programme - objet de type *PGM - lien dynamique (appel par CALL) - OPM = CRTxxxPGM xxx étant le type de source ILE = CRTPGM phase de liage de modules existants = LIENS STATIQUES (copie de code) AVANTAGES: - meilleures performances - meilleure intégration de langages différents - préambule à la POO ? (Programmation Orientée Objet) INCONVENIENTS: - duplication du code = moins de souplesse, duplication en mémoire = maintenance des applicatifs compliquée !!! |
|
CRTxxxMOD CRTPGM PGM(PROG01) + MODULE(A B C) ..fichier source............ : .RPG................... : : : : : ############### : : membre A : :-> # MODULE A # -- ####################### : :.....................: : ############### ! # PROG01 : *PGM # : : ! ####################### : .COBOL................. : ############### ! # # # # : : membre B : :-> # MODULE B # > # # # P1 # : :.....................: : ############### ! # A # B ######## : .C..................... : ! # # # # : : membre C | P1 | P2 : :-> ############### ! # # # P2 # : :.....................: : # MOD.C P1 P2 # -- # # # # :..........................: ############### ####################### la création de PROG02 à partir des modules A,E,F,G entraînerait la duplication du module A dans cet autre programme. ==> pas de recherche d'adresse,de mémoire,etc.. à l'appel de module A ==> si modification du module A : recréation des pgms PROG01 et PROG02. |
|
MAIS: les liens dynamiques (CALL) sont toujours valides vous pouvez créer des pgms simples ne contenant qu'un seul module CRTBNDRPG = CRTRPGMOD + CRTPGM + DLTMOD Pour diminuer les problèmes de duplication de code pour les procédures souvent utilisées, ILE introduit un nouveau type d'objet: *SRVPGM (programme de service,équivalent des DLL Windows ou OS/2) Objet contenant un ensemble de modules (donc de procédures) Le lien est fait par référence (dynamique) à l'appel du pgm principal, ensuite l'appel d'une procédure est statique. (les modules système sont des *SRVPGM = bibliothèques de fonctions) |
|
*SRVPGM: CRTxxxMOD CRTSRVPGM SRVPGM(SRV01) + MODULE(B C) EXPORT(*ALL) ..fichier source............ : .RPG................... : : : : : ############### : : membre A : :-> # MODULE A # : :.....................: : ############### : : ################ : .COBOL................. : ############### -- # # # : : membre B : :-> # MODULE B # ! # # P1 # : :.....................: : ############### > # B ######## : .C..................... : ! # # # : : membre C | P1 | P2 : :-> ############### ! # # P2 # : :.....................: : # MOD.C P1 P2 # -- # # # :..........................: ############### ################ |
|
*SRVPGM: CRTxxxMOD CRTPGM PGM(PROG01) MODULE(A) BNDSRVPGM(SRV01) ..fichier source............ ################# : .RPG................... : # Prog01 # : : : : ############### # (ref : SRV01) # : : membre A : :-> # MODULE A # ------> ################# : :.....................: : ############### / : : ################ : .COBOL................. : ############### # # # : : membre B : :-> # MODULE B # # # P1 # : :.....................: : ############### # B ######## : .C..................... : # # # : : membre C | P1 | P2 : :-> ############### # # P2 # : :.....................: : # MOD.C P1 P2 # # # # :..........................: ############### ################ |
|
On peut modifier un module dans un programme existant sans re-linker : UPDPGM PGM(PROG01) MODULE(A) On peut modifier un programme de service de la même manière : UPDSRVPGM SRVPGM(SRV01) MODULE(B) Attention, si l'on ajoute un module dans le programme de service il y a alors un contrôle (type level-check) avec les programmes qui utilisent. il faut recompiler les programmes |
|
OU, utiliser le langage d'exportation
avec EXPORT(*SRCFILE) et placer dans QSRVSRC des ordres :
STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*NO)
ou STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES) SIGNATURE(xxx)
[ici la signature est imposée]
et placer un ordre EXPORT par procédure
exemple :
******* début des données **********
STRPGMEXP PGMLVL(*CURRENT) SIGNATURE(V1)
EXPORT SYMBOL('B')
EXPORT SYMBOL('P1')
EXPORT SYMBOL('P2')
ENDPGMEXP
********* fin des données ***********
|
|
Pour faciliter le liage, il existe un nouveau type d'objet *BNDDIR (Binding directory) = répertoire de liage Référence un ensemble de modules et de pgms de service dont peut avoir besoin une application, évite de lister tous les modules à lier. Le programme de liage ira chercher dans cette "directory" toutes les références non résolues. (noms de modules et de fonctions non trouvés) Commandes associées : CRTBNDDIR ADDBNDDIRE DLT " RMV " " DSP " WRK " " WRK " ET ENFIN ILE apporte un nouveau concept : la notion de groupe d'activation C'est un sous-ensemble de la notion de job permettant un cloisonnement, donc une indépendance, des applications. |
|
Chaque programme détermine à quel groupe d'activation il appartient: indiqué à la création CRTPGM ACTGRP( *NEW > un nouveau groupe est créé CRTSRVPGM *CALLER > groupe d'activation de l'appelant un_nom > appartient à ce groupe) Un groupe d'activation possède ses propres ressources : - contrôle de validation (COMMIT/ROLLBACK) - ODP (ouverture de fichiers) - partage (SHARE) = OPNSCOPE() - utilisation d'un résultat OPNQRYF " - influence d'une commande de substitution = OVRSCOPE() - option de nettoyage (RCLRSC <> RCLACTGRP) - établit une frontière pour la gestion des erreurs (messages) (influence d'une erreur dans la liste d'invocation) |
|
Tout job possède au moins un groupe d'activation : *DFTACTGRP. Chaque groupe d'activation possède un identifiant numérique unique Résumé : création du groupe d'activation lors de l'appel du premier pgm de ce groupe.(les pgms OPM ont le même groupe d'activation) détruit par : - un ordre de fin sur le programme, si *NEW. (SETON LR en RPG, STOP RUN en COBOL, ...) - la commande RCLACTGRP ou SIGNOFF. - tant que le groupe d'activation existe, la mémoire associée aux programmes (même terminés) n'est pas récupérée (appels suivants plus rapides) les programmes de services restent chargés |
