Por que jovens programadores não estão interessados ​​em mainframes? [fechadas]

Uma questão fundamental nos mainframes é que o grupo de programadores de suporte está diminuindo. Embora normalmente isso não seja um problema, pois uma oferta cada vez menor de programadores seria compensada por uma quantidade cada vez maior de salários, causando um aumento na oferta de programadores através da lei da oferta e demanda, não tenho certeza de que isso esteja realmente acontecendo. mainframes.

Embora eles ainda formem uma infraestrutura crítica para muitas empresas, o simples fato é que não existe um número adequado de jovens programadores para manter a população de suporte preenchida.

Por que é isso? O que torna os mainframes pouco atraentes para jovens programadores?

Sou um programador antigo e não estou interessado em mainframes. Minhas razões provavelmente serão semelhantes às razões apresentadas pelos jovens programadores, no entanto, embora sem o desconhecimento da tecnologia tão evidente em muitas dessas respostas.

Primeiro, vamos tirar a ignorância do caminho:

• As várias alegações de incapacidade de experimentar mainframes são falsas. O Hercules está disponível desde 1999 - provavelmente por mais tempo do que muitas das pessoas que responderam estão programando - e, apesar da insistência da IBM, as chances de ele desaparecer tão cedo são insignificantes (especialmente porque é de código aberto). Embora seja, de fato, verdade que você não pode (legalmente) executar o software caro por isso, há uma abundância de software disponível, você pode rodar nele, incluindo software que é realmente ainda em uso bastante comum lá fora.
• Novamente, ao contrário da opinião pública, os mainframes são mais do que COBOL, CICS e RPG2. De fato, quase (mas não exatamente) tudo o que você pode executar no seu PC executando Linux, você pode executar em um mainframe. <irony> Não sei por que. </irony>

Então, por que evite os mainframes por toda a minha vida depois de encontrá-los na escola? Bem:

• Embora seja verdade que você possa usar mais que COBOL, CICS, RPG2 etc. nos mainframes, as chances são muito altas de que, se você trabalhar com eles, é isso que você será relegado a fazer. Pior ainda, apesar de o COBOL ter sido massivamente "modernizado" nas últimas duas décadas (mais ou menos citações assustadoras, porque ainda não acho que seja uma linguagem muito moderna), a maior parte da codificação que você fará no COBOL ainda será antiga. código de estilo porque ...
• Há muito pouco desenvolvimento novo real acontecendo nos mainframes. Se você conseguir um emprego na IBM trabalhando para a divisão de P&D de mainframe, poderá ter a chance de fazer um novo desenvolvimento (e, nesse caso, poderá até gostar do seu trabalho!). Na realidade, porém, convenha: você não estará trabalhando lá. Você estará trabalhando na sala dos fundos de alguma instituição financeira ou de outro código COBOL de 50 anos, escrito por alguém que ainda pensa que 64 KB é uma enorme pilha de RAM. (Esse mesmo cara provavelmente será seu chefe.)
• Embora seja verdade que você possa executar o Linux em mainframes e, assim, tenha acesso a praticamente qualquer linguagem ou ambiente de programação que você queira, novamente, como trabalha na pesquisa e desenvolvimento de mainframe da IBM, você não conseguirá esse emprego. Voltamos à manutenção do COBOL de 50 anos.
• A programação corporativa é muito eficiente para sugar a alma de você (e lembre-se, é a programação corporativa que você fará como programador de mainframe, a menos que tenha muita sorte).
• É um gueto e cada vez mais encolhido. (É como o MUMPS dessa maneira.) Se você ficar muito impregnado da tradição do mainframe, se distancia de qualquer coisa que não seja mainframe. Você pode tentarpara acompanhar, mas você não vai. Sei que alguém apontou que os mainframes aumentaram em vendas enquanto outros setores de servidores encolheram um pouco, mas a programação de servidores é minoria atualmente. Os PCs infernais em geral estão perdendo importância. O mundo da programação é muito amplo e muito diversificado e ter uma parte minúscula dela crescer em comparação com outra parte minúscula não faz sentido quando comparado com, digamos, o crescimento repentino e explosivo da programação em algo tão trivial como o iPhone (que é o próprio uma plataforma minoritária - de longe). Não, comece a trabalhar em mainframes e você só terá outros mainframers para compartilhar seus pensamentos, alegrias e raiva - e eles são uma raça em extinção. Isso leva a um ciclo de feedback negativo que faz o rebanho encolher ainda mais e mais rápido.

Tenho certeza de que há muitas razões que um programador de mainframe poderia dar por que a carreira é gratificante e cheia de alegrias e desafios interessantes. De fato, ouvi muitos deles de pessoas tentando me recrutar para o campo. No final, no entanto, permaneci não convencido, principalmente por causa do problema do gueto. Se entrei e descobri que não gostei, como saio?

Tenho 27 anos e sou desenvolvedor profissional há mais de 4 anos (por isso espero que me qualifique ainda jovem). Também trabalho como especialista em integração, para ter muita exposição ao mundo do desenvolvimento de mainframe.

1. Parece haver pouca ou nenhuma inovação acontecendo na comunidade.
   Eu sei que esse não é exatamente o caso, mas para o observador casual parece que sim. Ninguém quer se envolver em uma área onde é difícil "deixar sua marca".
2. Quanto novo desenvolvimento ou novos projetos estão acontecendo?
   Nenhum, até onde eu sei. Se você entrar nessa área, estará se condenando a ser um programador de manutenção para sempre.
3. Não é acessível ao aluno casual.
   A maioria das pessoas começou a aprender como programar em seu PC em casa. Novamente, a maioria das pessoas não gosta de mudar do que sabe. Portanto, fazer a transição de um para o outro leva tempo e motivação. Dadas as outras duas razões, não há muitos compradores.

Com 40 anos, em setembro, não sei se isso me qualifica como jovem, mas tenho conhecimento pessoal em primeira mão de por que alguém pode não querer ser programador de mainframe.

Os últimos 10 anos da minha vida profissional foram dedicados à programação de mainframe. Aprendendo tudo o que há para saber sobre batch, jcl, Cobol, Assembler, Easytrieve, CICS e Web Services, eu gostei imensamente e ainda o faria se não percebesse uma tendência. Meu último local de trabalho me levou a trabalhar lado a lado com desenvolvedores da web (jsp, javascript, spring e hibernate) e notei que a empresa estava trazendo desenvolvedores da web com anos de experiência comparáveis ​​por muito mais dinheiro. Sem mencionar o fato de que a posição dos desenvolvedores da web era muito menos estressante.

Depois de me cansar dessa tendência, decidi sair do negócio de mainframe. Agora estou em uma posição em que desenvolvo serviços da web com java e interface do usuário de front-end com javascript. Esse estilo de programação não é mais difícil do que eu fiz no mainframe, mas agora ganho mais dinheiro e tenho menos dor de cabeça. Não recebo mais essa ligação às 2:00 da manhã de que algo foi interrompido e os principais processos do sistema estão esperando por mim para corrigir meus problemas. Então, me dê uma boa razão para permanecer como programador de mainframe quando puder ganhar mais dinheiro e ter menos estresse em minha vida como programador de sistemas distribuídos?

Tenho certeza de que há circunstâncias em que as empresas pagam mainframers e sistemas distribuídos, mas eu pessoalmente não os encontrei. Além disso, comecei a fazer pesquisas de emprego em ambas as perspectivas e descobri que as listagens de empregos de sistemas distribuídos superavam em número as listagens de empregos em mainframe de pelo menos 10 para 1. Isso me diz que, no momento, para eu ter melhores oportunidades de emprego, o mainframe não é o lugar para estar.

Pelo que vi até agora, e comparando com Linux e Windows, o problema básico com mainframes e midframes é que você DEVE pagar antecipadamente para usá-los. E pague muito. Todo ano. Para tudo.

Simplesmente não é assim que os alunos se interessam por algo, porque eles não podem pagar. Se isso não lhes interessa, eles provavelmente não farão uma carreira voluntariamente.

Infelizmente, o modelo de negócios da IBM não permite disponibilizar as máquinas de forma barata aos estudantes, ou eles podem ter uma chance de mudar isso.

Um dos meus primeiros empregos de verão como programador foi amplamente baseado em raspar telas verdes e arquivos PRN. Naquela época, eu provavelmente não me importaria de sujar as mãos no COBOL (ou seja, se eles tivessem confiado em mim o suficiente como estudante para me deixar entrar nesse código), mas não tenho certeza se me sentiria da mesma maneira sobre o mesma perspectiva hoje.

Eu não acho que o problema seja realmente com mainframes em si. É a obsessão de nossa indústria (muitas vezes justificada) pelo novo e brilhante.

Veja C. C. ainda é obviamente uma linguagem de importância crítica. Quase todo o código incorporado e a maioria dos sistemas operacionais são escritos em C. Não vai a lugar nenhum tão cedo. E, no entanto, está ficando mais difícil encontrar programadores em C. Uma rápida olhada na página de tags Stack Overflow coloca em 1/6 do tamanho [c#]e 1/4 do tamanho [java]. Alguém se lembra quando C era essencialmente a língua dominante, sem dúvida o único jogo na cidade?

Programadores adoram ferramentas poderosas. Talvez seja porque (SPECULATION ALERT) a maioria dos programadores são homens. Você atribui a um programador Java ou .NET a tarefa de, digamos, copiar um arquivo, e muitos, se não a maioria, ainda optarão por escrevê-lo em Java ou C # em vez de escrever um arquivo em lotes do DOS ou * shell script nix que seria 50 vezes mais rápido para escrever e implantar. Por que usar uma vara e molinete para pescar um peixe quando você tem uma rede retrátil gigantesca que pode capturar 500 peixes?

Sim, COBOL e PL / I são antigos , assim como Pascal, e ainda está vivo e chutando na forma de Delphi. A aversão ao primeiro provavelmente decorre do fato de que essas linguagens são pesadas em comparação com as ferramentas modernas. A orientação a objetos ainda é um conceito relativamente novo no mundo COBOL (ênfase em relativamente ), mas no mundo C #, LINQ e genéricos e AJAX deixaram de ser revolucionários anos atrás. Pedir a um desenvolvedor acostumado a essas ferramentas para começar a programar em mainframes é como pedir a um músico de rock que comece a tocar banjo.

É claro que também há o problema do estereótipo de autoperpetuação. Como programadores enquanto mais jovens acreditam que não há nada para eles em mainframes (se é ou não é verdade), então quaisquer jovens programadores que não optam por ir para ele vai acabar gastando a maior parte de seus dias em torno de pessoas muito mais velhas. A TI não é muito uma profissão socialmente atraente para começar, mas o desincentivo adicional de uma lacuna de geração tende a colocá-la abaixo de muitos limites de dor das pessoas. Sem querer ofender - eu pessoalmente passei a maior parte da minha vida trabalhando com pessoas muito mais velhas, mas nem todo mundo tem esse histórico ou essa capacidade.

Por fim, a maioria dos programadores não gosta de trabalhos de manutenção e quase todo o trabalho em mainframe é de manutenção. Não há muitos softwares novos sendo escritos em PL / I. Qualquer trabalho definido total ou amplamente em torno do código de manutenção inicia automaticamente com uma pontuação negativa.

Não são positivos para trabalhar em código legado ( "legacy" abrangendo mainframes e muitas outras coisas), que você provavelmente vai precisar para jogar até se você está tentando atrair um público mais jovem:

• Os sistemas são, como você diz, infraestrutura crítica. Desenvolvedores mais jovens, pelo menos no mundo dos negócios (não no Google / Microsoft), geralmente não têm chance de causar impacto real . É desanimador trabalhar em um sistema que você sabe que será abandonado ou substituído após alguns meses ou anos. Os aplicativos de mainframe que já estão em execução há 50 anos provavelmente serão executados por muito mais tempo, porque não faz sentido que as empresas os reconstruam; portanto, o trabalho que você faz neles é realmente importante para muitas pessoas.

• Se você é uma daquelas poucas empresas que realmente não têm uma inclinação para "upgrade", em seguida, um monte de programadores, jovens e velhos, serão atraídos por essa oportunidade, porque então há oportunidades individuais para trabalhar no código de missão crítica e flexionar alguns desses músculos C # / Java. Obviamente, nenhuma empresa sã simplesmente descartaria o mainframe e reconstruiria do zero, mas vi sistemas que (por exemplo) têm um núcleo COBOL que se integra aos componentes Java.

• Finalmente, há a indispensabilidade - pelo menos, como nós os estranhos percebemos. Quando todo o seu código está no .NET, sempre há o risco de que os proprietários o troquem por um recém-formado ou, pior, uma equipe offshore, em uma tentativa equivocada de cortar custos. Não acho que isso ocorra com muita frequência no mundo do mainframe, especialmente se o que você diz é verdade e a oferta parece estar diminuindo. Obviamente, esse ponto é discutível se você não pagar o suficiente; os salários precisam ser ajustados para refletir essa oferta cada vez menor, caso contrário as pessoas não "venderão".

Tenho certeza de que existem muitos desenvolvedores mais jovens por aí que não recusariam uma oferta razoavelmente generosa de uma empresa que parecia estar se esforçando para tornar o ambiente de trabalho atraente para os funcionários mais jovens. Mas se você quiser alcançá-los, seria sensato jogar com seus pontos fortes e talvez até precise começar a fazer algum marketing; tendemos a ver os mainframes como um mundo diferente e muito estrangeiro, e tenho certeza de que não os vi na feira de empregos do campus há 10 anos trabalhando para mudar essa percepção.

Para resumir em uma única frase: nada faz com que os mainframes não sejam atraentes , é apenas que nada os torna atraentes e isso os coloca em séria desvantagem quando comparados com a margem de sangramento que nos oferece grandes aumentos de produtividade e refrigerantes gratuitos.

Sou jovem (meados dos anos 30) e atualmente trabalho com suporte a mainframe. RPG, COBOL, porcaria 4GL proprietária. O desenvolvimento é lento e, sempre que possível, é migrado para um hardware mais moderno usando linguagens mais modernas.

O desenvolvimento do mainframe é tão complicado em comparação com os sistemas modernos que o próprio mainframe tende a ser relegado ao back-end, enquanto linguagens mais modernas são usadas para fazer os tipos de relatórios e transformações de dados que costumavam ser feitas no próprio mainframe. Nesse ponto, até transformamos a maior parte da entrada de dados em um processo controlado por lote, portanto, as únicas coisas que permanecem no servidor estão relacionadas à cobrança.

Embora possa parecer um bom nicho para entrar, acho que muitas empresas estão percebendo que não precisam mais desses sistemas. A mudança acontece lentamente no mundo das finanças, mas acontece.

Pessoalmente, não entendo qual é a vantagem comercializável para os mainframes.

Número rápido e processamento de dados? Por que não posso distribuir isso em um farm para processamento ou comprar um servidor robusto "normal".

Alta redundância e escalabilidade? Prefiro ter um farm de servidores Linux ou um conjunto de servidores virtuais.

Virtualização e vários SOs? Talvez haja uma diferença considerável de desempenho ao usar isso em vez de uma estratégia de "nuvem"?

Embora eu adorasse entender todas essas coisas com mais detalhes, a falta de explicações úteis sobre o que diferencia um mainframe é a principal razão pela qual não programa para esses sistemas.

Tenho 25 anos e atualmente estou em um programa MSCS (minha formação não é CS) e definitivamente estou interessado em mainframes. O problema é que não sei por onde começar. Eu olhei para o COBOL e não sei onde obter um compilador decente (nem tenho certeza do que é um compilador decente para o COBOL, eu sei que existe um compilador de código aberto, mas não sei qual a qualidade dele). Eu simplesmente não vejo muitas informações para isso e, para ser honesto, o tempo gasto procurando é o momento em que eu poderia estar trabalhando ativamente em um projeto em .Net ou Java (eu prefiro .Net, mas o trabalho da escola é em Java) . Como @ Joshua Smith, eu me preocupo que, se eu fosse para os mainframes, seria a minha vida, mas também os acho mais interessantes que os aplicativos da Web e toda a mania da Web 2.0 (me chame de louco). Para mim, porém,

A linha inferior é esta:

(1) As informações não estão prontamente disponíveis para eu aprender o que eu preciso aprender para fazer a programação de mainframe.
(2) Neste ponto da minha vida, eu só quero poder programar para viver e o .Net e Java permitem para que eu trabalhe em direção a esse objetivo enquanto estiver na escola, porque há muitos recursos para os quais posso recorrer e aprender o que preciso para obter um portfólio no final da minha carreira acadêmica
(3) Seria difícil para mim ficar preso fazer algo que não gosto e a possibilidade de ficar preso apenas fazendo mainframes para uma carreira é algo que me assusta (embora eu saiba que existem maneiras de contornar isso, como atualizar coisas novas no meu tempo livre e contribuindo para o código aberto)

Esta é apenas a minha perspectiva pessoal como um jovem programador. Eu nunca trabalhei em um mainframe antes, então não posso falar da experiência em primeira mão em um. Mas é isso, nunca trabalhei em um e não prevejo que isso aconteça tão cedo. Não sei ao certo onde você deseja definir a linha entre o mainframe e um servidor simples, mas quando penso em mainframe, imagino uma máquina IBM gigante como a Z-Series 900, que consome US $ 35 / dia apenas em eletricidade. Eu não vou ter um desses no meu porão tão cedo para mexer no meu tempo livre. Especialmente quando eu posso pegar uma máquina antiga, jogar o ubuntu-server nela e hospedar o que eu quiser com muita facilidade. Se eu tiver um problema, a comunidade Linux é enorme e é provável que outra pessoa tenha encontrado o meu problema e postado uma solução online. Eu estou apenas adivinhando,

Comecei a trabalhar no mainframe quando entrei na força de trabalho há 10 anos. Eu nunca havia tocado em um mainframe antes.

Havia vários aspectos que eu não gostei, então parei de fazer o trabalho de mainframe assim que pude:

1. O código de edição foi muito primitivo. Você estava basicamente trabalhando em um editor de texto, corrigido para ALL CAPS e 80 linhas de caracteres. Sem conclusão de código ou verificação de sintaxe.
2. A compilação foi feita iniciando um trabalho em lotes, que foi agendado e executado em algum momento, geralmente nos próximos 5 minutos, se você tiver sorte. Se você digitou um erro de digitação e o código não foi compilado, repita várias vezes.
3. Não havia depurador de nenhum tipo. A depuração foi realizada imprimindo valores variáveis ​​e repetindo essa etapa longa de compilação.
4. As mudanças que fizemos foram sempre incrivelmente conservadoras. Estávamos desenvolvendo 20 anos de código legado, em que a única documentação era manuscrita em papel em um arquivo, em algum lugar. Além disso, este era um código financeiro, portanto não havia tolerância a erros. Portanto, a etapa de codificação real foi mínima em comparação com a pesquisa necessária anteriormente.

(OTOH, eles tinham controle de versão muito avançado e promoção de código, durante o período).

Duas razões para considerar ingressar na força de trabalho de mainframe:

1. Paga bem
2. Existem toneladas de aberturas

A força de trabalho em cinza no campo de mainframe é e criará um grande número de aberturas no campo.

Trabalho em uma grande empresa financeira e, nos próximos 5 anos, perderemos cerca de 30% de nossa força de trabalho para a aposentadoria. Esse número aumentará exponencialmente em 10 a 15 anos.

Mais razões:

• Estou no campo há mais de 25 anos e nunca fiquei entediado.
• Menos concorrência por empregos.
• Pare de reclamar sobre a tecnologia (veja algumas postagens acima) ... ela pode ser antiga, mas de muitas maneiras está anos-luz à frente dos sistemas abertos. HTML - me dê um tempo. É tão parecido com o Basic que tirei 30 anos atrás na faculdade. Estamos muito além disso.
• O mainframe é rápido e confiável, testado e verdadeiro.
• Experimente a programação de sistemas se você é muito inteligente e adora solucionar problemas.
• Como líder de equipe, gostaria de encontrar técnicos jovens e treinados para preencher vagas.
• Eu mencionei que paga bem?
• Outras opções de carreira em mainframe, além do desenvolvimento de software - engenheiros de hardware, técnicos de armazenamento, redes e muito mais.
• É divertido, emocionante, desafiador e há um grande crescimento na carreira.
• Pare de pensar no mainframe apenas como tecnologia antiga - confira e verifique tudo o que eu disse.

Verifique também o System z Academic Initiative da IBM.

Ainda sou um programador jovem (tenho 29 anos) e definitivamente não estou interessado em aprender a desenvolver para o mainframe. Eu trabalho para uma companhia de seguros em uma equipe .NET, mas também trabalhamos com uma grande equipe de programadores de mainframe da velha escola.

Existem algumas coisas que tornam o mundo do mainframe pouco atraente para mim. Primeiro, existe o COBOL. Entendo que grande parte do mundo funciona com COBOL, mas isso não torna a linguagem menos feia aos meus olhos.

A seguir, há o conceito de 'ciclo'. Não sei se isso é comum aos mainframes ou é apenas a maneira como fazemos as coisas, mas nosso mainframe precisa executar um ciclo noturno antes que possamos obter dados atuais dele. O lado .NET da nossa loja está fortemente envolvido no envio e tratamento de dados do mainframe (especificamente, na exibição de uma tonelada de dados em um site interno da LOB para agentes). A empresa deseja que os dados exibidos aos agentes sejam atualizados a cada minuto. No entanto, o mainframe não opera dentro do meu conceito (limitado) de tempo real. Temos algumas soluções insanas para simular no site o que esperamos ser a saída real do mainframe no dia seguinte.

Por fim, acredito firmemente que, se eu avançar para o desenvolvimento de mainframe a essa altura, isso dominará minha carreira. Penso que minhas habilidades como desenvolvedor moderno ficariam cada vez mais para trás, chegando ao ponto em que a manutenção COBOL seria minha única opção. Sei que há um bom dinheiro a ser ganho, agora e especialmente daqui a dez anos, mas o dinheiro é quarto ou quinto na minha lista de prioridades para minha carreira. Prefiro continuar ganhando meu salário decente se isso significa trabalhar em coisas novas e interessantes.

Eu trabalho principalmente com Java, mas usamos mainframes para o nosso back-end, o que significa que tenho que lidar muito com eles (RPG). O maior problema que tenho é a falta de documentação disponível ao público. É possível encontrar a documentação SQL para DB2 que se traduz principalmente no iSeries DB2, mas publib.boulder é horrível em comparação com os javadocs da Sun.

Outra coisa de que não gosto é a sintaxe difícil de ler das principais linguagens de mainframe. O RPG não tem o conceito de escopo local, o que significa que você precisa de enormes blocos de declaração de variáveis. Eu acho que Cobol sofre do mesmo problema. Também leva a nomes de variáveis ​​sem sentido e significados ocultos. Ele também possui muitas funções internas diferentes sobre as quais tenho dificuldade em descobrir (veja acima). Isso me lembra por que não uso mais o BASIC para programação séria. Felizmente, a IBM está tentando mover todos para Java, mas essas linguagens herdadas não vão desaparecer tão cedo.

Acho difícil ficar empolgado em aprender a programar em um ambiente como esse.

Olha, eu tenho 42 anos e não estou interessado em mainframes. Bem, vamos qualificar isso. Estou interessado na história da computação. Estudei arquiteturas de mainframe até certo ponto e entendi como, por exemplo, os mainframes da IBM influenciaram arquiteturas de microprocessadores, como o Motorola 68000 ou 80386. Nos mainframes dos anos 60, já funcionavam a velocidades superiores a 30 Mhz, e ostentavam sistemas operacionais avançados de multitarefa com virtual recordações. Para as pessoas acostumadas a esses ambientes, os primeiros microprocessadores foram decepcionantes de várias maneiras, e demorou um tempo para as arquiteturas baseadas em microprocessadores alcançarem recursos e desempenho semelhantes.

Mas alcançou essas arquiteturas, e os mainframes deixaram de ser "modernos" há muito tempo. Aconteceu quando os hackers conseguiram colocar minicomputadores em seus bancos e logo após as estações de trabalho executando o Unix.

Os mainframes são estranhos aos jovens programadores desde o início dos anos 1980. Esse pode ter sido um excelente momento para as empresas de mainframe se perguntarem sua própria pergunta.

Hoje a resposta é inter-geracionalmente recursiva: jovens programadores não estão interessados ​​em mainframes porque, mesmo que tenham pais ou professores interessados ​​em computação, esses pais e professores (mais de 40 geezers como eu) já não estavam interessados ​​em fazer nada com mainframes por um quarto século atrás.

De qualquer forma, hoje, um telefone celular pode lidar com as tarefas que os mainframes foram usados ​​há 30 anos! Fazendas de caixas de servidor baratas são o novo mainframe. Portanto, de certa forma, hoje existem novos programadores de mainframe, apenas sua especialidade é juntar máquinas em rede para criar nuvens. De certa forma, poderíamos dizer que Mark Zuckerberg e sua turma estavam fazendo um novo tipo de programação de mainframe quando produziram o Facebook, no sentido de que não é apenas um pequeno aplicativo que roda em um microprocessador simples com um disco.

A propósito, uma das últimas especialidades do mainframe foi a virtualização. Mas isso agora é onipresente em máquinas de desktop / servidor. As pessoas começaram a fazer mal no começo, usando técnicas de software. As VMs eram tão úteis que os usuários não se importaram com o desempenho atingido. Então, empresas como a Intel analisaram o mainframe novamente e aprenderam mais algumas lições, apoiando a virtualização em hardware para torná-lo rápido.

Aprender o desenvolvimento da Web, telefone celular ou PC é bastante barato e fácil.

Os custos de hardware, mesmo para um mainframe antigo, são terrivelmente altos, e a IBM frequentemente fica chateada com o projeto de emulador Hercules (que permite emular System / 370, ESA / 390 e zSeries). Sem o Hercules, isso faz com que os custos de entrada para aprender a arquitetura de mainframe e o desenvolvimento de aplicativos estejam fora do alcance de todos, exceto os hobbistas mais ricos.

Nenhuma faculdade que frequentei desde os anos 80 tinha mainframe disponível para uso dos alunos. Eu acho que a IBM e o resto dos fantasmas da indústria de mainframe deram um tiro no pé, tornando-os menos acessíveis ao aprendizado.

Vamos começar com alguns fatos sobre os mainframes da IBM e, especificamente, sobre o zSeries.

O hardware é de marca brilhante e novo. Ele contém alguns dos mais avançados designs de chips e eletrônicos disponíveis e são rápidos.

Embora o z / OS tenha suas raízes na década de 1960, ele passou por desenvolvimento contínuo e pelo menos duas reescritas completas, além das peculiaridades resultantes do fetiche da IBM pela compatibilidade com versões anteriores, provavelmente um dos sistemas operacionais mais recentes em uso geral.

Os principais pontos de venda são: -

• A compatibilidade com versões anteriores mencionada, se um programa foi executado em 1976 em uma máquina MVS / MVT, é provável que seja executado no zSeries mais recente sem ser recompilado e produzir exatamente os mesmos resultados.
• Largura de banda, ele pode mover o acesso e armazenar grandes quantidades de dados, em alta velocidade e em um nível muito refinado.
• Disponibilidade. O SYSPLEX, disponível nos últimos 15 anos, fornece clustering contínuo em vários sites, completo com balanceamento de carga, failover automático etc. muito dos quais é implementado em hardware. Faz com que a maioria dos clusters * nix pareça primitiva.
• Convergência. Este parece um pouco estranho, mas com suporte completo ao POSIX e uma JVM super rápida, um mainframe moderno é praticamente indistinguível de qualquer outra caixa * NIX, se é assim que você deseja usá-lo.

Até agora, o mainframe sobreviveu a quase tudo o que os especialistas disseram que iria substituí-lo.

Há várias desvantagens: -

• Compatibilidade com versões anteriores significa que muitas lojas estão executando sistemas de vinte, trinta e, em alguns casos, quarenta anos. Enquanto eles funcionam bem e desempenham bem suas funções comerciais (ou ainda não estavam funcionando!), Eles refletem os estilos de codificação e as obsessões de uma época passada.
• cultura atrasada. Os programadores que trabalham em um gueto de sistemas COBOL antigos não parecem ter percebido que o mundo seguiu em frente, ou se eles fizerem uma gestão fossilizada não permitirão.
• Falta de disponibilidade. A menos que você esteja realmente sendo pago para trabalhar em um desses monstros, você não terá acesso a um. Pode até haver um em que você trabalha, mas se sua descrição imediata do trabalho não incluir trabalho, você não obterá um login. Muito já foi dito em outras postagens sobre o software de emulação "herecules" e é realmente excelente, mas é apenas para especialistas, ele roda uma versão antiga do sistema operacional, não possui a maioria dos componentes padrão, como CICS, COBOL e DB2, que forma a estrutura da maioria dos aplicativos de mainframe em execução.

Engraçado você perguntar isso. Acabamos de conversar na Universidade sobre mainframes, e que a IBM está descontente com o nível de desenvolvedores de mainframe, de modo que eles estão implementando um módulo de mainframe em nossa universidade, ensinando-nos a programação de mainframe e tendo acesso a um de seus mainframes remotamente.

Na verdade, estou adotando este módulo em setembro, pode não ser algo que farei novamente, mas me dará a chance de trabalhar em algo 'diferente' e abrir meus olhos para novos paradigmas.

Tenho 28 anos e sou desenvolvedor profissional há 10 anos. Passei 3 anos trabalhando em um mainframe.

O ambiente era esotérico, obsoleto, estagnado, confuso (JCL e ISPF, alguém?). Com isso dito, eu tinha um enorme respeito pelo sistema, como tudo funcionava, a escala dele. O sistema possuía algo como 150M SLOC, suportava um farm intermediário de servidores UNIX via SOA e literalmente administrava a maior parte do país.

Com isso dito, por que jovens programadores não estão interessados? Aqui está minha opinião, como programador "jovem" (comecei neste sistema aos 23 anos). Tenha em mente que esta é minha perspectiva do sistema em que estava trabalhando e a pesquisa que fiz:

• Há pouco desenvolvimento de mainframe novo. Muito disso é legado.
• Existem enormes barreiras à entrada
• O trabalho realizado é para finanças, grandes empresas e governo. Nada disso é sangrento.
• As ferramentas de desenvolvimento são antigas e amplamente antiquadas. Depuração não é nada como o VS.

Os mainframes sempre terão um lugar na economia. Eles simplesmente não conduzem negócios iniciais devido aos seus enormes custos e requisitos de suporte.

Embora eu ache que provavelmente haja um trabalho muito interessante nos mainframes, eu ficaria aterrorizado em realmente mudar minha carreira nessa direção. Há uma chance muito grande de que, 10 anos depois, minha experiência se torne inútil e não haja trabalho disponível para um programador de mainframe. Não quero me obsoleto gastando muito tempo em uma tecnologia estagnada com uma base de instalação cada vez menor.

Essa resposta é que não há futuro nele. Tenho vinte e dois anos de experiência como programador de mainframe e estou sem trabalho há cinco anos. Estou voltando para a escola para obter meu diploma de bacharel em desenvolvimento web. Por que alguém em sã consciência gostaria de ser um programador de mainframe COBOL?

Ken