Le module présenté dans cet article est le résultat d’un travail collaboratif entre plusieurs personnes, dont David Malle et moi même.
La première version de cet outil, développée il y a quelques années, ne me donnait pas complètement satisfaction, et j’avais demandé à  David de m’apporter son expertise et ses idées, de manière à  le rendre plus paramétrable. David était allé bien au delà  de mes attentes, en prévoyant une solution encore plus puissante et paramétrable que ce que j’avais envisagé. Il ne le savait sans doute pas avant que j’écrive cet article, mais je l’ai souvent béni par la suite pour sa clairvoyance, car je dois reconnaître que sa solution m’a rendu, et continue de me rendre, de grands services.

Cet article résulte du développement d’une édition un peu particulière, produite récemment pour un client, et qui a donné lieu à  la mise au point d’un algorithme s’appuyant sur le concept de listes mémoires, dont j’ai parlé dans un précédent article.

Le concept de liste mémoire est une véritable bouffée d’oxygène pour les développeurs Adelia, qui bénéficient ainsi d’une fonctionnalité très puissante, pouvant remplacer avantageusement le système des fichiers temporaires (« montés » dans QTEMP) cher aux développeurs AS/400. Mais l’on verra que tout n’est pas rose avec cette nouvelle technique, et qu’il vaut mieux en connaitre les inconvénients pour ne pas l’utiliser de manière inconsidérée.

Curieusement, Hardis ne fournit pas d’outil permettant de dupliquer aisément un environnement de développement Adelia. Il nous a fallu trouver une solution, que je vous expose ci-dessous.
Vous pouvez trouver différents avantages, à  employer cette technique. Dans mon cas, il s’agissait essentiellement de disposer d’un environnement qui soit la copie conforme de l’application en production, me permettant d’intervenir rapidement sur tout problème lié à  la production, tandis que mon équipe et moi même pouvions entamer une série de modifications importantes sur l’environnement de développement courant.