 |
| Bellacosa Mainframe e a sociedade do mainframe rumo a alta disponibilidade |
☕ Um Café no Bellacosa Mainframe
A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade
Quando um Programador COBOL Padawan Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas
"Nem todos os sistemas que caem estão perdidos. Alguns apenas aguardam que outra região assuma sua missão."
Introdução
Existe um momento na carreira de todo programador COBOL em que ele deixa de pensar apenas no programa que escreveu.
Até então, seu universo era relativamente pequeno.
Recebia uma especificação.
Criava um programa COBOL.
Compilava.
Executava.
Corrigia alguns ABENDs.
Consultava um VSAM.
Executava um SQL.
Colocava em produção.
Fim da história.
Mas então surge uma pergunta aparentemente simples.
"O que acontece quando o programa está funcionando e o servidor onde ele está executando simplesmente desaparece?"
Silêncio.
Essa pergunta muda completamente a forma de enxergar um sistema corporativo.
É exatamente neste ponto que começa nossa jornada.
Como em O Senhor dos Anéis – A Sociedade do Anel, descobrimos que existe um mundo muito maior além do Condado.
O COBOL é apenas Frodo.
O CICS é Rivendell.
O z/OS é a Terra Média.
E a Alta Disponibilidade é a Sociedade que mantém o Um Anel longe das forças do caos.
Hoje atravessaremos essa Terra Média tecnológica.
Pegue seu café.
Afivele o cinto do terminal 3270.
Nossa aventura apenas começou.
Capítulo I
O Condado: Onde Todo Programador COBOL Começa
Todo iniciante acredita que um sistema funciona assim:
Cliente
↓
Programa COBOL
↓
Banco de Dados
↓
Resposta
Simples.
Bonito.
Organizado.
Funciona perfeitamente...
até acontecer a primeira falha.
Imagine um banco.
São nove horas da manhã.
Milhares de pessoas fazem PIX.
Empresas pagam fornecedores.
Cartões de crédito autorizam compras.
Caixas eletrônicos funcionam.
Aplicativos móveis recebem milhões de acessos.
De repente...
A máquina que executa aquele programa simplesmente para.
Não trava.
Não fica lenta.
Ela desaparece.
Agora faça uma pergunta.
Quanto dinheiro um banco perde por minuto parado?
Algumas instituições estimam milhões de reais por hora.
Em bolsas de valores...
alguns segundos podem representar perdas gigantescas.
Foi por isso que nasceu um dos conceitos mais importantes da computação corporativa:
High Availability.
Capítulo II
Mordor Existe
No universo da fantasia existe Sauron.
No Mainframe existem as falhas.
Elas sempre existirão.
Não importa a qualidade do hardware.
Não importa quanto custa o servidor.
Tudo pode falhar.
Discos quebram.
Fontes queimam.
Cabos são desconectados.
Switches morrem.
Processadores apresentam defeitos.
LPARs reiniciam.
Operadores cometem erros.
Programadores também.
O objetivo nunca foi impedir isso.
O objetivo sempre foi impedir que o cliente perceba.
Essa mudança de mentalidade separa iniciantes dos arquitetos de sistemas.
Capítulo III
A Sociedade do Mainframe
Assim como Frodo jamais chegaria sozinho a Mordor, um ambiente CICS nunca depende de um único componente.
A Sociedade é formada por personagens extraordinários.
Frodo — O Programa COBOL
É quem realmente executa a missão.
Ele processa contas.
Calcula juros.
Autoriza cartões.
Move dinheiro.
Mas sozinho ele não sobreviveria.
Gandalf — O WLM
O Workload Manager é um verdadeiro mago.
Ele conhece toda a Terra Média do z/OS.
Sabe onde há CPU disponível.
Onde existe memória.
Onde há menos filas.
Onde o tempo de resposta está melhor.
Enquanto os usuários apenas enviam solicitações...
Gandalf decide para onde cada missão será enviada.
Sem ele...
o reino mergulharia no caos.
Aragorn — O CICS
O verdadeiro líder da batalha.
Cada Região CICS representa um comandante.
Ela recebe transações.
Executa programas.
Coordena recursos.
Mantém a ordem.
Mas, assim como Aragorn, nenhuma região governa sozinha.
Existem várias espalhadas pelo reino.
Legolas — O Monitoramento
Legolas enxerga longe.
Muito longe.
Ele percebe um problema antes dos outros.
O monitoramento faz exatamente isso.
Analisa:
CPU
Storage
SOS
Locks
SQL lento
Esperas
MQ
Threads
Tempo de resposta
Antes mesmo dos usuários reclamarem.
Gimli — O Hardware IBM Z
Robusto.
Pesado.
Quase indestrutível.
Mas nem Gimli é imortal.
Até o melhor hardware pode falhar.
Por isso existem outros anões prontos para assumir.
Sam — O Db2
Frodo jamais teria chegado ao fim sem Sam.
O COBOL também não.
O Db2 acompanha todas as transações.
Protege os dados.
Mantém consistência.
Recupera informações.
Suporta milhões de acessos simultâneos.
Capítulo IV
O Portal de Rivendell
Observe o caminho percorrido por uma simples transação.
Usuário
↓
Aplicativo
↓
Rede
↓
Load Balancer
↓
WLM
↓
Região CICS
↓
COBOL
↓
DB2
↓
Resposta
O usuário nunca conversa diretamente com o COBOL.
Há diversos guardiões protegendo o caminho.
Isso é proposital.
Cada camada adiciona inteligência.
Cada camada aumenta a disponibilidade.
Cada camada reduz riscos.
Capítulo V
O Conselho de Elrond
Imagine que existem quatro Regiões CICS.
CICSA
CICSB
CICSC
CICSD
Durante um dia comum...
todas trabalham juntas.
Cada uma atende milhares de usuários.
Agora imagine que CICSB falhou.
O que acontece?
Nada.
Ou melhor...
quase nada.
O WLM simplesmente deixa de enviar novas transações para ela.
As demais assumem a carga.
Os clientes continuam utilizando o sistema.
É exatamente como retirar Boromir da Sociedade.
A missão continua.
Capítulo VI
O Um Anel da Alta Disponibilidade
Existe um erro comum entre iniciantes.
Pensar que redundância significa desperdício.
Não.
Redundância significa sobrevivência.
Ter apenas uma região é barato.
Mas extremamente perigoso.
Ter quatro regiões parece mais caro.
Até o dia da primeira falha.
Nesse instante...
descobre-se que o investimento pagou décadas de tranquilidade.
Capítulo VII
O Caminho para Mordor
Toda transação percorre diversos desafios.
Primeiro o balanceamento.
Depois o processamento.
Depois acesso ao banco.
Depois gravação em logs.
Depois confirmação.
Se qualquer etapa falhar...
existem mecanismos de recuperação.
Algumas transações reiniciam.
Outras utilizam Syncpoint.
Outras fazem rollback.
Outras repetem a operação.
Tudo pensado para preservar integridade.
Capítulo VIII
O Olho de Sauron Nunca Dorme
Monitoramento contínuo.
Esse é um conceito que muitos desenvolvedores ignoram.
Eles imaginam que basta a região responder.
Mas responder não significa estar saudável.
Uma região pode:
consumir 100% da CPU;
estar sem armazenamento (SOS);
aguardar locks;
enfrentar lentidão no Db2;
acumular filas no MQ.
Ela ainda responde.
Mas lentamente.
O monitoramento detecta esses sinais antes que o usuário perceba.
Ferramentas como OMEGAMON, RMF, SMF, CICS Explorer e soluções de observabilidade modernas funcionam como os sentinelas de Gondor: vigiam continuamente o horizonte em busca de qualquer ameaça.
Capítulo IX
A Fortaleza Invisível: Shared Db2 e VSAM
Uma pergunta importante surge.
Se existem várias regiões...
como todas enxergam os mesmos dados?
A resposta está no compartilhamento.
O Db2, utilizando Data Sharing, permite que diferentes regiões CICS acessem o mesmo conjunto de informações com consistência.
O VSAM, quando configurado com Record Level Sharing (RLS), também possibilita acesso concorrente seguro.
Imagine uma conta bancária.
Saldo:
R$ 1.000
Se uma região enxergasse R$ 1.000 e outra R$ 950, o caos seria inevitável.
É por isso que a consistência dos dados é tão importante quanto a disponibilidade da aplicação.
Capítulo X
O Reino Além do Reino: Parallel Sysplex
Aqui chegamos ao verdadeiro ápice da engenharia IBM.
O Parallel Sysplex.
Imagine várias fortalezas espalhadas pela Terra Média.
Cada uma possui seus soldados.
Cada uma possui seus recursos.
Entretanto...
todas trabalham como se fossem uma única cidade.
É exatamente isso que acontece.
Diversos sistemas IBM Z compartilham recursos através do Coupling Facility, coordenando locks, caches e estruturas compartilhadas.
O resultado?
Escalabilidade quase linear.
Disponibilidade extraordinária.
Capacidade de crescimento contínuo.
É uma das arquiteturas mais elegantes já construídas na história da computação.
Capítulo XI
Alta Disponibilidade não é Disaster Recovery
Esse tema costuma aparecer em entrevistas técnicas.
E muitos candidatos confundem os conceitos.
High Availability (HA) trata de falhas locais.
Uma região caiu?
Outra assume.
Um processador apresentou defeito?
Outro continua executando.
Já Disaster Recovery (DR) lida com eventos muito maiores.
Incêndios.
Enchentes.
Falhas elétricas generalizadas.
Ataques físicos.
Perda completa de um Data Center.
Nesses casos, outro ambiente — muitas vezes localizado em outra cidade ou país — assume as operações.
Uma boa analogia é imaginar um castelo.
Se uma torre desmorona, os soldados continuam defendendo a fortaleza.
Isso é HA.
Mas se o castelo inteiro é destruído por um dragão...
é necessário recuar para outra fortaleza.
Isso é DR.
Curiosidades que Pouca Gente Conhece
🏰 Curiosidade 1
Grandes bancos frequentemente operam com dezenas de Regiões CICS simultaneamente.
🏰 Curiosidade 2
Alguns ambientes processam dezenas de milhares de transações por segundo.
🏰 Curiosidade 3
É comum realizar manutenção em hardware IBM Z sem desligar aplicações críticas.
🏰 Curiosidade 4
Muitos clientes nunca percebem que uma região inteira foi reiniciada durante o expediente.
🏰 Curiosidade 5
Grande parte da confiabilidade do Mainframe vem da combinação entre hardware, sistema operacional, middleware e processos operacionais — não de um único componente.
Passo a Passo para o Padawan COBOL Entender HA
Se você está começando agora, siga esta trilha de estudos:
Aprenda a arquitetura básica do z/OS.
Entenda o papel do CICS.
Estude a diferença entre TOR, AOR e FOR.
Aprenda como funciona o WLM.
Conheça o Db2 Data Sharing.
Estude VSAM RLS.
Entenda Syncpoint e Commit.
Aprenda conceitos de rollback e recuperação.
Descubra como funciona o Parallel Sysplex.
Explore ferramentas de monitoramento como RMF, SMF e OMEGAMON.
Essa sequência fará muito mais sentido do que tentar estudar todos os componentes isoladamente.
Easter Egg Bellacosa Mainframe ☕
Existe uma antiga lenda entre os Sysprogs.
Ela diz que, em algum lugar escondido dentro do Coupling Facility, existe um Palantír Digital.
Apenas os arquitetos mais experientes conseguem enxergar através dele o fluxo de todas as transações da Terra Média do Mainframe. Enquanto um programador iniciante vê apenas um programa COBOL executando um EXEC CICS LINK, o velho mago observa regiões inteiras assumindo cargas, WLM redistribuindo trabalho, Db2 sincronizando dados e o Sysplex mantendo o reino unido.
Dizem ainda que Gandalf jamais utilizou magia para derrotar Sauron.
Na verdade...
ele apenas configurou corretamente o WLM, distribuiu as transações entre múltiplas regiões CICS e deixou que a Alta Disponibilidade fizesse o restante.
Claro... nenhum manual da IBM confirma essa história.
Mas todo bom Sysprog sorri discretamente quando alguém menciona que "o sistema simplesmente não pode parar".
Conclusão
Assim como A Sociedade do Anel não era formada por heróis isolados, a Alta Disponibilidade em um ambiente CICS também é resultado da cooperação entre diversos componentes. O COBOL executa a lógica de negócio, o CICS coordena as transações, o WLM distribui inteligentemente a carga, o Db2 e o VSAM garantem a consistência dos dados, o monitoramento identifica problemas antes que eles afetem os usuários e o Parallel Sysplex transforma múltiplos sistemas em uma infraestrutura única e resiliente.
Para o programador COBOL iniciante, compreender esses conceitos representa uma mudança profunda de perspectiva. Você deixa de enxergar apenas linhas de código e passa a entender o ecossistema que mantém bancos, companhias aéreas, seguradoras, bolsas de valores e governos funcionando ininterruptamente.
No fim da jornada, a maior lição não é aprender a escrever um programa perfeito, mas compreender que, em computação corporativa, a verdadeira excelência está em construir sistemas capazes de continuar servindo milhões de pessoas mesmo quando partes da infraestrutura falham. Esse é o espírito do Mainframe: transformar redundância em confiança, engenharia em continuidade de negócios e tecnologia em um serviço tão confiável que a maioria das pessoas sequer percebe que ele existe.
Porque, como diria um velho mago da Terra Média adaptado ao universo IBM Z:
"Um grande sistema não é aquele que nunca enfrenta falhas. É aquele cuja missão continua, mesmo quando uma parte da Sociedade precisa ficar para trás."
