Discussion :

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

[Invité]

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

Totalement faux, j'en vois plein de nouveaux autour de moi, assez régulièrement très talentueux, malgré une formation à l'arrache...Et j'adore travailler avec des jeunes, s'ils ont pleins de choses à apprendre, je n'hésite pas moi aussi à apprendre (même si je pas tête baissée, par expérience).

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

[Invité]

100% d'accord, les informaticiens ont trop longtemps vécus sur le mythe qu'ils sont irremplaçables, être grassement payé à ne rien faire ne peux pas durer toute une vie...

J'ai rarement vu des informaticiens grandouiller, même peu de temps; quant aux gens grassement payés, les Dev' ? Vous rigolez ou quoi ?

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

[Invité]

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.


Pourrais-tu nous en dire plus ?

Vous êtes à l'opposé total de ce qui se fait sur mainframe : les types numériques sont traitées par du microcode, d'où un gain de performance non négligeable. Vos instructions en C montrent à quel point ce langage est d'une pauvreté affligeante.

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 ?

En COBOL, toute la mémoire est statique. On peut bien entendu faire des gestions dynamiques de mémoire avec Language Environment, services CEEGTST et CEEFRST. Même mal employés, vous plantez votre programme ("enclave" est le mot exact). Vous dépassez les bornes d'un tableau, idem : ça devient farfelu ou vous plantez...

Quelle est la différence avec les autres langages ?

De quoi parlez-vous ?

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.

Aucun problème, l'optimisation du compilateur fait le job. Mais oui, c'est moche de copier/coller.

[benjani13]

Plusieurs intervenants ont parlé des performances plus intéressantes du COBOL, connaissez vous des comparatifs publics sérieux de performance entre des programmes COBOL sur mainframe et leur équivalent (quelque soit le langage) sur des architectures plus "courantes"?

[Invité]

Plusieurs intervenants ont parlé des performances plus intéressantes du COBOL, connaissez vous des comparatifs publics sérieux de performance entre des programmes COBOL sur mainframe et leur équivalent (quelque soit le langage) sur des architectures plus "courantes"?

Comment ont peut comparer des architectures physiques aussi radicalement différentes que des machines Z/OS et "le reste du monde" ? Il y a trop de biais ou de choses incomparables.

[benjani13]

Comment ont peut comparer des architectures physiques aussi radicalement différentes que des machines Z/OS et "le reste du monde" ? Il y a trop de biais ou de choses incomparables.

Tu prend une machine Z/OS, qui te coute un certains prix, qui au maximum te traitent tant de donnée/batch/whatever par jour, et tu regardes à un budget équivalent si tu obtient plus ou moins de traitement par jour sur une autre architecture (avec un langage adapté).
D'autres critères peuvent être évalués. Le temps d'écriture d'un code COBOL sur Z/OS et d'un autre code équivalent sur une autre archi. Tu peux prendre en compte le cout de la maintenance dans le temps...

[Invité]

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 ?

Les tableaux peuvent êtres de dimension fixe (jusqu'à 7 dimensions depuis COBOL 5, mais pas de dimension négative comme en PL/1, donc avec des indices négatifs). Ou de longueur variable pour le nombre de postes.
A charge du programmeur de gérer les débordements : parfois ce n'est pas fait, tout va bien, jusqu'au jour où on atteint les limites ==> ABEND S04C.
On peut faire de puissante recherches en mémoire avec les tableaux; séquentiellement avec SEARCH et un INDEX (pas un indice); dichotomiquement avec SEARCH ALL et toujours un INDEX (contient l'adresse réelle en mémoire, pas le rang d'un poste, qui sera converti en adresse mémoire puis reconverti en rang). Les tableaux commencent à 1 et c'est logique, le premier numéro d'une maison dans une rue c'est 1, pas 0...

Les chaines de caractères sont fixes, car véhiculées dans des fichiers, et bases de données (mais on a du VARCHAR dans DB2; là encore on doit pouvoir gérer une longueur maximale). Il n'y a rien de natif dans COBOL pour déclarer une chaine de longueur variable sans stocker explicitement une variable binaire qui contient sa longueur. D'ailleurs dans DB2, il faut prévoir lors d'un SELECT par exemple, une zone qui indiquera si la longueur est nulle ou si la variable hôte est trop petite après exécution. Moins cool qu'en Java, je le concède.

[Invité]

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


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

Désolé, mais sans contrat avec le client, on ne s'amuse pas à hacker un dispositif et ensuite aller voir la banque en toute naïveté.
Ceci dit, ces mainframes devaient êtres couplés à des systèmes genre UNIX ou Microsoft, et là, tout est possible. Ou alors la gestion de la sécurité laissait franchement à désirer (c'est cher la sécurité, hein ?!). J'ai connu un système CICS de production où la transaction CSMT n'était pas protégée par un mot de passe. Je vous laisse le soin de cherche ce que l'on peut faire avec...

[Invité]

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.


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.


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.

Les banques ont évolué d'une manière énorme dans la modernisation de leur SI. Mais cela coûte cher, et il ne faut pas se laisser entrainer dans des aventures hasardeuses. Si une seule banque de taille significative ne peut plus rien recevoir / envoyer comme virement / prélèvement pendant 24 heures, les conséquences peuvent vite devenir cauchemardesques. Idem pour les compagnies d'assurance, le secteur de la distribution.
Le mainframe IBM Z/OS (MVS comme disent certains, quoique MVS existe encore: c'est le noyau) a énormément évolué depuis les années 1970 :
- ouverture aux réseaux TCP/IP et abandon du réseau propriétaire.
- ouverture au web via les serveurs Websphere, et donc au monde HTML / Javascript / Java, donc y compris smartphone et tablette
- l'interface TSO est progressivement remplacé par Rationnal Developper for Z/OS (IBM), une version spéciale d'Eclipse, avec les PD Tools (https://www.developpez.net/forums/d7...-system-z-rdz/) et d'autres IDE tout aussi révolutionnaires
- DB2 peut maintenant exécuter des requêtes sur des flux XML stockés en base (XQuery et Xpath, oui...), les processeurs spécialisés ZIIP (oui, deux "i") le font à une vitesse incroyable
- COBOL Z/OS permet de parser des flux XML ou d'en générer, à partir de fichiers séquentiels
- COBOL pour AIX, l'Unix d'IBM, permet même de valider un flux par rapport à un schéma XSD
- les machines Z/OS sont maintenant en architure 64 bits

[Pyramidev]

Vos instructions en C montrent à quel point ce langage est d'une pauvreté affligeante.

Ce n'est pas du code en C, mais en C++, qui est un langage beaucoup plus riche que le C.

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 ?

Quelle est la différence avec les autres langages ?

De quoi parlez-vous ?

Je ne sais pas exactement ce que el_slapper entend par programme (processus ? thread ? routine ?) et par plante (crash ? retourne un code d'erreur ? autre ?)
el_slapper, peux-tu développer ?

[danyclassique]

D’après la dernière newsletter on avait un reportage sur les langues et en particulier sur COBOL , qui stipulait qu’on était pas près de l’abandonner et aujourd’hui dans cette newsletter on nous dit carrément l’inverse ou presque. J’ai pas totalement tout compris

[sam01]

100% d'accord, les informaticiens ont trop longtemps vécus sur le mythe qu'ils sont irremplaçables, être grassement payé à ne rien faire ne peux pas durer toute une vie...

Heu grassement payés à ne rien faire... tu fais surement allusion aux traders là...

[Escapetiger]

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

En 1997, il met en évidence une faille dans le système de sécurité des cartes bancaires. Cette faille permet de créer des cartes acceptées par les terminaux, mais non liées à un compte bancaire.

Tu veux parler de Serge Humpich peut-être ?

[foetus]

Oui il parle de l'inventeur des "YesCard" qui ont fait fureur début 2000 (<- lien wiki)
Et cette affaire met en évidence la différence française (EU ??) et américaine : aux USA, il y a eu des hackers qui ont été embauchés pour justement améliorer la sécurité. En France, on lui colle un procès au derrière.

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

[el_slapper]

(..../....)
Je ne sais pas exactement ce que el_slapper entend par programme (processus ? thread ? routine ?) et par plante (crash ? retourne un code d'erreur ? autre ?)
el_slapper, peux-tu développer ?

Je ne parlait pas de plantage, mais de fuites mémoires. Qui sont impossibles, en gros. Mon collègue a été plus précis sur le pourquoi. un bête plantage, quel que soit l'Os, en effet, ne pose de problème qu'à ce qui est planté. Sinon, tes mots n'ont aucun sens en Z/Os, mais "routine" est sans doute ce qui s'en éloigne le moins

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.

les diplomés en info en COBOL ont toujours été des bêtes rares.

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.

tiens, ça, c'est moi. La plasturgie n'était pas aussi maltraitée que les autres domaines, mais je suis sorti du service militaire la mauvaise année.

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