Discussion :

[sphinou]

Bonjour,

Je suis en train de faire un mémoire sur la complexité du J2EE. J'aimerais comparer le J2EE au cobol.
Jusqu'à présent, j'avais entendu dire que le cobol est mort. Cependant dans l'entreprise où je travail je sais qu'il existe beaucoup de projet en cobol.
En plus des personnes me disent que le cobol n'est pas du tout mort et que c'est plus simple à développer en cobol qu'en J2EE.
Mes grandes questions sont :

pourquoi les entreprises développent des projets en cobol ?

Est ce qu'il existe de la complexité dans le développement cobol ?

Est-ce que l'architecture du cobol est facile à comprendre ?

Si quelqu'un peut m'aider se serait vraiment très sympa, j'ai beaucoup de mal à trouver des informations de ce style sur le cobol.

Merci

[Homer-ac]

Une réponse partielle sur COBOL qui est effectivement loin d'être mort.
Sa grande faiblesse est certainement sa couche présentation. Cobol reste cependant extrèmement compétitif quand il s'agit de traitement par lot (on parle de traitement Batch) et de façon générale quand on veut traiter des volumes conséquents de données et informations. D'une part par sa facilité d'écriture et surtout et je pense que c'est l'atout de sa survie quoi que l'on ait pu parfois prétendre, parce que le code généré s'avère rester très performant et permet d'économiser les ressources machine. Enfin c'est un langage ancien (années 1960) qui a su évoluer surtout en terme de structuration du code, donc encore très présent dans de grandes entreprises, je pense en particulier à des banques ou assurances mais aussi encore dans des secteurs industriels.
Un exemple vécu sur 'mainframe' IBM z/OS :
J'ai eu à écrire un programme de relevé de la totalité des fichiers catalogués et de leurs caractéristiques sur une partition z/OS d'un site (plusieurs centaines de milliers).
IBM proposait des exemples d'utilisation d'une méthode d'accès pas très évidente à mettre en oeuvre (IGGCSI). Ces exemples sont soit en langage REXX (un langage interprété mais on ne peut plus simple pour la compréhension et l'écriture), soit en Assembleur MVS (qui permet de programmer avec un soucis optimum de performances).
Le problème est que si la recherche de performances est prioritaire quand on décide de mettre en oeuvre ce type de méthode (sinon il y a des moyens d'accès aux catalogues autrement plus faciles). REXX en tant que langage interprété n'est certes pas une bonne idée, quant à l'assembleur MVS, les compétences disparaissent et les sites répugnent à laisser perdurer ces programmes.
J'ai donc écrit dans un premier temps mon programme en REXX, disons comme maquette. Puis ensuite un programme iso-fonctionnel COBOL créant un fichier résultant identique. Comme j'ai par ailleurs la chance de pouvoir utiliser le compilateur REXX (pas très usuel sur les sites MVS), j'ai pu également compiler le REXX pour obtenir un module exécutable et j'ai comparé les temps d'exécution des 3.
- Le REXX compilé est en gros 5 fois plus rapide que le REXX interprété.
- Le COBOL est également environ 5 fois plus rapide que le REXX compilé.
Bon c'est un exemple avec toutes les spécificités que peut impliquer un cas particulier, mais ça donne simplement une idée de ce qui reste un atout certain pour COBOL.

[el_slapper]

COBOL a un immense avantage : ça marche.

Ici, on a du cobol, du vb, du java. Le vb disparait parceque la migration vers .NET ressemble à un mur. Les grands chefs sont à fond pour java. Les devs de moins en moins. Pour plusieurs raisons

1)les conditions de développement. Le projet JAVA est devenu tellement énorme que les PC sont à genoux. En COBOL, on travaille sur un seul programme à la fois(sur central, mais on ne mets pas le central à genoux)
2)les performances. Sur très gros traitements, Java n'est efficace qu'avec une programmation optimisée pour le multithreading. Cobol se contente d'optimisations simples. La différence est énorme.
3)les formats de données complexes. Hors formats dynamiques(souvent peu pertinents en applications de gestion), Cobol est optimisé pour gérer des formats de données hyper-complexes.

Après, Java a aussi plein d'avantages. Mais, suivant le type d'entreprise, une couche cobol peut être un excellent choix pour gérer les informations de bas niveaux. Parfois même plus(mais soyons honnête, ça devient rare).

[sphinou]

Je suis surprise de ce qu'apporte le COBOL par rapport au J2EE.
En faites le COBOL a encore beaucoup de chemin à faire.

Merci beaucoup pour ces réponses elles vont être très utiles.

[fsmrel]

En faites le COBOL a encore beaucoup de chemin à faire.

Vous avez sans doute raison. Cela dit, j’ai écrit mon premier programme COBOL il y a quarante ans (mais oui...) et je dirais que c’est avec les vieilles marmites qu’on fait les bonnes soupes. Certes, c’est un langage orienté gestion, mais tant qu’il y aura à gérer des comptes dans les banques, des dossiers d’assurance dans les sociétés s’assurance, des prises de commande massives dans l’industrie, des trames téléphoniques à avaler, digérer chez les opérateurs, des impôts à faire rentrer à la DGI, etc., couplé à un SGBDR comme DB2, COBOL c’est la puissance du mammouth de l’Âge de glace, mais doublée d’un turbo. Le mammouth en a fait du chemin ! plus que n’importe quel autre langage ! Et des langages, il en a laissés sur le carreau...

Pourquoi les entreprises développent des projets en COBOL ?

COBOL a un sacré CV, il a fait ses preuves, même si tout le monde se moque de lui, ce vieux lourdaud qu’ils disent, avec sa casserolle (le célèbre GO TO).

Est ce qu'il existe de la complexité dans le développement COBOL ?

Non, si le développeur sait structurer sa pensée, donc ses algorithmes, donc sa programmation. Il utilise son jeu d'instructions favorites, correspondant à ce qui lui est nécéssaire et suffisant. A une époque, des rigolos avaient introduit une instruction étonnante "ALTER TO PROCEED" permettant de changer dynamiquement le comportement des instructions de branchement. Ceux qui s’en servirent s’en mordirent les doigts, car pour de la complexité, ça en injectait de la complexité et le débogage devenait impossible. Cette instruction redoutable fut rapidement bannie.

Est-ce que l'architecture du COBOL est facile à comprendre ?

Sans problème, avec une nette séparation données/traitements :

— Description de l’environnement, disons des entrées/sorties (fichiers), là, COBOL est très fort.
— Description des données proprement dites.
— Description des traitements.

En plus, la lecture d’un programme est très facile à aborder. Autrement dit, je saurais sans difficulté procéder à la rétro-conception de programmes que j'ai écrits il y a quarante ans.

[CobolProgrammator]

pour les applications orientées gestion cobol est le meilleur langage que je connaisse: c'est le meilleur rapport qualité prix, le plus compétitif, celui qui permet d'être le 1er en productivité. Son seul défaut c'est qu'aujourd'hui on ne jure (à tort je pense) plus que par les interfaces 'sexy' genre window, internet. Et encore des solutions existent et sont d'ailleurs utilisées pour la couche présentation.
Si on compare à java:
impossible d'aborder la programmation java sans une bonne formation ou alors on va à la catastrophe
temps de développement bien plus longs en java
Après ceux qui n'y connaissent rien diront que l'interface de développement mainframe est une horreur et qu'un environnement eclipse par exemple est beaucoup plus convivial : c'est une erreur de débutant à mon sens; est ce un progrés d'être obligé de travailler avec des écrans de 21", 2Go de RAM, la main sur la souris ?
La puissance de cobol : les variables conditionnelles (niveaux 77), la redéfinition de zones (REDEFINES) sont des caractéristiques de base hyper puissantes et simples à utiliser, qui simplifient grandement l'ecriture du code, évitent de faire des boucles inutiles, etc ...
Bon donc pour répondre à tes questions :
1) parcequ'elles ont déjà un existant en cobol qui fonctionnent très bien, pourquoi se compliquer la vie puissance 12 à vouloir changer ce qui fonctionne ?
2) non justement il n'y a pas de complexité, on peut s'y mettre facilement (attention cela ne veut pas dire que tous les programmes se valent: on distingue parfaitement un programme écrit par un bon programmeur qu'un programme écrit par un nul, et il y a une différence de performance entre les 2 et donc de cout d'utilisation
3) oui c'est facile à comprendre, même si c'est plus difficile pour un programme transactionnel que batch.

[Hédhili Jaïdane]

...les variables conditionnelles (niveaux 77)

Noms de condition niveau 88,
Niveau 77 juste pour éviter les alignements sur 4/8 octets (mot/double mot)

[el_slapper]

(.../...)
impossible d'aborder la programmation java sans une bonne formation ou alors on va à la catastrophe(.../...)

Je pense que ce point-là est celui qui surpasse tous les autres : pas besoin d'être intelligent ou bien formé pour faire du bon Cobol, il suffit d'être rigoureux. Pour faire du bon Java il faut être intelligent et bien formé et rigoureux.

Pour le distingo batch/transactionnel, beeeeen ça dépend surtout du focntionnel à gérer. J'ai fait des batchs hyper-lisibles - mais le fonctionnel s'y prétait. Un batch à multi-ruptures croisées sera difficille, mais une gestion fine de la pagination peut aussi vite tourner au casse-tête.

Pour le reste, sur les temps de développement notamment, il est possible de faire des merveilles avec de l'objet, sur certains sujets - aussi me garderais-je d'être aussi catégorique que toi.

[CobolProgrammator]

Noms de condition niveau 88,
Niveau 77 juste pour éviter les alignements sur 4/8 octets (mot/double mot)

Tout à fait ... aïe aïe aïe maintenant je fais de l'ideal non stop (depuis 2ans) et je commence à oublier cobol ...

[CobolProgrammator]

Je pense que ce point-là est celui qui surpasse tous les autres : pas besoin d'être intelligent ou bien formé pour faire du bon Cobol, il suffit d'être rigoureux. Pour faire du bon Java il faut être intelligent et bien formé et rigoureux.

Pour le distingo batch/transactionnel, beeeeen ça dépend surtout du focntionnel à gérer. J'ai fait des batchs hyper-lisibles - mais le fonctionnel s'y prétait. Un batch à multi-ruptures croisées sera difficille, mais une gestion fine de la pagination peut aussi vite tourner au casse-tête.

Pour le reste, sur les temps de développement notamment, il est possible de faire des merveilles avec de l'objet, sur certains sujets - aussi me garderais-je d'être aussi catégorique que toi.

Ah je veux bien le croire, mais cela ne dépend il pas de beaucoup de "si" = si la conception initiale a été bien faite, si trop de développeurs ne connaissant pas le fonctionnel sont venus ajouter leur patch au programme, bref si tout est parfait, ce qui tout simplement ne reflète pas la réalité ..?

[Hédhili Jaïdane]

Tout à fait ... aïe aïe aïe maintenant je fais de l'ideal non stop (depuis 2ans) et je commence à oublier cobol ...

T'occupe, je sais que c'est une simple coquille mais j'ai voulu rectifier pour ceux qui viendraient lire derrière.

[el_slapper]

En fait justement où je travaille ils veulent remplacer ideal par java petit à petit, et je trouve que franchement cobol aurait été plus adapté; au bout du compte je pense qu'on sera perdants car à l'avenir au lieu d'obtenir des augmentations ils devront payer les surcouts de développement (à mon avis les coûts vont être multipliés par 4 et ça va bien devoir pleurer dans les chaumières).

ça dépend de qui s'en occuppe.....et surtout du type d'applications que vous faites. Pour générer un email automatique en Java, il faut juste brancher l'API correspondante, alors qu'en COBOL, on va se farcir plein de technose. Le générateur XML de COBOL a aussi pas mal de limites(et j'en suis à revenir à une solution faite main). Bien utilisée, la couche objet de JAVA permet d'éviter un tas de redondances de codes..... Par contre, si vôtre appli, c'est juste de la gestion de données, alors oui c'est une idiotie.

[el_slapper]

Alors je précise: je travaille dans une banque et il ne s'agit donc pas de gérer des mails (évidemment que java aurait été adapté pour ça), mais de gérer des données.

tiens, mon ancien domaine.....remarque, maintenant, je suis en assurances, c'est xactement pareil. Et oui, là, le Cobol est très fort. Même si je regrette la lourdeur du modèle objet de Cobol3(en gros, elle rend ladite couche objet quasi inutilisable).

Celà dit, parfois, une banque aussi a besoin de générer des mails en automatique, que ce soit en interne(genre, le trésor nous a demandé de prélever 500€ d'impôts en retard sur le compte du client X appartenant à vôtre périmètre, merci de gérer sa réaction.....), ou en externe(genre, cher trésor, nôtre client Y qui vous doit 2000 €uros a malheureusement un compte en négatif, nous ne pouvons donc pas vous renvoyer la somme demandée - ce qui ne nous pas empeché de lui mettre 102 €uros de frais à cette occasion). Ce projet-là était en pur Java/JEE, ce qui a provoqué bien des lourdeurs, mais pour ce genre de détails, c'était quand même fichtrement pratique.