Discussion :

[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.

[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!!

[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.

[darklinux]

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.

Personne n ' oblige à tout mettre sur le cloud ! tu peux aussi acheter des serveurs et mettre un accès chiffré et restreint . Le cloud c 'est pour la publication et la release , le reste est en quatre murs

[el_slapper]

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++.

Certes. Mais est-ce que les processeurs sont optimisés pour ça? Indépendamment du proc, est-ce que ce genre de fonctions a un impact sur les performances? Les machines Z/OS ont des proc spécificquements optimisés pour ce genre de calcule en COBOL. C'est tout un écosystème qui est performant sur ce point précis; pas juste le langage.

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 ?

Partout ou je suis passé en COBOL, la partie orienté objet du langage était désactivée dans les compilateurs. C'est la seule partie qui permet des fuites mémoires.

Pour le reste, elles ne sont pas découragées, elles sont carrément impossibles : la mémoire est allouée à la compilation, et tout accès en dehors est puni par un plantage 0C4. Une zone mémoire en COBOL, doit être définie à la compilation, ne peut pas être étendue après compilation. Évidemment, ça rend certains styles de programmation impossibles, et certains algorithmes chiants(je reste poli) à coder. Mais il est rare(même si ça arrive) Qu'on aie besoin de ce genre d'algorithmes.

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.

Vrai, mais c'est vrai partout. Dans tous les langages, tu as pléthores d'ignares qui font n'importe quoi. J'en ai brièvement fait partie, d'ailleurs, puis j'ai appris. A chaque nouveau langage, d'ailleurs(le dernier étant le COS). Certains n'apprennent jamais.

Ce que je veux dire, c'est que le COBOL est bien plus tolérant vis-à-vis de ce genre de mauvais programmeurs. Un médiocre fera quand même tourner son appli, après bien des efforts. Et ça sera satisfaisant. Le même en JAVA, et les temps de traitement sont multipliés par 400(alors que le Java moderne est loin d'être lent, quand il est programmé dans les règles de l'art). En plus, l'aspect verbeux du COBOL, si il peut repousser le geek habitué à faire des choses complexes en trois caractères et demi, le rend bien plus lisible des années après. Même si il est codé moyennement. Du code immonde sera toujours immonde, mais du code à peine moyen sera quand même assez lisible, alors que dans des langages objets, j'ai tendance à trouver que du code moyen est vite incompréhensible.

Tous ces petits trucs, et quelques autres, mis bout à bout expliquent pourquoi tous les projets de refonte en profondeur échouent. Par contre, certaines boites font de la guérilla en pelures d'oignon, pour se rapprocher chaque années un tout petit peu du noyau, et c'est à mon sens la bonne stratégie. Mais même eux, quand ils s'approchent trop du noyau, se crament. Ce n'est pas un hasard. Je ne dis pas que c'est infaisable, hein. Je dis juste que l'approche qui consiste à dire "yaka mettre un langage moderne et virer toutes ces vieilleries" sans comprendres ce que sont réellement lesdites vieilleries ne marche pas. Et a déjà couté des sommes délirantes.

[Escapetiger]

Un jour il n'y aura plus de développeur COBOL, donc il faut bien passer à autre chose ^^

Pour recadrer les faits, lu dans ce rapport de décembre 2013 :

Gary Barnett, directeur de la recherche chez Ovum estime que 90 % de toutes les transactions financière et 75 % de l’ensemble des transactions dans le monde allant du retrait d’argent à un DAB, à la réservation d’un billet d’avion ou à la saisie d’une facture se font à l’aide de programmes écrits en Cobol. Il évalue le nombre des transactions quotidiennes supportées par un programme écrit en Cobol à 30 milliards.

Source: http://rapportsalzman.blogspot.com/2...-pas-mort.html
Rapport Salzman: Le Cobol n’est toujours pas mort


... et puisque nous avons de l'humour également :

A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

When he asked why he was unfrozen, he was told:

"It's the year 9999 - and you know Cobol"

[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

[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.

[e-ric]

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++.

Oui mais c'est le système qui le supporte directement. Enfin rien n'empêcherait d'étendre un compilateur pour supporter nativement un tel type de données mais en général on se contented'uen émulation à l'aide de bibliothèques.

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 ?

Là où je travaillais avant, on avait interdiction pure et simple de faire de faire des allocations dynamiques, toutes les déclarations étant statiques, cela élimine des problèmes certes mais rend difficile la mise en oeuvre d'algorithmes sophistiqués et peut compliquer diablement voire décourager des développeurs (c'est sans doute ce que veut dire rester dans les règles ;-) ) les développeurs cobol ne raisonnent que rarement en termes dynamiques, cela participe aussi à la différence de façon de penser des cobolistes. Je pense qu'il est difficile de se faire comprendre un développeur python (par exemple) et un développeur Cobol.

Sans compter la lourdeur du code Cobol (au bas mot une page de code pour un simple print("coucou")) et je ne parle même pas de la façon de déclarer des données dans Cobol, là on est en plein dans les années 60. Je hais le cobol, ce langage devrait disparaître, une petite citation sympathique :

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

[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.

[Pyramidev]

Pour le reste, elles ne sont pas découragées, elles sont carrément impossibles : la mémoire est allouée à la compilation, et tout accès en dehors est puni par un plantage 0C4. Une zone mémoire en COBOL, doit être définie à la compilation, ne peut pas être étendue après compilation. Évidemment, ça rend certains styles de programmation impossibles, et certains algorithmes chiants(je reste poli) à coder. Mais il est rare(même si ça arrive) Qu'on aie besoin de ce genre d'algorithmes.

Là où je travaillais avant, on avait interdiction pure et simple de faire de faire des allocations dynamiques, toutes les déclarations étant statiques, cela élimine des problèmes certes mais rend difficile la mise en oeuvre d'algorithmes sophistiqués et peut compliquer diablement voire décourager des développeurs (c'est sans doute ce que veut dire rester dans les règles ;-) ) les développeurs cobol ne raisonnent que rarement en termes dynamiques, cela participe aussi à la différence de façon de penser des cobolistes. Je pense qu'il est difficile de se faire comprendre un développeur python (par exemple) et un développeur Cobol.

Si je comprends bien, l'allocation dynamique n'est pas directement supportée par le langage et il n'est pas dans la culture des développeurs COBOL de réimplémenter l'allocation dynamique sur une mémoire allouée à la compilation de très grande taille qui jouerait le rôle de la mémoire dynamique.

Du coup, par curiosité, concrètement, comment les développeurs COBOL gèrent les tableaux de longueur variable, dont les chaînes de caractère ? Y a-t-il un nombre maximal d'éléments fixé pour chacun d'eux ? Si oui, est-ce que les données en entrée du programme ont un format explicitement pensé pour pouvoir fixer des tailles maximales de tableaux pas trop élevées, tout en garantissant que le programme fonctionnera ?

[Ryu2000]

Je hais le cobol, ce langage devrait disparaître

Le problème c'est qu'il y a plein de systèmes critique qui utilise Cobol et apparemment ils sont sécurisé et efficace.
Tout refaire aussi bien mais dans un autre langage semble compliqué.
En programmant quelque chose de nouveau il risque d'y avoir des failles de sécurité.

Quoi qu'il y a des articles qui disent que des hackers se sont introduit dans des systèmes mainframe du gouvernement américain.

Banks scramble to fix old systems as IT 'cowboys' ride into sunset

The Common Business-Oriented Language was developed nearly 60 years ago and has been gradually replaced by newer, more versatile languages such as Java, C and Python. Although few universities still offer COBOL courses, the language remains crucial to businesses and institutions around the world.

In the United States, the financial sector, major corporations and parts of the federal government still largely rely on it because it underpins powerful systems that were built in the 70s or 80s and never fully replaced. (GRAPHIC: tmsnrt.rs/2nMf18G)

And here lies the problem: if something goes wrong, few people know how to fix it.

En tout cas les systèmes mainframe coûtent chère à maintenir et ne sont pas flexible, donc il faudra bien passer à autre chose.
Mais les banques n'aiment pas trop investir pour améliorer leur système...

C'est comme quand des chercheurs ont informé une banque que leur distributeur de billet avait une faille exploitable et qu'il y avait une solution pour améliorer la sécurité, et la banque a attaqué les chercheurs en justice au lieu de les remercier (je raconte mal, un prof nous avait raconté cette anecdote c'est difficile de retrouver la source).

[e-ric]

Si je comprends bien, l'allocation dynamique n'est pas directement supportée par le langage et il n'est pas dans la culture des développeurs COBOL de réimplémenter l'allocation dynamique sur une mémoire allouée à la compilation de très grande taille qui jouerait le rôle de la mémoire dynamique.

Le langage le permet mais je pense surtout que les développeurs sont assez méfiants vis à vis des structures dynamiques. La façon dont sont penser les programmes ne justifie pas l'allocation dynamique, très souvent on manipule des enregistrements en entrée et en sortie.

Du coup, par curiosité, concrètement, comment les développeurs COBOL gèrent les tableaux de longueur variable, dont les chaînes de caractère ? Y a-t-il un nombre maximal d'éléments fixé pour chacun d'eux ? Si oui, est-ce que les données en entrée du programme ont un format explicitement pensé pour pouvoir fixer des tailles maximales de tableaux pas trop élevées, tout en garantissant que le programme fonctionnera ?

Les tableaux cobol peuvent être dynamiques sous certaines limites. Le fait de définir uniquement des structures statiques a l'avantage de rendre la charge des machines plus prédictible, ce qui est un aspect important dans ce milieu.

[e-ric]

Le problème c'est qu'il y a plein de systèmes critique qui utilise Cobol et apparemment ils sont sécurisé et efficace.
Tout refaire aussi bien mais dans un autre langage semble compliqué.
En programmant quelque chose de nouveau il risque d'y avoir des failles de sécurité.

En tout cas les systèmes mainframe coûtent chère à maintenir et ne sont pas flexible, donc il faudra bien passer à autre chose.
Mais les banques n'aiment pas trop investir pour améliorer leur système...

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). Elles investissent beaucoup mais elle n'aime pas les révolutions ;-). En outre, les banques ont certaines obligations quant à leur service.

Quoi qu'il y a des articles qui disent que des hackers se sont introduit dans des systèmes mainframe du gouvernement américain.

C'est je pense un péché d'orgueil de la part d'IBM qui imagine ses machines inattaquables, en fait, IBM entretient une certaine obscurité sur ses systèmes. Une fois que les hackers comprendront le système, cela risque de saigner.

C'est comme quand des chercheurs ont informé une banque que leur distributeur de billet avait une faille exploitable et qu'il y avait une solution pour améliorer la sécurité, et la banque a attaqué les chercheurs en justice au lieu de les remercier (je raconte mal, un prof nous avait raconté cette anecdote c'est difficile de retrouver la source).

Pas surprenant de leur part, avec l'orgueil démesuré et le complexe de supériorité qui prévaut dans ce milieu. La prochaine fois, ces chercheurs se serviront d'abord cela leur permettra de couvrir les frais de justice.

[el_slapper]

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.

Quand le code est suffisement vieux, tu peux être certain qu'il n'y aura plus aucune doc. La plus vieille doc que j'ai trouvé avait 15 ans d'âge, et consistait en des mails imprimés. Ca n'est pas spécifique au COBOL. C'est partout pareil. Quand tu as du code de 30, 35 ans d'âge, tu est à peu près certain que le code sera ta seule doc. Quand tu refonds le code(En COBOL, sinon ça ne marchera jamais), tu prends ça en compte.

Les grandes boîtes utilisent quasiment toutes des mainframes car ces machines permettent le traitement de très gros volumes de données mais :
(.../...)Je suis assez circonspect quant à ces chantiers à vrai dire. Je pense que certaines boîtes vont boire la tasse

Ben, ça fait 35 ans qu'ils se plantent tous. Le conditionnel de prudence t'honore, mais n'est pas forcément utile.

(.../...)
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.

JCL, c'est effectivement à chier. COBOL, ça dépend. On peut faire des choses rigolotes, en COBOL. Certes, ce n'est pas dans les habitudes. Mais on peut, si on reste conservateur.

(.../...)Je pense qu'il est difficile de se faire comprendre un développeur python (par exemple) et un développeur Cobol.

Sans compter la lourdeur du code Cobol (au bas mot une page de code pour un simple print("coucou")) et je ne parle même pas de la façon de déclarer des données dans Cobol, là on est en plein dans les années 60. Je hais le cobol, ce langage devrait disparaître, une petite citation sympathique :

Sauf que ça marche, et qu'un programmeur à peine moyen peut s'en sortir. Essaye donc de mettre un programmeur à peine moyen sur un projet JAVA de taille conséquente..... Et les programmeurs moyens, ce n'est pas ça qui manque.

Oui, la communication est difficille. Je me souviens, quand je me suis dit qu'il fallait que je me mette à l'objet, je suis resté 2 jours à regarder le code exemple sans comprendre cet exemple avec un getter tout simple. Il a fallu me tordre le cerveau violemment pour comprendre que c'était tout simplement une définition de données - avec son propre code(tout le reste découle de ça, en fait, toutes les théories sur le polymorphisme, l'héritage, toutes les différences en termes de manière de penser, vient de cette seule et unique mais immense différence avec le procédural : la structure de données peut embarquer son propre code, et on appelle le tout une classe).

Si je comprends bien, l'allocation dynamique n'est pas directement supportée par le langage et il n'est pas dans la culture des développeurs COBOL de réimplémenter l'allocation dynamique sur une mémoire allouée à la compilation de très grande taille qui jouerait le rôle de la mémoire dynamique.

Du coup, par curiosité, concrètement, comment les développeurs COBOL gèrent les tableaux de longueur variable, dont les chaînes de caractère ? Y a-t-il un nombre maximal d'éléments fixé pour chacun d'eux ? Si oui, est-ce que les données en entrée du programme ont un format explicitement pensé pour pouvoir fixer des tailles maximales de tableaux pas trop élevées, tout en garantissant que le programme fonctionnera ?

Oui. Ca peut poser des problèmes de conception, d'ailleurs. Mais tous les tableaux, dans les bonnes pratiques, sont dimensionnés à la compilation. On rajouter généralement une sécurité qui assure un plantage "propre" en cas de dépassement, pour pourvoir rapidement(moins de 10 minutes) corriger, recompiler, livrer en Homologation, tester rapidement, et livrer en production.

D'ailleurs, avantage de ne pas avoir d'objets, juste des descriptions de donnes "plates" (bon, on peut mettre un peu de métier avec les niveaux 88, mais ça reste rudimentaire, c'est du paramétrage, pas du code), c'est que les éléments sont faiblement couplés. Donc pas besoin de tout rebuilder à chaque fois qu'on fait un changement. On peut livrer juste le composant impacté, sans toucher au reste, et ça tourne. C'est évidemment moins élégant qu'un bel objet avec ses héritages, mais quand je voyais les gens du JAVA mettre plusieurs heures à recompiler leur solution, je me disais que j'étais un heureux homme. Jusqu'au jour ou j'ai du mettre en place un algorithme vraiment compliqué et vraiment dynamique. Un tableau à 4 dimensions que je torturais dans tous les sens, avec gestion systématique des tailles maximales de tableau,et compteurs, là ou des collections imbriquées auraient fait le boulot nativement.

Mais ce genre d'algo est rarissime dans ce genre de domaine fonctionnel. Des algos compliqués, j'ai du en faire 3 en 8 ans de programmation COBOL. Celui là, un système de mapping dynamique entre de nombreux formats de fichiers ressemblants et pas identiques(on m'avait conseillé de faire par paire de formats, je les ai envoyé chier, j'ai fait un moteur à la place), et une comparaison de fichiers plats avec double rupture sur clef partielle des deux cotés(un poil moins méchant que les deux autres, hein). C'est très peu, 3 en 8 ans. COBOL est pourri pour les algorithmes compliqués, mais très très fort pour les suites complexes d'opérations unitaires pas très compliquées - qui sont l'alpha et l'oméga de l'informatique bancaire.

Évidemment, le diplômé en informatique, soit il est moyen(ou pire) et ne rêve que de passer chef, Soit il est bon(ou encore meilleur) et ne rêve qu'objet et algorithmes rigolos(donc compliqués). Fatalement, le COBOL ne fait pas rêver grand monde, et on trouve dans ce monde là surtout des reconvertis(genre moi, à l'époque). Mais il fonctionne, permet des maintenances à chaud sans interférences sur les composants d'à coté, est très adapté au types de problématiques qui se posent, et forme avec Z-OS et les processeurs dédiés un écosystème particulièrement optimisé pour sa niche.

Donc ce genre d'inconvénients, on les accepte. Ca bloque rarement, finalement. Ca fait souvent chier, mais c'est rarement un gros problème.

[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".

[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.