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.

[festy29]

Quand vous dites certaines grandes banques françaises, c'est un peu réducteur :

- Caisse des dépôts
- Banque de France
- Caisse d'Epargne
- CA
- BNP
- SG
- LBP
- Crédit Mutuel
- Crédit Lyonnais

Pour ne citer que celles pour lesquelles j'ai travaillé ....

[festy29]

Plus de 35 années avec PACBASE et je n'ai jamais eu d'erreurs de compil dues à PACBASE lui-même ...

[escartefigue]

CA et BNP sont sortis de PacBase il y a déjà quelques années et c'est en cours chez BPCE (c'est à dire Caisse d'Epargne, Banques populaires, Crédit Coopératif, BCP, Natixis...)
Il me semble que c'est fait aussi chez le Crédit Mutuel.

Bref, il ne reste plus grand monde, voire plus personne.

[festy29]

Bonjour,

Désormais, effectivement, il n'y a plus de client PACBASE car IBM a réussi à se désengager de celui-ci (après une levée de boucliers de + de 15 ans, vu les clients concernés).
Ceci dit, il y a 2 ans, développement d'une reprise en PACBASE au CA et jusqu'à la fin de l'année dernière, développement en PACBASE chez BPCE SI (CE) en attendant la mise en place et la bascule vers la solution de remplacement.
IBM a développé une solution de "rechange" que quasiment personne n'a adopté et qui n'est ni plus ni moins que du PACBASE "habillé".

[escartefigue]

À ce sujet

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.

Gérer le dictionnaire de données au niveau des traitements est une véritable hérésie ! C'est une source de redondances (synonymes nombreux) et de typage incohérent.
Le dictionnaire de données doit être créé et maintenu lors de la modélisation des données, MCD et dictionnaire doivent évoluer de concert. Les traitements ne font qu'hériter du modèle de données qu'ils utilisent.
Grâce au catalogue relationnel, il est très facile d'identifier les impacts avec de simples requêtes SQL.