Après avoir poussé vos changements, la compilation est généralement la chose la plus intéressante à accomplir. Le moyen le plus simple consiste à utiliser l'action Build qui, par défaut, génère un membre CL nommé COMPILE. CLLE pour compiler chaque membre changé, en utilisant la dernière commande compile utilisée à partir
Construire les membres changés
du RSE.
Bien entendu, vous pouvez modifier
les membres changés au fil des besoins
et, en configurant votre style de
construction à partir des propriétés du
projet, vous pouvez stopper le comportement
par défaut qui entraîne la
régénération de ce membre CL chaque
fois que vous sélectionnez l’action
Remote Actions, Build. Cette action
pousse vers la bibliothèque associée
du projet et le compile et l’exécute sur
l’iSeries.
De plus, si vous créez manuellement
un membre BIND.CLLE, lui aussi
sera poussé, compilé et exécuté sur un
build, mais seulement si le membre
COMPILE se compile et s’exécute correctement.
C’est là que vous pouvez
mettre des actions de post-compilation
comme la liaison de vos modules ILE
dans des programmes et des programmes
de service. Tous les builds
soumis sont affichés dans un « iSeries
Build Job Status », où on peut facilement
surveiller leur état dans la file
d’attente des jobs.
Au terme de l’opération, toutes les
erreurs provenant de toutes les compilations
sont combinées et vous pouvez
les afficher dans une vue Error List
unique en faisant un clic droit sur l’action
Retrieve Errors dans la vue Build
Status. Comme dans le RSE, quand
vous double-cliquez sur l’une de ces
erreurs, le membre est ouvert dans
l’éditeur et vous vous trouvez juste sur
l’erreur. Bien entendu, si vous avez utilisé
des vérificateurs, vous n’aurez plus
jamais d’erreurs de compilation dans
vos membres RPG, Cobol ou DDS. La
figure 4 montre les vues Build Job
Status et Errors List.
On nous demande souvent d’affecter
de façon permanente la liste des bibliothèques
d’un projet afin que les
builds choisissent les bibliothèques
nécessaires. La réponse est la même
que dans le cas du RSE : utiliser l’action
Properties sur la connexion associée,
dans la vue Remote Systems, dans la
page Subsystems, iSeries Commands.
Il existe d’autres options pour les
builds, appelées build styles. Par
exemple, il existe un build style pour
simplement exécuter une commande
iSeries que vous indiquez dans la configuration
du build style. C’est le bon
choix si vous avez déjà un processus
pour construire votre application. Si
vous utilisez sur l’iSeries certains produits
classiques de gestion du changement,
il est probable qu’ils fournissent
leurs propres build styles, lesquels s’intègrent
dans la perspective iSeries
Project. L’action build est conçue spécialement
pour que les fournisseurs
puissent l’étendre et la développer, ce
qu’ils ont fait.
Téléchargez cette ressource
Solutions Cloud & Services Managés Simplifiés
Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les identités des développeurs doivent être prises en compte !
- Architecture de données ouverte : un levier essentiel pour maximiser les bénéfices de l’IA générative
- Les DRH repensent leurs priorités en 4 étapes
- Patch Tuesday Septembre 2024
- L’ambivalence des plateformes d’observabilités : entre similitudes et divergences