Discussion :

[ji_louis]

Pour avoir fait de la transposition du COBOL vers java durant des années, je peux dire que la plupart des commentaires précédents sont justes.

COBOL est un langage ancien qui a les avantages et inconvénients de son époque: C'est un langage impératif très simple et très efficace (la compilation transforme le code en langage machine, il n'y a pas plus rapide). Mais il faut gérer "à la main" les espaces de mémoire destinés aux variable (tout programme est en 3 parties: déclaration des ressources [lecteurs de fichiers, bases de données, écrans, imprimantes, réseau, etc.], puis déclaration des variables et des structures de données [variables de boucles, lignes de fichiers plats, tupples de tables de Bdd, etc.], puis le code qui effectue les tâches demandées) et une valeur peut être interprétée à la fois comme du texte et comme un nombre par deux variables simultanées, il faut donc faire attention à ce qu'on fait. La taille des variables est définie individuellement, on peut définir un nombre avec une précision arbitraire, par exemple avec 20 chiffres avant et 100 après la virgule.

La longueur de la compilation (réel problème pour la maintenance quotidienne) est davantage due au matériel utilisé qu'au langage lui-même. Il existe des version de COBOL pour PC (entre autre par Microsoft).

La transition du COBOL vers des technologies plus récentes implique de TOUT remettre en cause:
- architecture matérielle (passer du mainframe aux serveurs distribués, au web, aux PC, etc.)
- architecture logicielle (passer des fichiers plats aux bases de données relationnelles ou non-relationnelles, de données source unique à des ressources distribuées)
- langages utilisés
Cela impacte l'organisation de l'entreprise, ses buts (c'est l'occasion d'abandonner des tâches ou de s'en fixer de nouvelles); la tâche est tellement importante qu'il faut un volontarisme fort et continu de la direction, tout simplement parce que cela implique une redéfinition complète du travail de l'entreprise ou de l'administration, et c'est ça la partie la plus difficile du projet.
Une fois les possibilités étudiées, les buts définis et les budgets débloqués, le projet et sur les rails. Si il y a ne serait-ce qu'un peu de flou dans la phrase qui précède alors le projet part au crash.

Finalement, la transition du COBOL vers autre chose est un projet transformant l'entreprise, qui ressort non pas de la responsabilité du DSI mais de la direction générale. C'est l'occasion de transformer Amazon d'une épicerie de quartier en géant mondial du commerce en ligne (pour illustrer le niveau de responsabilité des décision à prendre).

[JPLAROCHE]

Pour avoir fait de la transposition du COBOL vers java durant des années, je peux dire que la plupart des commentaires précédents sont justes.

COBOL est un langage ancien qui a les avantages et inconvénients de son époque: C'est un langage impératif très simple et très efficace (la compilation transforme le code en langage machine, il n'y a pas plus rapide). Mais il faut gérer "à la main" les espaces de mémoire destinés aux variable (tout programme est en 3 parties: déclaration des ressources [lecteurs de fichiers, bases de données, écrans, imprimantes, réseau, etc.], puis déclaration des variables et des structures de données [variables de boucles, lignes de fichiers plats, tupples de tables de Bdd, etc.], puis le code qui effectue les tâches demandées) et une valeur peut être interprétée à la fois comme du texte et comme un nombre par deux variables simultanées, il faut donc faire attention à ce qu'on fait. La taille des variables est définie individuellement, on peut définir un nombre avec une précision arbitraire, par exemple avec 20 chiffres avant et 100 après la virgule.

les decimal sont sur 31 chiffres, en Cobol tu n'a pas de tuple etc... ce sont des déclaration de variable , tu peux si tu est sur AS400 utiliser des déclaration de fichier toutes prêtes...

La transition du COBOL vers des technologies plus récentes implique de TOUT remettre en cause:
- architecture matérielle (passer du mainframe aux serveurs distribués, au web, aux PC, etc.)
- architecture logicielle (passer des fichiers plats aux bases de données relationnelles ou non-relationnelles, de données source unique à des ressources distribuées)
- langages utilisés
Cela impacte l'organisation de l'entreprise, ses buts (c'est l'occasion d'abandonner des tâches ou de s'en fixer de nouvelles); la tâche est tellement importante qu'il faut un volontarisme fort et continu de la direction, tout simplement parce que cela implique une redéfinition complète du travail de l'entreprise ou de l'administration, et c'est ça la partie la plus difficile du projet.
Une fois les possibilités étudiées, les buts définis et les budgets débloqués, le projet et sur les rails. Si il y a ne serait-ce qu'un peu de flou dans la phrase qui précède alors le projet part au crash.

Finalement, la transition du COBOL vers autre chose est un projet transformant l'entreprise, qui ressort non pas de la responsabilité du DSI mais de la direction générale. C'est l'occasion de transformer Amazon d'une épicerie de quartier en géant mondial du commerce en ligne (pour illustrer le niveau de responsabilité des décision à prendre).

c'est bien ce que je dis vouloir remplacer un AS400 ou IPOWER par un server pc c'est ce fourer le doitg dans l'oeil jusqu'au coude....
1) ce n'est pas la machine qui est en cause.
2) aujourd'hui COBOL-ILE (IBM) est un cobol très avancé et n'a rien à rougir devant le C/C++
3) la définition d'une base de donnée est un metier ça ne remet pas en cause le Cobol la Méthode AXIAL est fortement recommandé pour la definition BD.
4) pourquoi réécrire si c'est bien fait quelque chose qui fonctionne et tourne comme une horloge et que cela répond au problème d'une société

un exemple : http://www.ombrebleu.com/wxsrc/src/

[Matthieu Vergne]

Quand on investit dans du matériel, on prend en compte son renouvellement : on établit un budget qui prévoit le remplacement des machines qui tombent en rade par exemple. C'est pareil avec les technos, il faut prévoir leur remplacement. Et cela se fait autant au niveau budgétaire que technique : on démarre avec un système legacy qui fonctionne, on commence par le refactorer (si besoin) pour pouvoir l'utiliser en parallèle avec un autre système, si pas faisable on le planque derrière un "proxy" (le design pattern, pas le dispositif réseau) qui se chargera d'utiliser l'ancien ou le nouveau système, puis on commence à développer le nouveau système, à transférer progressivement les responsabilités de l'ancien vers le nouveau, jusqu'au jour où le nouveau peut faire l'intégralité du job, jour où l'ancien système peut être éteint (et le proxy retiré si plus besoin).

Ce sont des périodes transitoires à prévoir dans le cycle de développement des application à longues durées de vie. Et quand on le fait correctement, on le fait en créant un système facilement remplaçable.

En pratique, la plupart s'en foutent et se focalisent sur le court terme. Qu'ils ne viennent pas pleurer après, ils on fait leur choix.

Les gens qui postulent à ce genre de job ont je pense 2 perspectives :
- ils le font dans le but de comprendre le legacy pour le réimplémenter et le remplacer : ces gens là sont des champions et méritent leurs salaires.
- ils le font dans le but de maintenir le legacy : ces gens là sont des parasites qui font valoir leur rareté pour se faire richement payer mais ne règlent pas le problème de fond.

[commandantFred]

Quand on investit dans du matériel, on prend en compte son renouvellement : on établit un budget qui prévoit le remplacement des machines qui tombent en rade par exemple. C'est pareil avec les technos, il faut prévoir leur remplacement. Et cela se fait autant au niveau budgétaire que technique : on démarre avec un système legacy qui fonctionne, on commence par le refactorer (si besoin) pour pouvoir l'utiliser en parallèle avec un autre système, si pas faisable on le planque derrière un "proxy" (le design pattern, pas le dispositif réseau) qui se chargera d'utiliser l'ancien ou le nouveau système, puis on commence à développer le nouveau système, à transférer progressivement les responsabilités de l'ancien vers le nouveau, jusqu'au jour où le nouveau peut faire l'intégralité du job, jour où l'ancien système peut être éteint (et le proxy retiré si plus besoin).

Ce sont des périodes transitoires à prévoir dans le cycle de développement des application à longues durées de vie. Et quand on le fait correctement, on le fait en créant un système facilement remplaçable.

En pratique, la plupart s'en foutent et se focalisent sur le court terme. Qu'ils ne viennent pas pleurer après, ils on fait leur choix.

Les gens qui postulent à ce genre de job ont je pense 2 perspectives :
- ils le font dans le but de comprendre le legacy pour le réimplémenter et le remplacer : ces gens là sont des champions et méritent leurs salaires.
- ils le font dans le but de maintenir le legacy : ces gens là sont des parasites qui font valoir leur rareté pour se faire richement payer mais ne règlent pas le problème de fond.

Clairement, vous posez les bonnes questions.
Comme toujours, il y a plusieurs façons de faire le feu sous la pluie et la migration cobol vers X n'est pas différente d'une refonte logicielle sous contrainte. On rencontre les mêmes fondamentaux pour migrer du procédural vers l'objet, du RAD vers le cloud...
Plus haut dans ce topic, j'ai raconté une expérience désastreuse dans la migration d'un grand compte de l'AS 400 vers une architecture des années 2000. J'ai aussi connu une expérience couronnée de succès dans la migration d'une plateforme VAX vers VS-Oracle.

La différence entre les deux c'est un homme, chef projet free-lance qui embauche 2 développeurs pour un gros chantier et qui le réussit malgré le départ d'un des deux qui "n'a pas accroché sur la mission" et laissé un code PL/SQL de mauvaise qualité. Il ne connaissait pas la clause "GROUP BY" !

La première qualité de cet homme, c'est une implication totale. Il questionnait les utilisateurs parfois plusieurs fois par jour, imprimait ses schémas sur des A4 qu'il collait au scotch pour couvrir tout un mur de la salle de travail. Bon contact, toujours une blague pour mettre de bonne humeur et, au final, une crème de gars bouillonnant et gentil.

Sur la trentaine de projets que j'ai traité dans ma vie, je n'en ai jamais vu un fonctionner sans au moins un gars passionné par son job, qui a tout le projet dans la tête au point de n'utiliser le papier que pour se rappeler des types ou des nombres de décimales..

Ensuite, inévitablement dans une migration, on va se poser la question "from scratch ou portage ?". Il faut trouver la réponse à cette question avant de passer au fonctionnel avec la certitude de faire le bon choix...

[Nyrlodas]

Comme toujours dans ce genre de discussion, on peut lire une suite de messages absurdes et bien loin de la réalité.
Je fais du COBOL depuis 20 ans, et je vois que le reste du monde de l'informatique est différent de mon quotidien.
Je le vois d'autant mieux que je travaille avec des développeurs JAVA et JS. Et que je fais du Python en amateur.

Nous devons souvent répondre à la question : pourquoi des entreprises ne change pas leur périmètre Mainframe ?
Et bien je retourne la question : pourquoi devrait-elle le faire ? Pour quelle raison technique et/ou financière ?
Ensuite, je voudrais savoir si les personnes qui nous exhortent à changer savent ce que l'on fait vraiment ? (parce que les provocations sur les dinosaures, ça va deux minutes).

[Matthieu Vergne]

Nous devons souvent répondre à la question : pourquoi des entreprises ne change pas leur périmètre Mainframe ?
Et bien je retourne la question : pourquoi devrait-elle le faire ? Pour quelle raison technique et/ou financière ?

Parce que la technique, ça rouille. Donc soit on se satisfait de maintenir l'existant avec des moyens de moins en moins disponibles (moins de main d'oeuvre qualifiée, moins de support, etc.) ou devant être produis sur place (formation systématique des nouveaux sur des technos de plus en plus éloignées de ce qui s'apprend ailleurs), soit on remplace par du "matériel neuf" dont on trouvera plus facilement et à moindre coût les "pièces de rechange" et "extensions intéressantes".

Si on a juste de l'existant qui fonctionne et qu'on ne souhaite pas toucher, remplacer n'est pas forcément intéressant. Mais si on a besoin de faire évoluer, une techno en perdition fera naturellement monter les coûts. Simple jeu de l'offre et de la demande. C'est toujours une question de contexte.

[commandantFred]

Comme toujours dans ce genre de discussion, on peut lire une suite de messages absurdes et bien loin de la réalité.
Je fais du COBOL depuis 20 ans, et je vois que le reste du monde de l'informatique est différent de mon quotidien.
Je le vois d'autant mieux que je travaille avec des développeurs JAVA et JS. Et que je fais du Python en amateur.

Nous devons souvent répondre à la question : pourquoi des entreprises ne change pas leur périmètre Mainframe ?
Et bien je retourne la question : pourquoi devrait-elle le faire ? Pour quelle raison technique et/ou financière ?
Ensuite, je voudrais savoir si les personnes qui nous exhortent à changer savent ce que l'on fait vraiment ? (parce que les provocations sur les dinosaures, ça va deux minutes).

Pour ce qui me concerne, vous marquez le point. Si le système convient comme il est, aucune raison de changer. Sauf si...

J'ai dû aller sur wiki anglais pour avoir un aperçu de Cobol que j'avais refusé d'apprendre dans ma jeunesse.
Si on ne change pas l'architecture, il faut impérativement pouvoir s'interfacer avec elle. Le monde du cobol est quand même assez restreint.
Quelques questions me viennent :
Peut-on ouvrir un socket ip, lire et écrire librement dessus ?
Y a-t-il des patches qui permettent notamment d'interroger les bases de données en SQL ?

Evidemment, à force d'interfacer un mainframe avec les réseaux modernes, des redondances vont apparaitre mais ça n'a rien de rédhibitoire si ce n'est qu'un des deux mondes va lentement grignoter l'autre et je doute que ce soit le mainframe...

En tous cas, comme freelance, j'applique souvent l'adage "on ne change pas ce qui marche" à condition toutefois de pouvoir l'interfacer avec les nouveaux développements. Il faut notamment pouvoir lire et écrire dans les BDD.

[smarties]

Evidemment, à force d'interfacer un mainframe avec les réseaux modernes, des redondances vont apparaitre mais ça n'a rien de rédhibitoire si ce n'est qu'un des deux mondes va lentement grignoter l'autre et je doute que ce soit le mainframe...

En tous cas, comme freelance, j'applique souvent l'adage "on ne change pas ce qui marche" à condition toutefois de pouvoir l'interfacer avec les nouveaux développements. Il faut notamment pouvoir lire et écrire dans les BDD.

Je suis complétement d'accord avec toi.

Je n'ai jamais travail sur l'environnement COBOL mais je retiens que les choses créées sont robustes et rapides.
Sauf que pour les faire évoluer, il y a un fort manque de compétence et de gens intéressés. On se retrouve donc avec un système qui doit souvent évoluer (je pense aux banques et assurances) et une technologie (donc le COBOL) dont les nouveaux ne veulent pas.
A mon avis, ça finira par être le manque de compétence qui aura raison du COBOL et les systèmes seront forcés d'évoluer.

[Nyrlodas]

Parce que la technique, ça rouille. Donc soit on se satisfait de maintenir l'existant avec des moyens de moins en moins disponibles (moins de main d'oeuvre qualifiée, moins de support, etc.) ou devant être produis sur place (formation systématique des nouveaux sur des technos de plus en plus éloignées de ce qui s'apprend ailleurs), soit on remplace par du "matériel neuf" dont on trouvera plus facilement et à moindre coût les "pièces de rechange" et "extensions intéressantes".

Si on a juste de l'existant qui fonctionne et qu'on ne souhaite pas toucher, remplacer n'est pas forcément intéressant. Mais si on a besoin de faire évoluer, une techno en perdition fera naturellement monter les coûts. Simple jeu de l'offre et de la demande. C'est toujours une question de contexte.

Sur ce point, je suis d'accord. D'autant que je suis amené à former des collaborateurs et de faire de l'assistance.
Et les nouveaux arrivants ne sont pas toujours à la hauteur après leurs formations (mais on arrive à corriger le problème).
J'ajouterai que le monde du Mainframe n'a pas la même souplesse autour du travail d'équipe que les autres équipes (attention, il s'agit d'un problème culturel plus que technologique) et qu'il est parfois difficile d'encadrer des nouveaux arrivants.

Mais :
- Des écoles (IUT) vont se remettre à former en Mainframe.
- La technologie donne pleinement satisfaction et n'a rien d'obsolète.
- Les technologies plus récentes ont le même problème, car il y a un manque de stabilité et nécessite de former constamment les collaborateurs (c'est un constat pas un jugement).

Pour répondre à un autre message : oui, le Mainframe est très facile à connecter à d'autre plateforme.

[JPLAROCHE]

Pour ce qui me concerne, vous marquez le point. Si le système convient comme il est, aucune raison de changer. Sauf si...

J'ai dû aller sur wiki anglais pour avoir un aperçu de Cobol que j'avais refusé d'apprendre dans ma jeunesse.
Si on ne change pas l'architecture, il faut impérativement pouvoir s'interfacer avec elle. Le monde du cobol est quand même assez restreint.
Quelques questions me viennent :
Peut-on ouvrir un socket ip, lire et écrire librement dessus ?
Y a-t-il des patches qui permettent notamment d'interroger les bases de données en SQL ?

Evidemment, à force d'interfacer un mainframe avec les réseaux modernes, des redondances vont apparaitre mais ça n'a rien de rédhibitoire si ce n'est qu'un des deux mondes va lentement grignoter l'autre et je doute que ce soit le mainframe...

En tous cas, comme freelance, j'applique souvent l'adage "on ne change pas ce qui marche" à condition toutefois de pouvoir l'interfacer avec les nouveaux développements. Il faut notamment pouvoir lire et écrire dans les BDD.

Franchement vous ne connaissez vraiment pas COBOL allez voir COBOL-ILE rien a envier au C/C++ alors oui c'est du propriétaire IBM mais c'est largement aussi bien et même mieu que le c/c++ en tout cas pour faire de la gestion il n'y a pas photo .
les requête sql mais il y a plus 20 ans que cela existe ......

[Escapetiger]

Le Cobol est utilisé pour le code spécialisé, genre calculer des taux dans quelque opération financière complexe.

Le risque à migrer dans une techno plus récente est de remplacer un code qui marche par un qui fait des erreurs de calcul.

La difficulté à migrer un code Cobol est aussi lié aux mauvaises pratiques d'antan : nom de variables cryptiques, code spaghetti a base de Goto, pas de documentation ni de commentaires, etc... On se contente donc de patcher les programmes existants pour l'adapter aux nouveaux usages. Ceux qui ont une compréhension globale du code sont depuis longtemps à la retraite, voire morts et enterrés.

Salut Jeff,

je me permets de te reprendre amicalement de volée sur ce point en tant que débutant Cobol en 1982 pour une grande institution française, respectueuse et rendant compte des deniers publics (je pense que c'est toujours le cas : la Défense, plus précisemment l' Armée de l'Air) :

On utlisait toujours des cartes perforées, les écrans cathodiques étaient loués l'équivalent de 1 500 € (actualisés de mémoire) par mois par IBM, Bull et compagnie ...
Impression sur des listings 80 - 132 colonnes ...

L'algorithme, les spécifications étaient écrites en commentaire dans le code, faute de mieux, d'outils appropriés, de compréhension du personnel non-informaticien, etc...

Le hardware, la mémoire, coûtait une blinde ; d'où le codage de l'année sur 2 chiffres par exemple (512 octets c'était le maximum autorisé), etc d'où des programmes en assembleur, puis la sous-traitance avec les SSII/ESN (véritable pénurie d'informaticien.ne?s) à l'époque))... le bug de l'an 2000 ...

Qui peut perdurer juqu'en 2016 (bon, enfin là , c'est plus politique qu'autre chose ...) :
L'Éducation nationale envoie une partie de l'algorithme admission post-bac... sur format papier
Droit des lycéens demande de l'aide pour l'analyser


À plus de 60 ans, le langage COBOL est encore utilisé par des États américains

Jean E. Sammet, une informaticienne qui a participé au développement de COBOL,
Est morte à l'âge de 89 ans

....

Grace Murray Hopper, née le 9 décembre 1906 à New York et morte le 1er janvier 1992 dans le comté d'Arlington, est une informaticienne américaine et Rear admiral (lower half) de la marine américaine. Elle est la conceptrice du premier compilateur en 1951 (A-0 System) et du langage Cobol en 1959.
Source : Grace Hopper - wikipedia

[edit]
Et pour être plus au coeur du sujet «Ces vieux langages sont toujours demandés par les grandes entreprises, mais en pénurie de compétences», lesdites entreprises n'investissent plus sur ce que l'on appelle le legacy (70 % du chiffre d'affaire en banque-assurance pour le Cobol en France tout de même il y a peu ) :

En 2020 il y a t-il encore de l'avenir pour le Cobol ?

Migration Zos vers UNIX/LINUX

Abandon du ZOS pour les systèmes distribués

[edit 2]
Pour ce qui est des compétences, de mémoire, IBM et Cap Gemini ont mis en place en France une «académie Cobol», des promotions d'une vingtaine de personnes par an plutôt jeunes (~ la trentaine maximum), motivées, triées sur le volet, etc. pour le plus grand bien de leurs clients respectifs ....

Il existe ausssi la version industrielle dans le mauvais sens du terme pour des résultats plus aléatoires - tant pour les candidat.e.s que pour les entreprises - à travers des SSII/ESN du type Adaming :
Avis sur Adaming - SSII

[houariES]

Trouvez-vous cette étude pertinente ou pas ? Oui et c'est toujours d'actualité

Votre entreprise utilise-t-elle toujours d'anciens systèmes et dispositifs ? Oui et a de plus en plus de mal a trouver des profils ou à attirer des jeunes pour les former