Discussion :

[el_slapper]

les AS/400 sont des mainframe "light", généralement utilisés dans des structures plus petites, ce qui rend la migration vers autre chose possible. Il est possible qu'ils disparaissent à moyen terme.

Pour les énormes machines Z/OS qu'on trouve dans la plupart des grands comptes financiers(ainsi qu'à la FNAC et quelques autres), c'est différent. On a des existants absoluments massifs, et la plupart des projets de migration se terminent mal. Ce qui se passe, par contre, c'est que tout ce qui est loin du noyau comptable(à commencer par les interfaces utilisateurs) a déjà été remplaçé, et que les langages modernes, peu à peu, s'emparent des couches intérmédiaires.

Mais pour les couches basses, les immenses batchs comptables du noyau et des données connexes, le duo COBOL/Mainframe reste diablement efficace. J'en veut pour preuve ce projet ou on avait été mis en concurrence avec le JAVA, et ou notre estimation était moitié moindre(alors qu'on avait à gérer l'aller-retour depuis UNIX en plus, eux tournaient en natif), et ou on a quasiment tenu le tryptique delai-cout-qualité. Ou encore ce grand compte qui a mis 100M$ sur la table pour passer son SI de COBOL/ZOS à JAVA/UNIX et qui a fait demi-tour pour des raisons de performances.

Le truc, c'est que COBOL est le seul langage à ma connaissance à proposer en natif des formats de données numériques optimisées pour la comptabilité(suivi de très très loin par, ne rigolez pas, le VB6,avec son très limité format currency qui est mieux que rien). Tant que les nouveaux langages seront conçus par des geeks qui considèrent qu'un nombre de taille fixe à virgule fixe, c'est l'anathème absolu, alors le COBOL restera le meilleur dans cette niche là. Le jour ou le prochain Guido Van Rossum aura des bases comptables, alors oui on pourra remplacer le COBOL. Pas avant.

Bon, et puis nombre des défauts de COBOL sont aussi des qualités dans le monde bancaire. Notamment, son extrême rigidité sur la déclaration de variables fait que les fuites mémoires sont impossibles. Si on fait une erreur, le programme plante, mais ne va pas empêcher les autres de tourner. Son aspect repoussant pour les geeks fait que les gens qui bossent dessus auront moins des réflexes de contournement des règles. Ce qui allonge les temps de développement, mais sécurise aussi le banquier prudent avec l'argen de ses clients.

[sirthie]

Je rêve ! Personne n'a évoqué les secrets industriels ?

Est-ce que des entreprises comme Arianespace, Airbus, Dassault, etc. doivent tout mettre "dans le cloud" ? Perso, avec les piratages récents, j'hésiterais.

Certes, un mainframe connecté à internet peut tout aussi bien être piraté, mais ça, ça dépend (entre autres) des moyens de protection déployés par l'entreprise.

[FreeDev83]

En même temps, quand je vois le bordel sur certaines infras basées sur TSE, qui semble avoir le vent en poupe depuis quelques années, je me dis que ceux qui tournent toujours en Mainframe peuvent bien prendre leur temps de réfléchir à leur migration...

Je suis plutôt en faveur des solutions http auto-hébergées, mais visiblement il faudra du temps pour que ça devienne la norme ; au moins assez pour qu'une majorité de devs apprennent ce qu'est un container - au hasard...

Remarquez, pas plus tard qu'il y a deux semaines un dev tentait bien de me démontrer par A+B que le VBA était l'avenir du développement des logiciels de gestion... Il nous faudra peut-être quelques siècles, en fin de compte.

[Pyramidev]

Le truc, c'est que COBOL est le seul langage à ma connaissance à proposer en natif des formats de données numériques optimisées pour la comptabilité(suivi de très très loin par, ne rigolez pas, le VB6,avec son très limité format currency qui est mieux que rien). Tant que les nouveaux langages seront conçus par des geeks qui considèrent qu'un nombre de taille fixe à virgule fixe, c'est l'anathème absolu, alors le COBOL restera le meilleur dans cette niche là. Le jour ou le prochain Guido Van Rossum aura des bases comptables, alors oui on pourra remplacer le COBOL. Pas avant.

Pourquoi veux-tu absolument que ce soit en natif ?

Pour manipuler des nombres réels de taille fixe à virgule fixe, il n'y a pas besoin de les avoir en natif. Il suffit de coder une petite bibliothèque dans un langage qui supporte à la fois les entiers de taille fixe et la surcharge des opérateurs. Il en existe plusieurs, le plus connu étant C++.

Par exemple, le code C++ suivant affiche 3.95 dans la sortie standard :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
#include <cstdint>
#include <iostream>
 
//! Nombre de 32 bits précis au centième près qui supporte l'addition et la multiplication.
class Nb32BitsPrecisCentieme final {
private:
	int32_t m_centiemes;
	explicit constexpr Nb32BitsPrecisCentieme(int32_t centiemes) noexcept :
		m_centiemes{centiemes}
	{}
public:
	static constexpr Nb32BitsPrecisCentieme depuisCentiemes(int32_t centiemes) noexcept {
		return Nb32BitsPrecisCentieme{centiemes};
	}
	//! \warning Risque d'overflow ou d'underflow.
	static constexpr Nb32BitsPrecisCentieme depuisUnites(int32_t unites) {
		return Nb32BitsPrecisCentieme{unites * 100};
	}
	//! \warning Risque d'overflow ou d'underflow.
	constexpr Nb32BitsPrecisCentieme operator+(Nb32BitsPrecisCentieme autre) {
		return Nb32BitsPrecisCentieme{m_centiemes + autre.m_centiemes};
	}
	//! \warning Risque d'overflow ou d'underflow et risque de troncage.
	constexpr Nb32BitsPrecisCentieme operator*(Nb32BitsPrecisCentieme autre) {
		return Nb32BitsPrecisCentieme{m_centiemes * autre.m_centiemes / 100};
	}
	constexpr double convertirEnDouble() noexcept {
		return static_cast<double>(m_centiemes) / 100;
	}
};
 
int main()
{
	auto quaranteDeux = Nb32BitsPrecisCentieme::depuisUnites(42);
	auto unDixieme    = Nb32BitsPrecisCentieme::depuisCentiemes(10);
	auto moinsUnQuart = Nb32BitsPrecisCentieme::depuisCentiemes(-25);
	auto nombre       = quaranteDeux * unDixieme + moinsUnQuart;
	std::cout << nombre.convertirEnDouble();
	return 0;
}

Parmi les autres langages performants qui permettent de faire ce genre de choses, on a aussi Rust et D.

Bon, et puis nombre des défauts de COBOL sont aussi des qualités dans le monde bancaire. Notamment, son extrême rigidité sur la déclaration de variables fait que les fuites mémoires sont impossibles.

Pourrais-tu nous en dire plus ?
En langage C, il faut fixer des conventions pour déterminer qui est responsable de désallouer. En général, par défaut, c'est celui qui alloue qui doit désallouer. Malheureusement, beaucoup de développeurs n'ont pas ce niveau de rigueur.
En C++, il suffit de maîtriser le RAII pour que les fuites de mémoire soient quasiment impossibles. Malheureusement, beaucoup de développeurs C++ ne le maîtrisent pas.
En COBOL, qu'est-ce qui décourage les fuites de mémoire ?

Si on fait une erreur, le programme plante, mais ne va pas empêcher les autres de tourner.

Quelle est la différence avec les autres langages ?

Son aspect repoussant pour les geeks fait que les gens qui bossent dessus auront moins des réflexes de contournement des règles. Ce qui allonge les temps de développement, mais sécurise aussi le banquier prudent avec l'argent de ses clients.

Quelles règles ? Si tu parles des bonnes pratiques, je me rappelle que tu avais écrit que certains développeurs COBOL faisaient des copiés-collés au lieu de factoriser proprement le code.

[4sStylZ]

SAP ERP ne souffre-t-il pas des mêmes défauts que les systèmes pour mainframe?Un écosystème très à part, souffrant d'un héritage technique assez lourd, de peu de développeurs (de part le manque de formation et le fait que le dev SAP est peu sexy), une UX à la ramasse (même si il y a des possibilités de clients légers, d'interfaces web plus poussées). J'ai fait du dev ABAP sur SAP R/3 pour une boite et c'est franchement pas un bon souvenir.
Je ne remet pas en cause les capacités de SAP, mais sa façon de fonctionner très "vieux monde" qui lui colle peut être les même tares que le développement mainframe aujourd'hui.

Tu relève toute sorte de défauts qui sont tout à fait réels et maîtrisés par les boites qui migrent. L’un problème majeur de la boite pour qui j’ai bossé c’était :*
Le manque d’éditeur et de suivi qui étaient capable de leur fournir du service. Pour le coup, SAP a réussi à leur vendre une main d’œuvre concéquente.
L’avantage aussi de SAP c’est qu’ils sont au top en métier pour de la logistique. Ils ont une expérience de conseil et un outil taillé pour ça même si c’est une grosse galère à paramétrer.

Oui, c’est le vieux monde aussi, mais la DSI de cette boite avait bien tout benchmarké et résumé par « Il n’y a pas d’alternative à SAP pour notre projet »

j'ai bossé aussi longtemps sur AS/400 et je me souviens d'utilisateurs qui avaient choisi de passer d'un produit AS/400 vers du Client/Server Oracle car l'appli était très jolie avec des couleurs et des icônes partout...six mois plus tard, les utilisateurs regrettaient les écrans texte vert qui était réduits à leur plus simple expression, avec une saisie rapide et intuitive normalisée (F3 = Quitter, F4 = Liste, F5 = Actualiser, F7 = Page suivante, F8 = Page précédente...si je me souviens bien) alors que sous Windows ils passaient leur temps à prendre la souris pour cliquer sur un bouton, pour ouvrir ou fermer une boîte de dialogue

… Dans l'exemple de Paul Toth, rien n'empêchait les devs de la nouvelle application de conserver les raccourcis claviers.…

J’ai vécu la même chose avec des vendeurs chez Conforama qui saisissaient des commandes 10 fois moins vites haha.
@Benjani tu ne te rend pas comptes de la rapidité / du temps de réponse d’un émulateur de terminal sur un AS-400 comparé à n’importe quel client lourd / navigateur qui fait des requêtes par ex en HTTP.
Il ne s’agit pas simplement d’UI, de placement des boutons. Tu aurait beau les mettre aux mêmes endroits que rien ne serait aussi rapide et fluide. Ce serait comme filer un écran de téle 30 fps qui a du ghostering et une souris 50hz a un Pro-gamer qui a un écran 144hz et une souris 1000hz.
Les users experts sur émulateur sont capable de saisir des éléments et d’utiliser des touches de fonctions qui s’empileront de manière séquentielles avant même que les écrans des transactions n’apparaissent. Parfois, on n’a pas le temps de voir l’interface (qui est pourtant hyper légère) tellement l’usage de la saisie / des touches de fonctions et de raccourcis est rapide.

Plusieurs fois j’ai vu des émulateurs de terminal recodés pour tourner dans des navigateurs, pour interroger via internet et avoir une petite couche de css légère. C’était beaucoup plus lent.

[Paul TOTH]

Quelques petits trucs sur les environnements mainframe. Je ne suis pas une bible, je ne dev même plus mais j’ai bossé sur AS-400…

On ne code pas forcément en COBOL si on fait du Mainframe (Ou des mini-ordinateurs comme l’AS-400). Il y a des langages qui lui ressemblent comme RPG-IV ile qu’il ne faut pas oublier. De mon experience le COBOL*est peut être moins utilisé que le RPG. Au final ça ne change pas grand chose juste que de lire tout le temps COBOL sans jamais lire RPG j’ai l’impression que personne sait se représenter le mainframe. Moi même je ne sais pas de quoi parle l’article étant donné que tous les sujets ici je les ai constaté sans jamais avoir bossé dans le main-frame mais sur AS-400.
Pour generer du COBOL ou du RPG on ne code pas dans ces langages, on utilise parfois des langages de plus haut niveau, des AGL etc.
Pour apprendre les langages de bas niveaux il y a toujours des formations qui existent. Bien-sur ça attire moins de gens… mais ça file du boulot, c’est bien payé etc. Sur que c’est pas à la mode mais faut pas cracher dans la soupe :*On fait des trucs incroyable avec la puissance de ces machines.

Pour ce qui est du patrimoine applicatif il faut comprendre que les boites qui ont travaillés en mainframe le font depuis 30~40 ans et qu’il s’agit des banques, des assurances, de la logistiques. 99 des 100 plus grande entreprise française possède un AS-400.
Ces sociétés ont des patrimoines immenses. Un exemple :*l’un des groupes logistique pour lequel j’ai bossé possède un patrimoine de 12000 programmes interactifs (sans parler des batchs donc) pour son appli logistique. La migration envisagé a été validé et en 2014 ils parlaient d’une horizon 2027 pour passer chez SAP.
Ce genre de client ne « laisse pas » mourir leurs applicatifs car ils peuvent ce permettre ça.

J’ajouterai sur la partie IHM qu’on peut très bien mettre à profit la puissance du Mainframe pour faire des interfaces web hyper modernes. Pour la plupart des gens toute l’IHM des applis en COBOL sont des écrans verts sur noir qu’on exploite via un émulateur de terminal. Or il existe des produits qui permettent d’attaquer des serveurs main frame.
Donc l’argument du mainframe qui meurt à cause de l’IHM…

j'ai bossé aussi longtemps sur AS/400 et je me souviens d'utilisateurs qui avaient choisi de passer d'un produit AS/400 vers du Client/Server Oracle car l'appli était très jolie avec des couleurs et des icônes partout...six mois plus tard, les utilisateurs regrettaient les écrans texte vert qui était réduits à leur plus simple expression, avec une saisie rapide et intuitive normalisée (F3 = Quitter, F4 = Liste, F5 = Actualiser, F7 = Page suivante, F8 = Page précédente...si je me souviens bien) alors que sous Windows ils passaient leur temps à prendre la souris pour cliquer sur un bouton, pour ouvrir ou fermer une boîte de dialogue, une perte de temps énorme avec des écrans pas au standard Windows en plus...et la gestion des impressions c'est un autre monde sur AS/400 ... longue histoire.

[KEKE93]

Quand tu migres de l'AS400 à SAP R/3, il y a possibilité de garder la base de données sur AS400; c'est peu fréquent car la majorité des implémentations SAP R/3 se fait sur une base de données genre Oracle, SQL/server ou IBM DB mais ça se fait.
L'architecture de SAP R/3 est à trois niveaux:
- La base de données
- Le serveur d'applications SAP R/3
- le poste client front-end.
Comme quoi, tout n'est pas perdu; il reste les données mais il faudra configurer SAP R/3, refaire les programmes spécifiques, modifier les programmes standards par des user-exits, BADIS,etc... C'est tout un projet, long en temps et en argent!!

[e-ric]

j'ai bossé aussi longtemps sur AS/400 et je me souviens d'utilisateurs qui avaient choisi de passer d'un produit AS/400 vers du Client/Server Oracle car l'appli était très jolie avec des couleurs et des icônes partout...six mois plus tard, les utilisateurs regrettaient les écrans texte vert qui était réduits à leur plus simple expression, avec une saisie rapide et intuitive normalisée (F3 = Quitter, F4 = Liste, F5 = Actualiser, F7 = Page suivante, F8 = Page précédente...si je me souviens bien) alors que sous Windows ils passaient leur temps à prendre la souris pour cliquer sur un bouton, pour ouvrir ou fermer une boîte de dialogue, une perte de temps énorme avec des écrans pas au standard Windows en plus...et la gestion des impressions c'est un autre monde sur AS/400 ... longue histoire.

Ton expérience met en exergue deux choses :
- une application "moderne" n'est pas forcément meilleure qu'une ancienne application.
- l'être humain n'apprécie pas toujours le changement.

Perso, je n'ai pas trouvé mon expérience sur mainframe extrêmement enrichissante, techniquement ça vole à ras des pâquerettes, enfin la partie cobol, jcl, pour le reste je ne sais pas trop.

[benjani13]

les utilisateurs regrettaient les écrans texte vert qui était réduits à leur plus simple expression, avec une saisie rapide et intuitive normalisée (F3 = Quitter, F4 = Liste, F5 = Actualiser, F7 = Page suivante, F8 = Page précédente...si je me souviens bien) alors que sous Windows ils passaient leur temps à prendre la souris pour cliquer sur un bouton

Ton expérience met en exergue deux choses :
- une application "moderne" n'est pas forcément meilleure qu'une ancienne application.
- l'être humain n'apprécie pas toujours le changement.

L'humain n'apprécie pas le changement quand il est brutal, mal pensé, et uniquement conduit par une philosophie qu'on lui impose ("le tout souris c'est l'avenir", "le flat design c'est la mode", etc), ou tout simplement quand on change par ce que... il faut changer (mémoire des nombreux sites web dont le design a été complètement chamboulé du jour au lendemain, sans aucun apport de fonctionnalité et causant le désespoir des utilisateurs). Si le changement prend en compte l'utilisateur ça se passe plutôt bien. Dans l'exemple de Paul Toth, rien n'empêchait les devs de la nouvelle application de conserver les raccourcis claviers.

Convertir des millions de lignes, mettre en place et sécuriser de nouvelles infrastructures, former les développeurs qui vont affronter un changement important dans la façon de penser (cela va dans les deux sens, passer de technos actuelles à Cobol est une souffrance tellement c'est restrictif et primitif).

Comme tu le dis, il faut former les devs. Avec une bonne formation, quelque soit la techno ce n'est jamais une souffrance. Bon, c'est pas forcément intéressant si la techno est pas sexy, mais bon on t'a donné tous les outils pour bosser. C'est quand on te lâche sans formation que la souffrance née.

[Invité]

Quelques petits trucs sur les environnements mainframe. Je ne suis pas une bible, je ne dev même plus mais j’ai bossé sur AS-400…

On ne code pas forcément en COBOL si on fait du Mainframe (Ou des mini-ordinateurs comme l’AS-400). Il y a des langages qui lui ressemblent comme RPG-IV ile qu’il ne faut pas oublier. De mon experience le COBOL*est peut être moins utilisé que le RPG. Au final ça ne change pas grand chose juste que de lire tout le temps COBOL sans jamais lire RPG j’ai l’impression que personne sait se représenter le mainframe. Moi même je ne sais pas de quoi parle l’article étant donné que tous les sujets ici je les ai constaté sans jamais avoir bossé dans le main-frame mais sur AS-400.
Pour generer du COBOL ou du RPG on ne code pas dans ces langages, on utilise parfois des langages de plus haut niveau, des AGL etc.
Pour apprendre les langages de bas niveaux il y a toujours des formations qui existent. Bien-sur ça attire moins de gens… mais ça file du boulot, c’est bien payé etc. Sur que c’est pas à la mode mais faut pas cracher dans la soupe :*On fait des trucs incroyable avec la puissance de ces machines.

Pour ce qui est du patrimoine applicatif il faut comprendre que les boites qui ont travaillés en mainframe le font depuis 30~40 ans et qu’il s’agit des banques, des assurances, de la logistiques. 99 des 100 plus grande entreprise française possède un AS-400.
Ces sociétés ont des patrimoines immenses. Un exemple :*l’un des groupes logistique pour lequel j’ai bossé possède un patrimoine de 12000 programmes interactifs (sans parler des batchs donc) pour son appli logistique. La migration envisagé a été validé et en 2014 ils parlaient d’une horizon 2027 pour passer chez SAP.
Ce genre de client ne « laisse pas » mourir leurs applicatifs car ils peuvent ce permettre ça.

J’ajouterai sur la partie IHM qu’on peut très bien mettre à profit la puissance du Mainframe pour faire des interfaces web hyper modernes. Pour la plupart des gens toute l’IHM des applis en COBOL sont des écrans verts sur noir qu’on exploite via un émulateur de terminal. Or il existe des produits qui permettent d’attaquer des serveurs main frame.
Donc l’argument du mainframe qui meurt à cause de l’IHM…

Depuis plus de 20 ans, on ne développe plus d'interface en CICS ou IMS, ou alors c'est très rare. Les interfaces Web ont largement supplanté ces systèmes, et c'est tant mieux. Mais derrière ces jolies choses, il y a bien un bon gros mainframe et des régions CICS ou IMS pour accéder aux bases de données (DB2 ou IMS) via des serveur WAS par exemple.

[Gwilherm]

1. Le mainframe coute cher.
2. le mainframe est rigide.
3. le mainframe manque de glamour.
4. le mainframe manque de personnel qualifié.
5. les langages n'évoluent pas.

1 -> le cout de la facturation est élevé, c'est incontestable mais si on prend le nombre de traitement batch traité par un Z et celui du monde distribué, on s’aperçoit que si votre machine Z tient dans un bureau de 4 personnes, l'équivalent en terme de serveur pour traiter le même nombre de batch vous nécessite un datacenter. Je serais gentil et ne parlerais pas du cout de gestion en terme de réseau, de mise à niveau, de personnel, de surveillance et de gestion du parc. (A qui il est ce serveur ?)... (dans ma boite, sur un Z, nous sommes en termes de batch à 70 000 traitements jours, et pour les transactions...)
2 -> Tout les traitements ne nécessitent pas d'être modifiés tout les 5 matins, une chaîne comptable reste une chaîne comptable. Et la gestion du legacy nécessite un environnement stable et fiable. Donc non on ne peut pas installer n'importe quoi, (enfin si on peut mais pas les dev... ). Et pour être exact, ce sont le plus souvent les process qui rendent la gestion des projets et évolutions sur les Z lourdingues.
3 -> Ah le côté suranné des panels ISPF... On n'est pas dans le clic & drop, les interfaces sont peu conviviales c'est vrai mais ça fait le taf et ça le fait bien.
4 -> Oui mais la faute à qui ?
5 -> Si si, les langages évoluent, et la prise de tête que génère chaque migration cobol...

Oui la tendance est à la disparition du Mainframe, mais d'un autre côté j'entends ce discours depuis le début des années 2000. Cela arrivera, mais la réactivité et les grands groupes...

[Aiekick]

c'est quoi ca le mainframe ? c'est genre une facon de faire comme "l'agile" ou c'est tout autre chose ?

[4sStylZ]

En plus de ne pas savoir ce qu’est le mainframe tu n’as pas l’air de savoir ce qu’est un moteur de recherche.

[Invité]

En plus de ne pas savoir ce qu’est le mainframe tu n’as pas l’air de savoir ce qu’est un moteur de recherche.

Ou alors c'est un troll ?

[e-ric]

Salut

Ca va être un beau chantier et les SSII vont s'empiffrer. Ca c'est le côté "positif" (humour).

Cela dit, par expérience personnelle (et passée ouf !), la reprise de code Cobol c'est pas forcément simple vu la qualité très moyenne du codage et des "possibilités mirifiques" du langage, en outre, ceux qui vont faire la migration auront sans doute intérêt de trouver des compétences Cobol pour analyser ce qui se passe dans les programmes, vu que les docs c'est pas toujours le fort des services informatiques.

Les grandes boîtes utilisent quasiment toutes des mainframes car ces machines permettent le traitement de très gros volumes de données mais :
- remplacer des millions de lignes de codes ne se fait pas en 5 minutes surtout si les programmes sont très anciens et que l'on ne sait plus trop ce qui s'y passe.
- la façon de penser des cobolistes est très différente de celle des développeurs travaillant avec des technos plus récentes (POO, Web etc...).
- il faudra sans doute envisager des solutions de transitions pour garantir la continuité de service tout en s'assurant que le SI reste cohérent.
- les entreprises utiliseront alors des outils mieux connus des hackers et s'exposeront aussi sans doute d'avantage à des nouveaux problèmes de sécurité.

Je suis assez circonspect quant à ces chantiers à vrai dire. Je pense que certaines boîtes vont boire la tasse

Cdlt

[Serguei_TARASSOV]

De mémoire, "des chefs de grandes entreprises" envisageraient "d’abandonner le système mainframe" les 30 dernières ans, au moins.
Les SGBD IMS (produit depuis 1968) toujours traitent 50 milliard de transactions/jour et sont utilisés par 95% d'entreprises de TOP 1000.
Voir aussi une histoire drôle de front-end en Java/Web qui est devenu le goulot d’étranglement en cohésion de mainframe/BDD/COBOL.

[mitteljc]

Cela fait plus de 30 ans que je suis dans l'informatique. Régulièrement on nous fait cette annonce et il est toujours là, et bien là. On oublie de parler de sa robustesse et de sa très faible vulnérabilité aux attaques pirates, ce qui financièrement n'est pas négligeable. J'ai aussi des applications datant de mes débuts et étant encore souvent sollicitées. Peut-on en dire autant d'un autre système ?

[Ryu2000]

Cela fait plus de 30 ans que je suis dans l'informatique. Régulièrement on nous fait cette annonce et il est toujours là, et bien là.

Ouais mais ça finira forcément par évoluer.
Est-ce qu'en 2100 il y a aura toujours des systèmes AS/400 et du COBOL ?

Tout fini par disparaitre.
Est-ce que le mainframe est en train de se répandre, de stagner, de se raréfier ?

Est-ce que des gens travaillent sur une nouvelle technologie qui a les avantages de COBOL, plus des nouveaux avantages ? (et moins de ses défauts)

===
C'est un peu comme fin 1980 / début 1990, où des musiciens trouvaient que Pro Tools c'était de la merde (Slow Tools).
Ils disaient "la bande magnétique ne se fera jamais remplacer par les DAW".

[mitteljc]

Est-ce qu'en 2100 il y a aura toujours des systèmes AS/400 et du COBOL ?

Entièrement de ton avis, mais on peut en dire autant pour Windows, Apple, Androïd et consorts... Evidemment que cela va évoluer, mais tant qu'on n'aura pas trouvé mieux en terme de solidité, de sécurité, de disponibilité, de stabilité et plus encore, certaines entreprises ne sauteront pas le pas.

[Grogro]

Entièrement de ton avis, mais on peut en dire autant pour Windows, Apple, Androïd et consorts... Evidemment que cela va évoluer, mais tant qu'on n'aura pas trouvé mieux en terme de solidité, de sécurité, de disponibilité, de stabilité et plus encore, certaines entreprises ne sauteront pas le pas.

Pour moi le seul risque pour l'avenir de COBOL, c'est éventuellement le renouvellement des compétences. La difficulté à recruter des nouveaux venus pour faire du COBOL. Et ce n'est pas surprenant si les jeunes diplômés en informatique ne veulent surtout pas en faire (alors qu'une expérience en COBOL peut être très instructif dans une carrière plus large) : on est en France, on a le culte des étiquettes. Tu as le mot magique "COBOL" sur ton CV, on ne te proposera plus que des missions mainframe. C'est un risque que peu sont prêts à prendre tellement les premières années d'une carrière sont déterminantes.

Honnêtement je ne vois pas par quelle techno le mainframe pourrait être remplacé tellement cette archi est performante et fiable pour son domaine d'expertise. Et le COBOL a un avantage sociétal non négligeable : donner du travail aux cohortes de diplômés en chimie, biologie, géologie, neurosciences. Autant de filières de l'enseignement supérieur pour lesquelles il n'y a quasiment aucun débouchés direct (en dehors de niches comme la bioinfo), si ce n'est passer le CAPES ou l'Agreg pour se faire agresser en ZEP.