☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sábado, 15 de dezembro de 2018

IBM Mainframe Discovery : Capítulo XII — A Biblioteca Infinita da Galáxia

 

Bellacosa Mainframe apresenta ibm mainframe parte xii

☕ Um Café no Bellacosa Mainframe

Capítulo XII — A Biblioteca Infinita da Galáxia

Db2 for z/OS: Onde Bilhões de Histórias São Guardadas Sem Que Uma Única Página se Perca


NONA REGRA DOS GRANDES ARQUIVISTAS CÓSMICOS

Nunca pergunte:

"Onde está o dado?"

Pergunte:

"Como encontrá-lo antes que o Universo envelheça?"

Porque encontrar uma informação em uma tabela com dez registros é fácil.

Encontrar uma única linha entre:

  • cinquenta bilhões de registros;

  • milhares de tabelas;

  • centenas de aplicações;

  • milhões de usuários;

...é outra história completamente diferente.

Hoje visitaremos um dos lugares mais fascinantes de toda a Federação IBM Z.

A gigantesca Biblioteca Universal.

Seu nome é:

Db2 for z/OS.


A Biblioteca Que Nunca Fecha

Imagine uma biblioteca.

Não uma biblioteca comum.

Uma biblioteca planetária.

Ela possui:

  • todos os livros já escritos;

  • todos os jornais;

  • todos os registros médicos;

  • todos os contratos;

  • todas as contas bancárias;

  • todas as reservas de voos;

  • todas as apólices de seguro.

Agora imagine que milhões de leitores entram ao mesmo tempo.

Todos procuram livros diferentes.

Nenhum pode receber o livro errado.

Nenhum livro pode desaparecer.

Nenhuma página pode ser rasgada.

Esse é exatamente o problema que o Db2 resolve.


Antes dos Bancos de Dados

Voltemos algumas décadas.

Imagine um enorme arquivo de aço.

Milhões de pastas.

Um funcionário recebe um pedido.

Começa a procurar.

Corredor.

Prateleira.

Caixa.

Pasta.

Documento.

Enquanto isso...

cem outras pessoas aguardam.

Não escalava.


Então Surgiu Uma Pergunta

"E se existisse um bibliotecário capaz de encontrar qualquer livro em poucos milissegundos?"

Essa pergunta mudou a história da computação corporativa.


O Grande Bibliotecário

Imagine um senhor muito elegante.

Ele conhece absolutamente todos os livros.

Todas as estantes.

Todos os corredores.

Todos os atalhos.

Você apenas pergunta:

"Preciso deste documento."

Ele responde imediatamente:

"Corredor 217.

Estante 14.

Prateleira 3.

Livro 928."

Esse bibliotecário chama-se:

Otimizador SQL.


SQL Não É Mágica

Existe um mito curioso.

As pessoas acreditam que SQL conversa diretamente com o disco.

Na realidade...

SQL faz um pedido.

O Db2 decide como atendê-lo.

É uma diferença enorme.

Você diz:

SELECT *
FROM CLIENTES
WHERE CPF='12345678900'

Você nunca diz:

"Leia exatamente esta trilha do disco."

Quem escolhe isso é o Db2.


A Cidade das Tabelas

Imagine uma gigantesca cidade.

Cada prédio representa uma:

Tabela.

Dentro dela vivem milhões de moradores.

Cada apartamento representa um:

Registro.

Cada morador possui:

nome.

CPF.

telefone.

saldo.

endereço.

Tudo cuidadosamente organizado.


As Ruas da Cidade

Agora imagine tentar encontrar:

João da Silva.

Sem ruas.

Sem números.

Sem mapas.

Levaria dias.

Então alguém inventou:

Índices.


Os Índices — O Índice Remissivo da Galáxia

Pegue qualquer enciclopédia.

Ela possui um índice.

Você procura:

Saturno.

Vai diretamente à página.

Sem precisar ler mil páginas.

Os índices do Db2 fazem exatamente isso.

Segundo Wilhelm G. Spruth, os mecanismos de indexação são fundamentais para que o Db2 consiga localizar informações rapidamente sem percorrer tabelas inteiras sempre que isso não é necessário.


Nem Todo Livro Precisa Ser Aberto

Imagine um bibliotecário.

Alguém pergunta:

— Existe um livro chamado "COBOL"?

Ele consulta apenas o catálogo.

Nem precisa andar até a estante.

O Db2 faz isso milhares de vezes por segundo.


Pages — As Páginas do Livro

Agora chegamos a um conceito importante.

O Db2 não lê registros individualmente.

Ele trabalha com:

Pages.

Imagine um livro.

Você nunca pega apenas uma palavra.

Abre uma página inteira.

Depois outra.

Depois outra.

O banco faz exatamente isso.


Buffer Pool — A Mesa do Pesquisador

Imagine um pesquisador consultando livros.

Ele não devolve imediatamente cada volume.

Primeiro coloca tudo sobre sua mesa.

Assim evita caminhar até a biblioteca repetidamente.

Essa mesa chama-se:

Buffer Pool.

Quando uma página é utilizada frequentemente...

permanece ali.

Resultado?

Muito menos acesso ao disco.

Muito mais velocidade.


O Grande Armazém

Imagine um depósito gigantesco.

Ali ficam guardados milhões de livros.

Esse depósito representa os discos.

O Buffer Pool evita viagens desnecessárias.

Quanto melhor organizado...

mais rápido o pesquisador trabalha.


O Catálogo da Biblioteca

Agora imagine que existe um livro especial.

Ele contém informações sobre:

todos os livros.

todas as estantes.

todos os autores.

Esse livro chama-se:

Catálogo do Db2.

Ele descreve toda a estrutura do banco.

Sem ele...

o bibliotecário ficaria completamente perdido.


O Otimizador — O Mestre dos Caminhos

Agora imagine três rotas até o mesmo destino.

Uma possui trânsito.

Outra está interditada.

Outra está completamente livre.

Quem escolhe?

O GPS.

No Db2 esse GPS chama-se:

Optimizer.

Ele analisa dezenas de possibilidades antes de executar uma consulta.

Seu objetivo é encontrar o caminho mais eficiente.


RUNSTATS — O Recenseamento Galáctico

Mas como o GPS sabe qual estrada está congestionada?

Porque alguém faz estatísticas.

No Db2 esse trabalho chama-se:

RUNSTATS.

Imagine pesquisadores visitando cada bairro.

Eles contam:

moradores.

prédios.

ruas.

movimento.

Essas informações alimentam o Otimizador.

Sem estatísticas...

até o melhor GPS toma decisões ruins.


EXPLAIN — O Mapa da Expedição

Imagine pedir ao bibliotecário:

"Mostre exatamente como pretende encontrar meu livro."

Ele desenha um mapa.

Esse mapa chama-se:

EXPLAIN PLAN.

Todo Programador COBOL Padawan deveria aprender a lê-lo.

Porque ali está escondida boa parte da performance do sistema.


Locks — O Livro Não Pode Ser Rasgado

Agora imagine dois pesquisadores.

Ambos querem editar exatamente a mesma página.

Ao mesmo tempo.

O resultado seria um desastre.

Então surge outro personagem.

O:

Lock Manager.

Ele organiza quem pode modificar determinado dado.

Enquanto um escreve...

os demais aguardam.


Commit — O Carimbo Oficial

Imagine um cartório.

Você assina um documento.

Mas ele só passa a existir oficialmente depois do carimbo.

No Db2 esse carimbo chama-se:

COMMIT.

Até esse momento...

a transação ainda pode voltar atrás.


Rollback — A Máquina do Tempo

Agora imagine que alguém percebe um erro.

Antes do carimbo.

Tudo pode ser desfeito.

Esse mecanismo chama-se:

ROLLBACK.

É como voltar alguns minutos no tempo.


O Diário da Biblioteca

Imagine um bibliotecário anotando absolutamente tudo.

Quem entrou.

Quem saiu.

Quem retirou livros.

Quem devolveu.

Esse diário chama-se:

Log.

Ele registra todas as alterações.

Graças a ele...

o Db2 consegue recuperar informações após falhas.


Recovery — Reconstruindo a Biblioteca

Imagine um meteoro atingindo parte da biblioteca.

Os livros desapareceram.

Fim da história?

Não.

Graças aos Logs e aos Backups, o Db2 pode reconstruir o estado correto dos dados, preservando a integridade das transações.

É um dos pilares da confiabilidade da plataforma.


Data Sharing — Vários Bibliotecários, Uma Biblioteca

Lembra do Parallel Sysplex?

Agora imagine cinco bibliotecários.

Todos consultam exatamente os mesmos livros.

Sem discutir.

Sem criar cópias diferentes.

Esse recurso chama-se:

Db2 Data Sharing.

Ele permite que múltiplas instâncias do Db2 compartilhem os mesmos dados em um ambiente Parallel Sysplex, aumentando escalabilidade e disponibilidade.


O Db2 Nunca Trabalha Sozinho

Curiosamente...

o Db2 raramente aparece sozinho.

Ele conversa continuamente com:

CICS.

IMS.

MQ.

COBOL.

Java.

Python.

REST APIs.

z/OS Connect.

Linux.

OpenShift.

É como a grande biblioteca central da Federação.

Todos passam por ela.


O Que Mudou Desde 2010?

Desde que Spruth publicou seu relatório...

o Db2 evoluiu extraordinariamente.

Hoje encontramos:

  • SQL muito mais inteligente;

  • Compressão avançada;

  • Criptografia transparente;

  • Aceleração analítica;

  • Machine Learning para otimização;

  • Integração com Apache Spark;

  • Hybrid Transaction & Analytics;

  • Pesquisa Vetorial;

  • Busca Híbrida com OpenSearch;

  • IA Generativa utilizando dados corporativos.

O curioso?

A filosofia continua idêntica.

Guardar conhecimento.

Encontrá-lo rapidamente.

Nunca perdê-lo.


Uma Lição Para Além da Tecnologia

Existe uma reflexão escondida neste capítulo.

Conhecimento não vale apenas porque existe.

Vale porque conseguimos encontrá-lo quando precisamos.

O mesmo acontece conosco.

Livros esquecidos em uma estante ajudam pouco.

Conhecimento organizado transforma civilizações.

Talvez seja por isso que bancos de dados e bibliotecas tenham algo em comum.

Ambos preservam a memória coletiva.


Curiosidades do Diário de Bordo

📚 O Db2 for z/OS processa diariamente bilhões de transações em algumas das maiores instituições financeiras do planeta.

🚀 O Otimizador SQL pode analisar inúmeras estratégias diferentes antes de escolher o plano de execução mais eficiente.

🛰️ Buffer Pools reduzem drasticamente o acesso ao disco, mantendo páginas frequentemente utilizadas em memória.

🌌 O Data Sharing permite que múltiplos sistemas IBM Z compartilhem a mesma base de dados mantendo consistência e alta disponibilidade.


Diário de Bordo do Padawan COBOL

Antes de deixar a Biblioteca Infinita da Federação, registre estas coordenadas no seu Holocron Técnico:

✅ O Db2 é muito mais do que um banco de dados; ele é o guardião da memória corporativa.

✅ Índices, Buffer Pools e o Otimizador trabalham juntos para transformar bilhões de registros em respostas obtidas em milissegundos.

✅ COMMIT, ROLLBACK e Logs garantem que a integridade dos dados seja preservada mesmo diante de falhas.

✅ O verdadeiro poder do Db2 não está apenas em armazenar informações, mas em permitir que toda a galáxia corporativa encontre exatamente o dado certo, no instante certo, com absoluta confiança.


Missão Seguinte

No próximo capítulo deixaremos a Biblioteca Galáctica para explorar uma vasta Rede de Comunicações Interestelares: IBM MQ e os sistemas de mensageria.

Descobriremos por que mensagens viajam com muito mais segurança do que chamadas diretas, como filas evitam o caos entre civilizações digitais e por que o IBM MQ se tornou o serviço postal da galáxia corporativa, entregando bilhões de mensagens por dia sem perder uma única encomenda.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

Capítulo V — A Frota Invisível do Transporte Interestelar

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

Abrir artigo

sexta-feira, 14 de dezembro de 2018

🔥 CICS TS 5.5 — O CICS que Chegou para Misturar Linguagens, Node.js e APIs Modernas

 

Bellacosa Mainframe anuncia o CICS 5.5

🔥 CICS TS 5.5 — O CICS que Chegou para Misturar Linguagens, Node.js e APIs Modernas



☕ Midnight Lunch em dezembro de 2018 — a versão que virou referência

Se o CICS TS 5.4 trouxe suporte sólido a Java EE e APIs assíncronas, o CICS TS 5.5 fez algo maior: converteu o CICS em uma plataforma verdadeiramente mixed-language, oficialmente abrindo as portas não só para Java, mas também para Node.js, GraphQL, segurança forte, melhores ferramentas de gestão e integração com o mundo moderno.

📌 Em 2018, o CICS deixou de ser “servidor transacional legado” e virou hub de aplicações corporativas modernas.


📅 Datas de marca

📌 Data de Lançamento (GA): dezembro de 2018
📌 Fim de Vida (EOS): CICS TS 5.5 já passou por ciclos de suporte padrão e hoje muitos sites operam em versões posteriores (5.6, 6.x).

💬 Bellacosa comenta:

“5.5 é o release que diz ‘vem com tudo’ para linguagens que não sejam só COBOL e Java — e ele não disse isso timidamente.”


CICS 5.5

🆕 O que há de novo nas entranhas do CICS 5.5

🟡 Suporte oficial a Node.js

Agora o CICS pode hospedar aplicações Node.js diretamente — sem encanação, sem plugin extra — abrindo caminho para arquiteturas full stack modernas rodando no mainframe.
💬 Bellacosa:

“Antes era Java, depois era JSON… agora é asynchronous JavaScript you can call from TN3270 to Web.”


🟡 Enhancements no CICS Explorer

O CICS Explorer ficou ainda mais capaz e produtivo, com visualizações ampliadas, melhores gráficos de dependências e interfaces que facilitam desde a configuração até a análise de métricas.
📌 Uma IDE CICS amigável que reduz aquele medo clássico do terminal 3270.


🟡 GraphQL API integrado

Uma API moderna que permite consultar relações de recursos CICS — ícones, vínculos de workload, Estados de containers, topologia — com consultas expressivas e instantâneas.
🐣 Easteregg: GraphQL no mainframe? Parece coisa da nuvem… mas é real e é útil aqui!


🟡 Segurança reforçada

✔ Default mínimo TLS elevado para 1.2
✔ Keyrings compartilháveis entre regiões
✔ Novos parâmetros de senha e phrases
✔ Suporte SNI em conexões HTTP
💬 Bellacosa:

“Segurança hoje não é detalhe — é exigência regulatória e 5.5 entendeu isso.”


🟡 Desempenho e Performance

✔ Acesso threadsafe às tabelas de coupling facility
✔ Buffers 64-bit para clientes web
✔ CICS-MQ bridge e trigger monitor melhorados
📌 Performance não é só mais rápido — é mais estável, resiliente e observável.


🟡 Linguagens & Runtime Modernos

✔ Node.js
✔ Java EE 8 / Jakarta EE
✔ Spring Boot chamável via LINK
✔ Mapas e containers exploráveis por EXCI
💬 Bellacosa comenta:

“Aqui o mainframe diz: ‘Scripts também têm lugar na festa’.”


🧠 Melhoria contínua e APARs

O CICS TS 5.5 também coleta APARs de entrega contínua, incluindo melhorias em:

  • JWT e OpenID Connect (OIDC) no Liberty JVM server

  • XML e JSON mapping levels avançados

  • Enhanced policy rule types

  • Db2 thread management

  • GraphQL, enhanced inter-resource relationships

Esses ajustes mostram uma filosofia de evolução sem precisar esperar uma nova major release.


🧠 Curiosidades e Eastereggs Bellacosa

🍺 Compuware e suporte Day One — ferramentas como CAFC deram suporte já no dia do lançamento, o que é sinal claro de parceria e maturidade do ecossistema.
🍺 Node.js e CICS — você pode ter aplicações JS servindo dados corporativos direto do mainframe.
🍺 GraphQL — no universo tradicional, consultas eram pesadas e verbosas; aqui são expressivas e rápidas.


🧪 Exemplo prático — “O Portal que Nasceu no Mainframe”

Uma empresa de seguros tinha:

  • Back-end em COBOL + DB2

  • APIs REST servindo clientes móveis

  • Uma camada Web pesada em Linux

Trasnformação com CICS TS 5.5:

  1. Subiram serviços Node.js rodando em CICS

  2. Configuraram GraphQL para consultar recursos e estados

  3. Integraram APIs modernas com JSON direto dos programas tradicionais

  4. Liberaram dashboards internos sem precisar de middlewares extras

💬 Bellacosa resume:

“De servidor transacional para hub de APIs e serviços mistos — tudo em uma só plataforma.”


🧠 Dicas Bellacosa para Explorar o 5.5

✔ Aproveite Node.js para novas aplicações sem descartar legado.
✔ Amarre GraphQL para inspeções profundas de recursos.
✔ Reforçe TLS, criptografia e keyrings compartilháveis para segurança corporativa.
✔ Use CICS Explorer e atualize para as versões mais novas para visualizar métricas completas.


🎯 Conclusão Bellacosa

CICS TS 5.5 não foi apenas um release.
Foi o ponto onde o mainframe se rebelou contra a estagnação e gritou: “Eu sou moderno, escalável, seguro e ágil!”

✔ Node.js prático
✔ GraphQL explorável
✔ JVM / Java EE atualizado
✔ Segurança reforçada
✔ APIs modernas

🔥 5.5 é o CICS que prova — transacional e moderno podem andar de mãos dadas.

quinta-feira, 13 de dezembro de 2018

O Caso do Registro que Não Podia Ser Tocando : Quando um Jovem Programador COBOL Descobriu que Dois Usuários Podiam Roubar Dinheiro Sem Serem Ladrões

 

Bellacosa Mainframe e o caso do registro que nao podia ser tocando

☕ Um Café no Bellacosa Mainframe

O Caso do Registro que Não Podia Ser Tocando

Quando um Jovem Programador COBOL Descobriu que Dois Usuários Podiam Roubar Dinheiro Sem Serem Ladrões

"Existem crimes que deixam impressões digitais. Outros deixam apenas inconsistências no VSAM."


A chuva caía sobre o Centro de Processamento de Dados.

As luzes verdes do IBM Z piscavam lentamente, como se respirassem na escuridão.

Era quase meia-noite.

No monitor 3270, uma única mensagem chamava a atenção do jovem programador COBOL.

RESP = 14

Nenhum ABEND.

Nenhum dump.

Nenhum S0C7.

Nenhum S0C4.

Apenas um simples código de retorno.

Mas, como todo bom investigador sabe, às vezes o menor detalhe esconde o maior dos mistérios.

Foi então que o velho administrador de CICS aproximou-se segurando uma caneca de café.

Sem olhar para o monitor, apenas perguntou:

— Você tentou fazer REWRITE sem entender quem estava segurando a chave do cofre?

O rapaz respondeu:

— Eu só queria alterar um telefone...

O veterano sorriu.

— É exatamente assim que começam todos os grandes mistérios do CICS.

Hoje vamos investigar um dos mecanismos mais importantes de toda a arquitetura CICS: READ UPDATE e REWRITE, dois comandos aparentemente simples, mas responsáveis por proteger bilhões de registros VSAM diariamente em bancos, seguradoras, bolsas de valores, companhias aéreas e órgãos governamentais.

Prepare seu café.

Acenda a luminária verde da mesa.

Porque esta investigação vai muito além de um simples comando COBOL.


O verdadeiro problema nunca foi gravar um registro

Todo programador iniciante pensa assim:

"Quero alterar um cliente."

Então imagina algo parecido com:

Ler

↓

Modificar

↓

Gravar

Parece simples.

E realmente seria...

...se apenas uma pessoa utilizasse o sistema.

Mas o CICS nasceu para outro mundo.

Um mundo onde milhares de pessoas utilizam o mesmo arquivo ao mesmo tempo.

Imagine um banco.

Enquanto você lê este artigo...

Milhares de clientes estão:

  • pagando boletos;

  • transferindo PIX;

  • alterando endereço;

  • consultando saldo;

  • contratando empréstimos;

  • desbloqueando cartão.

Tudo isso pode atingir exatamente o mesmo registro VSAM.

Agora surge a pergunta que assombra arquitetos desde os anos 1970:

Quem ganha quando duas pessoas querem alterar o mesmo registro ao mesmo tempo?


O nascimento do maior vilão dos sistemas online

Seu nome é:

Lost Update

Ele não gera ABEND.

Não trava o CICS.

Não derruba o sistema.

Pior.

Ele produz dados errados.

Imagine o seguinte registro.

Cliente

Saldo

R$ 1.000,00

Agora entram dois caixas.

Caixa A deposita:

+R$ 100,00

Caixa B faz um saque.

-R$ 200,00

Os dois executam:

READ

Ambos recebem:

R$ 1.000,00

Caixa A calcula:

1.100

Grava.

Logo depois...

Caixa B calcula:

800

Também grava.

Resultado final:

R$ 800,00

Mas espere.

O correto seria:

R$ 900,00

Onde desapareceram os R$ 100,00?

Ninguém roubou.

Ninguém fraudou.

Nenhum operador errou.

Foi apenas um clássico caso de Lost Update, um problema de concorrência em que uma atualização sobrescreve a outra por ambas terem partido de uma mesma versão antiga do registro.

É exatamente para impedir esse tipo de situação que o CICS criou um dos mecanismos mais elegantes da computação transacional.


A filosofia do READ UPDATE

Muitos iniciantes acreditam que UPDATE significa:

"Atualize o registro."

Na verdade...

Não.

O UPDATE não grava absolutamente nada.

Ele apenas comunica ao CICS:

"Vou precisar modificar este registro. Reserve-o para mim."

É quase como chegar à biblioteca e colocar um marcador sobre um livro dizendo:

"Estou usando."

Enquanto esse marcador existir...

Ninguém mais pode pegar aquele livro.

No CICS acontece exatamente isso.

EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-CHAVE)
     INTO(WS-REGISTRO)
     UPDATE
END-EXEC

Observe.

Não houve alteração alguma.

O registro continua exatamente igual.

A única diferença é invisível.

Agora existe um cadeado.

Registro Cliente

──────────────

Saldo

Telefone

Endereço

──────────────

🔒

Esse pequeno cadeado é um dos maiores responsáveis pela confiabilidade dos sistemas bancários modernos.


O cadeado invisível

Esse bloqueio é chamado de lock exclusivo.

Enquanto ele existir:

✔ outro programa pode consultar outros registros;

✔ outras transações continuam funcionando normalmente;

✔ outros clientes continuam utilizando o banco.

Mas aquele registro...

Aquele especificamente...

Pertence temporariamente à sua transação.

É como um investigador isolando a cena do crime.

Até que a perícia termine...

Ninguém entra.


O segundo investigador chega

Imagine agora.

Programa A faz:

READ UPDATE

Registro bloqueado.

Cinco milissegundos depois...

Programa B também tenta atualizar o mesmo cliente.

READ UPDATE

O que acontece?

O CICS responde algo semelhante a:

RESP = 14

Registro bloqueado.

Dependendo da configuração da aplicação, a segunda transação poderá:

  • aguardar a liberação do lock;

  • receber imediatamente a indicação de bloqueio;

  • ou seguir outra estratégia definida pelo sistema.

Perceba a genialidade.

O CICS prefere atrasar uma operação por alguns milissegundos a permitir corrupção dos dados.


REWRITE: a hora da verdade

Depois de alterar a Working-Storage...

Chega o momento mais importante.

EXEC CICS REWRITE
     FILE('CLIENTE')
     FROM(WS-REG)
END-EXEC

Agora sim.

O VSAM grava novamente o registro.

Muitos iniciantes perguntam:

"Ele grava somente o telefone?"

Não.

O REWRITE grava o registro inteiro.

Mesmo que apenas um campo tenha mudado.

Imagine um cadastro.

Nome

CPF

Telefone

Cidade

Saldo

Limite

Nascimento

Endereço

Estado Civil

Você modifica somente:

Telefone

Mesmo assim...

Todo o registro volta ao disco.

Isso acontece porque o VSAM trabalha com registros completos, e o REWRITE substitui a imagem inteira do registro originalmente lido.


O segredo da chave imutável

Existe uma regra quase sagrada.

O REWRITE mantém a mesma chave do registro.

Você pode alterar:

  • telefone;

  • saldo;

  • limite;

  • endereço;

  • e-mail;

  • profissão.

Mas não pode alterar a chave primária.

Se precisar mudar a chave...

O caminho normalmente envolve excluir o registro antigo e gravar outro com a nova chave.

É uma mudança de identidade.

E identidades novas exigem um novo registro.


A importância do COMMIT

Um detalhe frequentemente esquecido pelos iniciantes é imaginar que o REWRITE já libera o registro.

Nem sempre.

Enquanto a unidade lógica de trabalho não termina, o lock pode continuar ativo.

É por isso que o fluxo clássico é:

READ UPDATE

↓

Modificar memória

↓

REWRITE

↓

SYNCPOINT (COMMIT)

↓

Lock liberado

O COMMIT confirma a alteração e encerra aquela etapa da transação.

Se ocorrer um erro antes disso, o sistema pode desfazer a operação, preservando a consistência dos dados.


O perigo dos formulários longos

Imagine esta situação.

Você faz:

READ UPDATE

Depois envia uma tela.

O usuário vai atender o telefone.

Conversar.

Tomar café.

Voltar vinte minutos depois.

Só então pressiona ENTER.

Durante todo esse tempo...

O registro permaneceu bloqueado.

Resultado?

Filas.

Esperas.

Outros usuários impedidos de alterar aquele mesmo cliente.

Por isso existe uma regra de ouro no desenvolvimento CICS:

Nunca mantenha um lock por mais tempo do que o estritamente necessário.

Uma estratégia comum é:

  1. Fazer um READ simples para exibir os dados.

  2. Receber as alterações do usuário.

  3. Executar um READ UPDATE pouco antes da gravação.

  4. Validar novamente.

  5. Fazer o REWRITE.

  6. Finalizar a unidade de trabalho.

Assim, o bloqueio dura apenas alguns milissegundos.


RESP e RESP2: os investigadores silenciosos

Nunca ignore os códigos de retorno.

Um programa robusto verifica cuidadosamente o resultado de cada comando CICS.

Alguns exemplos comuns:

RESPSignificado
00Operação realizada com sucesso
02Registro não encontrado
14Registro bloqueado
20Arquivo ou recurso não encontrado
30Requisição inválida
91Atualização não concluída; investigar a causa

Quando disponível, RESP2 complementa o diagnóstico, fornecendo informações adicionais específicas sobre a condição encontrada.

Um bom programador COBOL não apenas trata o erro; ele entende por que ele ocorreu.


Curiosidade: por que não existe UPDATE como no SQL?

Quem vem do mundo relacional estranha.

No SQL basta escrever:

UPDATE CLIENTE
SET TELEFONE = '11999999999'
WHERE ID = 100;

No VSAM, a lógica é diferente.

Primeiro você obtém o registro.

Depois altera sua cópia em memória.

Só então grava o registro inteiro novamente.

Essa diferença vem da própria natureza do VSAM, que trabalha com registros físicos completos, enquanto o banco de dados relacional manipula colunas e linhas sob um mecanismo diferente de armazenamento.


Curiosidade histórica

Os conceitos por trás de READ UPDATE e REWRITE surgiram muito antes da popularização da internet.

Décadas antes de existirem smartphones, APIs REST ou microsserviços, grandes bancos já processavam milhões de transações simultâneas graças a mecanismos sofisticados de bloqueio, sincronização e recuperação.

Grande parte dessas ideias continua válida até hoje.

Muitas tecnologias modernas reinventaram princípios que os mainframes já utilizavam há décadas.


Passo a passo para atualizar um registro com segurança

Um fluxo típico em uma aplicação COBOL/CICS pode ser resumido assim:

  1. Receber a chave do registro.

  2. Executar READ UPDATE.

  3. Verificar RESP e, quando aplicável, RESP2.

  4. Alterar apenas os campos necessários na Working-Storage.

  5. Executar REWRITE.

  6. Confirmar a unidade lógica de trabalho (SYNCPOINT) ou realizar rollback em caso de falha.

  7. Encerrar a transação.

Parece simples.

E realmente é.

A dificuldade não está na sequência.

Está em compreender por que ela existe.


Dicas de ouro para quem está aprendendo CICS

✔ Nunca execute REWRITE sem um READ UPDATE bem-sucedido.

✔ Mantenha o tempo de bloqueio o menor possível.

✔ Sempre trate RESP e RESP2.

✔ Não altere a chave do registro antes do REWRITE.

✔ Pense em concorrência desde o primeiro programa que escrever.

✔ Lembre-se de que o usuário nunca está sozinho no sistema.

✔ Teste cenários com duas transações tentando atualizar o mesmo registro.

Esses testes ensinam mais sobre CICS do que centenas de exemplos puramente teóricos.


Easter Egg Bellacosa Mainframe 🕵️

Os veteranos do CPD contam uma velha história.

Durante uma madrugada de processamento, um programador jurava que o VSAM "perdia dinheiro".

Após horas analisando dumps, SMF e logs do CICS, nada parecia explicar o problema.

Foi então que um analista aposentado, conhecido apenas como O Guardião do 3270, pediu para ver apenas uma linha do código.

Ali estava:

EXEC CICS READ

Sem a palavra:

UPDATE

O veterano fechou o terminal, tomou um gole de café e disse:

— "O culpado nunca foi o VSAM. O registro estava falando com duas pessoas ao mesmo tempo."

Dizem que, desde então, quem programa CICS nas madrugadas presta mais atenção aos quatro caracteres que mudam completamente o destino de uma transação:

UPDATE


O verdadeiro mistério nunca esteve no REWRITE

Ao final desta investigação, descobrimos que o REWRITE não é o protagonista.

Ele apenas grava o resultado.

O verdadeiro herói é o READ UPDATE, que protege o registro enquanto a alteração está sendo preparada.

É ele quem impede que duas transações sobrescrevam o trabalho uma da outra.

É ele quem preserva a integridade dos dados.

É ele quem garante que milhões de operações bancárias possam acontecer simultaneamente com segurança.

Na superfície, parecem apenas dois comandos COBOL.

Nas sombras do CPD, porém, eles são os guardiões silenciosos da consistência, da concorrência e da confiança que sustentam alguns dos sistemas mais críticos do planeta.

E, como em toda boa revista noir dos anos 1950, o maior mistério nunca foi quem escreveu o código.

Foi descobrir quem estava segurando a chave do cofre quando ninguém mais podia tocá-lo.


terça-feira, 11 de dezembro de 2018

⚗️ TAKUMI IRUMA E A ALQUIMIA DO SOFTWARE — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE CÓDIGO ERA APENAS UM DOS INGREDIENTES

 

Bellacosa Mainframe e a engenharia de software

☕ Um Café no Bellacosa Mainframe

⚗️ TAKUMI IRUMA E A ALQUIMIA DO SOFTWARE — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE CÓDIGO ERA APENAS UM DOS INGREDIENTES

Engenharia de Software, processos, representações, requisitos, COBOL, qualidade, testes, DevOps, conhecimento, legado, IA — e o dia em que Takumi descobriu que transformar requisitos em código era praticamente alquimia.



🎬 PRÓLOGO — O PROGRAMADOR QUE ACHAVA QUE SOFTWARE ERA CÓDIGO

Takumi Iruma estava diante de sua bancada.

Sobre ela havia alguns materiais aparentemente sem relação:

ferro
madeira
cristais
ervas
água
minério
pedras mágicas

Para uma pessoa comum aquilo era apenas uma pilha de coisas.

Para um alquimista, porém, eram representações intermediárias de alguma coisa que ainda não existia.

Uma espada.

Uma ferramenta.

Uma poção.

Uma carroça.

Uma casa.

Talvez até aquele lendário vaso sanitário mágico que prova definitivamente que, mesmo em outro mundo, infraestrutura sanitária continua sendo requisito não funcional importantíssimo.

Em algum datacenter distante, nosso jovem programador COBOL observava outra bancada.

Sobre ela estavam:

requisitos
diagramas
copybooks
programas COBOL
JCL
DDL
casos de teste
documentação
logs
procedimentos

Ele olhou aquilo e perguntou:

— Mestre Takumi, onde está o software?

Takumi apontou para tudo.

— Aí.

— Não, mestre. Quero dizer o programa.

Takumi sorriu.

— Esse é seu primeiro erro.

E assim começou nossa dungeon.



🏭 CAPÍTULO 1 — SOFTWARE É UM PRODUTO

Uma das grandes mudanças introduzidas pela Engenharia de Software foi tratar software como produto.

Parece óbvio hoje.

Mas essa mudança conceitual possui consequências profundas.

Nos primeiros tempos da computação era muito fácil associar:

SOFTWARE = PROGRAMA

O programador recebia uma necessidade, escrevia código, compilava e executava.

Se o compilador dissesse:

MAXCC=0000

havia uma grande tentação de declarar:

Funcionou!

Só que compilação bem-sucedida significa basicamente que o programa conseguiu atravessar determinadas verificações necessárias àquela etapa.

Não significa que o sistema resolve corretamente o problema.

Observe:

COMPUTE WS-JUROS =
        WS-SALDO * WS-TAXA.

Sintaticamente, isso pode estar perfeito.

Agora pergunte:

  • Qual é a taxa?

  • Ela é mensal ou anual?

  • É percentual ou decimal?

  • Quem determina seu valor?

  • Existe arredondamento?

  • Qual legislação rege o cálculo?

  • O cálculo deve ser auditável?

  • Devemos registrar a taxa utilizada?

  • Existe uma data de vigência?

  • O que acontece quando a taxa é zero?

  • Taxas negativas são possíveis?

  • Quem pode alterar essa informação?

Nosso pequeno COMPUTE acabou de abrir uma dungeon inteira.

Takumi coloca uma barra de ferro sobre a mesa.

— Isto é uma espada?

— Não.

— E seu programa COBOL isolado também não é necessariamente o produto completo.



📦 CAPÍTULO 2 — O PRODUTO SOFTWARE É MAIOR QUE O SOURCE

Imagine um sistema bancário em mainframe.

O iniciante encontra:

PGMCRD01.CBL

e pensa:

Achei o sistema.

Não necessariamente.

O verdadeiro produto talvez envolva:

COBOL
copybooks
JCL
PROCs
BMS Maps
Db2
DDL
VSAM
CICS definitions
parâmetros
interfaces
mensageria
documentação
casos de teste
dados de teste
procedimentos operacionais
runbooks
monitoramento
logs
controles de segurança

Portanto:

SOFTWARE ≠ APENAS SOURCE CODE

Uma representação melhor seria:

PRODUTO DE SOFTWARE
        =
CÓDIGO
+
DADOS
+
CONFIGURAÇÃO
+
DOCUMENTAÇÃO
+
TESTES
+
CONHECIMENTO OPERACIONAL
+
PROCEDIMENTOS
+
EVIDÊNCIAS

Isso explica algo curioso encontrado frequentemente em sistemas legados.

Uma empresa pode possuir:

100% do source code

e talvez apenas:

60% do conhecimento necessário

para compreender plenamente o sistema.

Os outros 40% estavam na cabeça de Antônio, que se aposentou em 2007.

Ou de Maria, que sabia por que determinado job precisava executar antes das 03:17.

Ou de Joaquim, que lembrava por que aquele campo aparentemente inútil do copybook jamais poderia ser removido.

O código permaneceu.

Parte do conhecimento desapareceu.



🧠 CAPÍTULO 3 — TAKUMI DESCOBRE QUE SOFTWARE É CONHECIMENTO

Aqui encontramos uma das ideias mais interessantes discutidas nesta nossa aventura.

Uma forma poderosa de compreender Engenharia de Software é enxergar desenvolvimento como um processo de criação e manipulação de representações.

Imagine um banco dizendo:

Queremos permitir que clientes solicitem aumento do limite do cartão.

Isso já representa conhecimento.

Mas ainda é extremamente abstrato.

Podemos transformá-lo:

NECESSIDADE
     ↓
REQUISITO
     ↓
MODELO
     ↓
ARQUITETURA
     ↓
DESIGN
     ↓
PROGRAMA
     ↓
EXECUTÁVEL
     ↓
TESTES
     ↓
PRODUÇÃO

Observe o detalhe.

Não estamos necessariamente criando coisas completamente independentes.

Estamos descrevendo progressivamente o mesmo sistema através de diferentes representações.

Takumi pega minério.

Transforma em metal.

Transforma o metal em lâmina.

Transforma a lâmina em espada.

O programador faz algo semelhante:

IDEIA
 ↓
REQUISITO
 ↓
MODELO
 ↓
ALGORITMO
 ↓
COBOL
 ↓
LOAD MODULE

É a alquimia da Engenharia de Software.



⚗️ CAPÍTULO 4 — O PROGRAMADOR É UM ALQUIMISTA DE REPRESENTAÇÕES

Imagine a seguinte regra:

Clientes inadimplentes há mais de 90 dias não podem solicitar aumento do limite.

O programador transforma isso em:

IF WS-DIAS-ATRASO > 90
    MOVE 'N' TO WS-PERMITE-AUMENTO
END-IF.

Acabamos de realizar uma transformação:

CONHECIMENTO DO NEGÓCIO
          ↓
REPRESENTAÇÃO COMPUTACIONAL

Parece simples.

Mas existe uma armadilha.

O requisito dizia:

mais de 90 dias

Portanto:

> 90

Mas alguém poderia programar:

IF WS-DIAS-ATRASO >= 90

Agora clientes exatamente no nonagésimo dia foram incluídos.

Um caractere mudou uma regra empresarial.

Esse pequeno exemplo mostra por que transformar representações é perigoso.

Toda transformação pode introduzir:

erro
omissão
ambiguidade
interpretação
inconsistência

É exatamente por isso que Engenharia de Software precisa de mecanismos de avaliação.


🏰 CAPÍTULO 5 — AS DUAS GRANDES PEÇAS DA DUNGEON

Podemos simplificar o processo de desenvolvimento em duas grandes categorias:

PROCESSO DE DESENVOLVIMENTO
          |
     +----+----+
     |         |
ATIVIDADES  REPRESENTAÇÕES

As representações armazenam conhecimento sobre o sistema.

As atividades criam, modificam, examinam ou controlam essas representações.

Essa ideia é particularmente elegante porque não depende de religião metodológica.

Você pode trabalhar com:

Waterfall
Scrum
Kanban
XP
DevOps
SAFe
CI/CD

Pode programar em:

COBOL
PL/I
Assembler
Java
Python
JavaScript

O princípio continua existindo.

Estamos criando, transformando, avaliando e controlando representações.


🧭 CAPÍTULO 6 — PRIMEIRA ATIVIDADE: LEVANTAMENTO DE INFORMAÇÕES

Antes de fabricar alguma coisa, Takumi precisa entender o problema.

O mesmo vale para software.

Levantamento de informações significa adquirir conhecimento externo necessário ao desenvolvimento.

Pode significar conversar com:

usuários
analistas
especialistas
DBAs
auditores
operações
segurança
arquitetos
gestores
clientes

Mas no mainframe existe uma variante maravilhosa.

Às vezes ninguém sabe a resposta.

Então começa a arqueologia.

Você examina:

programas COBOL
copybooks
JCL
PROCs
tabelas Db2
arquivos VSAM
CICS
mensagens
logs
SMF
documentação antiga
tickets
incidentes

E encontra:

IF WS-COD-PAIS = 076
    PERFORM 4200-TRATA-BRASIL
END-IF.

Por quê?

Ninguém sabe.

O programador iniciante pensa:

Código velho.

O programador experiente pensa:

Evidência arqueológica.

Antes de apagar, investigue.


👻 CAPÍTULO 7 — O CONHECIMENTO TRIBAL

Existe uma frase particularmente perigosa em informática:

Sempre foi assim.

Imagine um batch.

JOB A
 ↓
JOB B
 ↓
JOB C

JOB B sempre executa às 03:17.

Você pergunta por quê.

Um operador responde:

— Porque precisa ser assim.

— Mas por quê?

— O Carlos sabia.

— Onde está Carlos?

— Aposentou-se em 2014.

Parabéns.

Você encontrou conhecimento tribal.

O sistema possui uma regra que não está adequadamente representada em documentação, código compreensível ou procedimento formal.

Ela existe na memória humana.

Quando a pessoa vai embora:

CONHECIMENTO
     |
     V
 /DEV/NULL

Esse fenômeno conecta Engenharia de Software a outro conceito importante:

Bus Factor.

Quantas pessoas precisam desaparecer inesperadamente antes que determinado conhecimento crítico seja perdido?

Se a resposta for:

1

Takumi recomenda fabricar imediatamente uma poção de documentação.


🔄 CAPÍTULO 8 — SEGUNDA ATIVIDADE: MUDANÇA DE REPRESENTAÇÃO

Grande parte do desenvolvimento é transformação.

Observe:

CONVERSA
   ↓
REQUISITO
   ↓
MODELO
   ↓
ESPECIFICAÇÃO
   ↓
CÓDIGO
   ↓
EXECUTÁVEL

O compilador também transforma representações.

Você escreve:

ADD WS-VALOR TO WS-TOTAL.

Aquilo passa por diversas transformações até resultar em instruções executáveis pela máquina.

Integração moderna faz exatamente a mesma coisa.

Imagine:

Aplicativo
   ↓
JSON
   ↓
REST
   ↓
z/OS Connect
   ↓
COBOL/CICS
   ↓
Db2

Cada fronteira representa uma transformação ou interpretação de informação.

É por isso que modernização não significa necessariamente eliminar o legado.

Muitas vezes significa criar novas representações e interfaces para capacidades existentes.


🔎 CAPÍTULO 9 — TERCEIRA ATIVIDADE: AVALIAÇÃO

Takumi terminou uma espada.

Ele não simplesmente entrega a espada.

Verifica:

resistência
peso
equilíbrio
acabamento
finalidade

Software também precisa ser avaliado.

Daí surgem:

code review
teste unitário
teste integrado
teste de sistema
UAT
regressão
análise estática
testes de performance
testes de segurança

No ecossistema mainframe podemos encontrar ferramentas e práticas envolvendo:

ZUnit
COBOL Check
pipelines
análise estática
automação de testes

Mas existe uma distinção conceitual importantíssima.

Verificação

Pergunta:

Construímos corretamente?

Validação

Pergunta:

Construímos a coisa correta?

É perfeitamente possível produzir um sistema:

bem programado
bem documentado
sem warnings
com testes aprovados

e que resolve o problema errado.

Temos então:

MAXCC=0000

para o desastre.


🧠 CAPÍTULO 10 — QUARTA ATIVIDADE: REFLEXÃO

Esta é uma atividade extremamente interessante.

Reflexão significa pensar sobre o problema, as soluções e as próprias representações que construímos.

Imagine encontrar:

IF WS-FLAG = 'S'
    PERFORM 8500-PROCESSA
END-IF.

Você pergunta:

O que é WS-FLAG?

Começa a investigação.

Procura referências.

Consulta o copybook.

Examina o programa chamador.

Pesquisa documentação.

Analisa histórico.

Conversa com alguém.

Descobre finalmente que aquilo implementa uma regra criada após um incidente ocorrido em 1998.

O código ganhou significado.

Você não mudou necessariamente nenhuma linha.

Mesmo assim realizou trabalho de Engenharia de Software.

Você produziu conhecimento.

É por isso que manutenção de legado frequentemente parece arqueologia.


🎛️ CAPÍTULO 11 — QUINTA ATIVIDADE: CONTROLE

Takumi possui dezenas de objetos na oficina.

Imagine se ninguém soubesse:

quem criou
quando criou
qual material utilizou
qual versão é atual
quem aprovou
onde será usado

Teríamos caos.

Em software temos o mesmo problema.

Precisamos responder:

Quem alterou?
Por quê?
Quando?
Qual versão?
Qual requisito?
Quem aprovou?
Quais testes passaram?
O que foi implantado?
Como voltar?

Daí surgem ferramentas e processos como:

Git
Endevor
Changeman
ISPW
Jenkins
DBB
pipelines
change management
aprovações
segregação de funções

O iniciante às vezes chama isso de burocracia.

Até acontecer um incidente.

Então alguém pergunta:

Quem colocou isso em produção?

Silêncio.

Nesse momento, versionamento deixa de parecer burocracia e passa a parecer magia ancestral de proteção.


📐 CAPÍTULO 12 — QUALIDADE NÃO É UMA POÇÃO JOGADA NO FINAL

Existe uma ideia que precisa ser destruída:

DESENVOLVIMENTO
     ↓
TESTE
     ↓
QUALIDADE

Como se qualidade pudesse ser adicionada depois.

Não pode.

Imagine:

REQUISITO ERRADO
      ↓
DESIGN CORRETO
      ↓
PROGRAMA CORRETO
      ↓
TESTE CORRETO

Resultado?

Sistema errado.

Todos fizeram corretamente aquilo que lhes foi pedido.

Esse é o terror.

Portanto:

QUALIDADE
   |
   +-- requisitos
   +-- arquitetura
   +-- design
   +-- código
   +-- testes
   +-- implantação
   +-- operação
   +-- manutenção

Qualidade é uma propriedade construída durante o processo.

Não uma inspeção final.


🏭 CAPÍTULO 13 — SOFTWARE É INDÚSTRIA, MAS NÃO É PARAFUSO

A analogia entre desenvolvimento de software e produção industrial trouxe enorme quantidade de conhecimento útil.

Processos.

Controle.

Qualidade.

Padronização.

Medição.

Rastreabilidade.

Melhoria contínua.

Mas precisamos reconhecer uma diferença fundamental.

Uma fábrica transforma:

AÇO
 ↓
PEÇA
 ↓
COMPONENTE
 ↓
AUTOMÓVEL

Software transforma principalmente:

CONHECIMENTO
 ↓
REQUISITO
 ↓
MODELO
 ↓
ALGORITMO
 ↓
CÓDIGO
 ↓
COMPORTAMENTO COMPUTACIONAL

Existe outra diferença econômica fascinante.

Fabricar o segundo automóvel continua consumindo matéria-prima.

Copiar um executável custa praticamente nada comparado ao esforço necessário para criá-lo.

O verdadeiro custo está em:

entender
descobrir
projetar
implementar
testar
corrigir
operar
manter
evoluir

Portanto software é um produto industrial peculiar.

Sua principal matéria-prima é conhecimento.


🚀 CAPÍTULO 14 — AGILE NÃO MATOU ESSA IDEIA

Alguns poderiam olhar para representações, documentação e processos e pensar:

Isso é Waterfall.

Não.

Agile mudou principalmente como organizamos e conduzimos o desenvolvimento.

As representações continuam existindo.

Uma user story é representação.

Um backlog é representação.

Um source é representação.

Um teste automatizado é representação.

Um commit é representação.

Um arquivo YAML é representação.

Uma especificação OpenAPI é representação.

Infrastructure as Code é representação.

Até um dashboard representa alguma coisa:

COMPORTAMENTO REAL DO SISTEMA
            ↓
MÉTRICAS
            ↓
DASHBOARD

DevOps também não elimina essa teoria.

Na realidade, automatiza uma quantidade enorme de transformações e avaliações.


🤖 CAPÍTULO 15 — TAKUMI ENCONTRA A PEDRA FILOSOFAL DA IA

Agora chegamos a 2026.

O programador entrega um COBOL para uma IA:

Explique este programa.

Temos:

COBOL
 ↓
LLM
 ↓
DOCUMENTAÇÃO

Mudança de representação.

Depois:

Gere testes para este requisito.

REQUISITO
 ↓
LLM
 ↓
CASOS DE TESTE

Depois:

Explique este copybook.

COPYBOOK
 ↓
LLM
 ↓
MODELO CONCEITUAL

Depois:

Crie uma interface JSON.

ESTRUTURA LEGADA
       ↓
      IA
       ↓
ESTRUTURA MODERNA

Aí percebemos algo fascinante.

IA generativa pode ser vista como uma poderosa máquina de transformação de representações.

Mas existe uma enorme pegadinha.

Transformar não significa preservar perfeitamente o conhecimento.

Uma IA pode:

omitir
interpretar
inventar
generalizar
simplificar

Portanto, as outras atividades continuam necessárias.

Especialmente:

AVALIAÇÃO
REFLEXÃO
CONTROLE

A IA não aboliu Engenharia de Software.

Ela tornou Engenharia de Software ainda mais necessária.


💥 CAPÍTULO 16 — A ALQUIMIA PROIBIDA

Takumi encontra uma fórmula perigosa:

REQUISITO RUIM
      +
AUTOMAÇÃO
      +
VELOCIDADE
      =
ERRO EM ESCALA

Antes, um programador poderia produzir cinco artefatos errados.

Agora uma IA pode produzir cinquenta em minutos.

Código.

Testes.

Documentação.

APIs.

Scripts.

Casos de teste.

Diagramas.

Tudo perfeitamente consistente...

...com uma premissa errada.

É quase bonito.

E aterrorizante.

A produtividade aumenta a importância da validação.

Quanto maior nossa capacidade de produzir, maior precisa ser nossa capacidade de verificar o que estamos produzindo.


🧪 CAPÍTULO 17 — TAKUMI FABRICA UM SISTEMA DO ZERO

Vamos acompanhar um exemplo completo.

O banco informa:

Depois de três tentativas consecutivas de PIN incorreto, bloqueie o cartão.

Temos nossa primeira representação.

Takumi imediatamente pergunta:

— Três tentativas onde?

Boa pergunta.

Começamos a refletir:

São consecutivas?
Existe janela temporal?
PIN correto zera o contador?
Vale em qualquer ATM?
Tentativas no POS contam?
Bloqueio é permanente?
Existe desbloqueio automático?
Precisamos registrar os eventos?

O requisito aparentemente simples explode.

Após investigação:

Após três tentativas consecutivas de PIN inválido, independentemente do ATM utilizado, o cartão deverá ser bloqueado. Uma autenticação válida antes da terceira tentativa reinicia o contador.

Agora temos representação melhor.

Criamos dados:

PIN-ERROR-COUNT
CARD-STATUS
LAST-ATTEMPT

Criamos COBOL:

IF PIN-INVALID
    ADD 1 TO PIN-ERROR-COUNT

    IF PIN-ERROR-COUNT >= 3
        MOVE 'B' TO CARD-STATUS
    END-IF
ELSE
    MOVE ZERO TO PIN-ERROR-COUNT
END-IF.

Agora avaliamos.

CONTADOR  EVENTO       RESULTADO

0         erro         1
1         erro         2
2         erro         3 / bloqueio
2         correto      0

Depois precisamos controlar a mudança:

commit
 ↓
review
 ↓
build
 ↓
teste
 ↓
aprovação
 ↓
deploy
 ↓
monitoramento

Perceba a sequência.

Nunca estivemos simplesmente "programando COBOL".

Estávamos transformando conhecimento até torná-lo comportamento computacional controlado.


🏛️ CAPÍTULO 18 — O MAINFRAME COMO MUSEU VIVO DO CONHECIMENTO

Mainframes fornecem talvez um dos melhores laboratórios para compreender essa teoria.

Imagine um programa criado em 1987.

Recebe alterações em:

1989
1994
1999
2002
2008
2014
2020
2026

Aquele programa contém mais do que algoritmos.

Ele pode carregar vestígios de:

mudanças monetárias
legislação
fusões
novos produtos
novas regulamentações
incidentes
mudanças arquiteturais
migrações
restrições técnicas
decisões comerciais

Um programa COBOL antigo pode ser um fóssil executável da organização.

Por isso aquela rotina estranha talvez não seja lixo.

Talvez seja história empresarial compilada.

Antes de remover:

PERFORM 7310-ROTINA-ESTRANHA

descubra por que ela existe.

Takumi jamais jogaria fora um cristal desconhecido encontrado numa dungeon antes de descobrir suas propriedades.

O mantenedor de legado deveria desenvolver o mesmo instinto.


🗿 CAPÍTULO 19 — AS 80 COLUNAS E O FANTASMA DOS CARTÕES

Existe um easter egg histórico maravilhoso aqui.

COBOL herdou convenções relacionadas aos cartões perfurados de 80 colunas.

O cartão físico desapareceu.

Mas durante décadas continuamos encontrando vestígios daquela representação.

Observe a cadeia:

CARTÃO FÍSICO
      ↓
80 COLUNAS
      ↓
FORMATO DO SOURCE
      ↓
CONVENÇÃO
      ↓
LEGADO

O objeto desapareceu.

A representação sobreviveu.

Isso ensina uma coisa fantástica sobre sistemas:

decisões técnicas podem sobreviver às razões que originalmente as criaram.

Quando alguém perguntar por que determinado sistema funciona daquela maneira, talvez a resposta esteja vinte, trinta ou cinquenta anos no passado.


🧰 CAPÍTULO 20 — CHECKLIST DO APRENDIZ DE ALQUIMISTA COBOL

Quando receber uma alteração, não abra imediatamente o editor.

Primeiro pergunte:

1. Qual problema estamos resolvendo?

Depois:

2. Quem conhece a regra?

Então:

3. Onde esse conhecimento está representado hoje?

Pode estar em:

documentação
COBOL
JCL
copybook
Db2
VSAM
ticket
procedimento
cabeça de alguém

Depois identifique:

4. Quais representações serão afetadas?

Não pense apenas no programa.

Talvez precise alterar:

copybook
programa
DDL
JCL
API
teste
documentação
monitoramento

Então pergunte:

5. Como validaremos a transformação?

Crie evidências.

Depois:

6. Como controlaremos a mudança?

Versionamento.

Aprovação.

Deploy.

Rollback.

Finalmente:

7. Como o próximo programador entenderá isso daqui a cinco anos?

Essa última pergunta separa frequentemente uma correção rápida de Engenharia de Software profissional.


🧙 CAPÍTULO 21 — O COMENTÁRIO QUE SALVA O FUTURO

Imagine encontrar:

*> ALTERADO EM 25/09/2026
*> MOTIVO: REGRA XYZ
*> CHAMADO: INC-12345
*> AUTOR: USER-ID

Daqui a dez anos talvez ninguém conheça o autor.

Mas existe uma pista.

O comentário tornou-se representação de conhecimento histórico.

Não precisamos transformar programas em romances.

Mas registrar:

quem
quando
por quê
referência

pode economizar horas de arqueologia futura.

Software possui memória.

Nós decidimos quanto dela sobreviverá.


⚔️ CAPÍTULO 22 — O VERDADEIRO INIMIGO NÃO É O LEGADO

Chegamos então a outra conclusão.

Legado não significa simplesmente:

velho

Um sistema antigo pode ser:

estável
conhecido
testado
auditado
rentável
crítico

E um microsserviço criado ontem pode já ser legado se ninguém consegue entendê-lo.

O verdadeiro problema é conhecimento perdido.

Quando existe:

código sem contexto
regra sem origem
interface sem contrato
job sem explicação
dependência sem documentação

temos dívida de conhecimento.

Modernização séria precisa recuperar esse conhecimento antes de simplesmente trocar tecnologias.

Caso contrário:

COBOL incompreendido
       ↓
Java incompreendido

Parabéns.

Gastamos milhões para modernizar a linguagem do problema.

O problema permaneceu.


🏆 CAPÍTULO 23 — O QUE SIGNIFICA SER PROFISSIONAL

Voltamos finalmente ao ponto inicial.

Software tornou-se atividade profissional não simplesmente porque utilizamos metodologias sofisticadas.

Profissionalização significa tornar o processo:

compreensível
controlável
avaliável
repetível
auditável
evolutivo

Um cliente maduro não deveria perguntar somente:

Vocês sabem COBOL?

Deveria perguntar:

Como vocês desenvolvem?

Como levantam requisitos?

Como controlam versões?

Como testam?

Como tratam defeitos?

Como rastreiam mudanças?

Como garantem segurança?

Como documentam decisões?

Como fazem rollback?

Como medem qualidade?

Como preservam conhecimento?

Essas perguntas revelam a capacidade real de uma organização muito melhor do que uma apresentação cheia de palavras mágicas.


⚗️ EPÍLOGO — TAKUMI ENTREGA A POÇÃO

Nosso aprendiz finalmente volta à oficina.

Sobre a bancada está o programa COBOL.

Ele pergunta:

— Mestre, agora entendi. Então COBOL não é software?

Takumi balança a cabeça.

— É parte dele.

— E documentação?

— Também.

— Testes?

— Também.

— Dados?

— Também.

— JCL?

— Infelizmente também.

Takumi sorri.

O aprendiz continua:

— Então o que fazemos durante o desenvolvimento?

Takumi coloca cinco cristais sobre a mesa:

INFORMAÇÃO
TRANSFORMAÇÃO
AVALIAÇÃO
REFLEXÃO
CONTROLE

E finalmente explica:

Pegamos conhecimento sobre um problema e progressivamente o transformamos em representações capazes de produzir um comportamento computacional confiável.

O aprendiz olha novamente para:

IDENTIFICATION DIVISION.

Agora aquilo parece diferente.

Não é simplesmente o começo de um programa.

É uma representação.

Uma entre muitas.

Antes dela houve conversas, regras, necessidades e decisões.

Depois dela haverá compilação, testes, execução, logs, manutenção e novas alterações.

E talvez daqui a quarenta anos outro programador encontre aquele source.

Se fizermos nosso trabalho direito, ele conseguirá descobrir não apenas o que o programa faz, mas por que ele existe.

Essa talvez seja uma das responsabilidades menos comentadas da Engenharia de Software.

Nós não escrevemos somente para computadores.

Escrevemos para pessoas que ainda nem chegaram.


☕ ÚLTIMO CAFÉ NO BELLA COSA MAINFRAME

O iniciante aprende:

COBOL

Depois aprende:

CICS
Db2
VSAM
JCL

Mais tarde descobre arquitetura.

Depois qualidade.

Depois processos.

Depois negócio.

Depois pessoas.

Até perceber que passou a carreira inteira trabalhando com algo invisível:

conhecimento.

COBOL é uma representação desse conhecimento.

Java é outra.

UML é outra.

JSON é outra.

OpenAPI é outra.

JCL é outra.

Um teste é outra.

Uma pipeline é outra.

Um prompt para uma IA também é outra.

As tecnologias mudam.

As representações mudam.

As ferramentas mudam.

Os nomes das metodologias mudam.

Mas permanece o grande desafio:

PROBLEMA HUMANO
      ↓
CONHECIMENTO
      ↓
REPRESENTAÇÕES
      ↓
TRANSFORMAÇÕES
      ↓
AVALIAÇÃO
      ↓
SOFTWARE
      ↓
RESULTADO

É por isso que Engenharia de Software nunca foi simplesmente saber programar.

E é por isso que uma IA capaz de gerar dez mil linhas de código em minutos não elimina o engenheiro.

Ela apenas constrói uma máquina alquímica muito mais rápida.

Alguém ainda precisa saber:

o que colocar nela, o que deveria sair dela e como descobrir se a poção resultante vai curar o usuário ou explodir a dungeon inteira.

Takumi fecha a oficina.

O programador olha para o último job da noite.

IEF142I JOB01742 STEP030 - STEP WAS EXECUTED - COND CODE 0000

Ele sorri.

Antigamente teria ido embora satisfeito.

Agora sabe que ainda falta uma pergunta:

MAXCC=0000... mas construímos a coisa certa?

No relógio do datacenter:

03:17.

Em algum lugar, um velho batch começa a executar.

Ninguém sabe exatamente por quê.

Ainda.

☕ Bem-vindo à Engenharia de Software.

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...