Translate

terça-feira, 6 de abril de 2021

☕💥 A Jornada do Sysprog Padawan – SAF : Performance, CPU, Memória e Escalabilidade - Parte IV

 

Bellacosa Mainframe apresenta o saf parte IV

☕💥 A Jornada do Sysprog Padawan – Parte 4

SAF – Performance, CPU, Memória e Escalabilidade

Quanto custa uma chamada SAF? Como bancos executam bilhões de autorizações por dia?

"No Reino IBM Z, a melhor autorização é aquela que acontece tão rápido que ninguém percebe que aconteceu."

Bellacosa Mainframe


Introdução

Nas partes anteriores descobrimos:

  • O que é SAF

  • Sua anatomia interna

  • Como funciona no TSO, CICS, IMS, MQ, DB2, USS e JES2

Agora chegamos ao território favorito dos Sysprogs:

Performance

CPU.

Memória.

Escalabilidade.

Throughput.


A pergunta que todo gerente faz

Quanto custa o SAF?


Resposta curta.

Muito pouco.


Resposta de Sysprog.

Depende.


O problema que a IBM resolveu

Imagine.

Banco.

50 CICS.

3 IMS.

2 DB2.

JES.

VTAM.


Sem SAF.

Cada produto.

Implementaria.

Autorização.

Própria.


Duplicação.

CPU.

I/O.

Complexidade.


Com SAF.

Uma arquitetura.

Centralizada.


Muito mais eficiente.


O custo de uma chamada

VERIFY

Mais cara.


Cria.

ACEE.


Consulta.

RACF.


Perfis.


MFA.


Certificados.


Passphrase.


OMVS.


Labels.


AUTH

Médio.


Verifica.

Permissões.


Classe.

Perfil.


Pode utilizar.

Cache.


FASTAUTH

Nosso campeão.


Baixíssimo.

Consumo.


Poucos ciclos.

CPU.


Muito utilizado.

Em alto volume.


Exemplo

CICS.

100 mil TPS.


Sem FASTAUTH.

CPU sobe.


Com FASTAUTH.

Sistema.

Voa.


Onde SAF economiza?

I/O

Grande benefício.


Sem SAF.

Mais consultas.


Com SAF.

Mais cache.


Menos disco.


Locks

Menos.

Contention.


Menos.

ENQ.


Melhor.

Escalabilidade.


ACEE

Nosso herói.


Evita.

Consultar.

RACF.

Toda hora.


Exemplo simplificado

Sem ACEE.

10 milhões AUTH

↓

10 milhões RACF

Com ACEE.

10 milhões AUTH

↓

1 VERIFY

↓

9.999.999 ACEE

Economia.

Enorme.


Memória

Pouco impacto.


Buffers.


Contextos.


Caches.


Tabelas.


Insignificante.

Para z16.

z17.


O segredo

IBM prefere.

Memória.


IBM odeia.

I/O.


SAF segue.

Essa filosofia.


O SAF possui cache?

Sim.


ESM.

Pode utilizar.

Caches.


FASTAUTH.

Ajuda.

Muito.


Grandes bancos

Possuem.

Bilhões.

De verificações.


Por dia.


Mesmo assim.

CPU.

Permanece.

Baixa.


Porque.

SAF.

É extremamente.

Otimizado.


O impacto no CICS

Sem SAF.


Cada.

Transação.

Consultaria.

RACF.


Impossível.


Com SAF.


FASTAUTH.


ACEE.


Cache.


Resultado.

Excelente.


MQ

MQOPEN.


MQGET.


MQPUT.


FASTAUTH.

É praticamente.

Obrigatório.


DB2

SQL.


Permissões.


Plan.


Package.


DSNR.


Tudo.

Muito rápido.


USS

SSH.


Git.


Python.


Zowe.


Ansible.


OpenSSH.


Utilizam.

VERIFY.


AUTH.


Sem problemas.

De escala.


O que degrada performance?

Muitas verificações VERIFY


Criações.

Excessivas.

ACEE.


Muitas falhas

RC=8.


Negações.


Perfis.

Complexos.


Certificados.

Demais.


Labels.

Complexos.


Como medir?

RMF.


SMF.


SMF80.


SMF30.


OMEGAMON.


zSecure.


Security Monitor.


Métricas interessantes

VERIFY.

Rate.


AUTH.

Rate.


FASTAUTH.

Hits.


Cache.

Misses.


RC.


Falhas.


Sysplex

Curiosidade.


SAF.

Existe.

Em cada.

LPAR.


Não é.

Compartilhado.


Por design.


Mais seguro.


Mais rápido.


O custo real

Normalmente.

Muito.

Menor.

Do que.

As pessoas.

Imaginam.


O maior.

Consumidor.

Geralmente.

Não é.

SAF.


São.

Aplicações.

Mal projetadas.


Dicas Bellacosa

Evite.

VERIFY.

Desnecessário.


Use.

FASTAUTH.


Monitore.

SMF80.


Estude.

ACEE.


Revise.

Classes.


Observe.

Negações.


Menos.

RC=8.

Melhor.

Performance.


Easter Egg Bellacosa ☕

Imagine.

Um castelo.

Com.

100 mil.

Visitantes.

Por hora.


Sem SAF.

Todos.

Correm.

Para o cartório.


Caos.


Com SAF.

O porteiro.

Olha.

O crachá.


Libera.

Em segundos.


Cartório.

Descansa.


CPU.

Descansa.


Sysprog.

Toma café.


Curiosidade Histórica

Provavelmente.

O SAF.

Já economizou.

Trilhões.

De instruções.

CPU.


Desde.

OS390.

Até.

zOS 3.1.


Talvez.

Seja.

Uma das.

Rotinas.

Mais utilizadas.

Da história.

Do IBM Z.


Checklist do Sysprog Jedi

Monitorar.

SMF80.


Analisar.

FASTAUTH.


Evitar.

VERIFY.

Em excesso.


Entender.

ACEE.


Revisar.

Classes.


Auditar.

Negações.


Conhecer.

RMF.


Utilizar.

zSecure.


Como impressionar um Security Architect

Diga:

O SAF é uma infraestrutura de autorização altamente otimizada, orientada a ACEEs e FASTAUTH, projetada para minimizar I/O, reduzir contenção e sustentar bilhões de decisões de segurança diárias em ambientes de missão crítica.

Provavelmente.

A entrevista.

Mudará.

De nível.


Frase Bellacosa Mainframe

"O RACF decide. O ACEE lembra. O SMF registra. Mas é o SAF que trabalha silenciosamente bilhões de vezes por dia para que ninguém perceba que a segurança está funcionando perfeitamente."


☕💥 Continua na Parte 5

SAF – Troubleshooting, ICH408I, RC=8, IPCS, Dumps, SMF80, zSecure e Como Encontrar o Verdadeiro Culpado às 3h da Manhã Quando Todo Mundo Está Culpando o RACF.


segunda-feira, 5 de abril de 2021

🧠 Guia dos arquétipos de personalidade em animes japoneses

 

Bellacosa Mainframe em uma analise dos arquetipos femininos dos animes

🧠 Guia dos arquétipos de personalidade em animes japoneses

Os japoneses adoram classificar personalidades em arquétipos emocionais — especialmente nos animes, mangás e jogos. Esses perfis misturam traços de comportamento, forma de amar e expressar sentimentos. São tão reconhecíveis que viraram ícones culturais.

Vamos conhecer os principais 👇


❤️ 1. Tsundere (ツンデレ)

“Tsun” = agressivo / “Dere” = carinhoso

  • Personalidade: fria, irritadiça, difícil de lidar no início, mas no fundo é doce e carinhosa.

  • Frase típica: “Não é como se eu gostasse de você ou algo assim, baka!”

  • Exemplo: Taiga Aisaka (Toradora!)

  • Curiosidade: é o tipo mais popular nos animes românticos; representa o amor que “derrete com o tempo”.


💞 2. Yandere (ヤンデレ)

“Yan” = doente / “Dere” = amorosa

  • Personalidade: amável e devotada, mas com amor obsessivo e possessivo, chegando à loucura.

  • Exemplo: Yuno Gasai (Mirai Nikki)

  • Curiosidade: virou meme e fetiche na cultura otaku por misturar fofura com psicose amorosa.


💗 3. Kuudere (クーデレ)

“Kuu” = cool (frio) / “Dere” = amorosa

  • Personalidade: calma, racional e indiferente, mas revela emoções profundas quando se apega.

  • Exemplo: Rei Ayanami (Neon Genesis Evangelion)

  • Curiosidade: representam o “amor silencioso” e o mistério — geralmente associadas a garotas frias ou tímidas.


💚 4. Dandere (ダンデレ)

“Danmari” = silêncio / “Dere” = amorosa

  • Personalidade: tímida, introvertida e reservada, mas se abre com quem confia.

  • Exemplo: Hinata Hyuga (Naruto)

  • Curiosidade: diferem das kuudere porque são socialmente ansiosas, não frias.


💛 5. Deredere (デレデレ)

Totalmente “dere” — puro amor e alegria.

  • Personalidade: extrovertida, gentil, sempre feliz e apaixonada.

  • Exemplo: Usagi Tsukino (Sailor Moon)

  • Curiosidade: simboliza o amor inocente e otimista, o oposto das personalidades tsun ou yan.


💙 6. Himedere (ヒメデレ)

“Hime” = princesa / “Dere” = amorosa

  • Personalidade: trata os outros como súditos, exigindo tratamento real.

  • Exemplo: Erina Nakiri (Shokugeki no Soma)

  • Curiosidade: acreditam ser “superiores”, mas escondem insegurança emocional.


🧡 7. Kamidere (カミデレ)

“Kami” = deus / “Dere” = amorosa

  • Personalidade: arrogante, com complexo de divindade — acredita estar acima dos outros.

  • Exemplo: Light Yagami (Death Note)

  • Curiosidade: o amor deles é uma bênção… ou uma maldição.


💜 8. Sadodere (サドデレ)

“Sado” = sádico / “Dere” = amorosa

  • Personalidade: gosta de provocar, humilhar ou dominar o parceiro — de forma lúdica ou cruel.

  • Exemplo: Kurumi Tokisaki (Date A Live)

  • Curiosidade: popular entre animes ecchi; o prazer vem do poder emocional.


💝 9. Bakadere (バカデレ)

“Baka” = bobo / “Dere” = amorosa

  • Personalidade: ingênua, avoada, atrapalhada — mas genuinamente amável.

  • Exemplo: Yui Hirasawa (K-On!)

  • Curiosidade: representa a pureza do amor inocente, sem malícia ou lógica.


🖤 10. Hinedere (ヒネデレ)

“Hine” = cínico / “Dere” = amorosa

  • Personalidade: sarcástica, cética e com dificuldade de confiar.

  • Exemplo: Tomoko Kuroki (Watamote)

  • Curiosidade: o amor vem com resistência emocional e ironia constante.


💫 Extras que surgiram mais recentemente:

  • Undere — faz tudo que o amado diz, submissa.

  • Mayadere — inimiga que se apaixona.

  • Nemuidere — sempre sonolenta, amor preguiçoso.

  • Utsudere — sofre de depressão ou traumas, mas encontra redenção no amor.


☕ Estilo Bellacosa diz:

Esses arquétipos são mais do que rótulos: são metáforas emocionais sobre como o amor é percebido no Japão — entre repressão, devoção e autoexpressão.
Cada -dere mostra uma forma diferente de vulnerabilidade humana.
E é por isso que, quando um personagem muda de “tsun” para “dere”, o coração do fã explode ❤️

domingo, 4 de abril de 2021

DotCom : Capítulo XVI — A Caixa-Preta da Bolha da Internet: Os 25 Maiores Erros que Destruíram Milhares de Empresas e Como Evitá-los na Era da Inteligência Artificial

Bellacosa Mainframe e o estouro da bolha dotcom capitulo xvi

 

Capítulo XVI — A Caixa-Preta da Bolha da Internet: Os 25 Maiores Erros que Destruíram Milhares de Empresas e Como Evitá-los na Era da Inteligência Artificial

Toda queda deixa destroços. Mas também deixa uma caixa-preta cheia de informações preciosas para quem deseja não repetir os mesmos acidentes.

"Na aviação, cada acidente melhora os aviões. Na engenharia de software, cada grande fracasso melhora toda uma geração de sistemas."

Durante toda esta jornada analisamos empresas que desapareceram.

Investidores que perderam fortunas.

Profissionais que precisaram recomeçar suas carreiras.

Tecnologias que amadureceram.

Mercados que aprenderam.

Mas existe um exercício extremamente útil que engenheiros costumam fazer após grandes incidentes.

Chama-se Post-Mortem.

No universo da aviação existe algo semelhante.

Quando um avião sofre um acidente, investigadores procuram imediatamente a caixa-preta.

Ela registra tudo.

Cada comando.

Cada decisão.

Cada falha.

Cada alerta.

O objetivo não é encontrar culpados.

É aprender.

Na computação deveria acontecer exatamente o mesmo.

Se pudéssemos abrir a caixa-preta da bolha da Internet...

Quais seriam os maiores erros registrados?

E, mais importante...

Quais deles continuam acontecendo hoje na corrida pela Inteligência Artificial?

Vamos abrir essa caixa-preta.


Erro 1 — Confundir Tecnologia com Modelo de Negócio

A Internet era extraordinária.

Isso não significava que qualquer empresa da Internet seria extraordinária.

Hoje acontece algo parecido.

A IA é revolucionária.

Mas isso não transforma automaticamente qualquer startup de IA em um bom investimento.

Lição: tecnologia cria oportunidades; modelo de negócios cria empresas.


Erro 2 — Crescer Antes de Saber para Onde

Muitas Dot-Com contrataram milhares de funcionários antes de descobrir se realmente possuíam mercado.

Escalaram rapidamente.

Na direção errada.

Hoje algumas empresas treinam modelos gigantescos antes mesmo de validar a necessidade do cliente.

Lição: primeiro encontre o caminho. Depois acelere.


Erro 3 — Gastar Como se o Dinheiro Nunca Acabasse

Escritórios luxuosos.

Campanhas milionárias.

Eventos extravagantes.

Contratações exageradas.

Tudo parecia justificável.

Até o dinheiro acabar.

A história mostrou que caixa sempre vence apresentações bonitas.


Erro 4 — Ignorar Custos Operacionais

Durante a bolha poucos prestavam atenção ao custo de manter sistemas funcionando.

Hoje ocorre algo semelhante em alguns projetos de IA.

Treinar modelos.

Executar inferências.

Armazenar vetores.

Consumir energia.

Tudo possui custo.

Lição: inovação precisa caber no orçamento.


Erro 5 — Construir Produtos que Ninguém Pediu

Diversas startups criaram soluções impressionantes.

O problema?

Pouquíssimas pessoas realmente precisavam delas.

Essa continua sendo uma das principais causas de fracasso.


Erro 6 — Confundir Usuários com Clientes

Ter milhões de usuários não significa possuir receita.

Essa diferença destruiu inúmeras empresas.

Até hoje muitas startups descobrem tarde demais que audiência e faturamento não são sinônimos.


Erro 7 — Acreditar que Crescimento Resolve Todos os Problemas

Existe uma frase famosa entre arquitetos de software.

"Escalar um sistema ruim apenas produz um sistema ruim maior."

Empresas seguem exatamente a mesma lógica.


Erro 8 — Subestimar Engenharia

Durante a euforia, marketing frequentemente recebia mais investimentos do que engenharia.

A crise mostrou rapidamente a consequência.

Promessas sobrevivem poucos meses.

Arquiteturas sobrevivem décadas.


Erro 9 — Esquecer Segurança

Muitas empresas cresceram rapidamente sem investir em proteção.

Quando incidentes ocorreram...

A confiança desapareceu.

Hoje, na era da IA, segurança tornou-se ainda mais importante.


Erro 10 — Ignorar Governança

Quem toma decisões?

Quem aprova mudanças?

Quem responde por falhas?

Essas perguntas raramente apareciam durante a bolha.

Hoje são fundamentais.


Erro 11 — Acreditar Demais nas Próprias Projeções

Planilhas suportam praticamente qualquer cenário otimista.

Mercados reais não.

Toda previsão precisa conviver com a possibilidade de estar errada.


Erro 12 — Não Ouvir Clientes

Diversas empresas ouviam apenas investidores.

Os clientes permaneciam em segundo plano.

Esse erro continua surpreendentemente comum.


Erro 13 — Esquecer a Concorrência

Durante períodos de euforia muitos acreditam ser únicos.

Raramente são.

Sempre existe alguém tentando resolver o mesmo problema.


Erro 14 — Subestimar Infraestrutura

A infraestrutura costuma parecer cara.

Até o dia em que ela falha.

Foi exatamente isso que levou muitas empresas a investir posteriormente em cloud, observabilidade e automação.


Erro 15 — Acreditar que a Tecnologia Elimina Administração

Software não substitui gestão.

Inteligência Artificial também não.

Empresas continuam precisando de estratégia.

Planejamento.

Liderança.

Execução.


Erro 16 — Ignorar Pessoas

Nenhuma revolução tecnológica acontece sem profissionais preparados.

Treinamento sempre produz retorno.


Erro 17 — Pensar Apenas no Curto Prazo

Empresas sobreviventes quase sempre possuíam visão de longo prazo.

As demais estavam preocupadas apenas com a próxima rodada de investimentos.


Erro 18 — Não Medir

Aquilo que não é medido dificilmente pode ser melhorado.

Esse princípio vale para software.

Vale para negócios.

Vale para Inteligência Artificial.


Erro 19 — Não Preparar Planos de Contingência

Toda empresa acredita que continuará crescendo.

Poucas planejam crises.

As sobreviventes normalmente fazem ambos.


Erro 20 — Esquecer a Ética

Quando dinheiro entra rapidamente, decisões apressadas tornam-se tentadoras.

A história mostra que ética nunca deve ser tratada como acessório.

Principalmente quando lidamos com IA.


Erro 21 — Não Aprender com a História

Talvez o erro mais curioso.

Cada geração acredita estar vivendo algo completamente novo.

Raramente está.

Conhecer a história reduz enormemente a probabilidade de repetir erros antigos.


Erro 22 — Desprezar Sistemas Legados

Muitas startups acreditavam que poderiam reconstruir completamente tudo do zero.

Décadas depois descobriram que integrar costuma ser muito mais inteligente do que substituir.


Erro 23 — Subestimar Complexidade

Soluções simples frequentemente escondem enorme complexidade operacional.

Quem trabalha com mainframe conhece essa realidade muito bem.


Erro 24 — Confundir Velocidade com Direção

É possível correr muito rapidamente...

Na direção errada.

Esse talvez seja um dos maiores ensinamentos da bolha.


Erro 25 — Esquecer que Toda Revolução se Torna Infraestrutura

Poucas pessoas falam hoje sobre TCP/IP.

DNS.

HTTP.

Cloud.

Porque deixaram de ser novidades.

Passaram a ser infraestrutura.

O mesmo provavelmente acontecerá com a Inteligência Artificial.

Quando uma tecnologia realmente vence...

Ela deixa de chamar atenção.

Passa simplesmente a fazer parte do cotidiano.


O Que Todas Essas Falhas Possuem em Comum?

Observe cuidadosamente esses vinte e cinco erros.

Quase nenhum deles é tecnológico.

A maioria envolve:

expectativas;

gestão;

liderança;

planejamento;

engenharia;

psicologia;

economia.

Isso explica por que tantas revoluções tecnológicas apresentam padrões semelhantes.

Os computadores mudam.

As pessoas mudam muito menos.


Enquanto Isso... O Mainframe Continuava Ensinando

Existe um motivo pelo qual ambientes IBM Z valorizam tanto:

controle de mudanças;

gestão de configuração;

auditoria;

backup;

planejamento;

recuperação;

capacidade;

documentação;

testes.

Esses processos não existem para burocratizar.

Existem porque alguém já pagou muito caro pela ausência deles.

A história da computação é, em grande parte, uma história de lições aprendidas.


O Maior Aprendizado

Depois de abrir a caixa-preta da bolha percebemos algo surpreendente.

As empresas não fracassaram porque utilizavam Internet.

Fracassaram porque ignoraram princípios fundamentais de administração e engenharia.

Isso muda completamente a interpretação da história.

Não devemos temer novas tecnologias.

Devemos apenas evitar antigos erros.


Lições para o Padawan COBOL

Imagine que a USS Enterprise sofreu uma pane durante uma missão.

Os motores de dobra desligaram.

Os escudos falharam.

A tripulação conseguiu sobreviver.

Dias depois, engenheiros analisam cuidadosamente todos os registros da nave.

Ninguém pergunta:

"Quem devemos culpar?"

Todos perguntam:

"O que podemos aprender para que isso nunca mais aconteça?"

Esse é o verdadeiro espírito da engenharia.

A bolha da Internet foi uma gigantesca caixa-preta da história da tecnologia.

Ela registrou erros extremamente caros.

Mas também produziu conhecimento que hoje protege toda uma nova geração de empresas.

Talvez essa seja a maior vantagem do Programador COBOL Padawan.

Ele inicia sua carreira não apenas estudando linguagens modernas ou Inteligência Artificial.

Ele começa carregando consigo décadas de experiências acumuladas por milhares de engenheiros que vieram antes.

E isso representa uma vantagem competitiva impossível de comprar.

No próximo capítulo encerraremos nossa jornada reunindo as cinquenta maiores lições que atravessam toda esta história, formando uma espécie de Holocron do Programador COBOL Padawan: princípios atemporais capazes de orientar qualquer profissional, independentemente da próxima revolução tecnológica que venha a surgir.


sábado, 3 de abril de 2021

☕💣🚀 PADAWAN, O IMS NÃO É UM BANCO DE DADOS. É UMA CIVILIZAÇÃO DIGITAL QUE SOBREVIVEU A TODAS AS MODAS DA COMPUTAÇÃO!

 

Bellacosa Mainframe e o database ims

☕💣🚀 PADAWAN, O IMS NÃO É UM BANCO DE DADOS. É UMA CIVILIZAÇÃO DIGITAL QUE SOBREVIVEU A TODAS AS MODAS DA COMPUTAÇÃO!

A Anatomia Completa do IMS DB: Como uma Tecnologia Nascida Para Levar o Homem à Lua Continua Movimentando Trilhões de Dólares no Século XXI

Quando alguém escuta a sigla IMS, normalmente imagina um sistema antigo, preso aos anos 1960, escondido em alguma sala refrigerada de um banco.

Mas essa visão está tão errada quanto acreditar que um Boeing 787 voa usando a mesma tecnologia dos irmãos Wright.

O IMS evoluiu.

E evoluiu muito.

O que nasceu em 1966 para ajudar a NASA no Programa Apollo transformou-se em uma das plataformas de gerenciamento de dados mais resilientes da história da computação. Segundo o material estudado, o IMS foi desenvolvido pela IBM em parceria com Rockwell e Caterpillar para apoiar o projeto que levaria o homem à Lua.

Mais de meio século depois, ele continua processando algumas das cargas de trabalho mais críticas do planeta.

E existe uma razão simples para isso:

O IMS não foi construído para ser bonito.

Foi construído para nunca falhar.


O Grande Equívoco dos Novatos

Uma das primeiras armadilhas para quem começa a estudar IMS é tentar compará-lo diretamente com bancos relacionais.

O raciocínio geralmente é:

  • Oracle possui tabelas

  • SQL Server possui tabelas

  • PostgreSQL possui tabelas

  • Então IMS também deve possuir tabelas

Não.

O IMS enxerga o mundo de forma completamente diferente.

Enquanto bancos relacionais organizam informações em linhas e colunas, o IMS organiza informações em árvores hierárquicas.

Imagine uma árvore genealógica.

Existe:

  • um ancestral

  • filhos

  • netos

  • bisnetos

Esse é exatamente o modelo mental utilizado pelo IMS.

A estrutura inteira foi desenhada para representar relacionamentos naturais de dependência.


Por Que a IBM Criou um Banco Hierárquico?

Voltemos para 1966.

Não existiam:

  • bancos relacionais

  • SQL

  • ORM

  • Hibernate

  • Entity Framework

  • MongoDB

  • Kubernetes

A preocupação era outra.

A NASA precisava controlar volumes gigantescos de componentes.

Imagine um foguete Saturn V.

Ele possuía:

  • estágios

  • motores

  • sistemas hidráulicos

  • sistemas elétricos

  • sensores

Cada componente dependia de outro componente.

O modelo hierárquico era extremamente natural para representar essa realidade.

Foi daí que nasceu o IMS.


O Que É um Segmento?

No universo IMS, tudo gira ao redor do conceito de segmento.

O tutorial define segmento como a menor unidade de informação movimentada entre a aplicação e o banco através do DL/I.

Pense nele como um registro lógico.

Exemplo:

CLIENTE
--------
Código
Nome
CPF
Telefone

Esse conjunto de campos forma um segmento.


Campo Não É Segmento

Outro erro comum.

Campo e segmento não são a mesma coisa.

O segmento é o recipiente.

Os campos são os dados armazenados dentro dele.

Exemplo:

CLIENTE
    Código
    Nome
    CPF
    Cidade

CLIENTE = Segmento

Código = Campo

Nome = Campo

CPF = Campo

Cidade = Campo

Parece simples.

Mas essa distinção é fundamental para entender DBDs, PSBs e chamadas DL/I.


O Poder da Hierarquia

Imagine uma seguradora.

Cada cliente possui:

CLIENTE
 ├── APÓLICE
 │     ├── COBERTURA
 │     ├── SINISTRO
 │     └── PAGAMENTO

Perceba algo interessante.

Um sinistro não existe sem uma apólice.

Uma apólice não existe sem um cliente.

Essa dependência natural é exatamente o que o IMS modela de forma brilhante.


O Segmento Root: O Imperador da Galáxia

Toda hierarquia IMS possui um segmento raiz.

O chamado Root Segment.

Ele é o ponto de entrada para todo o restante da estrutura.

Sem ele nada existe.

Na prática:

CLIENTE
 ├── CONTA
 ├── CARTÃO
 └── EMPRÉSTIMO

CLIENTE seria o Root.

Toda navegação começa nele.

Toda recuperação passa por ele.

Toda inserção depende dele.


Parent, Child, Dependents e a Família IMS

Uma das razões pelas quais o IMS é intuitivo é que ele utiliza conceitos familiares.

O material apresenta:

Parent Segment

Segmento que possui filhos abaixo dele.

Child Segment

Segmento que possui um pai acima dele.

Dependent Segment

Qualquer segmento que não seja raiz.

Isso cria uma estrutura extremamente organizada.


Twin Segments: Os Gêmeos do Banco

Uma característica curiosa do IMS é a existência dos Twin Segments.

Imagine:

CLIENTE
 ├── CONTA 001
 ├── CONTA 002
 ├── CONTA 003

Todas são ocorrências do mesmo tipo de segmento.

Logo:

CONTA 001
CONTA 002
CONTA 003

são twins.

Em bancos relacionais isso parece trivial.

No IMS isso influencia diretamente o processamento DL/I.


Database Record: Muito Mais Que Um Registro

Em SQL um registro normalmente significa uma linha.

No IMS não.

Um Database Record é composto pelo Root mais todos os segmentos subordinados.

Exemplo:

CLIENTE
 ├── CONTA
 │    ├── MOVIMENTO
 │    ├── MOVIMENTO
 │    └── MOVIMENTO
 └── CARTÃO

Tudo isso junto forma um único Database Record.

Essa diferença muda completamente a forma de programar.


Database Path: A Estrada Dentro da Árvore

O conceito de Path é outro dos pilares do IMS.

Um Path é o caminho percorrido do Root até um segmento específico.

Exemplo:

CLIENTE
 └── CONTA
      └── MOVIMENTO

O caminho é:

CLIENTE → CONTA → MOVIMENTO

Não é permitido "pular" níveis.

Isso garante consistência estrutural.


DL/I: O Tradutor Universal

Se existe algo que todo programador IMS precisa dominar é o DL/I.

O Data Language Interface é a interface utilizada pelos programas para conversar com o banco.

Pense nele como:

SQL do IMS

Mas muito mais poderoso.

E muito mais perigoso para iniciantes.


Processamento Sequencial: A Filosofia Original

O tutorial mostra que o processamento sequencial segue um padrão fixo:

Primeiro desce.

Depois anda para a direita.

Em outras palavras:

Root
 ↓
Filho
 ↓
Neto
 ↓
Bisneto
 →
Próximo irmão

Isso parece estranho para quem vem de SQL.

Mas oferece uma eficiência impressionante.


Processamento Aleatório: A Arma dos Especialistas

Nem sempre queremos percorrer a árvore inteira.

Às vezes queremos acessar diretamente:

Cliente 999999

Nessa situação usamos Random Processing.

Para isso fornecemos uma chave concatenada.

Exemplo:

BANCO
CLIENTE
CONTA

Essa combinação identifica exatamente o caminho desejado.


Chave Concatenada: A Magia do Desempenho

O tutorial apresenta um conceito frequentemente ignorado pelos novatos:

Concatenated Key.

Ela contém as chaves de todos os segmentos necessários para localizar um ponto específico da árvore.

Exemplo:

AGENCIA = 1234
CLIENTE = 998877
CONTA = 000001

Juntos eles definem um único caminho.

É isso que torna o acesso tão rápido.


Por Que IMS Costuma Ser Mais Rápido Que Bancos Relacionais?

O próprio material destaca que o processamento IMS costuma ser mais rápido que DB2 para determinadas cargas.

O motivo é simples.

Não existe JOIN.

Não existe otimizador tentando adivinhar o melhor plano.

Não existe estatística de tabela.

A estrutura já define previamente o caminho.

O acesso é direto.

Determinístico.

Previsível.


DBD: O DNA do Banco

Chegamos a uma das partes mais importantes.

O DBD.

Database Descriptor.

Se o banco fosse um ser humano, o DBD seria seu DNA.

Ele descreve:

  • segmentos

  • campos

  • relacionamentos

  • método de acesso

  • estrutura física

Nada existe sem o DBD.


DBDGEN: O Ritual Sagrado dos DBAs IMS

O DBD é construído através do DBDGEN.

Quem já trabalhou com IMS sabe:

Criar um DBD não é apenas escrever macros.

É desenhar a forma como os próximos milhões de registros viverão pelos próximos anos.

Um erro de modelagem pode sobreviver décadas.


PSB: A Janela do Programa

O programa COBOL não enxerga o banco inteiro.

Ele enxerga apenas o que o PSB permite.

Imagine um castelo.

O DBD define o castelo.

O PSB define quais portas podem ser abertas.

Isso oferece:

  • segurança

  • isolamento

  • controle


PCB: O Passaporte da Aplicação

Dentro do PSB encontramos os famosos PCBs.

Program Communication Blocks.

Eles informam:

  • qual banco acessar

  • quais segmentos acessar

  • quais operações executar

Sem PCB não existe comunicação.


ACB: A União dos Mundos

O ACB combina:

DBD
+
PSB
=
ACB

O tutorial descreve o ACB como a forma executável do acesso ao banco.

É o elo final entre definição e execução.


DFSRRC00: O Maestro da Orquestra

Uma curiosidade que separa iniciantes de veteranos.

Programas IMS Batch normalmente são executados através do módulo:

DFSRRC00

O material mostra esse papel do módulo de inicialização batch IMS.

Quando um desenvolvedor COBOL executa um programa IMS, frequentemente é esse componente que está coordenando toda a operação.


O Programa COBOL Não Conversa Diretamente Com o Banco

Esse é outro conceito importante.

O fluxo real é:

COBOL
 ↓
DL/I
 ↓
IMS
 ↓
Database

O programa nunca acessa diretamente os dados.

Tudo passa pela camada DL/I.


O Verdadeiro Poder do IMS

Agora chegamos ao ponto que raramente aparece em tutoriais.

O verdadeiro poder do IMS não está em segmentos.

Nem em DBDs.

Nem em PSBs.

Nem mesmo no DL/I.

O verdadeiro poder está na previsibilidade.

Quando um banco movimenta:

  • cartões

  • seguros

  • telecomunicações

  • reservas aéreas

  • operações bancárias

o requisito principal não é inovação.

É sobrevivência.

O IMS foi desenhado para operar continuamente durante décadas.

E conseguiu.


O Que os Desenvolvedores Modernos Podem Aprender com o IMS?

Muita coisa.

Principalmente:

Modelagem importa

O IMS força o arquiteto a pensar antes de criar.

Performance nasce no desenho

Não existe milagre posterior.

Estruturas simples escalam

Uma árvore bem desenhada pode sobreviver cinquenta anos.

Confiabilidade vale mais que moda

Tecnologias modernas aparecem todos os anos.

Pouquíssimas permanecem relevantes por meio século.


Conclusão: O IMS Não Sobreviveu ao Futuro. Ele Ajudou a Construí-lo.

Existe uma frase que gosto de repetir aos alunos:

"O mundo não roda em aplicativos modernos. O mundo roda em sistemas que nunca podem parar."

O IMS é um dos maiores exemplos dessa realidade.

Enquanto gerações de bancos surgiram e desapareceram, o IMS continuou armazenando informações críticas, processando transações e sustentando operações que movimentam parte significativa da economia mundial.

Quando você estuda Root Segments, Paths, DBDGEN, PSBGEN, PCBs e DL/I, não está apenas aprendendo uma tecnologia antiga.

Está estudando uma das arquiteturas mais bem-sucedidas da história da computação corporativa.

E talvez essa seja a maior lição do IMS:

Em tecnologia, longevidade não acontece por acaso. Ela é conquistada através de decisões de arquitetura tão sólidas que continuam funcionando décadas depois que todas as tendências da época desapareceram.


sexta-feira, 2 de abril de 2021

☕💣🏫 OPERADOR, O DISASTER RECOVERY PSICOLÓGICO DE SCHOOL-LIVE CRIOU UMA CATEGORIA INTEIRA DE ANIMES QUE ESCONDEM FALHAS CRÍTICAS ATRÁS DE INTERFACES INOCENTES!

 

Bellacosa Mainframe com animes bizarros mesma tematica que School Live

☕💣🏫 OPERADOR, O DISASTER RECOVERY PSICOLÓGICO DE SCHOOL-LIVE CRIOU UMA CATEGORIA INTEIRA DE ANIMES QUE ESCONDEM FALHAS CRÍTICAS ATRÁS DE INTERFACES INOCENTES!

Introdução

Quando Gakkougurashi! (School-Live!) estreou em 2015, muitos espectadores acreditaram estar diante de mais um anime escolar do tipo Cute Girls Doing Cute Things. Personagens fofas, amizade, clube estudantil, situações leves e uma atmosfera acolhedora pareciam indicar um ambiente operacional estável. Porém, bastaram alguns minutos para que a série revelasse que o sistema estava funcionando sobre uma infraestrutura completamente comprometida.

School-Live tornou-se um marco porque mostrou que horror não depende apenas de monstros ou violência explícita. O verdadeiro terror pode nascer da percepção, da negação, da perda e dos mecanismos psicológicos que criamos para continuar funcionando quando a realidade se torna insuportável. A obra influenciou uma geração inteira de produções que utilizam contrastes entre inocência e escuridão, esperança e desespero, aparência e verdade.

Os animes desta lista seguem caminhos semelhantes. Alguns apresentam personagens aparentemente comuns enfrentando horrores indescritíveis. Outros escondem reviravoltas devastadoras sob uma estética colorida e amigável. Há ainda aqueles que exploram trauma, colapso social, loops temporais, isolamento psicológico e sobrevivência emocional.

O elemento que une todas essas obras não é necessariamente a presença de zumbis ou cenários pós-apocalípticos. O que realmente as conecta é a capacidade de enganar o espectador, construir expectativas e depois desmontá-las de forma magistral. São séries que obrigam o público a questionar o que está vendo e, muitas vezes, o que acredita saber sobre seus próprios personagens.

Se School-Live foi um ambiente escolar executando um Disaster Recovery invisível, os animes abaixo representam sistemas igualmente instáveis, operando no limite entre a esperança e o colapso total.


1. Mahou Shoujo Madoka★Magica (2011)

Resumo

Uma garota comum recebe a oportunidade de realizar qualquer desejo em troca de se tornar uma garota mágica.

Personagens

  • Madoka Kaname

  • Homura Akemi

  • Sayaka Miki

  • Mami Tomoe

  • Kyubey

Easter Egg

Os labirintos das bruxas utilizam referências visuais inspiradas em colagens surrealistas europeias.

Comentário

Assim como School-Live, começa parecendo algo leve e gradualmente revela uma realidade muito mais cruel.


2. Higurashi no Naku Koro ni (2006)

Resumo

Um garoto muda-se para uma pequena vila e descobre que acontecimentos estranhos estão ligados a uma série de mortes.

Personagens

  • Keiichi Maebara

  • Rena Ryuuguu

  • Mion Sonozaki

  • Rika Furude

Easter Egg

Diversos eventos aparecem nos primeiros episódios muito antes de serem explicados.

Comentário

Uma das maiores referências quando o assunto é horror psicológico e narrativa fragmentada.


3. Made in Abyss (2017)

Resumo

Uma menina desce ao maior abismo do mundo em busca da mãe desaparecida.

Personagens

  • Riko

  • Reg

  • Nanachi

Easter Egg

Muitos artefatos encontrados nos primeiros episódios possuem importância futura.

Comentário

Possui o mesmo contraste entre aparência infantil e conteúdo extremamente sombrio.


4. Shinsekai Yori (2012)

Resumo

Mil anos no futuro, crianças descobrem segredos terríveis sobre a sociedade em que vivem.

Personagens

  • Saki Watanabe

  • Satoru

  • Maria

  • Shun

Easter Egg

As lendas contadas no início explicam praticamente toda a história.

Comentário

Uma das obras mais inteligentes já produzidas sobre colapso social.


5. Another (2012)

Resumo

Uma sala de aula está amaldiçoada por uma tragédia ocorrida décadas antes.

Personagens

  • Kouichi Sakakibara

  • Mei Misaki

Easter Egg

A identidade do verdadeiro alvo da maldição aparece diversas vezes em segundo plano.

Comentário

Mistério escolar e horror psicológico em sua forma mais clássica.


6. Wonder Egg Priority (2021)

Resumo

Garotas entram em mundos paralelos para salvar vítimas de traumas e suicídio.

Personagens

  • Ai Ohto

  • Neiru

  • Rika

  • Momoe

Easter Egg

Os ovos representam memórias reprimidas e experiências traumáticas.

Comentário

Explora saúde mental de maneira semelhante ao aspecto psicológico de School-Live.


7. Bokurano (2007)

Resumo

Crianças aceitam participar de um jogo e descobrem que precisam pilotar um robô gigante em batalhas fatais.

Personagens

  • Jun Ushiro

  • Kana

  • Masaru

  • Chizu

Easter Egg

O contrato assinado pelas crianças é uma metáfora para responsabilidades adultas.

Comentário

Uma das histórias mais pesadas emocionalmente do gênero.


8. Yakusoku no Neverland (2019)

Resumo

Crianças descobrem um segredo aterrador sobre o orfanato onde vivem.

Personagens

  • Emma

  • Norman

  • Ray

Easter Egg

O número de identificação das crianças possui significados ocultos.

Comentário

Talvez o anime que mais se aproxima da sensação de descoberta de School-Live.


9. Sora yori mo Tooi Basho (2018)

Resumo

Quatro garotas embarcam em uma expedição para a Antártida.

Personagens

  • Mari Tamaki

  • Shirase Kobuchizawa

  • Hinata Miyake

  • Yuzuki Shiraishi

Easter Egg

Diversas mensagens emocionais são construídas silenciosamente desde o primeiro episódio.

Comentário

Não é horror, mas compartilha o forte aspecto emocional e psicológico.


10. Girls' Last Tour (Shoujo Shuumatsu Ryokou) (2017)

Resumo

Duas garotas atravessam um mundo pós-apocalíptico praticamente vazio.

Personagens

  • Chito

  • Yuuri

Easter Egg

Os cenários abandonados simbolizam a memória da humanidade desaparecida.

Comentário

Se School-Live mostra a luta para manter a normalidade, Girls' Last Tour mostra o que acontece quando a normalidade já desapareceu completamente.


☕ Veredito Bellacosa Mainframe

Mais parecido com School-Live

🥇 Madoka Magica
🥈 The Promised Neverland
🥉 Higurashi

Melhor Horror Psicológico

🥇 Higurashi
🥈 Another
🥉 Madoka Magica

Melhor Construção de Mistério

🥇 Shinsekai Yori
🥈 The Promised Neverland
🥉 School-Live

Maior Impacto Emocional

🥇 Made in Abyss
🥈 Bokurano
🥉 Girls' Last Tour

Todos esses animes possuem algo em comum: eles apresentam uma interface amigável para o usuário, mas escondem no backend alguns dos sistemas mais perturbadores já executados na história da animação japonesa. ☕💣🏫


quinta-feira, 1 de abril de 2021

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

 

Bellacosa Mainframe apresenta alguns casos de ataques hackers em mainframe

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

🧪 1. 1965 — O primeiro “hack” da história (IBM 7094 – CTSS)

👉 Sistema: IBM 7094 (CTSS – Compatible Time Sharing System)

O que aconteceu:

  • Um bug no editor criou um arquivo temporário com nome fixo
  • Dois usuários simultâneos causaram:
    • exposição do arquivo de senhas (!)

Impacto:

  • Senhas ficaram visíveis para qualquer usuário

📌 IMPORTANTE:
👉 Isso é considerado o primeiro vazamento de credenciais da história

✔️ Lição:

  • Controle de concorrência e isolamento são fundamentais


🧠 2. 1967 — Primeira invasão de rede (IBM APL Network)

👉 Ambiente: rede experimental IBM APL

O que aconteceu:

  • Estudantes exploraram workspaces compartilhados
  • Conseguiram navegar além do escopo permitido

Impacto:

  • Primeira invasão “não autorizada” documentada em rede

✔️ Lição:

  • Segurança lógica > segurança física


💣 3. 2007 — Primeiro hack documentado em z/OS moderno

👉 Caso citado em estudos de segurança mainframe

Possível alvo:

  • Banco europeu (ex: Nordea Bank)

O que aconteceu:

  • Uso de vulnerabilidades em ambiente z/OS
  • exploração via acesso indireto (provavelmente aplicações)

✔️ Lição:

  • Mainframe moderno também é atacável


🏦 4. 2012 — Caso Nordea Bank / Governo Sueco (O MAIS CLÁSSICO)

👉 Ambiente: IBM z/OS

O que aconteceu:

  • Hackers usaram:
    • z/OS emulado
    • exploração de vulnerabilidades (0-day)
  • Conseguiram:
    • escalar privilégios (SPECIAL)
    • modificar APF
    • acessar dados sensíveis
    • transferir dinheiro (~$850k)

Impacto:

  • Um dos raros casos confirmados de invasão real em mainframe

✔️ Técnica usada:

  • privilege escalation
  • persistência (APF)
  • exfiltração de datasets

✔️ Lição:

  • RACF mal configurado = porta aberta


🏴‍☠️ 5. 2012 — Hacker do Pirate Bay (caso judicial)

👉 Hacker: cofundador do Pirate Bay

O que aconteceu:

  • Invasão de mainframe
  • Roubo de dados governamentais

Impacto:

  • considerado o maior caso de hacking de mainframe na Dinamarca

✔️ Lição:

  • ameaça real não é só técnica — é também judicial/legal


🧾 6. Casos indiretos (2014–2015) — Dados de mainframe expostos

👉 Empresas:

  • Home Depot
  • Anthem
  • Experian

O que aconteceu:

  • Ataque NÃO começou no mainframe
  • MAS:
    • dados críticos estavam no mainframe
    • foram exfiltrados via sistemas distribuídos

Impacto:

  • milhões de registros vazados

✔️ Insight poderoso:
👉 O mainframe NÃO foi invadido diretamente
👉 mas foi comprometido indiretamente

✔️ Lição:

  • o risco está na integração (APIs, middlewares)


⚠️ 7. Casos IBM i (AS/400) — “Nunca foi hackeado” (mito quebrado)

👉 Realidade:

  • já houve invasões documentadas

Problema comum:

  • permissões abertas (*PUBLIC *ALL)
  • falta de auditoria

✔️ Lição:

  • segurança default ≠ segurança real


🧨 8. Engenharia social e insider (o ataque mais comum)

👉 Segundo especialistas:

  • A maioria dos ataques não é “hack remoto hollywoodiano”
  • São:
    • insiders
    • credenciais roubadas
    • acesso legítimo abusado

✔️ Lição:

  • RACF + auditoria > firewall


📊 9. Estatística brutal (realidade do mercado)

👉 Apenas 0.1% dos mainframes reportaram breach direto

✔️ Tradução Bellacosa:

  • extremamente seguro
  • MAS quando falha → impacto é gigante


🧠 🔥 Padrões REAIS dos ataques em Mainframe

🧩 Vetores mais comuns

  • má configuração de RACF / ACF2 / Top Secret
  • credenciais roubadas
  • aplicações CICS vulneráveis
  • integração com sistemas distribuídos
  • insiders

⚙️ Técnicas usadas

  • privilege escalation (SPECIAL / OPERATIONS)
  • manipulação de APF
  • execução de REXX malicioso
  • leitura de datasets (PII)
  • exfiltração via FTP / TCP/IP stack

💀 MITO vs REALIDADE

MitoRealidade
Mainframe não é hackeávelÉ, mas difícil
Só ataque externoMaioria é interna
RACF resolve tudoDepende da configuração
Isolado = seguroIntegração quebra isso

🧠 Conclusão estilo Bellacosa

👉 O mainframe NÃO é invulnerável
👉 Ele é mal compreendido

💡 A verdade:

“Mainframe não cai por brute force…
cai por negligência.”


PS: Nunca se esqueça que o inimigo pode estar dentro do castelo. E os demonios riem quando fazemos planos infaliveis. 

terça-feira, 30 de março de 2021

O Guia Definitivo para um Programador Padawan Entender o Que Realmente Acontece Quando um Programa "Morre" no IBM Z

 

Bellacosa Mainframe apresenta abends sem misterios

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios

O Guia Definitivo para um Programador Padawan Entender o Que Realmente Acontece Quando um Programa "Morre" no IBM Z

"O primeiro ABEND assusta. O centésimo ensina. O milésimo transforma um programador comum em alguém que consegue conversar com o sistema operacional."


Introdução

Existe um momento na vida de praticamente todo programador COBOL em que ele termina seu código, compila sem erros, executa o JOB e...

***** ABEND *****

Silêncio.

O coração acelera.

A primeira reação costuma ser:

"Meu programa está errado."

Na maioria das vezes, essa conclusão está incompleta.

No mundo Mainframe, um ABEND (Abnormal End) não significa apenas que o programa possui um erro. Ele significa que alguma parte do ecossistema que envolve aquela execução encontrou uma condição considerada fatal.

E esse ecossistema é enorme.

Um programa COBOL nunca trabalha sozinho.

Ele depende de:

  • JCL

  • JES2

  • z/OS

  • Catálogo

  • Arquivos

  • CICS

  • Db2

  • VSAM

  • SDSF

  • Memória

  • Storage

  • Segurança (RACF)

  • Compilador

  • Link-Edit

  • Bibliotecas (STEPLIB)

Quando qualquer uma dessas peças falha, o programa pode terminar com um ABEND.

Entender isso é a primeira evolução de um Programador Padawan.


Afinal, o que significa ABEND?

ABEND é abreviação de:

ABnormal END

Ou seja:

O sistema encerrou aquela execução porque ela não podia continuar de maneira segura.

É importante observar que:

Nem todo erro produz um ABEND.

Um programa pode terminar normalmente retornando RC=08.

Outro pode gerar apenas mensagens.

Já um ABEND significa:

"A execução foi interrompida imediatamente."


Quem executa um programa COBOL?

Muitos iniciantes imaginam algo assim:

COBOL
 ↓
Executa

Na realidade, acontece algo muito maior.

JCL

↓

JES2

↓

Initiator

↓

Load Module

↓

Language Environment

↓

Programa COBOL

↓

Arquivos

↓

Db2

↓

VSAM

↓

CICS

↓

z/OS

O programa é apenas um pequeno participante.


O papel do JCL

O JCL funciona como um plano de execução.

Ele informa:

  • qual programa executar;

  • quais arquivos abrir;

  • quais bibliotecas usar;

  • memória necessária;

  • parâmetros;

  • classes;

  • datasets temporários.

Se o COBOL é o cozinheiro...

O JCL é a receita inteira.


O papel do JES2

O JES2 (Job Entry Subsystem 2) é o grande organizador do processamento batch.

Ele:

  • recebe JOBs;

  • coloca na fila;

  • controla prioridades;

  • envia para execução;

  • coleta SYSOUT;

  • registra mensagens;

  • devolve resultados.

Pense no JES2 como um enorme aeroporto.

Os JOBs são aviões.

O JES2 decide:

  • quem decola;

  • quando decola;

  • em qual pista;

  • para onde vai.


O papel do SDSF

Depois da execução, normalmente usamos o SDSF.

Ele não executa nada.

Ele apenas permite observar.

No SDSF encontramos:

  • JESMSGLG

  • JESJCL

  • JESYSMSG

  • SYSOUT

  • RC

  • ABEND

É o equivalente ao painel de monitoramento.


Como um ABEND nasce?

Imagine:

JCL

↓

Programa COBOL

↓

OPEN INPUT CLIENTES

↓

Arquivo inexistente

↓

IEC141I

↓

S013

Ou então:

MOVE "ABC"
TO WS-NUMERO PIC 9(5)

↓

S0C7

Cada tipo de erro produz um código diferente.

Esse código é o ABEND.


ABENDs do Sistema (Sxxxx)

Quando começam com:

S

Significa:

System Abend

O próprio z/OS detectou o problema.

Exemplos:

S0C4

S0C7

S013

SB37

ABENDs do Usuário (Uxxxx)

Quando aparecem:

U4038

U0999

Foram gerados pela aplicação.

Ou pelo Language Environment.


ABENDs do CICS

No CICS aparecem códigos de quatro letras:

ASRA

AICA

AEI9

São específicos do ambiente transacional.


Os ABENDs mais importantes


S0C1

Operation Exception

O processador tentou executar uma instrução inválida.

Pode ocorrer por:

  • módulo corrompido;

  • CALL incorreto;

  • programa não compilado corretamente;

  • desvio para área inválida.

É relativamente raro.


S0C4

Protection Exception

Provavelmente o ABEND mais famoso.

O programa tentou acessar memória proibida.

Exemplos:

  • ponteiro inválido;

  • tabela fora do OCCURS;

  • endereço inexistente;

  • parâmetro incorreto na LINKAGE.

Sempre que ouvir "Storage Violation", pense em S0C4.


S0C7

Data Exception

O favorito dos iniciantes.

O programa tentou fazer cálculo com dados inválidos.

Exemplo:

PIC 9(5)

conteúdo:

12A45

Ao executar:

ADD 1

Resultado:

S0C7

A maior causa costuma ser falta de validação de entrada.


S013

Erro de Dataset

Relaciona-se à abertura de arquivos.

Normalmente envolve:

  • DCB incompatível;

  • RECFM;

  • LRECL;

  • BLKSIZE;

  • modo de abertura incorreto;

  • DD errado.

É um ABEND de integração entre JCL e programa.


S222

O JOB foi cancelado manualmente.

Normalmente:

CANCEL JOB

Não significa erro da aplicação.


S322

Tempo de CPU excedido.

O programa entrou em loop.

Ou o TIME do JOB foi ultrapassado.

Sempre investigue:

PERFORM UNTIL

GO TO

READ

EOF

S806

Programa não encontrado.

As causas clássicas:

  • STEPLIB incorreta;

  • LOAD inexistente;

  • biblioteca errada;

  • módulo não linkeditado.

É um dos primeiros erros que um desenvolvedor encontra.


SB37

Sem espaço durante gravação.

O dataset atingiu seu limite.

Muito comum em SORTs.


SD37

Sem espaço por quantidade de extents.

Mesmo existindo espaço físico.

O dataset não consegue crescer.


SE37

Quantidade máxima de extensões atingida.

O administrador normalmente resolve ajustando a alocação.


B37

Erro semelhante aos anteriores.

Também relacionado à falta de espaço.

A diferença está na forma como o sistema detectou a limitação.

Na prática, todo Padawan deve associar:

B37

SB37

SD37

SE37

↓

Problemas de espaço em disco.

U4038

Muito comum em COBOL.

Normalmente produzido pelo Language Environment.

Pode esconder:

  • S0C7;

  • S0C4;

  • SQLCODE fatal;

  • erro interno.

Sempre consulte o CEEDUMP.

Nunca pare na primeira mensagem.


U0999

Erro definido pela própria aplicação.

É comum em grandes bancos.

Exemplo:

IF ERRO

DISPLAY "CLIENTE INVALIDO"

MOVE 999 TO RETURN-CODE

CALL ABEND

É um erro de negócio.


ASRA (CICS)

Equivalente ao S0C4 ou S0C7 dentro do CICS.

Na maioria das vezes há um ABEND de sistema escondido atrás dele.

É necessário verificar o dump do CICS.


AEI9

Tentativa de acessar recurso inexistente.

Pode envolver:

  • programa;

  • mapa BMS;

  • fila;

  • recurso não instalado.


AKCS

Erro relacionado ao ambiente CICS ou à configuração de recursos e segurança. Costuma indicar inconsistências operacionais que exigem análise das mensagens associadas e da definição do recurso.


APCT

Programa não encontrado no CICS.

Equivale ao S806 do ambiente batch.

Verifique:

  • PPT;

  • DFHRPL;

  • módulo.


AICA

Loop infinito.

O CICS cancelou a transação.

É o equivalente do:

S322

Só que dentro do CICS.


ATNI

A transação solicitada não está instalada ou habilitada.

Verifique:

  • PCT;

  • nome da transação;

  • instalação dos recursos.


AEYD

Problemas relacionados ao acesso ou ao estado de recursos do CICS (como filas, arquivos ou outros objetos), normalmente indicando que o recurso esperado não está disponível ou não pode ser utilizado da forma solicitada. A mensagem detalhada do CICS complementa o diagnóstico.


Como investigar um ABEND?

Uma sequência bastante utilizada por profissionais experientes é:

1
Qual é o ABEND?

↓

2
É System?
É User?
É CICS?

↓

3
Verificar JESYSMSG

↓

4
Verificar JESMSGLG

↓

5
Verificar SYSOUT

↓

6
Existe CEEDUMP?

↓

7
Existe SYSMDUMP?

↓

8
Analisar última instrução executada

↓

9
Conferir JCL

↓

10
Reproduzir o problema

Essa disciplina evita "corrigir" o sintoma sem encontrar a causa.


Dicas de ouro para um Padawan

  • Leia a primeira mensagem de erro, não apenas a última. Muitas vezes ela explica a causa antes do ABEND.

  • Aprenda a navegar no SDSF. JESMSGLG, JESYSMSG e SYSOUT contam a história da execução.

  • Conheça os utilitários do compilador e do Language Environment. CEEDUMP, SYSMDUMP e IPCS são aliados valiosos.

  • Não altere código antes de entender o erro. Corrigir por tentativa e erro pode esconder problemas mais sérios.

  • Entenda o contexto. Um S806 aponta para bibliotecas; um S013 para JCL e datasets; um S0C7 para dados; um S0C4 para memória. O código do ABEND já indica a direção da investigação.

  • Mantenha um caderno de ABENDs. Profissionais experientes criam seu próprio catálogo de erros e soluções ao longo da carreira.


Curiosidades

  • Muitos bancos possuem verdadeiras "enciclopédias" internas de ABENDs, acumuladas ao longo de décadas.

  • Alguns ABENDs praticamente desapareceram com compiladores modernos, enquanto outros continuam comuns porque dependem de erros de lógica ou configuração.

  • Um mesmo problema de negócio pode gerar ABENDs diferentes dependendo se a execução ocorre em batch, CICS ou sob o Language Environment.

  • Desenvolvedores experientes frequentemente identificam a causa provável apenas ao ouvir um código como S0C7 ou S806, antes mesmo de abrir o dump.


Conclusão

O maior erro de um iniciante é imaginar que um ABEND representa apenas um defeito no programa COBOL.

Na realidade, um ABEND é uma mensagem do ecossistema IBM Z. Ele informa que alguma camada — aplicação, JCL, compilador, Language Environment, CICS, JES2, arquivos, armazenamento ou o próprio z/OS — encontrou uma condição que impediu a continuidade segura da execução.

Aprender a interpretar esses códigos é um divisor de águas. O programador deixa de ser apenas alguém que escreve COBOL e passa a compreender como o sistema operacional, o ambiente batch e o ambiente transacional trabalham em conjunto.

Como todo Padawan descobre cedo ou tarde: escrever o programa é apenas parte do trabalho. O verdadeiro domínio começa quando se entende por que ele executa, por que falha e como o IBM Z revela exatamente onde procurar a causa.


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