Translate

terça-feira, 15 de outubro de 2024

Doubleagent : O Pandaren que Ensinou ao Mundo que Colher Flores Também é Engenharia

 

Bellacosa Mainframe e o lendario  Doubleagnt no WoW

☕ Um Café no Bellacosa Mainframe

Doubleagent

O Pandaren que Ensinou ao Mundo que Colher Flores Também é Engenharia

"Enquanto milhões corriam para derrotar chefes, um único jogador decidiu caminhar devagar. Enquanto todos buscavam experiência pela força, ele encontrou evolução pela persistência. E sem perceber, escreveu uma das histórias mais inspiradoras da cultura gamer."

Existe uma antiga lição que todo profissional IBM Z aprende cedo.

Nem sempre o engenheiro mais valioso é aquele que resolve o maior incidente.

Muitas vezes é aquele que passou vinte anos aprendendo silenciosamente cada detalhe do sistema.

No mundo dos games existe uma história quase lendária que transmite exatamente essa filosofia.

Ela não fala sobre espadas lendárias.

Não fala sobre derrotar dragões.

Não fala sobre equipamentos épicos.

Ela fala sobre... colher flores.

Sim.

Flores.

E talvez justamente por isso seja uma das histórias mais bonitas já escritas pela comunidade de World of Warcraft.

Hoje vamos conhecer a jornada de Doubleagent, um jogador que provou que existe mais de um caminho para evoluir e cuja persistência acabou inspirando milhares de jogadores e, possivelmente, influenciando o nascimento de um dos maiores clichês das light novels e dos animes isekai modernos.

Pegue seu café.

Esta não é uma história sobre Warcraft.

É uma história sobre dedicação.


O mundo sempre escolhe o caminho mais rápido

Imagine um novo jogador entrando em World of Warcraft.

O caminho parece óbvio.

Aceitar missão.

Matar monstros.

Ganhar experiência.

Subir de nível.

Repetir.

Foi assim durante anos.

Toda a comunidade estava condicionada a acreditar que aquele era "o jeito certo" de jogar.

Isso lembra muito um programador iniciante.

Ele acredita que existe apenas um caminho:

Aprender COBOL.

Depois JCL.

Depois VSAM.

Depois CICS.

Depois Db2.

Depois IMS.

Depois MQ.

Depois APIs.

Depois DevOps.

Mas os verdadeiros mestres normalmente enxergam possibilidades onde ninguém mais olha.

Foi exatamente isso que Doubleagent fez.


Uma decisão completamente maluca

Quando os Pandaren foram lançados em Mists of Pandaria, eles possuíam uma característica curiosa.

Durante os primeiros níveis permaneciam neutros.

Somente ao concluir a ilha inicial deveriam escolher:

Aliança

ou

Horda.

Todo mundo fazia essa escolha.

Exceto uma pessoa.

Doubleagent pensou:

"E se eu nunca escolher nenhum dos dois?"

Isso significava permanecer preso para sempre na Wandering Isle.

Sem cidades.

Sem raids.

Sem PvP.

Sem dungeons.

Sem profissões avançadas.

Sem conteúdo novo.

Sem praticamente nada.

A maioria das pessoas considerou aquilo um desperdício de personagem.

Mas ele enxergou um laboratório.


O nascimento de um desafio impossível

Na ilha existiam apenas alguns recursos.

Algumas plantas.

Alguns minérios.

Poucos NPCs.

Nada que lembrasse uma progressão tradicional.

Mas havia um detalhe importante.

Cada erva coletada concedia experiência.

Cada minério também.

Era pouca.

Muito pouca.

Ridiculamente pouca.

Enquanto outros ganhavam milhares de pontos derrotando inimigos, Doubleagent recebia pequenas gotas de experiência.

Era como encher um lago usando um conta-gotas.

Mesmo assim ele continuou.


O poder da repetição

Todos os dias.

Coletava.

Esperava o reaparecimento das plantas.

Coletava novamente.

Esperava.

Repetia.

Durante semanas.

Depois meses.

Depois anos.

Sem glamour.

Sem chefões.

Sem espadas brilhando.

Sem montarias lendárias.

Sem transmissões épicas.

Apenas disciplina.

Se isso lhe parece familiar...

É porque exatamente assim funciona a carreira de um especialista IBM Z.


O verdadeiro treinamento Jedi

Um Padawan COBOL costuma perguntar:

"Quanto tempo demora para aprender CICS?"

A resposta correta é:

Depende de quantas flores você está disposto a colher.

Porque aprender CICS não acontece apenas lendo apostilas.

Você compila.

Erra.

Corrige.

Compila novamente.

Descobre um AEI9.

Depois um ASRA.

Depois um SOS.

Depois entende COMMAREA.

Depois Channels.

Depois Containers.

Depois percebe que ainda sabe muito pouco.

O crescimento ocorre da mesma maneira que Doubleagent subia de nível.

Um pequeno avanço por vez.


A comunidade começou a prestar atenção

No início todos riram.

Depois ficaram curiosos.

Depois começaram a acompanhar.

Quando ele alcançou níveis cada vez maiores, algo mudou.

As pessoas perceberam que ele havia encontrado uma interpretação completamente diferente das regras do jogo.

Ele não estava quebrando nenhuma regra.

Apenas utilizava uma mecânica ignorada pela maioria.

Isso acontece frequentemente também na tecnologia.

Um recurso existe há décadas.

Ninguém utiliza.

Até que alguém encontra uma aplicação brilhante.


O programador que lê o manual

No IBM Z existe uma frase antiga.

"O manual sempre esteve certo."

Quantos profissionais ignoram a documentação?

Quantos nunca exploram comandos pouco conhecidos do IDCAMS?

Quantos jamais abriram um manual do DFSORT?

Quantos desconhecem recursos do Enterprise COBOL 6.5?

Doubleagent fez justamente o contrário.

Ele estudou o sistema.

Encontrou uma funcionalidade aparentemente insignificante.

Transformou aquela funcionalidade em sua estratégia principal.

Isso não é sorte.

Isso é engenharia.


Quando a persistência vira arte

Existe uma enorme diferença entre insistência e persistência.

Insistência ignora resultados.

Persistência aprende com eles.

Doubleagent não coletava ervas mecanicamente.

Ele estudava rotas.

Calculava tempos de reaparecimento.

Otimizava trajetos.

Reduzia desperdícios.

Transformou uma caminhada em algoritmo.

Sem perceber, aplicava conceitos que hoje chamamos de otimização operacional.


A filosofia Kaizen escondida em Azeroth

Os japoneses possuem um conceito chamado Kaizen.

Melhoria contínua.

Um pequeno avanço.

Todos os dias.

Não é necessário mudar o mundo hoje.

Basta melhorar um pouco.

Foi exatamente isso.

Uma flor.

Depois outra.

Depois outra.

Depois milhares.

O resultado final parecia impossível.

Mas nasceu de pequenas ações repetidas.


A Blizzard percebeu

Chega um momento em que uma comunidade inteira passa a respeitar alguém.

A Blizzard também percebeu.

Doubleagent tornou-se um símbolo de criatividade.

Sua história foi divulgada por sites especializados.

Entrevistas surgiram.

Milhares de jogadores passaram a acompanhar sua evolução.

Mais tarde, a Blizzard criou uma homenagem dentro do próprio jogo, inspirando um NPC em seu estilo de jogo e aparência.

Pouquíssimos jogadores recebem esse tipo de reconhecimento.

Não porque eram os mais fortes.

Mas porque mostraram uma forma completamente nova de viver Azeroth.


E os mangakás?

É impossível afirmar que um autor específico copiou Doubleagent.

Não existe declaração oficial estabelecendo essa relação.

Mas existe algo muito interessante.

Depois dessa época, houve uma explosão de web novels japonesas protagonizadas por:

  • Herbalistas.

  • Coletores.

  • Fazendeiros.

  • Alquimistas.

  • Artesãos.

  • Cozinheiros.

  • Mineradores.

  • Domadores de monstros.

O herói deixava de evoluir derrotando monstros.

Passava a crescer dominando um ofício.

É exatamente a mesma inversão de perspectiva que tornou Doubleagent famoso.

Os leitores japoneses adoraram essa ideia porque ela dialoga com valores profundamente presentes na cultura do país: disciplina, aperfeiçoamento contínuo e respeito pelo trabalho bem executado.


O herói improvável

Observe os protagonistas dos isekais modernos.

Muitos começam sendo ridicularizados.

Recebem uma classe considerada inútil.

"Farmer."

"Gatherer."

"Crafter."

"Potion Maker."

Depois descobrem que justamente aquela habilidade ignorada possui potencial infinito.

Isso lembra muito o COBOL.

Durante anos ouvimos:

"O mainframe vai morrer."

"O COBOL acabou."

"O futuro está apenas na nuvem."

Décadas depois...

Os bancos continuam funcionando.

As bolsas continuam operando.

Os cartões continuam autorizando transações.

Os sistemas continuam processando milhões de operações por segundo.

Às vezes a classe desprezada é justamente a mais poderosa.


O paralelo perfeito

Imagine dois Padawans.

O primeiro quer aprender tudo em três meses.

O segundo aprende um comando novo por dia.

Depois um utilitário.

Depois um recurso do DFSORT.

Depois um parâmetro do IDCAMS.

Depois um comando SDSF.

Depois um relatório RMF.

Depois um registro SMF.

Cinco anos depois...

Quem realmente domina o sistema?

Doubleagent responde essa pergunta sem dizer uma única palavra.


O verdadeiro significado do nível máximo

No RPG, o nível máximo representa poder.

Na vida profissional, representa responsabilidade.

Você não se torna um especialista IBM Z porque fez cinquenta cursos.

Você se torna especialista quando consegue resolver problemas que ninguém mais consegue.

Isso exige exatamente o mesmo ingrediente utilizado por Doubleagent.

Tempo.

Não existe atalho para experiência.

Existe apenas prática acumulada.


Um Easter Egg para os Padawans

Existe uma curiosidade interessante.

Em muitos RPGs japoneses, a habilidade Gathering costuma parecer inútil nas primeiras horas.

Entretanto, perto do final do jogo, ela fornece ingredientes capazes de criar armas e poções superiores às obtidas derrotando chefes.

É quase uma metáfora da vida.

O conhecimento aparentemente simples de hoje pode ser exatamente aquilo que resolverá o maior problema amanhã.

Quem aprende profundamente fundamentos quase sempre surpreende quando chegam os desafios mais difíceis.


O legado de Doubleagent

Doubleagent não venceu o jogo.

Ele redefiniu a forma como as pessoas enxergavam o jogo.

Essa talvez seja a maior conquista que alguém pode alcançar.

Não mudar as regras.

Mas mudar a maneira como todos interpretam as regras.

Essa é exatamente a missão de grandes engenheiros.

Grandes professores.

Grandes arquitetos.

Grandes programadores.


O conselho final do Mestre Bellacosa

Se você é um Padawan COBOL, provavelmente olha para profissionais experientes e pensa:

"Como eles aprenderam tudo isso?"

A resposta é mais simples do que parece.

Eles colheram flores.

Durante anos.

Cada manual lido foi uma flor.

Cada ABEND resolvido foi uma flor.

Cada JCL corrigido foi uma flor.

Cada programa COBOL compilado foi uma flor.

Cada madrugada analisando um dump foi uma flor.

Cada curso concluído foi uma flor.

Cada erro cometido foi uma flor.

Nenhuma delas parecia importante isoladamente.

Mas juntas construíram uma carreira inteira.

Doubleagent nos lembra de que evolução não depende apenas de velocidade. Ela depende de direção, constância e propósito.

No universo IBM Z, os profissionais mais admirados raramente foram aqueles que buscavam atalhos. Foram aqueles que aceitaram caminhar longas distâncias, aprender os fundamentos e aperfeiçoar-se continuamente. Assim como o Pandaren que preferiu colher ervas em vez de correr atrás da próxima batalha, o verdadeiro mestre entende que o conhecimento sólido cresce devagar, raiz por raiz.

Da próxima vez que você abrir o ISPF, escrever um novo programa COBOL ou estudar mais um capítulo sobre CICS, lembre-se de Doubleagent.

Talvez você ache que está apenas colhendo mais uma flor.

Mas é exatamente assim que as maiores lendas começam.


segunda-feira, 14 de outubro de 2024

O Guia Definitivo para um Programador COBOL Padawan Entender Como a Inteligência Artificial Aprendeu a Pensar — e Como Você Pode Acompanhar Essa Jornada Sem Medo

 

Bellacosa Mainframe e as redes neurais

☕ Um Café no Bellacosa Mainframe

Redes Neurais sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender Como a Inteligência Artificial Aprendeu a Pensar — e Como Você Pode Acompanhar Essa Jornada Sem Medo

"Durante décadas os programadores COBOL ensinaram computadores a executar regras de negócio. Agora estamos ensinando computadores a descobrir regras sozinhos. Parece uma revolução. Na verdade, é apenas mais um capítulo da evolução da Computação."


Introdução

Existe uma pergunta que recebo praticamente todas as semanas.

"Bellacosa, eu programo COBOL há anos. Ainda dá tempo de aprender Inteligência Artificial?"

Minha resposta sempre é a mesma.

Não apenas dá tempo. Você possui uma vantagem enorme.

Pode parecer estranho ouvir isso justamente quando o mercado parece girar exclusivamente em torno de Python, GPUs, Transformers, ChatGPT e modelos gigantescos.

Mas existe uma verdade que poucos comentam.

Os profissionais que realmente conseguem construir soluções de IA corporativa são aqueles que entendem de sistemas.

E ninguém entende sistemas corporativos melhor do que quem passou anos trabalhando com:

  • COBOL

  • CICS

  • Db2

  • MQ

  • VSAM

  • Batch

  • JCL

  • z/OS

O mercado fala muito sobre modelos.

Mas as empresas vivem de processos.

E IA sem processos não resolve problemas reais.

Neste café vamos entender como nasceram as Redes Neurais, por que cada arquitetura surgiu, quais problemas resolveram e, principalmente, como um Programador COBOL Padawan pode construir sua própria trilha rumo ao universo da Inteligência Artificial.

Pegue sua caneca.

Hoje vamos atravessar quarenta anos de evolução tecnológica.


O cérebro sempre foi a inspiração

Desde os anos 1940 os cientistas tentavam responder uma pergunta simples.

Como um cérebro aprende?

Eles perceberam que um neurônio faz algo extremamente simples.

Recebe sinais.

Processa.

Decide.

Envia um novo sinal.

Visualmente:

Entradas

↓

Neurônio

↓

Saída

Individualmente parece pouco.

Mas agora imagine:

100 bilhões de neurônios.

Cada um conectado a milhares de outros.

É assim que nosso cérebro funciona.

As Redes Neurais tentam reproduzir exatamente essa ideia.


O primeiro erro dos iniciantes

Quando alguém vê IA pela primeira vez costuma imaginar:

"Existe uma única Inteligência Artificial."

Não existe.

Na verdade existem dezenas de arquiteturas diferentes.

Cada uma foi criada para resolver um problema específico.

É exatamente igual ao mundo Mainframe.

Você nunca usaria:

  • CICS para processamento Batch.

Nem

  • JCL para criar uma API REST.

Nem

  • Db2 para substituir MQ.

Cada tecnologia nasceu para uma finalidade.

Com Redes Neurais acontece exatamente o mesmo.


Primeira geração — MLP

Tudo começou aqui.

Multi-Layer Perceptron.

O famoso MLP.

Se existisse um equivalente no Mainframe seria algo assim:

READ CLIENTE

↓

VALIDAR

↓

CALCULAR

↓

WRITE

A informação sempre anda para frente.

Nunca volta.

Nunca olha para trás.

É por isso que chamamos esse tipo de arquitetura de Feed Forward.

Ela é extremamente eficiente quando os dados são organizados em tabelas.

Por exemplo:

Idade

Salário

Estado Civil

Cidade

↓

Chance de inadimplência

É praticamente o mesmo problema que bancos resolvem há décadas.


Dica Bellacosa

Se você trabalha com Db2, provavelmente mais de 70% dos seus modelos iniciais poderiam ser resolvidos apenas com MLP.

Nem todo problema precisa de um GPT.


Segunda geração — CNN

A MLP era excelente.

Até aparecer uma fotografia.

Ela via isto:

255

128

90

45

...

Ela não fazia ideia de que aquilo representava um gato.

Foi então que surgiu uma ideia brilhante.

Ao invés de analisar a imagem inteira...

Por que não olhar pequenos pedaços?

Nascia a Convolutional Neural Network.


Imagine um inspetor de qualidade em uma fábrica.

Ele não olha o carro inteiro de uma vez.

Primeiro observa:

✔ roda

Depois

✔ porta

Depois

✔ retrovisor

Depois

✔ pintura

Depois

✔ farol

A CNN trabalha exatamente assim.

Ela identifica padrões simples.

Depois combina esses padrões.

Até reconhecer objetos extremamente complexos.


Curiosidade

Hoje praticamente todo exame médico envolvendo IA utiliza CNN em alguma etapa.

Radiologia.

Mamografia.

Tomografia.

Retina.

Dermatologia.

A maioria começou usando CNN.


Terceira geração — RNN

Agora apareceu outro problema.

Texto.

Veja estas frases.

Maria ama João.

Agora troque.

João ama Maria.

As mesmas palavras.

Significados completamente diferentes.

A MLP não entendia isso.

Ela tratava tudo como números.

Foi então que surgiu a Rede Neural Recorrente.

Ela ganhou memória.

Cada palavra influencia a próxima.


Analogia COBOL

Imagine um programa Batch processando extratos.

Cada registro depende do saldo anterior.

Saldo Inicial

↓

Débito

↓

Crédito

↓

Novo Saldo

Esse estado precisa ser carregado.

A RNN faz exatamente isso.


O problema do esquecimento

Mas apareceu outro desafio.

Quanto maior o texto...

Mais difícil lembrar do começo.

Imagine ler um livro inteiro e esquecer quem era o protagonista.

Era isso que acontecia.

Chamamos isso de:

Vanishing Gradient.


LSTM — A memória inteligente

Foi então criada a Long Short-Term Memory.

A ideia é maravilhosa.

Ela criou "porteiros".

Toda informação pergunta:

Posso entrar?

↓

Guardar?

↓

Esquecer?

↓

Mostrar?

Esses controles fizeram uma enorme diferença.

Agora a rede conseguia lembrar eventos ocorridos centenas de palavras antes.


Easter Egg Mainframe

Quem trabalha com CICS conhece bem o conceito de COMMAREA.

Ela transporta contexto entre transações.

A LSTM faz algo parecido.

Ela leva contexto de uma etapa para outra.


GRU

Depois alguém perguntou:

"Será que precisamos de tanta complexidade?"

Nasceu a GRU.

Ela faz quase o mesmo.

Mas usando menos portas.

Resultado:

✔ treinamento mais rápido

✔ menos memória

✔ menos parâmetros


Hoje ela aparece bastante em:

IoT.

Sensores.

Equipamentos industriais.

Dispositivos embarcados.


O terremoto chamado Transformer

Então chegou 2017.

Um artigo mudou completamente a história da IA.

Attention Is All You Need

Esse artigo talvez seja para IA o equivalente ao System/360 para a computação empresarial.

Mudou tudo.


Antes

As redes liam:

Palavra

↓

Palavra

↓

Palavra

Uma por vez.


Agora...

Todas as palavras são analisadas simultaneamente.

Todas

↓

Todas conversam entre si

↓

Resultado

Isso permitiu usar milhares de GPUs em paralelo.

Foi aí que nasceram:

GPT

Claude

Gemini

Llama

Mistral

DeepSeek

Qwen

Phi


Self-Attention

Aqui está a verdadeira mágica.

Imagine:

O gerente entregou o relatório ao diretor porque ele solicitou.

Quem solicitou?

O gerente?

Ou o diretor?

O Transformer calcula relações entre todas as palavras.

Ao mesmo tempo.

É quase como construir um enorme grafo de relacionamentos.


Curiosidade

Quando o ChatGPT responde sua pergunta...

Ele está realizando bilhões de operações matemáticas envolvendo Attention.

A resposta não vem de um banco de dados.

Ela surge desses cálculos.


Autoencoders

Existe outra família extremamente importante.

Os Autoencoders.

Eles aprendem a compactar informação.

Pense em um enorme VSAM.

Imagine reduzir milhões de registros para poucas variáveis que representam todo o comportamento do sistema.

É isso que eles fazem.


Onde aparecem?

Detecção de fraude.

Anomalias.

Compressão.

Stable Diffusion.

Representação Latente.

Sistemas de recomendação.


O que os iniciantes normalmente estudam errado?

Quase todos querem começar aprendendo:

Transformer.

Erro.

É como querer aprender Sysplex antes de entender JCL.

Existe uma ordem natural.


A trilha Bellacosa Mainframe

Se eu estivesse começando hoje...

Minha trilha seria exatamente esta.


Etapa 1

Matemática.

Não precisa virar matemático.

Mas domine:

✔ Álgebra Linear

✔ Vetores

✔ Matrizes

✔ Probabilidade

✔ Estatística


Etapa 2

Python.

Não para virar desenvolvedor Python.

Mas porque praticamente todo ecossistema de IA utiliza Python.

Aprenda:

if

for

listas

funções

classes

Nada além disso inicialmente.


Etapa 3

NumPy.

Aprenda:

arrays

broadcast

matrizes

Etapa 4

Pandas.

Manipulação de dados.

Quem conhece SORT e Db2 aprende Pandas muito rapidamente.


Etapa 5

Visualização.

Matplotlib.

Plotly.

Gráficos contam histórias.


Etapa 6

Machine Learning clássico.

Antes das Redes Neurais.

Aprenda:

Regressão.

Árvore.

Random Forest.

XGBoost.

SVM.

K-Means.


Etapa 7

MLP.

Aqui começa Deep Learning.


Etapa 8

CNN.

Visão Computacional.


Etapa 9

RNN.


Etapa 10

LSTM.


Etapa 11

GRU.


Etapa 12

Attention.


Etapa 13

Transformers.


Etapa 14

LLMs.


Etapa 15

Fine-Tuning.


Etapa 16

RAG.


Etapa 17

Agentes de IA.


Uma analogia com a evolução do Mainframe

Observe como as duas histórias se parecem.

MainframeIA
BatchMLP
CICSRNN
SysplexTransformer
MQAttention
Db2Embeddings
VSAMVetores
RACFGuardrails
WLMScheduler do treinamento
SMFObservabilidade
RMFMonitoramento de desempenho

Perceba algo interessante.

O Mainframe sempre trabalhou com integração.

A IA moderna também.


Cinco conselhos para o COBOL Padawan

1. Não tenha medo da matemática. Você não precisa provar teoremas. Precisa entender conceitos como vetores, matrizes e probabilidades para interpretar o comportamento dos modelos.

2. Preserve sua experiência em regras de negócio. Um modelo de IA pode aprender padrões, mas dificilmente conhece décadas de processos bancários, seguradoras ou governo como um analista experiente.

3. Estude arquitetura, não apenas ferramentas. Frameworks mudam rapidamente. Conceitos como atenção, embeddings, funções de ativação e treinamento permanecem relevantes.

4. Construa pequenos projetos. Um classificador de documentos, um detector de anomalias em transações ou um chatbot para consultar manuais ensinam muito mais do que apenas assistir vídeos.

5. Continue aprendendo continuamente. A evolução da IA é rápida, mas segue princípios fundamentais. Quem domina esses princípios consegue acompanhar as novidades com muito mais facilidade.


Curiosidades

  • O Perceptron, criado em 1958 por Frank Rosenblatt, foi um dos primeiros modelos de rede neural.

  • O termo Deep Learning só ganhou popularidade décadas depois, quando hardware e grandes volumes de dados tornaram possível treinar redes profundas.

  • O artigo "Attention Is All You Need", publicado em 2017, tem pouco mais de uma dezena de páginas e redefiniu praticamente toda a indústria de IA moderna.

  • Muitos modelos atuais utilizam bilhões de parâmetros, mas continuam baseados em conceitos matemáticos desenvolvidos ao longo de décadas.


Easter Eggs para quem vive no IBM Z

  • Embeddings podem ser comparados a índices inteligentes: em vez de procurar por igualdade exata, eles permitem encontrar informações por similaridade.

  • Attention lembra uma consulta complexa que cruza várias tabelas de uma só vez para decidir quais relacionamentos são mais importantes.

  • Fine-Tuning se parece com adaptar um sistema legado para uma nova legislação: você não reescreve tudo, apenas especializa o comportamento.

  • RAG (Retrieval-Augmented Generation) é como combinar um programa COBOL com consultas ao Db2 ou VSAM: o modelo raciocina, mas consulta uma base confiável para responder.

  • Agentes de IA lembram muito a arquitetura tradicional do mainframe: um coordenador orquestra vários componentes especializados, cada um responsável por uma função específica.


Conclusão

Durante muitos anos, o mercado acreditou que Inteligência Artificial substituiria a engenharia de software tradicional. O que estamos observando é justamente o contrário: os sistemas mais poderosos combinam modelos de IA com bancos de dados, filas de mensagens, APIs, regras de negócio, observabilidade, segurança e governança — exatamente os pilares que profissionais de mainframe dominam há décadas.

As redes neurais não eliminam a necessidade de arquitetura; elas ampliam sua importância. Saber quando usar um MLP, uma CNN, um Transformer ou um Autoencoder é tão importante quanto saber quando utilizar COBOL, CICS, Db2 ou MQ.

A verdadeira jornada de um Programador COBOL Padawan rumo à IA não começa decorando nomes de modelos, mas entendendo que cada arquitetura nasceu para resolver um problema específico. Quando você percebe essa evolução, deixa de enxergar a IA como uma caixa-preta e passa a vê-la como mais uma disciplina da Engenharia de Software.

No fim das contas, os princípios continuam os mesmos: compreender o problema, escolher a arquitetura adequada, construir soluções confiáveis e evoluí-las continuamente. Essa sempre foi a essência do desenvolvimento no IBM Z — e continua sendo a essência da Inteligência Artificial moderna.

domingo, 13 de outubro de 2024

MCP Design Patterns: O Manual Definitivo para Construir Agentes de IA Inteligentes (e por que Arquitetura Vale Muito Mais que Prompt)

 

Bellacosa Mainframe mcp design patterns

☕ Um Café no Bellacosa Mainframe

MCP Design Patterns: O Manual Definitivo para Construir Agentes de IA Inteligentes (e por que Arquitetura Vale Muito Mais que Prompt)

"Todo desenvolvedor júnior se encanta pelo agente. O desenvolvedor sênior se preocupa com a arquitetura. O arquiteto sabe que um agente inteligente sobre uma arquitetura ruim apenas toma decisões erradas mais rapidamente."

Durante muitos anos nós, programadores, aprendemos que desenvolver software significava criar classes, funções, APIs e bancos de dados.

Depois vieram os microsserviços.

Depois Kubernetes.

Depois Serverless.

Agora chegou a vez da Inteligência Artificial.

Mas existe um erro que praticamente todo iniciante comete.

Ele acredita que construir um sistema baseado em IA significa apenas conectar o ChatGPT a uma API.

Não significa.

Na verdade, isso representa apenas uma pequena parte da arquitetura.

É exatamente aqui que entra um conceito que provavelmente será tão importante quanto REST foi para os sistemas distribuídos:

Model Context Protocol (MCP).

Mas existe uma segunda descoberta que poucos fazem no início da jornada.

O MCP resolve a comunicação.

Os Design Patterns resolvem o problema real.

Hoje vamos entender profundamente por quê.

Pegue seu café.

Porque esta conversa pode mudar completamente sua forma de enxergar agentes inteligentes.


O que realmente é o MCP?

Imagine um programador COBOL chegando ao escritório.

Ele precisa consultar:

  • CICS

  • Db2

  • IMS

  • RACF

  • VSAM

  • MQ

  • arquivos JCL

  • documentação

  • APIs REST

Cada tecnologia possui uma interface diferente.

Agora imagine um engenheiro de IA.

Ele possui exatamente o mesmo problema.

Só que o usuário é um LLM.

O LLM não sabe conversar com Db2.

Não entende CICS.

Nunca ouviu falar em JES2.

Muito menos em um dataset PDS.

Então alguém precisava criar um idioma universal.

Esse idioma recebeu o nome de Model Context Protocol (MCP).

Pense nele como um USB-C.

Você não precisa mais fabricar um cabo diferente para cada dispositivo.

Todos falam o mesmo protocolo.

O mesmo acontece com IA.

Ao invés de ensinar cada modelo a conversar com milhares de APIs diferentes...

Criamos um protocolo único.


MCP não é um Framework

Esse é outro erro comum.

MCP não substitui:

  • Spring Boot

  • FastAPI

  • Express

  • ASP.NET

Ele também não substitui:

  • REST

  • GraphQL

  • gRPC

Na verdade...

Ele vive acima deles.

Usuário

↓

LLM

↓

MCP Client

↓

MCP Server

↓

REST
SOAP
GraphQL
SQL
MQ
Filesystem
Mainframe

Perceba que o MCP não elimina tecnologias existentes.

Ele apenas organiza o acesso a elas.


O maior erro dos iniciantes

Quase todo mundo faz isso.

"Vou criar um MCP."

Mas ninguém pergunta:

Meu fluxo realmente funciona como?

Essa pergunta vale milhões.

Porque existem dezenas de maneiras diferentes de organizar um sistema baseado em IA.

É exatamente para isso que servem os Design Patterns.


Pense como um arquiteto

Um arquiteto não começa desenhando portas.

Ele pergunta:

Será uma escola?

Hospital?

Shopping?

Casa?

Prédio?

O mesmo vale para MCP.

Não existe um único padrão.

Existe o padrão correto para determinado problema.

Vamos conhecer cada um deles.


Pattern 1 — Local Resource Access

É o padrão mais simples.

Mas também um dos mais utilizados.

Imagine um agente que precisa responder perguntas usando documentos internos.

PDFs.

Excel.

TXT.

CSV.

Imagens.

JCL.

COBOL.

PL/I.

Datasets.

Não faz sentido enviar tudo para a nuvem.

Então o MCP acessa diretamente o sistema de arquivos.

LLM

↓

Servidor MCP

↓

Filesystem

Simples.

Seguro.

Rápido.


Exemplo no Mainframe

Imagine perguntar:

"Liste todos os JOBs que utilizam SORT."

O MCP poderia analisar:

SYS1.PROCLIB

SYS2.PROCLIB

USER.JCL

PRODUCTION.JOBS

Sem copiar absolutamente nada para fora do ambiente z/OS.

Esse padrão é fantástico para ambientes regulados.


Curiosidade

Empresas financeiras dificilmente aceitam que seus documentos internos sejam enviados para provedores externos de IA.

Por isso, o Local Resource Pattern provavelmente será um dos mais utilizados nos próximos anos.


Pattern 2 — Hierarchical MCP

Agora o sistema começou a crescer.

Imagine uma fintech.

Ela possui:

Clientes.

Pagamentos.

PIX.

Cartões.

Fraude.

CRM.

Cobrança.

Tudo misturado.

Um caos.

Então surge um roteador principal.

Agente

↓

Router MCP

↓

Clientes

↓

Pagamentos

↓

PIX

↓

Fraudes

Cada servidor conhece apenas seu domínio.

Exatamente como microsserviços.


Analogia Mainframe

Pense em um Sysplex.

Cada LPAR executa determinadas cargas.

Existe coordenação.

Mas ninguém tenta fazer tudo sozinho.

O mesmo acontece aqui.


Pattern 3 — Event Driven

Esse padrão muda completamente a filosofia.

Nem tudo precisa acontecer imediatamente.

Às vezes basta gerar um evento.

Pedido recebido

↓

MQ

↓

Servidor MCP

↓

Worker

↓

Resposta futura

Isso lembra bastante:

  • IBM MQ

  • Kafka

  • RabbitMQ

  • Event Streams


Exemplo corporativo

Recebeu uma nota fiscal.

Extrair dados.

Classificar.

Enviar ao ERP.

Gerar relatório.

Enviar e-mail.

Tudo isso pode acontecer sem bloquear o usuário.


Exemplo IBM Z

CICS

↓

MQ

↓

MCP

↓

Análise

↓

Atualiza Db2

↓

Notifica operador

É exatamente a filosofia dos sistemas orientados a eventos.


Pattern 4 — MCP-to-Agent

Agora chegamos onde a IA realmente fica interessante.

Imagine um único agente tentando responder tudo.

Financeiro.

Jurídico.

RH.

Infraestrutura.

Banco de dados.

Não parece uma boa ideia.

Então fazemos exatamente o contrário.

Criamos especialistas.

Supervisor

↓

Especialista COBOL

Especialista Db2

Especialista CICS

Especialista RACF

Especialista MQ

Cada um conhece profundamente sua área.

Depois alguém junta as respostas.

Isso é arquitetura Multi-Agent.


Imagine isso

Usuário pergunta:

"Por que meu JOB terminou com RC=12?"

O supervisor encaminha a pergunta para:

  • Especialista JCL

  • Especialista SORT

  • Especialista Db2

  • Especialista JES2

Todos analisam simultaneamente.

Depois entregam um diagnóstico consolidado.

Muito mais eficiente.


Pattern 5 — Composite Service

Agora o MCP vira um maestro.

Ele coordena vários serviços.

Consulta Cliente

↓

Consulta Crédito

↓

Consulta Receita

↓

Consulta ERP

↓

Consulta Open Finance

↓

Resposta

Para o usuário parece uma única ferramenta.

Mas internamente dezenas de APIs trabalharam juntas.


Exemplo Mainframe

Abrir uma conta.

O MCP pode chamar:

  • CICS

  • Db2

  • MQ

  • RACF

  • z/OS Connect

  • API do CRM

Tudo automaticamente.


Pattern 6 — Direct API Wrapper

É o mais simples.

Você já possui APIs.

Só precisa expô-las.

REST

↓

MCP

↓

LLM

Não existe necessidade de reinventar nada.

Esse padrão é excelente para:

  • MVP

  • Provas de conceito

  • Hackathons

  • Integrações rápidas


Comparando todos os padrões

PatternComplexidadeEscalaQuando usar
Local ResourceMuito baixaMédiaArquivos locais
Direct APIBaixaAltaAPIs existentes
CompositeMédiaAltaIntegrações
Event DrivenAltaMuito altaProcessamentos longos
HierarchicalAltaMuito altaGrandes empresas
MCP-to-AgentMuito altaExtremamente altaIA especializada

Como isso conversa com RAG?

Muita gente confunde.

RAG não substitui MCP.

MCP não substitui RAG.

Eles trabalham juntos.

Imagine:

Pergunta

↓

Agente

↓

RAG procura conhecimento

↓

MCP executa ação

↓

Resposta

Um encontra informação.

O outro executa tarefas.

São complementares.


E onde entra o Prompt Engineering?

Outro mito.

Prompt Engineering não desapareceu.

Na verdade ficou ainda mais importante.

Agora temos:

  • Prompt do usuário

  • Prompt do agente

  • Prompt das ferramentas

  • Prompt dos especialistas

  • Prompt do supervisor

É uma arquitetura inteira de prompts.


Observabilidade: o detalhe que todo mundo esquece

Quem respondeu?

Qual ferramenta foi utilizada?

Quanto tempo demorou?

Qual API falhou?

Qual agente tomou determinada decisão?

Sem observabilidade...

Você nunca conseguirá depurar um sistema baseado em IA.

Da mesma forma que usamos:

  • SMF

  • RMF

  • SDSF

  • JES2

para monitorar o z/OS,

precisaremos monitorar agentes.

Provavelmente surgirão verdadeiros "SDSFs para IA".


Segurança

Este talvez seja o assunto mais importante.

Imagine um agente com acesso irrestrito.

Ele poderia:

Excluir arquivos.

Cancelar JOBs.

Criar usuários.

Alterar tabelas.

Assustador.

Por isso o MCP precisa respeitar princípios como:

  • Menor privilégio (Least Privilege)

  • Zero Trust

  • Autenticação forte

  • Autorização por função

  • Auditoria completa

  • Logs imutáveis

No mundo IBM Z, isso conversa diretamente com RACF, ACF2 e Top Secret.


O futuro: agentes especializados

Hoje temos um único chatbot.

Daqui a alguns anos teremos verdadeiras equipes virtuais.

Imagine um ambiente de desenvolvimento onde coexistem:

  • um Arquiteto de Software virtual;

  • um Especialista COBOL;

  • um DBA Db2;

  • um Especialista CICS;

  • um Analista de Segurança RACF;

  • um Especialista em Performance WLM;

  • um Engenheiro DevOps;

  • um Especialista em Observabilidade.

Você faz uma única pergunta, e um agente supervisor distribui automaticamente as tarefas para cada especialista. Essa visão, que parecia ficção científica há poucos anos, já começa a aparecer nas arquiteturas corporativas mais modernas.


Dicas para o Programador Júnior

Se você está começando agora, não tente aprender tudo de uma vez. Construa sua base de forma incremental:

  1. Aprenda primeiro o que é o MCP e como ele expõe ferramentas.

  2. Crie um pequeno servidor MCP acessando arquivos locais.

  3. Envolva uma API REST existente usando o padrão Direct API Wrapper.

  4. Evolua para um Composite Service, orquestrando duas ou três APIs.

  5. Estude filas e processamento assíncrono com IBM MQ, Kafka ou RabbitMQ.

  6. Experimente arquiteturas multiagentes, separando especialistas por domínio.

  7. Documente tudo. Um bom diagrama vale tanto quanto um bom código.

  8. Pense sempre em segurança, observabilidade e governança desde o primeiro dia.

Lembre-se: a melhor arquitetura é aquela que continua simples mesmo quando o sistema cresce.


Curiosidades

☕ O conceito de protocolos padronizados não é novo. Assim como HTTP revolucionou a Web e JDBC padronizou o acesso a bancos de dados, o MCP busca padronizar a comunicação entre modelos de IA e ferramentas.

☕ Muitas empresas estão reutilizando APIs que já existiam há anos. Em vez de reescrever sistemas, apenas criam uma camada MCP sobre elas.

☕ Um servidor MCP pode conversar com sistemas escritos em COBOL, Java, Python, C#, Go ou Node.js. O protocolo não depende da linguagem de implementação.

☕ Ambientes IBM Z são candidatos naturais para o uso de MCP, pois concentram processos críticos, regras de negócio consolidadas e décadas de conhecimento corporativo.


Easter Eggs para os apaixonados por tecnologia

🥚 Easter Egg #1: Se você conhece o padrão Facade da programação orientada a objetos, já entendeu parte da ideia do Composite Service Pattern: esconder a complexidade de vários serviços atrás de uma interface simples.

🥚 Easter Egg #2: O Hierarchical MCP Pattern lembra a organização de um Sysplex: vários componentes especializados coordenados por uma camada superior.

🥚 Easter Egg #3: O Event-Driven Pattern conversa naturalmente com IBM MQ, Kafka e até mesmo com os tradicionais batch triggers do z/OS. O conceito muda, mas a filosofia continua a mesma.

🥚 Easter Egg #4: Um agente supervisor distribuindo tarefas para especialistas lembra muito o escalonamento de workloads feito pelo Workload Manager (WLM): cada recurso executa aquilo para o qual foi projetado.

🥚 Easter Egg #5: Se você percebeu que um servidor MCP funciona como uma espécie de "3270 inteligente" para a IA, parabéns! Em ambos os casos existe uma camada intermediária que traduz comandos e controla o acesso aos sistemas corporativos.


Conclusão

O entusiasmo em torno da Inteligência Artificial faz muita gente acreditar que basta escolher o melhor modelo de linguagem para resolver qualquer problema. A prática mostra o contrário. Modelos excelentes podem fracassar quando são colocados sobre arquiteturas mal planejadas, enquanto modelos mais modestos entregam resultados impressionantes quando sustentados por uma boa engenharia.

O Model Context Protocol (MCP) representa um passo importante nessa evolução porque padroniza a comunicação entre agentes e sistemas. No entanto, o protocolo é apenas a fundação. O verdadeiro diferencial está na escolha do Design Pattern adequado ao fluxo de trabalho, ao domínio de negócio, aos requisitos de segurança e à estratégia de escalabilidade.

Para quem trabalha com IBM Mainframe, a boa notícia é que muitos dos princípios utilizados há décadas — modularização, separação de responsabilidades, processamento assíncrono, governança, auditoria e alta disponibilidade — continuam absolutamente válidos. O cenário mudou, mas os fundamentos permanecem.

No fim das contas, construir soluções com IA não é muito diferente de construir sistemas corporativos de qualidade: o protocolo conecta, a arquitetura organiza e a experiência do engenheiro transforma tecnologia em valor para o negócio.

Porque, como gostamos de dizer aqui no Bellacosa Mainframe:

"A IA pode escrever código em segundos. Mas somente uma boa arquitetura garante que esse código continuará útil daqui a dez anos."

 

sábado, 12 de outubro de 2024

Docker para Programadores COBOL Mainframe: O "JCL" do Mundo Moderno que Todo Padawan IBM Z Precisa Entender

 

Bellacosa Mainframe e o docker no mundo cobol mainframe

☕ Um Café no Bellacosa Mainframe

Docker para Programadores COBOL Mainframe: O "JCL" do Mundo Moderno que Todo Padawan IBM Z Precisa Entender

"Você pode passar trinta anos programando COBOL sem nunca escrever uma linha de Docker. Mas provavelmente trabalhará com pessoas que usam Docker todos os dias para entregar o seu programa em produção."

Existe um mito muito comum entre profissionais de Mainframe.

"Docker é coisa de Linux."

Não.

Docker é uma tecnologia que muda completamente a forma como software é distribuído.

E isso afeta diretamente quem trabalha com COBOL.

Mesmo que seu programa execute dentro de um IBM Z rodando z/OS.

Hoje praticamente toda arquitetura moderna possui alguma camada containerizada.

Seu COBOL conversa com APIs.

As APIs estão em containers.

Os testes automatizados rodam em containers.

O banco PostgreSQL usado para homologação roda em container.

O Redis roda em container.

O RabbitMQ roda em container.

O Kafka roda em container.

Até o VS Code que conversa com seu Zowe pode estar executando dentro de um Dev Container.

Ou seja...

Mesmo que você nunca instale Docker, Docker provavelmente trabalha para você todos os dias.


A analogia que todo coboleiro entende

Imagine um JOB.

Você escreve:

//STEP01 EXEC PGM=MEUPROG

Quando o operador executa o JOB, ele sabe exatamente:

  • qual programa executar

  • quais datasets utilizar

  • quais bibliotecas carregar

  • qual ambiente existe

Docker segue exatamente essa filosofia.

Em vez de dizer

"Execute o programa."

Ele diz

"Execute exatamente ESTE ambiente."

Essa pequena diferença mudou toda a indústria.


O maior problema do desenvolvimento moderno

Todo desenvolvedor já ouviu a frase:

"Na minha máquina funciona."

Essa frase custa milhões para empresas.

Porque existem diferenças entre computadores.

Imagine três desenvolvedores.

Carlos usa Ubuntu.

João usa Windows.

Maria usa Mac.

Cada um possui:

  • versões diferentes de Java

  • versões diferentes de Python

  • bibliotecas diferentes

  • PATH diferente

  • variáveis diferentes

Resultado?

O software funciona em uma máquina.

Quebra na outra.

Docker elimina esse problema.


O container é um ambiente fechado

Pense nele como um mini sistema operacional.

Dentro dele existe tudo.

Aplicação

↓

Bibliotecas

↓

Dependências

↓

Sistema

↓

Configuração

↓

Rede

Tudo viaja junto.

Assim como um LOAD MODULE leva seu código compilado.


O paralelo perfeito com Mainframe

No z/OS nós temos:

STEPLIB

LINKLIST

LPALIB

PROCLIB

PARMLIB

SDFHLOAD

SCEERUN

DBRMLIB

Cada biblioteca influencia a execução.

Docker faz exatamente isso.

Só que empacotado.


O Dockerfile é praticamente um PROC

Olhe este Dockerfile.

FROM ubuntu

RUN apt update

RUN apt install python3

COPY app.py .

CMD python3 app.py

Ele descreve todo ambiente.

Assim como uma PROC descreve um JOB.


Um PROC

//COBPROC PROC

//COB EXEC PGM=IGYCRCTL

//LKED EXEC PGM=IEWL

// PEND

Os dois descrevem como construir um ambiente.

Só muda a linguagem.


O Build

Quando fazemos

docker build

Estamos criando uma imagem.

É semelhante a:

Compilar COBOL

↓

Link-edit

↓

Gerar Load Module

Não executa ainda.

Apenas cria.


A imagem

A imagem é imutável.

Ela funciona como um LOAD MODULE.

Você gera uma vez.

Executa milhares.


O Container

Quando fazemos

docker run

É semelhante ao operador executando

SDSF

COMMAND

S

START JOB

A imagem ganha vida.


O Registry

Docker possui repositórios.

Semelhantes a uma gigantesca LOADLIB.

Docker Hub

GitHub Registry

Azure Registry

IBM Registry

O COBOL moderno conversa com containers

Imagine seu programa.

COBOL

↓

CICS

↓

REST API

↓

Docker

↓

Java

↓

Banco

Você nem percebe.

Mas boa parte da aplicação vive dentro de containers.


O Docker não substitui Mainframe

Esse é outro mito.

Ele complementa.

Mainframe continua fazendo aquilo que faz melhor.

Processamento crítico.

Docker faz aquilo que faz melhor.

Microsserviços.

APIs.

Ferramentas.

Integração.


Um exemplo real

Seu COBOL chama:

CLIENTE

↓

API PIX

↓

Container

↓

Spring Boot

↓

Banco PostgreSQL

O COBOL nunca sabe.

Só vê uma URL.


Onde um coboleiro usa Docker?

Muito mais do que imagina.

Exemplos.

PostgreSQL

docker run postgres

MongoDB

docker run mongo

Redis

docker run redis

Kafka

docker run kafka

RabbitMQ

docker run rabbitmq

Jenkins

docker run jenkins

SonarQube

docker run sonarqube

GitLab Runner

Container.


Zowe

Pode rodar em container.


IBM Explorer

Ambientes de teste podem ser containerizados.


Easter Egg número 1

Docker também possui "camadas".

Assim como o Mainframe possui bibliotecas em cascata.

Quando duas imagens compartilham partes iguais...

Docker reutiliza.

É quase um:

LPA

Shared Library

LINKLIST

Easter Egg número 2

Imagem Docker.

Read Only

Load Module.

Read Only

Curiosa coincidência.


Easter Egg número 3

Containers morrem.

Dados persistem.

Parece familiar?

Datasets.

Você apaga um JOB.

Mas o VSAM continua.


Volumes

Volumes são onde vivem os dados.

Sem volume.

Tudo desaparece.

Assim como arquivos temporários em SYSDA.


Cuidado

Padawans fazem isto:

docker run mysql

Depois:

docker rm

Adeus banco.

Tudo perdido.


O equivalente ao DELETE do catálogo.

Sem backup.

Sem retorno.


Docker Compose

Imagine um sistema inteiro.

Você precisa:

  • PostgreSQL

  • Redis

  • RabbitMQ

  • API

  • Front-end

Seria trabalhoso iniciar tudo manualmente.

Então existe:

docker-compose.yml

É praticamente um scheduler.


Você escreve.

Suba tudo.

E ele sobe.

Na ordem correta.


Parece JCL?

Muito.

STEP01

↓

STEP02

↓

STEP03

Docker Desktop

É o ISPF do Docker.

Quem conhece ISPF aprende Docker Desktop rapidamente.


Como um coboleiro evolui?

Nível 1

Aprender comandos.

docker ps

docker images

docker stop

docker rm

docker logs

Nível 2

Dockerfile.


Nível 3

Volumes.


Nível 4

Networks.


Nível 5

Compose.


Nível 6

CI/CD.


Nível 7

Kubernetes.


O comando que todo mundo esquece

docker logs

É praticamente:

SDSF

OUTPUT

SYSOUT

Sem logs.

Não existe diagnóstico.


Outro comando essencial

docker exec -it container bash

É equivalente a:

TSO

LOGON

Você entra dentro da máquina.


Redes Docker

Containers conversam por rede virtual.

Pense em CICS falando com DB2.

Tudo isolado.


Variáveis de ambiente

No Mainframe temos:

PARMLIB.

PARM.

SYSIN.

No Docker temos:

ENV

Environment Variables

Mesmo conceito.


Segurança

Nunca coloque senhas.

Errado.

ENV PASSWORD=123456

Correto.

Secrets.

Vault.

Azure Key Vault.

Hashicorp Vault.


Um perigo enorme

Container não é Máquina Virtual.

Muitos iniciantes confundem.

Container compartilha o Kernel.

Máquina Virtual possui Kernel próprio.

São tecnologias diferentes.


Outro erro comum

Criar imagens gigantes.

Imagem de:

12 GB

Quando poderia ter:

300 MB

Outro erro

Executar como root.

Jamais.

Sempre criar usuário.


Outro erro

Copiar arquivos desnecessários.

Use:

.dockerignore

Assim como usamos:

EXCLUDE

Em utilitários.


Docker e DevOps

Hoje praticamente toda pipeline faz:

Git

↓

Build

↓

Testes

↓

Docker

↓

Deploy

Mesmo sistemas Mainframe participam desse fluxo.


Onde entra o COBOL?

Exemplo.

GitHub

↓

Compila COBOL

↓

Executa testes

↓

Publica API

↓

Container

↓

OpenShift

↓

Consome CICS

O COBOL continua sendo protagonista.

Docker apenas ajuda.


Curiosidade

IBM possui imagens oficiais.

Ferramentas IBM também utilizam containers.

OpenShift é baseado em Kubernetes.

Kubernetes nasceu para gerenciar milhares de containers.


Easter Egg número 4

No Mainframe aprendemos cedo:

Nunca altere produção diretamente.

Docker leva isso ao extremo.

Você nunca altera um container.

Você destrói.

Cria outro.

É uma filosofia muito parecida com a imutabilidade dos artefatos promovida por pipelines modernos.


Easter Egg número 5

O famoso:

docker kill

Lembra muito um operador fazendo:

CANCEL JOB

A diferença é que o impacto pode ser ainda maior.

Se aquele container fazia parte de um cluster, outro poderá assumir automaticamente.

É como um Sysplex distribuindo a carga para outro membro.


Docker e IBM Z: um casamento cada vez mais comum

Muitos padawans imaginam que Docker existe apenas em servidores x86. Na prática, o ecossistema IBM Z também abraçou containers. É comum encontrar ambientes onde aplicações Java, Node.js, Python ou Go executam em Linux on IBM Z ou LinuxONE dentro de containers, enquanto os sistemas críticos permanecem em z/OS.

Um cenário típico é:

Internet
     │
API Gateway
     │
Container Spring Boot
     │
IBM MQ
     │
CICS
     │
Programa COBOL
     │
DB2

Perceba que o COBOL continua onde sempre esteve: no coração da transação. O Docker atua nas camadas de integração, autenticação, observabilidade e exposição de serviços.


Como identificar problemas em Docker com a mentalidade de um operador de Mainframe

Um bom programador COBOL costuma pensar de forma estruturada. Essa habilidade ajuda muito ao trabalhar com containers. Ao investigar um problema, faça perguntas parecidas com as que faria diante de um ABEND:

  • O container iniciou corretamente?

  • O processo principal terminou inesperadamente?

  • Os logs mostram mensagens de erro?

  • Há portas em conflito?

  • O volume de dados foi montado?

  • A variável de ambiente obrigatória foi definida?

  • A imagem está na versão correta?

  • Existe comunicação entre os containers?

  • O serviço externo está disponível?

Essa abordagem sistemática reduz drasticamente o tempo de diagnóstico.


Conclusão: Docker é mais familiar ao coboleiro do que parece

Quando um padawan olha para Docker pela primeira vez, tudo parece novo: imagens, containers, volumes, registries, compose, redes. Porém, um veterano de Mainframe rapidamente percebe padrões conhecidos.

Você já entende de ambientes controlados.

Já entende de bibliotecas.

Já entende de versões.

Já entende de promoção entre desenvolvimento, homologação e produção.

Já entende da importância dos logs.

Já entende que uma alteração aparentemente pequena pode causar um grande incidente.

Docker apenas utiliza outra linguagem para resolver muitos dos mesmos problemas que o Mainframe resolveu décadas atrás.

No fim das contas, um bom programador COBOL não precisa abandonar sua experiência para aprender Docker. Pelo contrário: sua disciplina, seu cuidado com mudanças, sua visão de estabilidade e sua capacidade de diagnosticar problemas são exatamente as qualidades que diferenciam um excelente profissional de containers.

E fica um último pensamento para os Padawans do Bellacosa Mainframe:

"Quem domina JCL entende que infraestrutura também é código. Docker apenas tornou essa ideia popular para o restante da indústria."

A tecnologia muda, as ferramentas evoluem, mas os princípios continuam os mesmos: ambientes reproduzíveis, processos previsíveis, mudanças controladas e software confiável. E nisso, poucos profissionais têm tanto a ensinar quanto um bom coboleiro de Mainframe.

Docker na Stack Mainframe

Não houve um único ano, um release ou um anúncio dizendo "Docker agora suporta COBOL Mainframe". O que aconteceu foi uma convergência gradual de tecnologias.

Esta é uma linha do tempo que ajuda a entender essa evolução:

AnoMarcoImpacto para Mainframe
2013Docker é lançado pela dotCloudNasce o conceito moderno de containers Linux.
2014Docker 1.0Empresas começam a adotar containers em produção.
2015Kubernetes ganha forçaOrquestração de milhares de containers.
2016-2017IBM passa a investir fortemente em containers e microserviçosIntegrações com IBM Z tornam-se prioridade.
2017IBM adquire a Red Hat? (não, o anúncio foi em 2018 e conclusão em 2019)Estratégia híbrida começa a se consolidar.
2018IBM anuncia a aquisição da Red HatOpenShift torna-se a principal plataforma de containers da IBM.
2019Conclusão da aquisição da Red HatOpenShift passa a ser peça central da estratégia IBM Hybrid Cloud.
2020+OpenShift chega amplamente ao IBM Z e LinuxONEContainers tornam-se parte da arquitetura corporativa junto ao z/OS.
2021-2024APIs, z/OS Connect, Ansible, Zowe e OpenShift amadurecemCOBOL passa a conviver naturalmente com aplicações containerizadas.

O ponto importante

Docker não executa programas COBOL do z/OS.

Quem continua executando o COBOL é:

  • z/OS

  • CICS

  • Batch

  • IMS

  • Db2

  • JCL

O Docker normalmente executa o que está ao redor do COBOL:

  • APIs REST

  • Java

  • Spring Boot

  • Node.js

  • Python

  • NGINX

  • Redis

  • PostgreSQL

  • Kafka

  • RabbitMQ

  • Ferramentas DevOps

O cenário típico hoje é:

Internet
      │
OpenShift / Docker
      │
API REST
      │
z/OS Connect
      │
CICS
      │
Programa COBOL
      │
DB2

O programa COBOL continua exatamente onde sempre esteve.

O Docker apenas fornece uma maneira moderna de consumir seus serviços.

Quando o COBOL "abraçou" Docker?

Se tivermos que escolher um período, eu diria que foi entre 2018 e 2022.

Isso ocorreu porque várias tecnologias amadureceram ao mesmo tempo:

  • IBM OpenShift no IBM Z

  • Linux on IBM Z

  • z/OS Connect Enterprise Edition

  • Zowe

  • Git e pipelines DevOps para Mainframe

  • APIs REST consumindo programas COBOL

  • Arquiteturas híbridas (Hybrid Cloud)

Foi nessa época que deixou de ser incomum ver um sistema como este:

Docker
      │
Spring Boot
      │
REST
      │
z/OS Connect EE
      │
CICS
      │
COBOL
      │
DB2

Hoje essa arquitetura é bastante comum em bancos, seguradoras, telecomunicações e grandes empresas.

Existe Docker rodando diretamente no z/OS?

Não.

O Docker utiliza recursos do kernel Linux (namespaces, cgroups etc.), portanto não roda nativamente sobre o kernel do z/OS.

No ecossistema IBM Z, o mais comum é:

  • Docker rodando em Linux on IBM Z ou LinuxONE.

  • OpenShift gerenciando containers nesses ambientes Linux.

  • z/OS executando COBOL, CICS, IMS, Db2 e batch.

  • Comunicação entre ambos via REST, IBM MQ, gRPC, eventos ou APIs.

Uma curiosidade para o coboleiro

O Docker nunca substituiu o Mainframe. Na verdade, ele acabou reforçando seu papel.

Quando uma empresa cria dezenas ou centenas de microsserviços em containers, muitos deles precisam consultar dados críticos. Em vez de migrar décadas de regras de negócio, eles chamam as aplicações COBOL existentes por meio de APIs. Assim, o COBOL permanece como o sistema de registro (System of Record), enquanto os containers atuam como camada de apresentação, integração e inovação.

É por isso que, atualmente, um programador COBOL moderno não precisa aprender Docker para "rodar COBOL", mas sim para compreender o ecossistema onde seu código vive e como ele se integra ao restante da arquitetura corporativa. Esse conhecimento facilita a comunicação com equipes de DevOps, SRE, desenvolvimento Java, APIs e nuvem híbrida, tornando o profissional de Mainframe ainda mais valioso.


sexta-feira, 11 de outubro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON GENERATE - Parte III

 

Bellacosa Mainframe e o json em cobol parte iii

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 3 – JSON GENERATE

Quando o Padawan Aprende a Construir APIs REST com COBOL e Descobre que Também Pode Falar com a Galáxia

Por Bellacosa Mainframe


"JSON PARSE ensina COBOL a escutar. JSON GENERATE ensina COBOL a responder. Um Mestre Jedi precisa dominar ambos."

Mestre Bellacosa Sysprog Jedi


Introdução

Nas jornadas anteriores, o jovem Padawan descobriu algo extraordinário.

Primeiro aprendeu que COBOL moderno fala JSON.

Depois aprendeu a utilizar JSON PARSE.

Agora chega o momento em que ele percebe uma verdade ainda mais impressionante.

COBOL não apenas entende JSON.

COBOL também consegue produzir JSON de forma elegante, otimizada e extremamente rápida.

E isso é feito através de uma instrução quase tão poderosa quanto um sabre de luz recém-montado.

JSON GENERATE


O que é JSON GENERATE?

JSON GENERATE é um serializador.

Seu objetivo é simples.

Transformar estruturas COBOL em texto JSON.

Visualmente.

WORKING STORAGE


↓

JSON GENERATE


↓

JSON


↓

REST API


↓

Aplicativo


↓

Microsserviço

Em outras palavras.

Ele faz exatamente o oposto de JSON PARSE.


Antes do Enterprise COBOL 6

A vida era difícil.

Muitos sistemas faziam:

STRING

"{"

'"id":'

WS-ID

','
'"nome":"'

WS-NOME

'"'

"}"

INTO WS-BUFFER

Problemas.

Vírgulas.

Aspas.

Espaços.

Campos vazios.

Arrays.

Escape.

Tudo manual.


Padawan sofria.


O nascimento de JSON GENERATE

Enterprise COBOL Version 6.

Introduziu.

JSON GENERATE.


Mudou completamente.

Integrações.


Hoje.

Muito utilizado.

6.3

6.4

6.5


Primeiro exemplo

Passo 1

Estrutura COBOL

01 WS-CLIENTE.


05 WS-ID.
PIC 9(5).


05 WS-NOME.
PIC X(30).


05 WS-IDADE.
PIC 999.

Passo 2

JSON Buffer

01 WS-JSON.

PIC X(500).

Passo 3

Popular

MOVE 100

TO WS-ID


MOVE 'Bellacosa'

TO WS-NOME


MOVE 52

TO WS-IDADE

Passo 4

Gerar

JSON GENERATE

WS-JSON


FROM WS-CLIENTE

Passo 5

Display

DISPLAY WS-JSON

Resultado.

{

"id":100,

"nome":"Bellacosa",

"idade":52

}

Pronto.

API pronta.


Como funciona internamente?

Compilador gera.

Serializer.


Percorre.

Estrutura.

Campo.

Por campo.


Converte.

Numéricos.

Strings.

Booleans.

Occurs.


Escreve.

JSON.


Visualmente.

WS-ID


↓

Serializer


↓

"id":100

Memória

JSON continua sendo.

Texto.


Exemplo.

01 WS-JSON.

PIC X(10000).

Buffer.

Grande.


Serializer.

Preenche.


Pouco overhead.


Muito eficiente.


Campos vazios

Problema comum.


Exemplo.

MOVE SPACES

TO WS-NOME

Resultado.

"name":""

Nem sempre desejado.


SUPPRESS

Ferramenta poderosa.


Exemplo conceitual.

JSON GENERATE

WS-JSON


FROM WS-DADOS


SUPPRESS

Campos vazios.

Não aparecem.


Muito usado.

Em APIs.


OMITTED

Outra técnica.


Campo opcional.


Excelente.

Open Banking.

PIX.


NAME OF

Talvez a funcionalidade favorita.

Do Bellacosa.


COBOL.

05 WS-NOME.

JSON desejado.

"customerName"

NAME OF permite.

Mapear.


Muito elegante.


Exemplo API PIX

COBOL.

01 PIX.


05 CHAVE.


05 VALOR.


05 DATA.

JSON.

{

"chave":"abc",


"valor":100,


"data":"2026-06-25"

}

JSON GENERATE.

Faz.

Tudo.


Arrays

Muito útil.


COBOL.

05 TELEFONES.


10 TEL OCCURS 5.

JSON.

"telefones":[


"1111",


"2222"

]

Automático.


Objetos aninhados

COBOL.

01 CLIENTE.


05 DADOS.


10 ID.


10 NOME.



05 ENDERECO.


10 CIDADE.


10 CEP.

Resultado.

{

"cliente":{


"id":1,

"nome":"Bellacosa"


},

"endereco":{


"cidade":"SP"

}

}

Muito elegante.


Null

JSON suporta.


COBOL não.


Precisamos.

Decidir.


Campo vazio.


Campo omitido.


Valor padrão.


Muito importante.


UTF8

Outro cuidado.


JSON.

UTF8.


COBOL.

EBCDIC.


Conversão.

Necessária.


Especialmente.

Acentos.


José.

São Paulo.


Ç.

Ã.


Sempre testar.


Segurança

Poucos lembram.


JSON GENERATE.

Também possui.

Riscos.


Exemplo.

Dados internos.


Senha.


CPF.


Token.


Acidentalmente.

Expostos.


Exemplo.

01 CLIENTE.


05 SENHA.


PIC X(20).

JSON GENERATE.

Sem SUPPRESS.


API.

Expõe.

Senha.


Muito perigoso.


Boa prática

Criar.

Estrutura.

Específica.

API.


Nunca.

Gerar.

Diretamente.

Working Storage.

Inteira.


Pretty JSON

COBOL.

Não gera.

JSON bonito.


Compacto.


Mais eficiente.


Consumidor.

Pode formatar.


Performance

Excelente.


Serializer.

Nativo.


Compilado.


Muito rápido.


Melhor.

Que STRING.


Melhor.

Que montar.

Na mão.


Benchmark aproximado

Manual.

100%


JSON GENERATE.

Muito menor.

CPU.


Menos bugs.


Mais manutenção.


Curiosidade

Muitos aplicativos bancários.

Recebem.

JSON.

Gerado.

Por COBOL.


Usuário.

Nunca percebe.


Abre app.


Consulta saldo.


Recebe.

JSON.


Origem.

COBOL.

No z17.


APIs modernas

JSON GENERATE é usado.

Em.

z/OS Connect

CICS

Liberty

MQ

Kafka

OpenShift

Cloud Pak


Praticamente.

Todo lugar.


Bellacosa Best Practices

Sempre

Criar DTO.

Separado.


Sempre

Usar SUPPRESS.


Sempre

Validar UTF8.


Sempre

Versionar JSON.


Sempre

Documentar.

Swagger.

OpenAPI.


Nunca

Expor.

Campos internos.


Nunca

Montar.

JSON.

Na mão.

Com STRING.


Comparação

TécnicaRecomendada
STRINGNão
UNSTRINGNão
INSPECTNão
Parser próprioEvitar
JSON GENERATESim
JSON PARSESim

O Conselho do Mestre Bellacosa

Durante muitos anos, o programador COBOL era visto como alguém responsável apenas por arquivos sequenciais, relatórios batch e transações CICS.

JSON GENERATE mudou essa percepção.

Ele permitiu que sistemas escritos décadas atrás começassem a responder chamadas REST, conversar com aplicativos móveis, participar do Open Finance e integrar-se naturalmente a arquiteturas modernas baseadas em APIs.

Talvez essa seja uma das maiores virtudes do Enterprise COBOL.

Ele não exige que o desenvolvedor abandone tudo aquilo que aprendeu.

Ele simplesmente acrescenta novas habilidades.

E diz ao Padawan:

Continue usando seus níveis 01, 05 e 10.

Continue escrevendo programas robustos.

Continue confiando na estabilidade do IBM Z.

Eu apenas ensinarei seu código a responder em uma linguagem compreendida por praticamente toda a galáxia digital.


Continua na Parte 4

JSON Jedi Master – z/OS Connect, MQ, Kafka, OpenShift, APIs de Alto Desempenho, Segurança OWASP e Técnicas Avançadas para o Mestre Bellacosa do IBM Z.

quinta-feira, 10 de outubro de 2024

Inteligência Artificial Para Programadores COBOL: Da Conferência de Dartmouth ao ChatGPT

Bellacosa Mainframe apresenta IA para programadores COBOL


Inteligência Artificial Para Programadores COBOL: Da Conferência de Dartmouth ao ChatGPT

Introdução

Se você trabalha com COBOL, mainframe, processamento batch, CICS, DB2, JCL ou sistemas corporativos legados, provavelmente já ouviu alguma das seguintes frases:

  • "A IA vai substituir os programadores."

  • "O ChatGPT pensa."

  • "Agora tudo é Inteligência Artificial."

  • "COBOL morreu."

  • "Mainframe ficou obsoleto."

Curiosamente, todas essas afirmações têm algo em comum: são simplificações excessivas de assuntos extremamente complexos.

Nos últimos anos, a Inteligência Artificial saiu dos laboratórios de pesquisa e passou a ocupar espaço nas notícias, nas redes sociais, nas empresas e até nas conversas familiares.

Mas para compreender verdadeiramente o que está acontecendo, precisamos voltar algumas décadas.

Muito antes de existirem smartphones, internet comercial, computação em nuvem ou ChatGPT, alguns cientistas acreditavam que seria possível reproduzir aspectos da inteligência humana através de máquinas.

Foi dessa ideia que nasceu a Inteligência Artificial.

Neste artigo vamos percorrer essa trajetória, relacionando os conceitos modernos com uma realidade mais familiar para profissionais de desenvolvimento tradicional e ambientes corporativos.


Antes da IA Existir

Muitas pessoas acreditam que a Inteligência Artificial nasceu recentemente.

Na verdade, ela possui raízes filosóficas muito antigas.

Desde a Antiguidade, seres humanos imaginavam a possibilidade de criar entidades artificiais capazes de raciocinar.

A questão fundamental sempre foi:

"Será que a inteligência é algo exclusivamente humano ou pode ser reproduzida por regras?"

Essa pergunta é mais profunda do que parece.

Um programador COBOL está acostumado a pensar em termos de regras:

IF SALDO > 0
    MOVE "ATIVO" TO STATUS-CONTA
ELSE
    MOVE "INATIVO" TO STATUS-CONTA
END-IF

O raciocínio dos pioneiros da IA era semelhante.

Eles imaginavam que talvez toda inteligência pudesse ser decomposta em conjuntos gigantescos de regras.

Se isso fosse verdade, bastaria descobrir as regras corretas.

O restante seria programação.


Bellacosa Mainframe e a evolução da IA

O Contexto dos Anos 1950

Após a Segunda Guerra Mundial ocorreu uma explosão tecnológica.

Alguns acontecimentos mudaram completamente a história da computação:

  • surgimento dos computadores eletrônicos;

  • teoria da informação de Claude Shannon;

  • trabalhos de Alan Turing;

  • avanços matemáticos em lógica formal.

Pela primeira vez na história existiam máquinas capazes de executar cálculos complexos em velocidades impressionantes.

Naquele momento surgiu uma pergunta inevitável:

"Se computadores podem calcular, será que podem pensar?"

Hoje sabemos que pensar é um conceito extremamente difícil de definir.

Mas naquela época muitos cientistas acreditavam que a resposta seria positiva.


Dartmouth 1956: O Nascimento Oficial da IA

O marco histórico normalmente utilizado para definir o nascimento da Inteligência Artificial ocorreu em 1956.

O evento foi chamado:

Dartmouth Summer Research Project on Artificial Intelligence.

Entre os participantes estavam nomes que se tornariam lendários:

  • John McCarthy

  • Marvin Minsky

  • Claude Shannon

  • Nathaniel Rochester

Foi John McCarthy quem cunhou o termo:

Artificial Intelligence.

O objetivo do encontro era ambicioso.

Os pesquisadores acreditavam que seria possível descobrir princípios gerais da inteligência e implementá-los em computadores.

Em outras palavras:

eles queriam construir uma mente artificial.


O Excesso de Otimismo

Algo interessante aconteceu logo no início.

Os pesquisadores acertaram na direção geral.

Mas erraram completamente no prazo.

Muitos acreditavam que máquinas comparáveis ao intelecto humano surgiriam em poucas décadas.

A realidade mostrou-se muito mais difícil.

A inteligência humana envolve:

  • percepção;

  • linguagem;

  • memória;

  • abstração;

  • aprendizado;

  • adaptação;

  • contexto.

Resolver apenas uma dessas áreas já se mostrou um desafio gigantesco.

Resolver todas simultaneamente é ainda mais complicado.


O Que É Inteligência Artificial?

Existe uma tendência popular de associar IA apenas a chatbots.

Isso é um erro.

IA é um campo inteiro da computação.

Uma definição razoavelmente moderna seria:

"Conjunto de técnicas computacionais que permitem a sistemas executar tarefas normalmente associadas à inteligência humana."

Isso inclui:

  • reconhecimento de padrões;

  • tomada de decisão;

  • planejamento;

  • aprendizado;

  • tradução;

  • percepção visual;

  • processamento de linguagem.

Observe algo importante.

A definição não menciona consciência.

E isso não é um acidente.


Inteligência Não É Consciência

Muitas discussões públicas misturam conceitos diferentes.

Um sistema pode ser inteligente para determinada tarefa sem possuir consciência.

Por exemplo:

Uma calculadora executa operações matemáticas melhor do que praticamente qualquer ser humano.

Mesmo assim ninguém acredita que ela possua consciência.

O mesmo vale para sistemas modernos de IA.

Eles podem apresentar comportamentos extremamente sofisticados sem necessariamente possuir experiências subjetivas.

Essa distinção é fundamental.


A Primeira Grande Abordagem: IA Simbólica

Os primeiros sistemas de IA eram baseados em símbolos e regras.

O paradigma era simples.

Se especialistas humanos conseguem explicar como raciocinam, então podemos transformar esse raciocínio em código.

Imagine um sistema médico simplificado:

SE febre
E tosse

ENTÃO suspeita de gripe

A lógica parecia perfeita.

Mas logo surgiram problemas.

O mundo real possui exceções praticamente infinitas.

Quanto mais regras eram adicionadas, mais difícil se tornava manter o sistema.

Curiosamente, programadores COBOL entendem esse problema muito bem.

Sistemas corporativos gigantes frequentemente acumulam décadas de regras de negócio.

O resultado pode se tornar extremamente complexo.


Os Sistemas Especialistas

Durante as décadas de 1970 e 1980 surgiu uma categoria chamada Sistemas Especialistas.

Esses sistemas tentavam capturar o conhecimento de especialistas humanos.

Um médico, por exemplo, forneceria regras.

O sistema aplicaria essas regras automaticamente.

Durante algum tempo pareceu que essa abordagem dominaria o futuro.

Mas havia limitações.

Os sistemas não aprendiam.

Eles apenas aplicavam conhecimento previamente inserido.

Toda nova situação exigia trabalho humano.


Os Invernos da IA

Um dos capítulos mais importantes da história da IA raramente aparece em apresentações superficiais.

Os chamados AI Winters.

Ou Invernos da IA.

O padrão se repetiu diversas vezes:

  1. Surge uma descoberta.

  2. O entusiasmo explode.

  3. Promessas exageradas aparecem.

  4. Os resultados não acompanham as expectativas.

  5. O financiamento diminui.

Foi exatamente isso que ocorreu.

A comunidade percebeu que muitos problemas eram muito mais difíceis do que parecia inicialmente.

Durante anos a área perdeu prestígio e investimento.

Essa lição continua extremamente relevante atualmente.


A Mudança de Paradigma

A grande transformação ocorreu quando pesquisadores começaram a fazer uma pergunta diferente.

Ao invés de programar regras diretamente, por que não ensinar a máquina a descobrir regras?

Essa ideia deu origem ao Machine Learning.

Aprendizado de Máquina.


O Que É Machine Learning?

Imagine que você queira identificar gatos.

Na abordagem tradicional você escreveria regras:

  • possui orelhas;

  • possui bigodes;

  • possui cauda.

Mas isso rapidamente se torna complicado.

Agora imagine mostrar milhões de imagens de gatos e não gatos.

O sistema passa a identificar padrões estatísticos.

Ele aprende sozinho.

Esse é o coração do Machine Learning.

O programador deixa de especificar todas as regras.

Passa a construir mecanismos capazes de descobrir regras.


Uma Analogia Para Profissionais COBOL

Imagine um sistema bancário tradicional.

Você programa explicitamente:

  • cálculo de juros;

  • regras de crédito;

  • classificação de clientes.

Tudo é definido manualmente.

No Machine Learning ocorre algo diferente.

Você fornece históricos de dados.

O modelo tenta descobrir padrões existentes nesses dados.

A lógica deixa de ser totalmente explícita.

Ela passa a emergir do treinamento.

Essa mudança foi revolucionária.


Deep Learning

O próximo salto foi o Deep Learning.

Deep Learning é um subconjunto de Machine Learning.

Baseia-se em redes neurais artificiais.

Apesar do nome, essas redes são apenas inspirações matemáticas extremamente simplificadas do cérebro humano.

Não são cérebros digitais.

Não reproduzem neurônios biológicos reais.

São modelos matemáticos.

Mas modelos incrivelmente poderosos.


Por Que Deep Learning Mudou Tudo?

Durante décadas existiram limitações de:

  • processamento;

  • armazenamento;

  • disponibilidade de dados.

Quando esses fatores melhoraram simultaneamente, redes neurais profundas passaram a produzir resultados extraordinários.

Sistemas começaram a:

  • reconhecer imagens;

  • compreender voz;

  • traduzir textos;

  • identificar padrões complexos.

O desempenho cresceu rapidamente.


Deep Blue: O Primeiro Grande Choque Público

Em 1997 ocorreu um evento histórico.

O computador Deep Blue derrotou Garry Kasparov.

Campeão mundial de xadrez.

O mundo ficou impressionado.

Parecia uma demonstração de inteligência artificial.

Mas existe uma nuance importante.

Deep Blue não possuía inteligência geral.

Ele era especialista em xadrez.

Extremamente especializado.

Não conseguia conversar.

Não conseguia dirigir.

Não conseguia escrever artigos.

Mas conseguia jogar xadrez em nível sobre-humano.

Essa distinção continua importante atualmente.


Watson e o Processamento de Linguagem

Em 2011 surgiu outro marco.

IBM Watson venceu o programa Jeopardy.

O desafio era muito diferente do xadrez.

Agora a máquina precisava interpretar linguagem humana.

O feito demonstrou que computadores poderiam lidar com ambiguidades linguísticas em níveis impressionantes.

Mas novamente:

não era uma mente artificial.

Era uma combinação sofisticada de múltiplas técnicas.


AlphaGo e a Surpresa dos Especialistas

Muitos pesquisadores acreditavam que o jogo Go permaneceria difícil por muito mais tempo.

Eles estavam errados.

Em 2016 o AlphaGo derrotou Lee Sedol.

Um dos maiores jogadores do planeta.

O feito chocou especialistas.

O número de possibilidades no Go é gigantesco.

Durante décadas acreditou-se que a intuição humana teria vantagem.

Mas a combinação de Deep Learning com aprendizado por reforço mudou o cenário.


O Que São LLMs?

Chegamos ao assunto mais popular atualmente.

LLM significa:

Large Language Model.

Modelo de Linguagem de Grande Escala.

O ChatGPT é um exemplo.

Mas não é o único.

O conceito fundamental é relativamente simples.

O modelo aprende padrões estatísticos presentes em enormes volumes de texto.


O Próximo Token

De forma extremamente simplificada, um LLM aprende a prever a continuação mais provável de uma sequência.

Exemplo:

"O céu é..."

A continuação mais provável pode ser:

"azul"

Agora imagine realizar esse processo em escala gigantesca.

Bilhões ou trilhões de exemplos.

Com enormes redes neurais.

O resultado é um sistema capaz de gerar texto extremamente convincente.


Mas o ChatGPT Entende?

Essa é uma das perguntas mais debatidas atualmente.

Existem três correntes principais.

A primeira afirma:

"Não entende. Apenas manipula padrões."

A segunda afirma:

"Possui algum grau de compreensão funcional."

A terceira argumenta:

"Se o comportamento é equivalente à compreensão, a distinção pode não ser tão relevante."

A verdade é que não existe consenso definitivo.

A ciência ainda debate essa questão.


IA Não É Sinônimo de ChatGPT

Outro erro comum.

ChatGPT é apenas uma aplicação específica.

A IA moderna inclui:

  • visão computacional;

  • robótica;

  • sistemas de recomendação;

  • previsão financeira;

  • diagnóstico médico assistido;

  • otimização logística;

  • detecção de fraude.

Reduzir IA a chatbots seria como reduzir computação inteira a planilhas eletrônicas.


O Efeito IA

Existe um fenômeno curioso.

Quando uma tecnologia é difícil, chamamos de IA.

Quando se torna comum, deixamos de chamar.

Reconhecimento óptico de caracteres (OCR) já foi considerado IA avançada.

Motores de busca já foram considerados IA.

Sistemas de recomendação também.

Depois que amadurecem, passam a ser vistos como ferramentas normais.

Esse fenômeno recebeu informalmente o nome de AI Effect.


A Relação Entre Mainframe e IA

Muitas pessoas acreditam que ambientes mainframe estão desconectados da revolução da IA.

Na prática, isso não é verdade.

Grande parte dos dados corporativos mais valiosos do mundo continua residindo em:

  • z/OS;

  • DB2;

  • IMS;

  • VSAM;

  • sistemas legados.

Modelos de IA dependem de dados.

E os dados corporativos frequentemente estão em plataformas tradicionais.

Por isso, integração entre IA e mainframe tornou-se uma área estratégica.


O Futuro do Programador COBOL

Uma preocupação recorrente é:

"IA vai substituir programadores COBOL?"

A resposta séria é mais complexa que um simples sim ou não.

Ferramentas de IA já conseguem:

  • sugerir código;

  • documentar programas;

  • explicar rotinas;

  • auxiliar manutenção.

Por outro lado, elas não eliminam a necessidade de compreender:

  • regras de negócio;

  • arquitetura corporativa;

  • requisitos regulatórios;

  • processos empresariais.

Conhecimento de domínio continua sendo extremamente valioso.


Os Desafios Éticos

A discussão atual vai muito além da tecnologia.

Existem questões importantes:

  • privacidade;

  • direitos autorais;

  • viés algorítmico;

  • transparência;

  • concentração de poder.

Quem controla os modelos?

Quem responde por erros?

Quem é dono do conteúdo produzido?

Essas perguntas ainda não possuem respostas definitivas.


Consumo Energético

Modelos modernos exigem infraestrutura gigantesca.

Datacenters utilizam:

  • energia elétrica;

  • sistemas de refrigeração;

  • redes de alta velocidade;

  • milhares de aceleradores computacionais.

O debate ambiental é legítimo.

Ao mesmo tempo, é necessário evitar simplificações.

Existe uma diferença enorme entre:

  • treinar um modelo;

  • utilizar um modelo já treinado.

Os impactos são distintos.


IA Geral Ainda Não Existe

Uma distinção essencial é a diferença entre:

ANI — Artificial Narrow Intelligence

e

AGI — Artificial General Intelligence.

A IA atual pertence majoritariamente à primeira categoria.

São sistemas extremamente competentes em tarefas específicas.

Uma AGI seria algo muito mais amplo.

Capaz de aprender praticamente qualquer domínio intelectual.

Até hoje não existe consenso sobre quando — ou mesmo se — isso será alcançado.


Conclusão

Talvez a maior lição da história da Inteligência Artificial seja a seguinte:

a IA não surgiu com o ChatGPT.

Ela representa décadas de pesquisa, fracassos, descobertas, ciclos de entusiasmo e longos períodos de frustração.

Desde Dartmouth em 1956 até os modernos modelos de linguagem, a área evoluiu continuamente.

Para o programador COBOL, compreender IA não significa abandonar conceitos tradicionais.

Pelo contrário.

Muitas ideias fundamentais continuam as mesmas:

  • representação de informação;

  • processamento de dados;

  • modelagem de problemas;

  • automação de tarefas.

O que mudou foi a escala.

O que mudou foi a capacidade de aprender padrões a partir de enormes volumes de dados.

O que mudou foi a sofisticação dos modelos.

A Inteligência Artificial não substitui a necessidade de pensamento crítico.

Ela torna esse pensamento ainda mais importante.

Porque quanto mais poderosas as ferramentas se tornam, maior é a responsabilidade daqueles que as utilizam.

E talvez essa seja a verdadeira questão da nossa era tecnológica:

não se as máquinas podem ser inteligentes, mas como nós, humanos, escolhemos utilizar a inteligência que construímos.

Esse texto tem estrutura adequada para publicação em blog técnico, newsletter, revista corporativa ou apostila introdutória para formação de programadores COBOL que desejam entender IA sem cair em simplificações ou marketing.

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
GitHub LinkedIn
Inicializando conteúdo...