Pourquoi les jeunes programmeurs ne sont-ils pas intéressés par les mainframes? [fermé]

Un problème clé avec les mainframes est que la cohorte d’appuis des programmeurs diminue. Bien que normalement cela ne poserait pas de problème en ce qu'une offre en baisse de programmeurs serait compensée par une augmentation de salaire, ce qui entraînerait une augmentation de l'offre de programmeurs via la loi de l'offre et de la demande, je ne suis pas sûr que cela se produise réellement. mainframes.

Bien qu'ils constituent toujours une infrastructure essentielle pour de nombreuses entreprises, le simple fait est qu'il n'y a pas un nombre suffisant de jeunes programmeurs pour maintenir la population de support peuplée.

Pourquoi est-ce? Qu'est-ce qui rend les ordinateurs centraux peu attrayants pour les jeunes programmeurs?

Je suis un vieux programmeur et les gros systèmes ne m'intéressent pas. Mes raisons seront probablement similaires à celles données par les jeunes programmeurs, mais sans la méconnaissance de la technologie si évidente dans nombre de ces réponses.

Commençons par l'ignorance:

• Les diverses affirmations selon lesquelles il est impossible d'essayer des ordinateurs centraux sont fausses. Hercules est disponible depuis 1999, probablement depuis plus longtemps que la plupart des personnes interrogées programmant, et malgré les rumeurs d'IBM, les chances de le voir disparaître de si tôt sont négligeables (en particulier étant donné qu'il est open source). S'il est vrai que vous ne pouvez pas (légalement) utiliser le logiciel coûteux, il existe de nombreux logiciels que vous pouvez utiliser, y compris des logiciels qui sont encore assez utilisés.
• Encore une fois, contrairement à l’opinion publique, les ordinateurs centraux ne se résument pas à COBOL, CICS et RPG2. En effet, presque tout ce que vous pouvez exécuter sur votre PC sous Linux, vous pouvez le faire sur un ordinateur central. <ironie> Je ne sais pas pourquoi. </ ironie>

Alors, pourquoi ai-je évité les mainframes toute ma vie après les avoir rencontrés à l’école? Bien:

• S'il est vrai que vous pouvez utiliser plus que COBOL, CICS, RPG2, etc. dans les mainframes, il y a de fortes chances pour que si vous travaillez avec eux, c'est ce que vous serez forcé de faire. Pire encore, bien que COBOL ait été massivement "modernisé" au cours des deux dernières décennies environ (citations alarmistes car je ne pense toujours pas que ce soit une langue très moderne), la plupart des codes que vous ferez dans COBOL seront toujours en ancien. code de style parce que ...
• Il y a très peu de nouveaux développements en cours dans les ordinateurs centraux. Si vous trouvez un emploi chez IBM au sein de sa division de recherche et développement sur ordinateur central, vous aurez peut-être la chance de faire de nouveaux développements (et dans ce cas, vous pourrez même vraiment apprécier votre travail!). En réalité cependant, vous ne travaillerez pas là-bas. Vous travaillerez dans l'arrière-salle d'une institution financière ou d'une autre institution conservant du code COBOL vieux de 50 ans écrit par quelqu'un qui pense toujours que 64 Ko est une énorme pile'o'RAM. (Ce même gars sera probablement votre patron.)
• Il est vrai que vous pouvez exécuter Linux sur des ordinateurs centraux et avoir ainsi accès à pratiquement tous les langages de programmation ou environnements de votre choix. Encore une fois, comme pour la recherche et développement d’ordinateurs centraux d’IBM, vous n’obtiendrez pas ce travail. Nous sommes revenus au maintien de ce COBOL vieux de 50 ans.
• La programmation d'entreprise est très efficace pour vous aspirer l'âme (et souvenez-vous que c'est une programmation d'entreprise que vous allez faire en tant que programmeur mainframe, à moins d'être TRÈS chanceux).
• C'est un ghetto de plus en plus petit. (C'est comme MUMPS de cette façon.) Si vous êtes trop imprégné de la culture mainframe, vous vous éloignez de tout ce qui n'est pas mainframe. Tu peux essayersuivre, mais vous ne le ferez pas. Je sais que quelqu'un a fait remarquer que les ventes de mainframes ont augmenté, alors que les autres secteurs de serveurs ont légèrement diminué, mais la programmation de serveurs est devenue une minorité de nos jours. Les PJ Hell en général perdent de l'importance. Le monde de la programmation est très vaste et très diversifié. Il est inutile de développer une minuscule partie de celle-ci par rapport à une autre minuscule. une plate-forme minoritaire - de loin). Non, commencez à travailler dans des ordinateurs centraux et vous n’avez plus qu’à d’autres à partager vos pensées, vos joies et vos colères - et c’est une race en voie de disparition. Cela conduit à une boucle de rétroaction négative qui réduit encore plus le troupeau et le rend plus rapide.

Je suis persuadé que les programmeurs mainframe pourraient expliquer en détail les raisons pour lesquelles leur carrière est enrichissante, pleine de joies et de défis intéressants. En effet, j'en ai entendu beaucoup de gens qui essayaient de me recruter sur le terrain. À la fin, cependant, je n’ai pas été convaincu, principalement à cause du problème du ghetto. Si je suis entré et que je n'ai pas aimé, comment puis-je sortir?

J'ai 27 ans et je suis développeur professionnel depuis plus de 4 ans (j'espère donc que cela me permettra de rester jeune). Je travaille également en tant que spécialiste en intégration, ce qui me permet de mieux connaître le monde du développement des ordinateurs centraux.

1. Il semble y avoir peu ou pas d’innovation dans la communauté.
   Je sais que ce n'est pas exactement le cas, mais cela semble être le cas pour l'observateur occasionnel. Personne ne veut s'impliquer dans un domaine où il est difficile de "laisser sa marque".
2. Combien de nouveaux développements ou de nouveaux projets sont en cours?
   Aucun pour autant que je sache. Si vous allez dans ce domaine, vous vous condamnez à être un programmeur de maintenance pour toujours.
3. Il n'est pas accessible à l'apprenant occasionnel.
   La plupart des gens ont commencé par apprendre à programmer sur leur PC à la maison. Encore une fois, la plupart des gens n'aiment pas passer de ce qu'ils savent. Il faut donc du temps et de la motivation pour passer de l'un à l'autre. Compte tenu des 2 autres raisons, il n'y a pas beaucoup de preneurs.

J'aurai 40 ans en septembre, je ne sais donc pas si cela me qualifie encore comme jeune, mais je sais très bien pourquoi quelqu'un ne voudrait peut-être pas devenir programmeur mainframe.

Les 10 dernières années de ma vie professionnelle ont été consacrées à la programmation sur ordinateur central. Tout ce qu'il y a à savoir sur batch, jcl, Cobol, Assembler, Easytrieve, CICS et Web Services, et je l’apprécie énormément et le ferais encore si je ne remarquais pas une tendance. Mon dernier lieu d’emploi m’avait fait travailler côte à côte avec des développeurs Web (jsp, javascript, spring et hibernate) et j’ai remarqué que la société faisait venir des développeurs Web ayant une expérience comparable au cours des années pour beaucoup plus d’argent. Sans parler du fait que la position des développeurs Web était beaucoup moins stressante.

Après en avoir marre de cette tendance, j'ai décidé de me retirer du marché des ordinateurs centraux. Maintenant, je suis dans une position où je développe des services Web avec Java et une interface utilisateur frontale avec JavaScript. Ce type de programmation n’est pas plus difficile que ce que j’ai fait sur le mainframe, mais maintenant je gagne plus d’argent et j’ai moins mal à la tête. Je ne reçois plus cet appel à 2 heures du matin à propos de quelque chose d'abendu et les processus du système central m'attendent pour résoudre mes problèmes. Alors, donnez-moi une bonne raison pour laquelle je resterais programmeur mainframe quand je pourrai gagner plus d’argent et moins de stress dans ma vie en tant que programmeur de systèmes distribués?

Je suis sûr que dans certaines circonstances, les entreprises paient des ordinateurs centraux ainsi que des systèmes distribués, mais je ne les ai pas trouvées personnellement. J'ai également commencé à chercher des emplois selon les deux perspectives et découvert que les offres d'emploi en systèmes distribués étaient plus nombreuses que les offres pour les ordinateurs centraux. être.

D'après ce que j'ai vu jusqu'à présent et comparé à Linux et Windows, le problème de base des mainframes et des midframes est que vous DEVEZ payer d'avance pour les utiliser. Et payer beaucoup. Chaque année. Pour tout.

Ce n'est tout simplement pas le moyen de faire en sorte que les étudiants s'intéressent à quelque chose, car ils ne peuvent pas se le permettre. Si cela ne les intéresse pas, ils ne feront probablement pas carrière volontairement.

Malheureusement, le modèle commercial d’IBM ne permet pas aux étudiants d’avoir accès aux machines à moindre coût, sinon ils pourraient avoir une chance de changer cela.

L'un de mes premiers emplois d'été en tant que programmeur était principalement basé sur le nettoyage des écrans verts et des fichiers PRN. À l'époque, je n'aurais probablement pas voulu me salir les mains en COBOL (c'est-à-dire s'ils m'avaient fait suffisamment confiance en tant qu'étudiant pour me laisser entrer dans ce code), mais je ne suis pas sûr que je serais du même avis à propos du même perspective aujourd'hui.

Je ne pense pas que le problème est vraiment avec les mainframes en soi. C'est l'obsession (souvent justifiée) de notre industrie avec le nouveau et le brillant.

Regardez C. Le C est toujours une langue d’importance critique. Presque tout le code intégré et la plupart des systèmes d'exploitation sont écrits en C. Cela ne va nulle part bientôt. Et pourtant, il devient de plus en plus difficile de trouver des programmeurs C. Un rapide coup d'œil à la page de balise Stack Overflow la place à 1/6 de la taille [c#]et 1/4 de la taille de [java]. Est-ce que quelqu'un se souvient de l'époque où C était essentiellement la langue dominante, sans doute le seul jeu en ville?

Les programmeurs aiment les outils puissants. C'est peut-être parce que (SPECULATION ALERT) la plupart des programmeurs sont des gars. Vous demandez à un programmeur Java ou .NET de copier un fichier, par exemple, et la plupart sinon la plupart choisiront toujours de l'écrire en Java ou en C # au lieu d'écrire un fichier de commandes DOS ou un script shell * 50 fois plus rapide à écrire et à déployer. Pourquoi utiliser une canne et un moulinet pour attraper un poisson alors que vous avez un énorme filet rétractable pouvant attraper 500 poissons?

Oui, COBOL et PL / I sont vieux , mais Pascal aussi, et il est toujours vivant et palpitant sous la forme de Delphi. L’aversion pour les premiers tient probablement au fait que ces langues sont difficiles à manier par rapport aux outils modernes. L'orientation objet est encore un concept relativement nouveau dans le monde COBOL (accent mis sur le relatif ), mais dans le monde C #, LINQ et les génériques et AJAX ont cessé d'être révolutionnaires il y a des années. Demander à un développeur habitué à ces outils de commencer à programmer sur des ordinateurs centraux revient à demander à un musicien de rock de commencer à jouer sur un banjo.

Bien sûr, il y a aussi le problème du stéréotype qui se perpétue. Tant que les jeunes programmeurs pensent qu'il n'y a rien pour eux dans les ordinateurs centraux (que ce soit vrai ou non), tous les jeunes programmeurs qui choisiront cette solution finiront par passer le plus clair de leur temps avec des personnes beaucoup plus âgées. Les TI n’ont pas une profession très attrayante sur le plan social au départ, mais la dissipation supplémentaire d’un fossé entre générations tend à le ramener au-dessous des seuils de douleur de nombreuses personnes. Aucune infraction, cela voulait dire - j’ai personnellement passé la majeure partie de ma vie à travailler avec des gens beaucoup plus âgés, mais tout le monde n’a pas cette expérience ni cette capacité.

Enfin, la plupart des programmeurs n’apprécient pas le travail de maintenance et la quasi-totalité du travail sur le système central est la maintenance. Il n’ya pas beaucoup de nouveaux logiciels en cours d’écriture en PL / I. Tout travail défini entièrement ou en grande partie autour du code de maintenance démarre automatiquement avec un score négatif.

Il y a positifs à travailler sur le code existant ( « héritage » englobant les ordinateurs centraux et bien d' autres choses), que vous aurez probablement besoin de jouer si vous essayez d'attirer une foule plus jeune:

• Les systèmes sont, comme vous dites, une infrastructure critique. Les plus jeunes développeurs, du moins dans le monde des affaires (pas Google / Microsoft), n'ont souvent aucune chance d'avoir un impact réel . C'est décourageant de travailler sur un système qui, vous le savez, va être abandonné ou remplacé au bout de quelques mois ou quelques années. Les applications mainframe qui fonctionnent déjà depuis 50 ans vont probablement en avoir beaucoup plus car il n’a aucun sens de les reconstruire, alors le travail que vous y effectuez est important pour beaucoup de gens.

• Si vous êtes un de ces rares entreprises qui en fait n'ont une tendance à « mettre à jour », puis beaucoup de programmeurs, jeunes et vieux, seront attirés par cette occasion, car alors il y a des possibilités jumelles à travailler sur le code de mission critique et de fléchir certains de ces muscles C # / Java. Évidemment, aucune entreprise sensée ne voudrait tout simplement supprimer l’ordinateur central et la reconstruire à partir de zéro, mais j’ai déjà vu des systèmes qui (par exemple) ont un noyau COBOL qui s’intègre aux composants Java.

• Enfin, il y a le caractère indispensable - du moins, tel que nous le percevons de l'extérieur. Lorsque tout votre code est dans .NET, il y a toujours un risque que les propriétaires vous échangent contre un jeune diplômé ou pire, une équipe offshore, dans une tentative malavisée de réduire les coûts. Je ne pense pas que cela se produise très souvent dans le monde du mainframe, surtout si ce que vous dites est vrai et que l'offre semble diminuer. Bien sûr, ce point est discutable si vous ne payez pas assez bien; les salaires doivent être ajustés pour refléter cette offre en baisse, sinon les gens ne «vendront» pas.

Je suis sûr que beaucoup de jeunes développeurs ne refuseraient pas une offre assez généreuse d'une entreprise qui semblait faire tout son possible pour rendre l'environnement de travail attrayant pour les jeunes employés. Mais si vous voulez les atteindre, vous feriez bien de miser sur vos atouts et vous devrez peut-être même commencer à faire du marketing. nous avons tendance à considérer les ordinateurs centraux comme un monde très différent et très étranger, et je suis à peu près sûr que je ne vous ai pas vu au salon de l'emploi sur le campus, il y a 10 ans, qui travaillait pour changer cette perception.

Pour résumer en une seule phrase: Rien ne rend les mainframes peu attrayantes , c'est juste que rien ne les rend attrayantes non plus, et cela les désavantage sérieusement par rapport au bord saillant qui nous offre une énorme augmentation de productivité et des boissons non alcoolisées gratuites.

Je suis jeune (au milieu de la trentaine) et travaille actuellement dans le support de mainframe. RPG, COBOL, merde 4GL propriété. Le développement est lent et, dans la mesure du possible, est migré vers un matériel plus moderne utilisant des langages plus modernes.

Le développement du mainframe est tellement lourd comparé aux systèmes modernes que le mainframe lui-même a tendance à être relégué au second plan, alors que des langages plus modernes sont utilisés pour effectuer le type de reporting et de transformation des données qui était auparavant fait sur le mainframe lui-même. À ce stade, nous avons même transformé la majeure partie de la saisie de données en un processus piloté par lots. Les seuls éléments restants sur le serveur sont liés à la facturation.

Bien que cela puisse sembler être un bon créneau, je pense que de nombreuses entreprises commencent à réaliser qu’elles n’ont plus vraiment besoin de ces systèmes. Le changement se produit lentement dans le monde de la finance, mais cela se produit.

Personnellement, je ne comprends pas quel est l’avantage commercialisable des mainframes.

Rapidité du nombre et du traitement des données? Pourquoi ne puis-je pas le distribuer dans une batterie de serveurs pour le traitement ou acheter un serveur costaud "normal"?

Haute redondance et évolutivité? Je préfère avoir une batterie de serveurs Linux ou un ensemble de serveurs virtuels.

Virtualisation et systèmes d'exploitation multiples? Peut-être y a-t-il une différence de performance notable pour l’utilisation de cette stratégie au lieu d’une stratégie «cloud»?

Bien que j'aimerais beaucoup comprendre toutes ces choses plus en détail, le manque d'explications utiles sur ce qui différencie un ordinateur central est la principale raison pour laquelle je ne programme pas pour ces systèmes.

J'ai 25 ans et je suis actuellement dans un programme MSCS (mon expérience n'est pas celle de CS) et je suis définitivement intéressée par les mainframes. Le problème est que je ne sais même pas par où commencer. J'ai regardé COBOL et je ne sais pas où trouver un compilateur décent (je ne sais même pas ce qu'est un compilateur décent pour COBOL, je sais qu'il existe un compilateur à code source ouvert, mais je ne sais pas de quelle qualité il dispose). Je ne vois tout simplement pas beaucoup d'informations à ce sujet et, pour être honnête, le temps passé à chercher c'est le temps de travailler activement sur un projet en .Net ou Java (je préfère .Net mais le travail scolaire est en Java) . Comme @Joshua Smith, je crains que si je devais entrer dans les mainframes, ce serait ma vie, mais je les trouve aussi plus intéressants que les applications Web et l'engouement pour le Web 2.0 (appelez-moi fou). Pour moi cependant

En bout de ligne est la suivante:

(1) Les informations ne sont pas facilement accessibles pour que je sache ce dont j’aurais besoin pour apprendre à faire de la programmation mainframe
(2) À ce stade de ma vie, je veux juste pouvoir programmer pour vivre, et .Net et Java le permettent. Je travaille dans ce but pendant que je suis à l’école parce que je peux me tourner vers beaucoup de ressources et apprendre ce dont j’ai besoin pour sortir avec un portfolio à la fin de ma carrière universitaire
(3) Il m’aurait été difficile de rester coincé Faire quelque chose que je n'aime pas et la possibilité de me retrouver coincé à ne faire que des mainframes pour une carrière est quelque chose qui me fait peur (même si, je sais qu'il y a des façons de le contourner, comme de mettre à jour de nouvelles choses dans mon temps libre et contribuer à l'open source)

Ceci est juste mon point de vue personnel en tant que jeune programmeur. Je n'avais jamais travaillé sur un ordinateur central auparavant, je ne peux donc pas parler d'expérience de première main. Mais, c'est la chose, je n'ai jamais travaillé sur un et ne prévois pas que cela se produise de si tôt. Je ne sais pas trop où vous voulez tracer la ligne de démarcation entre l'ordinateur central et un serveur simple, mais lorsque je pense à l'ordinateur central, j'imagine une machine colossale d'IBM telle que la Z-Series 900 consommant 35 $ / jour uniquement en électricité. Je ne vais pas avoir un de ceux-là dans mon sous-sol dans peu de temps pour bricoler avec mon temps libre. Surtout quand je peux attraper une vieille machine, y installer ubuntu-server et héberger ce que je veux très facilement. Si j'ai un problème, la communauté Linux est énorme et il est probable que quelqu'un d'autre a rencontré mon problème et a posté une solution en ligne. Je ne fais que deviner,

J'ai commencé à travailler sur l'ordinateur central lorsque je suis entré sur le marché du travail il y a 10 ans. Je n'avais jamais touché un ordinateur central auparavant.

Il y avait plusieurs aspects que je n'aimais pas, alors j'ai arrêté de travailler sur l'ordinateur central dès que j'ai pu:

1. Le code d'édition était très primitif. Vous travailliez essentiellement dans un éditeur de texte, défini sur ALL CAPS et sur 80 lignes de caractères. Pas de complétion de code ou de vérification de la syntaxe.
2. La compilation a été effectuée en démarrant un travail par lots, qui a ensuite été planifié et exécuté à un moment donné, généralement dans les 5 minutes suivantes si vous avez de la chance. Si vous avez eu une faute de frappe et que le code n'a pas été compilé, répétez l'opération plusieurs fois.
3. Il n'y avait pas de débogueur d'aucune sorte. Le débogage a été effectué en imprimant les valeurs des variables et en répétant cette longue étape de compilation.
4. Les changements que nous avons apportés ont toujours été incroyablement conservateurs. Nous nous appuyions sur 20 ans de code hérité où la seule documentation était écrite à la main sur papier dans un classeur, quelque part. De plus, il s’agissait d’un code financier, il n’y avait donc aucune tolérance pour les erreurs. L’étape de codage était donc minime par rapport aux recherches préalables requises.

(OTOH, ils disposaient d'un contrôle de version et d'une promotion du code très avancés, pour la période considérée.)

Deux raisons d'envisager de rejoindre la main-d'œuvre mainframe:

1. Ça paye bien
2. Il y a des tonnes d'ouvertures

La main-d’œuvre grisonnante dans le domaine des ordinateurs centraux crée et créera un très grand nombre d’ouvertures sur le terrain.

Je travaille pour une grande société financière et au cours des cinq prochaines années, environ 30% de nos effectifs vont perdre leur retraite. Ce nombre augmentera de manière exponentielle dans 10-15 ans.

Plus de raisons:

• Je suis sur le terrain depuis plus de 25 ans et je ne me suis jamais ennuyé.
• Moins de concurrence pour les emplois.
• Arrêtez de vous plaindre de la technologie (voir certains articles ci-dessus) ... elle est peut-être ancienne, mais à bien des égards, elle est à des années-lumière des systèmes ouverts. HTML - donnez-moi une pause. C'est tellement similaire à Basic que j'ai pris il y a 30 ans à l'université. Nous sommes bien au-delà de cela.
• Le mainframe est rapide et fiable, éprouvé et vrai.
• Essayez la programmation de systèmes si vous êtes très brillant et aimez les problèmes de dépannage.
• En tant que chef d'équipe, j'aimerais pouvoir trouver de jeunes techniciens formés pour combler les ouvertures.
• Ai-je mentionné que ça paye bien?
• Autres options de carrière mainframe en plus du développement logiciel - ingénieurs en matériel, techniciens en stockage, réseaux, etc.
• C'est amusant, excitant, stimulant et la carrière a beaucoup évolué.
• Arrêtez de considérer l'ordinateur central comme une simple technologie ancienne - vérifiez-le et vérifiez tout ce que j'ai dit.

Consultez également l’initiative IBM System z Academic.

Je suis toujours un jeune programmeur (j'ai 29 ans) et je ne suis absolument pas intéressé par l'apprentissage du développement pour le mainframe. Je travaille pour une compagnie d’assurance au sein d’une équipe .NET, mais nous travaillons également avec une grande équipe de programmeurs de mainframe traditionnels.

Il y a quelques choses qui rendent le monde du mainframe peu attrayant pour moi. Il y a d'abord le COBOL. Je comprends qu'une grande partie du monde fonctionne en COBOL, mais cela ne rend pas le langage moins laid à mes yeux.

Ensuite, il y a le concept de «cycle». Je ne sais pas si cela est commun aux ordinateurs centraux ou s'il s'agit simplement de la façon dont nous procédons, mais notre ordinateur central doit exécuter un cycle de nuit avant que nous puissions en obtenir les données actuelles. La partie .NET de notre boutique est fortement impliquée dans l'envoi et le traitement des données depuis le système central (en particulier, l'affichage d'une tonne de données sur un site Web LOB interne pour les agents). L’entreprise souhaite que les données affichées aux agents soient actualisées à la minute près. Cependant, l'ordinateur central ne fonctionne pas dans le cadre de mon concept (limité) de temps réel. Nous avons mis en place des solutions de rechange insensées pour simuler sur le site Web ce que nous prévoyons être la sortie réelle de l'ordinateur central le jour suivant.

Enfin, je suis fermement convaincu que si je devenais orienté vers le développement d’ordinateurs centraux à l’heure actuelle, c’était pour qu’il domine ma carrière. Je pense que mes compétences en tant que développeur moderne tomberaient de plus en plus loin, atteignant finalement le point où la maintenance COBOL serait ma seule option. Je sais qu'il y a beaucoup d'argent à gagner, maintenant et surtout dans dix ans, mais l'argent est le quatrième ou le cinquième sur ma liste de priorités pour ma carrière. Je préférerais continuer à gagner mon salaire décent si cela signifie travailler sur des choses nouvelles et intéressantes.

Je travaille principalement avec Java, mais nous utilisons des mainframes pour notre backend, ce qui signifie que je dois beaucoup les traiter (RPG). Le plus gros problème que j'ai est le manque de documentation publique. Vous pouvez trouver la documentation SQL pour DB2 qui traduira principalement vers iSeries DB2, mais publib.boulder est horrible par rapport aux javadocs de Sun.

Une autre chose que je n'aime pas, c'est la syntaxe difficile à lire des principaux langages mainframe. RPG n'a pas le concept de portée locale, ce qui signifie que vous avez besoin d'énormes blocs de déclaration de variable. Je pense que Cobol souffre du même problème. Cela conduit également à des noms de variables sans signification et à des significations cachées. Il comporte également de nombreuses fonctions intégrées sur lesquelles j'ai du mal à me renseigner (voir ci-dessus). Cela me rappelle pourquoi je n’utilise plus BASIC pour une programmation sérieuse. Heureusement, IBM essaie de déplacer tout le monde vers Java, mais ces langages hérités ne vont pas disparaître de si tôt.

J'ai du mal à m'enthousiasmer pour apprendre à programmer dans un environnement comme celui-ci.

Ecoute, j'ai 42 ans et je ne m'intéresse pas aux ordinateurs centraux. Eh bien, qualifions cela. Je m'intéresse à l'histoire de l'informatique. J'ai quelque peu étudié les architectures de mainframe et j'ai compris, par exemple, comment les mainframes IBM ont influencé les architectures de microprocesseurs tels que le Motorola 68000 ou 80386. Dans les années 1960, les mainframes étaient déjà en train de brûler à une vitesse supérieure à 30 Mhz. des souvenirs. Pour les utilisateurs habitués à ces environnements, les premiers microprocesseurs étaient décevants à bien des égards et les architectures basées sur des microprocesseurs ont mis du temps à rattraper leurs capacités et leurs performances.

Mais rattraper ces architectures a fait, et les ordinateurs centraux ont cessé d'être "hanche" il y a longtemps. Il est arrivé que des pirates informatiques puissent installer des mini-ordinateurs sur leurs bancs et peu de temps après, des postes de travail sous Unix.

Les ordinateurs centraux sont étrangers aux jeunes programmeurs depuis le début des années 1980 - quelque chose. C’était peut-être un excellent moment pour les sociétés de grands systèmes de se poser leur propre question.

Aujourd'hui, la réponse est récursive sur plusieurs générations: les jeunes programmeurs ne s'intéressent pas aux ordinateurs centraux, car même s'ils ont des parents ou des enseignants intéressés par l'informatique, ces parents et ces enseignants (plus de 40 ans comme moi) n'étaient déjà pas intéressés à utiliser des ordinateurs centraux. il y a un siècle.

Quoi qu’il en soit, aujourd’hui, un téléphone cellulaire peut gérer les tâches pour lesquelles les ordinateurs centraux étaient utilisés il y a 30 ans! Les batteries de serveurs peu coûteux constituent le nouveau mainframe. Donc, d’une certaine manière, il ya aujourd’hui de nouveaux programmeurs mainframe, seule leur spécialité est de rassembler des machines en réseau pour créer des clouds. En un rien de temps, nous pourrions dire que Mark Zuckerberg et son gang étaient en train de faire une nouvelle sorte de programmation mainframe quand ils ont créé Facebook, en ce sens que ce n’est pas simplement une petite application fonctionnant sur un simple microprocesseur avec un disque.

À propos, l'une des dernières spécialités de l'ordinateur central était la virtualisation. Mais cela est maintenant omniprésent dans les ordinateurs de bureau / serveur. Les gens ont mal commencé au début, en utilisant des techniques logicielles. Les ordinateurs virtuels sont si utiles que les utilisateurs ne se préoccupent pas des performances. Ensuite, des entreprises comme Intel ont à nouveau examiné le mainframe et tiré deux autres leçons en prenant en charge la virtualisation matérielle pour la rendre rapide.

L'apprentissage du développement Web, de la téléphonie mobile ou du PC est plutôt facile et pas cher.

Le coût du matériel, même pour un vieux mainframe obsolète, est terriblement élevé et IBM est souvent contrarié par le projet d'émulateur Hercules (qui vous permet d'émuler System / 370, ESA / 390 et zSeries). Sans Hercules, les coûts d’entrée pour apprendre l’architecture de l’ordinateur central et le développement d’applications sont hors de portée des passionnés les plus fortunés.

Aucune université que j'ai fréquentée depuis les années 80 n'a eu de mainframe disponible pour les étudiants. Je pense qu'IBM et le reste des fantômes de l'industrie mainframe se sont tiraillés dans le pied, les rendant moins accessibles à l'apprentissage.

Commençons par quelques faits sur les ordinateurs centraux IBM et plus particulièrement zSeries.

Le matériel est flambant neuf et éclatant. Il contient certaines des conceptions électroniques et des puces les plus avancées et rapides.

Si z / OS a ses racines dans les années 1960, il a connu un développement continu et au moins deux réécritures complètes. Outre les bizarreries résultant du fétichisme d'IBM en matière de compatibilité ascendante, c'est probablement l'un des systèmes d'exploitation les plus récents d'usage général.

Les principaux arguments de vente sont les suivants: -

• La rétrocompatibilité susmentionnée s’il s’agissait d’un programme exécuté en 1976 sur une machine MVS / MVT, il est probable qu’il s’exécutera sur le dernier zSeries sans être recompilé et produira exactement les mêmes résultats.
• La bande passante permet de déplacer l'accès et de stocker des quantités énormes de données, à une vitesse énorme et à un niveau de granulométrie très fin.
• Disponibilité. SYSPLEX, disponible depuis une quinzaine d'années environ, offre une mise en cluster transparente sur plusieurs sites, avec équilibrage de la charge, basculement automatique, etc., dont une grande partie est implémentée dans le matériel. Cela donne à la plupart des * nix une apparence de clustering primitive.
• Convergence. Celui-ci sonne un peu bizarre, mais avec le support POSIX complet et une machine virtuelle ultra-rapide, un ordinateur central moderne est pratiquement indiscernable de tout autre boîtier * NIX si vous voulez l'utiliser de cette manière.

Jusqu'à présent, l'ordinateur central a survécu à presque tout ce qui, selon les experts, allait le remplacer.

Il y a un certain nombre d'inconvénients: -

• La compatibilité ascendante signifie que de nombreux magasins utilisent des systèmes de vingt, trente et parfois quarante ans. S'ils fonctionnent bien et qu'ils remplissent bien leurs fonctions (ou qu'ils ne fonctionneraient toujours pas!), Ils reflètent les styles de codage et les obsessions d'une époque révolue.
• culture arriérée. Les programmeurs travaillant dans un ghetto d'anciens systèmes COBOL ne semblent pas s'être rendu compte que le monde a évolué ou, s'ils le font, une gestion fossilisée ne les laissera pas faire.
• Manque de disponibilité. À moins d'être payé pour travailler sur l'un de ces monstres, vous ne pourrez pas y accéder. Vous pouvez même en trouver un dans lequel vous travaillez, mais si votre description de poste ne comprend pas de travail, vous ne recevrez pas de login. Beaucoup de choses ont été dites dans d'autres articles sur le logiciel d'émulation "herecules" et il est vraiment excellent, mais il est réservé aux experts. Il utilise une version ancienne du système d'exploitation, il manque la plupart des composants standard tels que CICS, COBOL et DB2 qui constituent la structure de la plupart des applications mainframe en cours d’exécution.

C'est drôle, vous devriez demander ceci. Nous venons de parler à l'Université des ordinateurs centraux, et IBM n’est pas satisfait du nombre de développeurs d’ordinateurs centraux, de sorte qu’ils mettent en œuvre un module d’ordinateur central dans notre université, nous enseignent la programmation d’ordinateurs centraux et ont accès à l’un de leurs ordinateurs centraux à distance.

En fait, je prends ce module en septembre, ce ne sera peut-être pas quelque chose que je referai, mais cela me donnera une chance de travailler sur quelque chose de «différent» et de m'ouvrir les yeux sur de nouveaux paradigmes.

J'ai 28 ans et je suis développeur professionnel depuis 10 ans. J'ai passé 3 ans à travailler sur un ordinateur central.

L'environnement était ésotérique, vicié, stagnant, déroutant (JCL et ISPF, ça vous tente?). Cela dit, j’avais énormément de respect pour le système, son fonctionnement et son ampleur. Le système avait quelque chose comme 150 M SLOC, supportait une batterie de serveurs UNIX de milieu de gamme via SOA et gérait littéralement une grande partie du pays.

Cela dit, pourquoi les jeunes programmeurs ne sont-ils pas intéressés? Voici mon point de vue, en tant que "jeune" programmeur (j'ai commencé à utiliser ce système à 23 ans). Gardez à l'esprit que voici le point de vue du système sur lequel je travaillais et des recherches que j'ai effectuées:

• Il y a peu de développement de nouveaux ordinateurs centraux. C'est en grande partie un héritage.
• Il y a d'énormes barrières à l'entrée
• Le travail effectué concerne les finances, les grandes entreprises et le gouvernement. Rien de tout cela n'est à la pointe.
• Les outils de développement sont anciens et largement obsolètes. Le débogage n'a rien à voir avec VS.

Les mainframes auront toujours une place dans l'économie. Ils ne dirigent tout simplement pas les premières entreprises en raison de leurs coûts énormes et de leurs besoins en assistance.

Bien que je pense qu’il existe probablement un travail très intéressant dans les ordinateurs centraux, je serais terrifié d’avancer ma carrière dans cette direction. Il y a beaucoup trop de chances que 10 ans plus tard, mon expérience soit devenue inutile et qu'il n'y ait plus de travail disponible pour un programmeur mainframe. Je ne veux pas me rendre obsolète en passant beaucoup de temps dans une technologie stagnante avec une base d'installation réduite.

La réponse est qu'il n'y a pas d'avenir. J'ai vingt-deux ans d'expérience en tant que programmeur mainframe et je suis au chômage depuis cinq ans. Je retourne à l'école pour obtenir mon baccalauréat en développement web. Pourquoi une personne sensée voudrait-elle être un programmeur COBOL sur ordinateur central?

Ken