✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe alerta sobre riscos no racf mal configurado
💀🔥 “Seu RACF está seguro… ou você só acha?”
🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)
“RACF não falha…
quem falha é quem confia demais nele.”
🧠 📜 Contexto histórico (o começo de tudo)
O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).
👉 Naquela época:
segurança era controle de acesso
hoje é sobrevivência digital
💡 Curiosidade:
RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.
💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO
🧨 1. *PUBLIC — o vilão silencioso
👉 Procure:
// quem tem acesso aberto? RLIST DATASET * AUTHUSER(*)
💥 Red flag:
datasets críticos com:
ID(*PUBLIC) ACCESS(READ ou UPDATE)
🔥 Insight Bellacosa:
80% das falhas começam aqui.
🧠 2. Usuários com SPECIAL / OPERATIONS
👉 Liste:
SEARCH CLASS(USER) MASK(*) SPECIAL
💥 Risco:
acesso total ao RACF
🎯 Dica senior:
separar:
ADMIN ≠ AUDITOR
⚙️ 3. Grupos com autoridade excessiva
👉 Verifique:
LISTGRP * OMVS
💥 Problema:
grupo herdando privilégio indevido
🔥 Easter egg:
Um grupo mal configurado é pior que um usuário root.
🧬 4. Programas APF e AC=1
👉 Verifique APF:
D PROG,APF
💥 Risco:
execução em modo supervisor
🎯 Ataque clássico:
inserir loadlib malicioso
🔐 5. Password Policy (o calcanhar de aquiles)
👉 Cheque:
SETROPTS LIST
💥 Problemas comuns:
senha simples
sem expiração
sem history
🔥 Curiosidade:
Já vi banco com senha “123456” em ambiente produtivo.
🌐 6. FACILITY class (o “backdoor oficial”)
👉 Verifique:
RLIST FACILITY *
💥 Risco:
permissões ocultas
🎯 Exemplo crítico:
BPX.* (Unix System Services)
🧑💻 7. USS (Unix no mainframe = Linux feelings)
👉 Verifique:
LISTUSER USER OMVS
💥 Risco:
UID 0 (root)
🔥 Insight:
USS é o ponto favorito de pivot de atacante moderno.
🧾 8. Logging / SMF (sem isso você está cego)
👉 Cheque:
SMF 80 (RACF)
SMF 30 (jobs)
💥 Problema:
logs incompletos
🎯 Dica:
integrar com SIEM
🧠 9. Started Tasks (STC) — privilégio invisível
👉 Verifique:
RLIST STARTED *
💥 Risco:
tarefas com privilégios elevados
🔥 Easter egg:
STC mal protegido = root invisível rodando 24x7
🔗 10. Integrações externas (o novo campo de batalha)
👉 Verifique:
CICS
z/OS Connect
💥 Risco:
acesso indireto ao core
🎯 Realidade:
O ataque não entra pelo mainframe… entra pela API.
💀🔥 CHECKLIST RÁPIDO (modo auditor)
✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras
🧠💣 Fluxo real de ataque (pra abrir a mente)
credencial fraca
acesso TSO/FTP
enumeração RACF
exploração (APF / FACILITY / USS)
persistência
exfiltração
🧬 Easter Eggs que só senior percebe
💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe
🏦 Realidade nível banco
👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo
🔥 Frase final estilo Bellacosa
“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”
🗾✨ Golden Week — O Japão em Modo Férias, Tradição e Caos Organizado ✨🗾 Por El Jefe, direto do Bellacosa Mainframe Universe
Imagina o Japão — aquele país disciplinado, metódico, pontual ao extremo — parando tudo.
Trens lotados, hotéis impossíveis de reservar, parques abarrotados, e um sentimento coletivo de “ufa, finalmente descanso!”.
Pois é… isso tem nome, história e muita cultura por trás: a Golden Week (ゴールデンウィーク).
É como se o Japão dissesse:
“Agora é a hora de tirar o cartão de ponto espiritual, vestir o yukata, e deixar o tempo compilar sozinho.”
📜 A Origem — Quando o Japão Descobriu o Prazer de Feriar
A Golden Week nasceu oficialmente em 1948, no pós-guerra, quando o governo japonês consolidou vários feriados nacionais próximos no calendário.
Mas o nome curioso vem da indústria do cinema.
Nos anos 50, o estúdio Daiei Film percebeu que seus lucros subiam absurdamente durante essa semana de feriados — era o “período dourado” de bilheteria.
Inspirados no termo americano “Golden Time” (horário nobre de rádio e TV), batizaram o período de Golden Week.
O nome pegou, e o resto é história — literalmente.
🎌 O Que Compõe a Golden Week
A Golden Week não é um único feriado, mas um combo poderoso de datas sagradas para os japoneses:
📅 29 de abril – Showa Day (昭和の日)
Celebra o aniversário do imperador Hirohito (Era Showa), lembrando o pós-guerra e a reconstrução.
📅 3 de maio – Dia da Constituição (憲法記念日)
Comemora a constituição pacifista do Japão, implementada em 1947.
📅 4 de maio – Dia do Verde (みどりの日)
Dedicado à natureza, à paz e aos parques floridos — literalmente, o Japão em flor. 🌸
📅 5 de maio – Dia das Crianças (こどもの日)
Os céus se enchem de koinobori — aquelas carpas coloridas que representam força, sucesso e crescimento. 🐟
Resultado: uma semana inteira de festas, viagens, templos lotados, e memes de japoneses exaustos tentando “descansar organizadamente”. 😅
🧳 Curiosidades e Fofoquices Douradas
✨ 1. A Golden Week é o “Carnaval Japonês” (sem samba, mas com ordem).
É o único período do ano em que milhões de japoneses tiram férias ao mesmo tempo. Resultado: trens bala esgotam, passagens triplicam, e até o Monte Fuji entra em fila de espera.
✨ 2. Aeroportos lotados viram piada nacional.
Há quem brinque que “sobreviver à Golden Week é mais difícil que um exame de certificação da JICA”.
✨ 3. Alguns trabalhadores fogem para o campo ou templos.
Eles buscam silêncio, longe da multidão — como um “modo zen de depuração mental”.
✨ 4. A “Golden Week inversa”.
Algumas empresas tech e estúdios de anime adiam lançamentos para evitar o caos. (Sim, o Japão pausa até seus lançamentos digitais para respeitar o feriadão!)
✨ 5. Easter Egg Bellacosa:
Dizem que em 1978, um grupo de engenheiros da Fujitsu “codou” uma Golden Week não oficial no calendário do sistema operacional interno — um bug que dava um feriado automático ao tentar agendar batch jobs entre 29/04 e 05/05. 🖥️💛
🎥 Animes Que Citam a Golden Week
🎬 Steins;Gate – a trama inicia justamente durante o período da Golden Week, quando os personagens têm tempo livre para experimentar viagens no tempo (olha o perigo).
🎬 Lucky☆Star – Konata e amigas aproveitam a Golden Week para maratonar animes e visitar templos.
🎬 Tokyo Magnitude 8.0 – a protagonista está de férias na Golden Week quando ocorre o terremoto que muda tudo.
🎬 Toradora! e K-On! – ambas têm episódios especiais ambientados nessa época, com piqueniques, carpas ao vento e muito slice of life.
🎬 Detective Conan – vários casos acontecem na Golden Week, aproveitando o fluxo de turistas e eventos pelo Japão.
💡 Dicas Bellacosa Para Sobreviver à Golden Week
🚅 Planeje com antecedência — reservar trem ou hotel na véspera é pedir pra dormir no tatame da estação.
🌸 Evite pontos turísticos famosos — explore cidades menores, templos pouco conhecidos e parques locais.
🍡 Coma de tudo — é época de feiras, doces sazonais e hanami (flores de primavera).
📸 Leve sua câmera (ou zPhone) — o Japão nessa época é um colírio visual de cores, papéis, carpas e yukatas.
💭 Bellacosa Reflexão
A Golden Week é a prova de que até o país mais disciplinado do mundo precisa de uma pausa.
É o Japão lembrando a si mesmo que tradição também é descanso, e que o trabalho só tem valor quando o espírito respira.
Como diria um velho sysprog de Kobe:
“Até o mainframe precisa de um IPL. E nós também.”
Então, se a vida estiver travada em loop, talvez esteja na hora de acionar seu GO GOLDEN interno: pausar, respirar e compilar de novo com alma nova. 🌸✨
📜 Easter Egg Final:
Reza a lenda que quem faz um pedido sob uma bandeira de carpa na Golden Week atrai bons ventos para o resto do ano.
Então, se você ver uma koinobori balançando, faça seu desejo — nunca se sabe quando o vento japonês pode soprar até o seu terminal. 🐟💨💻
Jimi Dini Entrou no Catálogo — O Dia em que um GDG Criou uma Geração, Sofreu ABEND e Descobriu que IDCAMS Não É Um Curandeiro de Arquivos
Ou: como deixar de chamar todo arquivo com G0001V00 de “backup”, entender por que (+1) pode virar confusão e descobrir que o verdadeiro rock-and-roll do batch é saber o que ficou no catálogo depois do RC=12
Prólogo — a fita cassete que se chamava ontem
Imagine Jimi Dini, uma criatura de camisa de flanela, café frio e paciência limitada para apresentações com setenta slides, entrando na sala de operações às três da manhã. No monitor, um job de fechamento acabou de cair com ABEND. O operador aponta para a tela e decreta:
— Relaxa. O arquivo está no GDG.
Jimi olha para o spool, toma um gole de café e responde:
— “No GDG” quer dizer o quê? Está criado? Catalogado? É a geração ativa? É a de ontem? Está pendurada em deferred roll-in? Ou alguém só viu um G0042V00 no volume e resolveu chamar isso de plano de recuperação?
É aqui que começa a educação sentimental do programador COBOL. GDG não é uma palavra mágica para “backup”; IDCAMS não é uma ambulância que ressuscita dado errado; e o catálogo não é um detalhe administrativo que alguém do storage resolve quando o seu JCL ficou feio. Os três formam uma parte muito importante da segurança operacional do batch.
Vamos desmontar essa história sem misticismo — mas com respeito pelo momento em que um DELETE ... PURGE é digitado no ambiente errado e a sala inteira fica subitamente muito silenciosa.
1. GDG: uma estante, não uma pasta com nome bonito
GDG significa Generation Data Group. É um grupo de datasets relacionados, mantidos em ordem de geração pelo z/OS. Pense numa coleção de edições de jornal: a base é o título da coleção; cada GDS (Generation Data Set) é uma edição física.
O sufixo G0003V00 não é um ornamento que você inventa no teclado. Ele é formado pelo sistema: o número da geração e, quando necessário, o número de versão. A grande vantagem aparece quando o programa não precisa conhecer esse nome físico. Ele só pede a edição que precisa.
Referência no JCL
Tradução humana
(+1)
“Vou criar a próxima edição.”
(0)
“Quero a edição mais recente ativa.”
(-1)
“Quero a imediatamente anterior.”
(-2)
“Quero a de duas execuções atrás.”
G0042V00
“Quero exatamente esta edição física.”
Para um lote diário de extratos, isto é ouro. O job de hoje cria (+1). O processo de conferência lê (0). Uma rotina de comparação lê (-1). O JCL expressa intenção, não uma data carimbada à mão numa convenção de nomes que um dia alguém vai esquecer de atualizar.
Mas atenção: GDG administra gerações, não prova que o conteúdo está certo. Se o COBOL calculou juros usando uma taxa incorreta, você não possui um backup apenas porque o arquivo se chama G0088V00. Você possui uma versão perfeitamente organizada de um erro.
2. IDCAMS: o cartório do condomínio de datasets
IDCAMS, Access Method Services, é a ferramenta que conversa com o catálogo e administra vários objetos de dados. Ele é famoso entre programadores por criar VSAM, mas chamar IDCAMS de “o programa que cria KSDS” é como chamar um cartório de “o lugar onde se reconhece firma”. Verdadeiro, mas dramaticamente incompleto.
Com IDCAMS, podemos, entre outras coisas:
definir e alterar bases GDG;
listar entradas do catálogo;
criar, apagar e alterar clusters VSAM;
copiar ou carregar dados com REPRO;
trabalhar com índices alternativos;
investigar atributos que o JCL sozinho não torna tão visíveis.
Guarde uma regra de sobrevivência: se IDCAMS voltar com condição diferente de zero, não pare no RC=8. Abra o SYSPRINT. O retorno é o alarme; as mensagens são o laudo médico. Elas costumam revelar se a base já existe, se uma geração possui retenção, se houve problema de autorização RACF ou se o catálogo localizou algo diferente do que você imaginava.
3. Criando a base: antes de nascer a primeira geração
Definir a base GDG não cria um arquivo de negócio. Cria a regra de vida das futuras gerações no catálogo.
Também é válido escrever DEFINE GDG. Eu, porém, gosto de começar com GENERATIONDATAGROUP: evita que o jovem padawan imagine que está definindo um dataset sequencial. Está definindo a base, a estante e suas regras.
LIMIT(7): quantas edições cabem na estante?
LIMIT determina o número de gerações ativas. Para um job diário, LIMIT(7) pode representar uma semana. Para fechamento mensal, LIMIT(13) costuma cobrir doze meses e o atual. Para uma interface cuja correção pode levar noventa dias, talvez sete seja uma receita para uma conversa desagradável com auditoria.
O limite não deve nascer do folclore — “sempre fizemos 30” —, mas de perguntas concretas: por quantos dias pode ocorrer reprocessamento? Há retenção legal? Quem recupera um arquivo se o parceiro rejeitar a carga depois de duas semanas? Há espaço para isso? Em GDG clássico, o limite pode chegar a 255; um GDG estendido pode suportar até 999, sujeito à política do ambiente.
NOEMPTY: retire o mais antigo, não a banda inteira
Com NOEMPTY, quando chega uma nova geração acima do limite, apenas a mais velha sofre roll-off — deixa de fazer parte da base. É o comportamento normal em processamento contínuo.
EMPTY é outra conversa: quando o limite estoura, todas as gerações existentes saem da base. Há usos específicos para ciclos fechados, mas para relatório diário isso equivale a contratar Jimi Dini para organizar os arquivos e entregar-lhe um lança-chamas. Use NOEMPTY como padrão mental até que alguém explique, por escrito, por que EMPTY é necessário.
SCRATCH, NOSCRATCH, PURGE e NOPURGE: o que acontece quando a geração cai da estante?
Quando uma geração sofre roll-off, ela pode simplesmente deixar a base ou também ser removida do armazenamento:
SCRATCH: remove o dataset físico conforme o processamento aplicável;
NOSCRATCH: não o apaga automaticamente; ele pode continuar existindo e, no cenário SMS, ficar recatalogado fora da base como rolled off;
NOPURGE: respeita retenção/data de expiração;
PURGE: pode ultrapassar essa barreira de retenção.
Para operação comum, NOEMPTY, SCRATCH e NOPURGE são uma combinação honesta: remove somente a geração mais velha, libera espaço e não atropela proteção de retenção. Mas ela exige que seu LIMIT seja correto. Se a empresa precisa manter sessenta dias, LIMIT(7) com SCRATCH não é automação; é descarte programado.
4. O COBOL encontra o JCL: quem faz o quê?
O COBOL não deveria carregar a preocupação com o nome absoluto da geração. Ele abre um DDNAME. O JCL decide o dataset. O catálogo resolve a geração. Esta separação é uma das pequenas elegâncias do mainframe.
SELECT ARQ-EXTRATO ASSIGN TO EXTRATO
ORGANIZATION IS SEQUENTIAL
FILE STATUS IS WS-FS-EXTRATO.
O programa escreve em EXTRATO. Não precisa saber se virou G0042V00. E isto dá liberdade para a equipe ajustar as regras de infraestrutura sem reescrever lógica de negócio.
Na execução seguinte, o mais novo pode ser lido assim:
Esse é um ponto em que a vida do iniciante melhora: (+1) é para criar; (0) é a geração ativa mais recente; (-1) é a anterior. Não tente tratar (+1) como “o arquivo de hoje para leitura em qualquer etapa paralela”. O momento do catalogamento e o fluxo do job importam.
5. A cena do crime: job caiu ao criar (+1)
Agora chegamos à pergunta que separa quem decorou sintaxe de quem começa a entender operação.
O job aloca:
BELLACOSA.BATCH.EXTRATO(+1)
O z/OS reserva o nome físico, o programa começa a escrever e então acontece um ABEND: um S0C7, falta de espaço, falha de I/O, queda de subsistema ou aquela rotina antiga que decide que o valor HIGH-VALUES é uma proposta de carreira.
Pode sobrar uma geração física criada, por exemplo G0042V00, sem que ela tenha sido incluída como geração ativa na base. Esse é um estado conhecido como deferred roll-in. Na prática, o arquivo pode estar no DASD, mas (0) ainda aponta para a geração anterior.
O primeiro impulso de alguém é executar de novo. Às vezes funciona. Às vezes transforma um incidente simples numa investigação arqueológica.
Primeiro, investigue:
//LISTGDG EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LISTCAT ENT(BELLACOSA.BATCH.EXTRATO) ALL
LISTCAT LVL(BELLACOSA.BATCH.EXTRATO) ALL
/*
Depois, leia o spool: JESMSGLG, JESJCL, SYSPRINT e os SYSOUTs do programa. Você quer saber: a geração existe? O conteúdo foi fechado corretamente? O job morreu antes ou depois de gravar? A geração deveria sobreviver? Há outro job dependente em execução?
Se a GDS estiver íntegra e for realmente a geração que deve entrar na base, IDCAMS oferece a correção de catálogo:
O ROLLIN torna a geração ativa no GDG. É a ferramenta certa para a pergunta certa: “a geração existe e está boa, mas não foi associada à base”. Não a use como ritual automático após todo ABEND. Se o programa morreu depois de gravar metade do arquivo, colocar essa geração no GDG é apenas catalogar oficialmente um problema.
6. Reexecutar, corrigir ou recuperar? Três verbos, três decisões
Jimi Dini escreveria isto na parede da sala de controle: não conserte catálogo antes de decidir se o dado merece ser preservado.
Caso A — o conteúdo está correto, mas a geração não entrou
Valide volume, tamanho, quantidade de registros, totais de controle e sinal de término da aplicação. Se tudo estiver íntegro, ALTER ... ROLLIN pode ser a escolha adequada.
Caso B — o conteúdo está errado
Não “edite” a geração em silêncio para fingir que nada ocorreu. Corrija a causa, gere uma nova (+1) e documente o reprocessamento. A beleza do GDG é justamente preservar a sequência. Uma geração nova, correta e auditável costuma ser muito mais defensável que uma cirurgia clandestina na geração anterior.
Caso C — a geração está incompleta ou descartável
Depois de confirmação operacional, a geração física pode precisar ser excluída e o job reexecutado de maneira controlada. Isto não deve ser decidido pelo programador isolado em produção: há scheduler, dependências, retenção, RACF e possíveis consumidores do arquivo.
O vilão frequente é o segundo job disparado antes que o primeiro tenha sido tratado. Em GDS SMS no DASD, o mecanismo de GDS reclaim pode reutilizar uma geração pendente quando outro job tenta criar o mesmo (+1). Isso pode sobrescrever conteúdo anterior. Portanto, interrompa dependentes, entenda o estado e só então rerode.
7. ALTER, LISTCAT, DELETE: ferramentas, não martelos
LISTCAT é sua lanterna:
LISTCAT ENT(BELLACOSA.BATCH.EXTRATO) ALL
Ele permite enxergar atributos da base, limite e gerações. Use antes de tomar decisão destrutiva.
ALTER ajusta a política:
ALTER BELLACOSA.BATCH.EXTRATO LIMIT(45)
Isso aumenta a capacidade futura de retenção. Não traz de volta dados que já sofreram scratch. Também vale lembrar: reduzir limite pode provocar roll-off das gerações mais antigas. Não trate um ALTER LIMIT como ajuste cosmético.
DELETE faz exatamente o que o nome promete:
DELETE BELLACOSA.BATCH.EXTRATO.G0042V00
apaga uma geração específica; enquanto:
DELETE BELLACOSA.BATCH.EXTRATO GDG
atinge a base GDG. Isso é reconstrução, não manutenção corriqueira. Antes de qualquer DELETE, confirme ambiente, HLQ, entrada de catálogo, volumes e autorização. O personagem que diz “é só um GDG de teste” merece ao menos uma segunda verificação — porque o ambiente de teste costuma ter um nome suspeitosamente parecido com produção numa sexta-feira.
8. VERIFY não é varinha mágica
Outro equívoco comum: ouvir que IDCAMS possui VERIFY e concluir que ele corrige qualquer GDG. Não. VERIFY está ligado à verificação de consistência de estruturas VSAM e catálogo em cenários próprios. Ele não confere se a regra de cálculo do seu COBOL estava correta; não repõe registros faltantes num arquivo sequencial; não transforma uma GDS truncada em extrato válido.
Para GDG, pense assim:
Sintoma
Ação inicial correta
Arquivo lógico aponta para a geração errada
LISTCAT, avaliar estado e ROLLIN se aplicável
Geração não existe
Investigar job, retenção, scratch, backup e catálogo
Dados têm erro de negócio
Corrigir programa/parâmetro e reprocessar para nova geração
Retenção está pequena
ALTER LIMIT, com avaliação de espaço e auditoria
Estrutura VSAM está inconsistente
Acionar procedimento VSAM/storage; pode envolver VERIFY
Catálogo parece corrompido
Escalar ao storage/system programmer; não recriar base no improviso
O IDCAMS é excelente, mas não substitui diagnóstico. Ele administra registros de catálogo; seu processo operacional decide o que é dado confiável.
9. Passo a passo do jovem padawan antes de mexer num GDG
Quando um job com GDG falhar, siga este roteiro:
Pare o reflexo de rerodar. Veja se existem dependentes e evite duas tentativas criando o mesmo (+1).
Leia o ABEND e o spool. Descubra a causa, não só o código final.
Liste a base. Use LISTCAT ENT(nome-da-base) ALL.
Identifique a geração física. Ela existe? Está ativa, rolled off ou pendente?
Valide o conteúdo. Totais, contagem, trailer, retorno da aplicação, volume e integridade esperada.
Escolha conscientemente.ROLLIN se a geração boa não entrou; novo (+1) se deve reprocessar; descarte controlado se está incompleta.
Registre a decisão. Ticket, evidência de totals e horário da intervenção valem ouro na auditoria.
Libere a cadeia somente após a consistência. O próximo consumidor não deve descobrir o problema por acidente.
10. Curiosidades para contar no café — sem quebrar produção
Uma GDG pode ser muito mais antiga que boa parte do código Java que hoje a consome. E ainda assim ela resolve um problema moderno: versionamento de dados em lote. A diferença é que, no z/OS, esse versionamento está acoplado a catálogo, retenção, JCL, segurança e operação de grandes volumes — não a uma pasta chamada backup_final_agora_vai_3.
Outra curiosidade: o sufixo absoluto existe para quando uma referência precisa ser imutável. Usar (0) é ótimo para “a mais recente”; usar G0042V00 é apropriado quando uma auditoria, reconciliação ou reexecução exige provar que foi aquela geração, e não a que veio depois.
Por fim, GDG não elimina backup, disaster recovery, retenção corporativa ou cópia para fita/cloud. Ele ajuda a manter versões operacionais de datasets. Backup protege contra outra classe de problemas: perda de volume, desastre, corrupção ampla, retenção longa e erros que só foram percebidos quando todas as gerações úteis já saíram da estante.
Epílogo — o som que fica depois do ABEND
No fim da madrugada, Jimi Dini fecha o SYSPRINT, confere o LISTCAT e deixa uma frase para o programador COBOL iniciante:
— O mainframe não é antigo; ele só não confia em improviso.
GDG oferece uma cronologia clara. IDCAMS administra a cronologia no catálogo. JCL declara como cada etapa usa essa cronologia. COBOL processa os registros. Quando algo falha, a resposta madura não é “reroda e vê”. É descobrir o que foi alocado, o que foi catalogado, o que está íntegro e qual ação preserva tanto o negócio quanto a rastreabilidade.
Quando você entende isso, (+1) deixa de ser uma sequência estranha entre parênteses. Ele se torna uma promessa operacional: “esta é a próxima versão do dado; trate-a com o respeito que ela terá quando alguém precisar explicar seu conteúdo daqui a três meses.
O CICS apenas detectou que algo deu errado dentro do programa.
A investigação continua:
ASRA
↓
DFH Messages
↓
Trace
↓
Dump
↓
Programa
Ferramentas utilizadas pelos grandes bancos
Pouquíssimos profissionais analisam dumps manualmente o tempo todo.
Grandes instituições normalmente utilizam ferramentas como:
IBM Fault Analyzer
IBM Debug Tool
IBM Application Performance Analyzer
IBM File Manager
Abend-AID (BMC)
Xpediter
IBM IPCS
IBM Developer for z/OS (IDz)
Essas ferramentas aceleram a análise ao transformar endereços, offsets e registradores em informações mais fáceis de interpretar.
Mesmo assim, elas não substituem o conhecimento. Um bom analista sabe interpretar as evidências e confirmar se a ferramenta está apontando a causa correta.
Um roteiro de investigação profissional
Sempre que receber um chamado de produção, siga uma sequência lógica:
Receber o chamado
↓
Anotar o ABEND
↓
Identificar STEP
↓
Consultar JESMSGLG
↓
Consultar JESYSMSG
↓
Verificar SYSOUT
↓
Ler CEEDUMP
↓
Localizar o traceback
↓
Encontrar o offset
↓
Relacionar com o código COBOL
↓
Analisar os dados de entrada
↓
Reproduzir o erro
↓
Corrigir
↓
Testar novamente
Essa abordagem evita "chutes" e torna a investigação repetível.
Os erros mais comuns dos Padawans
Corrigir o código sem ler as mensagens do sistema.
Ignorar o JCL e assumir que o COBOL está errado.
Não validar dados antes de cálculos e conversões.
Usar índices ou subscritos fora dos limites de tabelas.
Não conferir SQLCODE, FILE STATUS ou RESP/RESP2 após operações críticas.
Descartar o CEEDUMP sem analisá-lo.
Não reproduzir o problema em ambiente de testes antes de aplicar uma correção.
O perfil de um excelente investigador de ABEND
Os profissionais mais respeitados em grandes bancos raramente são aqueles que escrevem mais código.
São aqueles que conseguem responder rapidamente perguntas como:
O erro veio do programa ou do ambiente?
O problema é de dados, lógica ou infraestrutura?
O ABEND é a causa ou apenas a consequência?
Qual foi a primeira mensagem relevante?
É possível reproduzir o problema?
Eles tratam cada incidente como uma investigação técnica, baseada em evidências.
Conclusão
Dominar ABENDs não significa decorar centenas de códigos. Significa desenvolver uma forma estruturada de pensar.
O IBM Z sempre deixa pistas: mensagens, dumps, registradores, traceback, offsets e logs. Quem aprende a reuni-las deixa de agir por tentativa e erro e passa a trabalhar como um verdadeiro engenheiro de software.
Todo programador passa pelo primeiro S0C7, pelo primeiro S0C4 ou pelo primeiro ASRA. A diferença está em como reage. O iniciante vê apenas um erro. O profissional enxerga uma oportunidade de compreender melhor o funcionamento interno do sistema.
No fim, os melhores desenvolvedores COBOL não são aqueles que nunca encontram ABENDs. São aqueles que conseguem transformá-los em conhecimento, experiência e sistemas cada vez mais confiáveis.
Bellacosa Mainframe e o anime sujo Kaifuku Jutsushi
☕🩸 “KAIFUKU JUTSUSHI NO YARINAOSHI” — O HEALER QUE DESCOBRIU QUE O SISTEMA ESTAVA CORROMPIDO… E DECIDIU REESCREVER O BANCO DE DADOS DO MUNDO 💀🖥️🔥
O anime mais polêmico da fantasia moderna
Kaifuku Jutsushi no Yarinaoshi (Redo of Healer) não é um anime comum. Ele não tenta ser confortável. Não tenta ser “bonzinho”. E definitivamente não tenta agradar todo mundo.
A obra pega a fórmula clássica do RPG fantasy…
herói
party
magia
reinos
aventuras
…e joga tudo dentro de um datacenter em colapso moral.
O resultado é um anime extremamente controverso, brutal, psicológico e pesado.
🖥️ O healer que virou administrador do caos
O protagonista, Keyaru, começa como um simples healer.
Mas existe um detalhe terrível:
A habilidade de cura dele não apenas recupera corpos…
Ela também permite:
copiar habilidades
absorver experiências
acessar memórias
alterar estruturas físicas
reescrever pessoas
Na prática?
O cara não é um healer.
Ele é praticamente um:
root user humano
debugger biológico
editor vivo de memória RAM humana
☠️ O trauma que corrompeu o sistema
O anime rapidamente mostra algo importante:
O mundo usa healers como ferramentas descartáveis.
Keyaru sofre:
abuso
tortura
manipulação
lavagem psicológica
exploração constante
Até que ele faz algo absurdo:
Ele volta no tempo.
E decide executar o equivalente fantasy de:
RESTORE DATABASE BEFORE DISASTER
Só que agora…
ele lembra de tudo.
🔥 O conceito central: “reprocessar o sistema”
A ideia do anime é quase um rollback de produção.
Imagine:
um ambiente inteiro comprometido
usuários maliciosos no poder
corrupção total
privilégios abusivos
exploração institucionalizada
Então o administrador resolve:
voltar backup
alterar usuários
recriar permissões
manipular eventos
corrigir “falhas” usando métodos extremos
Esse é o núcleo de Redo of Healer.
🧠 O anime trabalha com desconforto psicológico
E aqui está o ponto importante:
Esse anime NÃO é recomendado para qualquer público.
Ele contém:
violência extrema
abuso psicológico
conteúdo sexual pesado
vingança explícita
cenas perturbadoras
Muita gente odeia a obra justamente porque ela atravessa limites que animes normalmente evitam.
Outros enxergam como uma crítica grotesca sobre:
abuso de poder
corrupção
trauma
vingança
degradação humana
⚔️ Keyaru é herói… vilão… ou malware?
Essa é a pergunta que divide a internet até hoje.
Porque Keyaru não segue a lógica tradicional do protagonista shounen.
Ele não busca:
justiça
amizade
redenção
heroísmo clássico
Ele busca:
controle absoluto.
E isso transforma o anime quase num estudo sobre corrupção emocional.
O personagem vira algo parecido com:
um sysprog traumatizado
com autoridade irrestrita
sem auditoria
sem RACF
sem compliance
sem limite operacional
Resultado?
O sistema inteiro entra em estado crítico.
💾 O lado técnico escondido na narrativa
Curiosamente, o anime trabalha conceitos que lembram muito arquitetura de sistemas:
Conceito Fantasy
Equivalente Mainframe
Cura/Reescrita
Update em memória
Volta no tempo
Restore de backup
Alterar pessoas
Manipulação de registros
Copiar habilidades
Clone de ambiente
Vingança planejada
Job batch programado
Controle mental
Override de segurança
Trauma acumulado
Corrupção de sistema
🎭 Por que o anime ficou tão famoso?
Porque ele virou uma bomba cultural.
Uns chamam de:
lixo
choque gratuito
edgy exagerado
Outros dizem que é:
ousado
perturbador
diferente
uma fantasia de vingança sem filtros
Mas uma coisa é impossível negar:
ninguém assiste e sai indiferente.
☕ Veredito Bellacosa Mainframe
Kaifuku Jutsushi no Yarinaoshi é como acessar um ambiente de produção completamente sem governança.
Você sabe que aquilo vai dar problema.
Mas não consegue parar de observar o desastre acontecendo.
É um anime pesado, controverso e desconfortável…
mas também extremamente eficiente em mostrar:
como trauma corrompe pessoas
como poder absoluto destrói limites
e como um sistema sem ética inevitavelmente entra em colapso.
💫 「As MÃOS nos Animes」— A Linguagem Silenciosa dos Heróis e Demônios
📓 Por El Jefe Midnight Lunch — edição Bellacosa Mainframe para mentes que pensam com os dedos e sentem com o código do coração.
Existem palavras que se perdem no vento, mas gestos que atravessam eras.
E entre todos os gestos, a mão — simples, humana, falha — é talvez a mais poderosa ferramenta narrativa dos animes.
No Japão, o gesto da mão vai muito além do toque físico: é símbolo de respeito, emoção, promessa, redenção e destino.
É o handshake entre mundos, o contrato invisível entre criador e criatura.
E no silêncio entre dois personagens, uma mão estendida fala mais do que mil episódios.
Hoje, no compasso suave da madrugada, o blog El Jefe Midnight Lunch abre o dossiê:
👉 As MÃOS nos Animes — a arte de tocar o invisível.
🤝 1. O toque de Naruto e Sasuke — A mão que encerra o ciclo do ódio
No auge da batalha final, dois meninos que começaram como rivais terminam de mãos dadas, ensanguentadas, mutiladas.
Um gesto simples, mas que simboliza o que nenhuma kunai conseguiu: a reconciliação.
Aquela mão que outrora lançou jutsus da destruição, agora sela a paz — uma assinatura de carne e alma.
💡 Curiosidade: Kishimoto desenhou aquela cena inspirado numa fotografia da Segunda Guerra, em que dois soldados inimigos se ajudam após a explosão de uma granada.
🫱 2. O aceno de Tanjiro — A mão que agradece ao destino
Em Kimetsu no Yaiba, Tanjiro não luta apenas com espada, mas com gentileza.
Seu aceno — sempre calmo, respeitoso, quase espiritual — é um lembrete de que até o inimigo merece compaixão.
Quando ele segura a mão de um demônio moribundo, o faz não por fraqueza, mas por entender que toda dor um dia foi humana.
💡 Fofoquice: no Japão, o gesto de “segurar a mão do adversário” é visto como yūjō no katachi — “a forma visível da empatia”.
✋ 3. O aperto de mãos de Luffy e Shanks — A promessa que fundou uma era
O gesto mais icônico de One Piece não foi um soco, mas um aperto de mãos e um chapéu entregue.
Shanks passa seu sonho adiante, e Luffy aceita com os olhos brilhando.
Ali, duas gerações de aventureiros selam um pacto invisível:
“Eu te dou o símbolo da liberdade. Cuide dele até me superar.”
💡 Curiosidade técnica: O gesto é inspirado em uma tradição samurai chamada katashiro, em que um guerreiro entrega um objeto a um aprendiz como substituto de seu próprio destino.
✊ 4. O punho de Edward Elric — A mão que busca redenção
Um braço de metal, uma alma ferida.
Em Fullmetal Alchemist, a mão de Edward é mais que prótese: é culpa materializada e esperança renascida.
Cada vez que ele toca alguém, o gesto vibra entre o perdão e o sacrifício.
💡 Easter-egg Bellacosa: O automail de Ed é o mainframe da redenção — hardware frio rodando sentimentos quentes.
🫶 5. As mãos unidas de Shinji e Kaworu — A conexão que não cabe na lógica
Em Neon Genesis Evangelion, a famosa cena do “toque” é a anti-ação:
um momento de silêncio em que duas almas quebradas se reconhecem.
Freud chamaria de “ato falho do coração”.
Eu chamo de o bug mais humano do sistema divino.
💡 Curiosidade: Hideaki Anno declarou que a cena nasceu de uma lembrança pessoal de isolamento — “era o toque que eu desejava ter recebido”.
🖐️ 6. A mão aberta de Goku — A saudação universal do guerreiro
Goku é o Maou da pureza.
A mão dele está sempre estendida: pra lutar, cumprimentar ou ajudar.
É o hello world do espírito japonês — simples, direto, sincero.
💡 Fofoquice: Na Toei Animation, há um manual interno chamado “Goku Smile Bible”, com regras para desenhar o gesto e a expressão “de confiança e amizade global”.
🫳 7. As mãos dançantes de Gojo Satoru — O toque proibido entre realidades
Gojo não toca — controla o toque.
Em Jujutsu Kaisen, a distância infinita entre suas mãos e o alvo é o próprio paradoxo da intimidade moderna:
tão perto que quase toca, tão longe que jamais encosta.
💡 Curiosidade filosófica: o poder “Limitless” foi inspirado na metáfora zen da flecha de Zenão, que nunca chega ao alvo — um toque eterno que nunca acontece.
🖤 8. As mãos em prece de Itachi Uchiha — O gesto que pede perdão ao próprio destino
A mão que mata o irmão é a mesma que o abençoa.
Itachi é o monge assassino, o guerreiro que reza pelo próprio erro.
Cada selo de mão em seus jutsus é uma confissão silenciosa.
💡 Easter-egg: os selos manuais de Itachi seguem a sequência de Kuji-in, gestos de meditação ninja do budismo esotérico japonês.
🪶 9. As mãos entre Chihiro e Haku — A promessa entre mundos
Em A Viagem de Chihiro, quando as mãos de Chihiro e Haku se tocam, o tempo para.
É o toque que devolve o nome, que reconecta a alma ao corpo.
💡 Curiosidade: Miyazaki descreveu essa cena como “a ponte mais pura entre inocência e memória”.
🌙 10. As mãos cruzadas de Light e L — O aperto que encerra o xadrez da mente
Em Death Note, o aperto de mãos entre Light e L é um microcosmo da série:
dois gênios, um segredo, e a tensão de quem sabe que o toque é tanto cumprimento quanto sentença.
💡 Curiosidade obscura: o storyboard original previa que o toque acendesse a música “Ave Maria” em piano — descartada por ser “excessivamente simbólica”.
🪷 Epílogo do Capitão Bellacosa
As mãos — sejam humanas, metálicas, demoníacas ou espirituais — são o teclado da emoção.
Com elas, os heróis digitam a própria história.
O Japão as trata com reverência: mão que constrói, salva, promete, destrói e recomeça.
E nós, que vivemos teclando no escuro, também deixamos nossas digitais invisíveis nas coisas e nas pessoas.
No fundo, cada clique, cada gesto, é uma saudação silenciosa ao outro lado da tela.
Então da próxima vez que estender a mão, lembre-se:
Pode não haver música, mas o toque certo é sempre um episódio inesquecível.
☕💻 El Jefe Midnight Lunch "Porque toda mão tem uma história — e toda história, uma assinatura invisível."
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
