Translate

Mostrar mensagens com a etiqueta modernizacao. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta modernizacao. Mostrar todas as mensagens

quinta-feira, 25 de junho de 2026

☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

Bellacosa Mainframe quando a magia da migração via ia do mainframe falha


☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

O Dia em que o Mercado Percebeu que o ChatGPT Não Conhece o Batch das 02h17

Existe um momento na carreira de todo profissional de Mainframe em que ele aprende uma lição importante.

A primeira é que JCL não foi criado para ser bonito.

A segunda é que ninguém documenta adequadamente um scheduler.

A terceira é que sempre haverá alguém chegando com um PowerPoint dizendo:

— Vamos aposentar o Mainframe em doze meses.

Nos últimos vinte anos ouvi essa frase tantas vezes quanto mensagens $HASP373, IEC161I ou aquele clássico telefonema de sexta-feira às 18h:

— Bellacosa, caiu a produção.

Recentemente, entretanto, surgiu um ingrediente novo nessa antiga receita corporativa.

A Inteligência Artificial Generativa.

E, junto dela, uma nova promessa digna dos antigos alquimistas digitais:

"Nossa IA converte milhões de linhas COBOL para Java automaticamente."

"Seu CICS vira microsserviços em poucos cliques."

"Seu VSAM agora é PostgreSQL."

"Seu batch vira Kubernetes."

"Seu legado desaparece em seis meses."

Foi justamente nesse contexto que a Gartner publicou uma análise que talvez represente um dos maiores banhos de água fria já aplicados no mercado de migração de Mainframe.

Segundo a consultoria, mais de 70% dos projetos de saída do Mainframe iniciados em 2026 não entregarão os benefícios esperados.

E o motivo é simples.

As pessoas estão superestimando o que a IA realmente sabe fazer.

E subestimando brutalmente o que um ambiente IBM Z realmente é.


O Maior Equívoco da Década: Achar que Mainframe é Apenas COBOL

Quando alguém diz:

— Temos cinquenta milhões de linhas COBOL.

Meu primeiro pensamento nunca é sobre COBOL.

Meu primeiro pensamento é:

Quantos schedulers existem?

Quantos GDGs?

Quantos catálogos?

Quantos exits?

Quantos produtos ISV?

Quantos jobs dependem de um único arquivo VSAM aberto em RLS?

Porque o código é apenas a ponta visível do iceberg.

Abaixo da linha d'água vivem criaturas muito mais antigas e perigosas.

CA-7.

Control-M.

ESP.

Zeke.

NetView.

RACF.

DFSMS.

SMF.

RMF.

MQ.

WLM.

CICSplex.

IMS.

DB2 Packages.

Plan Stability.

PassTickets.

SAF.

Exit routines escritas em Assembler por alguém que se aposentou em 2009 e hoje cultiva orquídeas em Campinas.

A IA consegue interpretar um trecho como:

IF SALDO > LIMITE
   MOVE 'BLOQUEAR' TO ACAO
END-IF

Ela pode até gerar um Java elegante.

Mas dificilmente responderá perguntas como:

Por que esse programa executa apenas às terças-feiras?

Por que ele depende do fechamento do SMF?

Por que aguarda um arquivo SWIFT vindo da Bélgica?

Por que existe um passo IEBGENER aparentemente inútil?

Por que um job precisa terminar antes das 02h17?

E principalmente:

Quem será responsabilizado se o PIX parar durante duas horas?


O Conhecimento Tribal: A Tecnologia Mais Difícil de Migrar

Costumo dizer aos alunos do Bellacosa Mainframe:

O ativo mais caro de um banco não é o hardware.

Não é o software.

Nem mesmo os dados.

É o conhecimento acumulado por pessoas.

José está há trinta e dois anos na instituição.

Maria administra o RACF desde 1997.

Carlos conhece cada mensagem DFSxxxx de cabeça.

João sabe exatamente qual dataset pode ser apagado e qual causará um desastre regulatório.

Nenhum deles está em um repositório Git.

Nenhum deles está em um Wiki.

Nenhum deles aparece em um prompt.

Esse conhecimento mora na memória das pessoas.

E a IA não faz leitura telepática.

Ela apenas processa aquilo que recebeu.

Quando recebe documentação incompleta, devolve respostas incompletas.

Quando recebe caos, produz caos estatisticamente coerente.


O Marketing da Varinha Mágica Digital

Não tenho dúvidas.

Existe muita tecnologia impressionante surgindo.

Copilots.

Agentes autônomos.

Análise semântica.

Descoberta automática de dependências.

RAG.

Embeddings.

Vetorização.

Tudo isso possui enorme potencial.

Mas também estamos vivendo uma epidemia de apresentações corporativas.

Parece que alguns vendedores descobriram a Pedra Filosofal da Computação.

Basta enviar um ZIP contendo quarenta milhões de linhas COBOL.

E, algumas horas depois, nasce uma arquitetura nativa de nuvem.

Observabilidade pronta.

CI/CD configurado.

Microsserviços desacoplados.

Eventos Kafka.

Terraform.

OpenTelemetry.

Kubernetes.

Documentação impecável.

Testes automatizados.

Compliance.

Segurança.

Alta disponibilidade.

Tudo isso sem compreender uma única regra de negócio.

É quase uma versão tecnológica daquele vendedor de elixires do Velho Oeste.

Só que agora utilizando a palavra GenAI.


O Mainframe Continua Evoluindo

Enquanto parte do mercado tenta organizar funerais prematuros para o IBM Z, a IBM continua investindo bilhões de dólares na plataforma.

Hoje temos:

COBOL 6.x;

z/OS Connect;

OpenTelemetry;

Ansible;

Zowe;

Git integrado;

DevOps moderno;

API Economy;

Containers Linux on Z;

IA embarcada;

Criptografia acelerada por hardware;

Processadores especializados.

Ou seja.

O Mainframe não está parado.

O Mainframe está fazendo aquilo que sempre fez melhor.

Adaptando-se.

Em 1964 ele sobreviveu ao surgimento dos minicomputadores.

Nos anos 80 sobreviveu às workstations.

Nos anos 90 sobreviveu ao Client/Server.

Nos anos 2000 sobreviveu à internet.

Nos anos 2010 sobreviveu à cloud.

Nos anos 2020 provavelmente sobreviverá ao hype da IA Generativa.

Porque, no final das contas, bancos continuam precisando fechar o dia.

Companhias aéreas continuam emitindo passagens.

Governos continuam pagando benefícios.

Seguradoras continuam processando milhões de eventos.

E quase ninguém gosta quando esses sistemas param.


Talvez a Pergunta Esteja Errada

A pergunta nunca deveria ser:

"Como saímos do Mainframe?"

A pergunta correta talvez seja:

"Qual workload realmente precisa sair?"

Talvez um portal web de RH possa migrar.

Talvez um batch de impressão possa ser substituído.

Talvez um sistema satélite seja reescrito.

Mas talvez o motor central de compensação bancária deva permanecer exatamente onde está.

Porque engenharia não é religião.

Arquitetura não é ideologia.

Tecnologia não é torcida organizada.

A melhor plataforma é aquela que resolve o problema com menor risco, melhor disponibilidade, maior previsibilidade financeira e retorno sustentável.


Considerações Finais

Suspeito que a Gartner não esteja dizendo:

"Nunca migrem."

Também não está afirmando:

"Mainframe venceu."

A mensagem parece muito mais madura.

A IA Generativa será extraordinariamente útil para documentar, explicar, testar, modernizar e integrar aplicações existentes.

Mas ainda estamos distantes de confiar bilhões de dólares em transações financeiras a um modelo estatístico incapaz de compreender por que um velho JOB chamado FINA987 precisa começar precisamente às 02h17 da madrugada.

E talvez seja justamente aí que esteja a maior ironia desta década.

A tecnologia mais avançada da atualidade descobriu que o Mainframe nunca foi apenas COBOL.

Ele sempre foi memória institucional.

Processos.

Pessoas.

Histórias.

E algumas dezenas de milhares de linhas de JCL escritas por um Sysprog que provavelmente continua tendo razão.

https://www.gartner.com/en/newsroom/press-releases/2026-06-18-gartner-predicts-more-than-70-percent-of-mainframe-exit-projects-will-fail-due-to-overestimation-of-generative-ais-capabilities

sexta-feira, 8 de maio de 2026

☕🔥 O NOVO PROFISSIONAL MAINFRAME — O “SYSOP DO FUTURO” JÁ CHEGOU… E MUITA GENTE AINDA NÃO PERCEBEU 🔥☕

 

Bellacosa Mainframe fala sobre o futuro do profissional mainframe

☕🔥 O NOVO PROFISSIONAL MAINFRAME — O “SYSOP DO FUTURO” JÁ CHEGOU… E MUITA GENTE AINDA NÃO PERCEBEU 🔥☕

Durante anos o mercado repetiu a mesma ladainha:

“Mainframe morreu.”
“COBOL acabou.”
“Tudo vai para cloud.”
“Só tem profissional velho.”
“Daqui 5 anos ninguém mais usa z/OS.”

…e mesmo assim o mainframe continua processando bilhões de transações financeiras, cartões, seguros, companhias aéreas, governo, saúde e bancos do planeta inteiro.

O mais curioso?

Enquanto muita gente fazia meme do COBOL…
a IBM lançava:

  • novas releases do z/OS,
  • melhorias absurdas de segurança,
  • integração com Linux,
  • OpenShift,
  • containers,
  • APIs REST,
  • IA embarcada,
  • automação,
  • observabilidade,
  • criptografia quântica,
  • integração cloud híbrida,
  • DevOps,
  • Ansible,
  • Zowe,
  • Python no z/OS,
  • pipelines CI/CD,
  • modernização de CICS,
  • Db2 acelerado,
  • zCX,
  • Wazi,
  • integração com Kubernetes…

Ou seja:

o mainframe não ficou parado.

Muita gente ficou.

☕💾 O PROFISSIONAL MAINFRAME DE HOJE NÃO É MAIS “OPERADOR DE TELA VERDE”

Esse é talvez o maior choque cultural.

O profissional moderno de mainframe virou um híbrido raro no mercado.

Hoje ele precisa entender:

  • infraestrutura,
  • cloud,
  • segurança,
  • automação,
  • Linux,
  • APIs,
  • containers,
  • integração distribuída,
  • observabilidade,
  • DevOps,
  • redes,
  • performance,
  • IA,
  • além do velho e poderoso conhecimento de z/OS.

O cara que antes conhecia apenas:

  • JCL,
  • JES2,
  • TSO,
  • COBOL,
  • CICS,

…agora conversa com:

  • squads cloud,
  • times DevOps,
  • arquitetos AWS/Azure/GCP,
  • desenvolvedores Java,
  • SRE,
  • engenharia de plataforma,
  • segurança ofensiva,
  • APIs e microsserviços.

E isso muda completamente a carreira.

☕🔥 O MAINFRAME VIROU O “CORE ENGINE” DA CLOUD HÍBRIDA

Muita gente ainda pensa:
“Cloud substitui mainframe.”

Mas na prática o mercado percebeu algo diferente:

☁️ Cloud resolve elasticidade.
💾 Mainframe resolve missão crítica.

E o mundo corporativo descobriu que:

  • downtime custa bilhões,
  • segurança importa,
  • consistência importa,
  • throughput importa,
  • governança importa,
  • estabilidade importa.

Resultado?

O discurso mudou de:
“vamos eliminar o mainframe”

…para:
“como integrar o mainframe com cloud?”

Esse é o novo jogo.

E quem entende dos dois mundos virou profissional premium.

☕🚀 O PROFISSIONAL 50+ MAINFRAME NÃO ESTÁ ULTRAPASSADO

Esse talvez seja o ponto mais importante.

Existe uma geração inteira de profissionais carregando:

  • décadas de experiência,
  • conhecimento de negócio,
  • troubleshooting real,
  • visão sistêmica,
  • disciplina operacional,
  • capacidade analítica,
  • experiência em crises reais.

Essa experiência vale ouro.

Porque infraestrutura crítica não é TikTok.
Não é hype.
Não é framework da semana.

Banco não pode “dar refresh”.
PIX não pode travar.
Cartão não pode cair.
Folha de pagamento não pode falhar.

E quando tudo explode às 2h da manhã…
a empresa descobre rapidamente quem é profissional de verdade.

☕💡 O DESAFIO NÃO É IDADE. É ATUALIZAÇÃO.

O mercado não está descartando profissionais 50+.

O mercado está descartando quem:

  • parou no tempo,
  • rejeita aprender,
  • tem medo de mudança,
  • trata novidade como inimiga.

Porque hoje existe espaço gigantesco para:

  • mentor técnico,
  • especialista híbrido,
  • arquiteto legado/cloud,
  • modernização,
  • automação z/OS,
  • segurança,
  • observabilidade,
  • integração API/mainframe,
  • DevOps enterprise.

O profissional experiente que aprende:

  • Linux,
  • automação,
  • APIs,
  • Python,
  • cloud híbrida,
  • IA aplicada,
  • ferramentas modernas IBM,

vira praticamente um “unicórnio corporativo”.

☕🔥 IA NÃO VEIO PARA MATAR O MAINFRAME

Na verdade…

IA vai aumentar ainda mais a importância dos ambientes estáveis.

Porque IA precisa:

  • dados confiáveis,
  • processamento consistente,
  • segurança,
  • governança,
  • rastreabilidade.

E adivinha onde estão os dados mais críticos do planeta?

No mainframe.

O que muda é o papel do profissional.

Menos trabalho repetitivo.
Mais automação.
Mais integração.
Mais análise.
Mais arquitetura.
Mais inteligência operacional.

O futuro do mainframe não é apertar ENTER em tela verde.

É orquestrar ambientes híbridos gigantescos.

☕💾 HOME OFFICE MUDOU O JOGO

Antigamente o profissional mainframe era visto quase como:
“o cara preso no CPD.”

Hoje:

  • participa de reuniões globais,
  • trabalha remoto,
  • atende clientes internacionais,
  • opera ambientes gigantes de casa,
  • ensina online,
  • cria conteúdo,
  • ministra treinamento,
  • faz consultoria mundial.

O conhecimento ficou global.

E isso abriu espaço enorme para profissionais experientes.

☕🔥 O MAINFRAME NÃO MORREU. ELE EVOLUIU.

Talvez a maior mentira da TI tenha sido:
“mainframe vai acabar.”

O que acabou foi:

  • o isolamento do mainframe,
  • a cultura fechada,
  • o profissional que só conhecia um único mundo.

O novo profissional z/OS conversa com:

  • cloud,
  • Linux,
  • IA,
  • APIs,
  • automação,
  • DevSecOps,
  • observabilidade,
  • analytics,
  • containers.

E isso é fascinante.

☕🚀 UMA MENSAGEM PARA O PROFISSIONAL MAINFRAME 50+

Se você tem décadas de carreira:
não carregue vergonha da sua experiência.

Carregue orgulho.

Você sobreviveu:

  • a migração Y2K,
  • downsizing,
  • ondas Unix,
  • client/server,
  • virtualização,
  • internet,
  • cloud,
  • DevOps,
  • microsserviços,
  • IA…

…e o mainframe continua aqui.

Mas agora existe uma missão nova:

não proteger o passado.

E sim conectar o passado ao futuro.

Aprenda algo novo.
Teste Linux.
Brinque com Python.
Entenda cloud.
Automatize tarefas.
Explore IA.
Converse com equipes jovens.
Compartilhe experiência.

Porque o mercado não precisa apenas de juventude.

O mercado precisa de gente que entende o que acontece quando sistemas críticos realmente importam.

E nisso…
o profissional mainframe ainda é uma das peças mais valiosas da tecnologia mundial. ☕🔥

quinta-feira, 23 de abril de 2026

💣🔥 EzNoSQL no z/OS — O Golpe Silencioso: COMO O MAINFRAME APRENDEU JSON SEM PEDIR PERMISSÃO

 

Bellacosa Mainframe apresenta EzNoSQL no Z/OS

💣🔥 EzNoSQL no z/OS — O Golpe Silencioso: COMO O MAINFRAME APRENDEU JSON SEM PEDIR PERMISSÃO

Se você é COBOL júnior e acha que NoSQL é coisa de cloud, segura essa:
o mainframe não só entendeu… como absorveu o conceito sem quebrar uma linha de negócio.


🧬 Origem — de onde veio essa “mutação”?

Tudo começa com um problema real:

👉 Sistemas core em z/OS
👉 Dados rígidos em Db2, VSAM, IMS
👉 Mundo moderno falando JSON, REST, mobile, eventos

💥 Conflito inevitável.

A IBM já vinha preparando o terreno com:

  • Suporte a JSON no Db2
  • z/OS Connect expondo APIs
  • Integração com cloud

👉 O EzNoSQL for z/OS® surge como uma resposta pragmática:

💣 “E se a gente trouxer o modelo NoSQL pra dentro do mainframe ao invés de empurrar o mainframe pra fora?”


📅 História e lançamento

Diferente de produtos clássicos da IBM, o EzNoSQL não nasceu como um “big bang” tipo CICS ou Db2.

👉 Ele aparece por volta da década de 2010 (era pós-cloud), como parte da estratégia de:

  • Modernização de aplicações
  • APIs REST
  • Dados semi-estruturados

💡 Não é um produto mainstream amplamente divulgado como CICS ou Db2
👉 É mais nichado, usado em arquiteturas modernas híbridas


🧠 O que ele realmente é (explicação raiz)

Pensa assim, jovem COBOLista:

👉 VSAM = registro fixo
👉 Db2 = tabela estruturada
👉 EzNoSQL = documento flexível (tipo JSON)

Exemplo:

{
"conta": "123",
"cliente": "Bellacosa",
"apps": ["mobile", "web"],
"config": {
"notificacao": true
}
}

💣 Isso no mundo antigo exigiria:

  • várias tabelas
  • joins
  • redesign

👉 Aqui: 1 documento


⚙️ Como ele funciona na prática

Arquitetura típica:

App → API → z/OS Connect → COBOL → EzNoSQL

Integra com:

  • CICS
  • z/OS
  • Segurança via RACF

🚀 Vantagens (o lado poderoso)

🔥 1. Modernização sem reescrita

Você não precisa jogar COBOL fora.

👉 Você evolui.


⚡ 2. JSON nativo no mainframe

Perfeito para:

  • APIs REST
  • Mobile
  • Integrações modernas

🛡️ 3. Segurança absurda

Tudo herdado do mainframe:

  • RACF
  • auditoria
  • controle fino

🧩 4. Integração natural

Nada de ETL maluco ou sync externo.


⚠️ Desvantagens (a parte que ninguém te conta)

❌ 1. Não é cloud-native puro

Não compete diretamente com:

  • MongoDB
  • Cassandra

❌ 2. Escalabilidade diferente

Mainframe escala verticalmente
NoSQL moderno escala horizontalmente


❌ 3. Curva de entendimento

COBOL + JSON = choque cultural no começo 😅


🧪 Exemplo mental (modo Bellacosa)

🎯 Problema

Cliente muda preferências toda hora.

No Db2:

  • ALTER TABLE?
  • nova coluna?
  • impacto em batch?

💣 Dor.


🎯 Com EzNoSQL

{
"cliente": "123",
"preferencias": {
"tema": "dark",
"idioma": "pt-BR",
"notificacao": true
}
}

👉 Mudou? Só adiciona campo.

SEM ALTER TABLE.
SEM impacto global.


🧠 Curiosidades (nível raiz)

💡 EzNoSQL não substitui Db2
👉 Ele resolve outro tipo de problema

💡 Ele é mais comum em:

  • bancos
  • fintechs
  • modernização de legado

💡 Muitas vezes você usa sem perceber:
👉 “camada invisível” por trás de APIs


🥚 Easter Egg (essa é boa)

💣 O maior segredo:

Muita empresa diz:

👉 “Estamos usando microserviços modernos”

Mas por trás…

👉 ainda existe COBOL chamando algo tipo EzNoSQL no z/OS 😎


🧠 Insight profundo (pra você crescer rápido)

👉 O futuro NÃO é:

  • COBOL vs NoSQL
  • Mainframe vs Cloud

💣 O futuro é:

Mainframe + NoSQL + APIs + eventos


🧪 Analogia final (pra fixar de vez)

  • Db2 = planilha Excel organizada
  • VSAM = arquivo binário rápido
  • EzNoSQL = JSON flexível tipo API moderna

🚀 Conclusão

O EzNoSQL for z/OS® é uma peça estratégica:

👉 Ele permite que o mainframe:

  • fale JSON
  • exponha APIs
  • se conecte ao mundo moderno

💣 Sem perder:

  • performance
  • segurança
  • confiabilidade
  •  

domingo, 22 de março de 2026

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

Bellacosa Mainframe estuda o IBM BOB


☕ O Holocron do IBM Bob

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

"O medo de perder conhecimento leva ao caos. O caos leva à reescrita em Java. A reescrita em Java leva ao sofrimento."
— Mestre Sysprog Yoda, Sala de Operações do JES2, aproximadamente 03:17 da manhã.


Existe um momento na jornada de todo Padawan COBOL...

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

A aplicação que ele acabou de receber para manutenção possui mais de trinta anos.

Não existe documentação.

O analista funcional aposentou-se em 2014.

O arquiteto virou diretor.

O programador original mora em alguma praia do Nordeste e provavelmente desligou seu pager em 1998.

Os diagramas UML nunca existiram.

Os requisitos estão enterrados em milhares de linhas de COBOL, dezenas de PROCs catalogadas, JCLs obscuros, COPYBOOKS compartilhados por cinquenta programas diferentes, packages DB2 esquecidos, mapas BMS, tabelas VSAM, MQs espalhadas pela infraestrutura e algum código assembler que ninguém ousa tocar.

Você abre o primeiro programa.

São apenas 18 mil linhas.

Respira aliviado.

Até descobrir que ele faz PERFORM em outros vinte programas.

E então surge a pergunta inevitável.

"Será que existe alguma IA capaz de entender tudo isso?"

Talvez.

E talvez ela tenha um nome curioso.

IBM Bob.

Hoje vamos abrir mais um Holocron do Bellacosa Mainframe e conversar sobre aquilo que talvez seja uma das iniciativas mais interessantes da IBM para os próximos anos.


O que é o IBM Bob?

IBM Bob é apresentado como um assistente inteligente para desenvolvimento de software baseado em Inteligência Artificial.

Mas chamá-lo apenas de um gerador de código é diminuir bastante sua ambição.

Na prática, Bob parece querer ocupar um espaço muito maior.

Ele deseja ser:

  • Desenvolvedor auxiliar;

  • Revisor de código;

  • Especialista em documentação;

  • Tutor técnico;

  • Ferramenta de onboarding;

  • Auditor de segurança;

  • Agente de produtividade;

  • Companheiro corporativo de engenharia.

Talvez a melhor definição seja:

IBM Bob é uma tentativa da IBM de construir um "engenheiro de software virtual" especializado em ambientes empresariais.


IBM já tentou isso antes

A ideia não é nova.

IBM possui uma longa tradição em criar ferramentas para aumentar a produtividade.

DécadaFerramenta
1960FORTRAN Compiler
1970ISPF
1980CSP
1990VisualAge
2000Rational Rose
2010Bluemix
2020Watson
2025watsonx
2026IBM Bob

Existe uma espécie de evolução natural.

Antigamente tínhamos compiladores.

Depois IDEs.

Posteriormente ALM.

Mais tarde plataformas cloud.

Agora temos companheiros cognitivos.

Bob pode ser visto como uma mistura de:

  • GitHub Copilot

  • Rational Assistant

  • Watsonx

  • ChatGPT

  • Knowledge Assistant

Tudo isso embalado para empresas.


O problema que IBM está tentando resolver

Existe uma crise silenciosa acontecendo.

E ela não é tecnológica.

Ela é humana.

Estamos perdendo especialistas.

Todos os dias.

Pessoas que conhecem:

CICS

IMS

PL/I

COBOL

Natural

IDMS

JCL

Netview

SA z/OS

RACF

DB2

MQ

GDPS

SMP/E

RMF

SMF

SAF

VTAM

estão se aposentando.

E conhecimento não documentado possui meia vida curta.

Quando o especialista sai, o sistema continua.

Mas o entendimento desaparece.

Bob parece ser uma tentativa de capturar parte dessa inteligência institucional.


O maior erro do artigo original

O artigo que motivou esta discussão é bastante interessante.

Mas possui uma lacuna gigantesca.

Praticamente ignora o Mainframe.

E justamente aí está talvez a maior oportunidade do IBM Bob.

IBM possui bilhões de linhas COBOL instaladas.

Bilhões.

Sistemas que movimentam:

Cartões.

PIX.

Seguros.

Bolsas.

Impostos.

Benefícios sociais.

Compensação bancária.

Passagens aéreas.

Energia elétrica.

Telecomunicações.

Saúde.

Previdência.

Esses sistemas não vão desaparecer.

Eles precisam ser compreendidos.

E compreendê-los custa caro.

Muito caro.


Imagine conversar com um sistema legado

Imagine abrir um chat.

Perguntar:

Explique PROGCBL1.

Bob responde.


Sistema responsável pela liquidação diária.

Arquivos utilizados:

CLIENTES.KSDS

MOVTO.PS

Dependências:

DB2

MQ

CICS

Programas chamados:

CBL100

CBL200

CBL991

Pontos críticos:

Falta tratamento SQLCODE +100.

Possível deadlock.

Campo SALDO alterado em três locais.


Pronto.

Dias de investigação reduzidos para minutos.


O Holocron dos COPYBOOKS Perdidos

Todo Padawan COBOL conhece esse momento.

Você encontra:

COPY CLI0001

COPY BAN0007

COPY FIS9999

COPY SEG1234

Pergunta:

"Onde estão?"

Ninguém sabe.

Bob poderia consultar:

Git

Endevor

Changeman

Panvalet

Librarian

PDS

PDSE

e responder.


COPY SEG1234

Localização:

CORP.COBOL.COPYLIB

Última alteração:

15/03/2024

Responsável:

Equipe Seguros

Campos utilizados:

CPF

SALDO

RISCO

TIPO_APOLICE


Você acabou de economizar duas horas.


O poder do entendimento semântico

Talvez a maior revolução seja essa.

Não escrever código.

Entender sistemas.

Pergunta:

Quem atualiza SALDO_DISPONIVEL?

Resposta:

PROG010

PROG200

TRN991

JOBNIGHT

Impacto:

17 programas.

Possíveis efeitos colaterais:

Extrato.

PIX.

TED.

Internet Banking.


Isso é engenharia reversa inteligente.


Bob poderia ser o arqueólogo corporativo

Hoje fazemos arqueologia manual.

ISPF.

3.14.

3.4.

SUPERC.

FILEAID.

SPUFI.

SDSF.

JES2.

TSO.

Bob poderia atuar como um arqueólogo digital.

Encontrando relações invisíveis.


O sonho do Sysprog

Imagine perguntar.


Explique este JCL.


Resposta:

Job diário.

Executa às 23h.

Consome 4 CPUs.

Lê VSAM.

Executa DFSORT.

Atualiza DB2.

Publica mensagem MQ.

Gera SMF.

Último ABEND:

S806.

Ocorrências:


Ou então.


Por que ocorreu este ABEND?


S0C7

Campo NUMERO-CONTA possui dados inválidos.

Registro 145783.

Programa:

COBLIQ01

Parágrafo:

3000-PROCESSA


Isso seria quase magia.

Mas magia suficientemente avançada é indistinguível da tecnologia.


O problema dos LLMs

Nem tudo são flores.

Existe um problema sério.

LLMs alucinam.

E sistemas corporativos não aceitam alucinações.

Bob não pode inventar.

Não pode responder.

"Talvez."

Em bancos.

Talvez custa milhões.

Portanto provavelmente Bob utilizará RAG.

Retrieval Augmented Generation.

Consultando:

Catálogos.

DB2 Catalog.

Git.

Endevor.

SMF.

SDSF.

WLM.

RMF.

Copybooks.

Documentação interna.

Tickets Jira.

Confluence.

Runbooks.


Segurança

Este é provavelmente o aspecto mais importante.

Um banco não pode enviar CPF para um LLM público.

Nem dados médicos.

Nem cartões.

Nem chaves PIX.

Bob precisa viver próximo dos dados.

Talvez em:

LinuxONE.

OpenShift.

Cloud privada.

IBM Z.

Com recursos de:

LGPD.

PCI DSS.

SOX.

Mascaramento.

Auditoria.

Guardrails.

Zero Trust.


O verdadeiro diferencial

Acredito que Bob cometeria um erro enorme tentando competir diretamente com Copilot.

Copilot escreve código.

Bob deveria compreender empresas.

Ele deveria ser especialista em:

CICS.

IMS.

MQ.

COBOL.

JCL.

DB2.

VSAM.

RACF.

SA z/OS.

Netview.

GDPS.

WLM.

DFSMS.

SMP/E.


Prompt:

Crie API REST para este COBOL.

Resposta:

OpenAPI.

JSON.

COBOL parser.

z/OS Connect.

Swagger.

JCL Deploy.

Tudo documentado.


O Holocron Vivo da Empresa

Talvez seja essa a visão mais bonita.

Bob não substituirá desenvolvedores.

Ele preservará memória.

Será um Holocron corporativo.

Um aprendiz conversa.

Pergunta.

Aprende.

Entende.

Documenta.

Compartilha.

E a empresa deixa de depender exclusivamente da memória de poucas pessoas.


O futuro pertence aos desenvolvedores que sabem conversar com IA

Muitos têm medo.

"IA vai substituir programadores."

Talvez substitua quem apenas copia código.

Mas dificilmente substituirá quem entende negócio.

Quem entende processamento batch.

Quem entende compensação bancária.

Quem conhece JES2.

Quem domina CICS.

Quem compreende RACF.

Quem sabe porque um catálogo ICF ficou inconsistente às três da manhã.

Esses profissionais continuarão valiosos.

Talvez ainda mais.

Porque agora terão um novo aliado.

Um companheiro.

Um assistente.

Um aprendiz digital.

Um pequeno droide azul corporativo.

Um Bob.


Considerações Finais

Existe uma frase muito conhecida na comunidade de tecnologia:

"Todo sistema legado é apenas um sistema que continua pagando as contas."

IBM conhece essa realidade melhor do que ninguém.

E talvez o IBM Bob seja uma das primeiras tentativas realmente sérias de transformar cinquenta anos de conhecimento corporativo em algo conversável, pesquisável e ensinável.

Se conseguir compreender verdadeiramente COBOL, JCL, CICS, IMS, DB2, VSAM e os inúmeros segredos escondidos nos data centers do planeta, Bob poderá se tornar muito mais do que um assistente de programação.

Ele poderá tornar-se o primeiro grande Holocron do Mainframe Moderno.

E para nós, Padawans COBOL, isso significa algo extraordinário.

Pela primeira vez em décadas, talvez seja possível sentar diante de um sistema com quarenta anos de idade, tomar uma caneca de café, fazer uma pergunta simples e ouvir uma resposta compreensível.

E convenhamos...

Isso parece muito mais próximo da Força do que da simples Inteligência Artificial.


quarta-feira, 12 de janeiro de 2022

Do Mainframe a Cloud Computer, la e ca outra vez...

 

Bellacosa Mainframe e os primordios da nuvem


Do Mainframe a Cloud Computer, la e ca outra vez...


Conceitos sobre Nuvem / Cloud Computer

Salve jovem padawan, feliz 2022 e hoje voltamos a ativa, passado as festividades da Epifania dos Reis Magos, iniciamos o ano com um artigo de conceitos gerais, uma ferramenta para elucidar alguns termos usados nos cursos, principalmente nos AWS da Amazon e Azure da Microsoft.

Mas antes de iniciarmos, saiba que a origem desta moda das nuvens, iniciou-se em tempos idos, afinal tudo era nuvem, calma, não entre em pânico, o tiozão não surtou nem bebeu demais nas festas, mas nos primórdios da computação na Era de ouro dos Mainframes, tudo estava armazenado num servidor, longe da sede da empresa, muitas vezes a dezenas, quiçá centenas de quilômetros de distância.

O Centro de Processamento de Dados, era um servidor conectado via linha discada através de modens, que distribuía a informação localmente em terminais 3270 e posteriormente em emuladores de terminal 3270, através de conexões via ponte em CICS, época que os caracteres EBCDIC imperavam, era em que o espaço em disco era caríssimo, memoria idem, as empresas alugavam tempos de processamento com X ciclos de CPU, X espaço de memória e disco.

O armazenamento era feito em tapes e cartridges com a utilização de inúmeros aplicativos em COBOL, PLI e Assembly para gerar copias via JCL, que encareciam o processo e limitava o armazenamento de dados, obrigando que as empresas usassem estratégias locais para solucionar questões estratégicas analisando os dados.

Anos 60 a padronização dos serviços

Com pouco mais de duas décadas, muitos fabricantes e pouca padronização, situação que obrigou ao governo americano a lançar inúmeras Normas ISO/ASA para definir os tipos de serviços prestados em processamento de dados, as linguagens de programação aceitas e outras especificações técnicas que serviram para impulsionar o serviço e democratizar o acesso dos Computadores as Universidades e Empresas civis.

Anos 70 a Mainframe Cloud

Um pouco abstrato, um pouco imaginação do tiozão, porem nos primórdios os Mainframes, capitaneado a pela gigante azul, a IBM dominou o mercado e vendia/alugava serviços : serviços de codificação, processamento de dados, armazenamento e impressão de relatório, basicamente os clientes utilizavam-se de terminais para acessar os serviços e consumirem as informações, poucas empresas tinham capital suficiente para serem donas de 100% do parque informático e os Centro de Processamento situação muito semelhante com os services atuais (IaaS, PaaS, SaaS e DaaS, com uma vantagem adicional a concorrência era baixa e a maior parte das patentes e pessoal qualificado era da empresa.

Anos 80 e a multiplicação dos dados

Com o advento da microinformática e o uso intensivo do Clipper e base de dados XBase, surgiu novos ares no processamento de dados num mundo off-line, as empresas sentiram o poder da análise de dados e acumulação de informações e uso de planilhas de dados Lotus 123 e Supercalc..

Uma era fortemente ligada aos mainframes que geravam dados brutos e transmitiam via arquivos sequenciais em TXT, convertidos de EBCDIC para ASCII via protocolo FTP de alta para baixa plataforma e os pioneiros em ciências de dados, criavam programa estatísticos ou planilhas para explorarem tendências e acúmulos de dados.

Antes de prosseguirmos, recordem que era uma era off-line, onde muita das informações eram transmitidas via disquetes de 5 ¼, 3 ½ de face simples e dupla de acordo com a evolução, era uma era de rede em cabo coaxial, bem difícil de operar e com limitação de largura banda.

Anos 90 e a era da internet

Com a evolução tecnológica dos anos 90, o antigos PC XT rapidamente tornou-se obsoletos, o milagre da miniaturização e a produção em massa, facilitou a evolução, primeiros 286, 386, 486 e Pentiuns.

A linguagem Clipper e o padrão DBase com suas inúmeras versões, facilitaram o processo de processamento de dados, com utilização de fórmulas matemáticas e estatísticas sofisticadas e troca de dados na velocidade da luz, através de linhas discadas com modens rápidos e internet rápida com poderosos servidores.

Nisso foram surgindo novas linguagens e formatos de base de dados com SQL poderoso, pela primeira vez o domínio dos mainframes foi abalado, acuado com os ERPs e descentralização dos CPDs.

Y2K um fantasma na virada do século

Lembra do custo de armazenamento e uso de memória nos Mainframes nos primórdios da computação? Uma solução simples e econômica que atendia a 100% dos problemas na época. Para que século, cortaram 2 bytes do armazenamento e processamento da Data, afinal ninguém usava o 19 para nada, em milhões de registros era moedinhas no cofre, ninguém contava que os programas iriam durar tanto, e o doce cortar de bytes, gerou um bug, o bug do milênio transformou-se num monstro.

A resposta das empresas e consultorias informáticas virou uma enorme bola de neve, sorvedora de recursos e os custos para conversão de antigos programas em linguagens de alta plataforma, quebrou empresas e assustou gestores e investidores que forçou medidas drásticas aos sistemas centrais, deixando atemorizados acionistas e sociedade civil.

O JAVA e o MySQL, o Oracle, o Python, C e seus dialetos, o MS SQL e o pacote MS Office criaram um mundo novo na programação e o conceito de armazenamento de dados, fora do Mainframe e dentro de Servidores Web.

Anos turbulentos devido ao colapso econômico da Bolha da Internet e o atentado suicida as Torres gêmeas do Word Trade Center em Nova Iorque com perda de muita informação armazenada nos servidores locais.

Primeira década do novo milênio

O mundo se recuperava do colapso econômico e tudo parecia que estava bem, porem o mercado especulativo imperava, a formula de Back-Scholes-Merlon transformou o Mercado Financeiro um grande cassino, que gerou a grande bolha especulativa detonada em 2008.

As empresas buscavam soluções entre os servidores locais, servidores backups, mainframes e repentinamente as empresas viram-se numa arapuca, sem dinheiro para investir e com falências em todo o mercado.

A resposta foi cortar custos e com isso voltamos aos primórdios da informática e os servidores transformaram-se em sistemas centrais e empresas ocupam o nicho da IBM, vendendo espaço de armazenamento, serviço de processamento de dados e codificação.

Nuvem / Cloud

Uma metáfora para descrever a rede global de servidores temos inúmeros Centros de Processamento de Dados controlados por poucas empresas Amazon, Google, Microsoft, VMWare, SalesForce, RackSpace, Verizon, Cisco, entre outras. São computadores espalhados por todo o mundo que armazenam dados, executam aplicativos e fornecem serviços aos usuários por meio da internet, ocorrendo um movimento de migração e modernização de softwares.

Computação sem servidor

Foi o modelo de negócios principal da IBM no passado, hoje é um método desenvolvido para fornecer serviços de back-end às empresas, oferecendo tecnologias para escrever e executar códigos, gerir dados e integrar aplicações, tudo isso sem a necessidade de gerenciar servidores.

Uma verdadeira volta as origens, desta vez com a vantagem de existirem mais players no mercado, a concorrência ajuda a melhorar a qualidade e os custos dos serviços.

Redundância de dados

Duplicação de componentes para garantir serviço ininterrupto e evitar perda de dados. Para isso, são feitos backups dos dados em diferentes datacenters para acionar imediatamente quando houver falhas em algum deles.

Eu trabalhei no Banco Real na década de 90 e além, havia 3 grandes maquinas, o SP11, SP51 e o CA81, respectivamente na sede do Banco, na IBM SP e IBM Hortolândia, garantindo a execução dos processamentos batch e rotinas onlines durante 24 horas dias, 7 dias por semana e 365 dias ao ano.

A parte mais importante era a garantia de replicação dos dados e zero downtime. Participei de algumas simulações e os serviços levavam menos de um minutos para restabelecerem, trocava-se o servidor sem percebermos.

Middleware

O software que fica entre um sistema operacional e os aplicativos executados nele que permite a comunicação e o gerenciamento de dados para aplicativos distribuídos, como os aplicativos baseados em nuvem.

No passado era o COBOL, Natural, PL/I, Rexx, Assembly, que operavam em processo batchs via JCL, atualmente o JAVA e o C Sharp levam uma ligeira vantagem, mas existem linguagens e tecnologias para dar e vender, tornando o mercado caótico.

Services

Existem 4 tipos de serviços fortemente ligados a nuvem, mas antes a verdadeira imagem que devemos pensar é a terceirização dos diversos elementos ligado aos serviços informáticos. Pense uma grande empresa, necessita de uma equipe para manutenção de hardware, uma equipe de gestão de servidores, uma equipe de análise de incidentes e ocorrências, uma equipe de sustentação, uma equipe de desenvolvimento, uma equipe de base de dados, uma equipe de análise e organização e métodos, uma equipe de gestão de auditoria e acesso e finalizando uma equipe de comunicação e redes.

Devido a complexidade constantes, a necessidade de treinamentos e os altos custos envolvidos na aquisição de equipamento, locação de espaço, instalação de redes e comunicação e a gestão de pessoal implicou na evolução forçada dos CPDs e os inúmeros serviços que as SLAs, não conseguiam contemplar.

Por isso surgiram os serviços: IaaS, PaaS, SaaS, DaaS entre outros, que veremos nos parágrafos abaixo.

IaaS (Infrastructure as a Service)

é um tipo de serviço de computação em nuvem que oferece recursos fundamentais de computação, armazenamento e rede sob demanda e pagos conforme o uso, ou seja, um modelo de computação em nuvem que fornece recursos de computação na nuvem (como servidores, armazenamento, rede e software operacional) em um ambiente virtualizado. Ex: IBM Cloud.

Qualquer semelhança com os velhos serviços de mainframe é mera coincidência. Será?

PaaS (Plataform as a Service)

é um ambiente de desenvolvimento e implantação completo na nuvem, com recursos que permitem a você fornecer tudo, de aplicativos simples baseados em nuvem a sofisticados aplicativos empresariais habilitados para a nuvem, sem a necessidade de aquisição de licenças e pessoal técnico. .

Uma plataforma de nuvem completa para o desenvolvimento, execução e gestão de aplicações. Ex: AWS (Amazon Web Services), porém esse processo não é linear e simples, em alguns momentos ocorrem situações catastróficas como exemplo o TSB Bank.

SaaS (Software as a Service)

Uma inovação devida aos altos custos de aquisição de software, no passado fomentou muita pirataria e quebras de patentes. Também chamado de aplicativo hospedado, é um tipo de software que não precisa ser adquirido, instalado ou executado em computadores dos usuários. Ex: Adobe Creative Cloud.

DaaS (Desktop as a Service)

Os serviços evoluíram tanto, que atualmente até o Desktop é emulado, a semelhança dos antigos terminais 3270 da IBM, podemos acessar um determinado tipo de equipamento, bem como inúmeros Sistemas Operacionais de acordo com nossa necessidade.

Nuvem pública

Um dos primeiros serviço oferecidos, no passado pessoas e empresas armazenavam imagens, vídeos e arquivos de negócio. São serviços oferecidos por terceiros através da Internet e disponíveis a qualquer pessoa que queira adquirir. Ex: Google Cloud Platform.

Nuvem privada

Semelhante a nuvem publica, mas com melhores ferramentas de segmentação e segurança, pertinente para empresas com dados mais sensíveis. São serviços oferecidos pela Internet ou uma rede interna privada apenas para uso exclusivo de usuários selecionados. Ex: Cisco Cloud Center.

Nuvem híbrida

Como o mercado é dinâmico, e os custos envolvidos acabam criando barreiras, solucionadas através de packages que unem nuvem publica com a privada. Uma nuvem que combina nuvens públicas e privadas com tecnologia que permite que dados e aplicativos sejam compartilhados entre elas. Ex: Azure Stack.

Virtualização

O ato de criar uma versão virtual do ambiente de computação em vez de uma versão física, incluindo hardware, sistema operacional e dispositivos de armazenamento.

Conclusão

Caro padawan, espero não ter me estendido muito, mas tentei apresentar de maneira resumida o universo do Cloud Computer, utilizando como metodologia fazer uma comparação aos antigos sistemas centrais de Mainframe e a evolução com um pouco da historia recente.

Foi um mix de informações, onde aproveitei para tirar algumas duvidas no sites da Azure, AWS, Google e Wikipedia, qualquer duvida ou correção chama aqui ou no Discord.

Espero ter ajudado, lembre-se que é um trabalho continuo, sempre que possível irei atualizar e agregar novas informações.

No alt text provided for this image


Mais momento jabá, para distrair, vamos conhecer um pouco da Revolução Paulista de 1932, que completa 90 anos e em Itatiba a prefeitura fez uma justa homenagem ao transladar os restos mortais de um soldado constitucionalista para o Obelisco Mausoléu do Ibirapuera em SP, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=yqYWSLtsrps


https://www.linkedin.com/in/vagnerbellacosa/


https://github.com/VagnerBellacosa/


Pode me dar uma ajudinha no YouTube?


https://www.youtube.com/user/vagnerbellacosa


hashtagDesafio21DiasNaDIO

publicado originalmente em : https://web.dio.me/articles/do-mainframe-a-cloud-computer-la-e-ca-outra-vez/



Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988