Discussion :

[Bill Fassinou]

AWS veut-il tuer les mainframes ? Le fournisseur de services de cloud computing veut remplacer les mainframes par des serveurs à grande échelle
et COBOL par Java

Lors de l'édition 2021 de son événement re:Invent, qui s'est tenu du 29 novembre au 3 décembre à Las Vegas au Nevada, AWS a fait une flopée d'annonces, dont une a particulièrement retenu l'attention : le leader mondial des services de cloud computing a présenté "AWS Mainframe Modernization", un nouveau service géré qui permet aux entreprises de migrer leurs charges de travail mainframe vers le cloud. Beaucoup d'acteurs ont applaudi cette annonce et des critiques ont déclaré que AWS Mainframe Modernization pourrait être la réponse au problème des migrations de mainframes ridiculement complexes.

AWS pourrait nuire aux entreprises fournisseurs de mainframes

Même si les mainframes sont encore très présents dans les grands groupes, en particulier dans les banques et les assurances, et continuent d'être la colonne vertébrale d'une immense quantité de transactions, ils sont désormais en voie de disparition. Et AWS semble vouloir accélérer cette tendance. En effet, aujourd'hui, le coût, l'agilité et de nombreux autres facteurs incitent les entreprises à migrer vers des infrastructures modernes, mais un certain nombre de problèmes doivent être traités avant, pendant et après le processus de migration. Il s'agit, entre autres, de la complexité des applications et de leur compatibilité avec le cadre cible proposé.

Tous ces éléments auront une incidence sur les résultats de la migration et sur les opérations commerciales globales d'une entreprise. Comme la gestion des systèmes informatiques hérités tels que les mainframes pose un certain nombre de défis, les responsables informatiques doivent être préparés à faire face à ces problèmes et à ces processus complexes. Ainsi, bien que certaines organisations ressentent le besoin de migrer leurs charges de travail vers une infrastructure moderne, elles peinent à franchir le pas. La réponse du leader mondial des services de cloud computing est "AWS Mainframe Modernization". Le nouveau service offre deux options aux clients.

Certains peuvent vouloir remanier leurs charges de travail mainframe pour les faire fonctionner sur AWS en transformant les applications héritées - probablement écrites en COBOL - en services modernes basés sur Java dans le cloud. Les clients peuvent également conserver leurs applications telles qu'elles sont écrites et réorganiser leurs charges de travail sur AWS en réutilisant le code existant avec un minimum de modifications. AWS Mainframe Modernization promet un pipeline de migration complet, de bout en bout, qui comprend les outils de développement, de test et de déploiement nécessaires à l'automatisation du processus.

« Avec le lancement d'AWS Mainframe Modernization, les clients et les intégrateurs de systèmes peuvent désormais moderniser plus rapidement leurs charges de travail mainframe existantes de manière prévisible et se débarrasser d'une grande partie de la complexité et du travail manuel qu'impliquent les migrations », a déclaré William Platt, directeur général des services de migration chez AWS. Ce service met le fournisseur de services de cloud computing en concurrence avec les fabricants de mainframes et les fournisseurs de logiciels spécialisés, parmi lesquels IBM, Unisys, Bull, NEC et Fujitsu. Le nouveau produit d'AWS pourrait être un bâton dans leurs roues.

Selon Adam Selipsky, PDG de l'entreprise, AWS Mainframe Modernization peut réduire le temps de migration de deux tiers grâce à l'automatisation quasi complète du processus. En partant d'une analyse du mainframe, AWS Mainframe Modernization décide si le "refactoring" ou le "replatforming" est la meilleure solution avant de proposer des options.

Il peut également automatiser la réécriture du code : Selipsky a spécifiquement déclaré qu'il est capable de convertir COBOL en Java tout seul. Cette dernière fonctionnalité ne manquera pas d'enthousiasmer ceux qui veulent utiliser l'apprentissage automatique et ses capacités d'analyse, mais qui n'ont pas le bagage nécessaire pour le faire.

Les produits d'AWS pourraient accélérer la disparition des mainframes

Plus de 50 ans après l'apparition du premier mainframe, le System/360 d'IBM, ces machines imposantes sont encore très présentes dans les secteurs de la banque, de l'assurance et du commerce de détail, grâce à leur capacité à traiter efficacement d'énormes volumes de transactions, et à leur réputation en matière de sécurité et de temps de fonctionnement. Cependant, ces systèmes sont incroyablement coûteux et difficiles à entretenir, et le nombre de personnes qualifiées pour s'occuper de ces logiciels anciens ne cesse de diminuer. Depuis des années, AWS tente d'inciter ses clients à délaisser les mainframes et migrer vers ses centres de données.

Cette fois-ci, l'entreprise affirme avoir construit un moteur d'exécution qui fournit toutes les capacités de calcul, de mémoire et de stockage nécessaires à l'exécution d'applications remaniées et "replatformées", tout en gérant automatiquement l'approvisionnement en capacité, la sécurité, l'équilibrage des charges, la mise à l'échelle et la surveillance de l'état des applications. AWS a assuré que comme tout cela se fait via le cloud public, il n'y a pas de coûts initiaux, et les clients ne paient que pour la quantité de calcul provisionnée.

La banque brésilienne Banco Inter a été l'une des premières organisations à s'inscrire à Mainframe Modernization avec AWS. « En utilisant le runtime géré AWS Mainframe Modernization, nous espérons simplifier nos opérations de traitement des cartes pour une résilience et une évolutivité accrues », a déclaré Guilherme Ximenes, directeur technique chez Banco Inter. « Nous sommes également enthousiasmés par le pipeline DevOps CI/CD qui nous permettra d'accroître l'agilité dont nous avons besoin pour offrir plus rapidement à nos clients de nouvelles capacités de transaction par carte de crédit et de débit ».

Par ailleurs, certains critiques pensent qu'AWS Mainframe Modernization est particulièrement bienvenue dans le monde post-pandémique, qui a vu les mainframes et COBOL revenir dans l'actualité en raison de l'incapacité des vieux mainframes obsolètes à traiter les demandes de chômage. « Les mainframes sont ainsi revenus dans l'esprit du public et l'on s'est rendu compte que tout le monde voulait qu'ils disparaissent, mais que la plupart d'entre eux en dépendent encore », ont-ils déclaré.

Actuellement, AWS Mainframe Modernization est disponible en avant-première dans les régions de l'Est des États-Unis (N. Virginia), de l'Ouest des États-Unis (Oregon), de l'Asie-Pacifique (Sydney), de l'UE (Francfort) et de l'Amérique du Sud (São Paulo), avant d'être étendu à d'autres sites "dans les mois à venir".

Source : AWS

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez du service géré AWS Mainframe Modernization ?
IBM doit-il craindre pour son chiffre d'affaires sur le marché des mainframes ?
Pensez-vous que les mainframes vont effectivement disparaître ou resteront-ils encore longtemps ? Pourquoi ?

Voir aussi

AWS présente une flopée de nouveaux services de bases de données et de ML, et annonce en Preview version RDS Custom pour Microsoft SQL Server et AWS DMS Fleet Advisor

98 % des responsables informatiques envisageraient de migrer des mainframes vers le cloud, même si 96 % d'entre eux considèrent que les applications mainframe sont importantes, selon LzLabs

AWS présente Proton, le service de gestion des conteneurs, pour automatiser le développement et le déploiement des conteneurs et d'applications "serverless"

[autran]

De façon plus générale, de nombreuses maitrises d'ouvrages se posent déjà la question du remplacement de leur mainframe.
Parmi les solutions proposées, les architectures cloud émergent de plus en plus souvent.

Quant au langage, c'est un peu la même chose pour palier la perte de maitrise au départ des "sachants" COBOL.
Le langage JAVA adresse toutes les problématiques des grosses applications mainframe/COBOL (performances - sécurité...). De plus, il est est totalement mature pour une industrialisation large spectre (CI/CD - DEVOPS) et surtout il est maitrisé par toute une génération 25/55ans

[JPLAROCHE]

Passer du COBOL au JAVA ?????
ça doit être un troollll ,
Lla conception de Cobol est tourné vers les applications de gestion d'entreprise, d'autre part le Cobol à largement évoluer c'est méconnaître le Cobol que de dire que c'est un vieux langage,
A moins que l'on veuille dire que le langage existe depuis longtemps...
D'autre part j'aurai un 360 à migrer j'irai voir les nouveaux IPOWER avec le CobolILE(comparable au C et même mieux) et je ferais une moulinette ... , j'en profiterais pour nettoyer…
les techniques du Cobol utilisant les 3270/5250 et des frames très petites permette d'aller très vite dans les réseaux…
Mais je ne mettrais certainement pas cela en cloud avec java à moins d'être frapa dingue il y a d'autres solutions.
J'oubliais ils prêchent pour leurs paroisses.

[thamn]

Passer du COBOL au JAVA ?????
ça doit être un troollll ,
Lla conception de Cobol est tourné vers les applications de gestion d'entreprise, d'autre part le Cobol à largement évoluer c'est méconnaître le Cobol que de dire que c'est un vieux langage,
A moins que l'on veuille dire que le langage existe depuis longtemps...
D'autre part j'aurai un 360 à migrer j'irai voir les nouveaux IPOWER avec le CobolILE(comparable au C et même mieux) et je ferais une moulinette ... , j'en profiterais pour nettoyer…
les techniques du Cobol utilisant les 3270/5250 et des frames très petites permette d'aller très vite dans les réseaux…
Mais je ne mettrais certainement pas cela en cloud avec java à moins d'être frapa dingue il y a d'autres solutions.
J'oubliais ils prêchent pour leurs paroisses.

Mmh, en regardant sur wikipedia, je vois:
- la dernière version du langage COBOL date de 2014
- le COBOL ne gère pas la récursivité (??!!!!)
- le COBOL ne gère pas l'allocation dynamique de mémoire
- le temps de compilation serait lent
- le langage serait verbeux

A cela, je présume que je peux rajouter (même si je n'ai pas vérifié):
- que le code exécutable généré est probablement a 1000 lieux de ce que pourrait générer un compilateur "moderne".
- qu’écrire et exécuter des tests en COBOL doit être compliqué
- je présume aussi que les outils disponible ne doivent pas être super, et pas super accessible non plus
- de ce que je peux voir, il semblerait que les compilateurs soient très différents selon la plateforme
- je parle même pas du tooling (outil de formatage? generation de documentation? analyse de code?)
- je ne parle même pas des aspect de securite, et des bibliothèques disponible

Bref, ce langage semble aujourd'hui totalement archaïque, encore pire si on compare a ce qu'on fait de plus récent.
Honnêtement, je peux comprendre que ce langage pouvait avoir un intérêt quelconque pour une entreprise il y a 40 ans (intérêt qui probablement relevait de la "portabilité du langage" et sa relative simplicité j'imagine face a d'autre langage plus complexe de l’époque, ça devait rassurer les RHs qui déjà a l’époque ne devaient pas valoir un clou pour ce qui est de comprendre les métiers pour lequel ils recrutent..).
Mais, aujourd'hui, j'ai vraiment du mal a comprendre.

Je n'ai pas d'attrait particulier pour le Java, mais:
- les outils sont disponibles (documentation, testing, analyse de code), maintenus et continuent d’évoluer
- le langage est utilise par une grosse communauté (c'est le moins qu'on puisse dire ^^)
- le langage continue d’évoluer (dernière version en date d’âpres wikipedia: septembre 2021 et je présume que Java 16 n'est pas apparu il y a 7 ans parce qu'il me semble qu'a l’époque j'ai du utiliser Java 6 ou 7)
- il dispose du minimum vital pour un langage de programmation digne de ce nom (je veux dire, allocation dynamique, et récursivité sont possible, je dis pas que c'est forcement a utiliser mais des fois c'est quand même bien pratique hein).
- vu la relative simplité du COBOL, il semblerait possible d’écrire un transpileur vers un autre langage

@JPLAROCHE vous auriez un argument pour soutenir votre choix?
Parce que vous décrivez ce que vous feriez, mais vous ne dites pas pourquoi il serait plus efficace de le faire comme ça et pas autrement.

[autran]

Passer du COBOL au JAVA ?????
ça doit être un troollll ,
.........
Mais je ne mettrais certainement pas cela en cloud avec java à moins d'être frapa dingue il y a d'autres solutions.
J'oubliais ils prêchent pour leurs paroisses.

Non il ne s'agit pas d'un Troll mais de projets très sérieux déjà réalisés dans le monde réel.

Les sociétés de conseil qui proposent cette migration sont des players réputés (Cap Gemini - Atos - KPMG - Accenture). Et ils argumentent leurs proposition avec des éléments très tangibles sur 4 axes :

• Performances
• Coût
• Planning
• UX

En particulier : Les couts de redéveloppement sont largement compensés par le gains d'exploitation des serveurs d'application JEE en mode SaaS ou PaaS, versus le TCO colossal des MainFrames.
Bien entendu, on parle de projets à étaler sur des plannings à la maille annuelle et non des projets menés en quelques mois. Mais au final, l'utilisateur comme le client seront gagnant puisque l'ergonomie web sera toujours préférable aux IHM proposées dans le monde COBOL et que l'on pourra passer sur un mode de développement des services plus proche des métiers.

[TotoParis]

Mmh, en regardant sur wikipedia, je vois:

Il faudrait changer de référence que ce pitoyable Wikipedia.
Lire ceci par exemple : https://www.ibm.com/support/pages/en...tation-library (c'est juste au hasard !)

- la dernière version du langage COBOL date de 2014

IBM entreprise COBOl : 2019.

- le COBOL ne gère pas la récursivité (??!!!!)

Ah ben sûr que oui, même si c'est pas forcément ancien. Quant à son utilité...

- le COBOL ne gère pas l'allocation dynamique de mémoire

Ah que si même si nativement c'est récent, on pouvait utiliser depuis longtemps les service FREEMAIN et GETMAIN de LANGUAGE ENVIRONMENT : encore faillait-il lire la documentation IBM, démarche rarement suivie, que ce soit par des jeunots à la grande gueule, ou des plus anciens...

- le temps de compilation serait lent

Ah elle est bien bonne celle-là. J'ai jamais lu plus ridicule.

- le langage serait verbeux

En effet, un peu trop. Une expression comme "TOTAL = QUANTITE * PRIX" dans n'importe quel langage, peut s'écrire :
"COMPUTE TOTAL = QUANTITE * PRIX" ou MULTIPLY QUANTITE BY PRIX GIVING TOTAL" : en effet, c'est lourd à écrire.

A cela, je présume que je peux rajouter (même si je n'ai pas vérifié):

Ah ben faudrait un peu vérifier soi-même ou demander à des personnes qui en savent plus que vous.

- que le code exécutable généré est probablement a 1000 lieux de ce que pourrait générer un compilateur "moderne".

Le compilateur IBM est l'un des meilleurs au monde. Son code gère des adressages sur 64 bits, avec une franche et massive évolution du jeu d'instruction assembleur.

- qu’écrire et exécuter des tests en COBOL doit être compliqué

Pas pire qu'en C ou en Java. Sans outillage, comme XPEDITER, c'est en effet difficile, mais pas pire que faire du Python dans on EDI favori.

- je présume aussi que les outils disponible ne doivent pas être super, et pas super accessible non plus

Les outils sont en format terminal à la mode TSO : c'est une interface texte en effet. Sinon XPEDITER, que je connais très bien, est facile d'accès, et très puissant.

- de ce que je peux voir, il semblerait que les compilateurs soient très différents selon la plateforme

C'est un peu logique : les architectures technique sont fort différentes.

- je parle même pas du tooling (outil de formatage? generation de documentation? analyse de code?)

Formatage : en effet, ça manque.
Génération de documentation : idem.
Analyse de code : non, il y a plein d'outils, comme Code Coverage chez Microfocus, Compuware's Xpediter/Code Coverage, et sans doute d'autres.

- je ne parle même pas des aspect de securite, et des bibliothèques disponible

Le système Z/OS est l'un des plus sécurisé qui soit, sinon le plus sécurisé au monde. Aucune plateforme UNIX ou de cette famille ne peut le prétendre (comme la faille SSH l'a montré il y a quelques temps), ou alors au prix d'une armada de dispositifs logiciels et matériels des plus hallucinant (et merci la maintenance de ce "machin" alors).
Quant à Java, la dernière faille avec LOG4J est tout simplement hallucinante.

Bref, ce langage semble aujourd'hui totalement archaïque, encore pire si on compare a ce qu'on fait de plus récent.
Honnêtement, je peux comprendre que ce langage pouvait avoir un intérêt quelconque pour une entreprise il y a 40 ans (intérêt qui probablement relevait de la "portabilité du langage" et sa relative simplicité j'imagine face a d'autre langage plus complexe de l’époque, ça devait rassurer les RHs qui déjà a l’époque ne devaient pas valoir un clou pour ce qui est de comprendre les métiers pour lequel ils recrutent..).
Mais, aujourd'hui, j'ai vraiment du mal a comprendre.

C'est pourtant simple : à une certaine époque, il n'y avait que cela : Mainframe et COBOL, pour les traitements sur de grandes quantités de données.
Unix et ses serveurs, c'était bon pour bricoler dans son garage. Quant aux RH, en effet, ils n'avaient pas il y a 40 ans la même formation que de nos jours.

Je n'ai pas d'attrait particulier pour le Java, mais:
- les outils sont disponibles (documentation, testing, analyse de code), maintenus et continuent d’évoluer
- le langage est utilise par une grosse communauté (c'est le moins qu'on puisse dire ^^)
- le langage continue d’évoluer (dernière version en date d’âpres wikipedia: septembre 2021 et je présume que Java 16 n'est pas apparu il y a 7 ans parce qu'il me semble qu'a l’époque j'ai du utiliser Java 6 ou 7)
- il dispose du minimum vital pour un langage de programmation digne de ce nom (je veux dire, allocation dynamique, et récursivité sont possible, je dis pas que c'est forcement a utiliser mais des fois c'est quand même bien pratique hein).
- vu la relative simplité du COBOL, il semblerait possible d’écrire un transpileur vers un autre langage

Le paradigme Objet n'est pas forcément adapté à l'informatique de gestion pour faire des traitements batch. Depuis bien longtemps déjà l'essentiel du TP se fait via une interface web qui communique avec un Mainframe et du COBOL / DB2 derrière. Il manque juste la possibilité de définir des fonctions (autrement que sous forme de sous-programmes) : ça existe depuis si longtemps dans des langages qui ne sont même plus en vogue, que cela en est frustrant.

[TotoParis]

Un aspect essentiel n'est pas évoqué : les logiciels COBOL "traduits" en JAVA restent les propriété du client, ou c'est AMAZOn qui en devient propriétaire ?
Les données sont transférées chez AMAZON : dans quel pays ?
BNP PARIBAS avait tenté le coup en Inde pour la tenue de compte il y a pas mal d'années : le Gouvernement les a vite remis à leur place...

[JPLAROCHE]

vous auriez un argument pour soutenir votre choix?
Parce que vous décrivez ce que vous feriez, mais vous ne dites pas pourquoi il serait plus efficace de le faire comme ça et pas autrement.

Beaucoup parle du cobol en ce référent au cobol PC opensource , mais ne connaisse que très peu le monde IBM MainFrame .

Alors oui les 360/370 etc... peuvent migrer sur des IPOWER qui eux traitent aussi bien avec HTML / que les applications natives. De plus la notion OBJET y est fortement implémenté. L'implémentation Cobol-ILE y est natif voir l'installation avec le RPG-ILE
la lecture des sources ce fait tel un membre d'un fichier rien en vous empêche de monter une moulinette pour convertir si besoin est et profiter de l'apport que propose IPOWER , ce n'est que du texte qui est compilé...

J'ai pratiqué des conversions sur des sources IBM3.8 3.12 3.15 34 36 38 Systemi (AS400) IPOWER (OS400) voir des sources en carte et remis sur membre fichier source. j'ai eu aussi des propositions pour convertir des 360 vars AS400.

Ne pas oublier que l'on s'adresse à des applications de gestion

http://www.ombrebleu.com/wxsrc/src/ section ADMOPS idem produit rational d'IBM, mais en mode texte. Très performant pour celui qui connait son travail modifiable à volonté. j'ai fait cela en 1995 les premiers jets... de l'analyse de texte et de la reconfiguration, c'est le b a ba de la maintenance... le produit est fait à partir de l'étude d'un produit IBM ADM advanced manager de projet sources n'étant plus distribué par IBM je me suis vu le réécrire, à l'époque le produit rational était loin d'être aussi abouti.



https://www.ibm.com/fr-fr/it-infrastructure/power


lien donnant un aperçu du Cobol-ile
https://www.volubis.fr/news/liens/AF...R10TXT/ILE.htm


https://www.ibm.com/docs/en/i/7.3?to...uage-reference

https://www.ibm.com/docs/en/i/7.2?to...grammers-guide

tout ça nécessite une connaissance du Cobol. D'autre part il est exclu sur l'IPOWER d'utiliser les routines assembleur du 360/370

mais le Fortran il est possible de l'implémenter sur un IPOWER

autre possibilité exemple :

https://conversion-migration.com/con..._migration.php


https://conversion-migration.com/con...LEUR_COBOL.php

https://www.ibm.com/docs/fr/rpp/9.5....g-pacbase-data
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
un peu d'ironie...

J'aurai bien continué avec des ordres ayant une relation avec la gestion puisque c'est principalement sa fonction.

move Movel add sub mult div reste etc.... le read write delete update ( 90% des instructions) bref beaucoup de bla bla contre la gestion
le forms est depuis longtemps en Cobol mis par ds dds ---> DSPF display file qui sont des objets qui gèrent la saisie et affichage
donc la migration avec un peu d'huile de coude est faisable
vous seriez surpris de la simplicité mis a disponibilité que non pas encore aujourd'hui nos langages sur PC par exemple les subroutines les call interactif tel qu'ils sont mis à disposition chez IBM , oh bien-sur j'en ai fait en Pc, mais quelle galère et pas aussi fructueux et je doute que cela soit vraiment employé aux vues de ce que je peux lire y compris sur développer.com ( exemple de source et études de cas) car cela fait appel à du fondamental même dans les livres approprier qui parle du cœur de Linux on aborde pratiquement pas ce sujet. Alors vous me direz le thread pour le multi-tâche ben non sur mainframe c'est beaucoup plus.....

[JPLAROCHE]

Je n'ai pas d'attrait particulier pour le Java, mais:
- les outils sont disponibles (documentation, testing, analyse de code), maintenus et continuent d’évoluer
- le langage est utilise par une grosse communauté (c'est le moins qu'on puisse dire ^^)
- le langage continue d’évoluer (dernière version en date d’âpres wikipedia: septembre 2021 et je présume que Java 16 n'est pas apparu il y a 7 ans parce qu'il me semble qu'a l’époque j'ai du utiliser Java 6 ou 7)
- il dispose du minimum vital pour un langage de programmation digne de ce nom (je veux dire, allocation dynamique, et récursivité sont possible, je dis pas que c'est forcement a utiliser mais des fois c'est quand même bien pratique hein).
- vu la relative simplité du COBOL, il semblerait possible d’écrire un transpileur vers un autre langage

effectivement le Cobol-ILE comporte la notion Objet, pointeur, récursivité... avec une réactivité bien supérieur à Java, et approprié dans le domaine de la gestion, personnellement je préfère le RPG-ILE mais le Cobol a ses avantages si il est bien structuré.

[frfancha]

Oui le mainframe coûte un bras et même les deux...
La solution que nous avons appliquée avec grand succès :
1) migrer tout vers AS400 (oui ça s'appelle plus AS400 je sais)
2) réécriture progressive de tous les programmes de gestion type mainframe par des procédures SQL (pur procédure DB2 SQL, pas COBOL !) => Temps d'exécution divisé par 10 (basé sur notre cas qui n'est qu'un exemple mais qui est réel)
3) une fois qu'on a plus que du SQL, plus besoin d'AS400, migration vers SQL Server sur Intel. De nouveau, notre cas : temps d'exécution divisé par 100 ! Et coût divisé par 100 par rapport au mainframe d'origine.

Raisons du succès : la possibilité de migration progressive et testée facilement en parallèle grâce à l'AS400 qui supporte l'ancien monde tout autant que le SQL moderne.
Avoir toute la logique gestion en SQL vous libére pour le futur : SQL Server aujourd'hui, Postgresql ou Oracle demain s'il fallait (mais on est content de SQL Server)

[chaton-garrou]

Tout d'abord merci @TotoParis d'avoir taper ce pavé à ma place... J'ai perdu le courage en lisant certains commentaires.

En revanche, je vais compléter un peu.

Premièrement, on parle d'Amazon, qui certes est une bonne entreprise, mais les serveurs font défaut ces derniers temps.

Deuxièmement, nous avons de plus en plus de devs en France qui ne connaissent pas TSO et font du cobol... Comment?
RDZ est inclus dans les derniers packs IBM lors de la location d'un mainframe, libre à chaque DSI de l'utiliser ou non.
Petit complément d'infos, RDZ c'est juste l'IDE Eclipse avec une surcouche mainframe qui peut inclure les outils dont TotoParis parle.

Troisièmement, on parle de java, qui voit son image se dégrader, entre la mise à jour de leurs conditions d'utilisation les 7 dernières années et la faille la plus populaire de 2021. Je pense que certaines entreprises vont un peu freiner la machine.

La problématique aujourd'hui, c'est le manque de coboliste, ça n'attire pas les jeunes.
Je suis apte à le comprendre quand on vois qu'en sortie du cursus scolaire, on leurs apprends du cobol 1.0 qui est immonde avec des préjugés sortis de je ne sais où.
A ça s'ajoute les frais de location/entretien du mainframe auquel s'ajoute le prix des licences.

La vérité étant que nous n'avons, à l'heure actuelle, pas de systèmes plus performants/sécurisés pour des batchs importants.
Niveau sécurité, nous avons RACF qui fait de l'autorisation de connexion, autorisation d'action. C'est imbuvable, mais c'est aussi sa force.
Pour le coté performance, j'arrête tout de suite les idées reçues, je parle de traitement de plusieurs millions de données avec calculs, mise à jours, etc... à faire en quelques secondes.
Les banques et assurances utilisent énormément cette technologie, ce n'est pas pour rien, et la migration d'un SI ça prends du temps et de l'argent.

Depuis combien de temps entendons nous "le cobol est mort"?
Oui, un jour il le sera, non ça ne sera pas java qui le remplacera. (autran avant que tu ne me gronde là dessus, je parle de manière générale, pas pour des petits SI)
Le temps de migrer, étudier les règles métiers oubliées et tout le travail que ça peut engendrer en parallèle, je serais à la retraite

Une dernière info pour le plaisir Amazon a quelques années de retard sur le sujet
Certains services existent pour aider à migrer de cobol vers les services de cloud (en France), avec des garanties performances fiables,
mais ça ne touche pas tout un SI important.
On ne migre pas un ensemble métier lourd sans prévenir le client que ça sera risqué, possiblement plus long en traitement...

[thamn]

Il faudrait changer de référence que ce pitoyable Wikipedia.
Lire ceci par exemple : https://www.ibm.com/support/pages/en...tation-library (c'est juste au hasard !)


IBM entreprise COBOl : 2019.


Ah ben sûr que oui, même si c'est pas forcément ancien. Quant à son utilité...


Ah que si même si nativement c'est récent, on pouvait utiliser depuis longtemps les service FREEMAIN et GETMAIN de LANGUAGE ENVIRONMENT : encore faillait-il lire la documentation IBM, démarche rarement suivie, que ce soit par des jeunots à la grande gueule, ou des plus anciens...


Ah elle est bien bonne celle-là. J'ai jamais lu plus ridicule.


En effet, un peu trop. Une expression comme "TOTAL = QUANTITE * PRIX" dans n'importe quel langage, peut s'écrire :
"COMPUTE TOTAL = QUANTITE * PRIX" ou MULTIPLY QUANTITE BY PRIX GIVING TOTAL" : en effet, c'est lourd à écrire.


Ah ben faudrait un peu vérifier soi-même ou demander à des personnes qui en savent plus que vous.


Le compilateur IBM est l'un des meilleurs au monde. Son code gère des adressages sur 64 bits, avec une franche et massive évolution du jeu d'instruction assembleur.


Pas pire qu'en C ou en Java. Sans outillage, comme XPEDITER, c'est en effet difficile, mais pas pire que faire du Python dans on EDI favori.


Les outils sont en format terminal à la mode TSO : c'est une interface texte en effet. Sinon XPEDITER, que je connais très bien, est facile d'accès, et très puissant.


C'est un peu logique : les architectures technique sont fort différentes.


Formatage : en effet, ça manque.
Génération de documentation : idem.
Analyse de code : non, il y a plein d'outils, comme Code Coverage chez Microfocus, Compuware's Xpediter/Code Coverage, et sans doute d'autres.


Le système Z/OS est l'un des plus sécurisé qui soit, sinon le plus sécurisé au monde. Aucune plateforme UNIX ou de cette famille ne peut le prétendre (comme la faille SSH l'a montré il y a quelques temps), ou alors au prix d'une armada de dispositifs logiciels et matériels des plus hallucinant (et merci la maintenance de ce "machin" alors).
Quant à Java, la dernière faille avec LOG4J est tout simplement hallucinante.


C'est pourtant simple : à une certaine époque, il n'y avait que cela : Mainframe et COBOL, pour les traitements sur de grandes quantités de données.
Unix et ses serveurs, c'était bon pour bricoler dans son garage. Quant aux RH, en effet, ils n'avaient pas il y a 40 ans la même formation que de nos jours.


Le paradigme Objet n'est pas forcément adapté à l'informatique de gestion pour faire des traitements batch. Depuis bien longtemps déjà l'essentiel du TP se fait via une interface web qui communique avec un Mainframe et du COBOL / DB2 derrière. Il manque juste la possibilité de définir des fonctions (autrement que sous forme de sous-programmes) : ça existe depuis si longtemps dans des langages qui ne sont même plus en vogue, que cela en est frustrant.

La source de Wikipedia a propos de la date de dernière version de COBOL est https://www.iso.org/standard/51416.html et je ne doute pas que IBM continue de produire des nouvelles version de son compilateur mais ce n'est pas la même chose. On parle ici du langage, je veux dire que ce n'est pas IBM qui définit le standard COBOL, de la même façon que ce n'est pas Microsoft qui définit le standard du C++, bien que Microsoft implémente un compilateur C++..
Si vous pensez avoir des informations plus fraiches n’hésitez donc pas a proposer vos changements a Wikipédia, mais je ne pense pas qu'il soit acceptable de dire que le COBOL change quand IBM décide d'ajouter quelque chose a son compilateur.

Log4J n'est pas Java, ce qu’implémente Log4J est probablement possible dans d'autre langage, ce n'est pas le langage Java qui apporte la vulnérabilité.
De même que si je commence a chercher un peu sur la récursivité et le COBOL, je trouve rapidement non COBOL ne supporterait pas la récursivité, mais si vous avez des précision (qui ne concerne pas exclusivement le compilateur de papa IBM). La commande PERFORM ne peut pas être utilisé récursivement, d’âpres ce que j'ai pu glaner, non COBOL ne supporte pas la récursivité. Et pour le coup, la documentation d'IBM l'indique elle aussi:

A PERFORM statement must not cause itself to be executed. A recursive PERFORM statement can cause unpredictable results.

A propos de Z/OS, quel rapport avec COBOL? Ce n'est pas parce que Z/OS est selon vous celui qui a la plus grosse (parce que vous n’étayez pas vraiment non plus) que COBOL en devient un langage sécurisé, Z/OS d’après la documentation d'IBM permet de développer avec d'autre langages, comme le C++.

Plus généralement, par comparaison il existe de nouveau langages, comme par exemple, Rust, qui se passe très bien du paradigme objet (que je n’apprécie personnellement pas particulièrement pour plusieurs raisons mais j'ai du l'utiliser pour arriver a ces raisons), et qui en terme de tooling, d’accès, de documentation, de standardisation, de sécurité, de portabilité, semble être ni plus ni moins qu'avoir... 50 ans d'avance sur le COBOL, et... c'est bien normal pour un langage né 50 ans plus tard.
Bref on sait bien que si ce truc est encore utilisé aujourd'hui c'est pas pour ses vertus..

Pour finir, je serai très content d'entendre des avis "éclairés", c'est a dire des arguments fondés, des retours d’expériences, et pas simplement quelque sophismes
Vous attaquez bien fort pour quelqu'un qui semble confondre un peu tout (COBOL != IBM, Java != Log4J) Et j'utilise le conditionnel pour indiquer que justement, je n'ai pas forcement pris le temps de devenir expert en COBOL plutôt que d'essayer de faire croire que je sais. Ce qui est encore pire, c'est que quand je creuse, il semblerait bien que vous vous trompiez sur de nombreux point.

[JPLAROCHE]

La source de Wikipedia a propos de la date de dernière version de COBOL est https://www.iso.org/standard/51416.html et je ne doute pas que IBM continue de produire des nouvelles version de son compilateur mais ce n'est pas la même chose. On parle ici du langage, je veux dire que ce n'est pas IBM qui définit le standard COBOL, de la même façon que ce n'est pas Microsoft qui définit le standard du C++, bien que Microsoft implémente un compilateur C++..
Si vous pensez avoir des informations plus fraiches n’hésitez donc pas a proposer vos changements a Wikipédia, mais je ne pense pas qu'il soit acceptable de dire que le COBOL change quand IBM décide d'ajouter quelque chose a son compilateur.

Log4J n'est pas Java, ce qu’implémente Log4J est probablement possible dans d'autre langage, ce n'est pas le langage Java qui apporte la vulnérabilité.
De même que si je commence a chercher un peu sur la récursivité et le COBOL, je trouve rapidement non COBOL ne supporterait pas la récursivité, mais si vous avez des précision (qui ne concerne pas exclusivement le compilateur de papa IBM). La commande PERFORM ne peut pas être utilisé récursivement, d’âpres ce que j'ai pu glaner, non COBOL ne supporte pas la récursivité. Et pour le coup, la documentation d'IBM l'indique elle aussi:


A propos de Z/OS, quel rapport avec COBOL? Ce n'est pas parce que Z/OS est selon vous celui qui a la plus grosse (parce que vous n’étayez pas vraiment non plus) que COBOL en devient un langage sécurisé, Z/OS d’après la documentation d'IBM permet de développer avec d'autre langages, comme le C++.

Plus généralement, par comparaison il existe de nouveau langages, comme par exemple, Rust, qui se passe très bien du paradigme objet (que je n’apprécie personnellement pas particulièrement pour plusieurs raisons mais j'ai du l'utiliser pour arriver a ces raisons), et qui en terme de tooling, d’accès, de documentation, de standardisation, de sécurité, de portabilité, semble être ni plus ni moins qu'avoir... 50 ans d'avance sur le COBOL, et... c'est bien normal pour un langage né 50 ans plus tard.
Bref on sait bien que si ce truc est encore utilisé aujourd'hui c'est pas pour ses vertus..

Pour finir, je serai très content d'entendre des avis "éclairés", c'est a dire des arguments fondés, des retours d’expériences, et pas simplement quelque sophismes
Vous attaquez bien fort pour quelqu'un qui semble confondre un peu tout (COBOL != IBM, Java != Log4J) Et j'utilise le conditionnel pour indiquer que justement, je n'ai pas forcement pris le temps de devenir expert en COBOL plutôt que d'essayer de faire croire que je sais. Ce qui est encore pire, c'est que quand je creuse, il semblerait bien que vous vous trompiez sur de nombreux point.

Cobol version 6 IBM update le 2021-10-29

Vous voulez avoir raison tan pis pour vous je pense que c'est tout un monde le cobol IBM sur des très grosses bases de données et essentiellement pour de la gestion, je vais quand même pas vous fournir des programmes pour vous prouver ce que je dis. La récursivité en COBOL existe vous n'avez pas lue la documentation... sinon allez aux cours chez IBM.
Maintenant utiliser le Cobol opensource ne traitant même pas UTF8 sur PC à part pour la culture je n'en vois pas l'utilité. Il y a bien un compilateur propriétaire sur PC qui propose quelque chose de plus performant et qui travaille en UTF8 , mais on est loin du monde IBM.

dans la proposition c'est bien de convertir le cobol des grosses machine IBM 360 370, etc. vers du Java.
rappel : AWS veut-il tuer les mainframes ? Le fournisseur de services de cloud computing veut remplacer les mainframes par des serveurs à grande échelle et COBOL par Java

j'ai travaillé sur des 360/170 pour être plus précis, j'ai connu les bacs à cartes que l'on lisait et mettait sur bandes ... j'ai connu les cartes avec les fiches et le crayon à mine alu pour corriger au lieu de tout se retaper.... chez "sommer-alibert" 1976...79" ile de la jate Neuilly ,
j'ai vue les écrans arrivés ils coutaient une fortune. L'interactif à vraiment démarrer vers 1980 en France d'ailleurs les machines IBM34 était encore plus performante, car conçu pour l'interactif, etc. le PC pas encore présent, en 1985 mémoire central en MO la France a innové et a fait le premier pc ou tout était cartes ça m'a couté une fortune et une grosse engueulade à la maison

j'ai effectivement peu d'expérience ayant commencé en 1976 et fini ma carrière sans discontinuité en 2016(retraite) puis participant à des développements opensource PC et actif encore actuellement. C/C++ NIM ...

j'ai l'impression que l'on confond !!!!!
Un mainFrame n'est pas un server type PC , déjà en 1984 avec Alfa Romeo on utilisait des mainframes et communiquait par satellite et d'autre mode...(pour avoir été sollicité)
en 1985 j'ai démarré la première communication internet avec le TO7 / IBM38 en France.
Participé à l'élaboration de cours avec IBM , tête de pont pour l'Europe afin de valider les versions et si besoin les patcher, relation directe avec IBM Rochester
j'ai travaillé sur des IPOWER avec la possibilité d'avoir 5000 connexions interactives temps de réponse 3 nanoseconde hors transport, et en intranet aucune latence. Avec plus de 100 jobs batch actifs et pas de temps mort.
1984 et plus Communication inter-ordinateur (mainframe) en temps réel.avec DDM

pour ne citer que mon peu savoir sans parler du reste et ma confusion à votre dire.

Pour finir, je serai très content d'entendre des avis "éclairés", c'est a dire des arguments fondés, des retours d’expériences, et pas simplement quelque sophismes

qui enfin de compte montre votre ignorance. Je ne me permets même pas de vous mettre un pouce vers le bas


Extrait doc IBM puisque vous n'avez pas pris le temps de lire les liens et d'entre voir autre chose que Wikipédia qui parfois délire complètement (je paye et contribue à Wikipédia). Si vous allez visiter sur RPG Wikipédia est très loin de la réalité et c'est encore pire pour le Cobol.
clause Récursive:
La clause RECURSIVE est une clause optionnelle qui autorise les COBOL programmes être ré-entré récursivement. Cette clause précise que le programme et tout programme qu'il contient sont récursifs. ILE COBOL permet le RECURSIF clause dans un programme imbriqué. De plus, les programmes récursifs pourront contenir un sous-programme imbriqué. Program-name-1 peut être ré-entré récursivement pendant qu'un l'invocation précédente est toujours active si la clause RECURSIVE est spécifiée. Un programme actif ne peut pas être ressaisi récursivement si la clause RECURSIVE n'est pas spécifié.
La section Working-Storage d'un programme récursif définit le stockage qui est alloué statiquement et initialisé à la première entrée d'un programme, et est disponible dans le dernier état utilisé pour n'importe lequel des appels récursifs. la Section de stockage local d'un programme récursif (ainsi que d'un programme non récursif) définit le stockage qui est automatiquement alloué, initialisé et désalloué sur une base par appel.
Connecteurs de fichiers internes correspondant aux FD dans la section Fichier d'un programme récursif sont alloués statiquement. L'état des connecteurs de fichiers internes fait partie du dernier état utilisé d'un programme qui persiste à travers les appels. ........

Z/os
petit exemple source:
https://www.ibm.com/docs/en/cobol-zo...ample-sections

pour plus de renseignement d'application de la récursivité :
https://www.ibm.com/docs/en/cobol-zo...m-id-paragraph


Quant à ceux qui pense que le Cobol est dépassé en disant que le mode IHM n'est plus d'actualité, il ferait mieux de lire pour voir l'étendu et jusqu'où vas l'IHM. Car même sur le pc le mode IHM est de mise dans 100% des applications interactives
https://fr.wikipedia.org/wiki/Intera..._homme-machine

Quant aux réponses comment , je vous répète que les membres sources ( physique multi-membre) c'est du texte, il est facile de faire des moulinettes et convertir en COBOL-ILE sans parler des programmes de conversion mise à disposition par diverses sociétés entre autre IBM. C'est une étude pas un truc avec lequel on appuie sur un bouton et oups. Le gain généralement on ne perd pas la connaissance , la rapidité , le métier.
Combien de personne que j'ai formé sortant d'université ... dans le domaine de la gestion on dirait que l'université oups ne forme que des scientifiques ????? bref beaucoup d'entreprise forme leurs employés. Après oui ce n'est pas un informaticien de jeu ou de site web, mais sur des milliards de données regarder les Assurances les Banques les très grosses entreprises Dassault Renault Peugeot mais les PME aussi pour y avoir travaillé ex: des centaines de millions d'étiquettes avec traçabilité totale par mois.

c'est pareil pour DB2 IBM mainframe et UDB plus communément appeler "DB2 pour pc", c'est comme comparer un 1400 ZZR Full 220 chv Kawazaki et un solex

[JPLAROCHE]

Non il ne s'agit pas d'un Troll mais de projets très sérieux déjà réalisés dans le monde réel.

Les sociétés de conseil qui proposent cette migration sont des players réputés (Cap Gemini - Atos - KPMG - Accenture). Et ils argumentent leurs proposition avec des éléments très tangibles sur 4 axes :

• Performances
• Coût
• Planning
• UX

En particulier : Les couts de redéveloppement sont largement compensés par le gains d'exploitation des serveurs d'application JEE en mode SaaS ou PaaS, versus le TCO colossal des MainFrames.
Bien entendu, on parle de projets à étaler sur des plannings à la maille annuelle et non des projets menés en quelques mois. Mais au final, l'utilisateur comme le client seront gagnant puisque l'ergonomie web sera toujours préférable aux IHM proposées dans le monde COBOL et que l'on pourra passer sur un mode de développement des services plus proche des métiers.

je comprends bien ce que tu veux dire pour avoir plusieurs fois été confronté à ce problème.

Alors ce n'est que mon expérience, on se retrouve pied et main lier avec les produits proposé, tu devrais te rencarder sur les modes IHM actuel usité par le Cobol-ILE j'ai mis un lien dans la réponse avant. du 3270 au html et plus.

Bien souvent la machine n'arrive pas à la cheville d'un mainframe nouvelle génération les couts ont fortement diminuer, la multiplication des serveurs à un cout non négligeable et le personnel en plus qui n'est pas toujours sur le marché (homme réseau), une équipe bien rodée et un projet (énorme) bien défini peu faire des étincelles,
en l'an 2001 avec la bascule € tout en gardant le franc surtout pour le départ, car aucune personne ne pouvait dire cela palpable ... nous n'avons eu que 3cts d'écarts sur des 100 millions d'écritures comptables après contrôle d'impôts, nous avons passé 6 mois à chercher et allez voir les faiseurs de miracles , pour tout simplement utiliser les fonctions system mis à notre disposition qui est arrivé à point, alors oui il y a eu des modifications à des carrefours bien précis et notre solution a été signaler dans le monde Ibm du moins en France .

Mais je comprends quand les sociétés ont voulu se passer de leurs services informatique et ne conserver qu'un bidouilleur ça devient difficile de convertir.
Surtout ne prends pas ça comme une critique dure, mais comme un constat.

maintenant par expérience , je ne citerais pas la chaine de magasin, mais un test : les personnes ont eu des programmes type web et toutes sans exception ont préférées le type 3270/5250 tant le system était trop compliqué pour une saisie rapide et très concise et lente, tu pourras toujours me dire que le projet était mal fait, mais moi je te dis non pour l'avoir vu. Ne pas oublier que pour les mainframes c'est la data qui pèse le plus.
les camembères et autre pas besoin de cobol etc...

[thamn]

Vous voulez avoir raison tan pis pour vous je pense que c'est tout un monde le cobol IBM sur des très grosses bases de données et essentiellement pour de la gestion, je vais quand même pas vous fournir des programmes pour vous prouver ce que je dis. La récursivité en COBOL existe vous n'avez pas lue la documentation... sinon allez aux cours chez IBM.
Maintenant utiliser le Cobol opensource ne traitant même pas UTF8 sur PC à part pour la culture je n'en vois pas l'utilité. Il y a bien un compilateur propriétaire sur PC qui propose quelque chose de plus performant et qui travaille en UTF8 , mais on est loin du monde IBM.

dans la proposition c'est bien de convertir le cobol des grosses machine IBM 360 370, etc. vers du Java.
rappel : AWS veut-il tuer les mainframes ? Le fournisseur de services de cloud computing veut remplacer les mainframes par des serveurs à grande échelle et COBOL par Java

j'ai travaillé sur des 360/170 pour être plus précis, j'ai connu les bacs à cartes que l'on lisait et mettait sur bandes ... j'ai connu les cartes avec les fiches et le crayon à mine alu pour corriger au lieu de tout se retaper.... chez "sommer-alibert" 1976...79" ile de la jate Neuilly ,
j'ai vue les écrans arrivés ils coutaient une fortune. L'interactif à vraiment démarrer vers 1980 en France d'ailleurs les machines IBM34 était encore plus performante, car conçu pour l'interactif, etc. le PC pas encore présent, en 1985 mémoire central en MO la France a innové et a fait le premier pc ou tout était cartes ça m'a couté une fortune et une grosse engueulade à la maison

j'ai effectivement peu d'expérience ayant commencé en 1976 et fini ma carrière sans discontinuité en 2016(retraite) puis participant à des développements opensource PC et actif encore actuellement. C/C++ NIM ...

j'ai l'impression que l'on confond !!!!!
Un mainFrame n'est pas un server type PC , déjà en 1984 avec Alfa Romeo on utilisait des mainframes et communiquait par satellite et d'autre mode...(pour avoir été sollicité)
en 1985 j'ai démarré la première communication internet avec le TO7 / IBM38 en France.
Participé à l'élaboration de cours avec IBM , tête de pont pour l'Europe afin de valider les versions et si besoin les patcher, relation directe avec IBM Rochester
j'ai travaillé sur des IPOWER avec la possibilité d'avoir 5000 connexions interactives temps de réponse 3 nanoseconde hors transport, et en intranet aucune latence. Avec plus de 100 jobs batch actifs et pas de temps mort.
1984 et plus Communication inter-ordinateur (mainframe) en temps réel.avec DDM

pour ne citer que mon peu savoir sans parler du reste et ma confusion à votre dire.

qui enfin de compte montre votre ignorance. Je ne me permets même pas de vous mettre un pouce vers le bas


Extrait doc IBM puisque vous n'avez pas pris le temps de lire les liens et d'entre voir autre chose que Wikipédia qui parfois délire complètement (je paye et contribue à Wikipédia). Si vous allez visiter sur RPG Wikipédia est très loin de la réalité et c'est encore pire pour le Cobol.
clause Récursive:
La clause RECURSIVE est une clause optionnelle qui autorise les COBOL programmes être ré-entré récursivement. Cette clause précise que le programme et tout programme qu'il contient sont récursifs. ILE COBOL permet le RECURSIF clause dans un programme imbriqué. De plus, les programmes récursifs pourront contenir un sous-programme imbriqué. Program-name-1 peut être ré-entré récursivement pendant qu'un l'invocation précédente est toujours active si la clause RECURSIVE est spécifiée. Un programme actif ne peut pas être ressaisi récursivement si la clause RECURSIVE n'est pas spécifié.
La section Working-Storage d'un programme récursif définit le stockage qui est alloué statiquement et initialisé à la première entrée d'un programme, et est disponible dans le dernier état utilisé pour n'importe lequel des appels récursifs. la Section de stockage local d'un programme récursif (ainsi que d'un programme non récursif) définit le stockage qui est automatiquement alloué, initialisé et désalloué sur une base par appel.
Connecteurs de fichiers internes correspondant aux FD dans la section Fichier d'un programme récursif sont alloués statiquement. L'état des connecteurs de fichiers internes fait partie du dernier état utilisé d'un programme qui persiste à travers les appels. ........

petit exemple source:
https://www.ibm.com/docs/en/cobol-zo...ample-sections

pour plus de renseignement d'application de la récursivité :
https://www.ibm.com/docs/en/cobol-zo...m-id-paragraph


Quant à ceux qui pense que le Cobol est dépassé en disant que le mode IHM n'est plus d'actualité, il ferait mieux de lire pour voir l'étendu et jusqu'où vas l'IHM. Car même sur le pc le mode IHM est de mise dans 100% des applications interactives
https://fr.wikipedia.org/wiki/Intera..._homme-machine

Quant aux réponses comment , je vous répète que les membres sources ( physique multi-membre) c'est du texte, il est facile de faire des moulinettes et convertir en COBOL-ILE sans parler des programmes de conversion mise à disposition par diverses sociétés entre autre IBM. C'est une étude pas un truc avec lequel on appuie sur un bouton et oups. Le gain généralement on ne perd pas la connaissance , la rapidité , le métier.
Combien de personne que j'ai formé sortant d'université ... dans le domaine de la gestion on dirait que l'université oups ne forme que des scientifiques ????? bref beaucoup d'entreprise forme leurs employés. Après oui ce n'est informaticien de jeu ou de site web, mais sur des milliards de données regarder les Assurances les Banques les très grosses entreprises Dassault Renault Peugeot mais les PME aussi pour y avoir travaillé ex: des centaines de millions d'étiquettes avec traçabilité totale par mois.

c'est pareil pour DB2 IBM mainframe et UDB plus communément appeler "DB2 pour pc", c'est comme comparer un 1400 ZZR Full 220 chv Kawazaki et un solex

Et, tout ça pour dire quoi au final? Tout le monde est stupide de vouloir aller de l'avant, en se débarrassant des outils les plus désués?
Personnellement j'ai rien a prouver, le COBOL est un langage de 50 ans, il a l'air au moins aussi nul qu'un langage conçu il y a 50 ans pourrait l’être.

Enfin je demande "pour dire quoi?" mais c'est purement rhétorique, je vois bien que c'est difficile de se rendre compte que le monde ne s'est pas arrêté sur le peu que vous avez connu..

Aussi, c'est pas parce que vous en avez fait pendant x années que ça rend ce langage de dinosaure scintillant de qualités. Surtout si on le compare au autres langages, que cela vous plaise ou pas. Au fond, la meilleure preuve de sa désuétude c'est l'engouement pour s'en débarrasser, si ça peut permettre de débarrasser le monde professionnel des quelques réactionnaires idéalistes qui pensent encore que leur techno chérie qu'il on connue y'a 40 ans ne sera jamais dépassé c'est bon débarra.

Sinon, ça a pas été trop dur d'abandonner les cartes perforées? Ça vous manque pas trop ça va?

[JPLAROCHE]

Et, tout ça pour dire quoi au final? Tout le monde est stupide de vouloir aller de l'avant, en se débarrassant des outils les plus désués?
Personnellement j'ai rien a prouver, le COBOL est un langage de 50 ans, il a l'air au moins aussi nul qu'un langage conçu il y a 50 ans pourrait l’être.

Enfin je demande "pour dire quoi?" mais c'est purement rhétorique, je vois bien que c'est difficile de se rendre compte que le monde ne s'est pas arrêté sur le peu que vous avez connu..

Aussi, c'est pas parce que vous en avez fait pendant x années que ça rend ce langage de dinosaure scintillant de qualités. Surtout si on le compare au autres langages, que cela vous plaise ou pas. Au fond, la meilleure preuve de sa désuétude c'est l'engouement pour s'en débarrasser, si ça peut permettre de débarrasser le monde professionnel des quelques réactionnaires idéalistes qui pensent encore que leur techno chérie qu'il on connue y'a 40 ans ne sera jamais dépassé c'est bon débarra.

Sinon, ça a pas été trop dur d'abandonner les cartes perforées? Ça vous manque pas trop ça va?

Vous confondez tout, migration et refaire tout dans un autre langage, pour vous la migration, c'est jeter le bébé et l'eau du bain en même temps.

[chaton-garrou]

Merci pour la précision de LOG4J, effectivement j'ai été mal informé sur cette faille. (une confusion ne détruit pas le reste des informations)

On parle de Z/OS car le but est de quitter le mainframe d'après ce que laisse supposer l'article avec son titre accrocheur.
En réalité, les offres de migrations ne concerne qu'une partie du SI pour alléger la charge processeur qui est la base de la facturation.
Donc oui les avantages des mainframes est à prendre en compte surtout dans le contexte actuel où les piratages se multiplient.
Concernant la récursivité, je l'ai utilisé il y a deux semaines, j'ai pris un petit warning mais ça fonctionne.
Lors de mes derniers essais (il y a 4 ans en TELON), j'ai remarqué que sur ma machine de travaille, passer le 5em niveau de récursivité d'un paragraphe, le mainframe se perds (mais qui utilise encore le TELON ).
Si on veux une véritable récursivité, il faut créer un programme récursif pas un paragraphe...
en gros je n'en ai pas l'utilité dans mon domaine mais je laisse les curieux voir ça avec big blue: https://www.ibm.com/docs/en/i/7.2?to...ecursive-calls

On ne passe pas non plus une moulinette magique qui convertit le cobol,
si on voit les programmes des années 90...j'ai mal aux yeux et si tu génère ça, ce sera dégueulasse. (je parle en un langage autre, ayant vu des programmes avec + de 200 goto)
Ca demande une refonte avant moulinette + contrôle en sortie.

Mon précédent poste était axé sur "Non on ne va pas stopper tout du jour au lendemain car il n'y aurais pas de gains significatifs",
après je ne suis pas contre la conversion du cobol, je ne suis pas pour non plus...

Maintenant thamn si tu trouve nos informations trop déphasées, je t'invite à contacter l'entreprise la plus au fait des possibilités du cobol, des mainframes et qui fait de la migration aussi... Eh oui, IBM propose aussi de la migration en cloud
Il n'y a pas de match a qui sera le plus performant, le plus beau etc.
Tout les langages ont leurs points forts et leurs utilités, qu'il ai 50 ans n'est pas une faiblesse

[JPLAROCHE]

On ne passe pas non plus une moulinette magique qui convertit le cobol,
si on voit les programmes des années 90...j'ai mal aux yeux et si tu génère ça, ce sera dégueulasse. (je parle en un langage autre, ayant vu des programmes avec + de 200 goto)
Ca demande une refonte avant moulinette + contrôle en sortie.

bien-sur avec 200 goto mais il y a des aides à la refonte et restructuration du code proposé par IBM , mon but était seulement de dire et je l'ai dit après une étude que cela ce fait non sans mal, mais qu'il est possible de passer à du Cobol-ILE. Il n'est pas possible ici d'énumérer comment avec les cas et les façons dont cela a été écrit voir si il y a des routine assembleur ect... j'ai simplement dans mon 2eme poste montré avec des liens qu'IBM c'est penché dessus et qu'il y a des solutions.
un programme revu et corrigé fera peu de ligne supplémentaire comparé à C++ ou autre .

j'admets bien volontiers que certaines programmations sont écrites en dépit du bon sens et aurait dû être rejeté dès le départ. Ce qui n'arrange pas les choses Hélas. Mais en ayant pratiqué depuis de nombreuses années le C/C++ il y aurait aussi beaucoup à dire et certain expert dans développer.net non pas manqué de le dire et proposé des réponses. d'ou RUST ou NIM proposant une obligation de coding... par exemple, mais cela ne résout pas le problème du Cobol...
Pour ma part, je ne prenais pas cela comme une bataille que Cobol est meilleurs ou pires que les autres langages, mais que dans le monde IBM le Cobol-ILE est vraiment beaucoup plus performant ex display avec .dspf externe objet les sql intégrer crtcblsqlsrc etc... Ça apporte un grand coup de sabre dans la lecture du code. C'est un Cobol qui n'a rien à envier aux autres langages.

De toute façon, il faudra de l'huile de coude et un sérieux courage, après la motivation peux ce faire la monnaie ça existe , c'est un vrai chantier. Faire ça et être bien payé ce n'est pas si désagréable, il y a beaucoup de gents qui on peut à la fin du mois ...

une approche inétressante https://ego.developpez.com/uml/tutoriel/cobol/#LIV

[Escapetiger]

Beaucoup d'acteurs ont applaudi cette annonce et des critiques ont déclaré que AWS Mainframe Modernization pourrait être la réponse au problème des migrations de mainframes ridiculement complexes.

Pour finir, je serai très content d'entendre des avis "éclairés", c'est a dire des arguments fondés, des retours d’expériences, et pas simplement quelque sophismes

Pour la partie migration (à vous de voir si c'est ridiculement complexe) :

Migration Zos vers UNIX/LINUX

Abandon du ZOS pour les systèmes distribués


Pour la partie Cobol proprement dite :

À plus de 60 ans, le langage COBOL est encore utilisé par des États américains,
Les laissant face à un manque de programmeurs et des coûts de développement énormes

Le langage de programmation Cobol fête ses 60 ans,
Peut-il encore tenir longtemps face à la concurrence des nouveaux langages ?

Êtes-vous un développeur COBOL ? Si oui, il pourrait y avoir encore des opportunités pour vous
Dans le domaine de la finance


et des publications étaillées sur Cobol vs Java, notamment : Les banques restent fidèles à Cobol, plus performant que Java & Le Cobol n’est toujours pas mort du consultant en système d'information Claude Salzman (cf. https://rapportsalzman.blogspot.com/)

[Edit]
Le consultant Louis Naugès (cf. https://nauges.typepad.com/) :

• 85 % des transactions financières professionnelles sont réalisées en Cobol.
• 95% des opérations des distributeurs de billets sont gérés en Cobol.
• 5 milliards de nouvelles lignes de code Cobol sont développées chaque année. Oui, vous avez bien lu, on parle de «nouvelles» lignes de Cobol.

Source : Se libérer de ses Mainframe IBM, rapidement. Deuxième partie (2016)

[chaton-garrou]

Ah mais je suis d'accord avec toi JPLAROCHE, mais je ne connais pas le cobol ILE (mes clients ne l'utilisent pas),
en revanche j'ai déjà eu du cobol sous UNIX, ce qui était dans le cas de ce client là, une véritable horreur.

Du coté d'IBM, il y a quelques migrations effectuées avec succès via ce fameux programme, avec dans tout les cas des cobolistes pour confirmer ou corriger programme par programme.
La communication de Big Blue étant plus orienté entreprise, il est un peu moins facile d'en savoir plus en tant que simple dev et les règles de confidentialité ne permettent probablement pas de connaître tout les périmètres déjà migrer.

Ce qui me fait peur avec le cobol ILE c'est qu'il contient le mot cobol, ce qui a l'air de manquer de glamour auprès des plus jeunes...
Personnellement c'est un langage qui m'éclate et il est très complet pour la gestion,
qu'un dev avec 8 ans d'expérience en cobol peux réussir, même si il n'en connais que 10%.
Je pense notamment aux pointeurs, la première fois que je les ai vu j'ai été surpris que cobol gère ça.

Donc comme dit dans mon premier poste, nous rencontrons 2 problématiques, les ressources et le coût.
Je crains donc que le cobol ILE ne réponde pas à la première problématique d'attirer de nouvelles ressources.