Translate

quarta-feira, 8 de julho de 2026

Capítulo 8 — Business Week (1994)

Bellacosa mainframe e o dia que a impresna errou

☕ Um Café no Bellacosa Mainframe

Capítulo 8 — Business Week (1994)

O Dia em que a Imprensa Percebeu que Talvez Tivesse Enterrado o Mainframe Cedo Demais

Uma análise da reportagem publicada pela Business Week em 1994, mostrando como a indústria começou a reconhecer que as previsões sobre o fim do mainframe haviam sido exageradas e como o IBM Z continuou sua evolução tecnológica.

Por


Business Week reconhecendo em 1994 que o Mainframe continuava relevante
A reportagem da Business Week marcou um ponto de inflexão, mostrando que o mercado começava a reconsiderar o futuro dos mainframes.

"Quando os fatos mudam, a engenharia muda de direção. Quando o marketing muda de direção, normalmente muda também o discurso."

— Bellacosa Mainframe

Contexto histórico

Após anos de previsões sobre o desaparecimento dos grandes sistemas, empresas descobriram que migrar aplicações críticas era muito mais caro, complexo e arriscado do que parecia nas apresentações de marketing.

George Colony, da Forrester Research, sintetizou essa mudança ao afirmar que era "o fim do fim dos mainframes", reconhecendo que a plataforma continuava estratégica para grandes organizações.

A grande lição

A Business Week mostrou que tendências tecnológicas precisam ser avaliadas à luz dos resultados reais e não apenas das expectativas do mercado.

O IBM Mainframe continuou evoluindo nas décadas seguintes, incorporando Linux, Java, virtualização, DevOps, APIs, cloud híbrida, OpenShift, Inteligência Artificial e chegando ao IBM z17 como uma das plataformas mais resilientes da computação corporativa.


Janeiro de 1994

Estamos agora em um momento extremamente interessante da nossa história.

Até aqui vimos uma sequência de previsões pessimistas.

"O dinossauro."

"O último mainframe será desligado."

"O mainframe está correndo rumo à extinção."

Parecia que existia um consenso.

O funeral já estava marcado.

Faltava apenas escolher quem faria o discurso de despedida.

Mas então aconteceu algo curioso.

O mercado começou a olhar para os números.

E os números possuem um defeito terrível para quem vive de buzzwords.

Eles não ligam para apresentações em PowerPoint.


Alguma coisa não fechava

As vendas de servidores realmente cresciam.

Os PCs realmente dominavam os escritórios.

As redes locais realmente se expandiam.

Mas...

Os bancos continuavam comprando mainframes.

As seguradoras também.

As bolsas de valores igualmente.

As companhias aéreas não desligavam seus CPDs.

Os governos continuavam investindo em grandes sistemas.

As empresas mais críticas da economia simplesmente... não estavam abandonando o IBM Mainframe.

Isso começou a chamar atenção.


O Business Week muda o tom

Em 10 de janeiro de 1994, a Business Week, uma das revistas de negócios mais respeitadas do mundo, publicou uma reportagem que destoava da narrativa predominante.

Em vez de insistir na ideia da morte inevitável do mainframe, a matéria citava George Colony, fundador da Forrester Research, com uma frase que se tornaria histórica:

"It's the end of the end for the mainframes."

Em tradução livre:

"É o fim do fim dos mainframes."

Parece um jogo de palavras.

E é exatamente isso.

Mas também representa uma mudança profunda de percepção.

Pela primeira vez, uma publicação de grande circulação reconhecia que talvez a indústria tivesse exagerado nas previsões anteriores. Essa mudança de tom foi registrada por Wolfgang Spruth em The Death of the Mainframe como um marco importante na evolução do debate sobre a plataforma IBM.


Traduzindo o economês

Vamos simplificar.

George Colony estava dizendo algo parecido com:

"Talvez tenhamos exagerado."

Ou ainda:

"Talvez o problema nunca tenha sido o mainframe."

Ou, numa tradução Bellacosa Mainframe:

"Pessoal... acho que enterramos o paciente antes de confirmar o óbito."


A realidade começou a aparecer

Entre 1991 e 1994 muitas empresas iniciaram grandes projetos de migração.

Alguns deram certo.

Outros...

Nem tanto.

Sistemas previstos para serem reescritos em dezoito meses completavam quatro anos de projeto.

Os custos disparavam.

A complexidade aparecia.

Regras de negócio esquecidas voltavam a assombrar as equipes.

Interfaces que ninguém conhecia surgiam do nada.

Programas COBOL escritos quinze anos antes continuavam funcionando perfeitamente.

Descobriu-se algo que nenhum folder de marketing mencionava.

Legado não significa velho.

Significa importante.


O verdadeiro patrimônio da empresa

Imagine uma seguradora.

Ela possui vinte milhões de clientes.

Cada contrato depende de dezenas de regras.

Regras legais.

Regras fiscais.

Regras atuariais.

Regras internas.

Agora imagine alguém dizendo:

— Vamos reescrever tudo.

A pergunta não é:

"Conseguimos?"

A pergunta é:

"Vale a pena?"

Essa simples mudança de perspectiva transformou completamente a discussão.


Bellacosa Mainframe e o Cobol como o vilão favorito

O COBOL virou o vilão favorito

Durante anos, COBOL foi apresentado como um símbolo do passado.

Parecia existir uma competição para descobrir quem faria a manchete mais dramática.

"O fim do COBOL."

"A última geração de programadores."

"Ninguém mais aprende COBOL."

Enquanto isso...

Universidades deixavam de ensinar COBOL.

Mas bancos continuavam contratando especialistas.

Governos continuavam executando milhões de linhas de código.

Seguradoras ampliavam seus sistemas.

Era uma situação curiosa.

Todo mundo dizia que COBOL estava morrendo.

Mas ninguém queria desligar o sistema que pagava salários.


O humor do velho operador

Imagine um operador de CPD lendo aquela reportagem da Business Week.

Ele olha para o relógio.

Depois para o console.

Mais um JOB termina normalmente.

Outro começa.

Ele comenta com o colega:

— Parece que cancelaram meu funeral.

O colega responde:

— Ainda bem.

Temos o fechamento contábil às oito.


A IBM não ficou parada

Existe um detalhe frequentemente esquecido.

Muitas análises daquela época tratavam o mainframe como se fosse uma tecnologia congelada.

Como se a IBM tivesse parado de inovar.

Isso simplesmente não era verdade.

Enquanto o mercado discutia Client/Server...

A IBM continuava investindo bilhões em pesquisa.

Novos processadores.

Mais memória.

Melhores canais de entrada e saída.

Virtualização cada vez mais sofisticada.

Novos sistemas operacionais.

Ferramentas de desenvolvimento.

Integração com redes abertas.

A plataforma evoluía continuamente.

A diferença é que evolução incremental raramente vira manchete.


O mercado aprendeu uma palavra nova

Na metade da década de 1990 começou a surgir um conceito importante.

Integração.

Até então o debate parecia binário.

Ou era Mainframe.

Ou era Client/Server.

Com o amadurecimento dos projetos, as empresas descobriram que poderiam ter os dois.

O front-end poderia rodar em PCs.

As aplicações departamentais em servidores distribuídos.

E o processamento crítico permanecer no mainframe.

Hoje isso parece óbvio.

Na época foi quase revolucionário.


O Padawan visita uma reunião de diretoria

Nosso Padawan COBOL entra discretamente na sala.

Um consultor termina sua apresentação.

— Precisamos substituir completamente o mainframe.

O diretor financeiro faz apenas uma pergunta.

— Quanto custará?

O consultor responde.

— Aproximadamente cinquenta milhões de dólares.

O diretor permanece em silêncio.

Depois pergunta novamente.

— E se não substituirmos?

Outro silêncio.

Nesse momento o arquiteto da empresa comenta:

— Podemos integrar os novos sistemas ao ambiente existente.

A reunião muda completamente de direção.

Porque, no mundo corporativo, arquitetura sempre precisa conversar com orçamento.


O início da convivência

Foi justamente nessa época que a indústria começou a abandonar uma visão extremamente simplista.

Não era mais uma guerra.

Não existia vencedor absoluto.

Cada plataforma possuía seu espaço.

Mainframe para grandes volumes transacionais.

Servidores distribuídos para aplicações departamentais.

PCs para produtividade.

Mais tarde chegariam Linux.

Java.

Web Services.

Cloud.

Containers.

OpenShift.

Todos convivendo.

Essa mudança de mentalidade talvez tenha sido muito mais importante do que qualquer evolução de hardware.


O "fim do fim"

A frase de George Colony continua brilhante porque resume perfeitamente aquele momento.

Não significava que o mainframe venceria todas as disputas.

Também não significava que nada mudaria.

Significava apenas que a narrativa da morte inevitável começava a perder força.

A indústria finalmente compreendia algo essencial.

Uma tecnologia pode deixar de ser a única solução.

Sem deixar de ser uma solução excelente.


Trinta e dois anos depois

Estamos em 2026.

O IBM z17 integra Inteligência Artificial diretamente na plataforma.

O watsonx fornece modelos corporativos.

O BOB automatiza pipelines modernos.

O Zowe aproxima desenvolvedores open source.

O Ansible automatiza operações.

O COBOL continua recebendo novas versões.

O Db2 continua evoluindo.

O CICS continua sendo um dos monitores transacionais mais eficientes do mundo.

A grande surpresa?

Nada disso exigiu abandonar a arquitetura construída ao longo de décadas.

A plataforma simplesmente evoluiu.


A quarta grande lição

A reportagem da Business Week representa um momento raro na história da tecnologia.

O instante em que parte da imprensa começou a perceber que previsões muito otimistas também precisam ser revisadas.

Esse talvez seja o maior ensinamento deste capítulo.

Boa engenharia não se apaixona por modismos.

Ela mede.

Testa.

Observa.

Corrige.

E muda de opinião quando os fatos mudam.

Foi exatamente isso que começou a acontecer em 1994.

O mercado percebeu que a pergunta nunca deveria ter sido:

"Quem vai substituir o mainframe?"

A pergunta correta era:

"Como integrar novas tecnologias ao que já funciona extraordinariamente bem?"

Essa mudança de pergunta moldou praticamente toda a computação corporativa das três décadas seguintes.

E talvez explique por que, em vez de um túmulo...

Encontramos em 2026 um IBM z17 executando COBOL, Db2, CICS, Linux, OpenShift, APIs REST, DevOps, watsonx e Inteligência Artificial.

O funeral foi cancelado.

A evolução, não.


Fonte histórica

Business Week, 10 de janeiro de 1994, citando George Colony (Forrester Research) com a frase "It's the end of the end for the mainframes." O artigo, preservado por Wolfgang Spruth em The Death of the Mainframe, marcou uma inflexão importante no discurso da indústria: pela primeira vez, uma grande publicação reconhecia que as previsões sobre a extinção do mainframe talvez tivessem sido precipitadas.

Bellacosa Mainframe e o Funeral que nunca aconteceu


C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

DevOps no Mainframe: O Guia Definitivo para Quem Programa em COBOL e Quer Entrar no Mundo da Entrega Contínua

 

Bellacosa Mainframe e o guia do devops para mainframe

☕ Um Café no Bellacosa Mainframe

DevOps no Mainframe: O Guia Definitivo para Quem Programa em COBOL e Quer Entrar no Mundo da Entrega Contínua

"DevOps não é instalar uma ferramenta. É mudar a forma como pensamos sobre desenvolvimento, testes, implantação e operação. E sim... isso também vale para COBOL."

Se você trabalha com IBM Mainframe há alguns anos, provavelmente já ouviu alguém dizer:

"Mainframe não precisa de DevOps."

Ou então:

"DevOps é coisa de Java, Kubernetes e Cloud."

Nada poderia estar mais distante da realidade.

Hoje, os maiores bancos, seguradoras, empresas de cartão de crédito, telecomunicações e governos do mundo utilizam práticas de DevOps justamente nos ambientes mais críticos: os sistemas IBM Z.

A verdade é simples:

O código COBOL continua excelente. O processo de desenvolvimento é que evoluiu.

Neste café vamos entender, de maneira prática, o que é DevOps, como funciona, quais ferramentas existem, como começar do zero e como implantar esse modelo em uma fábrica de software Mainframe.

Pegue seu café.

Vamos conversar.


Antes de tudo: o que é DevOps?

A palavra DevOps vem da união de duas áreas:

  • Development (Desenvolvimento)

  • Operations (Operação)

Durante décadas essas equipes trabalharam separadas.

O desenvolvedor escrevia código.

O operador implantava.

O suporte resolvia problemas.

Quando dava errado...

Todo mundo culpava o outro.

DevOps nasceu justamente para eliminar esse conflito.

O objetivo é fazer todos trabalharem juntos durante todo o ciclo de vida do software.


O ciclo tradicional

Durante muitos anos o fluxo era parecido com isto:

Analista
      ↓
Programador COBOL
      ↓
Testes
      ↓
Homologação
      ↓
Mudança
      ↓
Produção

Tudo manual.

Muito e-mail.

Planilhas.

Checklist.

JCL executado manualmente.

Libraries copiadas.

Muitas chances de erro humano.


O ciclo DevOps

Agora imagine outro cenário.

Programador
      ↓
Git
      ↓
Build automático
      ↓
Testes automáticos
      ↓
Deploy automático
      ↓
Homologação
      ↓
Produção
      ↓
Monitoramento

Tudo rastreado.

Tudo versionado.

Tudo auditável.

Esse é o objetivo do DevOps.


DevOps não é uma ferramenta

Este talvez seja o maior erro dos iniciantes.

DevOps não é:

  • Jenkins

  • Git

  • GitHub

  • Azure DevOps

  • GitLab

Essas são ferramentas.

DevOps é uma cultura.

As ferramentas apenas ajudam.


Bellacosa Mainframe e o devops para iniciante mainframe

Os pilares do DevOps

Podemos resumir DevOps em seis grandes pilares.

1. Planejamento

Toda mudança começa aqui.

Exemplo:

  • Nova funcionalidade

  • Correção de bug

  • Mudança legal

  • Novo produto

Ferramentas:

  • Jira

  • Azure Boards

  • Trello

  • ServiceNow


2. Desenvolvimento

Aqui entra o programador COBOL.

Ele escreve código.

Exemplo:

Programa COBOL

+
JCL

+
PROC

+
Copybooks

+
DB2

+
CICS

Tudo precisa ficar versionado.


3. Integração Contínua (CI)

Sempre que alguém altera o código...

O sistema automaticamente:

  • compila

  • executa testes

  • verifica qualidade

  • gera relatórios

Sem intervenção humana.


4. Testes

Não basta compilar.

É necessário testar.

Tipos comuns:

  • teste unitário

  • teste funcional

  • teste integração

  • teste regressão

  • teste performance

No Mainframe isso pode envolver:

  • ZUnit

  • IBM Debug

  • File Manager

  • stubs

  • dados mascarados


5. Deploy

Depois da aprovação:

o sistema promove automaticamente os artefatos entre ambientes.

DEV

↓

QA

↓

HML

↓

PRD

Sem copiar datasets manualmente.


6. Monitoramento

Depois da implantação...

O trabalho continua.

Monitoramos:

  • CPU

  • tempo de resposta

  • erros

  • logs

  • abends

  • consumo

  • throughput


Bellacosa Mainframe e ferramentas para implementar o devops

O famoso CI/CD

Você verá muito essa sigla.

CI

Continuous Integration

CD

Continuous Delivery

ou

Continuous Deployment.

A diferença é simples.

Continuous Delivery

O deploy fica pronto.

Mas alguém aprova.

Continuous Deployment

O deploy acontece automaticamente.


Como isso funciona no Mainframe?

Imagine um programa COBOL.

Você altera uma linha.

Ao salvar:

Git

↓

Pipeline

↓

Compilação

↓

Link-edit

↓

Testes

↓

Deploy

↓

Homologação

Tudo automático.


Ferramentas mais usadas

Vamos conhecer as principais.

Git

O coração do DevOps.

Ele controla versões.

Permite:

  • histórico

  • branches

  • merge

  • rollback

Hoje praticamente todo projeto moderno usa Git.

Inclusive Mainframe.


GitHub

Hospeda repositórios Git.

Possui:

  • Pull Request

  • Code Review

  • Actions

  • Issues

Muito usado em projetos open source.


GitLab

Além do Git...

Possui pipeline integrada.

Muito utilizado em empresas.


Azure DevOps

Muito comum em bancos.

Possui:

  • Boards

  • Repos

  • Pipelines

  • Artifacts

  • Test Plans

Integra muito bem com ambientes corporativos.


Jenkins

Uma das ferramentas de automação mais famosas.

Ele executa:

  • compilação

  • testes

  • deploy

  • scripts

Tudo automaticamente.


IBM Dependency Based Build (DBB)

Ferramenta criada pela IBM para Mainframe.

Ela entende:

  • COBOL

  • PL/I

  • Assembler

  • JCL

  • Copybooks

Excelente para pipelines IBM Z.


IBM Developer for z/OS (IDz)

Substitui boa parte do ISPF.

Integra:

  • Git

  • Debug

  • Build

  • Pipeline


Zowe

Talvez a maior revolução dos últimos anos.

Permite acessar o Mainframe usando:

  • VS Code

  • APIs

  • CLI

  • Explorer

É praticamente uma ponte entre o mundo distribuído e o IBM Z.


VS Code

Hoje muitos programadores COBOL utilizam VS Code.

Com extensões adequadas é possível:

  • editar COBOL

  • enviar código

  • acessar datasets

  • executar comandos


Ansible

Automação de infraestrutura.

Pode automatizar:

  • configuração

  • deploy

  • instalação

  • tarefas repetitivas


SonarQube

Analisa qualidade do código.

Detecta:

  • duplicação

  • complexidade

  • bugs

  • vulnerabilidades

Inclusive existem plugins para COBOL.


JFrog Artifactory

Gerencia artefatos.

Armazena:

  • builds

  • binários

  • versões


Um pipeline simples

Imagine este fluxo.

Programador

↓

Git Commit

↓

Pipeline

↓

Compilar COBOL

↓

Executar testes

↓

Quality Gate

↓

Deploy DEV

↓

Deploy QA

↓

Deploy HML

↓

Produção

Sem copiar datasets manualmente.

Sem FTP.

Sem e-mail.


Como implantar DevOps em um sistema Mainframe?

Aqui está um roteiro simples.

Etapa 1

Mapeie o processo atual.

Pergunte:

Como o programa chega em produção?

Quem aprova?

Quem compila?

Quem faz bind?

Quem copia load modules?

Quem altera CICS?

Quem agenda o Job?


Etapa 2

Versione tudo.

Não apenas programas COBOL.

Também:

  • JCL

  • PROC

  • Copybooks

  • SQL

  • DDL

  • Scripts

  • Documentação


Etapa 3

Padronize.

Todos devem usar:

Mesmo padrão.

Mesmo fluxo.

Mesmo processo.


Etapa 4

Automatize a compilação.

Em vez de:

Editar

Compilar

Link

Testar

Faça:

Commit

↓

Pipeline

↓

Compilação automática

Etapa 5

Automatize testes.

Quanto mais testes...

Maior a confiança.


Etapa 6

Automatize deploy.

Reduza:

  • intervenção humana

  • erros

  • esquecimentos


Etapa 7

Monitore.

Depois do deploy acompanhe:

  • SMF

  • RMF

  • JES

  • SDSF

  • logs

  • CICS

  • DB2


Roadmap para quem está começando

Nível 1

Aprenda:

  • Git

  • GitHub

  • Branch

  • Merge

  • Pull Request


Nível 2

Aprenda:

  • Jenkins

  • Azure DevOps

  • GitLab CI


Nível 3

Aprenda:

  • Pipeline

  • YAML

  • Build


Nível 4

Aprenda:

  • Zowe CLI

  • VS Code

  • REST APIs


Nível 5

Aprenda:

  • DBB

  • IDz

  • SonarQube


Nível 6

Aprenda:

  • Docker (conceitos)

  • Kubernetes (conceitos)

  • OpenShift

Mesmo trabalhando apenas com Mainframe.


Nível 7

Aprenda observabilidade.

Conheça:

  • Grafana

  • Prometheus

  • Elastic

  • OpenTelemetry

Mesmo que parte do monitoramento do IBM Z utilize soluções específicas da IBM.


Quanto custa implantar?

A resposta depende do ambiente.

Há soluções gratuitas e corporativas.

Gratuitas

  • Git

  • GitHub (planos gratuitos)

  • VS Code

  • Jenkins

  • Zowe

  • SonarQube Community

O investimento principal será tempo de implantação, treinamento e adaptação dos processos.

Corporativas

Dependendo da empresa podem existir licenças para:

  • IBM Dependency Based Build

  • IBM Developer for z/OS

  • Azure DevOps

  • GitHub Enterprise

  • GitLab Enterprise

  • JFrog Artifactory

  • UrbanCode Deploy (ou soluções equivalentes)

  • ferramentas de testes automatizados

Além das licenças, considere:

  • infraestrutura

  • treinamento

  • consultoria

  • integração com RACF, CICS, DB2 e sistemas legados

  • manutenção contínua

Apesar do investimento inicial, a redução de retrabalho e de falhas costuma compensar em projetos de médio e grande porte.


Quais são os riscos?

Toda mudança traz desafios.

Os principais são:

Resistência cultural

O maior obstáculo raramente é técnico.

É comum ouvir:

"Sempre fizemos assim."

Sem apoio da liderança, a adoção perde força.

Automação mal planejada

Automatizar um processo ruim apenas faz o erro acontecer mais rápido.

Primeiro simplifique.

Depois automatize.

Falta de testes

Um pipeline sem testes é apenas um "copiador automático" de problemas.

Invista em testes desde o início.

Controle de acesso

Automações precisam respeitar políticas de segurança.

Integração com RACF, auditoria e segregação de funções são indispensáveis.

Dependência de poucas pessoas

Evite que apenas um especialista conheça o pipeline. Documente, treine a equipe e compartilhe conhecimento.


As grandes vantagens

Os benefícios aparecem rapidamente.

  • Menos erros manuais.

  • Entregas mais rápidas.

  • Maior rastreabilidade.

  • Rollback simplificado.

  • Melhor colaboração entre desenvolvimento e operações.

  • Qualidade de código mais alta.

  • Testes executados com frequência.

  • Auditoria facilitada.

  • Processos padronizados.

  • Redução do tempo de implantação.

  • Mais confiança para liberar novas versões.

  • Maior integração entre Mainframe e plataformas distribuídas.

Para ambientes regulados, como bancos e seguradoras, isso também significa maior conformidade e facilidade em auditorias.


E as desvantagens?

Nem tudo são flores.

  • Curva de aprendizado inicial.

  • Mudança cultural pode gerar resistência.

  • Necessidade de treinamento.

  • Tempo para configurar pipelines.

  • Investimento em ferramentas corporativas, quando necessário.

  • Ajustes em processos antigos.

  • Necessidade de governança para evitar pipelines desorganizados.

A boa notícia é que esses desafios diminuem à medida que a equipe ganha experiência.


Um exemplo prático

Imagine que uma alteração fiscal exige mudanças em um programa COBOL.

Sem DevOps:

  1. Desenvolvedor altera o código.

  2. Envia por e-mail.

  3. Outro profissional compila.

  4. Um terceiro faz o BIND.

  5. Alguém copia o módulo para homologação.

  6. Os testes são executados manualmente.

  7. A documentação é atualizada depois (ou esquecida).

  8. A implantação depende de uma janela operacional.

Com DevOps:

  1. O desenvolvedor cria uma branch.

  2. Implementa a alteração.

  3. Abre um Pull Request.

  4. O código passa por revisão.

  5. O pipeline compila automaticamente.

  6. Testes unitários e de integração são executados.

  7. A qualidade é validada pelo SonarQube.

  8. Após aprovação, o deploy é promovido para homologação.

  9. Com a autorização final, a mesma pipeline promove a versão para produção.

  10. Todo o processo fica registrado para auditoria.

Perceba que o COBOL continua sendo COBOL. O que mudou foi a forma de entregar software.


Conclusão

Durante muito tempo, DevOps foi visto como algo exclusivo do mundo Linux, Java e Cloud. Hoje sabemos que essa visão ficou no passado.

O IBM Z evoluiu. Ferramentas como Git, Zowe, IBM Dependency Based Build, Azure DevOps, Jenkins e pipelines de CI/CD permitem que aplicações COBOL participem do mesmo ciclo moderno de desenvolvimento utilizado nas demais plataformas da empresa.

Se você é um Padawan COBOL, não tente aprender tudo de uma vez. Comece pelo essencial: Git, versionamento, revisão de código e conceitos de integração contínua. Em seguida, avance para pipelines, automação de testes e deploy. Com essa base, ferramentas específicas do Mainframe farão muito mais sentido.

Lembre-se: DevOps não substitui o conhecimento de COBOL, JCL, CICS ou DB2. Ele potencializa esse conhecimento, reduzindo erros, aumentando a qualidade e permitindo que sistemas críticos evoluam com segurança.

No fim das contas, o maior legado do DevOps não é uma ferramenta nem um pipeline. É uma mudança de mentalidade: desenvolver, testar, implantar e operar como um único time, entregando valor continuamente para o negócio.

E esse, meu amigo Padawan, é um princípio que nunca ficará obsoleto.


PERFORM Recursivo em COBOL: O Warning que Todo Padawan Ignora (Até o Job Estourar o TIME e o REGION)

 

Bellacosa e o perigo do perform recursivo

☕ Um Café no Bellacosa Mainframe

PERFORM Recursivo em COBOL: O Warning que Todo Padawan Ignora (Até o Job Estourar o TIME e o REGION)

"Recursão é uma ferramenta fantástica... exceto quando você tenta usá-la como estrutura de repetição dentro de um programa COBOL Batch."

Quem vem de Java, C#, Python ou C costuma achar natural escrever funções recursivas.

Quem cresceu no COBOL aprende rapidamente uma regra quase sagrada:

Nunca faça um PERFORM recursivo em um parágrafo ou seção.

Mas por quê?

Vamos abrir o capô do compilador.


Primeiro: o que é um PERFORM recursivo?

Imagine algo assim:

0000-PRINCIPAL.

    PERFORM 1000-PROCESSA

    STOP RUN.

1000-PROCESSA.

    DISPLAY "PROCESSANDO"

    PERFORM 1000-PROCESSA.

O programa chama...

...que chama...

...que chama...

...que chama novamente...

Nunca termina.


O warning da compilação

O Enterprise COBOL consegue detectar algumas formas óbvias de recursão.

Durante a compilação pode surgir mensagens semelhantes a:

IGYPSxxxx-W

Recursive PERFORM detected.

ou

Possible recursive PERFORM.

O compilador está dizendo:

"Existe um caminho onde este PERFORM pode executar novamente antes do anterior terminar."

Nem sempre é erro.

Mas quase sempre indica problema de projeto.


Por que isso é perigoso?

Porque PERFORM não foi criado para funcionar como chamada infinita de procedimentos.

Cada PERFORM precisa guardar informações como:

  • endereço de retorno

  • contexto de execução

  • pilha de controle

  • informações internas do runtime

A cada nova chamada tudo isso cresce.

PERFORM A
    ↓
PERFORM A
    ↓
PERFORM A
    ↓
PERFORM A
    ↓
PERFORM A

A pilha nunca é liberada.


O que acontece durante a execução?

Enquanto houver memória:

Stack

+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+

Cada PERFORM adiciona um novo frame.

Quando acaba a pilha...

Boom.


O programa pode terminar com

Dependendo do ambiente:

  • S0C1

  • S0C4

  • S0CB

  • S878

  • S80A

Ou simplesmente:

ABEND

Tudo depende de onde ocorreu a falha.


O erro de TIME no JCL

Muito antes da memória acabar...

o Job pode morrer por tempo.

Exemplo:

//STEP1 EXEC PGM=MEUPROG,TIME=1

ou

TIME=1440

Mesmo com TIME=1440...

o programa nunca termina.

O JES percebe que o tempo máximo foi atingido.

Resultado:

S322

Ou mensagens semelhantes indicando limite de CPU excedido.

Não foi o COBOL.

Foi o JCL protegendo o sistema.


O erro de REGION

Outro clássico.

Cada PERFORM recursivo consome mais memória.

Em algum momento:

REGION=0M

não resolve.

Porque memória infinita não existe.

O resultado costuma ser:

S878

ou

S80A

Falta de armazenamento.


"Mas REGION=0M não é infinito?"

Não.

É apenas o máximo permitido pela instalação.

Existe limite de:

  • memória virtual

  • stack

  • storage abaixo da linha

  • storage acima da linha

  • política do sistema

Nada disso é infinito.


O maior problema: lógica

Suponha:

1000-ROTINA.

    IF WS-FIM = 'N'
       PERFORM 1000-ROTINA
    END-IF.

Quem altera:

WS-FIM

Se ninguém alterar...

Nunca haverá saída.

É um loop infinito disfarçado.


Por que não usar recursão em parágrafos e seções?

Porque COBOL foi projetado para outro paradigma.

A linguagem nasceu para processamento sequencial.

Ela possui comandos próprios para repetição.

Como:

PERFORM UNTIL
PERFORM VARYING
SEARCH
SEARCH ALL

Essas estruturas:

  • são previsíveis

  • ocupam pouca memória

  • facilitam depuração

  • têm melhor desempenho


"Mas COBOL suporta recursão."

Sim.

Desde o Enterprise COBOL moderno existe:

RECURSIVE PROGRAM-ID.

ou

PROGRAM-ID. MEUPROG RECURSIVE.

Isso significa que o programa pode chamar a si próprio.

Exemplo clássico:

  • árvore binária

  • parsing

  • algoritmos matemáticos

  • estruturas hierárquicas

Mesmo assim...

Não significa que seja recomendado para processamento batch tradicional.


A diferença importante

Errado

Parágrafo
↓

PERFORM

↓

Mesmo parágrafo

Recursão interna.

Difícil de manter.


Correto

Programa A

CALL Programa A

Novo contexto

Retorna

Quando realmente houver necessidade de recursão.


Curiosidade

Os compiladores antigos praticamente desencorajavam qualquer tipo de recursão.

O foco sempre foi:

  • velocidade

  • previsibilidade

  • baixo consumo de memória

A maioria dos sistemas bancários jamais precisou de recursão.


Como um sênior resolveria?

Em vez disso:

PERFORM UNTIL WS-FIM = 'S'

    ...

END-PERFORM

ou

PERFORM VARYING IDX FROM 1 BY 1
        UNTIL IDX > TOTAL

Muito mais claro.

Muito mais rápido.

Muito mais seguro.


Boas práticas

✅ Prefira PERFORM UNTIL para laços controlados.

✅ Use PERFORM VARYING para contadores.

✅ Evite PERFORM chamando o próprio parágrafo.

✅ Revise IFs que nunca alteram a condição de saída.

✅ Analise os warnings do compilador; eles frequentemente apontam defeitos reais de lógica.

✅ Monitore consumo de CPU e storage no SDSF durante testes.

✅ Se precisar de recursão, utilize programas declarados RECURSIVE e valide cuidadosamente profundidade máxima e condição de parada.

✅ Sempre tenha uma condição de saída claramente identificável.


Dicas de depuração

Se um Job "não termina":

  1. Verifique se a CPU continua aumentando no SDSF.

  2. Procure PERFORMs que retornam ao mesmo parágrafo.

  3. Confirme se a variável de controle realmente muda.

  4. Ative SSRANGE em ambiente de teste para detectar erros relacionados a índices e referências inválidas.

  5. Gere um compile listing (LIST, MAP, XREF) para acompanhar o fluxo de chamadas.

  6. Revise mensagens do compilador; um warning ignorado hoje pode virar um ABEND amanhã.


Caminho para o Padawan COBOL

Antes de pensar em recursão, domine completamente:

  1. PERFORM

  2. PERFORM THRU

  3. PERFORM UNTIL

  4. PERFORM VARYING

  5. Estrutura de parágrafos e seções

  6. Escopo explícito (END-IF, END-PERFORM)

  7. Fluxo estruturado sem GO TO

  8. Subprogramas com CALL

  9. Programas RECURSIVE apenas quando o problema realmente exigir

Quando você entender por que o COBOL prefere estruturas iterativas, começará a enxergar o sistema como os arquitetos do IBM Z enxergam: programas previsíveis, eficientes e fáceis de manter. Em ambientes que processam milhões de transações por dia, previsibilidade vale muito mais do que elegância acadêmica.


terça-feira, 7 de julho de 2026

Capítulo 7 — The New York Times (1993)

Bellacosa Mainframe rumo a extincao baboseira de 1993

☕ Um Café no Bellacosa Mainframe

Capítulo 7 — The New York Times (1993)

"Rumo à Extinção"... ou Apenas Mudando de Forma?

Análise da reportagem publicada pelo The New York Times em 1993, que afirmava que o mainframe caminhava para a extinção, e como a evolução do IBM Z demonstrou que inovação e continuidade podem caminhar lado a lado.

Por

Reportagem do The New York Times de 1993 prevendo a extinção do Mainframe
Em 1993, novas previsões indicavam que o Mainframe caminhava para a extinção. A história mostrou um resultado bem diferente.

"A tecnologia raramente desaparece porque outra nasceu. Ela desaparece quando deixa de resolver problemas. Em 1993, o Mainframe continuava resolvendo os maiores problemas da computação corporativa."

— Bellacosa Mainframe

Contexto histórico

No início da década de 1990, a expansão das redes, do modelo Client/Server e dos computadores pessoais reforçou a percepção de que os grandes sistemas centralizados desapareceriam em poucos anos.

Entretanto, bancos, seguradoras, governos e grandes empresas continuavam dependendo do processamento transacional oferecido por COBOL, CICS, Db2 e z/OS.

A lição de 1993

A previsão ignorava décadas de regras de negócio, compatibilidade, escalabilidade, disponibilidade e confiabilidade acumuladas pelos mainframes IBM.

Em vez de desaparecer, a plataforma continuou evoluindo até chegar ao IBM z17, incorporando Linux, APIs, DevOps, cloud híbrida e Inteligência Artificial.


Fevereiro de 1993

Quatro anos haviam se passado desde a primeira reportagem do The New York Times.

O mundo já era outro.

O muro de Berlim havia caído.

A Guerra Fria terminara.

A internet começava a sair dos laboratórios.

O Windows 3.1 conquistava milhões de usuários.

O UNIX continuava crescendo.

As workstations da Sun Microsystems eram o sonho de muitos desenvolvedores.

Os servidores Intel evoluíam rapidamente.

A arquitetura Client/Server dominava praticamente todas as conferências de tecnologia.

E o clima era de euforia.

Parecia que tudo seria reinventado.

Foi nesse ambiente que o The New York Times, em 9 de fevereiro de 1993, voltou ao assunto.

Desta vez utilizando uma expressão ainda mais forte.

Segundo a reportagem, o mainframe estava:

"Hurtling toward extinction."

Ou, em português:

"Correndo em direção à extinção."

A mensagem era clara.

Agora não se tratava apenas de um dinossauro envelhecido.

Tratava-se de uma espécie que caminhava rapidamente para desaparecer. Essa manchete foi posteriormente preservada por Wolfgang Spruth em The Death of the Mainframe como um dos exemplos mais representativos do pensamento dominante da época.


O auge do Client/Server

Se 1989 marcou o nascimento da narrativa...

1993 marcou seu auge.

Era praticamente impossível participar de um congresso de informática sem ouvir dezenas de palestras prometendo o mesmo futuro.

Tudo seria distribuído.

Cada departamento teria seus próprios servidores.

Os grandes CPDs desapareceriam.

A palavra da moda era:

Downsizing.

Na prática significava:

"Vamos trocar um computador enorme por centenas de computadores menores."

A ideia parecia brilhante.

Até que chegaram as primeiras contas de manutenção.


A década em que tudo seria "Open"

Outra característica marcante daquela época era a obsessão por sistemas "abertos".

Parecia que qualquer produto precisava carregar a palavra Open para ser considerado moderno.

Open Systems.

Open Architecture.

Open Computing.

Open Network.

Open Platform.

Open Software.

Era quase uma lei do marketing.

Se fosse "Open", era inovador.

Se fosse IBM, era "legado".

O curioso é que a própria IBM participava ativamente da padronização de tecnologias abertas, apoiava TCP/IP, POSIX, UNIX (AIX) e diversas iniciativas de interoperabilidade.

Mas isso raramente aparecia nas manchetes.


O que ninguém queria admitir

Existe uma característica curiosa do mercado de tecnologia.

Todo vendedor gosta de falar sobre instalação.

Pouquíssimos gostam de falar sobre migração.

Porque instalar um sistema novo é relativamente simples.

Migrar quarenta anos de operação é outra história.

Imagine um grande banco em 1993.

Ele possuía:

  • milhares de programas COBOL;

  • centenas de tabelas Db2;

  • aplicações CICS;

  • processamento batch;

  • integração com terminais 3270;

  • interfaces com caixas eletrônicos;

  • sistemas de compensação bancária;

  • processamento de cartões;

  • folhas de pagamento;

  • contabilidade;

  • auditoria.

Agora imagine um consultor dizendo:

"Vamos reescrever tudo."

A primeira pergunta de um diretor experiente provavelmente seria:

"Quanto custa?"

A segunda:

"Quanto tempo?"

E a terceira:

"Quem assume o risco?"

Essas três perguntas costumavam encerrar muitas reuniões.


A grande confusão

A reportagem do New York Times refletia um erro extremamente comum.

Confundir:

Evolução da arquitetura

com

Substituição da arquitetura.

Essas duas coisas são completamente diferentes.

Sim.

As empresas passaram a utilizar mais servidores.

Sim.

Aplicações departamentais migraram para outras plataformas.

Sim.

PCs transformaram o ambiente corporativo.

Mas isso nunca significou que os sistemas centrais deixariam automaticamente de existir.

Na verdade...

Eles passaram a conversar com muito mais sistemas do que antes.


Bellacosa Mainframe e o iceberg invisivel

O iceberg invisível

Imagine um enorme iceberg.

A parte visível representa:

  • computadores pessoais;

  • servidores;

  • interfaces gráficas;

  • aplicações de escritório.

A parte submersa representa:

  • regras de negócio;

  • processamento financeiro;

  • consistência transacional;

  • auditoria;

  • integração;

  • disponibilidade;

  • segurança.

A imprensa olhava principalmente para a parte visível.

Os arquitetos corporativos precisavam cuidar da parte submersa.

E todos sabemos qual parte sustenta o iceberg.


O COBOL não recebeu o memorando

Vamos imaginar uma situação curiosa.

Na manhã de 9 de fevereiro de 1993...

Um programa COBOL inicia sua execução.

Lê um arquivo VSAM.

Consulta o Db2.

Atualiza uma conta corrente.

Executa um COMMIT.

Encerra normalmente.

Horas depois alguém comenta:

— Você ficou sabendo?

— Do quê?

— O New York Times disse que você está caminhando para a extinção.

O programa responde:

— Interessante...

Mas antes preciso processar mais oito milhões de registros.


O humor da engenharia

Existe uma piada entre veteranos de mainframe.

"COBOL nunca lê jornais."

CICS também não.

Db2 muito menos.

JCL definitivamente não.

Enquanto analistas discutiam o futuro...

Os sistemas continuavam executando exatamente aquilo para o qual foram projetados.

Com estabilidade.

Previsibilidade.

Consistência.

Essas características nunca foram manchetes.

Mas sempre foram extremamente valiosas.


O mercado começou a descobrir a realidade

Curiosamente...

Foi justamente em meados da década de 1990 que muitas empresas começaram a perceber que migrar aplicações críticas era muito mais complexo do que parecia.

Projetos previstos para dois anos levavam cinco.

Orçamentos dobravam.

Alguns triplicavam.

Diversas iniciativas eram canceladas.

Outras terminavam funcionando...

Mas com desempenho inferior.

Os consultores descobriram uma verdade que os programadores COBOL já conheciam havia décadas.

Negócio é mais complicado do que tecnologia.


Enquanto isso... nos laboratórios da IBM

É interessante observar o contraste.

Enquanto jornais discutiam a possível extinção do mainframe...

A IBM trabalhava na próxima geração de sua plataforma.

Novos processadores.

Mais memória.

Mais canais.

Melhor gerenciamento de workload.

Mais virtualização.

Maior integração.

Os engenheiros pareciam ignorar completamente o funeral organizado pela imprensa.

Talvez porque estivessem ocupados demais desenvolvendo o futuro.


O verdadeiro patrimônio

Existe uma frase muito conhecida entre arquitetos de sistemas:

"As empresas não compram computadores. Elas compram continuidade do negócio."

Essa talvez seja a maior diferença entre um laboratório e um banco.

Entre uma universidade e uma seguradora.

Entre uma startup e um governo.

Tecnologia muda.

O negócio precisa continuar funcionando.

Todos os dias.

Sem exceção.

Essa exigência nunca saiu de moda.


Trinta e três anos depois

Agora olhe para 2026.

O IBM z17 processa Inteligência Artificial diretamente na plataforma.

O watsonx integra modelos de IA corporativa.

O COBOL continua evoluindo.

O Db2 incorpora recursos modernos.

O CICS expõe APIs REST.

O z/OS automatiza operações com Ansible.

O BOB integra pipelines DevOps.

O Zowe aproxima o mundo open source do IBM Z.

A plataforma que estaria "correndo rumo à extinção"...

Na verdade estava correndo rumo à modernização.

Existe uma diferença enorme entre essas duas trajetórias.


A terceira grande lição

A reportagem de 1993 ensina algo extremamente atual.

Toda vez que surge uma inovação importante...

Existe a tentação de transformar crescimento em exclusividade.

Foi assim com:

Client/Server.

Internet.

Cloud.

Microservices.

Blockchain.

Metaverso.

Agora acontece com Inteligência Artificial.

Mas a História mostra outra coisa.

A computação raramente substitui completamente suas fundações.

Ela constrói novos andares sobre elas.

Hoje uma aplicação pode começar em um smartphone.

Passar por APIs.

Atravessar Kubernetes.

Conversar com microsserviços.

Chegar ao CICS.

Consultar Db2.

Executar COBOL.

E responder ao usuário em poucos milissegundos.

Esse é o verdadeiro retrato da computação moderna.

Não uma guerra entre tecnologias.

Mas uma colaboração entre décadas de engenharia.


Um último conselho ao Padawan

Quando encontrar uma manchete afirmando:

"A tecnologia X está caminhando para a extinção."

Lembre-se de uma pergunta simples.

Ela ainda resolve um problema importante?

Se a resposta for "sim"...

Talvez ela esteja apenas evoluindo de maneira silenciosa.

Porque, na engenharia, quem faz mais barulho nem sempre é quem entrega mais resultados.

E talvez essa seja a maior ironia da reportagem do New York Times de 1993.

Enquanto o jornal enxergava um fim próximo...

Os engenheiros da IBM estavam preparando o caminho que, décadas depois, levaria ao IBM z17, ao watsonx, ao OpenShift, ao BOB, ao Zowe e a uma plataforma capaz de unir o legado das aplicações COBOL com a Inteligência Artificial corporativa.

O "dinossauro" não caminhava para a extinção.

Estava apenas iniciando mais uma etapa de sua evolução.


Fonte histórica

The New York Times, 9 de fevereiro de 1993, citado pelo Professor Wolfgang Spruth em The Death of the Mainframe. A reportagem utilizou a expressão "hurtling toward extinction" ("correndo rumo à extinção"), tornando-se um dos exemplos mais conhecidos do entusiasmo da imprensa com o movimento Client/Server e com as previsões de substituição dos grandes sistemas corporativos. Décadas depois, ela permanece como um importante registro histórico sobre os desafios de prever a evolução da tecnologia.

Bellacosa Mainframe e o Funeral que nunca aconteceu

C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

Como um Programador COBOL Padawan Pode Aprender Engenharia de Prompt e Conversar com IA Como um Arquiteto IBM Z

 

Bellacosa Mainframe dicas para criar prompts de ia melhores e mais abrangentes

☕ Um Café no Bellacosa Mainframe

Muito Além do "Escreva um Artigo"

Como um Programador COBOL Padawan Pode Aprender Engenharia de Prompt e Conversar com IA Como um Arquiteto IBM Z

"A diferença entre um programador júnior e um especialista raramente está na linguagem que ele conhece. Está na qualidade das perguntas que ele faz."


Imagine a seguinte situação.

São 8h30 da manhã.

Você acabou de entrar no TSO.

Depois de alguns segundos aparece a velha tela verde.

Você abre o SDSF.

Olha a fila.

Mais de 5.000 jobs.

Centenas de programas COBOL.

DB2.

IMS.

CICS.

MQ.

VSAM.

JCL para todos os lados.

Então alguém chega e pergunta:

— "Você conhece COBOL?"

Você responde:

— "Conheço."

Mas alguns minutos depois a mesma pessoa faz outra pergunta.

— "Como o sistema inteiro funciona?"

É aí que muitos programadores percebem que escrever código é apenas uma pequena parte da profissão.

Com Inteligência Artificial acontece exatamente a mesma coisa.

Quase todo mundo sabe escrever:

Escreva um artigo sobre COBOL.

Pouquíssimos sabem construir um pensamento.

E é justamente isso que diferencia quem apenas usa IA de quem trabalha lado a lado com ela.

Hoje vamos conversar sobre isso.

Pegue seu café.


O maior erro de um Padawan

Quando começamos em COBOL fazemos perguntas assim.

Como faço um READ?

Depois evoluímos.

Como funciona um VSAM KSDS?

Mais tarde.

Quando devo utilizar ESDS ao invés de DB2?

Depois.

Qual arquitetura suporta melhor processamento distribuído mantendo consistência ACID?

Percebeu?

As perguntas ficaram maiores.

Mais inteligentes.

Mais completas.

Com IA acontece exatamente igual.


A IA não lê pensamentos

Este talvez seja o maior Easter Egg deste artigo.

A IA possui bilhões de parâmetros.

Conhece milhões de livros.

Documentações.

Artigos.

Normas.

Código.

Mas existe uma coisa que ela nunca saberá.

O que você realmente queria.

Ela precisa inferir.

Quanto menos contexto você fornece...

Mais ela precisa adivinhar.

E adivinhações nunca são boas em engenharia.


Pense como um Sysprog

Um Sysprog nunca instala um produto IBM digitando apenas

INSTALL

Existe documentação.

Pré-requisitos.

SMP/E.

PTFs.

HOLDDATA.

CSI.

Libraries.

Parâmetros.

Porque sistemas complexos exigem contexto.

A IA também.


Um Prompt é Igual a um JCL

Esse é um paralelo que quase ninguém faz.

Observe.

Um JOB possui:

JOB

EXEC

DD

SYSIN

PARM

COND

REGION

CLASS

MSGCLASS

Cada linha informa uma intenção ao sistema.

Agora veja um prompt moderno.

ROLE

OBJECTIVE

AUDIENCE

CONTEXT

CONSTRAINTS

OUTPUT

STYLE

Não é muito diferente.

Na verdade...

É praticamente um JCL para um cérebro artificial.

Easter Egg #1

Sempre que pensar em Prompt Engineering imagine que você está escrevendo um JOB para executar um programa chamado GPT.

A analogia funciona incrivelmente bem.


Bellacosa Mainframe e a lista de frameworks para ampliar seu prompt

Frameworks são PROCs do pensamento

Quem trabalha com JCL sabe o poder de um PROC.

Você reutiliza padrões.

Evita erros.

Padroniza execução.

Frameworks fazem exatamente isso.

Eles são PROCs para organizar ideias.

Ao invés de reinventar a forma de escrever...

Você reutiliza um modelo que já foi validado durante décadas.


AIDA — O Job de Marketing

Imagine que você criou um curso COBOL.

Você escreve:

Meu curso ensina COBOL.

Fim.

Agora usando AIDA.

Attention

"O PIX brasileiro movimenta bilhões todos os dias utilizando tecnologias que nasceram décadas atrás."

Interest

"Você sabia que provavelmente existe COBOL em alguma etapa dessa transação?"

Desire

"Imagine fazer parte desse mundo."

Action

"Comece estudando COBOL no IBM Z."

Perceba.

As informações são praticamente iguais.

O caminho psicológico mudou completamente.


FAB — O erro clássico do iniciante

Quase todo programador apresenta tecnologia assim.

"COBOL possui COMP-3."

Legal.

E daí?

FAB ensina.

Feature

COMP-3.

Advantage

Ocupa menos espaço.

Benefit

Seu processamento Batch movimenta menos bytes, reduzindo I/O e aumentando desempenho.

O benefício sempre responde:

"Por que eu deveria me importar?"


PEEL — Escrevendo como um Arquiteto

Um arquiteto nunca despeja informações.

Ele organiza.

Cada parágrafo possui.

Point

Evidence

Explanation

Link

Observe qualquer documentação IBM.

Quase todas seguem essa lógica.

Nada está ali por acaso.


KISS — Um dos maiores segredos da IBM

Existe uma frase famosa.

Complexidade gera defeitos.

No Mainframe isso vale ouro.

Os melhores programas COBOL que conheci tinham milhares de linhas.

Mas eram fáceis de ler.

Nomes claros.

Fluxo simples.

Poucos IFs aninhados.

Poucos GO TO.

A IA também gosta disso.

Prompt enorme não significa prompt melhor.

Prompt organizado significa prompt melhor.


SOAPSTONE — Quem está falando?

Este framework é um verdadeiro Easter Egg.

Imagine pedir:

"Explique CICS."

Agora compare.

Você é um IBM Distinguished Engineer.

Explique CICS para um programador COBOL Júnior.

Tom inspirador.

Utilize exemplos bancários.

Use analogias.

Explique em português.

Pronto.

Você praticamente contratou um professor.


STAR — O framework escondido das entrevistas

Muitos usam STAR apenas para RH.

Erro enorme.

STAR é excelente para ensinar tecnologia.

Situação

Batch demorava 8 horas.

Tarefa

Reduzir para quatro.

Ação

RUNSTATS.

REORG.

Novo Access Path.

Resultado

2 horas.

Perceba como contar histórias facilita o aprendizado.


SWOT não serve apenas para empresas

Faça SWOT da sua carreira.

Forças

Conhece COBOL.

Fraquezas

Não conhece APIs.

Oportunidades

Modernização IBM Z.

Ameaças

Parar de estudar.

Você acabou de criar um plano de carreira.


OAR — O framework favorito do Bellacosa

Se eu tivesse que ensinar apenas um...

Seria OAR.

Objective.

Audience.

Research.

Toda vez que conversar com IA diga.

Objetivo.

Quem vai ler.

Quanto aprofundar.

Você ficará impressionado com a diferença.


O Easter Egg que ninguém comenta

Todos esses frameworks parecem diferentes.

Mas escondem um padrão.

Observe.

Todos respondem três perguntas.

O que?

Por quê?

Como?

É só isso.

Alguns acrescentam emoção.

Outros acrescentam evidências.

Outros acrescentam contexto.

Mas todos organizam pensamento.


O framework invisível da IBM

Depois de décadas lendo Redbooks percebi algo interessante.

A IBM raramente escreve utilizando apenas INTRO.

Ou apenas PEEL.

Ou apenas AIDA.

Ela mistura vários.

Introdução.

Contexto.

Problema.

Arquitetura.

Implementação.

Boas práticas.

Resumo.

É um framework híbrido.

E isso inspira um conceito poderoso para prompts.


O Framework Bellacosa Mainframe

Depois de muitos artigos, cursos e apresentações, gosto de organizar um prompt técnico em nove camadas:

1. Papel (Role)
Quem a IA deve representar: um arquiteto IBM Z, um especialista em CICS, um DBA Db2 ou um Sysprog.

2. Público (Audience)
Um Padawan de COBOL? Um desenvolvedor Java? Um gerente? A mesma explicação muda completamente conforme a audiência.

3. Objetivo (Objective)
Ensinar, convencer, revisar código, criar uma aula, produzir um laboratório ou escrever um artigo.

4. Contexto (Context)
Qual ambiente? Banco? Seguradora? IBM Z? z/OS 3.2? CICS TS 6.2? Db2 13? Quanto mais contexto, menos a IA precisa adivinhar.

5. Restrições (Constraints)
O que deve evitar? Qual o tamanho? Deve usar exemplos? Pode usar analogias? Deve citar documentação oficial?

6. Estrutura (Framework)
AIDA, PEEL, STAR, SWOT, INTRO... escolha conscientemente a estrutura que melhor atende ao objetivo.

7. Exemplos (Examples)
Mostre o estilo desejado. Um pequeno exemplo vale mais do que dezenas de instruções abstratas.

8. Formato de Saída (Output)
Artigo, slides, tabela comparativa, FAQ, quiz, roteiro de vídeo, laboratório prático ou infográfico.

9. Revisão (Quality Check)
Peça para a IA verificar coerência, consistência técnica, clareza e possíveis melhorias antes de finalizar.

Essa sequência transforma um pedido simples em uma conversa estruturada, muito parecida com a preparação de uma mudança em produção no ambiente IBM Z.


Easter Eggs para quem quer ir muito além

Se você chegou até aqui, aqui estão alguns "segredos" que costumam fazer diferença.

Easter Egg 1 — Dê identidade à IA

Em vez de pedir:

Explique VSAM.

Experimente:

Você é um IBM Fellow especialista em armazenamento. Explique VSAM para um programador COBOL com seis meses de experiência.

A qualidade costuma aumentar porque você definiu um papel, um público e um nível de profundidade.


Easter Egg 2 — Peça comparações

A IA explica muito melhor quando compara conceitos.

Exemplos:

  • VSAM × Db2

  • COMMAREA × Channels & Containers

  • RACF × ACF2 × Top Secret

  • Batch × Online

  • CICS × IMS TM

Comparações obrigam o raciocínio a destacar diferenças importantes.


Easter Egg 3 — Peça analogias

Analogia é uma ferramenta extraordinária para aprender.

"Explique WLM como se fosse um controlador de tráfego aéreo."

"Explique RACF como se fosse um sistema de portaria de um condomínio."

Você criará conexões mentais muito mais fortes.


Easter Egg 4 — Trabalhe em camadas

Não peça tudo de uma vez.

Prefira uma sequência como:

  1. Explique o conceito.

  2. Mostre a arquitetura.

  3. Apresente um exemplo COBOL.

  4. Explique os erros comuns.

  5. Mostre um caso real.

  6. Crie um laboratório.

  7. Elabore um quiz.

  8. Sugira leituras adicionais.

É exatamente assim que um bom curso é construído.


Easter Egg 5 — Transforme a IA em mentora

Em vez de pedir respostas prontas, peça orientação.

"Faça perguntas que me levem a descobrir a solução."

Esse método desenvolve autonomia e pensamento crítico.


Easter Egg 6 — Use múltiplos frameworks

Um artigo pode começar com INTRO, desenvolver cada seção com PEEL, ilustrar experiências usando STAR, analisar tendências com SWOT e concluir com AIDA. Frameworks não competem entre si; eles se complementam.


Easter Egg 7 — Aprenda observando

Leia Redbooks da IBM, RFCs, artigos técnicos e documentação oficial tentando identificar a estrutura utilizada.

Você começará a enxergar padrões que antes passavam despercebidos.


A maior lição de todas

Existe uma frase muito conhecida na área de desenvolvimento:

Garbage In, Garbage Out.

Ela continua verdadeira na era da Inteligência Artificial.

Uma pergunta superficial tende a produzir uma resposta superficial.

Uma pergunta rica em contexto, objetivos e estrutura abre espaço para uma resposta muito mais útil.

Curiosamente, isso também vale para um programador COBOL. Os profissionais mais respeitados que conheci não eram necessariamente aqueles que memorizavam mais comandos do TSO ou mais instruções COBOL. Eram aqueles que faziam as perguntas certas antes de escrever a primeira linha de código.

No fim das contas, Prompt Engineering não é sobre aprender dezenas de siglas. É sobre desenvolver uma forma organizada de pensar, comunicar objetivos e resolver problemas. Os frameworks apresentados neste artigo — AIDA, PEEL, STAR, SWOT, OAR, FAB, SOAPSTONE, KISS e tantos outros — são ferramentas para isso.

Assim como um Padawan aprende primeiro a dominar os fundamentos da linguagem COBOL antes de enfrentar um sistema bancário de milhões de linhas, quem deseja extrair o máximo da IA precisa dominar os fundamentos da comunicação estruturada. A tecnologia muda, os modelos evoluem e novas siglas surgem todos os meses, mas a capacidade de organizar ideias com clareza continua sendo uma habilidade atemporal.

Da próxima vez que abrir o ChatGPT, não pense apenas em "escrever um prompt". Pense que você está preparando um JCL para executar o maior ambiente de processamento de linguagem natural já criado. Defina o papel, o contexto, o objetivo, a estrutura e o formato da saída. Você descobrirá que conversar com uma IA pode ser tão elegante e previsível quanto construir um bom JOB para o z/OS.

E talvez esse seja o maior aprendizado para um COBOL Padawan: antes de dominar a máquina, aprenda a organizar o próprio pensamento. Afinal, os melhores programas, os melhores projetos e os melhores prompts sempre começam da mesma forma: com uma pergunta bem formulada.