Perché i giovani programmatori non sono interessati ai mainframe? [chiuso]

Un problema chiave con i mainframe è che la coorte di supportare i programmatori sta diminuendo. Mentre normalmente questo non sarebbe un problema in quanto un calo dell'offerta di programmatori sarebbe compensato da una quantità crescente di stipendio che causa un aumento dell'offerta di programmatori attraverso la legge della domanda e dell'offerta, non sono sicuro che questo stia realmente accadendo per mainframe.

Mentre formano ancora un'infrastruttura critica per molte aziende, il semplice fatto è che non esiste un numero adeguato di giovani programmatori che si avvicinano per mantenere popolata la popolazione di supporto.

Perchè è questo? Cosa rende i mainframe poco attraenti per i giovani programmatori?

Sono un vecchio programmatore e non mi interessano i mainframe. Le mie ragioni saranno probabilmente simili a quelle fornite dai giovani programmatori, anche se senza l'ignoranza della tecnologia così evidente in molte di queste risposte.

Innanzitutto, allontaniamo l'ignoranza:

• Le varie affermazioni sull'impossibilità di provare i mainframe sono false. Hercules è disponibile dal 1999 - probabilmente da più tempo di molte delle persone che hanno risposto hanno programmato - e nonostante l'IBM si lamenta di esso, le probabilità che scompaiano in qualsiasi momento presto sono trascurabili (soprattutto dato che è open source). Sebbene sia vero che non è possibile (legalmente) eseguire il software costoso per esso, è disponibile un sacco di software che è possibile eseguire su di esso, incluso il software che è ancora in uso abbastanza comune là fuori.
• Ancora una volta, contrariamente all'opinione pubblica, nei mainframe c'è molto di più di COBOL, CICS e RPG2. In effetti quasi (ma non del tutto) tutto ciò che puoi eseguire sul tuo PC con Linux puoi eseguire su un mainframe. <irony> Non sono sicuro del perché. </ ironia>

Allora perché ho evitato i mainframe per tutta la vita dopo averli incontrati a scuola? Bene:

• Mentre è vero che puoi usare più di COBOL, CICS, RPG2, ecc. Nei mainframe, le probabilità sono molto alte che se lavori con loro questo è ciò che verrai relegato a fare. Ancora peggio, nonostante COBOL sia stato massicciamente "modernizzato" negli ultimi due decenni circa (citazioni spaventose perché non penso ancora che sia un linguaggio molto moderno), la maggior parte della codifica che farai in COBOL sarà ancora in vecchio in stile codice perché ...
• Ci sono pochissimi nuovi sviluppi in corso nei mainframe. Se ottieni un lavoro presso IBM che lavora per la divisione R&D del mainframe, potresti avere la possibilità di fare un nuovo sviluppo (e in tal caso potresti persino goderti il ​​tuo lavoro!). In realtà, però, affrontalo: non lavorerai lì. Lavorerai nella stanza sul retro di qualche istituto finanziario o altro mantenendo il codice COBOL di 50 anni scritto da qualcuno che pensa ancora che 64 KB sia un enorme mucchio di RAM. (Questo stesso ragazzo sarà probabilmente il tuo capo.)
• Anche se è vero che puoi eseguire Linux su mainframe e quindi avere accesso a praticamente qualsiasi linguaggio di programmazione o ambiente che desideri, di nuovo, come nel caso della ricerca e sviluppo di mainframe IBM, non otterrai quel lavoro. È tornato a mantenere quel COBOL di 50 anni.
• La programmazione aziendale è molto efficace nel risucchiarti dall'anima (e ricorda, è la programmazione aziendale che farai come programmatore di mainframe a meno che tu non sia MOLTO fortunato).
• È un ghetto e sempre più piccolo. (È come MUMPS in questo modo.) Se diventi troppo intriso della tradizione dei mainframe, ti allontani ulteriormente da qualsiasi cosa non sia mainframe. Puoi provareper tenere il passo, ma non lo farai. So che qualcuno ha sottolineato che i mainframe sono cresciuti nelle vendite mentre altri settori di server si sono leggermente ridotti, ma la programmazione dei server è la minoranza in questi giorni. I PC infernali in generale stanno perdendo importanza. Il mondo della programmazione è molto ampio e diversificato e avere una porzione minuscola di essa rispetto a un'altra porzione minuscola non ha senso se paragonato, per esempio, alla crescita improvvisa ed esplosiva della programmazione in qualcosa di banale come l'iPhone (che a sua volta è una piattaforma di minoranza - di gran lunga). No, inizia a lavorare nei mainframe e avrai solo altri mainframer con cui condividere i tuoi pensieri, le tue gioie e le tue rabbia - e sono una razza morente. Questo porta ad un circuito di feedback negativo che rende la mandria ancora più piccola e più veloce.

Sono sicuro che ci sono molte ragioni per cui un programmatore di mainframe potrebbe spiegare perché la carriera è gratificante e piena di gioie e sfide interessanti. In effetti ne ho ascoltati molti da persone che cercavano di reclutarmi sul campo. Alla fine, tuttavia, sono rimasto non convinto, soprattutto a causa del problema del ghetto. Se sono entrato e ho scoperto che non mi piaceva, come posso uscire?

Ho 27 anni e sono uno sviluppatore professionista da più di 4 anni (quindi spero che mi qualifichi ancora giovane). Lavoro anche come specialista dell'integrazione, quindi sono molto esposto al mondo dello sviluppo del mainframe.

1. Sembra che ci sia poca o nessuna innovazione in corso nella comunità.
   So che non è esattamente così, ma per l'osservatore occasionale sembra di si. Nessuno vuole essere coinvolto in un'area in cui è difficile "lasciare il segno".
2. Quanti nuovi sviluppi o nuovi progetti stanno accadendo?
   Nessuno per quanto ne so. Se vai in quest'area ti condanni per sempre come programmatore di manutenzione.
3. Non è accessibile allo studente occasionale.
   Molte persone hanno iniziato a imparare a programmare sul proprio PC a casa. Ancora una volta, alla maggior parte delle persone non piace passare da ciò che sanno. Quindi fare il passaggio dall'una all'altra richiede tempo e motivazione. Date le altre 2 ragioni, non ci sono molti acquirenti.

A settembre compirò 40 anni, quindi non so più se questo mi qualifica come un giovane, ma ho una conoscenza personale di prima mano del perché qualcuno potrebbe non voler essere un programmatore di mainframe.

Gli ultimi 10 anni della mia vita lavorativa sono stati dedicati alla programmazione di mainframe. Imparando tutto ciò che c'è da sapere su batch, jcl, Cobol, Assembler, Easytrieve, CICS e Web Services, mi sono divertito immensamente e lo farei comunque se non per notare una tendenza. Il mio ultimo posto di lavoro mi ha fatto lavorare fianco a fianco con gli sviluppatori web (jsp, javascript, spring e hibernate) e ho notato che la società stava portando sviluppatori web con anni di esperienza comparabili per molti più soldi. Per non parlare del fatto che la posizione degli sviluppatori Web è stata molto meno stressante.

Dopo essermi stufato di questa tendenza, ho deciso di uscire dal business dei mainframe. Ora sono in una posizione in cui sviluppo servizi web con java e interfaccia utente front-end con javascript. Questo stile di programmazione non è più difficile di quello che ho fatto sul mainframe, ma ora guadagno più soldi e ho meno mal di testa. Alle 2:00 non ricevo più la chiamata che qualcosa è stato interrotto e i processi del sistema principale mi stanno aspettando per risolvere i miei problemi. Quindi, dammi una buona ragione per cui rimarrei programmatore di mainframe quando potrei guadagnare più soldi e avere meno stress nella mia vita di programmatore di sistemi distribuiti?

Sono sicuro che ci sono circostanze in cui le aziende pagano mainframer e sistemi distribuiti, ma personalmente non li ho trovati. Inoltre, ho iniziato a fare ricerche di lavoro da entrambe le prospettive e ho scoperto che gli elenchi di lavori dei sistemi distribuiti erano in numero superiore agli elenchi di lavori del mainframe almeno da 10 a 1. Ciò mi dice che al momento attuale per me avere migliori opportunità di lavoro il mainframe non è il posto dove essere.

Da quello che ho visto finora e rispetto a Linux e Windows, il problema di base con mainframe e midframe è che DEVI pagare in anticipo per usarli. E paga molto. Ogni anno. Per tutto.

Questo non è semplicemente il modo per rendere gli studenti interessati a qualcosa, perché non possono permetterselo. Se non li interessano, probabilmente non lo faranno volontariamente.

Sfortunatamente il modello di business di IBM non consente di rendere le macchine a buon mercato disponibili per gli studenti, o potrebbero avere la possibilità di cambiarle.

Uno dei miei primi lavori estivi come programmatore si basava principalmente sulla raschiatura di schermi verdi e file PRN. Allora probabilmente non mi sarebbe dispiaciuto sporcarmi le mani in COBOL (cioè se mi avessero abbastanza fidato di me come studente per farmi entrare in quel codice), ma non sono sicuro che mi sentirei allo stesso modo riguardo al stessa prospettiva oggi.

Non credo che il problema riguardi davvero i mainframe in sé. È l'ossessione (spesso giustificata) del nostro settore per il nuovo e brillante.

Guardare C. C è ancora ovviamente un linguaggio di fondamentale importanza. Quasi tutto il codice incorporato e la maggior parte dei sistemi operativi sono scritti in C. Non andrà da nessuna parte presto. Eppure è sempre più difficile trovare programmatori C. Un rapido sguardo alla pagina del tag Stack Overflow lo posiziona a 1/6 della dimensione di [c#]e 1/4 della dimensione di [java]. Qualcuno ricorda quando C era essenzialmente la lingua dominante, probabilmente l'unico gioco in città?

I programmatori amano strumenti potenti. Forse perché (ALLARME SPECULAZIONE) la maggior parte dei programmatori sono ragazzi. Dai a un programmatore Java o .NET il compito di, per esempio, copiare un file e molti, se non la maggior parte, sceglieranno ancora di scriverlo in Java o C # invece di scrivere un file batch DOS o uno script shell * nix che sarebbe 50 volte più veloce da scrivere e distribuire. Perché usare una canna e un mulinello per catturare un pesce quando hai una gigantesca rete retrattile che può catturare 500 pesci?

Sì, COBOL e PL / I sono vecchi , ma lo è anche Pascal, ed è ancora vivo e vegeto sotto forma di Delphi. L'avversione al primo deriva probabilmente dal fatto che quelle lingue sono ingombranti rispetto agli strumenti moderni. L'orientamento agli oggetti è ancora un concetto relativamente nuovo nel mondo COBOL (enfasi su relativamente ), ma nel mondo C #, LINQ e generici e AJAX hanno smesso di essere rivoluzionari anni fa. Chiedere a uno sviluppatore abituato a quegli strumenti di iniziare a programmare su mainframe è come chiedere a un musicista rock di iniziare a suonare su un banjo.

Naturalmente c'è anche il problema dello stereotipo che si autoalimenta. Mentre i programmatori Finché più giovani ritengono che non c'è nulla per loro nel mainframe (anche se non è vero), allora qualsiasi giovani programmatori che non scelgono di andare in esso finirà per spendere la maggior parte delle loro giornate in mezzo alla gente molto più vecchio. All'inizio l'IT non è una professione socialmente attraente, ma l'ulteriore disincentivo di un gap generazionale tende a portarlo al di sotto di molte soglie di dolore. Senza offesa, ho personalmente passato gran parte della mia vita a lavorare con persone molto più anziane, ma non tutti hanno quel background o quella capacità.

Infine, alla maggior parte dei programmatori non piace il lavoro di manutenzione e quasi tutto il lavoro del mainframe è la manutenzione. Non ci sono molti nuovi software scritti in PL / I. Qualsiasi lavoro definito interamente o in gran parte attorno al codice di manutenzione inizia automaticamente con un punteggio negativo.

Ci sono aspetti positivi nel lavorare su un codice legacy ("legacy" che comprende mainframe e molte altre cose), che probabilmente dovrai riprodurre se stai cercando di attirare un pubblico più giovane:

• I sistemi sono, come dici tu, un'infrastruttura critica. Gli sviluppatori più giovani, almeno nel mondo degli affari (non Google / Microsoft), spesso non hanno la possibilità di avere un impatto reale . È scoraggiante lavorare su un sistema che sai verrà abbandonato o sostituito dopo pochi mesi o anni. Le app mainframe che funzionano già da 50 anni probabilmente funzioneranno molto di più perché non ha senso per le aziende ricostruirle, quindi il lavoro che svolgi al loro interno è in realtà importante per molte persone.

• Se siete una di quelle poche aziende che in realtà non hanno una tendenza a "upgrade", poi un sacco di programmatori, giovani e meno giovani, saranno attratti da questa opportunità, perché poi ci sono gemelli opportunità di lavorare su codice mission-critical e per flettere alcuni di quei muscoli C # / Java. Ovviamente nessuna azienda sana avrebbe semplicemente demolito il mainframe e ricostruito da zero, ma ho visto sistemi che (per esempio) hanno un core COBOL che si integra con i componenti Java.

• Infine, c'è l'indispensabilità - almeno, come la percepiamo noi estranei. Quando tutto il tuo codice è in .NET, c'è sempre il rischio che i proprietari ti scambino per un neolaureato o peggio ancora, una squadra offshore, nel tentativo sbagliato di tagliare i costi. Non penso che ciò accada molto spesso nel mondo dei mainframe, specialmente se ciò che dici è vero e l'offerta sembra diminuire. Naturalmente, questo punto è discutibile se non paghi abbastanza bene; gli stipendi devono essere adeguati per riflettere la riduzione dell'offerta, altrimenti le persone non "venderanno".

Sono sicuro che ci sono un sacco di giovani sviluppatori là fuori che non rifiuterebbero un'offerta ragionevolmente generosa da un'azienda che sembrava fare di tutto per rendere l'ambiente di lavoro attraente per i dipendenti più giovani. Ma se vuoi raggiungerli, allora saresti saggio giocare sui tuoi punti di forza e potresti anche dover iniziare a fare un po 'di marketing; tendiamo a vedere i mainframe come un mondo diverso e molto straniero, e sono abbastanza sicuro di non aver visto voi ragazzi alla fiera del lavoro del campus 10 anni fa lavorando per cambiare quella percezione.

In poche parole: niente rende i mainframe poco attraenti , è solo che nulla li rende attraenti e ciò li mette in grave svantaggio rispetto al bordo sanguinante che ci offre enormi incrementi di produttività e bevande analcoliche gratuite.

Sono giovane (metà degli anni '30) e attualmente lavoro nel supporto di mainframe. RPG, COBOL, schifezza propietaria 4GL. Lo sviluppo è lento e, ove possibile, viene migrato su hardware più moderno utilizzando linguaggi più moderni.

Lo sviluppo del mainframe è così ingombrante rispetto ai sistemi moderni che il mainframe stesso tende a retrocedere verso il back-end, mentre linguaggi più moderni vengono utilizzati per eseguire i tipi di report e trasformazioni di dati che un tempo venivano eseguiti sul mainframe stesso. A questo punto, abbiamo persino trasformato la maggior parte della registrazione dei dati in un processo guidato in batch, quindi le uniche cose che rimangono sul server sono legate alla fatturazione.

Mentre può sembrare una buona nicchia in cui tuffarsi, penso che molte aziende stiano arrivando alla consapevolezza che non hanno più davvero bisogno di questi sistemi. Il cambiamento avviene lentamente nel mondo della finanza, ma succede.

Personalmente non capisco quale sia il vantaggio commerciabile per i mainframe.

Crunching rapido di numeri e dati? Perché non posso distribuirlo in una farm per l'elaborazione o acquistare un server "normale" robusto.

Alta ridondanza e scalabilità? Preferirei avere una server farm Linux o un set di server virtuali.

Virtualizzazione e sistemi operativi multipli? Forse c'è una differenza di prestazioni considerevole per l'utilizzo di questa invece di una strategia "cloud"?

Mentre mi piacerebbe capire tutte queste cose in modo più dettagliato, la mancanza di spiegazioni utili su ciò che differenzia un mainframe è il motivo principale per cui non programma per tali sistemi.

Ho 25 anni e attualmente sto partecipando a un programma MSCS (il mio background non è CS) e sono decisamente interessato ai mainframe. Il problema è che non sono sicuro da dove cominciare. Ho guardato COBOL e non so dove ottenere un compilatore decente (non sono nemmeno sicuro di cosa sia un compilatore decente per COBOL, so che esiste un compilatore open-source, ma non sono sicuro della qualità che ha). Semplicemente non vedo molte informazioni e ad essere sincero, il tempo trascorso a cercarlo è il tempo in cui potrei lavorare attivamente su un progetto in .Net o Java (preferisco .Net ma il lavoro scolastico è in Java) . Come @Joshua Smith, temo che se dovessi entrare nei mainframe sarebbe la mia vita, ma li trovo anche più interessanti delle app Web e dell'intera mania del Web 2.0 (chiamami pazzo). Per me però

La linea di fondo è questa:

(1) Le informazioni non sono prontamente disponibili per me per imparare cosa avrei bisogno di imparare per fare la programmazione mainframe
(2) A questo punto della mia vita, voglio solo essere in grado di programmare per vivere e .Net e Java mi permettono a lavorare per raggiungere questo obiettivo mentre a scuola perché ci sono molte risorse a cui posso rivolgermi e imparare ciò di cui ho bisogno per venire via con un portfolio alla fine della mia carriera accademica
(3) Sarebbe difficile per me rimanere bloccato fare qualcosa che non mi piace e la possibilità di rimanere bloccato solo facendo i mainframe per una carriera è qualcosa che mi spaventa (anche se, so che ci sono modi per aggirarlo come rintracciare nuove cose nel mio tempo libero e contribuire all'open source)

Questa è solo la mia prospettiva personale di giovane programmatore. Non ho mai lavorato su un mainframe prima, quindi non posso parlare per esperienza di prima mano su uno. Ma, questo è il punto, non ho mai lavorato su uno e non prevedo che accadrà presto. Non sono sicuro di dove vuoi tracciare il confine tra mainframe e un semplice server, ma quando penso al mainframe, immagino una macchina IBM colossale come la Z-Series 900 che consuma $ 35 al giorno solo in elettricità. Non avrò presto uno di quelli nel mio seminterrato per armeggiare nel mio tempo libero. Soprattutto quando riesco ad afferrare una vecchia macchina, lanciare ubuntu-server su di essa e ospitare tutto ciò che mi sento molto facilmente. Se ho un problema, la comunità Linux è enorme e ci sono possibilità che qualcun altro abbia riscontrato il mio problema e abbia pubblicato una soluzione online. Sto solo indovinando,

Ho iniziato a lavorare sul mainframe quando sono entrato nella forza lavoro 10 anni fa. Non avevo mai toccato un mainframe prima d'ora.

Ci sono stati diversi aspetti che non mi sono piaciuti, quindi ho smesso di fare il mainframe appena ho potuto:

1. Il codice di modifica era molto primitivo. Fondamentalmente stavi lavorando in un editor di testo, fissato su TUTTI MAIUSCOLI e 80 righe di caratteri. Nessun completamento del codice o controllo della sintassi.
2. La compilazione è stata eseguita avviando un processo batch, che è stato programmato ed eseguito ad un certo punto, di solito nei prossimi 5 minuti se si fosse fortunati. Se hai avuto un refuso e il codice non è stato compilato, ripeti più volte.
3. Non c'era alcun debugger di alcun tipo. Il debug è stato eseguito stampando i valori delle variabili e ripetendo la lunga fase della compilazione.
4. I cambiamenti che abbiamo apportato sono sempre stati incredibilmente conservativi. Stavamo costruendo 20 anni di codice legacy in cui l'unica documentazione era scritta a mano su carta in un archivio, da qualche parte. Inoltre, questo era un codice finanziario, quindi non c'era tolleranza per gli errori. Pertanto, l'attuale fase di codifica è stata minima rispetto alla ricerca richiesta in precedenza.

(OTOH, avevano un controllo della versione e una promozione del codice molto avanzati, per il periodo di tempo.)

Due motivi per considerare l'adesione alla forza lavoro mainframe:

1. Paga bene
2. Ci sono tonnellate di aperture

La forza lavoro ingrigita nel campo del mainframe è e creerà un numero enorme di aperture sul campo.

Lavoro per una grande società finanziaria e nei prossimi 5 anni perderemo circa il 30% della nostra forza lavoro a causa della pensione. Tale numero aumenterà esponenzialmente in 10-15 anni.

Più motivi:

• Sono stato sul campo per oltre 25 anni e non mi sono mai annoiato.
• Meno concorrenza per i lavori.
• Smetti di lamentarti della tecnologia (vedi alcuni post sopra) ... potrebbe essere vecchio, ma per molti versi è anni luce avanti rispetto ai sistemi aperti. HTML - dammi una pausa. È così simile a Basic che ho preso 30 anni fa al college. Siamo ben oltre.
• Il mainframe è veloce e affidabile, provato e vero.
• Prova la Programmazione dei sistemi se sei molto brillante e ami la risoluzione dei problemi.
• Come team leader, vorrei poter trovare tecnici giovani e qualificati per riempire le aperture.
• Ho già detto che paga bene?
• Altre opzioni di carriera per mainframe oltre allo sviluppo di software: ingegneri hardware, tecnologie di archiviazione, reti e altro.
• È divertente, eccitante, stimolante e c'è una grande crescita professionale.
• Smetti di pensare al mainframe come a una vecchia tecnologia: dai un'occhiata e verifica tutto ciò che ho detto.

Dai un'occhiata anche a System z Academic Initiative di IBM.

Sono ancora un programmatore giovane (ho 29 anni) e non sono assolutamente interessato a imparare a sviluppare per il mainframe. Lavoro per una compagnia assicurativa in un team .NET, ma lavoriamo anche con un grande team di programmatori mainframe della vecchia scuola.

Ci sono alcune cose che rendono il mondo mainframe poco attraente per me. Innanzitutto, c'è COBOL. Capisco che gran parte del mondo funziona con COBOL, ma ciò non rende la lingua meno brutta ai miei occhi.

Successivamente, c'è il concetto di "ciclo". Non so se questo è comune ai mainframe o è solo il modo in cui facciamo le cose, ma il nostro mainframe deve eseguire un ciclo notturno prima di poter ottenere i dati correnti da esso. Il lato .NET del nostro negozio è fortemente coinvolto nell'invio e gestione di dati dal mainframe (in particolare, visualizzazione di una tonnellata di dati su un sito Web LOB interno per agenti). L'azienda desidera che i dati visualizzati agli agenti siano aggiornati al minuto. Tuttavia, il mainframe non funziona nel mio (limitato) concetto di tempo reale. Abbiamo in atto alcune soluzioni pazzesche per simulare sul sito Web quello che prevediamo essere l'output effettivo dal mainframe il giorno seguente.

Infine, sono fermamente convinto che se a questo punto dovessi passare allo sviluppo del mainframe, questo dominerebbe la mia carriera. Penso che le mie capacità di sviluppatore moderno rimarranno sempre più indietro, raggiungendo infine il punto in cui la manutenzione COBOL sarebbe la mia unica opzione. So che ci sono buoni soldi da guadagnare, ora e soprattutto tra dieci anni, ma il denaro è il quarto o il quinto della mia lista di priorità per la mia carriera. Preferirei continuare a guadagnare il mio salario decente se ciò significa lavorare su cose nuove e interessanti.

Lavoro principalmente con Java, ma usiamo i mainframe per il nostro backend, il che significa che devo affrontarli molto (RPG). Il problema più grande che ho è la mancanza di documentazione pubblicamente disponibile. È possibile trovare la documentazione SQL per DB2 che si tradurrà principalmente in iSeries DB2, ma publib.boulder è orribile rispetto al javadocs di Sun.

Un'altra cosa che non mi piace è la sintassi difficile da leggere delle principali lingue del mainframe. RPG non ha il concetto di ambito locale, il che significa che hai bisogno di enormi blocchi di dichiarazioni variabili. Penso che Cobol soffra dello stesso problema. Porta anche a nomi di variabili senza significato e significati nascosti. Ha anche molte, molte diverse funzioni integrate che ho difficoltà a scoprire (vedi sopra). Mi ricorda perché non uso più BASIC per una programmazione seria. Per fortuna IBM sta cercando di spostare tutti su Java, ma quei linguaggi legacy non spariranno presto.

Trovo difficile essere entusiasti di imparare a programmare in un ambiente come questo.

Senti, ho 42 anni e non mi interessano i mainframe. Bene, qualifichiamolo. Sono interessato alla storia dell'informatica. Ho studiato le architetture dei mainframe in una certa misura e ho capito come, ad esempio, i mainframe IBM hanno influenzato le architetture di microprocessori come Motorola 68000 o 80386. Negli anni '60 i mainframe erano già in fiamme a velocità superiori a 30 Mhz e sfoggiavano sistemi operativi multi-tasking avanzati con virtuale ricordi. Per le persone abituate a quegli ambienti, i primi microprocessori erano deludenti in molti modi e ci volle un po 'di tempo prima che le architetture basate su microprocessori raggiungessero capacità e prestazioni simili.

Ma ha raggiunto quelle architetture, e i mainframe hanno smesso di essere "alla moda" molto tempo fa. Accadde quando gli hacker potevano mettere i minicomputer sui loro banchi e subito dopo quelle workstation che eseguivano Unix.

I mainframe sono stati estranei ai giovani programmatori dai primi anni '80 in poi. Potrebbe essere stato un momento eccellente per le aziende mainframe per porsi la tua stessa domanda.

Oggi la risposta è ricorsiva a livello intergenerazionale: i giovani programmatori non sono interessati ai mainframe perché anche se hanno genitori o insegnanti interessati all'informatica, quei genitori e insegnanti (oltre 40 geezers come me) non erano già interessati a fare nulla con i mainframe un quarto secolo fa.

Ad ogni modo, oggi, un telefono cellulare può gestire i compiti che i mainframe sono stati utilizzati 30 anni fa! Le farm di scatole server economiche sono il nuovo mainframe. Quindi, in un certo senso, oggi ci sono nuovi programmatori di mainframe, solo la loro specialità è mettere insieme macchine in rete per creare cloud. In breve, potremmo dire che Mark Zuckerberg e la sua banda stavano facendo un nuovo tipo di programmazione mainframe quando hanno prodotto Facebook, nel senso che non è solo una piccola applicazione che gira solo su un semplice microprocessore con un disco.

A proposito, una delle ultime specialità del mainframe è stata la virtualizzazione. Ma questo è ormai onnipresente nelle macchine desktop / server. Le persone hanno iniziato a farlo male all'inizio, usando tecniche software. Le macchine virtuali erano così utili che agli utenti non importava il successo delle prestazioni. Quindi aziende come Intel hanno esaminato nuovamente il mainframe e hanno appreso un paio di lezioni in più supportando la virtualizzazione nell'hardware per renderlo veloce.

Imparare lo sviluppo di web, telefoni cellulari o PC è piuttosto economico e facile.

I costi hardware anche per un vecchio mainframe maltrattato sono terribilmente elevati e IBM si arrabbia spesso per il progetto dell'emulatore Hercules (che consente di emulare System / 370, ESA / 390 e zSeries). Senza Hercules, questo rende i costi di accesso per apprendere l'architettura del mainframe e lo sviluppo di applicazioni fuori dalla portata di tutti, tranne i più ricchi hobbisti.

Nessun college che ho frequentato dagli anni '80 ha avuto un mainframe disponibile per gli studenti. Penso che IBM e il resto dei fantasmi dell'industria dei mainframe si siano sparati ai piedi rendendoli meno accessibili all'apprendimento.

Iniziamo con alcuni fatti sui mainframe IBM e in particolare su zSeries.

L'hardware è nuovo di zecca lucido e nuovo. Contiene alcuni dei più avanzati componenti elettronici e di chip disponibili e sono veloci.

Mentre z / OS ha le sue radici negli anni '60, ha subito uno sviluppo continuo e almeno due riscritture complete, quindi a parte le stranezze risultanti dal feticcio di IBM per la compatibilità con le versioni precedenti è probabilmente uno dei nuovi sistemi operativi in ​​uso generale.

I punti chiave di vendita sono: -

• La summenzionata compatibilità all'indietro, se si tratta di un programma eseguito nel 1976 su una macchina MVS / MVT, è probabile che verrà eseguita sull'ultima zSeries senza essere ricompilata e produrre esattamente gli stessi risultati.
• La larghezza di banda può spostare l'accesso e archiviare enormi quantità di dati, a grande velocità e ad un livello molto fine.
• Disponibilità. SYSPLEX che è stato disponibile negli ultimi 15 anni circa fornisce cluster senza soluzione di continuità su più siti, completi di bilanciamento del carico, failover automatico ecc. Molti dei quali sono implementati nell'hardware. Rende la maggior parte del clustering * nix un aspetto primitivo.
• Convergenza. Questo suona un po 'strano ma con il pieno supporto POSIX e una JVM superveloce un moderno mainframe è praticamente indistinguibile da qualsiasi altra scatola * NIX se è così che vuoi usarlo.

Finora il mainframe è sopravvissuto a quasi tutto ciò che gli esperti hanno detto che lo avrebbero sostituito.

Ci sono un certo numero di aspetti negativi: -

• Compatibilità con le versioni precedenti significa che molti negozi gestiscono sistemi di venti, trenta e in alcuni casi quarant'anni. Mentre lavorano bene e svolgono bene le loro funzioni aziendali (o non sarebbero ancora in esecuzione!) Riflettono gli stili di codifica e le ossessioni di un'epoca passata.
• cultura arretrata. I programmatori che lavorano in un ghetto di antichi sistemi COBOL non sembrano aver capito che il mondo è passato, o se lo fanno una gestione fossilizzata non glielo permetterà.
• Mancanza di disponibilità A meno che tu non sia effettivamente pagato per lavorare su uno di questi mostri, non avrai accesso a uno di questi. Potrebbe essercene anche uno in cui lavori ma se la descrizione del tuo lavoro immediato non include il lavoro su di esso non otterrai un accesso. Molto è stato detto in altri post sul software di emulazione "herecules" ed è davvero eccellente ma è molto solo per esperti, esegue una versione antica del sistema operativo, manca della maggior parte dei componenti standard come CICS, COBOL e DB2 che costituisce il framework della maggior parte delle applicazioni mainframe in esecuzione.

Divertente, dovresti chiedere questo. Abbiamo appena parlato all'università in merito ai mainframe e che IBM non è contenta del livello degli sviluppatori di mainframe, in modo tale da implementare un modulo mainframe presso la nostra Università, insegnarci a programmare mainframe e avere accesso a uno dei loro mainframe da remoto.

In realtà prenderò questo modulo a settembre, potrebbe non essere qualcosa che farò di nuovo, ma mi darà la possibilità di lavorare su qualcosa di "diverso" e aprire gli occhi a nuovi paradigmi.

Ho 28 anni e sono uno sviluppatore professionista da 10 anni. Ho trascorso 3 anni a lavorare su un mainframe.

L'ambiente era esoterico, stantio, stagnante, confuso (JCL e ISPF qualcuno?). Detto questo, ho avuto un enorme rispetto per il sistema, il modo in cui tutto ha funzionato, le sue dimensioni. Il sistema aveva qualcosa come 150M SLOC, supportava una farm di fascia media di server UNIX tramite SOA e gestiva letteralmente gran parte del paese.

Detto questo, perché i giovani programmatori non sono interessati? Ecco la mia opinione, come programmatore "giovane" (ho iniziato su questo sistema all'età di 23 anni). Tenete presente che questa è la mia prospettiva rispetto al sistema su cui stavo lavorando e la ricerca che ho fatto:

• C'è poco nuovo sviluppo del mainframe. Molto è eredità.
• Ci sono enormi ostacoli all'ingresso
• Il lavoro svolto è per finanziari, grandi imprese e governo. Niente di tutto ciò rappresenta un limite.
• Gli strumenti di sviluppo sono vecchi e in gran parte antiquati. Il debug non è come VS.

I mainframe avranno sempre un posto nell'economia. Semplicemente non guidano le prime aziende a causa dei loro enormi costi e requisiti di supporto.

Mentre penso che probabilmente ci sia un lavoro molto interessante nei mainframe, sarei terrorizzato a spostare effettivamente la mia carriera in quella direzione. C'è una possibilità troppo grande che 10 anni dopo, la mia esperienza è diventata inutile e non c'è lavoro disponibile per un programmatore di mainframe. Non voglio obsoleto trascorrendo molto tempo in una tecnologia stagnante con una base di installazione in calo.

La risposta è che non c'è futuro. Ho ventidue anni di esperienza come programmatore di mainframe e sono stato senza lavoro per cinque anni. Torno a scuola per ottenere la mia laurea in sviluppo web. Perché qualcuno nella sua mente giusta vorrebbe essere un programmatore COBOL mainframe?

comprensione