☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

domingo, 16 de dezembro de 2018

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron

Bellacosa Mainframe e o hacker ferris bueller em uma licao para red team

☕ Um Café no Bellacosa Mainframe — Especial Red Team

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron

🎬 Temporada de 12 artigos



1. Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e o princípio fundamental: não ataque a tecnologia; ataque as suposições de quem construiu o sistema.

Aqui apresentaríamos Red Team como mentalidade. Ferris observa pais, escola, diretor, horários, telefone, computador e comportamento humano. O verdadeiro exploit não está numa única máquina: está na combinação das peças.

https://eljefemidnightlunch.blogspot.com/2017/02/ferris-bueller-tinha-um-plano-de-ataque.html



2. Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Ferris, registros escolares, integridade de dados e o perigo de confiar cegamente naquilo que aparece na tela.

O artigo inspirado diretamente na famosa cena do computador. O diretor conhece Ferris pessoalmente, suspeita dele, quase pode sentir o cheiro da fraude — mas o sistema diz outra coisa.

Perfeito para falar de:

alteração de registros, privilégio excessivo, integridade, trilha de auditoria, insider threat e o princípio:

“Está no sistema” não significa “é verdade”.

 https://eljefemidnightlunch.blogspot.com/2017/03/nove-faltas-ctrlz-quando-o-banco-de.html



3. Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada, confiança contextual e como uma identidade falsa pode funcionar porque todos esperam que ela exista.

Esse pode ficar delicioso.

Ferris não precisa provar matematicamente que é Abe Froman. Ele precisa parecer suficientemente convincente durante tempo suficiente para atravessar o controle.

É praticamente:

Identity ≠ Authentication ≠ Authorization.

https://eljefemidnightlunch.blogspot.com/2017/05/abe-froman-o-rei-da-salsicha-de-chicago.html




4. “Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir
Como informação aparentemente inútil sobre pessoas, hábitos e organizações se transforma em superfície de ataque.

Aqui entra Recon.

Red Team não começa com nmap.

Começa perguntando:

Quem trabalha aqui?
Quem manda?
Quem confia em quem?
Como as pessoas falam?
Que sistemas utilizam?
Quando estão distraídas?

LinkedIn, GitHub, redes sociais, documentos públicos, metadata, vagas de emprego e até linguagem corporativa entram lindamente.

https://eljefemidnightlunch.blogspot.com/2017/06/voce-conhece-o-diretor-rooney-osint.html




5. Cameron, Atenda o Telefone — Social Engineering as a Service
Quando o atacante não trabalha sozinho e transforma pessoas legítimas em componentes involuntários do exploit.

Ferris usa Cameron como parte da infraestrutura.

E isso abre uma discussão maravilhosa:

Ferris → Cameron → Telefone → Escola → Funcionário → Sistema

Nenhum componente isoladamente é vulnerável.

A cadeia inteira é.

Swiss Cheese Model puro.

https://eljefemidnightlunch.blogspot.com/2018/01/cameron-atenda-o-telefone-social.html




6. O Diretor Rooney Está Procurando Malware no Lugar Errado
Por que organizações caçam invasores sofisticados enquanto o atacante entra pela recepção.

Rooney imagina Ferris fazendo alguma coisa mirabolante.

Ferris simplesmente manipula pessoas e processos.

É o clássico problema de segurança:

Firewall: US$ 500.000
SIEM: US$ 1.000.000
EDR: US$ 800.000
Zero Trust: US$ 2.000.000

Funcionário recebendo ligação:
— Sim senhor, posso alterar isso.

💀 GAME OVER.

https://eljefemidnightlunch.blogspot.com/2018/02/o-diretor-rooney-esta-procurando.html




7. A Ferrari do Cameron Não Tinha MFA
Privilégio, acesso físico e o perigo de acreditar que “ninguém jamais faria isso”.

A Ferrari vira nosso sistema crítico.

Não precisa ser literalmente roubada.

O problema é que o pai de Cameron criou um modelo de segurança baseado em:

medo + confiança + proibição.

Não em controle.

Excelente para falar de:

PAM, MFA, segregação de funções, least privilege, credenciais privilegiadas e controles compensatórios.

https://eljefemidnightlunch.blogspot.com/2017/07/a-ferrari-do-cameron-nao-tinha-mfa.html



8. Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
O glorioso momento em que alguém descobre que desfazer uma ação não significa desfazer suas consequências.

Este seria obrigatório. 😂

Tentam reverter a quilometragem colocando o carro em marcha a ré.

Metáfora perfeita para:

backup, restore, rollback, logs, journaling, Db2, VSAM, recuperação de transações e resposta a incidentes.

E a frase Bellacosa Mainframe:

“Produção não possui Ctrl+Z emocional.”

https://eljefemidnightlunch.blogspot.com/2017/08/colocamos-ferrari-em-re-por-que.html 




9. Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente
Tunnel vision, confirmation bias e o investigador que fica tão obcecado pelo atacante que começa a quebrar controles.

Aqui entraria seu universo recente de vieses cognitivos.

Rooney está tão convencido de que Ferris está fraudando tudo que começa a tomar decisões cada vez piores.

Perfeito para:

Confirmation Bias
Plan Continuation Bias
Sunk Cost Fallacy
Authority Gradient
Outcome Bias.

O defensor também pode ser explorado psicologicamente.

https://eljefemidnightlunch.blogspot.com/2017/09/rooney-invadiu-casa-errada-quando-o.html



10. FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos
O que acontece quando engenharia social, OSINT e automação encontram IA generativa.

Aqui a série pula brutalmente para 2026.

O Ferris de 1986 precisava:

telefonar, improvisar, conhecer pessoas e estudar o ambiente.

O Ferris de 2026 pode ter:

LLM, voice cloning, deepfake, agentes, scripts, OSINT automatizado, geração de phishing e análise de documentação.

A pergunta deixa de ser:

“Ferris conseguiria fazer isso hoje?”

E passa a ser:

“Quantos Ferris podem fazer isso simultaneamente?”

https://eljefemidnightlunch.blogspot.com/2017/10/ferrisgpt-agora-o-adolescente-tem-um.html





11. Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago
Como pensar Red Team em ambientes que não foram projetados com o atacante moderno como personagem principal.

Aqui entra pesado o Bellacosa Mainframe.

RACF
SAF
ACEE
APF
USS
TSO
JCL
CICS
Db2
MQ
z/OS Connect
Zowe
APIs
credenciais técnicas
service accounts.

E principalmente:

O mainframe pode ser extraordinariamente seguro e ainda assim estar ligado a cinquenta sistemas muito menos seguros.

O atacante talvez não ataque o z/OS.

Ele ataca o caminho até ele.

https://eljefemidnightlunch.blogspot.com/2017/11/ferris-entra-no-mainframe-racf-zos-e-o.html




12. “A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Por que o objetivo de um Red Team não é provar que o atacante é inteligente, mas descobrir aquilo que a organização ainda não sabe sobre si mesma.

Final mais filosófico.

Depois de 11 artigos fazendo bagunça, Ferris/Bellacosa fecha a temporada dizendo que Red Team não é sobre:

“HA! CONSEGUI INVADIR.”

É sobre transformar:

Ataque
   ↓
Descoberta
   ↓
Evidência
   ↓
Correção
   ↓
Detecção
   ↓
Aprendizado

https://eljefemidnightlunch.blogspot.com/2017/12/a-vida-passa-muito-rapido-o-red-team.html


E concluiríamos com algo bem Curtindo a Vida Adoidado:

Sistemas passam muito rápido. Se você não parar para observá-los de vez em quando, pode não perceber que alguém já encontrou um jeito de sair pela porta dos fundos. 

 


https://eljefemidnightlunch.blogspot.com/2018/12/ferris-buellers-red-team-como-hackear-o.html




☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Ferris Bueller’s Red Team

Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?

  • Red Team
  • OSINT
  • Engenharia Social
  • Blue Team
  • MFA
  • PAM
  • IA Generativa
  • RACF
  • z/OS
  • Mainframe
1

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.

Red Team • Recon • Threat Modeling • Criatividade Adversarial
2

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.

Integridade • Db2 • Auditoria • Insider Threat • Dados
3

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.

Engenharia Social • Pretexting • Identity • Authentication
4

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.

OSINT • Recon • LinkedIn • GitHub • Attack Surface
5

Cameron, Atenda o Telefone — Social Engineering as a Service

Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.

Social Engineering • Swiss Cheese Model • Human Risk
6

O Diretor Rooney Está Procurando Malware no Lugar Errado

Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.

SOC • SIEM • EDR • Zero Trust • Engenharia Social
7

A Ferrari do Cameron Não Tinha MFA

Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.

MFA • PAM • Least Privilege • Privileged Access
8

Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup

Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.

Backup • Restore • Rollback • Db2 • VSAM • Recovery
9

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.

Blue Team • SOC • Cognitive Bias • Incident Response
10

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT
11

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe
12

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.

Red Teaming • Purple Team • Detection • Resilience • Learning

🎬 Página principal da temporada

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.

☕ Acessar o especial completo SAVE FERRIS

Sobre a série SAVE FERRIS — Red Team

A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.

O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.

A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.

Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.

sábado, 15 de dezembro de 2018

IBM Mainframe Discovery : Capítulo XII — A Biblioteca Infinita da Galáxia

 

Bellacosa Mainframe apresenta ibm mainframe parte xii

☕ Um Café no Bellacosa Mainframe

Capítulo XII — A Biblioteca Infinita da Galáxia

Db2 for z/OS: Onde Bilhões de Histórias São Guardadas Sem Que Uma Única Página se Perca


NONA REGRA DOS GRANDES ARQUIVISTAS CÓSMICOS

Nunca pergunte:

"Onde está o dado?"

Pergunte:

"Como encontrá-lo antes que o Universo envelheça?"

Porque encontrar uma informação em uma tabela com dez registros é fácil.

Encontrar uma única linha entre:

  • cinquenta bilhões de registros;

  • milhares de tabelas;

  • centenas de aplicações;

  • milhões de usuários;

...é outra história completamente diferente.

Hoje visitaremos um dos lugares mais fascinantes de toda a Federação IBM Z.

A gigantesca Biblioteca Universal.

Seu nome é:

Db2 for z/OS.


A Biblioteca Que Nunca Fecha

Imagine uma biblioteca.

Não uma biblioteca comum.

Uma biblioteca planetária.

Ela possui:

  • todos os livros já escritos;

  • todos os jornais;

  • todos os registros médicos;

  • todos os contratos;

  • todas as contas bancárias;

  • todas as reservas de voos;

  • todas as apólices de seguro.

Agora imagine que milhões de leitores entram ao mesmo tempo.

Todos procuram livros diferentes.

Nenhum pode receber o livro errado.

Nenhum livro pode desaparecer.

Nenhuma página pode ser rasgada.

Esse é exatamente o problema que o Db2 resolve.


Antes dos Bancos de Dados

Voltemos algumas décadas.

Imagine um enorme arquivo de aço.

Milhões de pastas.

Um funcionário recebe um pedido.

Começa a procurar.

Corredor.

Prateleira.

Caixa.

Pasta.

Documento.

Enquanto isso...

cem outras pessoas aguardam.

Não escalava.


Então Surgiu Uma Pergunta

"E se existisse um bibliotecário capaz de encontrar qualquer livro em poucos milissegundos?"

Essa pergunta mudou a história da computação corporativa.


O Grande Bibliotecário

Imagine um senhor muito elegante.

Ele conhece absolutamente todos os livros.

Todas as estantes.

Todos os corredores.

Todos os atalhos.

Você apenas pergunta:

"Preciso deste documento."

Ele responde imediatamente:

"Corredor 217.

Estante 14.

Prateleira 3.

Livro 928."

Esse bibliotecário chama-se:

Otimizador SQL.


SQL Não É Mágica

Existe um mito curioso.

As pessoas acreditam que SQL conversa diretamente com o disco.

Na realidade...

SQL faz um pedido.

O Db2 decide como atendê-lo.

É uma diferença enorme.

Você diz:

SELECT *
FROM CLIENTES
WHERE CPF='12345678900'

Você nunca diz:

"Leia exatamente esta trilha do disco."

Quem escolhe isso é o Db2.


A Cidade das Tabelas

Imagine uma gigantesca cidade.

Cada prédio representa uma:

Tabela.

Dentro dela vivem milhões de moradores.

Cada apartamento representa um:

Registro.

Cada morador possui:

nome.

CPF.

telefone.

saldo.

endereço.

Tudo cuidadosamente organizado.


As Ruas da Cidade

Agora imagine tentar encontrar:

João da Silva.

Sem ruas.

Sem números.

Sem mapas.

Levaria dias.

Então alguém inventou:

Índices.


Os Índices — O Índice Remissivo da Galáxia

Pegue qualquer enciclopédia.

Ela possui um índice.

Você procura:

Saturno.

Vai diretamente à página.

Sem precisar ler mil páginas.

Os índices do Db2 fazem exatamente isso.

Segundo Wilhelm G. Spruth, os mecanismos de indexação são fundamentais para que o Db2 consiga localizar informações rapidamente sem percorrer tabelas inteiras sempre que isso não é necessário.


Nem Todo Livro Precisa Ser Aberto

Imagine um bibliotecário.

Alguém pergunta:

— Existe um livro chamado "COBOL"?

Ele consulta apenas o catálogo.

Nem precisa andar até a estante.

O Db2 faz isso milhares de vezes por segundo.


Pages — As Páginas do Livro

Agora chegamos a um conceito importante.

O Db2 não lê registros individualmente.

Ele trabalha com:

Pages.

Imagine um livro.

Você nunca pega apenas uma palavra.

Abre uma página inteira.

Depois outra.

Depois outra.

O banco faz exatamente isso.


Buffer Pool — A Mesa do Pesquisador

Imagine um pesquisador consultando livros.

Ele não devolve imediatamente cada volume.

Primeiro coloca tudo sobre sua mesa.

Assim evita caminhar até a biblioteca repetidamente.

Essa mesa chama-se:

Buffer Pool.

Quando uma página é utilizada frequentemente...

permanece ali.

Resultado?

Muito menos acesso ao disco.

Muito mais velocidade.


O Grande Armazém

Imagine um depósito gigantesco.

Ali ficam guardados milhões de livros.

Esse depósito representa os discos.

O Buffer Pool evita viagens desnecessárias.

Quanto melhor organizado...

mais rápido o pesquisador trabalha.


O Catálogo da Biblioteca

Agora imagine que existe um livro especial.

Ele contém informações sobre:

todos os livros.

todas as estantes.

todos os autores.

Esse livro chama-se:

Catálogo do Db2.

Ele descreve toda a estrutura do banco.

Sem ele...

o bibliotecário ficaria completamente perdido.


O Otimizador — O Mestre dos Caminhos

Agora imagine três rotas até o mesmo destino.

Uma possui trânsito.

Outra está interditada.

Outra está completamente livre.

Quem escolhe?

O GPS.

No Db2 esse GPS chama-se:

Optimizer.

Ele analisa dezenas de possibilidades antes de executar uma consulta.

Seu objetivo é encontrar o caminho mais eficiente.


RUNSTATS — O Recenseamento Galáctico

Mas como o GPS sabe qual estrada está congestionada?

Porque alguém faz estatísticas.

No Db2 esse trabalho chama-se:

RUNSTATS.

Imagine pesquisadores visitando cada bairro.

Eles contam:

moradores.

prédios.

ruas.

movimento.

Essas informações alimentam o Otimizador.

Sem estatísticas...

até o melhor GPS toma decisões ruins.


EXPLAIN — O Mapa da Expedição

Imagine pedir ao bibliotecário:

"Mostre exatamente como pretende encontrar meu livro."

Ele desenha um mapa.

Esse mapa chama-se:

EXPLAIN PLAN.

Todo Programador COBOL Padawan deveria aprender a lê-lo.

Porque ali está escondida boa parte da performance do sistema.


Locks — O Livro Não Pode Ser Rasgado

Agora imagine dois pesquisadores.

Ambos querem editar exatamente a mesma página.

Ao mesmo tempo.

O resultado seria um desastre.

Então surge outro personagem.

O:

Lock Manager.

Ele organiza quem pode modificar determinado dado.

Enquanto um escreve...

os demais aguardam.


Commit — O Carimbo Oficial

Imagine um cartório.

Você assina um documento.

Mas ele só passa a existir oficialmente depois do carimbo.

No Db2 esse carimbo chama-se:

COMMIT.

Até esse momento...

a transação ainda pode voltar atrás.


Rollback — A Máquina do Tempo

Agora imagine que alguém percebe um erro.

Antes do carimbo.

Tudo pode ser desfeito.

Esse mecanismo chama-se:

ROLLBACK.

É como voltar alguns minutos no tempo.


O Diário da Biblioteca

Imagine um bibliotecário anotando absolutamente tudo.

Quem entrou.

Quem saiu.

Quem retirou livros.

Quem devolveu.

Esse diário chama-se:

Log.

Ele registra todas as alterações.

Graças a ele...

o Db2 consegue recuperar informações após falhas.


Recovery — Reconstruindo a Biblioteca

Imagine um meteoro atingindo parte da biblioteca.

Os livros desapareceram.

Fim da história?

Não.

Graças aos Logs e aos Backups, o Db2 pode reconstruir o estado correto dos dados, preservando a integridade das transações.

É um dos pilares da confiabilidade da plataforma.


Data Sharing — Vários Bibliotecários, Uma Biblioteca

Lembra do Parallel Sysplex?

Agora imagine cinco bibliotecários.

Todos consultam exatamente os mesmos livros.

Sem discutir.

Sem criar cópias diferentes.

Esse recurso chama-se:

Db2 Data Sharing.

Ele permite que múltiplas instâncias do Db2 compartilhem os mesmos dados em um ambiente Parallel Sysplex, aumentando escalabilidade e disponibilidade.


O Db2 Nunca Trabalha Sozinho

Curiosamente...

o Db2 raramente aparece sozinho.

Ele conversa continuamente com:

CICS.

IMS.

MQ.

COBOL.

Java.

Python.

REST APIs.

z/OS Connect.

Linux.

OpenShift.

É como a grande biblioteca central da Federação.

Todos passam por ela.


O Que Mudou Desde 2010?

Desde que Spruth publicou seu relatório...

o Db2 evoluiu extraordinariamente.

Hoje encontramos:

  • SQL muito mais inteligente;

  • Compressão avançada;

  • Criptografia transparente;

  • Aceleração analítica;

  • Machine Learning para otimização;

  • Integração com Apache Spark;

  • Hybrid Transaction & Analytics;

  • Pesquisa Vetorial;

  • Busca Híbrida com OpenSearch;

  • IA Generativa utilizando dados corporativos.

O curioso?

A filosofia continua idêntica.

Guardar conhecimento.

Encontrá-lo rapidamente.

Nunca perdê-lo.


Uma Lição Para Além da Tecnologia

Existe uma reflexão escondida neste capítulo.

Conhecimento não vale apenas porque existe.

Vale porque conseguimos encontrá-lo quando precisamos.

O mesmo acontece conosco.

Livros esquecidos em uma estante ajudam pouco.

Conhecimento organizado transforma civilizações.

Talvez seja por isso que bancos de dados e bibliotecas tenham algo em comum.

Ambos preservam a memória coletiva.


Curiosidades do Diário de Bordo

📚 O Db2 for z/OS processa diariamente bilhões de transações em algumas das maiores instituições financeiras do planeta.

🚀 O Otimizador SQL pode analisar inúmeras estratégias diferentes antes de escolher o plano de execução mais eficiente.

🛰️ Buffer Pools reduzem drasticamente o acesso ao disco, mantendo páginas frequentemente utilizadas em memória.

🌌 O Data Sharing permite que múltiplos sistemas IBM Z compartilhem a mesma base de dados mantendo consistência e alta disponibilidade.


Diário de Bordo do Padawan COBOL

Antes de deixar a Biblioteca Infinita da Federação, registre estas coordenadas no seu Holocron Técnico:

✅ O Db2 é muito mais do que um banco de dados; ele é o guardião da memória corporativa.

✅ Índices, Buffer Pools e o Otimizador trabalham juntos para transformar bilhões de registros em respostas obtidas em milissegundos.

✅ COMMIT, ROLLBACK e Logs garantem que a integridade dos dados seja preservada mesmo diante de falhas.

✅ O verdadeiro poder do Db2 não está apenas em armazenar informações, mas em permitir que toda a galáxia corporativa encontre exatamente o dado certo, no instante certo, com absoluta confiança.


Missão Seguinte

No próximo capítulo deixaremos a Biblioteca Galáctica para explorar uma vasta Rede de Comunicações Interestelares: IBM MQ e os sistemas de mensageria.

Descobriremos por que mensagens viajam com muito mais segurança do que chamadas diretas, como filas evitam o caos entre civilizações digitais e por que o IBM MQ se tornou o serviço postal da galáxia corporativa, entregando bilhões de mensagens por dia sem perder uma única encomenda.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

Capítulo V — A Frota Invisível do Transporte Interestelar

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

Abrir artigo

sexta-feira, 14 de dezembro de 2018

🔥 CICS TS 5.5 — O CICS que Chegou para Misturar Linguagens, Node.js e APIs Modernas

 

Bellacosa Mainframe anuncia o CICS 5.5

🔥 CICS TS 5.5 — O CICS que Chegou para Misturar Linguagens, Node.js e APIs Modernas



☕ Midnight Lunch em dezembro de 2018 — a versão que virou referência

Se o CICS TS 5.4 trouxe suporte sólido a Java EE e APIs assíncronas, o CICS TS 5.5 fez algo maior: converteu o CICS em uma plataforma verdadeiramente mixed-language, oficialmente abrindo as portas não só para Java, mas também para Node.js, GraphQL, segurança forte, melhores ferramentas de gestão e integração com o mundo moderno.

📌 Em 2018, o CICS deixou de ser “servidor transacional legado” e virou hub de aplicações corporativas modernas.


📅 Datas de marca

📌 Data de Lançamento (GA): dezembro de 2018
📌 Fim de Vida (EOS): CICS TS 5.5 já passou por ciclos de suporte padrão e hoje muitos sites operam em versões posteriores (5.6, 6.x).

💬 Bellacosa comenta:

“5.5 é o release que diz ‘vem com tudo’ para linguagens que não sejam só COBOL e Java — e ele não disse isso timidamente.”


CICS 5.5

🆕 O que há de novo nas entranhas do CICS 5.5

🟡 Suporte oficial a Node.js

Agora o CICS pode hospedar aplicações Node.js diretamente — sem encanação, sem plugin extra — abrindo caminho para arquiteturas full stack modernas rodando no mainframe.
💬 Bellacosa:

“Antes era Java, depois era JSON… agora é asynchronous JavaScript you can call from TN3270 to Web.”


🟡 Enhancements no CICS Explorer

O CICS Explorer ficou ainda mais capaz e produtivo, com visualizações ampliadas, melhores gráficos de dependências e interfaces que facilitam desde a configuração até a análise de métricas.
📌 Uma IDE CICS amigável que reduz aquele medo clássico do terminal 3270.


🟡 GraphQL API integrado

Uma API moderna que permite consultar relações de recursos CICS — ícones, vínculos de workload, Estados de containers, topologia — com consultas expressivas e instantâneas.
🐣 Easteregg: GraphQL no mainframe? Parece coisa da nuvem… mas é real e é útil aqui!


🟡 Segurança reforçada

✔ Default mínimo TLS elevado para 1.2
✔ Keyrings compartilháveis entre regiões
✔ Novos parâmetros de senha e phrases
✔ Suporte SNI em conexões HTTP
💬 Bellacosa:

“Segurança hoje não é detalhe — é exigência regulatória e 5.5 entendeu isso.”


🟡 Desempenho e Performance

✔ Acesso threadsafe às tabelas de coupling facility
✔ Buffers 64-bit para clientes web
✔ CICS-MQ bridge e trigger monitor melhorados
📌 Performance não é só mais rápido — é mais estável, resiliente e observável.


🟡 Linguagens & Runtime Modernos

✔ Node.js
✔ Java EE 8 / Jakarta EE
✔ Spring Boot chamável via LINK
✔ Mapas e containers exploráveis por EXCI
💬 Bellacosa comenta:

“Aqui o mainframe diz: ‘Scripts também têm lugar na festa’.”


🧠 Melhoria contínua e APARs

O CICS TS 5.5 também coleta APARs de entrega contínua, incluindo melhorias em:

  • JWT e OpenID Connect (OIDC) no Liberty JVM server

  • XML e JSON mapping levels avançados

  • Enhanced policy rule types

  • Db2 thread management

  • GraphQL, enhanced inter-resource relationships

Esses ajustes mostram uma filosofia de evolução sem precisar esperar uma nova major release.


🧠 Curiosidades e Eastereggs Bellacosa

🍺 Compuware e suporte Day One — ferramentas como CAFC deram suporte já no dia do lançamento, o que é sinal claro de parceria e maturidade do ecossistema.
🍺 Node.js e CICS — você pode ter aplicações JS servindo dados corporativos direto do mainframe.
🍺 GraphQL — no universo tradicional, consultas eram pesadas e verbosas; aqui são expressivas e rápidas.


🧪 Exemplo prático — “O Portal que Nasceu no Mainframe”

Uma empresa de seguros tinha:

  • Back-end em COBOL + DB2

  • APIs REST servindo clientes móveis

  • Uma camada Web pesada em Linux

Trasnformação com CICS TS 5.5:

  1. Subiram serviços Node.js rodando em CICS

  2. Configuraram GraphQL para consultar recursos e estados

  3. Integraram APIs modernas com JSON direto dos programas tradicionais

  4. Liberaram dashboards internos sem precisar de middlewares extras

💬 Bellacosa resume:

“De servidor transacional para hub de APIs e serviços mistos — tudo em uma só plataforma.”


🧠 Dicas Bellacosa para Explorar o 5.5

✔ Aproveite Node.js para novas aplicações sem descartar legado.
✔ Amarre GraphQL para inspeções profundas de recursos.
✔ Reforçe TLS, criptografia e keyrings compartilháveis para segurança corporativa.
✔ Use CICS Explorer e atualize para as versões mais novas para visualizar métricas completas.


🎯 Conclusão Bellacosa

CICS TS 5.5 não foi apenas um release.
Foi o ponto onde o mainframe se rebelou contra a estagnação e gritou: “Eu sou moderno, escalável, seguro e ágil!”

✔ Node.js prático
✔ GraphQL explorável
✔ JVM / Java EE atualizado
✔ Segurança reforçada
✔ APIs modernas

🔥 5.5 é o CICS que prova — transacional e moderno podem andar de mãos dadas.

quinta-feira, 13 de dezembro de 2018

O Caso do Registro que Não Podia Ser Tocando : Quando um Jovem Programador COBOL Descobriu que Dois Usuários Podiam Roubar Dinheiro Sem Serem Ladrões

 

Bellacosa Mainframe e o caso do registro que nao podia ser tocando

☕ Um Café no Bellacosa Mainframe

O Caso do Registro que Não Podia Ser Tocando

Quando um Jovem Programador COBOL Descobriu que Dois Usuários Podiam Roubar Dinheiro Sem Serem Ladrões

"Existem crimes que deixam impressões digitais. Outros deixam apenas inconsistências no VSAM."


A chuva caía sobre o Centro de Processamento de Dados.

As luzes verdes do IBM Z piscavam lentamente, como se respirassem na escuridão.

Era quase meia-noite.

No monitor 3270, uma única mensagem chamava a atenção do jovem programador COBOL.

RESP = 14

Nenhum ABEND.

Nenhum dump.

Nenhum S0C7.

Nenhum S0C4.

Apenas um simples código de retorno.

Mas, como todo bom investigador sabe, às vezes o menor detalhe esconde o maior dos mistérios.

Foi então que o velho administrador de CICS aproximou-se segurando uma caneca de café.

Sem olhar para o monitor, apenas perguntou:

— Você tentou fazer REWRITE sem entender quem estava segurando a chave do cofre?

O rapaz respondeu:

— Eu só queria alterar um telefone...

O veterano sorriu.

— É exatamente assim que começam todos os grandes mistérios do CICS.

Hoje vamos investigar um dos mecanismos mais importantes de toda a arquitetura CICS: READ UPDATE e REWRITE, dois comandos aparentemente simples, mas responsáveis por proteger bilhões de registros VSAM diariamente em bancos, seguradoras, bolsas de valores, companhias aéreas e órgãos governamentais.

Prepare seu café.

Acenda a luminária verde da mesa.

Porque esta investigação vai muito além de um simples comando COBOL.


O verdadeiro problema nunca foi gravar um registro

Todo programador iniciante pensa assim:

"Quero alterar um cliente."

Então imagina algo parecido com:

Ler

↓

Modificar

↓

Gravar

Parece simples.

E realmente seria...

...se apenas uma pessoa utilizasse o sistema.

Mas o CICS nasceu para outro mundo.

Um mundo onde milhares de pessoas utilizam o mesmo arquivo ao mesmo tempo.

Imagine um banco.

Enquanto você lê este artigo...

Milhares de clientes estão:

  • pagando boletos;

  • transferindo PIX;

  • alterando endereço;

  • consultando saldo;

  • contratando empréstimos;

  • desbloqueando cartão.

Tudo isso pode atingir exatamente o mesmo registro VSAM.

Agora surge a pergunta que assombra arquitetos desde os anos 1970:

Quem ganha quando duas pessoas querem alterar o mesmo registro ao mesmo tempo?


O nascimento do maior vilão dos sistemas online

Seu nome é:

Lost Update

Ele não gera ABEND.

Não trava o CICS.

Não derruba o sistema.

Pior.

Ele produz dados errados.

Imagine o seguinte registro.

Cliente

Saldo

R$ 1.000,00

Agora entram dois caixas.

Caixa A deposita:

+R$ 100,00

Caixa B faz um saque.

-R$ 200,00

Os dois executam:

READ

Ambos recebem:

R$ 1.000,00

Caixa A calcula:

1.100

Grava.

Logo depois...

Caixa B calcula:

800

Também grava.

Resultado final:

R$ 800,00

Mas espere.

O correto seria:

R$ 900,00

Onde desapareceram os R$ 100,00?

Ninguém roubou.

Ninguém fraudou.

Nenhum operador errou.

Foi apenas um clássico caso de Lost Update, um problema de concorrência em que uma atualização sobrescreve a outra por ambas terem partido de uma mesma versão antiga do registro.

É exatamente para impedir esse tipo de situação que o CICS criou um dos mecanismos mais elegantes da computação transacional.


A filosofia do READ UPDATE

Muitos iniciantes acreditam que UPDATE significa:

"Atualize o registro."

Na verdade...

Não.

O UPDATE não grava absolutamente nada.

Ele apenas comunica ao CICS:

"Vou precisar modificar este registro. Reserve-o para mim."

É quase como chegar à biblioteca e colocar um marcador sobre um livro dizendo:

"Estou usando."

Enquanto esse marcador existir...

Ninguém mais pode pegar aquele livro.

No CICS acontece exatamente isso.

EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-CHAVE)
     INTO(WS-REGISTRO)
     UPDATE
END-EXEC

Observe.

Não houve alteração alguma.

O registro continua exatamente igual.

A única diferença é invisível.

Agora existe um cadeado.

Registro Cliente

──────────────

Saldo

Telefone

Endereço

──────────────

🔒

Esse pequeno cadeado é um dos maiores responsáveis pela confiabilidade dos sistemas bancários modernos.


O cadeado invisível

Esse bloqueio é chamado de lock exclusivo.

Enquanto ele existir:

✔ outro programa pode consultar outros registros;

✔ outras transações continuam funcionando normalmente;

✔ outros clientes continuam utilizando o banco.

Mas aquele registro...

Aquele especificamente...

Pertence temporariamente à sua transação.

É como um investigador isolando a cena do crime.

Até que a perícia termine...

Ninguém entra.


O segundo investigador chega

Imagine agora.

Programa A faz:

READ UPDATE

Registro bloqueado.

Cinco milissegundos depois...

Programa B também tenta atualizar o mesmo cliente.

READ UPDATE

O que acontece?

O CICS responde algo semelhante a:

RESP = 14

Registro bloqueado.

Dependendo da configuração da aplicação, a segunda transação poderá:

  • aguardar a liberação do lock;

  • receber imediatamente a indicação de bloqueio;

  • ou seguir outra estratégia definida pelo sistema.

Perceba a genialidade.

O CICS prefere atrasar uma operação por alguns milissegundos a permitir corrupção dos dados.


REWRITE: a hora da verdade

Depois de alterar a Working-Storage...

Chega o momento mais importante.

EXEC CICS REWRITE
     FILE('CLIENTE')
     FROM(WS-REG)
END-EXEC

Agora sim.

O VSAM grava novamente o registro.

Muitos iniciantes perguntam:

"Ele grava somente o telefone?"

Não.

O REWRITE grava o registro inteiro.

Mesmo que apenas um campo tenha mudado.

Imagine um cadastro.

Nome

CPF

Telefone

Cidade

Saldo

Limite

Nascimento

Endereço

Estado Civil

Você modifica somente:

Telefone

Mesmo assim...

Todo o registro volta ao disco.

Isso acontece porque o VSAM trabalha com registros completos, e o REWRITE substitui a imagem inteira do registro originalmente lido.


O segredo da chave imutável

Existe uma regra quase sagrada.

O REWRITE mantém a mesma chave do registro.

Você pode alterar:

  • telefone;

  • saldo;

  • limite;

  • endereço;

  • e-mail;

  • profissão.

Mas não pode alterar a chave primária.

Se precisar mudar a chave...

O caminho normalmente envolve excluir o registro antigo e gravar outro com a nova chave.

É uma mudança de identidade.

E identidades novas exigem um novo registro.


A importância do COMMIT

Um detalhe frequentemente esquecido pelos iniciantes é imaginar que o REWRITE já libera o registro.

Nem sempre.

Enquanto a unidade lógica de trabalho não termina, o lock pode continuar ativo.

É por isso que o fluxo clássico é:

READ UPDATE

↓

Modificar memória

↓

REWRITE

↓

SYNCPOINT (COMMIT)

↓

Lock liberado

O COMMIT confirma a alteração e encerra aquela etapa da transação.

Se ocorrer um erro antes disso, o sistema pode desfazer a operação, preservando a consistência dos dados.


O perigo dos formulários longos

Imagine esta situação.

Você faz:

READ UPDATE

Depois envia uma tela.

O usuário vai atender o telefone.

Conversar.

Tomar café.

Voltar vinte minutos depois.

Só então pressiona ENTER.

Durante todo esse tempo...

O registro permaneceu bloqueado.

Resultado?

Filas.

Esperas.

Outros usuários impedidos de alterar aquele mesmo cliente.

Por isso existe uma regra de ouro no desenvolvimento CICS:

Nunca mantenha um lock por mais tempo do que o estritamente necessário.

Uma estratégia comum é:

  1. Fazer um READ simples para exibir os dados.

  2. Receber as alterações do usuário.

  3. Executar um READ UPDATE pouco antes da gravação.

  4. Validar novamente.

  5. Fazer o REWRITE.

  6. Finalizar a unidade de trabalho.

Assim, o bloqueio dura apenas alguns milissegundos.


RESP e RESP2: os investigadores silenciosos

Nunca ignore os códigos de retorno.

Um programa robusto verifica cuidadosamente o resultado de cada comando CICS.

Alguns exemplos comuns:

RESPSignificado
00Operação realizada com sucesso
02Registro não encontrado
14Registro bloqueado
20Arquivo ou recurso não encontrado
30Requisição inválida
91Atualização não concluída; investigar a causa

Quando disponível, RESP2 complementa o diagnóstico, fornecendo informações adicionais específicas sobre a condição encontrada.

Um bom programador COBOL não apenas trata o erro; ele entende por que ele ocorreu.


Curiosidade: por que não existe UPDATE como no SQL?

Quem vem do mundo relacional estranha.

No SQL basta escrever:

UPDATE CLIENTE
SET TELEFONE = '11999999999'
WHERE ID = 100;

No VSAM, a lógica é diferente.

Primeiro você obtém o registro.

Depois altera sua cópia em memória.

Só então grava o registro inteiro novamente.

Essa diferença vem da própria natureza do VSAM, que trabalha com registros físicos completos, enquanto o banco de dados relacional manipula colunas e linhas sob um mecanismo diferente de armazenamento.


Curiosidade histórica

Os conceitos por trás de READ UPDATE e REWRITE surgiram muito antes da popularização da internet.

Décadas antes de existirem smartphones, APIs REST ou microsserviços, grandes bancos já processavam milhões de transações simultâneas graças a mecanismos sofisticados de bloqueio, sincronização e recuperação.

Grande parte dessas ideias continua válida até hoje.

Muitas tecnologias modernas reinventaram princípios que os mainframes já utilizavam há décadas.


Passo a passo para atualizar um registro com segurança

Um fluxo típico em uma aplicação COBOL/CICS pode ser resumido assim:

  1. Receber a chave do registro.

  2. Executar READ UPDATE.

  3. Verificar RESP e, quando aplicável, RESP2.

  4. Alterar apenas os campos necessários na Working-Storage.

  5. Executar REWRITE.

  6. Confirmar a unidade lógica de trabalho (SYNCPOINT) ou realizar rollback em caso de falha.

  7. Encerrar a transação.

Parece simples.

E realmente é.

A dificuldade não está na sequência.

Está em compreender por que ela existe.


Dicas de ouro para quem está aprendendo CICS

✔ Nunca execute REWRITE sem um READ UPDATE bem-sucedido.

✔ Mantenha o tempo de bloqueio o menor possível.

✔ Sempre trate RESP e RESP2.

✔ Não altere a chave do registro antes do REWRITE.

✔ Pense em concorrência desde o primeiro programa que escrever.

✔ Lembre-se de que o usuário nunca está sozinho no sistema.

✔ Teste cenários com duas transações tentando atualizar o mesmo registro.

Esses testes ensinam mais sobre CICS do que centenas de exemplos puramente teóricos.


Easter Egg Bellacosa Mainframe 🕵️

Os veteranos do CPD contam uma velha história.

Durante uma madrugada de processamento, um programador jurava que o VSAM "perdia dinheiro".

Após horas analisando dumps, SMF e logs do CICS, nada parecia explicar o problema.

Foi então que um analista aposentado, conhecido apenas como O Guardião do 3270, pediu para ver apenas uma linha do código.

Ali estava:

EXEC CICS READ

Sem a palavra:

UPDATE

O veterano fechou o terminal, tomou um gole de café e disse:

— "O culpado nunca foi o VSAM. O registro estava falando com duas pessoas ao mesmo tempo."

Dizem que, desde então, quem programa CICS nas madrugadas presta mais atenção aos quatro caracteres que mudam completamente o destino de uma transação:

UPDATE


O verdadeiro mistério nunca esteve no REWRITE

Ao final desta investigação, descobrimos que o REWRITE não é o protagonista.

Ele apenas grava o resultado.

O verdadeiro herói é o READ UPDATE, que protege o registro enquanto a alteração está sendo preparada.

É ele quem impede que duas transações sobrescrevam o trabalho uma da outra.

É ele quem preserva a integridade dos dados.

É ele quem garante que milhões de operações bancárias possam acontecer simultaneamente com segurança.

Na superfície, parecem apenas dois comandos COBOL.

Nas sombras do CPD, porém, eles são os guardiões silenciosos da consistência, da concorrência e da confiança que sustentam alguns dos sistemas mais críticos do planeta.

E, como em toda boa revista noir dos anos 1950, o maior mistério nunca foi quem escreveu o código.

Foi descobrir quem estava segurando a chave do cofre quando ninguém mais podia tocá-lo.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...