 |
| Bellacosa Mainframe e o misterio do cadeado invisivel |
☕ Um Café no Bellacosa Mainframe
O Mistério do Cadeado Invisível
Quando um Jovem Programador COBOL Descobriu que Milhões de Pessoas Esperavam por uma Chave que Ninguém Conseguia Ver
"Toda grande cidade possui cofres. Todo banco possui segredos. Todo sistema possui um guardião invisível. E, no silencioso universo do CICS, esse guardião atende por dois nomes: ENQ e DEQ."
As luzes do CPD eram fracas.
O ar-condicionado soprava continuamente, como se respirasse em nome das milhares de transações que cruzavam os cabos de fibra óptica.
Era quase meia-noite.
As impressoras de produção já haviam diminuído o ritmo, os operadores do console observavam atentamente as mensagens do sistema e, em uma pequena sala iluminada apenas pelo brilho verde de um terminal 3270, um jovem programador COBOL fazia uma pergunta aparentemente simples.
— Se dois usuários alterarem o mesmo registro exatamente no mesmo instante... quem vence?
O veterano sorriu.
Levantou lentamente uma velha caneca onde se lia:
Bellacosa Mainframe Café
Tomou um gole.
Olhou para o painel do CICS.
E respondeu apenas:
— Depende de quem pegar a chave primeiro...
O rapaz olhou confuso.
— Que chave?
O veterano respondeu:
— A chave que ninguém vê.
Naquela noite, ele descobriria um dos maiores mistérios do processamento transacional moderno.
O ENQ.
O Problema que Existe Desde que Computadores Aprenderam a Trabalhar Juntos
Quem está começando em COBOL normalmente imagina que um programa executa sozinho.
Mas isso nunca acontece em um ambiente CICS.
Enquanto você lê este artigo, existem sistemas bancários processando dezenas de milhares de transações por segundo.
Imagine um único banco.
Ao mesmo tempo existem:
aplicativo móvel;
Internet Banking;
caixas eletrônicos;
PIX;
TED;
cartão de crédito;
empréstimos;
agências;
sistemas antifraude;
APIs REST;
Web Services;
filas MQ;
processamento batch.
Todos querendo acessar os mesmos dados.
O problema não é escrever programas.
O problema é impedir que eles se matem.
O Fantasma da Concorrência
Existe um vilão invisível.
Seu nome é:
Concorrência.
Ela não aparece em mensagens de erro.
Não gera ABEND.
Não produz dump.
Mas pode destruir milhões de reais em poucos segundos.
Imagine duas pessoas alterando a mesma conta.
Saldo atual:
R$ 10.000
Cliente A faz:
Saque
R$ 1.000
Cliente B faz:
Depósito
R$ 2.000
Ambos começam exatamente no mesmo milissegundo.
Os dois leem:
R$ 10.000
Programa A grava:
R$ 9.000
Programa B grava:
R$ 12.000
O saque desapareceu.
Dinheiro simplesmente evaporou.
Nenhum hacker.
Nenhum vírus.
Nenhum criminoso.
Apenas dois programas trabalhando rápido demais.
Esse fenômeno possui um nome famoso:
Lost Update
Todo programador COBOL deveria decorar esse termo.
Bem-vindo ao Mundo da Serialização
A solução encontrada pelos engenheiros da IBM foi extremamente elegante.
Se duas pessoas querem mexer no mesmo objeto...
Apenas uma recebe a chave.
A outra espera.
Nascia o conceito de:
ENQ — Enqueue
O Porteiro Invisível do CICS
Imagine um prédio.
Existe apenas um porteiro.
Toda vez que alguém deseja entrar na sala do cofre ele pergunta:
— Quem está usando?
Se ninguém estiver:
Entrada autorizada.
Caso contrário:
Aguarde sua vez.
Esse porteiro chama-se ENQ.
Ele nunca aparece na tela.
Nunca imprime mensagens.
Mas está trabalhando durante toda a execução do sistema.
O Que Significa ENQ?
ENQueue significa literalmente:
Entrar na fila.
Mas, no universo CICS, seu verdadeiro significado é muito mais elegante.
Ele diz:
"Este recurso agora pertence exclusivamente a mim."
Enquanto isso durar...
Ninguém mais toca nele.
O Cadeado Invisível
Uma das melhores formas de entender ENQ é imaginar um cadeado.
Quando fazemos:
EXEC CICS ENQ
RESOURCE('CLIENTE0001')
END-EXEC.
É como colocar isto:
🔒
na porta.
Todos os outros programas verão:
OCUPADO
Curiosidade Bellacosa ☕
Pouca gente sabe que ENQ não bloqueia apenas arquivos.
Ele pode proteger praticamente qualquer coisa.
Você pode criar recursos chamados:
PIX
CHEQUE
LOTE
CLIENTE
CARRINHO
IMPRESSORA
NOTA-FISCAL
Ou qualquer nome inventado pela aplicação.
O CICS não se importa.
Para ele aquilo é apenas um identificador lógico.
É quase como colocar etiquetas em gavetas invisíveis.
O Outro Guardião
Todo cadeado precisa de uma chave.
Toda porta precisa ser aberta.
É aí que surge o segundo personagem da história.
DEQ
Dequeue.
Seu trabalho é extremamente simples.
Ele chega.
Olha para o cadeado.
E diz:
Pode liberar.
O Erro Mais Comum dos Iniciantes
O iniciante costuma pensar:
Fiz ENQ.
Já terminei.
Não.
Falta a parte mais importante.
Liberar.
EXEC CICS DEQ
RESOURCE('CLIENTE0001')
END-EXEC.
Sem isso...
Você deixou a porta trancada.
Imagine um Banheiro Público...
Parece engraçado.
Mas é exatamente isso.
Existe apenas uma chave.
Pessoa A entra.
Fecha.
Sai.
Devolve a chave.
Pessoa B entra.
Agora imagine alguém esquecer a chave no bolso.
Toda a fila para.
No CICS acontece exatamente igual.
O Que Está Sendo Protegido?
Essa é uma pergunta muito interessante.
Muitos imaginam que ENQ trava registros VSAM.
Não necessariamente.
Na verdade, ele protege:
recursos lógicos.
Essa é uma diferença extremamente importante.
READ UPDATE Não é ENQ
Essa confusão aparece em praticamente todas as entrevistas técnicas.
READ UPDATE faz lock do registro.
ENQ faz lock de um recurso definido pela aplicação.
São mecanismos diferentes.
Podem trabalhar juntos.
Aliás...
Nos melhores sistemas eles trabalham juntos.
O Fluxo Correto
Imagine um programa bancário.
Ele faz:
ENQ
↓
READ UPDATE
↓
ALTERA
↓
REWRITE
↓
DEQ
Perceba que existem dois níveis de proteção.
Um lógico.
Outro físico.
Essa dupla praticamente elimina atualizações perdidas.
O Segredo da Performance
Aqui existe uma pegadinha.
Quanto tempo você segura o cadeado?
Se a resposta for:
Cinco minutos.
Parabéns.
Você acabou de destruir a performance do banco inteiro.
Imagine um supermercado.
Existe apenas um caixa.
O cliente resolve conversar sobre futebol durante quinze minutos.
O restante da fila simplesmente não anda.
É exatamente isso que acontece quando um lock fica ativo tempo demais.
Quanto Menor, Melhor
Os grandes sistemas seguem uma regra quase sagrada.
Primeiro fazem:
✔ cálculos
✔ validações
✔ consultas
✔ regras de negócio
Depois...
Somente quando realmente precisam gravar:
ENQ
↓
Atualiza
↓
DEQ
O lock dura poucos milissegundos.
É elegante.
É rápido.
É eficiente.
Contention
Existe uma palavra que aparece frequentemente em reuniões de performance.
Contention.
Ela significa:
Disputa.
Imagine mil pessoas querendo alterar a mesma conta bancária.
Só uma vence.
As outras esperam.
Quanto maior a fila...
Maior o tempo de resposta.
Maior o consumo de CPU.
Maior a insatisfação do usuário.
O Detetive e a Conta 1001
Vamos transformar isso em um pequeno romance noir.
Uma agência bancária percebe diferenças de saldo.
Nenhum hacker.
Nenhum vírus.
Nenhuma invasão.
O detetive Bellacosa chega.
Analisa os logs.
Tudo parece correto.
Até encontrar duas transações iniciadas exatamente às:
14:03:51.982
Ambas alteraram:
Conta 1001.
Sem ENQ.
O crime perfeito.
O dinheiro não foi roubado.
Foi sobrescrito.
Easter Egg ☕
Os engenheiros veteranos costumam brincar dizendo:
"Todo deadlock começou como um lock inocente."
A frase parece engraçada.
Mas resume décadas de experiência.
Deadlock — Quando Dois Programas Viram Reféns Um do Outro
Imagine:
Programa A faz:
ENQ CONTA A
Programa B faz:
ENQ CONTA B
Depois:
Programa A tenta:
ENQ CONTA B
Enquanto isso:
Programa B tenta:
ENQ CONTA A
Resultado?
Os dois ficam esperando para sempre.
Nenhum avança.
Esse fenômeno chama-se:
Deadlock.
É um dos monstros mais famosos da computação corporativa.
Como Evitar?
Uma técnica clássica consiste em sempre adquirir recursos na mesma ordem.
Exemplo:
Primeiro Cliente.
Depois Conta.
Depois Contrato.
Nunca alterar essa sequência.
Parece simples.
Mas salva sistemas inteiros.
Um Paralelo com Star Wars
Imagine que apenas um Jedi pode entrar na Câmara do Holocron por vez.
Enquanto Luke consulta um Holocron, Obi-Wan, Yoda e Ahsoka aguardam.
Ninguém interrompe o processo.
Quando Luke termina, ele devolve a chave.
O próximo entra.
Esse é o princípio do ENQ.
Sem sabres de luz.
Mas com exatamente a mesma disciplina.
Um Paralelo com um Castelo Medieval
Visualize um castelo.
Existe apenas uma ponte levadiça.
Quando ela abaixa para um cavaleiro entrar, ninguém mais atravessa.
Depois que ela sobe novamente, outro cavaleiro recebe autorização.
ENQ funciona como o guarda da ponte.
DEQ é quem gira a manivela para liberá-la.
Curiosidade Histórica
Muito antes de ouvirmos falar em Kubernetes, microsserviços ou computação em nuvem, os engenheiros de mainframe já resolviam problemas de concorrência em ambientes com milhares de usuários simultâneos.
Nos anos 1970, quando bancos processavam milhões de operações em CICS, conceitos como serialização de recursos, controle de concorrência e recuperação transacional já eram realidade. Muitas das ideias presentes hoje em bancos de dados modernos, filas distribuídas e sistemas de mensageria têm raízes nesses mecanismos clássicos.
Em outras palavras, quando alguém diz que o mainframe é "tecnologia antiga", frequentemente está usando tecnologias que herdaram conceitos desenvolvidos décadas antes nos grandes computadores corporativos.
Dicas de Ouro para o Programador COBOL Iniciante
✔ Pense primeiro na regra de negócio e depois no bloqueio.
✔ Nunca mantenha um ENQ ativo enquanto espera entrada do usuário.
✔ Sempre planeje um caminho para liberar o recurso, mesmo em caso de erro.
✔ Conheça a diferença entre ENQ, READ UPDATE e os mecanismos de lock do banco de dados.
✔ Monitore contenção em produção: um sistema lento nem sempre sofre por falta de CPU; às vezes o gargalo é uma fila de transações esperando pelo mesmo recurso.
✔ Documente quais recursos lógicos sua aplicação utiliza. Um bom padrão de nomenclatura evita conflitos e facilita a manutenção.
✔ Lembre-se de que sincronização excessiva também tem custo. O objetivo não é bloquear tudo, mas bloquear apenas o necessário.
O Arquivo Secreto do Bellacosa Mainframe ☕
Existe uma velha lenda entre programadores veteranos.
Dizem que, em algum lugar dos laboratórios da IBM, existe uma placa com a frase:
"Dados podem ser recriados. Confiança do cliente, não."
Talvez ela nunca tenha existido.
Talvez seja apenas uma história passada de geração em geração.
Mas ela resume perfeitamente por que ENQ e DEQ são tão importantes.
Eles não servem apenas para bloquear recursos.
Eles existem para proteger aquilo que realmente importa.
A confiança de que, ao consultar sua conta bancária, emitir um boleto, fazer um PIX ou registrar um pedido, o resultado refletirá exatamente o que aconteceu — nem mais, nem menos.
Epílogo – O Mistério Resolvido
Já era madrugada.
O jovem programador fechou o manual do CICS.
Olhou novamente para o terminal.
Agora entendia que, por trás de cada transação aparentemente simples, havia um intricado jogo de sincronização, disciplina e engenharia.
O veterano terminou o último gole de café.
Apontou para o console iluminado.
Sorriu discretamente.
— Está vendo? O sistema parece silencioso.
Mas, neste exato instante, milhares de ENQs estão sendo adquiridos, milhares de DEQs estão sendo liberados e milhões de pessoas continuam movimentando seu dinheiro sem imaginar que existe um exército de cadeados invisíveis trabalhando para elas.
O jovem fez que sim com a cabeça.
Naquela noite, ele aprendeu que programar em COBOL não era apenas escrever comandos.
Era compreender a delicada coreografia que impede o caos em um mundo onde milhões de transações acontecem ao mesmo tempo.
E, enquanto as luzes do CPD permaneciam acesas e o z/OS seguia processando silenciosamente mais um dia de trabalho, um novo guardião do CICS acabava de nascer.
