 |
| Bellacosa Mainframe e o misterio do carimbo invisivel |
☕ Um Café no Bellacosa Mainframe
O Mistério do Carimbo Invisível
Quando um Jovem Programador COBOL Descobriu que Milhões de Transações Dependiam de uma Palavra Chamada SYNCPOINT
"Toda cidade possui um juiz invisível. No CICS, ele atende pelo nome de SYNCPOINT."
Era pouco depois das duas da manhã.
No CPD, apenas o som ritmado dos equipamentos IBM preenchia o ambiente. As luzes verdes piscavam como estrelas artificiais em um universo onde bilhões de bytes viajavam silenciosamente pelos canais do mainframe.
O jovem programador Henrique havia acabado de terminar sua primeira rotina de transferência bancária em COBOL.
Estava orgulhoso.
O programa compilava.
Não havia nenhum S0C7.
Nenhum AEI9.
Nenhum ASRA.
Tudo parecia perfeito.
Mas o velho analista Augusto Bellacosa apenas sorriu, tomou mais um gole de café e perguntou:
— "Muito bonito... mas quem garante que o dinheiro realmente chegou ao destino?"
Henrique congelou.
— "Como assim?"
Augusto levantou uma sobrancelha.
— "Você escreveu um programa. Ainda não escreveu uma transação."
Naquela madrugada, Henrique descobriria um dos maiores segredos do CICS.
Um segredo invisível.
Chamado...
SYNCPOINT.
O que realmente é um SYNCPOINT?
Todo iniciante imagina que um programa executa linha após linha e, no final, tudo fica gravado.
No mundo do CICS isso não funciona assim.
Na verdade, o CICS trabalha com um conceito muito mais sofisticado chamado:
Unit of Work (UOW).
Uma Unit of Work é um conjunto de operações que pertencem à mesma missão.
Imagine um detetive dos filmes noir dos anos 1950.
Ele recebe um envelope.
Dentro dele existem quatro documentos.
Nenhum pode desaparecer.
Nenhum pode ser trocado.
Nenhum pode ser perdido.
Somente quando todos estiverem completos ele coloca um enorme carimbo vermelho escrito:
CONFIRMADO
Esse carimbo é o SYNCPOINT.
Até esse momento...
Nada é definitivo.
A grande mentira que todo iniciante acredita
Muitos programadores pensam:
"Fiz um REWRITE.
O registro já está salvo."
Não.
Essa é uma das maiores armadilhas do CICS.
Na realidade acontece isto:
READ UPDATE
↓
Registro bloqueado
↓
Programa altera memória
↓
REWRITE
↓
Registro continua pertencendo à transação
↓
SYNCPOINT
↓
Agora sim tudo ficou permanente.
O REWRITE altera.
O SYNCPOINT confirma.
São responsabilidades completamente diferentes.
Imagine um Cartório
Pense em um contrato.
Você assina.
A outra pessoa assina.
As testemunhas assinam.
Mas...
Enquanto o tabelião não colocar o selo oficial...
Nada possui validade jurídica.
O SYNCPOINT é exatamente esse selo.
O nascimento da Unit of Work
Toda transação CICS começa discretamente.
Usuário entra
↓
Programa inicia
↓
Lê arquivos
↓
Atualiza DB2
↓
Atualiza VSAM
↓
Grava TSQ
↓
Envia MQ
↓
...
Tudo isso ainda pertence à mesma história.
É apenas quando aparece:
EXEC CICS
SYNCPOINT
END-EXEC.
que aquela história ganha um final definitivo.
O CICS possui memória fotográfica
Pouca gente sabe disso.
Enquanto você altera registros, o CICS praticamente fotografa o estado anterior dos dados.
Por quê?
Porque talvez precise voltar tudo.
Imagine um pintor restaurando um quadro do século XVIII.
Antes de tocar na tinta original ele tira dezenas de fotografias.
Caso algo dê errado...
Pode restaurar exatamente como estava.
O CICS faz algo parecido através dos mecanismos de recuperação e journals.
O poder escondido do Journal
Existe um personagem que quase nunca aparece nas apostilas.
O Journal.
Ele é como o diário secreto do sistema.
Ali ficam registrados acontecimentos suficientes para permitir que a recuperação seja feita com segurança.
É graças a ele que o CICS consegue dizer:
"Se algo der errado, sei exatamente como desfazer."
Sem Journal...
Rollback seria praticamente impossível.
O verdadeiro significado do COMMIT
A maioria pensa que COMMIT significa:
Gravar.
Na realidade significa muito mais.
Quando acontece um SYNCPOINT o CICS:
✔ confirma alterações no DB2
✔ confirma alterações VSAM
✔ confirma recursos recuperáveis
✔ sincroniza todos os participantes da transação
✔ grava informações de recuperação
✔ encerra a Unit of Work
✔ libera todos os locks
✔ informa aos Resource Managers que tudo terminou corretamente
É quase como um maestro encerrando uma sinfonia.
O Tribunal Supremo das Transações
Imagine um julgamento.
Cinco testemunhas.
Quatro advogados.
Um juiz.
Todos apresentam suas provas.
No final...
O juiz fala apenas uma palavra.
"Culpado."
Ou
"Inocente."
Não existe meio culpado.
O SYNCPOINT funciona exatamente assim.
Todos os recursos esperam a decisão final.
O fantasma chamado Rollback
Agora imagine outro cenário.
Henrique faz uma transferência.
Conta A
↓
Debita R$ 5.000
↓
Conta B
↓
Erro no VSAM
Sem rollback:
Conta A perdeu dinheiro.
Conta B não recebeu.
Dinheiro evaporou.
Imagine isso acontecendo milhões de vezes.
Nenhum banco sobreviveria.
Então entra em cena o segundo personagem desta história.
EXEC CICS
SYNCPOINT ROLLBACK
END-EXEC.
O CICS olha para trás.
Lê sua memória.
E desfaz tudo.
Como se nada tivesse acontecido.
É quase uma máquina do tempo.
O poder da viagem temporal
Poucas tecnologias conseguem fazer isso tão elegantemente.
Rollback literalmente faz o sistema voltar alguns segundos.
Não todo o computador.
Apenas aquela Unit of Work.
É como rebobinar somente uma cena do filme.
Um erro clássico dos iniciantes
Henrique perguntou:
— "Então posso fazer commit depois de cada registro?"
Augusto quase derrubou o café.
— "Claro que pode."
Henrique sorriu.
Então Augusto completou.
— "E também pode destruir toda a performance do sistema."
Commits possuem custo.
Cada um envolve sincronização.
Logs.
Liberação de locks.
Comunicação entre Resource Managers.
Por isso existe um equilíbrio delicado.
Nem commits demais.
Nem commits de menos.
Quando não fazer commit?
Imagine atualizar cem registros.
Se fizer cem commits...
O sistema gastará muito tempo apenas encerrando Units of Work.
Agora imagine atualizar dez milhões de registros.
Fazer apenas um commit no final também pode ser um desastre.
Locks ficarão presos durante muito tempo.
O segredo está no equilíbrio.
Esse é um dos motivos pelos quais arquitetos de sistemas estudam cuidadosamente o tamanho ideal da UOW.
O segredo dos Locks
Outro mistério.
Muitos acreditam:
READ UPDATE
↓
REWRITE
↓
Registro liberado
Não.
O lock continua.
Somente o commit libera.
Isso explica diversos problemas de contenção.
Enquanto uma transação segura um registro...
Outra precisa esperar.
ENQ, DEQ e SYNCPOINT
Lembra dos comandos ENQ e DEQ?
Eles são parentes próximos do SYNCPOINT.
Imagine uma biblioteca.
Você pega um livro raro.
Enquanto ele está emprestado ninguém mais pode utilizá-lo.
O ENQ reserva.
O DEQ devolve.
Já o SYNCPOINT garante que todo o processo envolvendo aquele livro foi concluído corretamente antes de liberar os demais recursos associados à transação.
São mecanismos diferentes, mas frequentemente trabalham em harmonia para preservar a consistência da aplicação.
E se o computador desligar?
Essa é uma das perguntas favoritas das entrevistas IBM.
Imagine:
UPDATE DB2
↓
UPDATE VSAM
↓
Queda de energia
O CICS consulta seus registros de recuperação.
Percebe que aquela Unit of Work nunca terminou.
Resultado?
Backout automático.
O usuário talvez nem perceba.
Esse comportamento é uma das razões pelas quais bancos confiam no CICS há mais de cinco décadas.
A ligação com o DB2
Quando DB2 participa da transação, ele também espera.
Nenhuma alteração fica permanente até que o SYNCPOINT seja executado.
É como vários cofres aguardando a mesma chave.
Somente quando a chave gira...
Todos são fechados simultaneamente.
VSAM também participa
Da mesma forma:
READ UPDATE
↓
REWRITE
↓
DELETE
↓
WRITE
Tudo permanece dentro da mesma Unit of Work.
O VSAM somente considera as alterações definitivamente concluídas quando o CICS encerra a transação com sucesso.
O relacionamento com HANDLE ABEND
Em artigos anteriores vimos o HANDLE ABEND.
Agora tudo faz sentido.
HANDLE ABEND
↓
Erro inesperado
↓
Rotina de recuperação
↓
SYNCPOINT ROLLBACK
↓
RETURN
Observe como as peças começam a formar um quebra-cabeça.
O conhecimento em CICS é cumulativo.
Cada comando reforça o entendimento do anterior.
Curiosidade Histórica
Nos primeiros anos do CICS, quando bancos começaram a abandonar sistemas baseados em processamento puramente batch para operações online, um dos maiores medos era exatamente este:
"E se o sistema cair no meio de uma transferência?"
Foi o amadurecimento dos mecanismos de recuperação, journals, locks e SYNCPOINT que permitiu o crescimento dos caixas eletrônicos, do internet banking e, décadas mais tarde, dos aplicativos móveis.
Cada saque em um caixa eletrônico, cada pagamento de boleto e cada transferência eletrônica dependem, direta ou indiretamente, desses princípios.
Curiosidade Técnica
Você provavelmente já ouviu falar nas propriedades ACID dos bancos de dados.
O SYNCPOINT é uma das peças fundamentais que ajuda a concretizar esses princípios dentro do ambiente transacional do CICS:
Atomicidade: tudo acontece ou nada acontece.
Consistência: os dados permanecem válidos.
Isolamento: outras transações não enxergam alterações incompletas.
Durabilidade: após o commit, as mudanças sobrevivem até mesmo a falhas do sistema.
Dicas para quem está aprendendo COBOL+CICS
✔ Sempre pense em termos de negócio, não apenas de comandos.
✔ Antes de programar pergunte:
"Se ocorrer um erro aqui... o que deve voltar?"
✔ Nunca esqueça que REWRITE não significa commit.
✔ Aprenda a visualizar uma Unit of Work inteira antes de escrever uma linha de código.
✔ Conheça RESP e RESP2 para tratar erros antes de decidir entre continuar ou executar um rollback.
✔ Estude os journals e os mecanismos de recuperação. Eles raramente aparecem nos primeiros cursos, mas fazem enorme diferença para compreender como o CICS realmente funciona.
Easter Egg Bellacosa ☕
Existe uma antiga lenda entre programadores veteranos de mainframe.
Dizem que, nas madrugadas em que o CPD está silencioso e apenas o z/OS continua trabalhando, é possível imaginar um enorme carimbo invisível passando de transação em transação.
Cada vez que um SYNCPOINT é executado com sucesso, esse carimbo marca silenciosamente:
"Integridade preservada."
Ninguém vê.
Nenhum operador escuta.
Nenhuma tela 3270 exibe essa mensagem.
Mas, graças a esse "carimbo invisível", milhões de pessoas acordam pela manhã e encontram seus saldos bancários exatamente onde deveriam estar.
Talvez esse seja o maior elogio que uma tecnologia possa receber: funcionar tão bem que quase ninguém percebe sua existência.
O Arquivo Confidencial Bellacosa
Nome do Caso: O Carimbo Invisível
Suspeitos: REWRITE, WRITE, DELETE, UPDATE, DB2, VSAM
Investigador Principal: CICS Transaction Manager
Juiz da Operação: SYNCPOINT
Plano de Fuga: SYNCPOINT ROLLBACK
Cúmplices: Journals, Locks, Unit of Work, Resource Managers
Veredito Final: Nenhuma transação recuperável deve terminar pela metade.
Conclusão
O SYNCPOINT é muito mais do que um simples comando do CICS. Ele representa a fronteira entre o provisório e o permanente, entre uma alteração ainda reversível e uma decisão definitiva. É ele quem encerra a Unit of Work, confirma atualizações em recursos como Db2, VSAM, filas recuperáveis e outros gerenciadores de recursos, libera bloqueios e garante que todas as partes da transação caminhem juntas.
Seu contraponto, o SYNCPOINT ROLLBACK, oferece ao sistema a capacidade de voltar atrás quando algo inesperado acontece, preservando a integridade dos dados e evitando inconsistências que poderiam comprometer operações críticas.
Quando um programador COBOL entende verdadeiramente conceitos como READ UPDATE, REWRITE, ENQ, DEQ, HANDLE ABEND, journals, locks, Unit of Work e SYNCPOINT, ele deixa de apenas escrever programas e passa a compreender a engenharia invisível que mantém bancos, seguradoras, companhias aéreas e grandes empresas funcionando de forma confiável há décadas.
No fim das contas, o maior mistério do CICS nunca foi sua velocidade, nem sua idade, nem mesmo sua capacidade de processar milhões de transações por segundo.
O verdadeiro mistério é que, enquanto o mundo dorme, um pequeno comando com apenas nove letras continua decidindo, silenciosamente, o destino de fortunas, contratos, reservas de voo, prontuários médicos e incontáveis operações críticas.
E como diria Augusto Bellacosa ao terminar mais uma xícara de café diante do brilho esverdeado de um terminal 3270:
"Programas escrevem dados. Transações escrevem confiança. E confiança... sempre termina com um SYNCPOINT."
Sem comentários:
Enviar um comentário