 |
| 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 é:
Fazer um READ simples para exibir os dados.
Receber as alterações do usuário.
Executar um READ UPDATE pouco antes da gravação.
Validar novamente.
Fazer o REWRITE.
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:
| RESP | Significado |
|---|
| 00 | Operação realizada com sucesso |
| 02 | Registro não encontrado |
| 14 | Registro bloqueado |
| 20 | Arquivo ou recurso não encontrado |
| 30 | Requisição inválida |
| 91 | Atualizaçã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:
Receber a chave do registro.
Executar READ UPDATE.
Verificar RESP e, quando aplicável, RESP2.
Alterar apenas os campos necessários na Working-Storage.
Executar REWRITE.
Confirmar a unidade lógica de trabalho (SYNCPOINT) ou realizar rollback em caso de falha.
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.
