Le développement de PACBASE

Pour Bernard Chapot, l’important est maintenant d’installer son produit en tant que leader des AGL du marché.

On commence à utiliser ce sigle pour caractériser les Ateliers de Génie Logiciel.

Il est vrai que PAC avait commencé à tuer la concurrence, Protée et Ariane ses principaux concurrents ayant eu du mal à s’adapter au transactionnel.

Ces deux produits étaient eux aussi des dictionnaires de données avec générateur de programmes COBOL, inspirés un peu de la méthode CORIG.
Certains anciens de CGI avaient d’ailleurs un peu trempé dedans.

1982 fut donc l’année du lancement du développement de ce qui allait devenir PACBASE sans en connaître encore le nom à l’époque.

On restait pour le moment sur PAC, en essayant de résoudre deux points très importants.

Une ergonomie permettant de mettre à jour en pleine page les informations du référentiel, et  la capacité de générer des programmes transactionnels avec accès aux bases de données puisque c’était le besoin des clients et le grand défi pour les entreprises d’offrir des applications en temps réel.

Pour  cela, on allait donc s’appuyer sur PAC TP qui avait été le point de départ de l’outil transactionnel, mais en le modernisant et en tenant compte des demandes des clients et aussi de l’expérience vécue pour le réaliser.

On continuerait donc à s’appuyer sur la structure de la base, physiquement avec les fichiers index et relatifs (AN, AR) et le fichier journal (JO), logiquement sur les bibliothèques et les versions assurant une gestion de l’espace et du temps.

ChainePac

La première chose à faire fut donc de revoir toute la présentation, avec des écrans de type fiche pour traiter les informations individuelles, et de type liste pour les collectives.

Avec bien sûr la possibilité de les mettre à jour en pleine page comme tout bon éditeur qui se respecte.
En interne, dans le produit, on retrouvait bien sûr toutes les entités qui avaient été utilisées précédemment, celles représentant les modèles de CORIG C, programmes et documentations comprises.

Avec aussi la nécessité d’assurer une compatibilité vers le haut, autrement dit continuer à gérer un programme de 1972 sans avoir à modifier quoi que ce soit.

Du coté du référentiel, c’était surtout de la technique mais l’autre face du volet, c’est à dire proposer un outil permettant de générer les applications transactionnelles, c’était autre chose puisqu’il fallait non seulement créer le générateur mais aussi la méthode.

      Dialogue

Car CORIG C, entièrement dédiée au batch,  ne proposait rien pour le temps réel,

Les premières réunions de travail avaient donc défini les grandes lignes, et ce fut à Pascal Garrigue qu’on attribua la responsabilité de ce projet.

On lui associa Bernard Maury qui devait plus particulièrement se pencher sur l’aspect base de données.

La première chose fut de choisir un nom, important sur l’aspect marketing, et on lui affecta le code «DIALOGUE». qui représentait bien l’objectif de ce type d’application, un dialogue entre l’homme et la machine.

On n’était plus dans les chaînes batch avec le traitement par lots, on passait vraiment dans le monde du temps réel.

Le module DIALOGUE avait donc pour objectif  : la conception, la documentation, la génération automatique et la maintenance des applications transactionnelles.

Vaste programme, sans oublier bien sûr la portabilité qui n’était pas évidente à l’époque puisque plusieurs Moniteurs Transactionnels se partageaient le marché.
CICS, IMS DC pour IBM, TDS pour Bull et d’autres .

Mais les trois premiers focalisant le maximum de clients, on allait plutôt se pencher sur eux.

Il fallait donc une génération automatique d’un source correspondant à l’image physique de l’écran (type BMS ou VIP/Questar), une autre pour le  COBOL correspondant aux traitements associés à chaque écran avec, cerise sur le gâteau, la possibilité de générer un fichier des libellés d’erreurs et de documentation pour les utilisateurs des systèmes conversationnels générés.

L’écran Help n’était pas oublié avec la fonction souffleur, une documentation interactive pour les utilisateurs des applications développées.

Tous les éléments nécessaires aux différentes générations devaient être écrits en langage PAC et les sources  obtenues en fonction des variantes de matériel, de langage, et de moniteur TP.

Ambitieux, mais avant tout réaliste.

Pour cela, observons les échanges d’un dialogue entre l’utilisateur et la machine.

Chaque écran d’une application transactionnelle reçoit un message, interprète ce message, effectue les traitements en rapport et envoie une réponse ou arrête l’application.

Plus de détail en lisant ici PACBASE