Discussion :

[tziani]

bonjour,

est ce que quelqu'un connaît les synchro rupture et pourrait me donner un exemple de rupture svp?

merci d'avance.

[escartefigue]

Bonjour,

Par curiosité et si ce n'est pas confidentiel, quel est votre client qui utilise encore PacBase ?

Ce générateur n'est plus maintenu, il génère un code de très piètre qualité et impose de nombreuses contraintes (notamment les noms d'attributs limités à 8 caractères et les noms de tables sur 4 )
PacBase était beaucoup utilisé chez certaines grandes banques françaises (Credit Agricole, BNP, Caisse d'Epargne)

J'espère que votre client ne conserve ce produit que pour les anciens traitements et l'a abandonné pour tous les nouveaux développements...

[faqfj64]

Bonjour

vous pourrez retrouver de la documentation officielle Pacbase sur ce lien ftp://public.dhe.ibm.com/software/vapacbase/pdf30_f/
Il vous faudra choisir le document "btc353.pdf" .

PS :
Pour Escartfigue ... L'intérêt de Pacbase n'était pas dans le code Cobol généré, qui n'est pas dans la logique de programmation algorithmique standard, mais principalement dans le dictionnaire. Si celui-ci était correctement administré alors les analyses d'impact sur des changements de format de données ou structure de flux était facilement identifiable.

[Luc Orient]

...
Ce générateur n'est plus maintenu, il génère un code de très piètre qualité ...

Le COBOL généré est carrément illisible ...

[M.Dlb]

Pour faire la transition entre Pacbase et du code Cobol natif (certainement plus lisible que celui généré), il existe RPP :
https://www.ibm.com/fr-fr/marketplac...mming-patterns

[faqfj64]

Le COBOL généré est carrément illisible ...

Le but de Pacbase n'était pas d'aller modifier directement dans le Cobol. C'était une abstraction de niveau supérieur.
Dire que le Cobol généré est illisible, c'est un peu trop partisan de mon point de vue.
Certes la structure des programmes Pacbase n'est pas celle que l'on apprend quand on code en Cobol Natif mais elle est lisible à qui veut bien la comprendre.
Sur ce ... je vais arrêter de débattre car ce sujet n'a plus lieu d'être car Pacbase est stoppé ou presque puisque Rpp a pris la suite.

[faqfj64]

Pour faire la transition entre Pacbase et du code Cobol natif (certainement plus lisible que celui généré), il existe RPP :
https://www.ibm.com/fr-fr/marketplac...mming-patterns

Rpp n'est qu'une nouvelle version Pacbase ou presque si l'on reste sur la facette "Pacbase" de l'outil.
Ce que Rpp apporte c'est que le code Cobol produit par le framework est directement visible et que l'implémentation du spécifique se fera en Cobol directement.

Pour faire la transition vers un Cobol Natif (ou plutôt vers un Cobol structuré) il existe des outils sur le marché pour vous aider.
Chaque outil a ses forces et ses faiblesses à vous de choisir en fonction des objectifs de votre société.

[Luc Orient]

Le but de Pacbase n'était pas d'aller modifier directement dans le Cobol. C'était une abstraction de niveau supérieur.

C'est l'argument habituel que nous sortent les thuriféraires de Pacbase ( vous n'avez pas à regarder le COBOL généré ! ). Sauf que parfois, l'outil arrivait à générer du COBOL avec des erreurs de compilation ! ... et là on fait comment ?

Je sais jamais vu un compilateur sérieux générer du code machine incorrect ...

[Kinalf]

Bonjour

Je vous trouve sévère avec Pacbase que j'avais utilisé il y a bien longtemps (PAC700 à l'époque )

PacBase avait certainement des imperfections mais également certains avantages.

En Batch une fois que l'on a compris la logique (pas si complexe et bien expliquée effectivement dans le document 'VisualAge Pacbase : Applications Batch' btc353f) avec ses indicateurs sur la synchronisation de fichiers cela peut même à mon sens faciliter la maintenance. Car on a l'avantage que tout le monde utilise la même logique.