Discussion :

[rberthou]

Déjà l'intérêt c'est de faire tourner des énormes applications existantes qui ont été développées pendant des années.

Oui, des applications critiques qui sont le cœur du SI de l'entreprise .

Ensuite des solutions mainfraime comme Cobol/CICS peuvent êtres encore très efficaces pour des traitements gestion très lourds et répétitifs, comme par exemple les traitements bancaire sur un très grand nombre de comptes et d'opérations....

Traitement de gestion très lourds... J'ai un doute, je ne pense pas que les transactions de gestion TP puissent etre lourde. Par contre CICS supporte parfaitement les gros nombre d'acces concurent (c'est un moniteur transactionnel...)

Les machines ont énormément monté en puissance ces dernières années et aujourd'hui je pense que dans bien plus de 50% des cas les mainframes peuvent etre remplacé par des serveurs de type "Intel". Le problème restant alors la ré-écriture des applications (des solutions complète de re-hosting existe - MicroFocu, Clerity, ..)

[jabbounet]

En fait aujourd'hui je me demande un peut quel est l'intérêt d'un mainframe plutôt qu'une solution en cluster avec des blades par exemple ?
Pourquoi choisir un mainframe de nos jours ?

Le cout d'une migration serait probablement prohibitif et assez risqué.
On parle de porter des applis qui ont 20 ans de vie derrière elle dans une nouvelle techno (cluster/java par exemple).


Ne pas oublier que pour porter ce genre d'appli comme souvent on aura:
- Une partie de code n'est pas décrite (comme souvent la doc n'est pas exhaustive)
- tout un tas de fonctionnalités n'ont pas évolué mais personne ne sais plus ce qu'il y'a dedans.
- certains sources peuvent avoir disparu (et la c'est boite noir que plus personne ne touche de peur de tout casser)
- remplacer l'équivalent de 20 de codage qui a fait ses preuves par un code neuf (qui ne se fera pas en claquant des doigt)

Bref c'est un risque d'indisponibilité très important du système et le temps c'est souvent de l'argent pour ceux qui utilisent ce type de système.

même si c'est techniquement faisable je ne crois pas q'un décisionnaire prendra cette décision ou alors il est bien fourni au niveau du pantalon, car le risque est énorme, sans parler du cout.

[rberthou]

Ne pas oublier que pour porter ce genre d'appli comme souvent on aura:
- Une partie de code n'est pas décrite (comme souvent la doc n'est pas exhaustive)
- tout un tas de fonctionnalités n'ont pas évolué mais personne ne sais plus ce qu'il y'a dedans.
- certains sources peuvent avoir disparu (et la c'est boite noir que plus personne ne touche de peur de tout casser)
- remplacer l'équivalent de 20 de codage qui a fait ses preuves par un code neuf (qui ne se fera pas en claquant des doigt)

Bref c'est un risque d'indisponibilité très important du système et le temps c'est souvent de l'argent pour ceux qui utilisent ce type de système.

même si c'est techniquement faisable je ne crois pas q'un décisionnaire prendra cette décision ou alors il est bien fourni au niveau du pantalon, car le risque est énorme, sans parler du cout.

Si on est dans cet état là :
- Une partie de code n'est pas décrite
- certains sources peuvent avoir disparu

Le système va déjà très mal, car je pense que la moindre modifications des chaines de traitement est très pénible, longue et parfois même impossible (si absence des sources d'origines).
Il est largement temps de faire un état des lieux et de re-documenter/cartographier son SI.

[jabbounet]

Si on est dans cet état là :
- Une partie de code n'est pas décrite
- certains sources peuvent avoir disparu

Le système va déjà très mal, car je pense que la moindre modifications des chaines de traitement est très pénible, longue et parfois même impossible (si absence des sources d'origines).
Il est largement temps de faire un état des lieux et de re-documenter/cartographier son SI.

"Le système va déjà très mal" c'est parce que je suis pessimiste de nature .

Je me souviens avoir débuté sur une tma de plusieurs applications en fortran/lisp en 1999 ou les les docs des applis étaient entassées dans une armoire et ou je devais faire de la spéléologie pour retrouver celles qui m'intéressaient.
Un jour alors que je cherchais des infos sur une des dites applis, je suis tombé sur un bout de spec et un listing (en assembleur) datant des années 70. mais rien entre les deux, alors que l'appli elle avait pas mal bougé (changement d'os de langage, ...).

Ceci dit c'était une expérience rigolote cette tma, j'avais une bonne partie de l'histoire de l'informatique devant moi celle comprise entre les années 1970 et 2000.

[el_slapper]

Tiens, c'est un peu mon projet qui va finissant, ça.....sauf qu'on a migré de COBOL vers COBOL. En explicitant un tas de trucs qui n'étaient pas documentés, en refactorisant partout ou c'était possible, en sortant un maximum de choses......mais il y a malgré tout des éléments que j'ai retranscrits tels quels, car nul ne sait pourquoi c'est là, mais chacun sait que sans, ça ne marche pas.

Je les ai quand même adaptés à du COBOL "moderne", c-à-d que j'ai remplaçé les horreurs du genre

Code :

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

1
2
3
4
5
6
7
8
 MOVE 0 TO I
A22.
 ADD 1 TO I
 IF I > LIMITE GO TO  A21.
 (.....traitement fonctionnel illisible.....)
 GO TO A22.
A21.

par des

Code :

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

1
2
3
4
5
 PERFORM VARYING I FROM 1 BY 1 UNTIL I > LIMITE
    (.....traitement fonctionnel retravaillé et correctement indenté.....)
 END-PERFORM
 .

(je préfèrerais qu'il y aie des FOR/NEXT en COBOL, mais bon, ça y ressemble fortement, et ça suffit)

Mais ça en reste là, parceque même retravaillé et indenté, le code fonctionnel, je ne sais pas ce qu'il fait ni surtout pourquoi. Alors transférer le bidule sur une autre technologie, je veux bien, mais bon courage. Ca sera sans doute plus facile à partir de ma version que de l'ancienne, mais reste qu'il y a des blocs imbitables. Qu'il faudra traduire quand même dans le nouveau language. A l'aveugle.

Donc c'est compliqué. J'ai passé 1 mois de ma vie sur 2 programmes de 5000 lignes chacun, juste à rétrodocumenter. Et encore, les 2000 premieres lignes du premier programme, qui consistent en des traitements comptables(tous sur le format que j'ai cité au dessus, avec des labels aussi explicites que A1, A11, A22, A21, A12, A12, le tout dans cet ordre), j'ai fait comme les autres : j'ai renoncé et on garde, parceque ça marche. Rien que nôtre appli, la gestion de contrat, ça représente des milliers de progs de 2000 lignes en moyenne. Certains plus modernes et mieux commentés, m'enfin pas plus de la moitié.....

Et on ne doit pas faire 20% du SI COBOL.

Je ne dis pas que c'est pas possible, je dis plutôt que c'est énorme. Et qu'il faut accepter une certaine dose de pertes. Perte de données, perte de savoir-faire, perte de précision. Perte aussi dans le fait que les gens(les utilisateurs) savent se retrouver dans l'existant, et gueulent dès qu'ils ont un bel écran JAVA à la place - devant lequel ils sont perdus.

Mais si on commence à migrer tout ce qui est interface vers des langages "modernes", c'est parceque l'on peut découper en série d'écrans cohérentes. Pour ce qui est du noyau "referentiel/batch", c'est infiniment plus complexe. Et budgetivore. Tout ça pour arriver à des solutions JAVA ou les gens ne peuvent même plus bosser tellement la taille du projet met leur machines de compèt' à genoux à la moindre compil/remise à niveau.....

Si COBOL met autant de temps à mourir dans les très grandes entreprises, ça n'est pas un hasard.....evidemment, en PME, tout ce que je viens de dire n'a aucun sens.

[fred_avignon]

Intéressante discussion... qui peut me concerner directement. Je vous explique.

Je suis en recherche d'emploi depuis 2 mois sur Avignon. J'ai bientôt 40 ans et je développe des applications depuis plus de 20 ans. Je suis plutôt spécialisé en développement orienté objet (C++, Java, PHP5, etc).

Actuellement les temps sont durs pour les informaticiens dans ma région et je me tâte pour savoir si je ne m'orienterais pas vers le développement sur mainframe. J'ai appris le cobol et le GAP (RPG) en 1989 sur des IBM S36 et j'ai bossé 1 an sur un AS400 dans la foulée.

Bref, à mon âge, il ne faut pas trop faire le difficile sinon on ne trouve rien.
Comme je suis peu mobile (pas envie de vivre dans une grande ville), j'essaye de savoir si les entreprises qui recherchent des développeurs cobol ou autres langages anciens sont plus enclins à accepter le télétravail.

Que pensez-vous de mon approche ? Est-ce utopique/faisable ?

[souviron34]

Pourquoi n'embauchent-elles pas des juniors et les faire se former avec l'aide d'un tuteur qui est dans les 5 dernières années avant sa retraite ? Cela coûte cher, mais cela ne vaut-il pas la peine de s'y mettre ?

• Parce qu'il n'y a pas un jeune qui soit formé à penser comme ça, dans l'enseignement tout n'est qu'OO.. quand maintenant ce n'est pas OA.
  
• Parce que l'intérêt des jeunes est sur les jeux vidéo, le traitement d'images, le data mining, l'IA...

L'erreur, c'est sans doute aussi de vouloir cibler des jeunes. Des expérimentés avides de stabilité peuvent être des profils bien plus interessants pour remplacer ceux qui vont partir. un jeune sorti de l'école, on lui dit "on va te former à des technos qui ont 40 ans pour que tu restes 40 ans dessus", il va fuir. Le gusse de 33 ans qui en a marre de bouger et a un enfant à nourrir, lui, serait plus interessé.....

Certes, le jeune est ciblé, mais la personne expérimentée... elle coute plus cher.. Ce n'est pas pour rien qu'ils préfèrent les petits jeunes sortis d'école, c'est plus facilement malléable...

ça aurait été vrai, dans le passé..

Je pense qu'à l'heure actuelle c'est le contraire.. Les jeunes sont moins malléables que les vieux : certitudes sur les langages, les concepts, les méthodologies, la "modernité", etc etc..

Et je pense que c'est une grave erreur de la part des boîtes...

Concernant la disparition des compétences je pense que c'est surtout un problème de perception, le Cobol, le PL1 le mainframe c'est l'informatique de "grand père" produisant des écrans noir et vert ...

ce que je dis plus haut..

Suffit de voir les quelques commentaires que l'on obtient dès que l'on tente de pondérer les élans d'enthousiasme pour tel ou tel "dernier avatar", ou quand on te dit que "10 ans c'est de la préhistoire"...

[Invité]

souviron34, je suis d'accord avec toi que les jeunes sont plus attiré par les nouveaux langages, mais les sociétés qui travaillent avec du mainframe n'ont, depui 20 ans, jamais investit dans la formation de personnel sur du Cobol. Maintenant, ils s'en mordent les doigts et vont être en pénurie de ces profils.

Pourquoi ? Pour réduire les coûts bien sûr. La réduction des coûts amènent les entreprises à ne plus former la jeune génération car il faut payer un senior et un junior pour former le junior.

Maintenant qu'elles ont bien gagné de l'argent, il va falloir qu'elles en perdent et qu'elles revoient leur politique RH. Soit il faut qu'elles forment des juniors à ces technologies, soient, elles changent leur SI (ce qui n'est pas envisageable)

[CORBASE]

Salut à tous !

Je voulais vous faire part de ma petite expérience ...

Effectivement je fais partir de ces "jeunes diplômes" qui ont opté pour la voie du mainframe.

Effectivement le problème vient du fait des compétences ... Si je prends le système phare du IBM System z, le z/OS, il faut au minimum 5 ans pour pouvoir être autonome sur la machine !

Le fait de vouloir garder une compatibilité ascendante fait qu'il faut arriver à garder le même mode de fonctionnement pour faire tourner les vieux programme. Il y a donc à celà un lourd passé historique, qui il est vrai n'est pas facile à comprendre au début. Mais bon, ce dire pour une entreprise que l'investissement logiciel qu'elle fait, sera pérenne au moins 20 à 30 ans, c'est quand même énorme.


Après, il faut savoir que ce type de machine à quand même des emplois de types spécifiques ... Tout le monde n'a pas besoin d'un mainframe, et surtout celui-ci n'est pas adapté à toutes les situations.

Effectivement comme je pouvais lire, pour le calcul financier intensif, celui-ci s'avère très peu rentable car il n'est pas conçu pour traiter ce types d'informations. Par contre, pour la gestion de la donnée, bah il n'y a pas meilleurs système au monde.

Pour information, tout le monde connait le système ERP : SAP. Bah celui-ci ne donne la garanti grande disponibilité que si les données sont hébergés sous z/OS et DB2 for z/OS. Ce qui vous prouve la robustesse de sa machine.


Ensuite je voulais insister sur un point noir dans l'esprit des jeunes : NON CE N'EST PAS UN DINOSAURE. Et oui, du COBOL certes ça marche très bien, mais aujourd'hui ce que l'on veut c'est du JAVA, de la SOA, etc ....
Et tout les produits dernier cris en matières de gestion applicatives sont bien sûr disponible sur la plateforme mainframe.

Enfin, voilà je vais pas m'attarder plus, mais je suis tomber "amoureux" de cette plateforme des les premiers instants.

[el_slapper]

Tiens, un enthousiaste.....

Je suis d'accord avec certains points évoqués, notamment le fait que le mainframe, ça marche. Et ça, c'est très important.

Maintenant, j'en fait depuis 2000, après une formation de 5 semaines, presque en continu, et je ne peux pas dire que je soit "amoureux" du truc. Juste, pour le noyau de données de gestion d'une grande entreprise, je pense que c'est resté très performant.

[rberthou]

[LIST]
Je pense qu'à l'heure actuelle c'est le contraire.. Les jeunes sont moins malléables que les vieux : certitudes sur les langages, les concepts, les méthodologies, la "modernité", etc etc..

Et je pense que c'est une grave erreur de la part des boîtes...

Là je ne suis pas d'accord.. Les "vieux" (parfois très tôt) refusent souvent tout changement dans leurs modes de travail ils n'acceptent pas de ce remettre en question, ils font cela depuis 20 ans donc c'est ce que l'on doit continuer a faire...

L'informatique c'est avant tout accepter d'évoluer et même les mainframes ont largement évoluer ces dernières années. Il y a 10 ans certains administrateurs mainframe refusaient toujours d'ouvrir leur "machine" au monde extérieure ( refus de DRDA, de CTG ... et franchement le développement de communications en APPC c'est tout de même très lourd...)

[souviron34]

Ensuite je voulais insister sur un point noir dans l'esprit des jeunes : NON CE N'EST PAS UN DINOSAURE. Et oui, du COBOL certes ça marche très bien, mais aujourd'hui ce que l'on veut c'est du JAVA, de la SOA, etc ....

C'est un peu (beaucoup) ce qui ressort des divers forums ici...

Je ne sais pas si c'est dû à l'enseignement, ou au "buzz" entre jeunes, mais c'est ce qu'il apparaît.. Tot ce qui a plus de 3 ans (et encore, des fois 1) est "dinosaure"...

Là je ne pas d'accord.. Les "vieux" (parfois très tôt) refusent souvent tout changement dans leurs modes de travail ils n'acceptent pas de ce remettre en question, ils font cela depuis 20 ans donc c'est ce que l'on doit continuer a faire...

C'est vrai aussi...

Mais il y a les 2 côtés...

L'informatique c'est avant tout accepter d'évoluer et même les mainframes ont largement évoluer ces dernières années. Il y a 10 ans certains administrateurs mainframe refusaient toujours d'ouvrir leur "machine" au monde extérieure ( refus de DRDA, de CTG ... et franchement le développement de communications en APPC c'est tout de même très lourd...)

C'est exact..


Mais c'est aussi (je ne sais pas, je n'évolue pas dans ce milieu.. mais de ce que j'ai vu) lié au paragraphe au dessus...

Je suis atypique, ayant beaucoup bougé et changé d'environnements. Je ne suis effectivement pas certain (et même j'aurais tendance à penser le contraire, avec la mentalité française) d'être représentatif des "vieux"... surtout dans le milieu grandes banques ou assurances...

Cependant, un aspect non négligeable est également justement l'expérience.. Alors oui , il faut évoluer, mais pas "évoluer pour évoluer"... Si c'est pour refaire exactement la même chose avec de nouveaux outils, c'est pas très rentable ni utile...

Donc je peux comprendre une partie "relativement réfractaire au changement", si ce changement n'est pas fortement justifié... On voit tous aujourdhui que la société de sur-consommation n'est pas forcément meilleure et ne donne pas forcément de meilleurs produits que celle d'avant... Quelqu'un qui a connu un moyen de faire quelque chose peut renâcler avec raison sur une modernisation qui, grâce à ce qu'il connaît de son exprience, n'apportera rien de plus...

A l'inverse, rester bloqué sur un outil ou une attitude est fondamentalement erroné.. Si on prouve que l'outil ou l'attitude est dommageable..

[keitaro_bzh]

souviron34, je suis d'accord avec toi que les jeunes sont plus attiré par les nouveaux langages, mais les sociétés qui travaillent avec du mainframe n'ont, depui 20 ans, jamais investit dans la formation de personnel sur du Cobol. Maintenant, ils s'en mordent les doigts et vont être en pénurie de ces profils.

Pourquoi ? Pour réduire les coûts bien sûr. La réduction des coûts amènent les entreprises à ne plus former la jeune génération car il faut payer un senior et un junior pour former le junior.

Maintenant qu'elles ont bien gagné de l'argent, il va falloir qu'elles en perdent et qu'elles revoient leur politique RH. Soit il faut qu'elles forment des juniors à ces technologies, soient, elles changent leur SI (ce qui n'est pas envisageable)

Mais à l'heure du capitalisme et de ses actionnaires, quel société est prêt à "perdre" de l'argent? Seules celles qui sont conscience de ce problème... Mais en général, ces sociétés ont pris les devant et n'ont pas hésité à opter pour la formation de junior depuis longtemps

[Invité]

Mais à l'heure du capitalisme et de ses actionnaires, quel société est prêt à "perdre" de l'argent? Seules celles qui sont conscience de ce problème... Mais en général, ces sociétés ont pris les devant et n'ont pas hésité à opter pour la formation de junior depuis longtemps

Oui, mais maintenant, elles se retrouvent devant un dilemme : payer pour former des jeunes à leur technologie ou alors changer de technologie.

Dans les deux cas, ça va leur coûter de l'argent. Donc on repousse au maximum la décision.

[keitaro_bzh]

Oui, mais maintenant, elles se retrouvent devant un dilemme : payer pour former des jeunes à leur technologie ou alors changer de technologie.

Dans les deux cas, ça va leur coûter de l'argent. Donc on repousse au maximum la décision.

En espérant que cela leurs serve de leçon!

Mais plus ils attendront, plus le problème grandira, et plus salée sera la facture... Faut pas avoir fait polytechnique pour le comprendre...

[Invité]

En espérant que cela leurs serve de leçon!

Mais plus ils attendront, plus le problème grandira, et plus salée sera la facture... Faut pas avoir fait polytechnique pour le comprendre...

Les actionnaires l'ont compris, mais lorsque le bateau sera en train de couler, ils seront déjà loin.

[aballarin]

Il faudait que l'on arrête d'opposer le Mainframe aux autres technologies. Sur le ZOS d'IBM, car c'est de cela qu'il s'agit, on peut TOUT faire: du Linux, de l'Unix, du Windows si l'on veut... On peut installer des serveurs d'applications sur des partitions Linux, installer des plate-formes d'échange sur d'autres partitions Linux ou Unix et des SGBD sur le ZOS. Ceux qui travaillent dans les Datacenter savent très bien qu'une machine de ce type peut remplacer des dizaines d'autres serveurs Unix qui consomment énormément d'énergie.
Pour un développement durable, le mainframe est une solution écologique.
Abal

[Invité]

Il faudait que l'on arrête d'opposer le Mainframe aux autres technologies. Sur le ZOS d'IBM, car c'est de cela qu'il s'agit, on peut TOUT faire: du Linux, de l'Unix, du Windows si l'on veut... On peut installer des serveurs d'applications sur des partitions Linux, installer des plate-formes d'échange sur d'autres partitions Linux ou Unix et des SGBD sur le ZOS. Ceux qui travaillent dans les Datacenter savent très bien qu'une machine de ce type peut remplacer des dizaines d'autres serveurs Unix qui consomment énormément d'énergie.
Pour un développement durable, le mainframe est une solution écologique.
Abal

Ce n'est pas un problème d'opposition des technologies, c'est un problème de connaissances de base des mainframes. Très peu d'école proposent à leurs élèves des cours sur du Mainframe, et très peu d'entreprises font le pas vers la formation des jeunes.
La technologie du mainframe est une bonne technologie, mais si personne ne sait s'en servir, ça ne sert à rien.

[j.peg]

ouais... quand on parle de mainframe , généralement on pense à MVS et consorts (CICS, DB2, etc....) , pas vraiment à la machine côté hardware.
et sur ces environnements les compétences se font rares, les jeunes n' y étant pas formés (parce que ça fait 20 ans que certains annoncent la mort du mainframe pour demain... vu ce qui reste encore, ne serait-ce que dans les banques, y a encore du taff pour pas mal de monde...)

[zecreator]

Le problème n'est pas seulement de remplacer les départ en retraite, mais de remplacer les compétences.

Or une formation de fin de cursus n'a rien à voir avec 30 années d'expérience, ou la connaissance pointue d'une application particulière sur laquelle on a travaillé pendant plus de 10 ans...

Je n'y connais rien en mainframe, je ne connais pas du tout le domaine, mais vous ne croyez pas qu'il aurait peut-être fallut se réveiller un peu plus tôt avant de tirer la sonnette d'alarme.

Perso, tant pis pour ceux qui vont se retrouver dans la mouize. Une entreprise, d'autant plus informatique se doit d'être au courant des tendances technologiques et savoir prévenir quelques années avant, les problèmes à rencontrer dans l'avenir, afin de mettre en place une solution.

ça me fait marrer moi, les boites qui veulent pas changer leur techno parce que ça coûte cher, et qu'ensuite ça pleure parce qu'il n'y a plus personne pour pouvoir administrer leur parc.

Tiens autre manque, il reste quelques écoles qui sont bien embêtées car y a personne pour pouvoir gérer du nano-réseau sur un parc de Thomson MO5.

Pareil, faut pas pousser...