Discussion :

[Girv48]

Bonjour,

PACBASE va bientôt disparaître, avec plusieurs solutions possibles pour prendre la suite. Que ce soit avec IBM, RAINCODE ou HP, la façon de développer va être radicalement différente. Le seul point commun : au final ce sera du développement en Cobol.
Tous les utilisateurs de PACBASE n’ont pas forcément encore fait leur choix ou n'ont pas encore migré, donc cela ne concerne pour l'instant que peu de personnes, mais je ne trouve aucun avis de ceux qui ont les mains dans le cambouis.

Donc, en tant que développeur PACBASE et forcément bientôt concerné, j’aimerais bien avoir l’avis de ceux qui aujourd’hui font du Cobol Natif façon Raincode, ou du Rpp (IBM), ou autre. Quel est leur quotidien avec ces nouveaux outils, en terme de confort de développement notamment ? Ont-ils été mis dans de bonnes conditions avec suffisamment de formations ? Le gain de productivité mis en avant par certains DSI est-il effectif ? Bref un 1er avis sur ce qui attend finalement pas mal de personnes.

[escartefigue]

Bonjour,

J'ai connu plusieurs générateurs COBOL(Ariane, APS, PacBase) tous ont déjà disparu ou sont sur le point de le faire.
Ariane et PacBase ont en commun un code généré de très piètre qualité ce qui rend la reprise très complexe quand ces générateurs sont en en fin de vie.

A mon sens, la bonne démarche n'est pas de remplacer PacBase par un autre générateur, qui aura les mêmes travers, mais de former les développeurs pour qu'ils maitrisent le langage Cobol, qui survivra bien après tous les autres générateurs.

Il faudra du coup gérer un dictionnaire de données ce que peut faire Pac, mais est rarement bien utilisé
(il suffit de regarder le nombre de définitions de données redondantes sur les différents sites Pac installés pour s'en convaincre)

Un point d'attention particulier devra être accordé aux développeurs ne connaissant pas ou peu cobol : PacBase leur a donné de très mauvaises habitudes à tout point de vue (utilisation des sections, format des données, usage intensif des goto et surtout, cinématique traitement aberrante), la formation les concerne en premier chef.

[Girv48]

Tout à fait d'accord sur le fait que la formation à Cobol va être nécessaire. Pour les Pacbasiens développer en Cobol ne sera forcément évident au départ. Modifier un écran ou un état, ajouter ou supprimer des ruptures/synchros avec du Cobol généré depuis Pacbase en Cobol Natif, ça risque d'être rock'n roll ...
Mais ce n'est pas tout. La plupart des outils de remplacement de Pacbase font que le développement se fera principalement sur Eclipse, avec RDZ. Il va donc également falloir apprendre à fonctionner avec le multi-fenêtrage (question d'habitude sans doute), inhabituel pour les gens du Z/Os. Et peut-être aussi avec RTC, qui n'a pas l'air très évident à appréhender.

Bref l'intéressant là-dedans c'est de savoir, pour ceux qui y trempent déjà :
- le temps qu'il leur a fallu pour appréhender les nouveaux outils ?
- quelle mécanique est mise en place pour remplacer le dico de données ? Avec quels contrôles sur les données créées ?
- quid des normes, comment sont-elles mises en place ?

[escartefigue]

Pour ce qui concerne le dictionnaire de données, un travail considérable a été fait par l'ISO et repris dans de nombreuses normes d'échanges de données. Je pense notamment à EDIFACT dont le dictionnaire est très riche et très bien documenté.

Ce type de dictionnaire, partagé par des filières métiers, peut être une base pour un dictionnaire de niveau entreprise, il suffira (mais c'est déjà un gros travail) de restreindre aux données et domaines de valeur applicables, et de préciser les conditions et règles d'usage en interne (avec quelques exemples d'utilisation).