☕ 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, 13 de abril de 2025

Teogonia - Quando o programador acordou em produção e descobriu que os deuses tinham RACF

Bellacosa Mainframe e o anime teogonia


☕ Um Café no Bellacosa Mainframe

 Teogonia

Quando o programador acordou em produção e descobriu que os deuses tinham RACF

Imagine que você foi contratado para dar manutenção em um sistema.

Não existe documentação.

Ninguém conhece todas as regras.

Os usuários estão em guerra.

Alguns possuem privilégios administrativos concedidos por entidades misteriosas.

Existem processos executando desde antes de você nascer.

E, quando você pergunta quem é o administrador do ambiente, alguém aponta para uma montanha e responde:

— Deus.

Bem-vindo a Teogonia.

Ou, mais precisamente:

神統記(テオゴニア) — Shintōki (Teogonia).

E talvez essa seja uma das primeiras pistas de que estamos diante de algo um pouco diferente do isekai industrial produzido aos quilômetros nos últimos anos.



1. A ficha do chamado

Título internacional: Teogonia
Título japonês: 神統記(テオゴニア)
Romanização: Shintōki (Teogonia)
Autor: Tsukasa Tanimai (谷舞司)
Ilustrador da light novel: Kouichiro Kawano
Mangá: arte de Shunsuke Aoyama
Diretor do anime: Kunihiro Mori
Composição da série: Tomoyasu Okubo
Estúdio: Asahi Production
Produção: WOWMAX
Música: Kenji Fujisawa
Estreia japonesa: 11 de abril de 2025 às 24h30 — tecnicamente já 12 de abril no calendário civil japonês
Final: junho de 2025
Episódios: 12
Gêneros: fantasia, aventura, ação, dark fantasy, guerra e isekai/reencarnação.

A transmissão japonesa ocorreu por Tokyo MX, Sun TV e BS11, enquanto a distribuição internacional ficou com a Crunchyroll em vários territórios, incluindo a América do Sul. (TVアニメ「神統記(テオゴニア)」公式サイト)

A equipe oficial confirma Mori na direção, Okubo na composição, Kawano no character design, Fujisawa na música e Asahi Production na animação. (TVアニメ「神統記(テオゴニア)」公式サイト)



2. Antes do anime existia uma novel

Aqui aparece aquela velha história que já conhecemos dos animes modernos:

Web Novel
    ↓
Light Novel
    ↓
Mangá
    ↓
Anime

A obra começou no Shōsetsuka ni Narō, plataforma que se tornou praticamente uma incubadora industrial de light novels e isekais japoneses.

A publicação online começou em 2017. Posteriormente, a Shufu to Seikatsu Sha adquiriu a obra e começou a publicá-la através do selo PASH! Books, em 2018. O mangá também começou em 2018, com desenhos de Shunsuke Aoyama. (Syosetu Blog)

Antes mesmo da estreia do anime, a editora/produtora anunciava que novel + mangá já haviam ultrapassado 500 mil exemplares em circulação. (東北新社)

Isso é importante.

Teogonia não surgiu como um projeto inventado por um comitê para preencher doze semanas de televisão.

O mundo já existia antes do anime.

E isso aparece no worldbuilding.


3. A história

O mundo de Teogonia não está bem.

E isso é excelente.

Não temos aquela tradicional cidade isekai:

🏰 muralha medieval
🍺 guilda
🧙 recepcionista
📜 aventureiro rank F
🐺 cinco lobos
💰 recompensa
❤️ elfa apaixonada

Aqui temos algo muito mais desagradável:

guerra.

Humanos lutam constantemente contra povos considerados semi-humanos, principalmente os Macaques, homens-macacos cinzentos, e os Ogres, homens-porcos.

Kai vive na aldeia de Lag.

Ele não é inicialmente o escolhido anunciado por uma profecia.

Não é rei.

Não é grande guerreiro.

Não possui um inventário mágico com 9.999 poções.

É essencialmente um garoto de fronteira tentando não morrer.

A sinopse oficial estabelece justamente esse cenário: Kai luta para proteger sua aldeia enquanto seus companheiros morrem em confrontos contra inimigos, alguns deles possuidores de poderes extraordinários associados às chamadas bênçãos ou proteções divinas. (TVアニメ「神統記(テオゴニア)」公式サイト)

Então ocorre o primeiro grande ABEND.

Kai começa a recordar coisas que jamais viveu.


4. O isekai acontece ao contrário

Aqui está uma das melhores ideias de Teogonia.

Normalmente:

Japão
  ↓
TRUCK-KUN
  ↓
Morte
  ↓
Deusa
  ↓
Reencarnação
  ↓
Mundo fantástico

Teogonia praticamente começa depois disso.

Kai já pertence àquele mundo.

Então começam a surgir fragmentos de memórias relacionadas a uma civilização tecnologicamente mais avançada.

O espectador percebe a implicação:

há outra existência enterrada dentro dele.

É quase um arquivo VSAM que alguém julgava apagado até Kai executar mentalmente:

READ PREVIOUS-LIFE
   INTO WS-MEMORY

E o retorno é:

FILE STATUS = 00

Ferrou.

😂

A Crunchyroll apresenta explicitamente a obra como fantasia isekai e descreve Kai recuperando memórias de outra vida durante a batalha. (Crunchyroll)

Mas o recurso é empregado de maneira relativamente discreta.

Não existe aquela necessidade desesperada de Kai dizer:

“No Japão fazíamos ketchup desta maneira!”

A vida anterior funciona muito mais como ruptura cognitiva.

Kai passa a perceber seu mundo de outra maneira.


5. Kai

Kai — CV: Mutsumi Tamura.

É justamente sua origem humilde que funciona.

Kai começa como uma pequena engrenagem dentro de uma máquina gigantesca.

Aos poucos descobre:

  • memórias inexplicáveis;

  • capacidades diferentes;

  • forças sobrenaturais;

  • divindades;

  • bênçãos;

  • territórios;

  • outros povos;

  • relações entre poder religioso e poder político.

Seu arco é menos:

“Como ficarei mais poderoso?”

e mais:

“Que mundo é este em que eu nasci?”

Essa diferença parece pequena.

Narrativamente, é enorme.


6. Jose

Jose — CV: Kana Hanazawa.

Ela ocupa uma posição importante dentro da sociedade humana e possui ligação direta com a estrutura de poder que Kai começa a conhecer.

E temos uma pequena bênção concedida pelos deuses do anime:

ela não existe exclusivamente para aumentar o harém de Kai.

Obrigado.

Podemos fechar o chamado.

😂

A relação entre Kai e Jose funciona também para demonstrar a distância social existente naquele mundo.

Eles não são simplesmente "garoto e garota".

Há posição, dever, poder e responsabilidade separando personagens.


7. Os outros personagens

O elenco principal oficial inclui:

Orha — Yoshitsugu Matsuoka
Vegin — Atsushi Miyauchi
Manso — Fukushi Ochiai/Fukunishi conforme romanizações de bases; o site oficial credita Fukushi/Fukunishi na grafia japonesa 福西勝也
Elsa — Manaka Iwami
Alue — Hana Tamegai
Polek — Hiroshi Naka
Zeyena — Yuko Kaida
Deus do Vale — Banjō Ginga.

O próprio elenco revela uma coisa interessante: o anime não se limita aos humanos. Macaques, Ogres e entidades divinas fazem parte da estrutura narrativa. (TVアニメ「神統記(テオゴニア)」公式サイト)


8. O verdadeiro protagonista talvez seja o mundo

E aqui Teogonia ganha pontos comigo.

Há animes em que o universo inteiro existe para servir ao protagonista.

O ferreiro existe para fabricar a espada dele.

A princesa existe para apaixonar-se por ele.

O dragão existe para ele derrotar.

A guilda existe para medir seu poder.

O rei existe para ficar impressionado.

Teogonia tenta construir a sensação contrária.

O mundo estava ali antes de Kai.

As guerras já existiam.

As fronteiras já existiam.

As divindades já existiam.

Os conflitos entre espécies já existiam.

Kai entrou em um sistema legado.

Meu amigo...

isso é mainframe.

😂


9. O Deus do Vale — ou o sysprog do universo

Aqui Teogonia começa a revelar sua camada mitológica.

Existem divindades associadas a lugares e povos.

Portanto, religião não funciona simplesmente como decoração medieval.

A geografia possui dimensão espiritual.

Um território pode estar relacionado a uma divindade.

Uma comunidade pode depender dessa proteção.

E determinados indivíduos possuem poderes extraordinários associados a essas forças.

Isso transforma o sistema mágico em algo próximo de uma infraestrutura política.

Pense:

IDENTIDADE
   ↓
TERRITÓRIO
   ↓
DIVINDADE
   ↓
PROTEÇÃO
   ↓
PODER
   ↓
SOBREVIVÊNCIA

Em linguagem Bellacosa:

o deus é praticamente o RACF daquele território.

Você atravessou uma fronteira?

ICH408I
USER(KAI)
RESOURCE(SACRED.VALLEY)
ACCESS INTENT(ENTER)
ACCESS ALLOWED(???)

10. O título Teogonia não foi escolhido por acaso

Aqui está um dos melhores easter eggs culturais.

Teogonia vem do grego:

theós = deus
gonía/gonos = nascimento/origem

A referência cultural inevitável é a Teogonia de Hesíodo, obra da Grécia Antiga que descreve genealogias e relações entre os deuses.

Isso fornece uma chave interessantíssima para interpretar o anime.

Talvez a pergunta fundamental não seja:

“Kai vai derrotar o inimigo?”

Mas:

“De onde vem a ordem divina que governa aquele mundo?”

A história parece inicialmente militar.

Depois torna-se política.

Depois territorial.

Depois religiosa.

E finalmente cosmológica.


11. Humanos versus semi-humanos

Essa é provavelmente a camada temática mais interessante.

Inicialmente recebemos uma interface muito conveniente:

HUMANS     = GOOD
DEMIHUMANS = ENEMY

Mas mundos interessantes raramente permanecem binários.

A existência de povos diferentes, estruturas próprias, territórios e entidades sobrenaturais começa a levantar uma questão desconfortável:

quem decidiu quem é o monstro?

Kai nasceu humano.

Naturalmente interpreta o conflito pelo ponto de vista humano.

Mas isso não significa que possua uma visão objetiva da história.

Aqui aparece uma leitura possível — e digo leitura, não uma afirmação explícita do autor — sobre alteridade, propaganda de guerra e desumanização do inimigo.

Toda sociedade em guerra produz uma narrativa:

Nós estamos defendendo nossa terra.

Curiosamente...

o inimigo frequentemente acredita exatamente na mesma coisa.


12. Guerra por recursos

Outra leitura interessante está no território.

Os povos não parecem lutar simplesmente porque alguém acordou numa terça-feira pensando:

“Hoje vou praticar genocídio.”

Há competição por:

  • terras;

  • alimento;

  • segurança;

  • espaço;

  • recursos;

  • proteção;

  • influência divina.

Isso aproxima Teogonia de uma fantasia antropológica.

Quando recursos são escassos, sociedades entram em conflito.

Quando uma sociedade conquista território, outra perde.

Quando existem forças sobrenaturais territorializadas, controlar a terra pode significar também controlar poder religioso.


13. As aventuras

Sem transformar isto num festival de spoilers, a primeira temporada acompanha uma escalada muito clara.

Começamos com:

sobrevivência da aldeia.

Kai combate Macaques e Ogres.

Depois:

descoberta.

As memórias e habilidades de Kai começam a modificar sua relação com aquele mundo.

Depois:

exploração.

O Vale e suas forças tornam-se fundamentais.

Depois:

divindades.

A existência de poderes muito maiores que aqueles conhecidos pelo aldeão começa a ficar evidente.

Depois:

povos diferentes.

A guerra deixa de parecer apenas uma batalha local.

Finalmente:

Kai deixa de ser simplesmente Kai da aldeia de Lag.

Seu papel naquele universo torna-se progressivamente maior.

É uma expansão clássica:

GAROTO
 ↓
ALDEIA
 ↓
VALE
 ↓
POVOS
 ↓
DEUSES
 ↓
MUNDO

14. A mensagem oculta mais bonita

Para mim existe uma ideia particularmente forte:

conhecimento muda a maneira como enxergamos o mundo.

As memórias anteriores de Kai são importantes não apenas porque podem ajudá-lo.

Elas lhe fornecem referencial.

Imagine uma pessoa medieval descobrindo conceitos modernos.

Ela não precisa possuir um smartphone.

Basta descobrir que:

“As coisas não precisam necessariamente funcionar desta maneira.”

Esse pensamento é revolucionário.

E vale para tecnologia, política, religião e sociedade.


15. Outra mensagem: poder possui responsabilidade

Os "abençoados" ou portadores de proteção representam uma desigualdade brutal.

Uma pessoa pode valer militarmente por dezenas de outras.

Isso produz uma questão interessante:

se Deus lhe deu poder, isso lhe deu também autoridade?

Poder físico não produz automaticamente legitimidade moral.

É uma questão antiga.

E extremamente atual.


16. O estúdio — Asahi Production

A Asahi Production não está no mesmo patamar de reconhecimento internacional de nomes como MAPPA, Madhouse, Bones, Ufotable ou Kyoto Animation.

E isso aparece.

Teogonia não é um espetáculo técnico permanente.

Há economia de animação.

Algumas batalhas poderiam ter mais fluidez.

Certos ambientes poderiam possuir mais detalhamento.

Mas existe uma decisão inteligente:

priorizar atmosfera e narrativa.

Kunihiro Mori dirige a série, enquanto Koichiro Kawano — que já trabalhava nas ilustrações da novel — participa diretamente do character design do anime. Isso ajuda a manter continuidade visual entre as encarnações da obra. (TVアニメ「神統記(テオゴニア)」公式サイト)


17. A música

A trilha é de Kenji Fujisawa.

A abertura é:

“Shōdō” — Noda Emi.

O encerramento:

“Tsuki to Boku to Atarashii Jibun” — STU48.

Ambos são confirmados oficialmente pela produção. (TVアニメ「神統記(テオゴニア)」公式サイト)

O contraste do encerramento com o mundo violento também reforça o tema de transformação pessoal de Kai.


18. Classificação indicativa

Teogonia não deve ser confundido com fantasia infantil.

Temos:

  • guerra;

  • mortes;

  • sangue;

  • violência;

  • ameaça constante;

  • criaturas humanoides;

  • temas religiosos;

  • tensão psicológica.

Não é Goblin Slayer em brutalidade explícita.

Mas também não é Pokémon.

Eu o colocaria conceitualmente na faixa de adolescentes mais velhos, lembrando que a classificação oficial varia conforme plataforma e território.


19. E a censura?

Aqui precisamos separar evidência de boato.

Não encontrei evidência confiável de uma grande controvérsia de censura envolvendo Teogonia, nem de cortes internacionais importantes que tenham se tornado parte relevante da história da produção.

A obra contém violência e temas potencialmente pesados, mas não ficou culturalmente marcada por uma batalha de censura.

Portanto:

CENSORSHIP-GATE STATUS:
NO MAJOR INCIDENT FOUND

Melhor dizer isso do que inventar uma polêmica onde ela não existe.


20. Existe mangá?

Sim.

E é importante.

A adaptação em mangá possui arte de Shunsuke Aoyama, informação confirmada pelo próprio site oficial do anime. (TVアニメ「神統記(テオゴニア)」公式サイト)

A publicação começou em 2018, pela linha PASH!/Comic PASH!. Bases bibliográficas atuais registram 14 volumes compilados. (Wikipedia)

Isso significa que quem terminar o anime e pensar:

“Quero mais desse mundo.”

tem bastante coisa para explorar.


21. E light novel?

Também.

Tsukasa Tanimai escreveu a história, com Kouichiro Kawano nas ilustrações da edição publicada.

A light novel comercial começou em 30 de março de 2018, após a origem como web novel. A edição impressa possui 3 volumes registrados. (Wikipedia)

Isso gera uma situação curiosa: a franquia ganhou bastante expansão pelo mangá apesar da quantidade relativamente pequena de volumes da light novel impressa.


22. Games?

Aqui também vale não transformar desejo em informação.

Não encontrei um videogame oficial relevante de Teogonia associado à franquia até agora.

Nada comparável às adaptações multimídia de Sword Art Online, Overlord, Re:Zero etc.

O ecossistema confirmado é essencialmente:

web novel → light novel → mangá → anime → música/merchandising.


23. Impacto cultural

Não colocaria Teogonia no mesmo nível cultural de:

Mushoku Tensei
Re:Zero
Sword Art Online
That Time I Got Reincarnated as a Slime
Overlord.

Seria exagero.

Mas existe um dado objetivo importante: novel + mangá já haviam ultrapassado 500 mil exemplares antes da transmissão televisiva, portanto não estamos falando de uma propriedade completamente desconhecida que surgiu do nada. (東北新社)

Seu interesse está principalmente em outra coisa:

mostrar que o isekai ainda pode funcionar sem obedecer integralmente ao template RPG.


24. O que Teogonia tem de diferente?

Essa é a pergunta fundamental.

O protagonista não fica olhando permanentemente para:

LEVEL: 287
HP: 99999
MP: 99999
SKILL: INFINITE COOKING
TITLE: GOD SLAYER

😂

O sistema sobrenatural está mais integrado ao mundo que à interface de videogame.

Além disso:

não existe dependência central de guilda;

não existe obsessão por níveis;

não existe economia narrativa baseada em skills infinitas;

o harém não domina a história;

a civilização possui conflitos anteriores ao protagonista;

religião interfere no funcionamento do mundo;

geografia possui importância;

os povos têm interesses próprios;

Kai não começa controlando tudo.

É quase uma reação silenciosa ao isekai industrializado.


25. Bellacosa Mainframe dá a nota

Agora podemos abrir o painel do operador.

História — 8/10

Boa construção gradual. Não reinventa fantasia, mas organiza elementos conhecidos de maneira inteligente.

Worldbuilding — 9/10

Provavelmente seu maior mérito.

Deuses, povos, fronteiras, bênçãos e território formam um sistema interessante.

Personagens — 7,5/10

Kai funciona muito bem como observador e agente da transformação. O elenco secundário poderia receber ainda mais desenvolvimento.

Animação — 6,5/10

Funcional, algumas vezes boa, mas claramente limitada pelo porte da produção.

Atmosfera — 8,5/10

Aqui funciona.

Você sente que aquele mundo é perigoso.

Originalidade dentro do isekai — 8/10

Não inventa a reencarnação, mas evita várias muletas contemporâneas.

Fanservice desnecessário

Baixo.

Os deuses ouviram nossas preces.

😂

Harém industrial

Sistema não instalado.

Truck-kun

Chamado encerrado sem intervenção.


Nota Bellacosa

⭐ 8,2 / 10 cafés

☕☕☕☕☕☕☕☕🥄

Não é uma obra-prima técnica.

Não é o novo Frieren.

Não possui a animação de Demon Slayer.

Não possui ainda o peso cultural de Mushoku Tensei.

Mas possui algo que considero cada vez mais valioso:

identidade.

Teogonia parece interessado em contar a história daquele mundo, não simplesmente em construir um parque de diversões para o protagonista.


26. O verdadeiro easter egg de Teogonia

No começo pensamos:

Kai está descobrindo seus poderes.

Depois percebemos:

Kai está descobrindo o Vale.

Mais tarde:

Kai está descobrindo os deuses.

Mas talvez a verdadeira história seja:

Kai está descobrindo que a versão do mundo ensinada pela sociedade humana não corresponde necessariamente ao mundo inteiro.

Isso é muito mais interessante.

É a diferença entre trabalhar durante vinte anos executando:

//STEP01 EXEC PGM=XPTO

e finalmente perguntar:

“Mas quem escreveu XPTO?”

Silêncio no CPD.

O operador olha para o programador.

O programador olha para o sysprog.

O sysprog olha para um load module compilado em 1987.

Ninguém sabe.

Então uma voz profunda ecoa do fundo do datacenter:

“EU ESCREVI.”

Kai se vira.

É o Deus do Vale.

E ele ainda programa em COBOL 74.

☕😂


Veredito

Teogonia é um isekai para quem já está começando a ficar cansado de isekai.

Sua maior qualidade não está no poder de Kai.

Está na sensação de que existe alguma coisa muito maior do que Kai.

Deuses antigos, territórios, povos, guerras, memórias de outra existência e uma estrutura cosmológica que ele mal começa a compreender.

O protagonista não recebeu o manual do sistema.

Recebeu acesso de usuário.

E está descobrindo produção na unha.

Esse, meus amigos do Bellacosa Mainframe, é o tipo de sistema legado que vale a pena investigar.

Site oficial de Teogonia

quarta-feira, 9 de abril de 2025

Dr. COBOL, IA e o Caso do S0C7: quando o novato entrou no CPD achando que aprenderia uma linguagem e descobriu que o paciente tinha 47 sistemas dependentes

 

Bellacosa Mainframe e a ia ensinando cobol

☕ Um Café no Bellacosa Mainframe

Dr. COBOL, IA e o Caso do S0C7: quando o novato entrou no CPD achando que aprenderia uma linguagem e descobriu que o paciente tinha 47 sistemas dependentes

🩺 A IA pode se tornar o melhor mentor de um novo profissional COBOL? Talvez. Mas antes ela terá de aprender uma regra básica da medicina, do mainframe e da vida corporativa: o sintoma quase nunca é a doença.

Imagine a cena.

Segunda-feira. 08h13.

O jovem programador COBOL acaba de chegar à empresa. Notebook novo, crachá ainda cheirando a plástico, LinkedIn atualizado com “Mainframe Developer”, uma caneca estrategicamente posicionada ao lado do teclado e a confiança de quem terminou três cursos no fim de semana.

Ele aprendeu:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

PROCEDURE DIVISION.
    DISPLAY 'HELLO WORLD'.
    STOP RUN.

Fantástico.

O mainframe, entretanto, não está nem um pouco impressionado.

Às 08h17 chega uma mensagem:

JOB PAYR042 - ABEND S0C7

O jovem olha para a tela.

A tela olha para o jovem.

Um silêncio constrangedor instala-se no CPD.

Então entra nosso médico imaginário de sistemas legados: manca metaforicamente pelos corredores digitais, olha para o erro, despreza a primeira explicação e sentencia:

“Todo mundo mente. Inclusive os dados.”

☕

Bem-vindo ao Bellacosa Mainframe Hospital.

O paciente de hoje é um sistema com quarenta anos de idade, dois bilhões de registros, sete aplicações dependentes, três copybooks diferentes descrevendo supostamente a mesma coisa e um comentário escrito por alguém chamado Ferreira em 1998:

* ALTERADO CONFORME SOLICITACAO

Qual solicitação?

Ninguém sabe.

Ferreira aposentou-se.

A solicitação provavelmente foi impressa.

O papel talvez tenha virado confete em alguma festa de fim de ano de 2007.

E você achava que aprender COBOL era decorar PERFORM.


🧬 Primeiro diagnóstico: COBOL não é a doença

Existe uma confusão muito comum entre quem começa.

A pessoa pensa:

“Vou aprender COBOL.”

Perfeito.

COBOL é relativamente simples de compreender.

Considere:

IF SALDO >= VALOR-SAQUE
    SUBTRACT VALOR-SAQUE FROM SALDO
    MOVE '00' TO COD-RETORNO
ELSE
    MOVE '51' TO COD-RETORNO
END-IF.

Não precisamos convocar Alan Turing, Grace Hopper, três monges tibetanos e um DBA certificado para compreender o objetivo geral.

Há saldo?

Sim?

Debita.

Não?

Retorna alguma condição de rejeição.

O problema aparece cinco minutos depois.

Você pergunta:

“Onde veio SALDO?”

Talvez de uma estrutura definida no próprio programa.

Talvez de uma copybook:

COPY CONTACLI.

Talvez tenha vindo do Db2.

Talvez tenha sido lido de VSAM.

Talvez tenha chegado numa COMMAREA do CICS.

Talvez tenha vindo de MQ.

Talvez o programa esteja processando um arquivo produzido três jobs antes.

E pronto.

O primeiro exame revelou uma coisa importante:

você não entrou para estudar apenas uma linguagem. Entrou para estudar um organismo.


🩻 A anatomia do paciente mainframe

O iniciante normalmente conhece as partes separadamente:

COBOL
JCL
VSAM
Db2
CICS
IMS
MQ
RACF
JES2
SORT
GDG
SDSF

Isso parece uma coleção de siglas inventada por alguém que recebia bônus por cada abreviação criada.

Mas o profissional experiente começa a enxergar outra coisa.

Ele vê relações.

Imagine um processamento batch:

Scheduler
    |
    v
   JCL
    |
    v
   JES2
    |
    v
Programa COBOL
  /        \
 v          v
VSAM       Db2
 |
 v
SORT
 |
 v
GDG

Agora um fluxo online:

Usuário
   |
   v
Terminal / Aplicação
   |
   v
 CICS
   |
   v
 COBOL
 /    \
v      v
Db2   VSAM
 |
 v
 MQ
 |
 v
Outro sistema

O iniciante vê caixas.

O veterano vê setas.

E sistemas corporativos quebram assustadoramente bem justamente nas setas.

Esse é um conceito que vale guardar.


🩺 “O programa está certo.”

Maravilha.

O arquivo está certo?

A copybook utilizada para ler o arquivo está certa?

O programa produtor usa a mesma versão?

O consumidor espera o mesmo LRECL?

A codificação é a esperada?

O job executou na sequência correta?

A tabela recebeu todos os registros?

O programa anterior terminou com RC=0 ou alguém aceitou RC=4 como “deve estar tudo bem”?

Uma alteração aparentemente minúscula pode parecer:

01 CLIENTE.
   05 CODIGO       PIC 9(08).
   05 NOME         PIC X(30).

Alguém resolve modernizar gloriosamente:

01 CLIENTE.
   05 CODIGO       PIC 9(08).
   05 NOME         PIC X(40).

“São só dez bytes.”

Dez bytes.

A frase equivalente no mainframe a:

“Acho que esse cogumelo não é venenoso.”

O programa novo entende 48 bytes.

Um programa antigo ainda espera 38.

O arquivo passa pela cadeia.

PROGRAMA A
   |
   | layout novo
   v
ARQUIVO
   |
   | layout antigo
   v
PROGRAMA B
   |
   v
💥

E lá aparece nosso amigo:

ABEND S0C7

O sintoma está no Programa B.

A doença nasceu no Programa A.

House ficaria satisfeito.


🤖 Entra a IA na sala de diagnóstico

Agora acontece algo que nenhuma geração anterior de programadores teve nessa escala.

O novato pode perguntar:

“O que é um S0C7?”

A IA explica.

Depois ele pergunta:

“Explique como se eu nunca tivesse trabalhado com mainframe.”

Ela simplifica.

Depois:

“Mostre um exemplo com PIC X sendo tratado como número.”

Ela mostra.

Depois:

“Como um arquivo desalinhado poderia provocar isso?”

Mais uma explicação.

Depois:

“Que informações eu deveria procurar no dump?”

Mais contexto.

Depois:

“Não me dê a solução. Faça perguntas para eu encontrar a causa.”

E aqui começa uma coisa realmente poderosa.

Porque IA deixa de ser apenas Google com diálogo.

Ela pode transformar-se em mentor.


🧠 A IA não precisa dar respostas. Ela pode construir raciocínio

Essa talvez seja uma das maiores oportunidades do ensino técnico moderno.

Suponha que você diga:

Meu programa terminou com S0C7.

Uma IA ruim para treinamento responde:

“O problema está em um campo numérico contendo dados inválidos. Faça X.”

Você corrige.

Funcionou.

Parabéns.

Você resolveu um incidente e talvez tenha aprendido quase nada.

Agora imagine uma IA configurada como mentor:

Em qual instrução ocorreu o abend?

Você responde.

Qual campo estava sendo usado nessa instrução?

Responde.

Como esse campo é declarado?

Responde.

De onde veio o conteúdo dele?

Responde.

Ele foi recebido de arquivo, Db2, CICS ou calculado anteriormente?

Arquivo.

Qual é o layout esperado?

Você procura.

O programa produtor utiliza a mesma copybook?

Hmmmmm.

Agora o cérebro começa a trabalhar.

Temos:

SINTOMA
   |
   v
HIPÓTESE
   |
   v
EVIDÊNCIA
   |
   v
TESTE
   |
   v
RESULTADO
   |
   v
NOVA HIPÓTESE

Isso é troubleshooting.

E troubleshooting é uma das competências mais importantes que você pode desenvolver em mainframe.


🔬 Diagnóstico diferencial para programadores

Na medicina investigativa, vários problemas podem produzir sintomas parecidos.

No mainframe também.

Um job falhou.

Por quê?

O iniciante frequentemente faz:

FALHOU
  |
  v
ACHOU UMA COISA ESTRANHA
  |
  v
DEVE SER ISSO

Perigoso.

Uma abordagem melhor:

FALHOU
  |
  +--> hipótese A
  |
  +--> hipótese B
  |
  +--> hipótese C
  |
  +--> hipótese D

Depois coletamos evidência.

Por exemplo, diante de um erro envolvendo dados:

Hipótese A: campo numérico contém caractere.

Hipótese B: layout utilizado está incorreto.

Hipótese C: arquivo foi produzido com tamanho diferente.

Hipótese D: área de memória foi sobrescrita anteriormente.

Hipótese E: registro inesperado entrou no processamento.

Agora investigamos.

A IA pode ajudar tremendamente nisso.

Mas existe uma regra importante:

Nunca confunda uma hipótese eloquentemente escrita com uma hipótese comprovada.

Modelos de IA são excelentes em produzir explicações plausíveis.

Produção exige evidência.


🦯 Primeiro easter egg: “Everybody lies”

Nosso médico televisivo imaginário repetiria que todo mundo mente.

No mainframe poderíamos adaptar:

Everybody lies. Especially the input file.

O arquivo se chama:

CLIENTES.VALIDADO.DADOS

Não significa que está validado.

Existe uma coluna chamada:

DATA_VALIDACAO

Não significa que alguém validou.

Existe um campo:

05 VALOR-NUMERICO PIC 9(09).

Também não significa que aqueles bytes realmente contenham números.

A máquina acredita em bytes.

Nós acreditamos em nomes.

Essa diferença já derrubou muitos programas.


☕ O antigo mentor da mesa ao lado

Antes da IA, existia uma tecnologia incrivelmente avançada chamada:

Carlos.

Carlos trabalhava na empresa desde 1987.

Você chegava:

“Carlos, S0C7.”

Carlos olhava por dois segundos.

“Vê o arquivo do step anterior.”

Você perguntava:

“Por quê?”

Ele dizia:

“Cara de layout.”

Como assim cara de layout?

😂

Anos depois você entende.

Carlos não estava praticando magia.

Ele possuía uma base estatística mental construída durante milhares de incidentes.

30 anos
   +
5000 incidentes
   +
milhares de dumps
   +
mudanças
   +
erros
   +
produção
   =
"cara de layout"

Experiência é uma espécie de modelo probabilístico ambulante.

O veterano vê sintomas e atualiza mentalmente probabilidades.

Quase um sysprog bayesiano.


🤖 Agora podemos carregar um “Carlos virtual” conosco

A IA pode ocupar parte desse espaço.

Ela nunca dorme.

Não precisa sair para almoçar.

Não diz:

“Leia o manual.”

Mesmo quando, sejamos justos, você deveria ler o manual.

Ela pode explicar DISP=(NEW,CATLG,DELETE) dez vezes.

Primeiro tecnicamente.

Depois usando analogia.

Depois visualmente:

DISP=(NEW,CATLG,DELETE)
       |    |      |
       |    |      +-- Se der errado, apagar
       |    +--------- Se der certo, catalogar
       +-------------- Dataset novo

Ainda não entendeu?

Ela pode comparar com criar um arquivo no Windows.

Ainda não?

Pode construir um exercício.

Ainda não?

Pode perguntar onde está sua dúvida.

Isso resolve um problema pedagógico enorme.


😶 “Professor, eu não entendi.”

Na sala de aula existe vergonha.

O professor explica.

Você pergunta.

Ele explica novamente.

Você continua sem entender.

Olha ao redor.

Todo mundo parece ter entendido.

Provavelmente metade também não entendeu, mas ninguém quer ser o próximo.

Você pensa:

“Vou pesquisar depois.”

Nunca pesquisa.

A IA elimina boa parte dessa pressão social.

Você pode perguntar:

“Explique outra vez.”

“Mais simples.”

“Agora como uma analogia de restaurante.”

“Agora esqueça o restaurante porque piorou.”

😂

Essa adaptabilidade é espetacular.


🗺️ Mas a maior vantagem talvez seja mostrar o mapa

Um dos maiores sofrimentos do novo profissional é não saber onde cada tecnologia se encaixa.

Você aprende JCL.

Depois Db2.

Depois CICS.

Depois VSAM.

Mas ninguém mostra o bairro inteiro.

A IA pode responder:

“Estou estudando COBOL. Onde JCL, Db2, CICS, VSAM e MQ entram?”

E criar:

                SISTEMA CORPORATIVO
                       |
          +------------+------------+
          |                         |
        BATCH                     ONLINE
          |                         |
         JCL                       CICS
          |                         |
        COBOL                     COBOL
       /     \                   /     \
    VSAM     Db2              VSAM     Db2
      \       /                  |
       \     /                   MQ
        DADOS                    |
                            OUTROS SISTEMAS

Agora o estudante ganha um modelo mental.

Depois ele aprofunda cada caixa.

Esse aprendizado é muito melhor do que colecionar siglas.


🌉 IA também pode funcionar como tradutora entre gerações tecnológicas

Imagine alguém vindo de Java.

Podemos explicar conceitos mainframe construindo pontes:

Mundo distribuído          Mainframe

Aplicação                   Programa COBOL
SQL database                Db2
Messaging                   MQ
Transaction manager         CICS
Batch orchestration         JCL + scheduler
Authorization               RACF/SAF
Logs/telemetria             SMF + ferramentas

Mas há uma pegadinha importantíssima.

Analogias ajudam.

Analogias também enganam.

CICS não é simplesmente “Spring Boot antigo”.

JCL não é “um shell script mais velho”.

RACF não é “Active Directory do mainframe”.

Essas comparações podem ensinar uma primeira aproximação, mas depois precisamos perguntar:

“Onde essa analogia deixa de funcionar?”

Essa pergunta é maravilhosa.

Ela transforma conhecimento superficial em conhecimento estrutural.


🏺 O segundo mistério: arqueologia corporativa

Chegamos a uma área em que IA encontra dificuldades especiais.

Veja:

IF COD-AGENCIA = 9999
    PERFORM ROTINA-ESPECIAL
END-IF.

Você pergunta:

“Por que 9999?”

O código não responde.

A documentação não responde.

O Git não responde porque aquele programa nasceu quando Git era apenas o verbo inglês para alguém desagradável.

O comentário informa:

* ALT FERREIRA 12/09/1997

Obrigado novamente, Ferreira.

A IA pode explicar o comportamento.

Pode investigar dependências.

Pode sugerir hipóteses.

Mas talvez só uma pessoa saiba:

“Em 1997 a agência 9999 representava uma unidade centralizadora criada durante uma migração.”

E lá está Carlos novamente.

Tomando café.


🏦 Código possui regras de negócio fossilizadas

Esse é um ponto fundamental para o iniciante.

Você pode encontrar:

IF DIAS-ATRASO > 90
    PERFORM BLOQUEIA-OPERACAO
END-IF.

Programação trivial.

Mas por que 90?

Legislação?

Norma regulatória?

Contrato?

Política comercial?

Uma limitação técnica histórica?

Uma regra que mudou em 2006 e ninguém percebeu?

O código pode explicar como.

O código nem sempre explica por quê.

E profissionais COBOL frequentemente trabalham justamente onde tecnologia e negócio se encontram.

Banco.

Seguro.

Governo.

Cartões.

Logística.

Aviação.

Telecomunicações.

Você não pode ser excelente nesses ambientes conhecendo apenas sintaxe.


🧠 É por isso que JUNIOR + IA = SENIOR é uma conta errada

Existe uma fantasia corporativa muito tentadora:

1 JUNIOR
+
CHATGPT
=
1 SENIOR

Não.

A equação mais razoável é:

JUNIOR + IA
=
JUNIOR MUITO MAIS ACELERADO

Enquanto:

SENIOR + IA
=
SENIOR COM UM EXOESQUELETO COGNITIVO

O júnior ganha velocidade para descobrir conceitos.

O sênior ganha velocidade para analisar, documentar, comparar, automatizar e investigar.

Mas experiência operacional não aparece magicamente porque alguém colocou um prompt bonito.


🚨 O terceiro caso da noite: competência terceirizada

Existe uma doença nova chegando ao hospital.

Chamaremos de:

Síndrome do Ctrl+C / Ctrl+V Cognitivo

Sintomas:

O desenvolvedor recebe erro.

Copia para IA.

Recebe resposta.

Copia solução.

Executa.

Funcionou.

Fecha chamado.

No dia seguinte aparece problema parecido.

Ele copia novamente.

Após dois anos parece possuir dois anos de experiência.

Na realidade talvez possua:

730 dias usando respostas prontas

Isso é perigoso.

Porque conhecimento não é somente conseguir produzir uma ação correta.

Conhecimento significa conseguir responder:

Por que essa ação é correta?

Quando ela seria errada?

Quais consequências pode gerar?

Como provar que resolveu?


🧪 Receita Bellacosa para aprender com IA sem virar passageiro

Quando encontrar um problema, experimente este fluxo:

1. LEIA O ERRO
       |
2. FORMULE SUA HIPÓTESE
       |
3. PEÇA À IA OUTRAS HIPÓTESES
       |
4. PROCURE EVIDÊNCIAS
       |
5. CONSULTE DOCUMENTAÇÃO
       |
6. TESTE EM AMBIENTE SEGURO
       |
7. COMPARE RESULTADOS
       |
8. DOCUMENTE O APRENDIZADO

Observe algo importante.

A IA entrou no passo 3.

Não no passo 1.

Essa pequena diferença muda tudo.


🎓 Transforme a IA num examinador inconveniente

Um prompt educativo muito melhor do que:

“Resolva este problema.”

é:

“Estou aprendendo COBOL. Não me dê a resposta. Faça uma pergunta de cada vez para me ajudar a diagnosticar este erro.”

Agora você está usando IA como mentor.

Outra excelente instrução:

“Quando eu responder, diga se minha hipótese faz sentido e peça evidências.”

Ou:

“Apresente três causas plausíveis, mas não diga qual é a correta. Diga como testar cada uma.”

Isso começa a formar mentalidade investigativa.


🔐 Há ainda um paciente que ninguém pode esquecer: segurança

O iniciante descobre que IA explica código maravilhosamente.

Então pensa:

“Vou colar este programa inteiro.”

Calma.

Aquele programa pode conter:

  • regras de negócio proprietárias;

  • nomes de tabelas;

  • estruturas internas;

  • endpoints;

  • dados pessoais;

  • informações financeiras;

  • arquiteturas sensíveis;

  • credenciais acidentalmente embutidas;

  • detalhes de autorização;

  • nomes de datasets;

  • informações reguladas.

Em ambiente corporativo:

IA + MAINFRAME

sempre deveria vir acompanhado de:

IA
+
SEGURANÇA
+
GOVERNANÇA
+
CLASSIFICAÇÃO DE DADOS
+
COMPLIANCE

A pergunta não é apenas:

“A IA consegue analisar?”

Também é:

“Eu tenho autorização para fornecer isso a ela?”


📚 Quarto easter egg: o manual não morreu

Há uma cena recorrente no suporte técnico.

Pergunta:

“O que significa esse parâmetro?”

Resposta:

“Segundo a documentação…”

O iniciante suspira.

A IA mudou a interface.

Não mudou a necessidade de fonte confiável.

Especialmente em:

  • CICS;

  • Db2;

  • RACF;

  • z/OS;

  • compiladores;

  • opções de runtime;

  • APARs;

  • parâmetros;

  • performance;

  • segurança.

Use IA para compreender documentação.

Não transforme IA em substituta infalível da documentação.

O pipeline saudável é:

IA
 |
 v
EXPLICAÇÃO
 |
 v
DOCUMENTAÇÃO
 |
 v
VALIDAÇÃO
 |
 v
LABORATÓRIO
 |
 v
CONHECIMENTO

🧙‍♂️ O veterano também muda de função

Aqui encontramos algo deliciosamente paradoxal.

Quanto melhor ficar a IA, mais interessante pode ficar o trabalho do mentor humano.

Carlos não precisa mais passar cinquenta minutos explicando:

PIC S9(7)V99 COMP-3

A IA faz isso.

Carlos pode gastar os cinquenta minutos explicando:

“Por que nós usamos esse campo dessa maneira neste sistema?”

Essa pergunta é infinitamente mais rica.

O veterano deixa de ser:

MANUAL HUMANO DE SINTAXE

e passa a ser:

MENTOR
ARQUITETO
CONTEXTUALIZADOR
GUARDIÃO DA MEMÓRIA
CRÍTICO

Talvez a IA não esteja reduzindo o valor do veterano.

Talvez esteja finalmente libertando o veterano para transmitir justamente o conhecimento que nunca coube nos manuais.


🧓➡️🤖➡️🧑‍💻 E podemos preservar conhecimento corporativo

Agora imagine algo ainda maior.

Carlos explica:

“Quando o job X termina com RC=4 durante o fechamento, veja primeiro o arquivo Y. Há uma situação histórica em que ele chega incompleto.”

Esse conhecimento é registrado.

Validado.

Classificado.

Documentado.

Depois colocado numa base corporativa de conhecimento.

VETERANO
   |
   v
EXPERIÊNCIA
   |
   v
DOCUMENTAÇÃO
   |
   v
KNOWLEDGE BASE
   |
   v
IA CORPORATIVA
   |
   v
NOVO PROFISSIONAL

Agora não estamos mais falando apenas de uma IA que conhece COBOL.

Estamos criando uma IA que consegue ajudar pessoas a compreender aquele ambiente.

Isso pode ser revolucionário para organizações com décadas de sistemas legados.


🚀 Minha trilha de seis níveis para o novo COBOLzeiro

Começaria pequeno.

Nível 1 — Aprenda a língua

COBOL básico.

Divisions.

Data Division.

Picture clauses.

MOVE.

IF.

PERFORM.

READ.

WRITE.

CALL.

Aqui a IA funciona muito bem como professora particular.

Nível 2 — Descubra o ecossistema

Comece JCL, datasets, JES, SDSF, Db2, VSAM e CICS.

Não precisa dominar tudo.

Construa o mapa.

Nível 3 — Aprenda a seguir dados

Pergunte sempre:

De onde veio?
Onde está agora?
Quem altera?
Para onde vai?
Quem consome depois?

Esse exercício é poderosíssimo.

Nível 4 — Quebre coisas

Em laboratório, claro.

Cause:

S0C7
S0C4
arquivo inexistente
RC diferente de zero
SQLCODE negativo
registro inválido

Depois investigue.

Quem nunca viu nada quebrado fica perigosamente assustado quando produção quebra.

Nível 5 — Faça diagnóstico, não caça ao Google

Crie hipóteses.

Colete evidências.

Leia logs.

Compare antes/depois.

Aprenda dumps.

Nível 6 — Aprenda o negócio

Finalmente pergunte:

“Por que esse sistema existe?”

Essa é provavelmente uma das perguntas mais importantes de toda sua carreira.


☕ O último caso

São 03h17.

Produção.

O fechamento parou.

Seu monitor mostra:

JOB FINCLOSE
ABEND S0C7

Um ano atrás você teria imediatamente perguntado à IA:

“Como corrigir S0C7?”

Hoje você olha.

Pensa.

Diz mentalmente:

“S0C7 é sintoma.”

Consulta o step.

Descobre o programa.

Localiza a instrução.

Identifica o campo.

Rastreia a origem.

O dado veio de um arquivo.

Você compara o layout.

A copybook do produtor mudou ontem.

A do consumidor não.

Silêncio.

Você encontrou o paciente zero.

Corrige o problema.

Reprocessa.

Alguns minutos depois:

IEF142I FINCLOSE STEP070 - STEP WAS EXECUTED
IEF285I...
MAXCC=0000

Você se recosta na cadeira.

A IA ajudou.

A documentação ajudou.

O mentor ajudou.

Os exercícios ajudaram.

Mas naquele momento havia algo novo dentro da equação:

você.


🩺 Diagnóstico final

Então, afinal:

A IA pode se tornar o melhor mentor para um novo profissional COBOL?

Pode se tornar o mentor mais disponível que já existiu.

Pode repetir infinitamente.

Adaptar explicações.

Construir diagramas.

Criar exercícios.

Comparar COBOL com Java e Python.

Explicar JCL.

Decifrar SQL.

Criar cenários CICS.

Simular incidentes.

Transformar um S0C7 em aula.

Questionar hipóteses.

Acompanhar evolução.

Mostrar conexões que antes demoravam anos para aparecer.

Mas existe uma coisa que precisamos evitar a qualquer custo:

IA
   ↓
RESPOSTA
   ↓
COPIAR
   ↓
PRODUÇÃO

O futuro interessante é:

              CURIOSIDADE
                   |
                   v
              FUNDAMENTOS
                   |
                   v
        +----------+----------+
        |                     |
        v                     v
       IA                 VETERANO
        |                     |
        +----------+----------+
                   |
                   v
             INVESTIGAÇÃO
                   |
                   v
              EVIDÊNCIA
                   |
                   v
             EXPERIÊNCIA
                   |
                   v
           MODELO MENTAL
                   |
                   v
      PROFISSIONAL MAINFRAME

A IA não precisa transformar o iniciante em um falso veterano.

Ela pode fazer algo muito melhor:

ajudar o iniciante a chegar mais rápido ao ponto em que começa a pensar como um profissional.

E aí está a diferença fundamental.

Aprender COBOL nunca foi somente memorizar:

PERFORM PROCESSA-DADOS
    UNTIL FIM-ARQUIVO.

É compreender por que aqueles dados existem, quem os produz, quem depende deles, quais regras representam, quais consequências uma alteração pode provocar e como descobrir o que aconteceu quando alguma coisa inevitavelmente der errado.

Porque no Bellacosa Mainframe Hospital a regra continua valendo:

O erro que aparece na tela é apenas o paciente dizendo onde dói. Não significa que seja ali que está a doença.

E quando o novato finalmente entende isso…

☕ pega a caneca.

🖥️ abre o SDSF.

🩺 observa os sintomas.

🧠 formula hipóteses.

🤖 consulta seu mentor artificial.

📚 confirma na documentação.

🔬 procura evidências.

E então, diante daquele velho sistema que parecia uma criatura incompreensível feita de COBOL, JCL, Db2, VSAM, CICS, copybooks e quarenta anos de decisões humanas, começa finalmente a dizer:

“Interessante… o paciente não está mentindo. Só estamos fazendo a pergunta errada.”

E somewhere, em algum CPD perdido no tempo, Carlos sorri atrás de uma caneca de café.

Porque nasceu mais um COBOLzeiro. ☕🧙‍♂️

terça-feira, 8 de abril de 2025

IBM z17 – O Mainframe para a Era da IA + Confiabilidade Extrema

 





⚙️ Postagem de Blog — Bellacosa Mainframe Style

IBM z17 – O Mainframe para a Era da IA + Confiabilidade Extrema




🧭 Introdução Técnica

A IBM z17 marca um salto importante na linha de sistemas IBM Z: lançado em 2025, ele é o primeiro projetado desde o início para a era da Inteligência Artificial (IA) integrada ao mainframe, além de trazer melhorias em segurança, inferência de dados em tempo real e suporte híbrido nublado 


🕰 Informações principais

  • Ano de lançamento: 2025 (anunciado abril, disponível a partir de junho)  

  • Modelo: z17 (também referido como máquina tipo 9175)  

  • CPU / arquitetura: Processador Telum II com acelerador de IA embutido; frequência elevada; aumento de cache (~ 40 %) para suportar até 450 bilhões de inferências por dia com latência de cerca de 1 ms.  

  • Versão do z/OS suportada: A IBM já anuncia que o z17 virá suportando ou sendo compatível com z/OS 3.2 (prevista para T3 2025) como a nova versão específica para esse hardware.  


📚 Curiosidade

  • O z17 não se limita apenas a “mais MIPS” — ele foi projetado para rodar inferência de IA nativa no mainframe, ou seja, usar modelos de machine learning diretamente onde os dados corporativos críticos residem, evitando latência de movimentação de dados. A IBM destaca que esta plataforma integra hardware, software e segurança com IA e aceleração — “bringing AI to the core of the enterprise”.  


📝 Nota Técnica

  • A arquitetura de interconexão, cache e aceleradores foi redesenhada para suportar workloads mistos tradicionais de mainframe (transações, CICS/DB2, Linux on Z) e cargas emergentes de IA/generative AI.  

  • O acelerador embutido permite que, segundo a IBM, se façam centenas de bilhões de inferências diárias com latência de ~1 ms, o que posiciona o z17 como plataforma “IA em tempo real” para transações. 

  • Além disso, novas capacidades de segurança e operação — por exemplo, gerenciamento de “segredos” (secrets management), detecção de anomalias com IA, integração de logs e métricas via OpenTelemetry — são parte do stack. 


🔁 O que muda em relação à versão anterior (z16)

  • O z17 complementa o z16 ao adicionar o “Telum II” com mais cache, maior frequência, e foco mais agressivo em IA (o z16 já trouxe IA on-chip, mas o z17 acelera mais cargas).

  • Aumento na escala de inferência de IA — mais operações por dia, menor latência.

  • Total integração de software operacional, IA de suporte às operações (ex: assistentes, agentes) e hardware de acelerador — o z17 traz além do chip principal, planos para cartões “Spyre Accelerator” (PCIe) para IA generativa. 

  • Maior foco em “hybrid cloud” + operações modernas de TI, integração com ambientes dev-ops, containers, geração de métricas operacionais e automação. 


💡 Dicas para Profissionais e Entusiastas

  • Se você trabalha com mainframe, valide como suas aplicações (COBOL, CICS, DB2) podem se beneficiar não só de mais MIPS, mas de inferência embutida — por exemplo, detecção de fraude, scoring de crédito ou análise de risco em tempo real.

  • Avalie a estratégia de modernização híbrida: z17 facilita a integração da plataforma Z com contêineres, nuvem híbrida e IA, então revise arquitetura e skills da equipe.

  • Fique atento à evolução do sistema operacional z/OS (como o 3.2 associado ao z17) e das ferramentas de suporte — por exemplo, automação de operação, observabilidade, integração de IA nas operações de mainframe.

  • Para seu curso ou aula, destaque: a transição do mainframe “só transações” para “transações + IA + segurança + nuvem” — o z17 encapsula essa mudança.


🏁 Conclusão Bellacosa

O IBM z17 é mais do que uma nova máquina — ele é o mainframe preparado para o futuro da computação empresarial: IA em tempo real, cloud híbrida, segurança de próxima geração, e desempenho corporativo robusto.
Para quem vive a Stack Mainframe, é um marco que reafirma: o mainframe não está ficando obsoleto — está se reinventando profundamente.

“Com o z17, o mainframe não só processa o que precisa ser feito — ele decide o que precisa ser feito.”
— Bellacosa Mainframe

 

segunda-feira, 7 de abril de 2025

☕🏨🖥️ APOCALYPSE HOTEL: O MAINFRAME QUE CONTINUOU RODANDO DEPOIS DO FIM DA HUMANIDADE

 

Bellacosa Mainframe e o fim do mundo no Apocalypse Hotel

☕🏨🖥️ APOCALYPSE HOTEL: O MAINFRAME QUE CONTINUOU RODANDO DEPOIS DO FIM DA HUMANIDADE

"Os usuários desapareceram. Os operadores sumiram. Os programadores morreram. Mas o sistema continua executando."


Ficha Técnica

Título Original

アポカリプスホテル (Apocalypse Hotel)

Título Internacional

Apocalypse Hotel

Estúdio

CygamesPictures

Direção

Kana Shundo

Roteiro

Shigeru Murakoshi

Lançamento

Abril de 2025

Episódios

12 episódios

Gêneros

  • Ficção Científica

  • Slice of Life

  • Drama

  • Pós-Apocalíptico

  • Filosófico

  • Iyashikei (anime contemplativo e reconfortante)

Classificação

Aproximadamente 12 a 14 anos, dependendo da região.


Sinopse

A humanidade abandonou a Terra.

Não houve explosão nuclear.
Não houve invasão alienígena.
Não houve guerra final.

Apenas chegou um momento em que os seres humanos precisaram partir.

Em meio às ruínas de Tóquio permanece o luxuoso Hotel Gingarou, administrado por uma equipe de robôs liderada por Yachiyo.

Mesmo sem hóspedes.

Mesmo sem humanidade.

Mesmo sem esperança concreta de retorno.

O hotel continua funcionando.


A Premissa Que Encanta Qualquer Profissional de Mainframe

Quando assisti Apocalypse Hotel, a primeira coisa que pensei foi:

"Isso não é um hotel. É um ambiente z/OS."

Imagine:

  • usuários desapareceram;

  • analistas aposentaram;

  • gestores mudaram;

  • fornecedores foram embora;

Mas:

  • JES2 continua ativo;

  • CICS continua respondendo;

  • DB2 continua íntegro;

  • batches continuam executando.

É exatamente essa sensação.

O hotel é um grande sistema corporativo sobrevivendo aos seus próprios criadores.


A História

Décadas após o desaparecimento da humanidade, Yachiyo continua seguindo as diretrizes recebidas.

O objetivo permanece simples:

Receber hóspedes e oferecer o melhor atendimento possível.

O problema?

Não existem hóspedes.

O anime então acompanha séculos de existência do hotel enquanto:

  • robôs envelhecem mecanicamente;

  • equipamentos quebram;

  • peças deixam de existir;

  • a natureza reconquista a cidade;

  • visitantes inesperados surgem.

Cada episódio apresenta novos desafios e encontros.


Personagens Principais

Yachiyo

A protagonista.

Uma robô gerente extremamente dedicada.

Ela representa:

  • dever;

  • disciplina;

  • responsabilidade;

  • perseverança.

Yachiyo é praticamente a personificação de um operador de produção experiente.


Equipe Robótica

Cada robô possui funções específicas:

  • manutenção;

  • limpeza;

  • cozinha;

  • segurança.

São equivalentes aos diversos subsistemas que mantêm um ambiente corporativo funcionando.


Os Visitantes

Ao longo da série surgem:

  • viajantes estranhos;

  • formas de vida desconhecidas;

  • visitantes inesperados.

Eles funcionam como eventos de produção que quebram a rotina aparentemente estável do hotel.


O Que Torna Apocalypse Hotel Diferente?

A maioria das obras pós-apocalípticas pergunta:

"Como sobreviver ao fim do mundo?"

Apocalypse Hotel pergunta:

"Como continuar vivendo depois que o objetivo desaparece?"

É uma diferença gigantesca.

O foco não está na destruição.

O foco está no vazio.


As Grandes Temáticas

1. Propósito

O anime constantemente pergunta:

"Se ninguém vê seu trabalho, ele ainda tem valor?"

Uma questão extremamente relevante para:

  • operadores;

  • administradores;

  • mantenedores;

  • profissionais de infraestrutura.


2. Memória

O hotel torna-se um museu involuntário da humanidade.

Cada quarto preservado.

Cada objeto guardado.

Cada procedimento seguido.

É uma metáfora poderosa para documentação histórica e preservação do conhecimento.


3. Legado

O que sobra quando desaparecemos?

Prédios?

Dados?

Programas?

Histórias?

Apocalypse Hotel sugere que o legado verdadeiro está nos efeitos que deixamos para trás.


4. Solidão

Diferentemente de muitos animes, a solidão aqui não é agressiva.

Ela é silenciosa.

Contemplativa.

Quase poética.

Lembra muito:

  • Yokohama Kaidashi Kikou

  • Girls' Last Tour

  • Planetarian


As Mensagens Ocultas

O Hotel é a Civilização

O hotel representa toda a sociedade humana.

Os robôs representam instituições.

As regras representam cultura.

A manutenção representa tradição.


Yachiyo é a Humanidade

Embora seja uma máquina, Yachiyo demonstra características cada vez mais humanas.

Curiosamente:

quanto mais os humanos desaparecem...

mais humana ela se torna.


O Tempo é o Verdadeiro Vilão

Não existe um grande inimigo.

Não existe um demônio final.

Não existe uma conspiração.

O adversário é o tempo.

Tudo envelhece.

Tudo muda.

Tudo desaparece.


Uma Leitura Mainframe Que Pouca Gente Percebe

Apocalypse Hotel parece ter sido criado para profissionais de sistemas legados.

Observe:

AnimeMainframe
HotelAmbiente produtivo
YachiyoOperador Sênior
ProtocolosProcedimentos Operacionais
QuartosAplicações
ManutençãoSuporte Técnico
HóspedesUsuários
Séculos de funcionamentoSistemas legados

A analogia é assustadoramente perfeita.


Impacto Cultural

Apesar de não ser um blockbuster, Apocalypse Hotel rapidamente conquistou:

  • fãs de ficção científica filosófica;

  • admiradores de obras contemplativas;

  • público interessado em inteligência artificial;

  • entusiastas de histórias existenciais.

Foi especialmente elogiado pela capacidade de transmitir emoções profundas sem depender de ação constante.


Houve Censura?

Não existem registros relevantes de censura internacional ou controvérsias significativas envolvendo Apocalypse Hotel.

O anime foi amplamente distribuído sem cortes importantes conhecidos.

Isso ocorre porque:

  • não possui violência extrema;

  • não possui fanservice excessivo;

  • não aborda temas políticos de forma direta.

Seu foco é filosófico e existencial.


A Grande Pergunta Que o Anime Deixa

Ao final, Apocalypse Hotel faz uma pergunta desconfortável:

"Você é definido pelo resultado do seu trabalho ou pelo ato de realizá-lo?"

Yachiyo continua servindo.

Continua organizando.

Continua preparando o hotel.

Mesmo quando não existe ninguém para agradecer.


Conclusão Bellacosa Mainframe

Se Serial Experiments Lain fala sobre redes.

Se Ghost in the Shell fala sobre consciência.

Se Planetarian fala sobre memória.

Então Apocalypse Hotel fala sobre operação contínua.

É a história do sistema que nunca recebeu o comando de shutdown.

Um anime que, sob a aparência de uma simpática gerente robótica, esconde uma das reflexões mais profundas dos últimos anos:

"Quando todos forem embora, o que continuará executando dentro de você?"

Para quem trabalha com Mainframe, z/OS, COBOL, CICS, JES2 ou operações de produção, Apocalypse Hotel parece menos uma ficção científica e mais um espelho filosófico da própria carreira.

E talvez seja exatamente por isso que ele permanece na memória muito tempo depois que os créditos terminam. ☕🚀🏨🖥️


domingo, 6 de abril de 2025

Da Era do Ecchi à Era do Isekai Como Sword Art Online, Re:Zero e Mushoku Tensei Redefiniram o Mercado de Animes entre 2012 e 2025

 

Bellacosa Mainframe e a era do isekai

☕ Um Café no Bellacosa Mainframe

Da Era do Ecchi à Era do Isekai

Como Sword Art Online, Re:Zero e Mushoku Tensei Redefiniram o Mercado de Animes entre 2012 e 2025

"Se a Era do Ecchi foi o COBOL dos animes dos anos 2000 — consolidada, lucrativa e dominante — o Isekai foi seu equivalente à computação em nuvem: uma mudança arquitetural completa do modelo de negócios da indústria."


Introdução

O mundo dos animes muda em ciclos.

Quem acompanha a indústria há décadas percebe algo semelhante ao que acontece na tecnologia corporativa.

Nos anos 80 tínhamos os super robôs.

Nos 90 vieram os bishoujo games.

Nos anos 2000 surgiu a explosão das visual novels.

Entre 2008 e 2015 vivemos a chamada Era de Ouro do Ecchi Moderno.

E então aconteceu algo curioso.

O mercado cansou.

Os espectadores cansaram.

Os estúdios precisavam de uma nova fórmula.

E ela surgiu.

Chamava-se:

Sword Art Online.

E depois veio:

Re:Zero.

Mushoku Tensei.

Tensura.

Overlord.

Konosuba.

The Eminence in Shadow.

Solo Leveling.

Poucos movimentos na história da animação japonesa foram tão impactantes quanto a ascensão do Isekai.

Hoje vamos analisar essa transformação como um arquiteto de sistemas IBM Z observa uma migração de um ambiente monolítico para microsserviços.

Pegue seu café.

Vamos debugar quinze anos de história dos animes.


O que era a Era do Ecchi?

Entre 2008 e 2015 a indústria descobriu um padrão extremamente lucrativo.

Arquitetura típica:

Light Novel
↓

Anime 12 episódios

↓

Blu-ray

↓

Figures

↓

Dakimakura

↓

Visual Novel

↓

Game Mobile

Praticamente um pipeline DevOps.

Os ingredientes eram:

Protagonista comum

Harém

Academia

Magia

Demônios

Fanservice

Heroínas arquétipo

Tsundere

Kuudere

Yandere

Imouto

Exemplos:

High School DxD

To Love Ru

Haganai

Infinite Stratos

Campione

Date A Live

Trinity Seven

Funcionava.

Muito.

Até deixar de funcionar.


O problema do modelo

A partir de 2013 surgiram sinais.

Audiência saturada.

Muitas obras eram quase idênticas.

Academia.

Garotas.

Torneio.

Praia.

Festival cultural.

Fim.

Os fãs queriam outra coisa.

Desejavam:

Progressão

Exploração

Aventura

Mundo aberto

Algo parecido com videogames.

E o Japão estava preparado.


O nascimento do Isekai moderno

Isekai significa:

Outro mundo.

Mas não nasceu em SAO.

Tem raízes antigas.

Aura Battler Dunbine

1983

Magic Knight Rayearth

1994

Fushigi Yuugi

1995

Escaflowne

1996

Digimon

1999

Zero no Tsukaima

2006

O conceito já existia.

Faltava apenas a tecnologia certa.


Sword Art Online

O Mainframe que iniciou tudo

2012

Autor

Reki Kawahara

Estúdio

A-1 Pictures


O diferencial

Kirito não estava numa escola.

Não havia festival cultural.

Não existia clube estudantil.

Existia:

Um MMORPG.

Progressão.

Níveis.

Itens.

Bosses.

Guildas.

Economia.


Era literalmente um MMORPG animado.

Algo que jogadores de:

Ragnarok

Lineage

Perfect World

Tibia

World of Warcraft

entenderam imediatamente.


Aincrad

100 andares.

Cada andar.

Uma dungeon.

Quests.

Mercado.

Casamento.

Respawn inexistente.

Morrer.

Morreu.


Porque funcionou

SAO foi lançado no momento perfeito.

Minecraft crescendo.

League of Legends.

Steam popularizando jogos digitais.

MMORPG ainda relevante.


SAO virou fenômeno.

Bilhões de dólares.

Filmes.

Jogos.

Novels.


A influência de SAO

Depois dele surgiram dezenas.

Log Horizon

Overlord

Death March

BOFURI

Infinite Dendrogram

Shangri-La Frontier


Todos descendem de SAO.


Overlord

O Sysprog Supremo

2015

Autor

Kugane Maruyama


Momonga não é herói.

É administrador.

Sysprog.

Praticamente um RACF Administrator.

Possui privilégios totais.


NPCs ganham consciência.


Tema central.

Responsabilidade.

Poder absoluto.

Solidão.


Konosuba

O Batch de Humor

2016

Autor

Natsume Akatsuki


Satiriza tudo.

Kazuma.

É preguiçoso.

Não quer salvar ninguém.


Aqua

É inútil.

Megumin

Só usa Explosion.

Darkness

Tank masoquista.


Konosuba foi a primeira grande crítica ao excesso de clichês.


Re:Zero

O dump S0C4 emocional

2016

Autor

Tappei Nagatsuki


Subaru morre.

Reinicia.

Loop infinito.


Como um Job abendando.

E sendo submetido novamente.


O diferencial.

Consequências.

Trauma.

Ansiedade.

Depressão.

Culpa.


Rem.

Emilia.

Beatrice.

Echidna.

Viraram ícones culturais.


O episódio 15

Possivelmente um dos melhores episódios dos anos 2010.


Mushoku Tensei

O z/OS do Isekai

Web Novel

2012

Anime

2021

Autor

Rifujin na Magonote


Muitos consideram:

O pai do Isekai moderno.


O diferencial.

Construção de mundo.

Linguagens próprias.

Geografia.

Política.

História.

Religião.

Economia.


Rudeus cresce.

Envelhece.

Erra.

Aprende.


Algo raro.

Personagens evoluem.


Studio Bind

Criado praticamente para adaptar Mushoku.


Qualidade absurda.

Animação cinematográfica.


Tensura

Virtualização de Monstros

2018

Rimuru.

Administra uma nação.


Diplomacia.

Economia.

Comércio.


Parece um simulador de WLM.


The Eminence in Shadow

O usuário que quer parecer hacker

Cid Kagenou.

Cria histórias.

As histórias tornam-se reais.


É praticamente um usuário criando documentação falsa.

E descobrindo que o ambiente produtivo realmente existe.


O impacto econômico

Ecchi domina.

Isekai cresce.

Explosão.

Domínio total.

Mercado consolidado.


Hoje.

Mais de 30% das novas light novels possuem elementos isekai.


O algoritmo das editoras

Antes.

Garotas bonitas
↓
Harém
↓
Blu-ray

Depois.

Outro Mundo
↓

Sistema RPG

↓

Poder oculto

↓

Progressão

↓

Merchandising

Porque o Ecchi perdeu espaço

Mudanças sociais.

Streaming.

Crunchyroll.

Netflix.

Disney.

Amazon.

Mercado global.


Blu-ray deixou de ser prioridade.


Agora o objetivo é:

Audiência mundial.

Licenciamento.

Games.

Mobile.

Gacha.


O papel dos videogames

Sem MMORPG.

Talvez o Isekai não existisse.

SAO.

WOW.

Ragnarok.

Final Fantasy XIV.

Elden Ring.

Dragon Quest.

Todos influenciaram.


O futuro

Já vemos uma nova mudança.

Isekai está saturando.


Novas tendências.

Villainess.

Regression.

Tower.

Hunter.

Dungeon.

LitRPG.


Solo Leveling.

Omniscient Reader.

TBATE.


Conclusão

O Datacenter dos Sonhos Otakus

O Ecchi não morreu.

Ele apenas deixou de ser o workload prioritário.

Assim como aplicações COBOL ainda processam trilhões de dólares diariamente, séries como High School DxD, Date A Live, To Love-Ru e Saekano continuam encontrando novos fãs.

Mas o scheduler da indústria mudou.

Entre 2012 e 2025, Sword Art Online, Re:Zero e Mushoku Tensei fizeram algo raro: alteraram completamente a arquitetura do entretenimento japonês.

O protagonista deixou de querer apenas conquistar garotas.

Ele passou a desejar:

  • Explorar continentes;

  • Derrotar chefes finais;

  • Construir reinos;

  • Salvar companheiros;

  • Compreender um mundo desconhecido;

  • E, às vezes, apenas ter uma segunda chance para viver melhor.

E talvez seja justamente isso que explica o sucesso do Isekai.

No fundo, ele conversa com um desejo humano muito antigo.

Não o desejo de escapar da realidade.

Mas a esperança de que, em algum lugar, exista um novo login, um novo personagem, um novo save point, permitindo recomeçar a aventura com a experiência acumulada da vida anterior — exatamente como um sysprog experiente que, após décadas mantendo um ambiente crítico em produção, finalmente recebe a oportunidade de projetar um sistema inteiramente novo, levando consigo todos os aprendizados das antigas batalhas travadas no datacenter.

sábado, 5 de abril de 2025

☕💥 Buffer Overflow, Memory Overwrite e Storage Corruption no z/OS

 

Bellacosa Mainframe e os perigos na gestão de memoria no mainframe

☕💥 Buffer Overflow, Memory Overwrite e Storage Corruption no z/OS

Ou como um simples MOVE pode transformar um datacenter multimilionário em uma sessão espírita conduzida por um Sysprog com café frio

 


Introdução

Existe uma frase antiga entre veteranos de Mainframe:

"Computadores não cometem erros. Eles apenas obedecem ordens idiotas em velocidades absurdamente altas."

E poucas coisas representam melhor isso do que três monstros ancestrais da programação:

  • Buffer Overflow

  • Memory Overwrite

  • Storage Corruption

O curioso é que muitos desenvolvedores COBOL juniores acreditam que isso é um problema de C, C++, Linux ou Windows.

Na verdade...

Mainframe conhece esses monstros desde que Elvis Presley ainda estava gravando discos.

A diferença é que o z/OS aprendeu a sobreviver a eles.

Hoje vamos entender como esses problemas surgem em:

  • COBOL

  • JCL

  • REXX

  • CICS

  • DB2

  • IMS

  • VSAM

  • Batch

  • JES2

  • SDSF

  • Language Environment

e principalmente...

como impedir que uma simples variável PIC X(10) provoque um incidente digno de abertura de War Room.


Capítulo 1

O que é Buffer Overflow?

Definição simples.

Você reservou espaço para 10.

Escreveu 100.

Fim.

Exemplo.

COBOL

01 WS-NOME.

   05 WS-TEXTO PIC X(10).



MOVE "BELLACOSA-MAINFRAME" TO WS-TEXTO

Teoricamente:

0123456789
BELLACOSA

Sobrou:

MAINFRAME

Para onde foi?

Depende.

Pode ir para:

Flag

Outra variável

LE Runtime

Heap

Stack


Linguagem C


char nome[10];

strcpy(nome,"BellacosaMainframe");

Mesmo problema.

COBOL apenas costuma esconder melhor.


Capítulo 2

Memory Overwrite

Buffer Overflow produz.

Memory Overwrite.

É o efeito colateral.


Exemplo

01 WS-AREA.

05 TABELA OCCURS 100.

10 COD PIC X.


05 FLAG PIC X.

Erro.

MOVE 'S'
TO TABELA(101)

Resultado.

FLAG = S


Pior.

Pode alterar:

SQLCA

DFHEIBLK

TGT

Save Area


Storage Corruption

É o estágio terminal.

Já não sabemos mais o que foi alterado.

O programa continua rodando.

Mas agora virou um zumbi.


O pesadelo

Job roda.

Termina RC=0000.

DB2 recebe dados errados.

VSAM inconsistente.

Extrato bancário incorreto.

E ninguém percebe.


Capítulo 3

Como o z/OS protege memória

1964

System/360

Quase nenhuma proteção.


Anos 70

Storage Keys

PSW


Anos 80

MVS/XA

Address Space


Anos 90

ESA

Cross Memory


Anos 2000

zOS

64 bits

LE

Heap protegido


Hoje

z16

z17

Guard Pages

Hardware assistido

Storage protection


O conceito de Address Space

Cada Job.

Cada TSO.

Cada CICS.

Possui seu universo.


Imagine apartamentos.

Apartamento 101.

COBOL.

Apartamento 102.

DB2.

Apartamento 103.

JES2.

Overflow.

Quebrou parede.

Invadiu apartamento vizinho.

Sysprog chora.


Capítulo 4

Batch

Batch é perigoso.

Porque roda horas.


Exemplo

5 milhões registros.

Erro.

Registro 3.456.789.

Corrupção.


Abends comuns

S0C4

Protection Exception


S0C7

Dados inválidos


S0C1

Opcode ilegal


S878

Storage


S80A

Memória insuficiente


U4038

LE detectou problema


Caso histórico

Década 90.

Seguradora.

Tabela OCCURS 500.

Nova regra.

700 elementos.

Programa não recompilado.

Sobrescreveu área.

Job fechou mensal.

Milhares apólices erradas.

Descoberta.

3 semanas depois.


Capítulo 5

CICS

No online.

Muito pior.


CICS compartilha recursos.

Tasking.

Threads.


Erro.

Pode derrubar milhares usuários.


DFHEIBLK corrompido.

Retorno errado.


Pseudo-conversacional.

COMMAREA.

Overflow.


Exemplo

DFHCOMMAREA PIC X(32767)

Recebe.

40 mil.

Boom.


Abends famosos

AEI9

ASRA

AEYD

APCT

AICA


AICA

Loop infinito.

CPU consumida.


ASRA

Equivalente S0C4.


Capítulo 6

DB2

DB2 é robusto.

Mas aplicativo não.


SQLDA.

SQLCA.

Host Variables.


Exemplo

PIC X(10)

Coluna VARCHAR(100)


Truncation.


SQLCODE

-302

-311

-305


Melhor prática.

Verificar.

SQLCODE.

Sempre.


Capítulo 7

IMS

IMS é uma máquina do tempo.

Ainda vivo.


PCB errado.

SSA inválida.

Pode gerar.

U0777


Overflow.

Área I/O.


Segmento corrompido.


Capítulo 8

VSAM

KSDS.

RRDS.

ESDS.


Erro clássico.

READ NEXT.

EOF ignorado.


Subscript inválido.


Storage corruption.


IDCAMS detecta.

VERIFY

EXAMINE


Capítulo 9

REXX

Parece inocente.

Não é.


Stem.

CLIENTE.0=100

DO I=1 TO 1000

SAY CLIENTE.I

END

Dados inexistentes.


RC inesperado.


Storage não costuma corromper.

Mas lógica.

Sim.


Capítulo 10

JES2

JES2 protege spool.


Mas programa pode gerar.

100 milhões linhas.

SYSOUT gigante.


JES2 sofre.


HASP...

mensagens.


Spool cheio.


Job cancelado.


Capítulo 11

SDSF

Melhor amigo.


ST

Status


DA

Address Spaces


LOG

Mensagens


ENC

Enclave


Examine.

MEMORY.

CPU.

Abends.


Capítulo 12

LE

Language Environment.

Herói desconhecido.


SSRANGE

CHECK

HEAPCHK

RPTSTG

TRAP

TERMTHDACT


Exemplo

PARM='TRAP(ON)'

Captura.

Stack.

Dump.


Capítulo 13

Ferramentas modernas

Fault Analyzer

Abend Aid

IBM Debug

IPDF

CEEDUMP


SMF

30

110

120


RMF


OMEGAMON


Z APM


Capítulo 14

Como programar seguro

Sempre

SSRANGE


Validar índices.

IF IDX <= MAX

Nunca confiar input.


CHECK LENGTH


SQLCODE


RESP

CICS


FILE STATUS


ON SIZE ERROR


INITIALIZE


INSPECT


TESTAR.

TESTAR.

TESTAR.


Capítulo 15

Detectando antes do caos

Pipeline ideal.

DEV

SSRANGE

QA

HEAPCHK

HML

TRAP

PRD

NOSSRANGE

SMF

OMEGAMON


Alarmes.

CPU.

Storage.

Abends.

Spool.

Response Time.


Easter Egg Bellacosa

Existe uma lenda em alguns datacenters.

Conta-se que um programa COBOL compilado em 1984 executava perfeitamente.

Até que um desenvolvedor júnior resolveu "modernizar".

Adicionou:

OCCURS 2000 TIMES

Compilou.

Promoveu.

Sexta-feira.

17h45.

Produção.

Fim de mês.

Folha salarial.

Executou.

RC=0000.

Tudo aparentemente perfeito.

Na segunda-feira descobriram que 12 mil funcionários haviam recebido exatamente:

R$ 0,01

O programa não havia abendado.

Não havia S0C4.

Não havia dump.

Apenas um discreto byte sobrescrito em uma área esquecida do Working Storage.

Dizem que o Sysprog responsável ainda hoje aparece pelos corredores do CPD segurando uma caneca de café e repetindo para novos desenvolvedores:

"Tem gente que teme IA substituir programadores. Eu temo programadores que compilam NOSSRANGE em homologação."


Conclusão

Os grandes incidentes em Mainframe raramente começam com uma pane espetacular.

Eles começam com pequenas negligências:

  • Um índice não validado;

  • Um OCCURS mal dimensionado;

  • Um SQLCODE ignorado;

  • Um COMMAREA maior que o esperado;

  • Um READ VSAM sem FILE STATUS;

  • Um JCL sem limites de espaço;

  • Um REXX assumindo que tudo sempre existe.

O z/OS evoluiu durante mais de 60 anos justamente para impedir que esses erros se transformem em catástrofes.

Mas a última linha de defesa continua sendo a mesma desde 1959:

O desenvolvedor que entende memória, respeita limites e trata cada MOVE como se estivesse carregando plutônio digital.

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