Pourquoi les jeunes programmeurs ne sont-ils pas intéressés par les mainframes?
Un problème clé des mainframes est que la cohorte de programmeurs de soutien diminue. Bien que ce ne soit normalement pas un problème dans la mesure où une baisse de l'offre de programmeurs serait compensée par une augmentation du salaire entraînant 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 vraiment pour mainframes.
Bien qu'ils forment toujours une infrastructure critique pour de nombreuses entreprises, le simple fait est qu'il n'y a pas un nombre suffisant de jeunes programmeurs qui viennent pour maintenir la population de soutien peuplée.
Pourquoi est-ce? Qu'est-ce qui rend les mainframes peu attrayants pour les jeunes programmeurs?
Je suis un ancien programmeur et je ne suis pas intéressé par les mainframes. Mes raisons seront probablement similaires aux raisons avancées par les jeunes programmeurs, bien que sans l'ignorance de la technologie si évidente dans beaucoup de ces réponses.
Tout d'abord, débarrassons-nous de l'ignorance:
- Les différentes allégations d'incapacité à essayer les mainframes sont fausses. Hercules est disponible depuis 1999 - probablement depuis plus longtemps que la plupart des personnes qui répondent ont programmé - et malgré les excès d'IBM, les chances qu'il s'en aille de sitôt sont négligeables (surtout étant donné qu'il est open source ). Bien qu'il soit en fait vrai que vous ne pouvez pas (légalement) exécuter le logiciel coûteux pour cela, il y a beaucoup de logiciels disponibles que vous pouvez exécuter dessus , y compris les logiciels qui sont en fait encore assez utilisés sur le marché.
- Encore une fois, contrairement à l'opinion publique, il y a plus dans les mainframes que COBOL, CICS et RPG2. En effet, presque (mais pas tout à fait) tout ce que vous pouvez exécuter sur votre PC sous Linux, vous pouvez l'exécuter sur un ordinateur central. <irony> Je ne sais pas pourquoi. </irony>
Alors pourquoi ai-je évité les mainframes toute ma vie après les avoir rencontrés à l'école? Bien:
- Bien qu'il soit vrai que vous pouvez utiliser plus que COBOL, CICS, RPG2, etc. dans les mainframes, les chances sont très élevées que si vous travaillez avec eux, c'est ce que vous serez relégué à faire . Pire encore, bien que COBOL ait été massivement "modernisé" au cours des deux dernières décennies (citations effrayantes parce que je ne pense toujours pas que ce soit un langage très moderne), la plupart du codage que vous ferez en COBOL sera toujours en ancien -style code parce que ...
- Il y a très peu de nouveaux développements en cours dans les mainframes. Si vous décrochez un poste chez IBM en travaillant pour leur division R&D mainframe, vous pourriez avoir la chance de faire de nouveaux développements (et dans ce cas, vous pourriez même vraiment apprécier votre travail!). Mais en réalité, avouons-le: vous n'y travaillerez pas. Vous travaillerez dans l'arrière-boutique d'une institution financière ou d'une autre société qui maintient un code COBOL vieux de 50 ans écrit par quelqu'un qui pense toujours que 64 Ko est un énorme tas'o'RAM. (Ce même gars sera probablement votre patron.)
- Bien qu'il soit vrai que vous pouvez exécuter Linux sur des mainframes, et ainsi avoir accès à à peu près n'importe quel langage de programmation ou environnement que vous souhaitez, encore une fois, comme pour travailler pour la R&D de mainframe d'IBM, vous n'obtiendrez pas ce travail. C'est de retour au maintien de ce COBOL vieux de 50 ans.
- La programmation d'entreprise est très efficace pour aspirer l'âme de vous (et rappelez-vous, c'est la programmation d'entreprise que vous allez faire en tant que programmeur mainframe, sauf si vous êtes TRÈS chanceux).
- C'est un ghetto, et toujours plus petit. (C'est comme OREILLONS de cette façon.) Si vous êtes trop imprégné de la tradition du mainframe, vous vous éloignez davantage de tout ce qui n'est pas du mainframe. Vous pouvez essayer de suivre, mais vous ne le ferez pas. Je sais que quelqu'un a souligné que les ordinateurs centraux ont augmenté dans les ventes tandis que les autres secteurs de serveurs ont un peu diminué, mais la programmation de serveurs est la minorité de nos jours. Les PC infernaux en général perdent de leur importance. Le monde de la programmation est très large et très diversifié et une partie minuscule de celle-ci croît par rapport à une autre partie minuscule n'a aucun sens par rapport, disons, à la croissance soudaine et explosive de la programmation dans quelque chose d'aussi trivial que l'iPhone (qui lui-même est une plate-forme minoritaire - de loin). Non, commencez à travailler dans les mainframes et vous n'aurez que d'autres mainframers pour partager vos pensées, vos joies et vos colères - et ils sont une race mourante. Cela conduit à une boucle de rétroaction négative qui fait que le troupeau se rétrécit encore plus et plus rapidement.
Je suis sûr qu'il y a beaucoup de raisons pour lesquelles un programmeur mainframe pourrait expliquer pourquoi la carrière est enrichissante et 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. En fin de compte, cependant, je ne suis pas resté convaincu, principalement à cause du problème du ghetto. Si je suis entré et que je ne l'ai pas aimé, comment en sortir?
J'ai 27 ans et je suis développeur professionnel depuis plus de 4 ans (j'espère donc que cela me qualifie encore jeune). Je travaille également en tant que spécialiste de l'intégration, donc je reçois beaucoup d'exposition au monde du développement mainframe.
- Il semble qu'il y ait peu ou pas d'innovation en cours dans la communauté.
Je sais que ce n'est pas exactement le cas, mais pour l'observateur occasionnel, il semble que ce soit le cas. Personne ne veut s'impliquer dans un domaine où il est difficile de "laisser sa marque". - Combien de nouveaux développements ou de nouveaux projets se produisent?
Aucune pour autant que je sache. Si vous allez dans ce domaine, vous vous condamnez à être un programmeur de maintenance pour toujours. - Il n'est pas accessible à l'apprenant occasionnel.
La plupart des gens ont commencé à apprendre à programmer sur leur PC à la maison. Encore une fois, la plupart des gens n'aiment pas passer de ce qu'ils savent. Faire la transition de l'un à l'autre demande donc du temps et de la motivation. Compte tenu des 2 autres raisons, il n'y a pas beaucoup de preneurs.
Je vais avoir 40 ans en septembre, donc je ne sais pas si cela me qualifie plus en tant que jeune, mais j'ai une connaissance personnelle de première main des raisons pour lesquelles quelqu'un pourrait ne pas vouloir être programmeur mainframe.
Les 10 dernières années de ma vie professionnelle ont été consacrées à la programmation mainframe. Apprendre tout ce qu'il y a à savoir sur batch, jcl, Cobol, Assembler, Easytrieve, CICS et les services Web et je l'ai beaucoup apprécié et je le ferais encore si je n'avais pas remarqué une tendance. Mon dernier lieu de travail 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 avec des années d'expérience comparables 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 quitter le marché du mainframe. Maintenant, je suis dans une position où je développe des services Web avec Java et l'interface utilisateur frontale avec javascript. Ce style de programmation n'est pas plus difficile que ce que je faisais 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 que quelque chose s'est arrêté et que 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 peux gagner plus d'argent et avoir moins de stress dans ma vie de programmeur de systèmes distribués?
Je suis sûr qu'il y a des circonstances où les entreprises paient les mainframers ainsi que les systèmes distribués, mais je ne les ai personnellement pas trouvés. De plus, j'ai commencé à faire des recherches d'emploi des deux points de vue et j'ai découvert que les listes d'emplois des systèmes distribués étaient plus nombreuses que les listes d'emplois du mainframe au moins 10 à 1. Cela me dit qu'à l'heure actuelle pour moi d'avoir de meilleures opportunités d'emploi, le mainframe n'est pas l'endroit idéal pour être.
D'après ce que j'ai vu jusqu'à présent, et par rapport à Linux et Windows, le problème de base avec les mainframes et les midframes est que vous DEVEZ payer à l'avance pour les utiliser. Et payez beaucoup. Chaque année. Pour tout.
Ce n'est tout simplement pas la façon d'intéresser les étudiants à quelque chose, car ils ne peuvent pas se le permettre. Si cela ne les intéresse pas, ils n'en feront probablement pas volontairement carrière.
Malheureusement, le modèle commercial d'IBM ne permet pas de rendre les machines disponibles à moindre coût aux étudiants, ou ils pourraient avoir une chance de changer cela.
Un de mes premiers emplois d'été en tant que programmeur était principalement basé sur le raclage des écrans verts et des fichiers PRN. À l'époque, cela ne me dérangerait probablement pas de me salir les mains dans COBOL (c'est-à-dire s'ils m'avait suffisamment fait confiance en tant qu'étudiant pour me laisser entrer dans ce code), mais je ne sais pas si je ressentirais la même chose pour la même perspective aujourd'hui.
Je ne pense pas que le problème soit vraiment avec les mainframes en soi. C'est l'obsession (souvent justifiée) de notre industrie pour le nouveau et le brillant.
Regardez C. C est toujours évidemment un langage extrêmement important. Presque tout le code embarqué et la plupart des systèmes d'exploitation sont écrits en C. Cela ne va nulle part de sitôt. Et pourtant, il devient plus difficile de trouver des programmeurs C. Un coup d'œil rapide à la page de balise Stack Overflow la place à 1/6 de la taille de [c#] et 1/4 de la taille de [Java]. Est-ce que quelqu'un se souvient quand 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 (ALERTE DE SPECULATION) la plupart des programmeurs sont des gars. Vous donnez à un Java ou un programmeur .NET la tâche, par exemple, de copier un fichier, et beaucoup sinon la plupart choisiront toujours de l'écrire en Java ou C # au lieu d'écrire un fichier batch DOS ou un script Shell * nix qui serait 50 fois plus rapide à écrire et à déployer. Pourquoi utiliser une canne et une bobine pour attraper un poisson quand vous avez un gigantesque filet rétractable qui peut attraper 500 poissons?
Oui, COBOL et PL/I sont anciens , mais Pascal aussi, et il est toujours vivant et dynamique sous la forme de Delphi. L'aversion pour les premiers provient probablement du fait que ces langues sont peu maniables par rapport aux outils modernes. L'orientation objet est encore un concept relativement nouveau dans le monde COBOL (accent sur relativement ), mais dans le monde C #, LINQ et génériques et AJAX a cessé d'être révolutionnaire il y a des années. Demander à un développeur habitué à ces outils de commencer à programmer sur des mainframes, c'est comme 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 auto-entretenu. Tant que les jeunes programmeurs croient qu'il n'y a rien pour eux dans les mainframes (que ce soit vrai ou non), alors les jeunes programmeurs qui faire choisir d'y aller finira par passer la plupart de ses journées avec des gens beaucoup plus âgés. Les TI ne sont pas beaucoup d'une profession socialement attrayante pour commencer, mais la dissuasion supplémentaire d'un écart de génération a tendance à la ramener en dessous de beaucoup de seuils de douleur. Aucune infraction ne signifiait - 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 formation ou cette capacité.
Enfin, la plupart des programmeurs n'apprécient pas les travaux de maintenance, et la quasi-totalité du travail mainframe est la maintenance. Il n'y a pas beaucoup de nouveaux logiciels écrits en PL/I. Tout travail défini entièrement ou largement autour du code de maintenance démarre automatiquement avec un score négatif.
Il y a points positifs à travailler sur le code hérité ("hérité" englobant les mainframes et bien d'autres choses), que vous devrez probablement jouer si vous ' re essayant d'attirer une foule plus jeune:
Comme vous le dites, les systèmes sont des infrastructures essentielles. Les jeunes développeurs, du moins dans le monde des affaires (pas Google/Microsoft), n'ont souvent pas la possibilité 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é après quelques mois ou années. Les applications mainframe qui fonctionnent déjà depuis 50 ans vont probablement durer beaucoup plus longtemps car cela n'a aucun sens pour les entreprises de les reconstruire, donc le travail que vous y faites est réellement important à beaucoup de gens.
Si vous êtes l'une de ces rares sociétés qui ont une tendance à "mettre à niveau", alors beaucoup de programmeurs, jeunes et vieux, seront attiré par cette opportunité, car il y a alors deux possibilités de travailler sur du code essentiel à la mission et pour fléchir certains de ces muscles C #/Java. De toute évidence, aucune entreprise sensée ne ferait que supprimer le mainframe et reconstruire à partir de zéro, mais j'ai vu des systèmes qui (par exemple) ont un noyau COBOL qui s'intègre avec Java composants.
Enfin, il y a le caractère indispensable - du moins, comme nous le voyons de l'extérieur. Lorsque tout votre code est en .NET, il y a toujours le risque que les propriétaires vous échangent contre un diplômé fraîchement sorti du collège 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 l'offre semble diminuer. Bien sûr, ce point est sans objet si vous ne payez pas assez bien; les salaires doivent être ajustés pour refléter cette diminution de l'offre, sinon les gens ne "vendront" pas.
Je suis sûr qu'il y a beaucoup de jeunes développeurs qui ne refuseraient pas une offre raisonnablement 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, il serait sage de jouer sur vos forces et vous devrez peut-être même commencer à faire du marketing; nous avons tendance à considérer les mainframes comme un monde différent et très étranger, et je suis presque sûr que je ne vous ai pas vu au salon de l'emploi du campus il y a 10 ans travailler à changer cette perception.
Pour résumer en une seule phrase: rien ne rend les mainframes peu attrayants , c'est juste que rien ne les rend attrayants non plus, et cela les désavantage sérieusement par rapport au Edge qui saigne qui nous offre d'énormes gains de productivité et des boissons sans alcool gratuites.
Je suis jeune (milieu des années 30) et travaille actuellement dans le support mainframe. RPG, COBOL, merde 4GL propriétaire. 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 de mainframe est si lourd par rapport aux systèmes modernes que le mainframe lui-même a tendance à être relégué au back-end, tandis que des langages plus modernes sont utilisés pour effectuer les types de rapports et de transformations de données qui étaient auparavant effectués sur le mainframe lui-même. À ce stade, nous avons même transformé la plupart des entrées de données en un processus piloté par lots, de sorte que les seules choses qui restent sur le serveur sont liées à la facturation.
Bien que cela puisse sembler un bon créneau pour se lancer, je pense que de nombreuses entreprises se rendent compte qu'elles n'ont plus vraiment besoin ces systèmes. Le changement se produit lentement dans le monde de la finance, mais il se produit.
Personnellement, je ne comprends pas quel est l'avantage commercialisable des mainframes.
Compilation rapide des nombres et des données? Pourquoi ne puis-je pas le distribuer dans une batterie de serveurs pour le traitement, ou acheter un serveur "normal" costaud.
Redondance et évolutivité élevées? Je préfère avoir une batterie de serveurs Linux ou un ensemble de serveurs virtuels.
Virtualisation et OS multiples? Peut-être y a-t-il une différence de performances importante pour utiliser cela au lieu d'une stratégie "cloud"?
Bien que j'aimerais 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 CS) et je suis vraiment intéressé 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 open-source, mais je ne suis pas sûr de sa qualité). Je ne vois juste pas beaucoup d'informations pour cela et pour être honnête, le temps passé à chercher c'est du temps que je pourrais 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éressantes que les applications Web et tout l'engouement pour le Web 2.0 (appelez Pour moi, cependant, il serait beaucoup plus facile d'apprendre Java puis de m'attacher à SAP, car je sais que cela peut aussi avoir beaucoup d'emplois.
La conclusion est la suivante:
(1) Les informations ne sont pas facilement disponibles pour moi pour savoir ce que j'aurais besoin d'apprendre pour faire de la programmation mainframe
(2) À ce stade de ma vie, je veux juste pouvoir programmer pour vivre et .Net et Java me permet de travailler vers cet objectif pendant mes études) car il y a beaucoup de ressources vers lesquelles je peux me tourner et apprendre ce dont j'ai besoin pour repartir avec un portfolio à la fin de ma carrière universitaire
(3) Il serait difficile pour moi de rester coincé à faire quelque chose que je n'aime pas et la possibilité de rester bloqué uniquement sur les mainframes pour une carrière est quelque chose qui me fait peur (même si je sais que il y a des moyens de contourner cela, comme rafraîchir de nouvelles choses pendant mon temps libre et contribuer à l'open source)
Deux raisons d'envisager de rejoindre la main-d'œuvre mainframe:
- Ça paie bien
- Il y a des tonnes d'ouvertures
La main-d'œuvre grisonnante dans le domaine du mainframe crée et créera n grand nombre d'ouvertures sur le terrain.
Je travaille pour une grande société financière et, au cours des 5 prochaines années, nous perdrons environ 30% de nos effectifs à la retraite. Ce nombre augmentera de façon exponentielle dans 10 à 15 ans.
Plus de raisons:
- Je suis dans le domaine 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 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 suivi il y a 30 ans au collège. Nous sommes bien au-delà de cela.
- Le mainframe est rapide et fiable, a fait ses preuves.
- Essayez la programmation des systèmes si vous êtes très brillant et que vous aimez le dépannage.
- En tant que chef d'équipe, j'aimerais pouvoir trouver de jeunes techniciens formés pour combler les postes vacants.
- Ai-je mentionné que cela payait bien?
- Autres options de carrière mainframe en plus du développement de logiciels - ingénieurs matériels, technologies de stockage, réseaux, etc.
- C'est amusant, excitant, stimulant et il y a une grande croissance de carrière.
- Arrêtez de considérer le mainframe comme une simple technologie - vérifiez-le et vérifiez tout ce que j'ai dit.
Consultez également l'initiative System z Academic d'IBM.
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 faire du travail mainframe dès que possible:
- L'édition du code était très primitive. Vous travailliez simplement dans un éditeur de texte, fixé sur TOUTES MAJUSCULES et 80 lignes de caractères. Aucune complétion de code ni vérification de syntaxe.
- 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 eu de la chance. Si vous avez eu une faute de frappe et que le code n'a pas été compilé, répétez plusieurs fois.
- Il n'y avait aucun 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.
- 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 manuscrite sur papier dans un classeur, quelque part. De plus, il s'agissait d'un code financier, il n'y avait donc aucune tolérance aux erreurs. Ainsi, l'étape de codage réelle était minime par rapport à la recherche qui était requise au préalable.
(OTOH, ils avaient un contrôle de version et une promotion de code très avancés pour la période.)
Ceci est juste mon point de vue personnel en tant que jeune programmeur. Je n'ai jamais travaillé sur un ordinateur central auparavant, donc je ne peux pas parler d'expérience de première main sur un seul. Mais c'est le truc, je n'ai jamais travaillé dessus et je ne prévois pas que cela se produise de si tôt. Je ne sais pas où vous voulez tracer la ligne entre le mainframe et un simple serveur, mais quand je pense au mainframe, j'imagine une machine IBM géante comme la Z-Series 900 rongeant 35 $/jour juste en électricité. Je ne vais pas en avoir un dans mon sous-sol de sitôt pour bricoler pendant mon temps libre. Surtout quand je peux récupérer une vieille machine, y lancer ubuntu-server et héberger tout ce que je ressens très facilement. Si j'ai un problème, la communauté Linux est énorme et il y a de fortes chances que quelqu'un d'autre ait rencontré mon problème et mis en ligne une solution. Je ne fais que deviner, mais je ne m'attendrais pas à voir ce niveau d'informations disponibles pour les problèmes de mainframe en ligne.
Ecoutez, j'ai 42 ans et je ne suis pas intéressé par les mainframes. Eh bien, qualifions cela. Je m'intéresse à l'histoire de l'informatique. J'ai étudié les architectures mainframe dans une certaine mesure, et je comprends comment, par exemple, les mainframes IBM ont influencé les architectures de microprocesseurs telles que le Motorola 68000 ou 80386. Dans les années 60, les mainframes flamboyaient déjà à des vitesses dépassant 30 Mhz, et arboraient des systèmes d'exploitation multitâches avancés avec virtual souvenirs. Pour les personnes habituées à ces environnements, les premiers microprocesseurs étaient décevants à bien des égards, et il a fallu un certain temps aux architectures basées sur microprocesseur pour rattraper des capacités et des performances similaires.
Mais ces architectures l'ont rattrapé, et les mainframes ont cessé d'être "branchés" depuis longtemps. Cela s'est produit lorsque des pirates ont pu mettre des mini-ordinateurs sur leurs bancs et peu de temps après, les postes de travail fonctionnant sous Unix.
Les mainframes sont étrangers aux jeunes programmeurs depuis le début des années 80. Cela aurait pu être un excellent moment pour les entreprises mainframe de se poser votre question.
Aujourd'hui, la réponse est récursive d'une génération à l'autre: les jeunes programmeurs ne sont pas intéressés par les mainframes parce que même s'ils ont des parents ou des enseignants intéressés par l'informatique, ces parents et enseignants (plus de 40 geezers comme moi) n'étaient déjà pas intéressés à faire quoi que ce soit avec des mainframes par trimestre. il y a un siècle.
Quoi qu'il en soit, aujourd'hui, un téléphone portable peut gérer les tâches que les mainframes étaient utilisées il y a 30 ans! Les fermes de boîtiers de serveurs bon marché sont le nouveau mainframe. Donc, d'une certaine manière, il y a de nouveaux programmeurs mainframe aujourd'hui, seule leur spécialité est de rassembler des machines en réseau pour construire des clouds. En résumé, nous pourrions dire que Mark Zuckerberg et son gang faisaient un nouveau type de programmation mainframe lorsqu'ils ont produit Facebook, dans le sens où ce n'est pas seulement une petite application qui s'exécute simplement sur un simple microprocesseur avec un disque.
Soit dit en passant, l'une des dernières spécialités du mainframe était la virtualisation. Mais c'est désormais omniprésent dans les ordinateurs de bureau/serveurs. Les gens ont commencé à mal le faire au début, en utilisant des techniques logicielles. Les machines virtuelles étaient si utiles que les utilisateurs ne se souciaient pas de la baisse des performances. Ensuite, des entreprises comme Intel ont réexaminé le mainframe et ont tiré quelques leçons supplémentaires en prenant en charge la virtualisation dans le matériel pour le rendre rapide.
Je suis encore un jeune programmeur (j'ai 29 ans) et je ne suis vraiment pas intéressé à apprendre à développer 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 mainframe à l'ancienne.
Il y a quelques choses qui rendent le monde mainframe peu attrayant pour moi. Tout d'abord, il y a COBOL. Je comprends qu'une grande partie du monde fonctionne avec 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 si c'est simplement la façon dont nous faisons les choses, mais notre ordinateur central doit exécuter un cycle de nuit avant de pouvoir obtenir des données actuelles. Le côté .NET de notre boutique est fortement impliqué dans l'envoi et le traitement des données du mainframe (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 pour les agents soient à jour à la minute près. Cependant, le mainframe ne fonctionne pas dans mon concept (limité) de temps réel. Nous avons des solutions de contournement insensées en place pour simuler sur le site Web ce que nous prévoyons être la sortie réelle du mainframe le lendemain.
Enfin, je crois fermement que si je devais évoluer vers le développement mainframe à ce stade, cela finirait par dominer ma carrière. Je pense que mes compétences en tant que développeur moderne prendraient de plus en plus de retard, atteignant finalement le point où la maintenance COBOL serait ma seule option. Je sais qu'il y a de l'argent à gagner, maintenant et surtout dans dix ans, mais l'argent est quatrième ou cinquième sur ma liste de priorités pour ma carrière. Je préfère continuer à gagner un 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 gérer (RPG). Le plus gros problème que j'ai est le manque de documentation accessible au public. Vous pouvez trouver la documentation SQL pour DB2 qui se traduira principalement par iSeries DB2, mais publib.boulder est horrible par rapport aux javadocs Sun.
Une autre chose que je n'aime pas 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 variables. 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 a également de nombreuses fonctions intégrées différentes que j'ai du mal à découvrir (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 disparaîtront pas de sitôt.
J'ai du mal à m'exciter d'apprendre à programmer dans un environnement comme celui-ci.
Apprendre le développement web, téléphone mobile ou PC est plutôt bon marché et facile.
Les coûts matériels, même pour un vieux mainframe battu, sont terriblement élevés, et IBM se fâche souvent à propos du projet d'émulateur Hercules (qui vous permet d'émuler System/370, ESA/390 et zSeries). Sans Hercules, cela rend les coûts d'entrée pour apprendre l'architecture mainframe et le développement d'applications hors de portée de tous les amateurs, sauf les plus riches.
Aucune université que j'ai fréquentée depuis les années 80 ne disposait d'un ordinateur central pour les étudiants. Je pense qu'IBM et le reste des fantômes de l'industrie mainframe se sont tirés une balle dans le pied les rendant moins accessibles à l'apprentissage.
Commençons par quelques faits concernant les mainframes IBM et en particulier zSeries.
Le matériel est flambant neuf et flambant neuf. Il contient certaines des conceptions électroniques et de puces les plus avancées disponibles et elles sont rapides.
Bien que z/OS ait ses racines dans les années 1960, il a subi un développement continu et au moins deux réécritures complètes, à part les caprices résultant du fétiche d'IBM pour la compatibilité descendante, c'est probablement l'un des OS les plus récents à usage général.
Les principaux arguments de vente sont: -
- La rétrocompatibilité susmentionnée si un programme s'exécutait en 1976 sur une machine MVS/MVT, il est probable qu'il s'exécute sur les dernières zSeries sans être recompilé et produise exactement les mêmes résultats.
- Bande passante, il peut déplacer l'accès et stocker des quantités massives de données, à une vitesse massive et à un niveau très fin.
- Disponibilité. SYSPLEX, disponible depuis environ 15 ans, fournit un clustering transparent sur plusieurs sites, avec équilibrage de charge, basculement automatique, etc., dont une grande partie est implémentée dans le matériel. Cela rend la plupart des clusters * nix plus primitifs.
- Convergence. Celui-ci semble un peu bizarre, mais avec un support POSIX complet et une JVM ultra-rapide, un mainframe moderne est pratiquement indiscernable de toute autre boîte * NIX si c'est comme ça que vous voulez l'utiliser.
Jusqu'à présent, l'ordinateur central a survécu à presque tout ce que les experts ont dit qu'il allait le remplacer.
Il y a plusieurs inconvénients: -
- La compatibilité descendante signifie que de nombreux magasins utilisent des systèmes vieux de vingt, trente et dans certains cas de quarante ans. Bien qu'ils fonctionnent bien et remplissent bien leurs fonctions commerciales (ou qu'ils ne fonctionneraient pas encore!), 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 avoir réalisé que le monde a évolué, ou s'ils font une gestion fossilisée, ils ne le laisseront pas.
- Manque de disponibilité. À moins que vous ne soyez réellement payé pour travailler sur l'un de ces monstres, vous n'en aurez pas accès. Il peut même y en avoir un où vous travaillez, mais si votre description de travail immédiate ne comprend pas de travail, vous n'obtiendrez pas de connexion. Beaucoup de choses ont été dites dans d'autres publications sur le logiciel d'émulation "herecules" et il est en effet excellent, mais il est réservé aux experts, il exécute une ancienne version du système d'exploitation, il lui manque la plupart des composants standard tels que CICS, COBOL et DB2 qui constitue le cadre de la plupart des applications mainframe en cours d'exécution.
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, périmé, stagnant, déroutant (JCL et ISPF n'importe qui?). Cela dit, j'avais énormément de respect pour le système, son fonctionnement, son ampleur. Le système avait quelque chose comme 150M SLOC, supportait une batterie milieu de gamme de serveurs UNIX via SOA et exploitait 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é sur ce système à l'âge de 23 ans). Gardez à l'esprit que c'est ma perspective du système sur lequel je travaillais et des recherches que j'ai faites:
- Il y a peu de nouveaux développements mainframe. Beaucoup est hérité.
- Il y a d'énormes barrières à l'entrée
- Le travail effectué concerne les services financiers, les grandes entreprises et le gouvernement. Rien de tout cela ne saigne Edge.
- Les outils de développement sont anciens et largement dépassés. Le débogage n'a rien à voir avec VS.
Les ordinateurs centraux auront toujours une place dans l'économie. Ils ne dirigent tout simplement pas les premières entreprises en raison de leurs énormes coûts et de leurs besoins d'assistance.
Drôle, vous devriez demander cela. Nous venons d'avoir une conférence à l'Université sur les mainframes, et IBM est mécontent du niveau des développeurs Mainframe, de sorte qu'ils implémentent un module mainframe dans notre Université, nous enseignent la programmation mainframe et ont accès à l'un de leurs mainframes à distance.
En fait, je prends ce module en septembre, ce n'est peut-être pas quelque chose que je ferai à nouveau, mais cela me donnera la chance de travailler sur quelque chose de "différent" et d'ouvrir mes yeux sur de nouveaux paradigmes.
Cette 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 mainframe?
Ken
Bien que je pense qu'il y a probablement un travail très intéressant dans les mainframes, je serais terrifié à l'idée de faire 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 il n'y a pas 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 en diminution.