Bellacosa Mainframe em uma introducao a segurança cibernetica

☕ Um Café no Bellacosa Mainframe

Em parceria com o Dr. Strangelove — que prometeu não ensinar o z/OS a cavalgar uma bomba, desde que ninguém deixe Igor perto do painel de emergência

Segurança Cibernética para Quem Escreve COBOL — Quando o Mainframe Descobriu que o Inimigo Não Precisava Arrombar a Porta, Bastava Pedir Acesso com Educação

Ou: o programador iniciante achava que segurança era coisa do RACF, até descobrir que uma senha roubada, uma API sem validação, uma biblioteca vulnerável e um log sem horário certo podiam reunir-se no mesmo JCL para produzir um ABEND de proporções cinematográficas

O Dr. Strangelove entrou no Bellacosa Mainframe Café às sete da manhã usando uma luva preta, um terno amarrotado e a expressão de quem acabara de receber autorização para transformar um diagrama de rede em uma arma estratégica.

— Cavalheiros — disse ele, olhando para o quadro branco —, hoje falaremos de segurança.

Igor, que estava instalando um cabo de rede entre a máquina de café e um terminal 3270, levantou a mão:

— É aquela coisa do cadeado, doutor?

— Não, Igor. O cadeado é apenas o desenho que vendemos para convencer as pessoas de que controlamos alguma coisa.

E, pela primeira vez, o jovem programador COBOL sentado no balcão percebeu que segurança não era uma disciplina distante, feita de capuzes pretos, telas verdes e pessoas digitando depressa em filmes ruins. Segurança era o motivo pelo qual um salário não aparecia na tela errada. Era o motivo pelo qual uma transação não podia ser alterada em silêncio. Era o motivo pelo qual o sistema continuava funcionando numa sexta-feira de pagamento, mesmo quando metade da internet resolveu tentar entrar ao mesmo tempo.

Em outras palavras: segurança era negócio, continuidade e confiança usando capacete.

---

Prólogo — O cofre, a porta e o sujeito que já estava lá dentro

A primeira imagem daquele caderno de cibersegurança fala de confidencialidade, integridade e disponibilidade: a velha tríade CIA. Não é agência de espionagem; é a fundação de quase tudo.

• Confidencialidade: somente quem deve ver consegue ver.

• Integridade: o dado permanece correto, completo e protegido contra alteração indevida.

• Disponibilidade: sistema e informação estão acessíveis quando autorizados precisam deles.

Pense num sistema de folha de pagamento em COBOL.

A confidencialidade impede que o operador do turno noturno veja salários, contas bancárias e descontos médicos de todos os funcionários. A integridade impede que alguém transforme discretamente 00000500000 em 00050000000 no campo de salário. E a disponibilidade garante que o batch de pagamento não fique parado porque um servidor periférico decidiu tirar férias no meio da madrugada.

Dr. Strangelove bateu a colher no pires.

— O problema, meus caros, é que os humanos tratam segurança como se fosse uma fechadura. Mas ela é uma cidade inteira: ruas, chaves, guardas, câmeras, regras, mapas de fuga e alguém responsável por acordar quando o alarme toca.

No mainframe, muita gente se acostumou — com alguma razão — a enxergar o ambiente como um cofre. RACF, segregação, datasets protegidos, auditoria, controle de job, CICS, Db2, JES2: há décadas de engenharia séria aí. Mas o cofre moderno ganhou APIs REST, Java, USS, FTP legado, TN3270, pipelines DevOps, conexões cloud e notebooks de usuários. A porta de aço continua forte; o problema é que agora ela tem interfone, Wi-Fi e formulário web.

---

1. A cadeia do desastre: ameaça, vulnerabilidade, exploit, impacto e risco

Antes de comprar qualquer ferramenta com painel cheio de gráficos verdes, é preciso aprender as palavras certas.

Uma ameaça é algo capaz de causar dano: criminoso, ransomware, insider malicioso, funcionário enganado, fornecedor comprometido, falha operacional. Uma vulnerabilidade é a fraqueza: software sem patch, senha fraca, serviço exposto, permissão excessiva, código que confia na entrada do usuário.

O exploit é a técnica usada para aproveitar a vulnerabilidade. E o impacto é o estrago: vazamento, fraude, interrupção, multa, perda de confiança, trabalho no fim de semana e café tomado com raiva.

Risco é a possibilidade de uma ameaça explorar uma vulnerabilidade e causar impacto.

O desenho simplifica isso como:

Risco = probabilidade × impacto

É uma boa fórmula para começar, mas não use como se fosse a tabela periódica. Uma vulnerabilidade CVSS 9.8 em um laboratório isolado não tem necessariamente prioridade maior que uma falha CVSS 6.5 em uma API pública que dá acesso a dados de clientes.

A pergunta madura não é “qual é a nota da CVE?”. É:

• Esse ativo é crítico?

• Está exposto à internet?

• Existe exploit público?

• Há sinais de exploração ativa?

• Que dados ele manipula?

• Temos controles compensatórios?

• Se ele parar agora, quem deixa de trabalhar, receber ou vender?

Igor anotou: “não discutir com a CVSS; perguntar onde ela mora”.

Boa anotação, Igor.

---

2. Rede: não existe ataque mágico, existe caminho

Um programa COBOL pode parecer morar exclusivamente dentro do mainframe, mas hoje ele conversa com CICS, Db2, MQ, arquivos, APIs, z/OS Connect, bancos externos, portais, aplicativos móveis e outros sistemas que alguém chama de “integração simples” cinco minutos antes da produção parar.

Por isso, o programador precisa entender a rua por onde os dados passam.

• IP é o endereço lógico de um equipamento na rede.

• Porta identifica o serviço: 443 costuma ser HTTPS; 22, SSH; 53, DNS.

• DNS traduz nome em endereço.

• TCP prioriza entrega confiável; UDP costuma priorizar velocidade e menor sobrecarga.

• TLS protege uma comunicação, criando canal criptografado e autenticado.

A analogia do Café é simples: o IP informa em qual prédio você está; a porta diz qual departamento atende; o protocolo define como a conversa acontece; TLS põe a conversa dentro de um envelope lacrado.

Firewall é a portaria. Ele pode dizer “essa origem não entra por esta porta”, mas não entende sozinho toda a lógica do negócio. Se uma requisição HTTPS legítima traz uma ordem de pagamento fraudulenta usando credenciais válidas, ela pode atravessar o firewall sorrindo e mostrando um crachá roubado.

Por isso existe defesa em profundidade:

• rede segmentada;

• firewall;

• IDS e IPS;

• controle de acesso;

• MFA;

• endpoint protegido;

• aplicação segura;

• criptografia;

• logs;

• backups;

• resposta a incidentes.

Não é redundância inútil. É a admissão honesta de que um controle pode falhar.

No z/OS, segmentar também significa pensar em ambientes, LPARs, redes, acessos a USS, perfis RACF, zonas de administração e fluxos entre componentes. O objetivo não é criar uma burocracia que faz qualquer mudança exigir seis luas cheias. É impedir que o comprometimento de um ponto vire passeio turístico pelo datacenter.

---

3. Autenticar não é autorizar — e RACF não lê pensamentos

Esta é uma das distinções mais importantes de toda a segurança:

• Autenticação pergunta: “quem é você?”

• Autorização pergunta: “o que você pode fazer?”

• Controle de acesso aplica a decisão e registra o resultado.

Uma senha, um token, um certificado ou uma biometria ajudam a autenticar. Já uma regra RACF, uma role, uma ACL ou uma política de API ajudam a autorizar.

Você pode provar que é o Vagner Bellacosa. Isso não quer dizer que pode alterar a tabela de salários, cancelar produção, dar SPECIAL para todos ou substituir a produção por um JOB chamado DOUTOR.STRANGELOVE.NUCLEAR.TESTE.

O princípio é o do menor privilégio: usuário, processo e serviço recebem somente o acesso necessário para executar a tarefa — nem uma migalha a mais.

Há modelos clássicos:

• RBAC: acesso por função. Ex.: operador, auditor, administrador.

• ABAC: acesso por atributos e contexto. Ex.: permitir somente se o usuário pertence à área correta, usa dispositivo gerenciado, está no horário permitido e acessa o caso atribuído.

• DAC: o proprietário decide quem acessa.

• MAC: acesso baseado em classificação formal, comum em contextos militares e governamentais.

A evolução moderna é o Zero Trust: não confiar automaticamente porque alguém está na rede interna, usa notebook corporativo ou teve acesso ontem. Cada solicitação importante deve ser avaliada com contexto.

É o oposto do velho pensamento: “está dentro do castelo, então é amigo”. O invasor moderno frequentemente já está dentro — usando conta válida, VPN, token, e-mail ou sessão roubada.

---

4. Criptografia: Base64 não é capa de invisibilidade, Igor

O caderno faz bem em separar três coisas que muita gente mistura.

Criptografia transforma informação legível em informação protegida por chave. Serve para confidencialidade.

Hash gera uma impressão digital do conteúdo. Ele ajuda a verificar integridade, mas não foi feito para recuperar o original.

Encoding, como Base64, só muda o formato. Não protege segredo algum. Se alguém “escondeu” senha em Base64, não criou segurança; apenas colocou bigode falso no dado.

Há duas famílias principais de criptografia:

• Simétrica: usa uma chave secreta compartilhada. É veloz e ótima para grandes volumes de dados.

• Assimétrica: usa par de chaves pública e privada. É muito útil para identidade, assinatura e troca segura de chaves.

No HTTPS moderno, o navegador e o servidor usam mecanismos assimétricos para estabelecer confiança e negociar segredos; depois, protegem a sessão com criptografia simétrica, mais rápida. É por isso que um site pode proteger milhões de conexões sem exigir que o datacenter compre uma usina nuclear do Dr. Strangelove.

Para quem trabalha em ambiente corporativo, as regras são pouco glamourosas e absolutamente vitais:

• nunca grave segredos no código;

• nunca suba senha ou token em repositório;

• proteja chave privada como ativo crítico;

• roteie segredos por cofre apropriado;

• rotacione chaves e credenciais;

• use TLS em trânsito;

• proteja dados sensíveis em repouso;

• valide certificados, não apenas “aceite qualquer um para o teste funcionar”.

No IBM Z, recursos criptográficos e serviços como ICSF não existem apenas para colocar siglas bonitas em apresentação. Eles permitem proteger chaves e operar criptografia com controles e desempenho compatíveis com dados de alto valor.

---

5. Aplicação segura: o bug também pode ser uma regra de negócio

Quando se fala em segurança web, o povo lembra de SQL Injection, escreve uma query parametrizada e vai dormir em paz. Seria lindo se o monstro fosse tão educado.

A segurança de aplicação inclui:

• controle de acesso quebrado;

• falhas de autenticação;

• injeção;

• configuração insegura;

• componentes desatualizados;

• segredos expostos;

• erros de integridade de software;

• logs insuficientes;

• desenho inseguro.

O exemplo mais perigoso para um iniciante entender é Broken Access Control.

Imagine uma API que recebe:

/cliente/123/extrato

Se o usuário autenticado troca 123 por 124 e a aplicação devolve o extrato de outra pessoa, não faltou criptografia. Faltou autorização no nível do objeto. O sistema verificou “você entrou?”, mas esqueceu de verificar “você pode ver exatamente este cliente?”.

Em COBOL e CICS, o equivalente pode aparecer em telas, transações, arquivos, bancos, serviços e integrações. Segurança não é só colocar uma rotina de login na entrada. É verificar regra de negócio em cada operação sensível.

E há uma frase que deveria morar na parede de todo time:

WAF é cinto de segurança; não é permissão para dirigir contra o muro.

WAF, firewall e scanner ajudam, mas não corrigem uma aplicação cujo desenho permite que um usuário aprove pagamento para a própria conta sem segregação de funções.

---

6. DevSecOps: segurança não entra na última janela de mudança

DevSecOps é a tentativa de fazer segurança acompanhar o ciclo de desenvolvimento em vez de aparecer no fim dizendo “encontrei 417 problemas, cancelem a entrega”.

O ideal é incluir segurança em todas as etapas:

1. Requisitos: quais dados existem? Quais obrigações legais? O que pode dar errado?

2. Desenho: modelar ameaças, definir fronteiras, privilégios e fluxos.

3. Desenvolvimento: revisão de código, práticas seguras, análise estática.

4. Build: verificar dependências, segredos, integridade de artefatos.

5. Testes: análise dinâmica, testes de integração, cenários de abuso.

6. Deploy: validar infraestrutura como código, configuração e permissões.

7. Operação: monitorar, detectar, responder e aprender.

Para COBOL, isso não significa jogar fora o processo de mudança confiável para fingir que tudo agora é container. Significa trazer princípios modernos para a casa: versionamento, revisão, testes automatizados onde possível, evidência de mudança, análise de dependências em componentes integrados, trilha de auditoria e separação adequada entre desenvolvimento e produção.

Dr. Strangelove olhou para Igor:

— E se o programador insistir em gravar a senha num literal COBOL?

— A gente chama de constante, doutor?

— Chamamos de incidente aguardando data de abertura.

---

7. Vulnerabilidade, endpoint e nuvem: scanner não é oráculo

Gestão de vulnerabilidades é processo contínuo:

inventariar → descobrir → analisar → priorizar → corrigir ou mitigar → validar → medir → repetir

O erro clássico é rodar scanner, gerar um PDF de 300 páginas e declarar vitória. Scanner não corrige patch, não remove privilégio excessivo, não fecha serviço, não atualiza imagem e não convence um dono de aplicação a testar a mudança.

O ativo desconhecido é especialmente perigoso. Um servidor “aposentado” pode continuar ligado com um serviço vulnerável, uma conta antiga e uma conexão esquecida. É o equivalente técnico daquele JCL que ninguém sabe quem criou, mas todos têm medo de apagar.

No endpoint, segurança é feita em camadas:

• hardening do sistema operacional;

• configuração segura;

• atualização;

• antimalware;

• EDR;

• controle de aplicações;

• criptografia e proteção física.

EDR é mais do que antivírus: observa comportamento e ajuda na investigação e resposta. Mas não deve virar desculpa para não aplicar patch, manter contas administrativas ou deixar software desconhecido rodar.

Na cloud, a pegadinha é a responsabilidade compartilhada. O provedor protege partes da infraestrutura; você continua responsável por identidade, dados, configuração, permissões, chaves, aplicações e uso correto dos serviços. Bucket público por engano não é “falha da nuvem”. Geralmente é uma porta aberta pela própria empresa.

---

8. SIEM, MITRE e o momento em que log vira história

Log isolado é ruído. Correlação transforma peças em narrativa.

Um login falho pode ser erro de digitação. Cinco tentativas falhas podem ser usuário esquecendo senha. Mas login falho na VPN, seguido de autenticação bem-sucedida de local impossível, depois elevação de privilégio e transferência anormal de dados: aí o SOC tem uma história para investigar.

SIEM recebe e organiza eventos de servidores, rede, aplicações, cloud, firewall, identidades e endpoints. Seu valor não está no painel colorido. Está em responder:

• o que aconteceu?

• quando?

• com qual conta?

• em qual ativo?

• de onde veio?

• que dados foram tocados?

• até onde o evento chegou?

Por isso, horário correto importa. Sem NTP, os logs são como testemunhas de boteco depois do quinto copo: todos têm certeza, ninguém concorda sobre a ordem dos fatos.

MITRE ATT&CK entra como vocabulário para comportamento adversário: acesso inicial, execução, persistência, roubo de credenciais, movimento lateral, exfiltração e impacto. Não é checklist de “tenho ferramenta para tudo?”. É ferramenta para perguntar: “se o atacante fizer isso, consigo ver? Consigo bloquear? Consigo investigar?”

---

9. Phishing e resposta a incidente: o ataque não começa no malware

Muitos ataques começam com uma história plausível: e-mail de fornecedor, chamada urgente do diretor, convite de reunião, QR code, documento compartilhado, WhatsApp ou voz clonada.

O phishing moderno pode ser perfeitamente escrito. Então a defesa não pode depender de procurar erro de português.

A defesa madura mistura:

• MFA;

• filtros e sandbox;

• autenticação de domínio;

• confirmação fora de banda para pagamento;

• bloqueio de anexos perigosos;

• cultura de reporte sem punição;

• treinamento baseado em situações reais.

Se a pessoa clicou e avisou em dois minutos, ela ajudou a organização. Não a transforme em inimiga. O inimigo agradeceria.

Quando há incidente, o ciclo é:

1. Preparar: papéis, playbooks, contatos, ferramentas, backups e exercícios.

2. Identificar: validar alerta, classificar, coletar evidência.

3. Conter: limitar propagação e preservar negócio.

4. Erradicar: remover causa, persistência e vulnerabilidade.

5. Recuperar: restaurar com segurança e monitorar.

6. Aprender: corrigir processo, controle, treinamento e arquitetura.

A regra de ouro é: não apague pistas antes de saber o que aconteceu. Isolar a máquina pode ser correto. Sair removendo arquivos, reiniciando tudo e destruindo evidência pode transformar um incidente investigável em uma novela de 14 capítulos.

---

Epílogo — O botão vermelho não é um plano de segurança

No fim do café, Dr. Strangelove desenhou uma arquitetura inteira no guardanapo:

identidade + menor privilégio + segmentação + código seguro + criptografia + patch + logs + detecção + resposta + backup

Igor olhou para a lista.

— Então qual é o controle mais importante, doutor?

A luva preta tentou subir até uma saudação, mas ele a segurou.

— O mais importante é não depender de apenas um.

Para o programador COBOL iniciante, este é o aprendizado de verdade: segurança não mora num produto, nem numa sigla, nem apenas no RACF, no firewall ou no SOC. Ela aparece quando você define um campo, trata uma entrada, autoriza uma transação, revisa uma mudança, registra uma ação, protege um segredo e pergunta: “o que acontece se isto falhar — ou se alguém tentar abusar?”

O mainframe não é velho. Velha é a ideia de que um sistema central, poderoso e conectado ao mundo pode sobreviver apenas porque sempre sobreviveu.

E, enquanto o sistema estiver processando pagamentos, hospitais, impostos, cartões, seguros e histórias inteiras de pessoas, segurança continuará sendo o trabalho silencioso de garantir que o próximo RETURN-CODE não venha acompanhado de sirenes.

Igor desligou o cabo da máquina de café.

O Dr. Strangelove respirou aliviado.

E o Bellacosa Mainframe Café permaneceu aberto.

DotCom : Capítulo III — A Economia do "Queime Caixa": Quando Gastar Milhões Virou Sinônimo de Sucesso

 

Bellacosa Mainframe o estouro da bolha do dotcom capitulo III

Capítulo III — A Economia do "Queime Caixa": Quando Gastar Milhões Virou Sinônimo de Sucesso

Como a obsessão pelo crescimento criou uma das maiores ilusões financeiras da história da tecnologia

"Uma nave pode acelerar até a velocidade de dobra. Mas, se o reator de antimatéria acabar antes do destino, toda a velocidade do universo será inútil."

Chegamos agora ao coração da bolha da Internet.

Se existe um conceito que todo Padawan COBOL precisa compreender para entender por que milhares de empresas desapareceram no início dos anos 2000, esse conceito é conhecido como Burn Rate, ou, em tradução livre, taxa de consumo de caixa.

Parece um termo moderno.

Mas sua lógica é antiga.

Muito antiga.

Imagine que você recebe um salário de R$ 10.000 por mês.

No primeiro mês, você resolve gastar R$ 30.000.

No segundo, mais R$ 30.000.

No terceiro, novamente R$ 30.000.

Enquanto houver alguém disposto a emprestar dinheiro, você continua vivendo como um milionário.

Mas chega um momento em que alguém faz a pergunta inevitável:

"Quando você pretende começar a ganhar mais do que gasta?"

Foi exatamente essa pergunta que destruiu milhares de empresas da era das Dot-Com.

---

O Que é Burn Rate?

De maneira simples, Burn Rate representa a velocidade com que uma empresa consome seu dinheiro disponível.

Imagine uma fogueira.

Quanto maior a chama...

Mais rapidamente a lenha desaparece.

Nas startups ocorre algo semelhante.

O dinheiro dos investidores é a lenha.

As despesas são o fogo.

Enquanto houver madeira...

O fogo continua bonito.

Quando acaba...

Não importa o tamanho da chama.

Tudo termina.

Esse conceito parece óbvio hoje.

Mas, durante alguns anos, parecia quase irrelevante.

---

Crescer Primeiro. Lucrar Depois.

A filosofia dominante entre 1997 e 2000 era extremamente sedutora.

Primeiro conquistaríamos milhões de usuários.

Depois descobriríamos como ganhar dinheiro.

A lógica parecia razoável.

Quanto maior a base de clientes, maior seria o potencial de receita futura.

O problema estava na palavra futuro.

Esse futuro nunca tinha data para chegar.

Enquanto isso, as contas continuavam vencendo.

Salários.

Aluguel.

Servidores.

Publicidade.

Marketing.

Infraestrutura.

Consultorias.

Viagens.

Eventos.

O dinheiro saía diariamente.

Mas quase não entrava.

---

A Corrida pela Escala

Outro conceito que ganhou enorme importância foi a escalabilidade.

Uma empresa tradicional precisava abrir novas lojas para crescer.

Cada nova unidade significava:

• aluguel;

• funcionários;

• estoque;

• energia;

• manutenção.

Na Internet parecia diferente.

Criava-se um site.

Depois mais servidores.

Depois mais usuários.

O crescimento parecia infinito.

Esse raciocínio estava correto.

Mas escondia um detalhe gigantesco.

Servidores também custam dinheiro.

Desenvolvedores custam dinheiro.

Data centers custam dinheiro.

Links de Internet custam dinheiro.

Suporte custa dinheiro.

Escalar não era gratuito.

Apenas era diferente.

---

O Dinheiro Parecia Infinito

Durante a bolha, fundos de investimento competiam entre si para financiar startups.

Era comum uma empresa levantar dezenas ou centenas de milhões de dólares antes mesmo de apresentar lucro.

Algumas sequer possuíam um produto finalizado.

Bastava convencer investidores de que estavam construindo "o futuro".

Em poucos anos, uma cultura extremamente perigosa começou a surgir.

Gastar muito passou a ser interpretado como sinal de crescimento.

Quanto maior o prejuízo...

Maior parecia ser o potencial da empresa.

Hoje isso soa absurdo.

Na época parecia perfeitamente lógico.

---

O Marketing Virou um Buraco Negro

Talvez nenhum setor tenha consumido tanto dinheiro quanto o marketing.

Empresas compravam espaços durante o Super Bowl.

Patrocinavam eventos.

Espalhavam outdoors por grandes cidades.

Contratavam celebridades.

Produziam comerciais milionários.

O objetivo era simples.

Ficar conhecido antes dos concorrentes.

Muitas acreditavam que bastava dominar a mente do consumidor para garantir o sucesso futuro.

Mas havia um problema.

Publicidade gera visibilidade.

Não gera automaticamente receita.

---

O CAC Começou a Explodir

Hoje existe um indicador bastante conhecido chamado CAC.

Customer Acquisition Cost.

Ou custo para adquirir um cliente.

Imagine vender um produto de R$ 50.

Se você gastar R$ 500 em publicidade para conquistar esse cliente...

Seu negócio está perdendo dinheiro.

Durante a bolha da Internet isso acontecia frequentemente.

Empresas gastavam centenas de dólares para conquistar consumidores que compravam apenas uma única vez.

Enquanto investidores financiavam essa diferença...

Parecia funcionar.

Quando os investimentos diminuíram...

O modelo inteiro desmoronou.

---

O LTV Era Apenas uma Esperança

Outro conceito bastante utilizado atualmente é o Lifetime Value (LTV).

Representa quanto um cliente gera de receita ao longo de todo o relacionamento com a empresa.

Muitas startups justificavam enormes prejuízos dizendo:

"Hoje estamos perdendo dinheiro com este cliente.

Mas durante os próximos dez anos teremos lucro."

A teoria era excelente.

Na prática...

Grande parte desses clientes simplesmente nunca voltou.

As projeções eram otimistas demais.

---

O Escritório Também Virou Produto

Curiosamente, muitas startups passaram a competir também pela aparência.

Escritórios enormes.

Salas coloridas.

Escorregadores.

Mesas de pingue-pongue.

Videogames.

Cafés gourmet.

Frutas à vontade.

Massagem.

Academias.

Na época parecia representar uma nova cultura corporativa.

Em muitos casos representava apenas uma enorme despesa adicional.

Ambientes agradáveis são importantes.

Mas eles não substituem um modelo de negócios sustentável.

---

Contratar Também Virou Competição

Outro fenômeno curioso ocorreu com o mercado de trabalho.

Empresas contratavam centenas de profissionais muito antes de realmente precisarem deles.

A lógica era impedir que concorrentes encontrassem talentos disponíveis.

Desenvolvedores recebiam salários impressionantes.

Mudavam de empresa diversas vezes por ano.

Stock options tornaram-se extremamente populares.

Todos acreditavam que ficariam milionários quando a empresa abrisse capital.

Em alguns casos isso aconteceu.

Na maioria...

As ações tornaram-se praticamente sem valor.

---

Quando Crescimento Virou Vaidade

Durante aquele período surgiu uma obsessão por métricas que pouco diziam sobre a saúde financeira das empresas.

Número de visitantes.

Número de acessos.

Quantidade de páginas vistas.

Downloads.

Cadastros.

Cliques.

Esses números apareciam em todas as apresentações para investidores.

Quase ninguém perguntava algo muito mais importante.

Quantos clientes realmente pagam?

Essa diferença continua extremamente atual.

Uma aplicação pode possuir milhões de usuários.

Se ninguém pagar por ela...

O problema permanece.

---

O Dia em que Lucro Virou Palavra Proibida

Existe uma frase atribuída a diversos investidores daquela época.

"Lucro é para empresas velhas."

Essa mentalidade tornou-se tão forte que algumas companhias praticamente evitavam discutir resultados financeiros.

O foco era apenas crescimento.

A crença era simples.

Quando dominarmos o mercado...

O lucro aparecerá naturalmente.

Algumas empresas conseguiram isso.

Amazon é um exemplo.

A maioria não.

Porque dominar mercado também exige sobreviver tempo suficiente para alcançá-lo.

---

Enquanto Isso... Nos Mainframes

Agora imagine um gerente de processamento de dados em um grande banco brasileiro em 1999.

Toda manhã ele recebia indicadores como:

• disponibilidade do sistema;

• tempo médio de resposta;

• volume de transações;

• utilização de CPU;

• consumo de disco;

• filas de processamento;

• integridade dos dados.

Nenhum diretor perguntava:

"Quantos milhões de acessos tivemos hoje?"

A pergunta era muito mais simples.

"O sistema funcionou?"

Esse contraste é fascinante.

Enquanto startups celebravam visitantes.

Mainframes celebravam transações concluídas com sucesso.

Enquanto empresas de Internet comemoravam páginas visualizadas.

Centros de processamento comemoravam disponibilidade de 99,999%.

Era uma diferença de mentalidade.

Uma focava expectativa.

Outra focava execução.

---

A Matemática Sempre Cobra

Existe uma característica curiosa da matemática.

Ela não possui opinião.

Não participa de reuniões.

Não lê reportagens.

Não acompanha tendências.

Ela simplesmente funciona.

Se uma empresa gasta continuamente mais do que arrecada...

Em algum momento o dinheiro termina.

Pode demorar meses.

Pode demorar anos.

Mas acontecerá.

Foi exatamente isso que ocorreu com centenas de startups.

Elas não quebraram porque a Internet era ruim.

Quebraram porque suas despesas cresceram mais rapidamente do que suas receitas.

---

A Armadilha do "Depois a Gente Resolve"

Talvez o maior erro estratégico daquele período tenha sido transformar problemas fundamentais em preocupações futuras.

Logística?

Depois resolvemos.

Rentabilidade?

Depois resolvemos.

Segurança?

Depois resolvemos.

Infraestrutura?

Depois resolvemos.

Atendimento?

Depois resolvemos.

Governança?

Depois resolvemos.

O problema é que empresas crescem.

Problemas também.

E quanto maior a empresa...

Mais caro se torna corrigir decisões equivocadas tomadas no início.

Essa continua sendo uma das maiores lições para startups atuais.

---

O Paralelo com a Inteligência Artificial

Olhando para 2026, encontramos algumas semelhanças interessantes.

Diversas empresas de IA recebem investimentos bilionários.

Muitas ainda operam com prejuízo.

Algumas apostam que receitas futuras compensarão os custos atuais.

A diferença é que boa parte dessas empresas já entrega valor concreto.

Modelos de IA realmente aumentam produtividade.

Automatizam tarefas.

Auxiliam desenvolvedores.

Transformam atendimento ao cliente.

Ou seja...

A tecnologia é real.

O desafio continua sendo construir modelos econômicos sustentáveis.

A história das Dot-Com não ensina que devemos desconfiar da inovação.

Ela ensina que inovação e sustentabilidade precisam caminhar juntas.

---

Lições para o Padawan COBOL

Todo programador COBOL aprende cedo que um sistema não pode depender apenas de condições ideais.

É preciso prever exceções.

Tratar erros.

Garantir recuperação.

Controlar recursos.

Planejar capacidade.

Empresas funcionam exatamente da mesma maneira.

Caixa é como memória disponível.

Se acabar...

O programa termina.

Receita é semelhante ao processamento de entrada.

Sem novos dados...

Não existe trabalho.

Lucro pode ser comparado ao espaço livre em disco.

Ele garante que o sistema continue crescendo sem entrar em colapso.

No universo da Frota Estelar, seria impensável iniciar uma missão interestelar sem calcular cuidadosamente o combustível, as reservas de energia e os recursos necessários para retornar à Terra. No entanto, foi exatamente isso que inúmeras empresas fizeram durante a bolha da Internet: aceleraram ao máximo, fascinadas pela velocidade, sem verificar se havia energia suficiente para completar a viagem.

No próximo capítulo veremos como essa cultura de crescimento a qualquer custo contaminou investidores, analistas e a mídia, criando um ambiente de euforia coletiva em que qualquer empresa ligada à Internet parecia destinada ao sucesso. Era o início do auge da bolha — justamente o momento em que ela começava, silenciosamente, a preparar seu inevitável colapso.

Boy Scout Rules : Quando um Programador COBOL Descobriu que a Matrix Não Era Mantida por Heróis… Mas por Pequenas Melhorias Feitas Todos os Dias

 

Bellacosa Mainframe apresenta boy scout rules

☕ Um Café no Bellacosa Mainframe

Boy Scout Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era Mantida por Heróis… Mas por Pequenas Melhorias Feitas Todos os Dias

"Você não precisa reescrever a Matrix inteira. Basta deixá-la um pouco melhor cada vez que passar por ela."

---

Prólogo — A Sala Esquecida da Matrix

Após anos atravessando corredores infinitos da Matrix, Neo começou a notar algo estranho.

Algumas partes pareciam modernas.

Outras lembravam sistemas criados décadas antes.

Havia corredores impecáveis.

Outros estavam escuros.

Cabos pendurados.

Portas enferrujadas.

Painéis quebrados.

Neo perguntou ao Arquiteto:

— Quem deixou isso assim?

O Arquiteto respondeu:

— Ninguém.

Neo estranhou.

— Como assim ninguém?

O Oráculo apareceu carregando uma velha lanterna.

Caminhou lentamente por um corredor abandonado.

Pegou um cabo solto.

Prendeu-o corretamente.

Apagou uma mensagem de erro antiga.

Organizou alguns arquivos.

Depois continuou andando.

Neo perguntou:

— Isso resolve o problema da Matrix?

Ela respondeu:

— Não.

Resolve apenas este corredor.

Neo insistiu:

— Então por que perder tempo?

Ela sorriu.

— Porque milhares de pessoas fizeram exatamente isso durante muitos anos.

É por isso que a Matrix ainda funciona.

Naquele instante Neo compreendeu a Boy Scout Rule.

---

O que é a Boy Scout Rule?

A regra é extremamente simples.

"Always leave the campground cleaner than you found it."

Em português.

"Sempre deixe o acampamento mais limpo do que você encontrou."

Na Engenharia de Software ela foi adaptada para:

"Deixe o código um pouco melhor do que encontrou."

Não significa reescrever tudo.

Significa realizar pequenas melhorias sempre que tocar em um trecho de código.

---

A origem da regra

A inspiração vem do movimento dos Escoteiros (Boy Scouts of America).

Existe uma orientação tradicional ensinada aos jovens escoteiros:

Quando abandonar um acampamento.

Deixe-o melhor do que estava.

Mesmo que isso signifique apenas:

• recolher um papel;

• apagar uma fogueira;

• organizar algumas pedras.

Na Engenharia de Software, Robert C. Martin (Uncle Bob) popularizou essa ideia como um hábito de desenvolvimento.

---

Matrix explica perfeitamente

Imagine que milhões de pessoas percorrem diariamente os corredores da Matrix.

Cada uma realiza apenas uma pequena melhoria.

No fim do ano.

Toda a Matrix está melhor.

Agora imagine o contrário.

Todos dizem:

"Não fui eu quem bagunçou."

Resultado.

O sistema envelhece rapidamente.

---

O COBOL vive exatamente esse cenário

Existem aplicações bancárias com:

• trinta;

• quarenta;

• cinquenta anos.

Nenhuma equipe consegue parar tudo para reescrever esses sistemas.

Mas milhares de pequenas melhorias acumuladas durante décadas fazem enorme diferença.

---

O efeito da melhoria contínua

Imagine um programa COBOL.

Você entra apenas para alterar uma regra tributária.

Durante a alteração percebe:

• variável mal nomeada;

• comentário desatualizado;

• código morto;

• PERFORM desnecessário;

• IF duplicado.

Você corrige.

Leva cinco minutos.

O próximo programador agradecerá.

---

Matrix Reloaded

Neo observa Zion sendo mantida.

Não existem apenas engenheiros brilhantes.

Existem centenas de pessoas realizando pequenas manutenções diariamente.

É isso que mantém a cidade viva.

---

O efeito psicológico

Existe um pensamento perigoso.

"Isso não é problema meu."

A Boy Scout Rule combate exatamente essa mentalidade.

Ela transforma todos em responsáveis pela qualidade coletiva.

---

O Programador COBOL Padawan

Você abre um programa.

Encontra:

MOVE ZERO TO WS-X.
MOVE ZERO TO WS-Y.
MOVE ZERO TO WS-Z.

Poderia deixar.

Mas decide organizar.

Talvez usar inicialização mais clara.

Talvez melhorar nomes.

Talvez remover duplicações.

Nenhuma dessas mudanças altera o negócio.

Mas todas melhoram a manutenção.

---

O Agente Smith adora abandono

Smith não destrói sistemas apenas criando bugs.

Ele espera.

Espera que pequenas sujeiras se acumulem.

Comentários antigos.

Variáveis confusas.

Código morto.

Layouts duplicados.

Depois de alguns anos.

A manutenção torna-se um pesadelo.

---

Um exemplo inspirado na Matrix

Imagine uma escada.

Cada pessoa deixa uma pequena pedra sobre um degrau.

Nenhuma pedra parece importante.

Anos depois.

A escada torna-se intransitável.

Agora imagine o contrário.

Cada pessoa remove uma pedra.

A escada permanece limpa para sempre.

---

Pequenas melhorias fazem enorme diferença

Você pode:

• alinhar código;

• renomear variáveis;

• remover comentários incorretos;

• apagar código morto;

• dividir um PERFORM enorme;

• atualizar documentação;

• melhorar mensagens de erro.

Nada disso muda o negócio.

Mas muda profundamente a qualidade.

---

O impacto no Mainframe

No ambiente IBM Z encontramos frequentemente:

• programas COBOL escritos por dezenas de equipes ao longo de décadas;

• COPYBOOKs antigos;

• comentários que não correspondem mais ao código;

• JCLs com parâmetros obsoletos;

• procedimentos duplicados.

Esperar uma reescrita completa é, muitas vezes, inviável.

A Boy Scout Rule oferece um caminho realista: evoluir continuamente.

---

Curiosidade

Muitas empresas perceberam que a maior parte da dívida técnica não nasce de grandes erros arquiteturais.

Ela surge de pequenas negligências repetidas diariamente.

Uma variável mal nomeada hoje.

Um comentário errado amanhã.

Uma duplicação na semana seguinte.

Meses depois.

Temos um sistema difícil de manter.

---

Atenção!

Boy Scout Rule não significa:

Refatorar o sistema inteiro enquanto corrige um pequeno bug.

Esse é um erro bastante comum.

---

A diferença

Boa prática

Corrigir um pequeno problema relacionado ao trecho alterado.

---

Exagero

Transformar uma correção simples em um projeto de seis meses.

---

Matrix e o Oráculo

O Oráculo nunca tenta reconstruir toda a Matrix.

Ela influencia pequenas decisões.

Uma conversa.

Uma escolha.

Uma melhoria.

No final.

Essas pequenas ações mudam toda a história.

---

Um exemplo COBOL

Antes.

IF WS-A = "S"
    MOVE "A" TO WS-X
ELSE
    MOVE "B" TO WS-X
END-IF

Você percebe que o comentário acima diz:

Calcula imposto.

Mas o código não calcula imposto algum.

Atualiza o comentário.

Parece pequeno.

Mas evita confusão futura.

---

Outro exemplo

Você encontra:

WS-TEMP1
WS-TEMP2
WS-TEMP3

Durante a manutenção.

Renomeia para:

WS-SALDO-ATUAL
WS-LIMITE-CREDITO
WS-VALOR-PARCELA

Nenhuma regra mudou.

Mas a legibilidade aumentou enormemente.

---

Ferramentas ajudam

Hoje possuímos excelentes ferramentas para apoiar pequenas melhorias contínuas.

Entre elas:

• IBM ADDI.

• SonarQube.

• COBOL Check.

• IBM Developer for z/OS.

• IBM Z Open Editor.

• Git.

• Pull Requests.

• Code Review.

• IA Generativa.

Elas ajudam a identificar pontos simples que podem ser aprimorados sem grandes impactos.

---

O papel da IA

A Inteligência Artificial tornou-se uma excelente parceira da Boy Scout Rule.

Ela consegue sugerir:

• nomes melhores;

• simplificação de IFs;

• remoção de código morto;

• reorganização de PERFORMs;

• comentários mais claros;

• duplicações.

Mas a decisão continua sendo humana.

Nem toda sugestão melhora o sistema.

---

Os riscos

Ignorar pequenas melhorias produz:

• crescimento da dívida técnica;

• manutenção lenta;

• onboarding difícil;

• maior número de bugs;

• baixa produtividade.

---

Erros clássicos

• "Depois alguém arruma."

• "Sempre foi assim."

• "Não vale a pena."

• "Não é minha responsabilidade."

• "Funciona, então deixa."

Essas frases envelhecem sistemas muito rapidamente.

---

Boas práticas

• Corrigir pequenos problemas ao modificar um módulo.

• Atualizar comentários inconsistentes.

• Remover código morto.

• Melhorar nomes de variáveis.

• Eliminar duplicações simples.

• Organizar PERFORMs.

• Registrar decisões importantes.

---

Boy Scout Rule conversa com toda esta série

Esse princípio é praticamente um elo entre todos os conceitos estudados até aqui.

Ele ajuda a combater:

• Technical Debt, reduzindo o acúmulo de dívida técnica.

• Lava Flow, removendo pequenos trechos abandonados.

• Spaghetti Code, reorganizando gradualmente o código.

• Big Ball of Mud, promovendo pequenas melhorias estruturais.

• DRY, eliminando duplicações encontradas durante a manutenção.

• KISS, simplificando trechos excessivamente complexos.

• YAGNI, removendo funcionalidades desnecessárias.

• Murphy's Law, fortalecendo validações e tratamentos de erro.

• SOLID, aproximando o código de responsabilidades mais claras.

Em vez de esperar um grande projeto de modernização, a qualidade cresce continuamente.

---

Aplicabilidade

A Boy Scout Rule pode ser aplicada em praticamente qualquer área da engenharia:

• COBOL.

• CICS.

• Db2.

• JCL.

• REXX.

• Java.

• Python.

• APIs.

• DevOps.

• Infraestrutura como Código.

• Documentação.

• Pipelines CI/CD.

• Playbooks Ansible.

Ela não depende de tecnologia.

Depende de cultura.

---

O ensinamento do Oráculo

O Oráculo leva Neo até um velho jardim dentro da Matrix.

O chão está coberto por folhas.

Ela entrega uma pequena vassoura.

Neo pergunta:

— Vamos limpar tudo?

Ela responde:

— Não.

Limpe apenas o caminho por onde passaremos hoje.

Horas depois.

Outras pessoas fazem o mesmo em outros caminhos.

Dias depois.

O jardim inteiro está limpo.

Sem que ninguém tenha realizado uma grande reforma.

Ela olha para Neo e diz:

"Quem espera pela grande transformação normalmente não muda nada. Quem melhora um pequeno detalhe todos os dias acaba transformando o mundo inteiro."

---

Lições para um Programador COBOL Padawan

Durante sua carreira você herdará programas escritos por profissionais que talvez nunca conheça.

Alguns serão excelentes.

Outros nem tanto.

Resista à tentação de criticar quem veio antes.

Lembre-se de que aqueles sistemas sobreviveram porque alguém os manteve funcionando.

Sua missão agora é continuar essa história.

Sempre que modificar um programa, pergunte:

• Posso melhorar o nome desta variável?

• Posso remover este trecho morto?

• Este comentário ainda faz sentido?

• Posso reduzir esta duplicação?

• Posso tornar este IF mais legível?

• Posso registrar melhor esta decisão?

Se a resposta for "sim" e o risco for baixo, faça a melhoria.

A próxima pessoa que abrir esse código talvez seja você mesmo daqui a cinco anos.

---

Curiosidades

A Boy Scout Rule influenciou fortemente práticas modernas como:

• Clean Code, de Robert C. Martin.

• Refatoração Contínua, popularizada por Martin Fowler.

• Trunk-Based Development, incentivando pequenas mudanças frequentes.

• Continuous Integration, reduzindo grandes refatorações.

• Code Review, estimulando melhorias incrementais.

• InnerSource, promovendo responsabilidade coletiva sobre o código.

Todas compartilham uma mesma visão:

qualidade é construída diariamente, não apenas em grandes projetos de modernização.

---

Conclusão — A Matrix Não Foi Salva em um Único Dia

Neo derrotou Smith em uma batalha decisiva.

Mas a Matrix não permaneceu estável por causa daquele único momento.

Ela continuou existindo porque milhares de pequenas correções, ajustes e melhorias foram realizadas continuamente ao longo do tempo.

Na Engenharia de Software acontece exatamente o mesmo.

A Boy Scout Rule nos ensina que grandes sistemas não envelhecem bem por acaso. Eles envelhecem bem porque cada desenvolvedor deixa uma pequena contribuição positiva sempre que toca no código.

Para um Programador COBOL trabalhando em IBM Z, essa filosofia é especialmente poderosa. Não é necessário esperar um projeto milionário de modernização para melhorar um sistema legado. Pequenas melhorias consistentes, feitas com responsabilidade e baixo risco, acumulam um enorme ganho de qualidade ao longo dos anos.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na entrada da oficina de manutenção da Matrix:

"Você talvez não tenha tempo para reconstruir toda a Matrix hoje. Mas sempre terá tempo para deixar um único corredor melhor do que o encontrou. E quando milhares de engenheiros fizerem o mesmo, a própria Matrix parecerá nova sem jamais ter sido reconstruída."

Porque o verdadeiro legado de um engenheiro não é apenas o código que ele escreve.

É o código que ele entrega em condições melhores para a próxima geração de Padawans.

O Guia Definitivo para um Programador COBOL Padawan Entender por que Todo Isekai, RPG e Mangá Usa as Letras E, D, C, B, A e S para Medir o Poder

 

Bellacosa Mainframe entenda os ranks das guildas em anime e alem

☕ Um Café no Bellacosa Mainframe

Ranks dos Animes sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que Todo Isekai, RPG e Mangá Usa as Letras E, D, C, B, A e S para Medir o Poder

Existe uma cena que praticamente todo fã de anime, mangá, light novel ou RPG já viu dezenas de vezes.

O protagonista chega até uma Guilda dos Aventureiros.

Uma esfera mágica mede suas habilidades.

Uma placa luminosa aparece.

Todos prendem a respiração.

Então surge uma única letra.

E.

Os aventureiros riem.

O recepcionista faz uma cara de pena.

Os veteranos comentam:

— "Só um Rank E..."

Mas, algumas temporadas depois, aquele mesmo personagem derrota um dragão ancestral, salva o reino inteiro e recebe o título de Rank S.

Se você está começando agora no mundo dos animes, talvez pense que essas letras foram inventadas apenas para deixar a história mais emocionante.

Na verdade, elas representam um sistema extremamente inteligente de progressão que mistura psicologia, teoria dos jogos, design de RPG, estatística, administração e até conceitos utilizados em grandes empresas.

Curiosamente, esse sistema também pode explicar perfeitamente como evolui um programador COBOL dentro de um ambiente IBM Z.

Pegue sua caneca de café.

Hoje vamos descobrir que essa pequena letra ao lado do nome de um aventureiro diz muito mais do que parece.

---

Antes de tudo: o que é um Rank?

Rank significa simplesmente:

posição dentro de uma hierarquia.

É uma maneira rápida de responder perguntas como:

• Quão experiente essa pessoa é?

• Em quem podemos confiar?

• Que tipo de missão ela consegue realizar?

• Quanto perigo ela suporta?

• Quanto ela já provou seu valor?

É exatamente igual ao mundo profissional.

Imagine um hospital.

Existem:

• Estagiários

• Residentes

• Médicos

• Especialistas

• Chefes de equipe

Todos são médicos.

Mas possuem níveis diferentes de experiência.

Nos animes acontece exatamente a mesma coisa.

---

A pirâmide do poder

A maioria dos animes representa os ranks como uma pirâmide.

           S
         A
       B
     C
   D
 E

Observe uma curiosidade.

Quanto maior o rank...

menor o espaço.

Isso representa uma verdade estatística.

Pouquíssimas pessoas chegam ao topo.

Essa ideia aparece em praticamente tudo na vida.

Por exemplo:

• Faixas do Karatê

• Graduação Militar

• IBM Fellow

• Doutorado

• Certificações técnicas

• Cargos executivos

Sempre existe uma base enorme.

E um topo extremamente pequeno.

---

Rank E — O Começo da Jornada

O Rank E costuma ser o menor nível oficial.

Muita gente interpreta isso como:

"Esse personagem é fraco."

Na verdade, não.

Ele apenas ainda não teve oportunidade de provar seu potencial.

O Rank E representa:

• iniciante

• novato

• aprendiz

• aventureiro recém-registrado

Ele conhece pouco sobre:

• monstros

• estratégia

• sobrevivência

• trabalho em equipe

É o equivalente ao famoso Padawan.

No mundo COBOL seria alguém que acabou de aprender:

• TSO

• ISPF

• JCL

• Compilar um programa

Ainda não significa que seja ruim.

Significa apenas que está começando.

---

Rank D — O Sobrevivente

Agora o aventureiro já saiu da teoria.

Ele enfrentou monstros reais.

Já conhece armadilhas.

Aprendeu que uma espada bonita não vence batalhas.

Experiência vence.

No mercado de trabalho seria o profissional júnior.

Ele ainda pergunta bastante.

Mas já consegue executar tarefas sozinho.

---

Rank C — O Profissional

Aqui começa a diferença.

O aventureiro deixa de ser apenas alguém que acompanha grupos.

Agora ele passa a ser alguém confiável.

Recebe missões importantes.

Pode liderar pequenas equipes.

É respeitado.

Em empresas seria o profissional pleno.

No Mainframe:

• desenvolve COBOL

• conhece VSAM

• entende Db2

• sabe trabalhar com CICS

Ainda consulta documentação.

Mas já entrega produção.

---

Rank B — O Especialista

Pouca gente chega aqui.

Agora o aventureiro possui:

• reputação

• fama

• dinheiro

• respeito

As pessoas conhecem seu nome.

É chamado para missões perigosas.

Pode ensinar iniciantes.

Em tecnologia seria:

Especialista.

É aquele profissional que todos procuram quando aparece um problema complicado.

---

Rank A — A Elite

Agora estamos falando de aventureiros que mudam guerras.

Eles enfrentam:

• dragões

• reis demônios

• calamidades

• monstros lendários

Governos pedem sua ajuda.

Reinos oferecem recompensas.

São poucos.

Muito poucos.

Na IBM seria alguém reconhecido internacionalmente.

---

Rank S — A Lenda

Esse é o rank mais famoso.

O curioso é que...

ele nem faz parte do alfabeto.

Depois do A...

vem o S.

Por quê?

Existem diversas teorias.

As mais conhecidas dizem que significa:

Special

Superior

Supreme

Super

Independentemente da origem, o Japão adotou o Rank S como:

"Acima do excelente."

São pessoas praticamente únicas.

---

Por que quase todos os animes usam letras?

Porque o cérebro entende letras instantaneamente.

Imagine duas situações.

Situação 1

Nível de combate:
785

Situação 2

Rank A

Qual delas comunica melhor?

A segunda.

Em menos de um segundo.

Isso é linguagem visual.

Os japoneses dominam isso como poucos.

---

A importância da Guilda

Outro detalhe importante.

Os ranks normalmente pertencem à Guilda.

Não ao personagem.

Isso significa que existe uma instituição responsável por avaliar todos.

É como:

OAB

CRM

IBM Certification

AWS

Microsoft

Cisco

A Guilda certifica.

O aventureiro representa.

---

Como alguém sobe de Rank?

Não basta dizer:

"Agora sou Rank A."

É preciso provar.

Normalmente envolve:

• quantidade de missões

• taxa de sucesso

• monstros derrotados

• comportamento

• liderança

• experiência

Perceba.

Força é apenas um dos critérios.

---

A psicologia da evolução

Existe um motivo pelo qual adoramos histórias assim.

Nosso cérebro ama progresso.

Toda vez que vemos:

Rank D

↓

Rank C

Sentimos satisfação.

Isso acontece porque percebemos evolução.

Os videogames exploram exatamente esse mecanismo.

XP.

Level.

Badges.

Achievements.

Tudo gira em torno da mesma ideia.

---

Quando aparecem os Ranks SS, SSS e EX

Muitos animes modernos resolveram exagerar.

Então surgiram:

SS

SSS

EX

Legend

Myth

God

Divine

Isso serve para mostrar personagens que estão muito acima da média.

Às vezes existe apenas uma pessoa no mundo inteiro com aquele título.

---

Existem animes sem ranks?

Sim.

E isso é interessante.

Obras como:

• Berserk

• Vinland Saga

• Monster

Não utilizam letras.

Mesmo assim existe hierarquia.

Ela apenas é construída pela narrativa.

Já nos isekais e RPGs, usar letras acelera a compreensão do espectador.

---

Alguns dos animes mais famosos que utilizam esse sistema

Praticamente virou um padrão do gênero.

Entre eles:

• Solo Leveling

• Overlord

• Goblin Slayer

• DanMachi

• Tsukimichi

• Arifureta

• The Rising of the Shield Hero

• Black Summoner

• Failure Frame

• I Parry Everything

• The Unwanted Undead Adventurer

• Infinite Dendrogram

• The Great Cleric

• Bofuri (para habilidades)

• Kuma Kuma Kuma Bear

• Boukensha ni Naritai

Cada um adapta o sistema às regras do seu universo, mas a lógica permanece a mesma.

---

A grande metáfora escondida

Na verdade...

esses ranks nunca falaram apenas de poder.

Eles falam sobre confiança.

Um aventureiro Rank A recebe missões importantes porque milhares de pessoas acreditam que ele será capaz de concluí-las.

No mundo corporativo acontece o mesmo.

Você não lidera um projeto crítico apenas porque sabe programar.

Você lidera porque demonstrou, ao longo do tempo, capacidade técnica, responsabilidade e maturidade.

---

O que isso ensina para um Programador COBOL Padawan?

Agora vem a parte mais divertida.

Imagine que o IBM Z também tivesse ranks oficiais.

🟢 Rank F — O recém-chegado

O Rank F costuma representar o nível mais baixo em alguns animes, mangás e RPGs, embora nem todos os universos o utilizem. Geralmente identifica aventureiros recém-registrados, sem experiência prática, equipamentos adequados ou feitos reconhecidos. 

Personagens nesse nível recebem missões simples, como coleta de ervas, entrega de itens ou eliminação de pequenos monstros. O objetivo é adquirir experiência, aprender trabalho em equipe e desenvolver habilidades básicas. 

Em muitos isekais, o protagonista começa no Rank F para evidenciar sua evolução ao longo da história. É a fase do aprendizado, onde persistência, disciplina e coragem valem mais do que força bruta.

---

🟢 Rank E — O Padawan

Você aprendeu:

• O que é um Mainframe

• Login no TSO

• Navegação no ISPF

• Criar um PDS

• Executar um JCL simples

Você ainda pergunta muito.

E isso é ótimo.

---

🔵 Rank D — O Desenvolvedor Júnior

Agora você:

• programa COBOL básico;

• entende COPYBOOKs;

• faz manutenção simples;

• lê mensagens do JES2;

• começa a entender ABENDs.

Já consegue contribuir em produção com supervisão.

---

🟡 Rank C — O Profissional Pleno

Neste ponto você domina:

• COBOL estruturado;

• JCL avançado;

• VSAM;

• Db2;

• CICS;

• SQL;

• controle de versões.

Você entrega funcionalidades completas e entende as regras de negócio.

---

🟠 Rank B — O Especialista

Agora você resolve problemas que poucos conseguem.

Conhece:

• IMS;

• MQ;

• RACF;

• SMF;

• RMF;

• Performance;

• tuning de SQL;

• integração com APIs;

• automação com Zowe e Ansible.

Quando ocorre um incidente crítico, seu telefone toca.

---

🔴 Rank A — O Arquiteto

Você não pensa apenas em programas.

Pensa em sistemas inteiros.

Decide arquiteturas.

Define padrões.

Mentora equipes.

Participa de modernizações e integrações com nuvem, DevOps e IA.

---

⭐ Rank S — A Lenda da Guilda

O Rank S não é apenas quem sabe mais comandos.

É quem inspira outros profissionais.

É o especialista que:

• resolve incidentes aparentemente impossíveis;

• conhece décadas de história do ambiente;

• entende profundamente regras de negócio;

• forma novos talentos;

• mantém sistemas que processam milhões de transações diárias sem falhas.

É o profissional cuja maior conquista não é um certificado, mas o respeito conquistado ao longo dos anos.

---

O verdadeiro significado da pirâmide

Quando olhamos novamente para aquela simples imagem de um anime, percebemos que ela representa muito mais do que níveis de força.

Ela fala sobre aprendizado contínuo, confiança, responsabilidade e evolução.

Nenhum protagonista começa no topo. Os heróis mais memoráveis tropeçam, erram, treinam e acumulam experiência antes de alcançar os maiores desafios. O mesmo vale para quem escolhe uma carreira em tecnologia.

No universo IBM Z, não existe magia que transforme um iniciante em especialista da noite para o dia. Cada programa compilado, cada ABEND investigado, cada JCL corrigido, cada consulta SQL otimizada e cada madrugada de suporte em produção acrescentam um pouco mais de experiência à sua jornada.

Essa talvez seja a maior lição escondida por trás dos ranks dos animes: o verdadeiro poder não está na letra que aparece ao lado do seu nome, mas na quantidade de conhecimento, disciplina e perseverança que foi necessária para conquistá-la.

Assim como os grandes protagonistas dos isekais, todo Programador COBOL Padawan começa no Rank E. E, com estudo constante, curiosidade e prática, pode um dia tornar-se uma verdadeira lenda da sua própria guilda tecnológica.

Teoria dos Jogos no Mainframe : Como um Programador COBOL Padawan Pode Aprender a Pensar Como um Estrategista

 

Bellacosa Mainframe e a teoria dos jogos no mainframe

☕ Um Café no Bellacosa Mainframe

Teoria dos Jogos no Mainframe

Como um Programador COBOL Padawan Pode Aprender a Pensar Como um Estrategista

"No mainframe, quase nenhum problema é apenas técnico. Quase todos envolvem pessoas tomando decisões."

Quando um desenvolvedor COBOL imagina Matemática aplicada ao desenvolvimento, normalmente pensa em algoritmos, estruturas de dados ou otimização.

Mas existe uma disciplina que explica boa parte dos conflitos encontrados diariamente dentro de um grande ambiente IBM Z:

A Teoria dos Jogos.

Não é sobre videogames.

É sobre entender como pessoas, equipes, empresas e até sistemas inteiros tomam decisões quando seus interesses dependem das escolhas dos outros.

E surpreendentemente...

Ela explica muito do que acontece dentro de um banco.

---

O que é Teoria dos Jogos?

A Teoria dos Jogos é um ramo da matemática aplicada que estuda situações onde vários participantes (chamados jogadores) precisam tomar decisões.

Cada decisão altera o resultado dos demais.

Ou seja...

Meu resultado depende da sua decisão.

E o seu depende da minha.

No mundo corporativo isso acontece o tempo inteiro.

No mainframe também.

---

Onde nasceu?

A origem moderna começa em 1944.

Dois pesquisadores publicaram um livro que mudou completamente Economia, Estratégia Militar e Ciência da Computação.

John von Neumann

Matemático brilhante.

Pai da arquitetura dos computadores modernos.

Participou do Projeto Manhattan.

Criou a primeira formulação matemática da Teoria dos Jogos.

---

Oskar Morgenstern

Economista.

Percebeu que economia não podia ser explicada apenas por oferta e demanda.

Era preciso considerar comportamento estratégico.

---

O livro histórico

Theory of Games and Economic Behavior (1944)

Foi um divisor de águas.

Mostrou que decisões racionais podem ser modeladas matematicamente.

Até hoje é considerado um dos livros mais importantes do século XX.

---

Depois veio John Nash

Se você assistiu ao filme Uma Mente Brilhante, conhece sua história.

John Nash revolucionou a área criando o conceito de:

Equilíbrio de Nash

É uma situação onde ninguém ganha mudando sua estratégia sozinho.

Todos ficam "presos" em uma decisão estável.

Isso acontece diariamente em TI.

---

Um exemplo no banco

Imagine duas equipes.

Equipe A deseja atualizar o sistema.

Equipe B deseja estabilidade.

Se A atualiza sem avisar...

B sofre.

Se B bloqueia todas as mudanças...

A nunca entrega inovação.

Ambas precisam cooperar.

Este é um jogo estratégico.

---

O famoso Dilema do Prisioneiro

É provavelmente o exemplo mais conhecido.

Dois suspeitos são presos.

Cada um pode:

• colaborar

• trair

O resultado depende da decisão dos dois.

Curiosamente...

Quando ambos tentam maximizar seu ganho individual...

Os dois acabam pior.

---

Isso acontece no Mainframe?

O tempo inteiro.

Exemplos:

• desenvolvimento versus operações

• aplicações versus infraestrutura

• segurança versus produtividade

• negócio versus tecnologia

• performance versus custo

• estabilidade versus inovação

Cada decisão influencia outra equipe.

---

Um Programador COBOL joga sem perceber

Imagine:

Você recebe uma alteração urgente.

Tem duas opções.

Estratégia A

Entregar rápido.

Maior risco.

---

Estratégia B

Testar corretamente.

Entrega mais lenta.

---

Agora imagine que o gestor mede apenas velocidade.

Naturalmente todos passam a entregar rápido.

Depois aparecem:

• incidentes

• rollback

• retrabalho

O sistema inteiro piora.

Foi um jogo mal desenhado.

---

Sistemas também jogam

Não apenas pessoas.

Diversos componentes competem por recursos.

Exemplos:

• CPU

• memória

• canais

• discos

• locks

• threads

• Db2

• CICS

• MQ

Todos disputam recursos limitados.

Isso lembra um enorme jogo cooperativo.

---

WLM é Teoria dos Jogos em ação

O Workload Manager não distribui CPU aleatoriamente.

Ele resolve conflitos.

Pergunta continuamente:

Quem precisa de mais recursos?

Quem pode esperar?

Quem possui maior prioridade?

É praticamente um árbitro estratégico.

---

Lock no Db2

Imagine dois programas.

Programa A bloqueia uma tabela.

Programa B espera.

Agora ambos aguardam recursos diferentes.

Nasce um deadlock.

O Db2 precisa decidir.

Quem perde?

Quem continua?

Existe estratégia envolvida.

---

Escalonamento Batch

No JES2 e nos schedulers acontece exatamente o mesmo.

Centenas de jobs.

Recursos limitados.

Dependências.

Janela batch.

Prioridades.

Cada decisão muda o resultado das demais.

---

Balanceamento de carga

No Sysplex:

várias LPARs compartilham carga.

Mover uma workload melhora um sistema...

mas pode piorar outro.

É otimização estratégica.

---

Segurança

Até segurança pode ser analisada pela Teoria dos Jogos.

O atacante escolhe:

• onde atacar

• quando atacar

• quanto investir

O defensor escolhe:

• onde proteger

• quanto monitorar

• quanto gastar

É um jogo contínuo.

---

IA também usa Teoria dos Jogos

Modelos modernos de IA utilizam conceitos relacionados em:

• aprendizado por reforço

• sistemas multiagentes

• negociação entre agentes

• coordenação

• planejamento estratégico

Cada agente toma decisões considerando os demais.

---

Grandes autores que vale conhecer

John von Neumann

Fundador da área.

---

Oskar Morgenstern

Aplicação econômica.

---

John Nash

Equilíbrio de Nash.

---

Thomas Schelling

Estratégia militar.

Conflitos.

Negociação.

Recebeu Nobel.

---

Robert Aumann

Jogos repetidos.

Cooperação.

Muito útil para organizações.

---

John Harsanyi

Jogos com informação incompleta.

Muito importante para segurança.

---

Lloyd Shapley

Valor de Shapley.

Como dividir benefícios em sistemas cooperativos.

Muito usado hoje em Inteligência Artificial.

---

Elinor Ostrom

Estudou cooperação em recursos compartilhados.

Suas ideias aparecem em computação distribuída.

---

Conceitos fundamentais

Todo Padawan deveria conhecer:

• jogadores

• estratégias

• payoff

• utilidade

• equilíbrio de Nash

• jogos cooperativos

• jogos não cooperativos

• jogos repetidos

• jogos simultâneos

• informação perfeita

• informação imperfeita

• dominância

• estratégia mista

• minimax

• soma zero

• soma não zero

Não precisa decorar fórmulas.

Entenda primeiro as ideias.

---

Como isso aparece no COBOL?

Mais do que parece.

Modelagem de regras

Quem ganha prioridade?

Quem espera?

Quem pode cancelar?

Tudo isso são decisões estratégicas.

---

Sistemas bancários

Fila de pagamentos.

Pix.

TED.

Cartões.

Empréstimos.

Todos possuem regras para resolver conflitos.

---

Controle de concorrência

Locks.

Timeout.

Retry.

Commit.

Rollback.

Tudo depende da estratégia adotada.

---

Escalabilidade

Quando dividir processamento?

Quando serializar?

Quando paralelizar?

Novamente...

Teoria dos Jogos.

---

Evolução da área

1944

Nascimento formal.

↓

1950

Equilíbrio de Nash.

↓

1970

Jogos evolucionários.

↓

1980

Aplicações em Computação.

↓

1990

Internet.

Redes.

Protocolos.

↓

2000

Segurança.

Mercados eletrônicos.

Cloud.

↓

2015+

Machine Learning.

IA.

Multiagentes.

Blockchain.

Robótica.

---

Como estudar?

Nível 1

Entenda lógica matemática.

Não precisa cálculo avançado.

---

Nível 2

Leia sobre:

• Dilema do Prisioneiro

• Equilíbrio de Nash

• Minimax

---

Nível 3

Estude algoritmos.

Pesquisa Operacional.

Otimização.

---

Nível 4

Veja aplicações em:

• IA

• Redes

• Segurança

• Economia

• Cloud

---

Nível 5

Passe a observar seu próprio ambiente de trabalho.

Você descobrirá jogos estratégicos em toda reunião.

---

Livros recomendados

Para iniciantes

• The Art of Strategy — Avinash Dixit e Barry Nalebuff.

• Thinking Strategically — Avinash Dixit e Barry Nalebuff.

Intermediário

• Game Theory: A Very Short Introduction — Ken Binmore.

Clássicos

• Theory of Games and Economic Behavior — John von Neumann e Oskar Morgenstern.

• Non-Cooperative Games — John Nash.

Aplicações

• The Evolution of Cooperation — Robert Axelrod.

• Micromotives and Macrobehavior — Thomas Schelling.

---

Aplicações diretas no IBM Z

Um profissional de Mainframe pode usar Teoria dos Jogos para:

• projetar regras de negócio mais robustas;

• definir prioridades no IBM Workload Manager (WLM);

• reduzir contenção de locks no Db2;

• modelar filas no IBM MQ;

• melhorar políticas de escalonamento em JES2 e schedulers;

• analisar conflitos entre aplicações Batch e Online (CICS);

• criar estratégias de segurança com RACF e gestão de privilégios;

• otimizar uso de CPU, memória e I/O entre LPARs;

• apoiar decisões de capacidade (Capacity Planning);

• compreender negociações entre equipes de desenvolvimento, operações e negócio.

O resultado é menos decisões baseadas em intuição e mais decisões baseadas em incentivos, equilíbrio e cooperação.

---

A Trilha Bellacosa para um Padawan COBOL

Uma boa jornada de estudos pode seguir esta sequência:

1. Lógica e Matemática Discreta.

2. Probabilidade e Estatística.

3. Teoria dos Jogos.

4. Pesquisa Operacional.

5. Algoritmos e Estruturas de Dados.

6. Sistemas Distribuídos.

7. Concorrência e Paralelismo.

8. WLM, JES2 e escalonamento no z/OS.

9. Db2: locking, isolamento e concorrência.

10. Inteligência Artificial, aprendizado por reforço e sistemas multiagentes.

Cada etapa amplia sua capacidade de entender não apenas como o sistema funciona, mas por que ele toma determinadas decisões.

---

Conclusão

Muitos acreditam que um excelente programador conhece apenas COBOL, JCL, CICS ou Db2.

Os grandes profissionais vão além.

Eles entendem comportamento.

Entendem incentivos.

Entendem conflitos.

Entendem cooperação.

No fim das contas, um sistema corporativo não é apenas código executando em um IBM Z.

É um enorme conjunto de pessoas, aplicações, recursos e decisões estratégicas interagindo o tempo todo.

Quem aprende Teoria dos Jogos deixa de enxergar apenas programas.

Passa a enxergar sistemas.

E esse é um dos maiores saltos que um Padawan pode dar rumo ao caminho de um verdadeiro Mestre Mainframe.

"No IBM Z, vencer não significa consumir toda a CPU. Significa encontrar o equilíbrio onde aplicações, equipes e negócios prosperam juntos. Essa é a verdadeira estratégia — e talvez o maior jogo de todos."

 

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade : Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

 

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:

1. Aprenda a arquitetura básica do z/OS.

2. Entenda o papel do CICS.

3. Estude a diferença entre TOR, AOR e FOR.

4. Aprenda como funciona o WLM.

5. Conheça o Db2 Data Sharing.

6. Estude VSAM RLS.

7. Entenda Syncpoint e Commit.

8. Aprenda conceitos de rollback e recuperação.

9. Descubra como funciona o Parallel Sysplex.

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