☕ 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

sexta-feira, 23 de agosto de 2024

🧿📜 Shikigami — Os Scripts Espirituais que Executam Ordens no Mundo Invisível

 

Bellacosa Mainframe explora os shikigami

🧿📜 Shikigami — Os Scripts Espirituais que Executam Ordens no Mundo Invisível

Se yokai são processos autônomos e ayakashi são bugs emocionais…
os Shikigami são scripts invocados sob comando direto.

Eles não agem por vontade própria.
Eles executam.

E se você errar a instrução…
o erro não dá rollback.


🧠 Conceito — Invocação como Código

O termo Shikigami (式神) pode ser entendido como:

  • “espírito comandado”
  • “entidade invocada”
  • “servo espiritual”

📌 Bellacosa traduz:

Shikigami = script que executa tarefas no plano espiritual.


📜 Origem — O Sistema Operacional do Onmyōdō

Os shikigami vêm do Onmyōdō, sistema esotérico japonês baseado em:

  • Yin-Yang (equilíbrio de forças)
  • Elementos naturais
  • Astrologia e espiritualidade

Figura central:

👉 Abe no Seimei — o “arquiteto root” dos shikigami

📌 Ele era conhecido por:

  • Invocar espíritos
  • Controlar entidades invisíveis
  • Operar no limite entre mundo físico e espiritual

🧬 Classificação — Não São Monstros, São Ferramentas

Shikigami não são criaturas independentes como yokai.

Eles são:

  • 🧿 Espíritos controlados
  • 📜 Manifestados via talismãs
  • 🧠 Dependentes do invocador
  • ⚙️ Extensões da vontade do usuário

👉 Em termos técnicos:

Não são processos autônomos — são subprocessos.


👁 Aparência — Do Papel ao Pesadelo

Formas comuns:

  • Papéis animados (ofuda)
  • Animais espirituais (raposas, aves)
  • Criaturas humanoides
  • Entidades grotescas

📌 Regra:

Quanto mais forte o invocador… mais complexo o “código”.


⚙️ Funcionamento — Execução Sob Comando

Para invocar um shikigami:

  1. Preparação espiritual
  2. Uso de talismãs
  3. Canalização de energia
  4. Comando direto

👉 Ele então:

  • Ataca
  • Espiona
  • Protege
  • Executa tarefas específicas

📌 Bellacosa:

Input errado = comportamento inesperado.


🎲 Atributos (Estilo RPG/Anime)

  • Dependência: Alta (do invocador)
  • Força: Variável
  • Inteligência: Limitada ou programada
  • Habilidades:
    • Ataque espiritual
    • Selamento
    • Rastreamento
    • Defesa

🧠 Comportamento

  • Não têm vontade própria (em teoria)
  • Seguem ordens
  • Podem se rebelar se mal controlados
  • Refletem o poder do invocador

👉 São estáveis… até não serem.


🤫 Fofoquices Espirituais

  • Dizem que invocadores fracos perdem controle
  • Alguns shikigami “ganham consciência” com o tempo
  • Mestres escondem seus shikigami mais poderosos
  • Há histórias de shikigami que mataram seus próprios donos

📌 Fofoquinha:

Nem todo script aceita ser encerrado.


🕹️ Easter Eggs nos Animes

  • Jujutsu Kaisen → invocações como shikigami (Megumi)
  • Naruto → invocações têm base conceitual semelhante
  • Onmyoji → representação direta
  • Nioh → uso histórico e espiritual

🎮 Easter Egg clássico:

Todo summon controlado em anime tem DNA de shikigami.


🧠 Diferença Rápida (Bellacosa Mode)

EntidadeFunção
YokaiProcesso autônomo
AyakashiBug emocional
MajuuMonstro físico
ShikigamiScript controlado

🧠 Interpretação Profunda

Shikigami representam:

  • Controle sobre o invisível
  • Poder mediado por conhecimento
  • Relação entre criador e criação
  • Responsabilidade sobre aquilo que você invoca

📌 Comentário Final — O Poder Não Está no Espírito

Você pode:

  • Invocar
  • Controlar
  • Executar

Mas no final…

o risco nunca está no shikigami
está em quem escreveu o comando.


🔥 Conclusão — Nem Todo Código Deve Ser Executado

No mundo dos animes (e da vida):

  • Nem tudo que pode ser invocado deve ser usado
  • Nem todo controle é absoluto
  • Nem toda ferramenta é segura

Porque quando você começa a rodar scripts no invisível…

você também passa a fazer parte do sistema.

quinta-feira, 22 de agosto de 2024

☕💥 VSAM sem Mistério: Do Zero ao Jedi dos Datasets — O LAB que vai destravar sua mente Mainframe!

 

Bellacosa Mainframe VSAM em primeiros passos para padawans

☕💥 VSAM sem Mistério: Do Zero ao Jedi dos Datasets — O LAB que vai destravar sua mente Mainframe!

Se você é um padawan COBOL tentando entender VSAM e ainda acha que KSDS é nome de sindicato… chegou a hora da virada.

Aqui não tem teoria chata. É mão na massa, com JCL, IDCAMS, conceitos e aquele tempero Bellacosa: história + prática + sacadas que só quem já tomou dump às 3 da manhã entende 😄


🧠 ANTES DE COMEÇAR — O MAPA DA FORÇA (VSAM em 1 minuto)

VSAM (Virtual Storage Access Method) é o método de acesso mais poderoso do z/OS para dados estruturados.

👉 Tipos principais:

  • ESDS → Sequencial (sem chave)
  • KSDS → Indexado (com chave)
  • RRDS → Acesso direto por número (RRN)

👉 Conceitos fundamentais:

  • CI (Control Interval) → menor unidade de I/O
  • CA (Control Area) → conjunto de CIs
  • INDEX → árvore B usada no KSDS

🧪 LAB 1 — Criando seu primeiro ESDS (o “arquivo raiz”)

🎯 Objetivo

Criar um dataset sequencial VSAM.

🔧 JCL + IDCAMS

//ESDSJOB JOB (ACCT),'LAB ESDS',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER(NAME(LAB.VSAM.ESDS)
RECORDSIZE(80 80)
TRACKS(1 1)
CISZ(4096)
NONINDEXED)
/*

💡 Insights Bellacosa

  • ESDS não tem chave → leitura sequencial pura
  • Ideal para logs, trilhas, arquivos históricos
  • CISZ(4096) → tuning começa aqui!

🧪 LAB 2 — KSDS: o cérebro do VSAM (com índice)

🎯 Objetivo

Criar um dataset indexado com chave.

🔧 JCL

//KSDSJOB JOB (ACCT),'LAB KSDS',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER(NAME(LAB.VSAM.KSDS)
RECORDSIZE(80 80)
KEYS(10 0)
INDEXED
TRACKS(1 1)
CISZ(4096))
/*

💡 Insights de guerra

  • KEYS(10 0) → chave começa na posição 0 com tamanho 10
  • KSDS usa árvore B (index) → acesso rápido tipo DB2-lite
  • Pode acessar:
    • sequencial
    • random (pela chave)

🧪 LAB 3 — RRDS: acesso direto estilo “memória RAM”

🎯 Objetivo

Criar dataset por número relativo.

🔧 JCL

//RRDSJOB JOB (ACCT),'LAB RRDS',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER(NAME(LAB.VSAM.RRDS)
RECORDSIZE(80 80)
NUMBERED
TRACKS(1 1)
CISZ(4096))
/*

💡 Sacada ninja

  • Acesso via RRN (Relative Record Number)
  • Tipo array:
    • Registro 1
    • Registro 2
    • Registro 3…

👉 Muito usado em sistemas antigos de alta performance


🔍 LAB 4 — Explorando INDEX (o segredo do KSDS)

🎯 Ver o INDEX

//LISTCAT JOB (ACCT),'LISTCAT',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LISTCAT ENT(LAB.VSAM.KSDS) ALL
/*

💡 O que observar:

  • INDEX LEVELS
  • CI/CA splits
  • FREESPACE

👉 Aqui você começa a pensar como performance engineer 😎


⚙️ LAB 5 — Brincando com CI e CA (onde mora a performance)

🎯 Criar KSDS com tuning

DEFINE CLUSTER(NAME(LAB.VSAM.KSDS.TUNED)
RECORDSIZE(80 80)
KEYS(10 0)
CISZ(8192)
FREESPACE(20 10)
INDEXED)

💡 Tradução prática

  • CISZ(8192) → menos I/O (mais dados por leitura)
  • FREESPACE(20 10):
    • 20% no CI
    • 10% no CA

👉 Evita CA SPLIT (o terror do desempenho)


🔥 LAB 6 — Carga de dados (REPRO)

//LOADJOB JOB (ACCT),'LOAD',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INFILE DD *
0000000001CLIENTE001
0000000002CLIENTE002
/*
//OUTFILE DD DSN=LAB.VSAM.KSDS,DISP=SHR
//SYSIN DD *
REPRO INFILE(INFILE) OUTFILE(OUTFILE)
/*

💻 LAB 7 — COBOL acessando VSAM (o momento Jedi)

📌 Exemplo KSDS

SELECT ARQ-KSDS ASSIGN TO 'LAB.VSAM.KSDS'
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS WS-KEY.

FD ARQ-KSDS.
01 REGISTRO.
05 WS-KEY PIC X(10).
05 WS-DADOS PIC X(70).

🧠 MENTALIDADE DE PRODUÇÃO (ouro puro)

👉 ESDS = simples, rápido, bruto
👉 KSDS = flexível, poderoso, mais caro
👉 RRDS = ultra rápido, mas limitado

👉 Problemas reais que você vai ver:

  • CI SPLIT
  • CA SPLIT
  • Fragmentação
  • Performance degradando com o tempo

⚡ DESAFIO FINAL (modo Bellacosa ON)

  1. Crie um KSDS com chave cliente
  2. Insira 100 registros
  3. Faça leitura random via COBOL
  4. Gere LISTCAT antes/depois
  5. Analise splits

👉 Se você fizer isso, você deixou de ser padawan.


FECHAMENTO

VSAM não é só dataset.

É:

  • engenharia de performance
  • organização de dados
  • base de sistemas críticos há décadas

E quando você entende CI, CA e INDEX…

👉 você começa a enxergar o mainframe como ele realmente é.


quarta-feira, 21 de agosto de 2024

Como os algoritmos sequestraram a liberdade de escolha

 

Bellacosa Mainframe e como os algoritmos sequestraram a liberdade de escolha

Como os algoritmos sequestraram a liberdade de escolha

Quando a internet decide por você

A promessa inicial da internet era simples: liberdade. Escolher o que ler, o que assistir, o que explorar. Mas, pouco a pouco, a realidade se distanciou dessa utopia. Hoje, parece que não escolhemos mais — somos escolhidos por algoritmos.

Mas como isso aconteceu? E por que sentimos que nossas decisões online não são mais nossas?


1. Algoritmos como “curadores invisíveis”

Tudo que aparece no feed, no TikTok, no Instagram ou no YouTube é resultado de cálculos matemáticos. O algoritmo decide:

  • O que você verá primeiro

  • O que é “relevante” para você

  • O que gera engajamento — e, portanto, lucro

O efeito é sutil, mas poderoso: o usuário passa a acreditar que está explorando livremente, quando na verdade está sendo conduzido.


2. O princípio da recompensa constante

Algoritmos exploram gatilhos psicológicos: likes, comentários, cliques e recompensas imediatas. Cada ação é registrada e usada para refinar o conteúdo entregue.

O problema é que isso modela o comportamento, reforçando apenas aquilo que já gostamos ou com o que reagimos.
Exemplo: alguém que gosta de memes de anime tende a receber apenas memes similares, perdendo exposição a obras diferentes ou críticas construtivas.


3. Filtragem de ideias e censura algorítmica

Além de moldar gostos, os algoritmos filtram informações consideradas sensíveis, ofensivas ou politicamente arriscadas.
O resultado é:

  • Conteúdos legítimos sendo ocultados

  • Opiniões divergentes sufocadas

  • Narrativas uniformizadas

A sensação de que tudo que é fora do padrão é proibido não é coincidência — é efeito direto da automação de decisões.


4. Ilusão de escolha

O perigo é o mais sutil: acreditamos que temos autonomia. Escolhemos clicar, mas as opções já foram pré-selecionadas.

É como entrar em uma loja onde apenas algumas prateleiras são visíveis. Você acha que decide livremente, mas o inventário real é maior — e invisível.


5. Consequências culturais e individuais

  • Cultura: algoritmos uniformizam tendências e tornam o consumo previsível

  • Psicológico: reforçam bolhas, vícios de atenção e reforço de comportamentos

  • Criativo: conteúdos arriscados, inovadores ou complexos desaparecem, pois não garantem engajamento imediato

Em resumo: o algoritmo substituiu a curiosidade por conforto e previsibilidade.


6. O que ainda podemos fazer

  • Reconhecer os padrões: entender que a maioria do que vemos é curadoria automática

  • Procurar fontes alternativas: feeds não convencionais, blogs, fóruns especializados

  • Praticar consumo crítico: questionar “por que estou vendo isso?”

  • Experimentar o “offline”: criar espaço fora do fluxo de recomendação

Mesmo sob controle algorítmico, ainda existe espaço de liberdade consciente.


Conclusão

O algoritmo sequestrou a liberdade de escolha, mas não a eliminou completamente.
Ele organiza, recomenda e direciona, mas cabe ao usuário redescobrir o sentido de navegar por vontade própria.

A pergunta que fica: estamos usando a internet ou apenas sendo usados por ela?

terça-feira, 20 de agosto de 2024

Debugando programa COBOL

Bellacosa Mainframe e o debug em cobol

☕ Um Café no Bellacosa Mainframe

Professor Pardal Entra no Abend: a Arte de Debugar COBOL sem Transformar Produção em Patópolis

🐔🔧 S0C7, S0C4, dumps, CEEDUMP, SYSOUT, DISPLAY, offsets, compile listings, Db2, CICS e a velha ciência de descobrir por que um programa que “funcionava ontem” resolveu explodir hoje

Existe uma frase particularmente perigosa no universo mainframe:

“Mas esse programa nunca deu problema.”

Meu jovem Padawan...

Um programa COBOL que está há 27 anos em produção não está necessariamente correto.

Ele pode simplesmente estar há 27 anos esperando o registro certo para explodir.

Então chega terça-feira.

02:47 da manhã.

O telefone toca.

JOB CLIENTE ABENDED
SYSTEM COMPLETION CODE=0C7

Silêncio.

Alguém pergunta:

— Quem alterou o programa?

Resposta:

— Ninguém.

Outra pessoa:

— Mudaram o arquivo?

— Não.

— Db2?

— Não.

— JCL?

— Também não.

Nesse momento, uma pequena porta se abre no CPD.

Entra um galo antropomórfico de chapéu, óculos e ferramentas.

Professor Pardal.

Ele olha para o dump.

Olha para o programador.

Olha novamente para o dump.

E provavelmente pergunta:

“Você leu a mensagem de erro?”

Porque antes de inventarmos observabilidade, AIOps, telemetry, tracing e outras palavras capazes de consumir três slides cada...

já existia uma técnica extraordinariamente eficiente:

LER A PORRA DO ERRO.

Bem-vindo ao maravilhoso mundo do debug COBOL.


🐔 Professor Pardal assume o plantão

Nos quadrinhos Disney, Professor Pardal é aquele inventor capaz de construir praticamente qualquer coisa.

Máquinas impossíveis.

Robôs.

Veículos.

Dispositivos absurdos.

Soluções para problemas que ninguém sabia que possuía.

E frequentemente suas invenções criam problemas ainda maiores.

Ou seja:

perfeitamente qualificado para desenvolvimento corporativo.

Ele também possui um pequeno ajudante robótico chamado Lampadinha.

Portanto nossa arquitetura está pronta:

PROFESSOR PARDAL
      |
      +---- Programador COBOL
      |
      +---- Lampadinha
              |
              +---- IA generativa

Agora precisamos descobrir por que:

COMPUTE WS-TOTAL =
        WS-QUANTIDADE * WS-VALOR.

mandou nosso JOB diretamente para Valhalla.


🧠 Debug não significa olhar código

Primeira lição do Professor Pardal:

debug é investigação.

Existe uma diferença enorme.

O programador desesperado abre o código e começa:

rolando...

rolando...

rolando...

rolando...

Até encontrar alguma coisa que parece suspeita.

Então altera.

Compila.

Executa.

Falha.

Altera outra coisa.

Compila.

Executa.

Falha diferente.

Parabéns.

Você não está fazendo debugging.

Está praticando:

Programação Orientada a Superstição™

Professor Pardal jogaria uma chave inglesa em sua cabeça.

O processo correto começa com evidência.


🔎 1. Qual foi exatamente o ABEND?

Antes de olhar código:

QUAL JOB?
QUAL STEP?
QUAL PROGRAMA?
QUAL ABEND?
QUAL OFFSET?
QUAL ARQUIVO?
QUAL REGISTRO?
QUAL SQLCODE?
QUAL TRANSAÇÃO?

Imagine:

JOBNAME  : FATURA01
STEP     : STEP030
PROGRAM  : FATU120
ABEND    : S0C7

Já sabemos muita coisa.

S0C7 normalmente aponta para uma data exception.

Em linguagem Bellacosa:

alguma operação decimal encontrou algo que não deveria estar ali.

Você esperava:

12345

Recebeu:

12A45

COBOL olhou aquilo.

Pensou por aproximadamente três nanossegundos.

E decidiu:

VAI TOMAR NO CU.

S0C7.

💥 S0C7 — o clássico

Talvez seja o ABEND mais famoso do universo COBOL.

Imagine:

01 WS-VALOR PIC 9(05).

MOVE '12A45' TO WS-VALOR.

ADD 1 TO WS-VALOR.

A movimentação pode deixar dados incompatíveis com aquilo que posteriormente será tratado como numérico.

Quando uma instrução decimal tenta utilizar o campo...

💥

SYSTEM COMPLETION CODE=0C7

Professor Pardal imediatamente pergunta:

De onde veio WS-VALOR?

Essa pergunta vale ouro.

Porque frequentemente o erro não está na instrução que explodiu.

A instrução apenas encontrou o cadáver.


🕵️ A cena do crime

Considere:

READ ARQ-CLIENTES
   AT END
      SET EOF TO TRUE
   NOT AT END
      MOVE CLI-VALOR TO WS-VALOR
END-READ.

...

COMPUTE WS-TOTAL = WS-VALOR * WS-TAXA.

O COMPUTE explode.

Quem é acusado?

COMPUTE

Mas talvez o verdadeiro assassino tenha acontecido vinte instruções antes:

MOVE CLI-VALOR TO WS-VALOR

E talvez CLI-VALOR tenha vindo de:

ARQUIVO

que veio de:

SORT

que veio de:

OUTRO PROGRAMA

que veio de:

DB2

que recebeu dados de:

API

que recebeu alguma porcaria enviada por alguém.

Bem-vindo ao debugging corporativo.


🗺️ O mapa do Professor Pardal

Uma investigação eficiente pode ser visualizada assim:

ABEND
  ↓
STEP
  ↓
PROGRAMA
  ↓
OFFSET
  ↓
INSTRUÇÃO
  ↓
VARIÁVEIS
  ↓
ORIGEM DOS DADOS
  ↓
REGISTRO
  ↓
CAUSA

Não:

ABEND
  ↓
PÂNICO
  ↓
ALTERA QUALQUER COISA
  ↓
COMPILA
  ↓
REZA

Essa segunda metodologia é bastante popular.


📜 2. Leia o dump

Ah, o dump.

Aquele maravilhoso documento de 18 quilômetros que aparece no spool.

O programador iniciante abre:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
HEX HEX HEX HEX HEX HEX HEX HEX
REGISTER REGISTER REGISTER
STORAGE STORAGE STORAGE

Fecha.

E declara:

“Não dá para entender.”

Professor Pardal sorri.

Porque o dump não foi criado para ser bonito.

Foi criado para contar o que existia na memória quando o programa morreu.

É a autópsia.


🧬 CEEDUMP

Em ambientes Language Environment, podemos encontrar informações extremamente úteis no CEEDUMP.

Dependendo da configuração e do problema, você pode conseguir identificar:

  • programa;

  • condição;

  • offset;

  • traceback;

  • rotina;

  • registradores;

  • storage;

  • contexto da falha.

Você não precisa compreender imediatamente cada byte.

Primeiro procure aquilo que reduz o universo da investigação.

Se seu programa possui 25.000 linhas e você descobre aproximadamente onde ocorreu a falha...

já eliminou uma enorme quantidade de Patópolis.


📐 3. O offset é seu amigo

Imagine uma mensagem apontando algo semelhante a:

PROGRAM FATU120
OFFSET X'00001A7C'

Agora temos uma coordenada.

Precisamos relacioná-la ao código compilado.

É aqui que o compile listing se torna extremamente importante.

Dependendo do compilador, opções utilizadas e informações disponíveis, podemos correlacionar offsets com statements/instruções.

Professor Pardal abre sua bancada:

ABEND
+
OFFSET
+
COMPILE LISTING
=
LOCALIZAÇÃO PROVÁVEL

Agora nossa investigação saiu de:

“Existe algum problema no programa.”

para:

“Existe alguma coisa errada nesta região.”

Isso muda tudo.


📚 Compile listing não é papel para alimentar impressora

Durante anos conheci programadores que tratavam listing como aquele negócio gigantesco produzido depois da compilação.

Errado.

Ele pode ser uma verdadeira radiografia do programa.

Dependendo das opções de compilação, encontramos informações sobre:

SOURCE
CROSS-REFERENCE
DATA MAP
PROCEDURE MAP
OFFSETS
MESSAGES
OPTIMIZATION

O velho:

XREF

pode ser particularmente interessante.

Quer saber onde determinada variável aparece?

Em vez de executar:

CTRL+F
CTRL+F
CTRL+F
CTRL+F

você pode analisar suas referências.


🐔 Professor Pardal pergunta: “Quem mexeu nesta variável?”

Imagine:

01 WS-SALDO PIC S9(09)V99 COMP-3.

Você encontra problema em WS-SALDO.

Pergunta:

Quem escreve nele?

Talvez:

01230 MOVE DB2-SALDO TO WS-SALDO
01870 ADD WS-JUROS TO WS-SALDO
02410 MOVE ZERO TO WS-SALDO
03150 COMPUTE WS-SALDO = ...

Agora temos suspeitos.

Debugging começa a parecer investigação criminal.

Porque essencialmente é.


🔦 Lampadinha recomenda DISPLAY

E chegamos à ferramenta mais sofisticada já inventada pela humanidade.

DISPLAY.

Sim.

Pode rir.

Temos ferramentas modernas de debugging.

IDEs.

Debuggers interativos.

Tracing.

Observabilidade.

Ferramentas comerciais excelentes.

Mas existe um momento na carreira de todo COBOLzeiro em que aparece:

DISPLAY 'ENTREI AQUI'.

Depois:

DISPLAY 'WS-VALOR=' WS-VALOR.

Depois:

DISPLAY 'ANTES DO COMPUTE'.

E finalmente:

DISPLAY 'MEU DEUS CHEGOU AQUI'.

É feio?

Sim.

Funciona?

ABSOLUTAMENTE.


⚠️ Mas DISPLAY também pode virar arma de destruição

Professor Pardal faz uma advertência.

Imagine:

PERFORM UNTIL EOF
   READ ARQUIVO
   DISPLAY REGISTRO-INTEIRO
END-PERFORM.

Arquivo:

83.000.000 registros

JES2:

VOCÊ TEM CERTEZA DISSO, FILHO?

Portanto DISPLAY deve ser usado com inteligência.

Talvez:

IF WS-CONTADOR < 100
   DISPLAY ...
END-IF

Ou somente quando determinada condição ocorrer:

IF WS-CLIENTE = 123456
   DISPLAY ...
END-IF

Debugging não deveria provocar um novo incidente.

Embora isso torne a história muito melhor depois.


🧯 S0C4 — entrou onde não deveria

Outro clássico:

S0C4

De maneira simplificada, estamos frequentemente olhando para algum problema de acesso à memória/storage, endereço inválido ou operação relacionada.

É uma família de situações que exige analisar contexto.

Ponteiros.

Índices.

Subscripts.

CALLs.

Parâmetros.

Storage.

Professor Pardal imediatamente procura coisas como:

SET ADDRESS OF ...

ou tabelas:

01 TABELA.
   05 ITEM OCCURS 100 TIMES.

e alguém fazendo:

ITEM(347)

A tabela possui 100 posições.

O programador quer acessar 347.

COBOL responde:

interessante.

O sistema responde:

S0C4.


📦 SSRANGE — o cinto de segurança

Durante desenvolvimento e testes, opções como SSRANGE podem ajudar enormemente na identificação de problemas relacionados a referências fora dos limites permitidos.

É o equivalente COBOL de colocar Professor Pardal ao lado da tabela dizendo:

“Meu amigo, existem 100 posições aqui. Por que você está tentando acessar a 347?”

Naturalmente existe custo associado às verificações adicionais, portanto decisões de compilação para desenvolvimento, teste e produção precisam considerar o ambiente e as políticas da organização.

Mas durante diagnóstico?

Pode ser extremamente útil.


🧮 COMP-3: onde mora o demônio hexadecimal

Agora entramos numa região particularmente divertida.

Packed decimal.

PIC S9(7)V99 COMP-3.

O programador iniciante olha um dump hexadecimal e pensa:

Satanás.

O COBOLzeiro experiente olha:

12 34 56 78 9C

e pensa:

Ah, 1234567,89 positivo.

E continua tomando café.

Campos COMP-3 são eficientes e tradicionais no processamento decimal empresarial.

Mas quando dados inválidos entram nesse território...

o S0C7 começa a afiar a faca.


🧪 TESTE O DADO, NÃO SUA FÉ

Uma das grandes lições do debugging é:

nunca confie cegamente na entrada.

“Mas o arquivo vem de outro sistema.”

Maravilha.

Outro sistema também possui programadores.

“Mas vem do banco.”

Ótimo.

“Mas existe validação.”

Excelente.

Mesmo assim:

VALIDATE.

Porque sistemas antigos frequentemente acumulam décadas de exceções, migrações, conversões e pequenas decisões históricas.

O campo chamado:

DATA-NASCIMENTO

pode conter:

00000000
99999999
20260231
        

e algum valor que ninguém consegue explicar desde 1987.


🗄️ Quando o culpado é Db2

Agora nosso programa executa SQL.

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CLIENTE
    WHERE ID = :WS-ID
END-EXEC.

Professor Pardal pergunta imediatamente:

SQLCODE?
SQLSTATE?

Não faça isto:

EXEC SQL
   ...
END-EXEC

CONTINUE.

Faça tratamento adequado.

Porque:

SQLCODE = 0

é uma história.

SQLCODE = +100

é outra.

Valores negativos contam histórias ainda mais interessantes.

Um bom debug de aplicação Db2 exige entender não apenas COBOL, mas a conversa entre:

PROGRAMA
   ↕
SQL
   ↕
DB2

🏦 CICS: agora o pato ficou bravo

Batch já é divertido.

Então entramos no CICS.

Agora temos:

TRANSACTION
COMMAREA
CHANNELS
CONTAINERS
RESP
RESP2
EIBRESP
EIBRCODE
MAPAS
TSQ
TDQ
FILES
DB2
MQ

E o usuário diz:

“A tela fechou.”

Excelente descrição técnica.

Professor Pardal pergunta:

Qual transação?

Usuário:

“Aquela azul.”

Bem-vindo ao suporte.


🚨 RESP e RESP2

Uma prática importantíssima no CICS é não tratar comandos como se fossem infalíveis.

Exemplo conceitual:

EXEC CICS READ
     FILE('CLIENTE')
     INTO(WS-REGISTRO)
     RIDFLD(WS-CHAVE)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC.

Agora conseguimos investigar.

Em vez de:

NÃO FUNCIONOU

temos informação sobre a resposta da operação.

Debugging é justamente isso:

transformar “não funciona” em evidência mensurável.


🧠 Professor Pardal apresenta o método científico

A melhor maneira de debugar COBOL não é decorar ABENDs.

É pensar como cientista.

Temos:

OBSERVAÇÃO
    ↓
HIPÓTESE
    ↓
TESTE
    ↓
EVIDÊNCIA
    ↓
CONCLUSÃO

Exemplo:

Observação

S0C7 durante cálculo.

Hipótese

WS-VALOR contém dados não numéricos.

Teste

Inspecionar campo imediatamente antes da operação.

Evidência

WS-VALOR = '00012A45'

Nova pergunta

Quem colocou A ali?

Seguimos para trás.

Isso é debugging.


❌ O anti-debug

O método corporativo alternativo é:

S0C7
 ↓
"DEVE SER O DB2"
 ↓
DBA INVESTIGA
 ↓
NÃO É DB2
 ↓
"DEVE SER INFRA"
 ↓
INFRA INVESTIGA
 ↓
NÃO É INFRA
 ↓
"SERÁ A REDE?"
 ↓
NETWORK INVESTIGA
 ↓
NÃO É REDE
 ↓
3 HORAS DE WAR ROOM
 ↓
CAMPO NUMÉRICO CONTINHA 'X'

Professor Pardal abandona Patópolis.


🤖 Lampadinha ganhou IA generativa

Agora chegamos a 2026.

Imagine Professor Pardal com uma Lampadinha equipada com IA.

Você fornece:

ABEND
dump
compile listing
trecho COBOL
copybook
JCL
mensagens

E pergunta:

“Quais são as hipóteses mais prováveis?”

Isso pode acelerar brutalmente a investigação.

IA pode ajudar a:

  • interpretar mensagens;

  • explicar código legado;

  • correlacionar variáveis;

  • sugerir pontos de inspeção;

  • construir hipóteses;

  • explicar hexadecimal;

  • analisar fluxos;

  • sugerir casos de teste.

Mas existe uma regra fundamental:

IA NÃO TRANSFORMA HIPÓTESE EM EVIDÊNCIA.

Se Lampadinha disser:

“Provavelmente WS-VALOR possui dado inválido.”

Excelente.

Agora prove.


🧠 IA pode alucinar. Dump não.

Esta frase deveria estar colada em toda War Room moderna.

IA:
"Talvez seja..."

DUMP:
"ERA ISTO."

Use IA como copiloto investigativo.

Não como oráculo.

Especialmente em ambientes críticos.

E jamais copie dumps de produção contendo dados sensíveis para serviços externos sem autorização, mascaramento e respeito às políticas de segurança.

Professor Pardal é maluco.

Mas RACF continua observando.


🔐 DEBUG também é segurança

Essa parte frequentemente é esquecida.

Dump pode conter:

CPF
CONTA
NOME
TOKEN
CARTÃO
ENDEREÇO
DADOS FINANCEIROS
CHAVES
CREDENCIAIS

DISPLAY também pode colocar dados sensíveis no spool.

Logs permanecem.

SYSOUT permanece.

Ferramentas armazenam informações.

Portanto:

DEBUG ≠ LIBEROU GERAL

Em produção, diagnóstico precisa respeitar controles de segurança e privacidade.


🧰 A caixa de ferramentas do Professor Pardal

Nosso laboratório COBOL pode conter várias ferramentas e técnicas:

ABEND MESSAGES
SYSOUT
JES/SDSF
DUMP
CEEDUMP
COMPILE LISTING
XREF
OFFSET
DISPLAY
SSRANGE
TEST OPTIONS
DEBUGGERS
FAULT ANALYSIS TOOLS
FILE INSPECTION
DB2 DIAGNOSTICS
CICS DIAGNOSTICS
SMF
LOGS

Nenhuma ferramenta substitui raciocínio.

Porque o problema fundamental continua sendo:

O que o programa deveria fazer e o que ele realmente fez?

Essa diferença é o território do debugger.


🧭 O algoritmo Bellacosa-Pardal de Debug COBOL™

Quando alguma coisa explodir:

1. NÃO ENTRE EM PÂNICO
        ↓
2. IDENTIFIQUE JOB/STEP/PROGRAMA
        ↓
3. LEIA O ABEND/MENSAGEM
        ↓
4. PROCURE OFFSET/TRACEBACK
        ↓
5. CONSULTE O LISTING
        ↓
6. IDENTIFIQUE A INSTRUÇÃO
        ↓
7. INSPECIONE AS VARIÁVEIS
        ↓
8. DESCUBRA QUEM AS ALTEROU
        ↓
9. RASTREIE A ORIGEM DOS DADOS
        ↓
10. CRIE UMA HIPÓTESE
        ↓
11. TESTE
        ↓
12. REPRODUZA
        ↓
13. CORRIJA A CAUSA
        ↓
14. FAÇA TESTE DE REGRESSÃO
        ↓
15. DOCUMENTE

Observe o item 13:

CORRIJA A CAUSA.

Não simplesmente o sintoma.


🩹 O remendo que cria o monstro

Programa:

IF WS-VALOR IS NUMERIC
   COMPUTE ...
END-IF.

Problema desapareceu.

CABÔ!

Talvez.

Mas espere.

Por que WS-VALOR não era numérico?

Se deveria obrigatoriamente ser...

você acabou de esconder um problema de qualidade de dados.

O programa não explode mais.

Agora apenas ignora silenciosamente dinheiro.

Excelente.

Transformamos um S0C7 visível em um erro contábil invisível.

Professor Pardal começa a suar frio.


🧪 Corrigir não é provar

Depois da alteração:

“Funcionou.”

Não significa:

“Está correto.”

Precisamos testar:

CASO ORIGINAL
CASOS NORMAIS
LIMITES
ZEROS
NEGATIVOS
VALORES MÁXIMOS
DADOS INVÁLIDOS
ARQUIVO VAZIO
DUPLICIDADES
ERROS DB2
ERROS CICS

E principalmente:

garantir que você não consertou uma coisa quebrando três.

Esse fenômeno é conhecido tecnicamente como:

sexta-feira às 17h43.


📚 Documente o incidente

Encontramos:

CAUSA:
campo VALOR recebeu caractere inválido.

ORIGEM:
programa anterior gerou registro inconsistente.

IMPACTO:
JOB FATURA01 interrompido.

CORREÇÃO:
validação corrigida na origem.

PREVENÇÃO:
teste adicionado.

Isso vale muito mais do que:

PROBLEMA RESOLVIDO.

Daqui a três anos outro programador pode encontrar situação semelhante.

E descobrir que o Professor Pardal de 2026 deixou um mapa.


🐔 O melhor debugger não é quem conhece todos os ABENDs

É quem sabe fazer boas perguntas.

O QUE FALHOU?

ONDE?

QUANDO?

COM QUAL DADO?

SEMPRE ACONTECE?

QUAL FOI A ÚLTIMA EXECUÇÃO BOA?

O QUE MUDOU?

CONSEGUIMOS REPRODUZIR?

QUAL VARIÁVEL ESTAVA ERRADA?

QUEM ALTEROU ESSA VARIÁVEL?

DE ONDE VEIO O DADO?

Cada resposta reduz o espaço de busca.

Debugging é uma batalha contra possibilidades.

Começamos com:

QUALQUER COISA PODE ESTAR ERRADA

e terminamos com:

ESTE BYTE ESTÁ ERRADO.

Isso é lindo.


☕ Professor Pardal termina seu café

Depois de duas horas de investigação encontramos a causa.

Um arquivo recebido por um programa COBOL possuía um registro:

0000000000000012578

e outro:

00000000000000A2578

Um único caractere.

Um miserável:

A

No meio de milhões de registros.

Esse pequeno A atravessou sistemas.

Passou por arquivos.

Entrou no programa.

Chegou a um campo tratado como numérico.

Esperou pacientemente.

Então encontrou uma operação decimal.

E derrubou um JOB gigantesco.

Milhares de linhas COBOL.

Db2.

JES2.

z/OS.

Mainframe de milhões de dólares.

Equipe de operações.

Desenvolvedores.

DBAs.

War Room.

Gestores.

Todos derrotados por:

A

Professor Pardal olha para Lampadinha.

Lampadinha olha para o dump.

O operador pergunta:

— Então era o mainframe?

Pardal responde:

— Não.

— Era COBOL?

— Não.

— Db2?

— Não.

— CICS?

— Também não.

— Então o que era?

Ele aponta para o registro.

A

Silêncio.

O JOB é reprocessado.

IEF142I FATURA01 STEP030 - STEP WAS EXECUTED
IEF285I
MAXCC=0000

E mais uma vez o gigantesco dinossauro de silício volta a trabalhar como se absolutamente nada tivesse acontecido.


🦖 A moral da história

Depois de décadas trabalhando com software, aprendemos uma coisa desconfortável:

os bugs mais difíceis nem sempre são tecnicamente sofisticados.

Às vezes são apenas pequenos.

Escondidos.

Intermitentes.

Dependentes de dados.

Dependentes de sequência.

Dependentes de uma combinação que acontece uma vez a cada cinco milhões de registros.

Por isso ferramentas são importantes.

Mas método é mais importante.

Professor Pardal pode possuir a oficina inteira.

Lampadinha pode possuir inteligência artificial.

Você pode ter o melhor debugger disponível.

Mas no final alguém ainda precisa perguntar:

“O que aconteceu imediatamente antes disso?”

E continuar perguntando.

Até encontrar aquele miserável byte que resolveu transformar uma madrugada tranquila em uma War Room.


☕ Epílogo — Um Café no Bellacosa Mainframe

03:58.

Incidente encerrado.

Professor Pardal guarda suas ferramentas.

Lampadinha desliga a IA.

Operações fecha o chamado.

O gerente pergunta:

“Podemos considerar causa raiz identificada?”

Sim.

“Podemos evitar recorrência?”

Sim.

“Precisamos de reunião amanhã?”

...

Professor Pardal olha para o relógio.

Olha para o mainframe.

Olha para Lampadinha.

Lampadinha discretamente apaga a luz.

E ambos fogem de Patópolis antes que alguém consiga pronunciar:

“Post-Mortem.”

🐔🔧☕🦖

JOB DEBUGPARDAL — MAXCC=0000

E todos viveram felizes...

até o próximo S0C7.

https://eljefemidnightlunch.blogspot.com/2026/06/a-saga-de-vagner-bellacosa-no-reino-dos.html

DISPLAY e BUG TRAP as melhores maneiras de debugar um programa COBOL. Qual é a sua técnica? #ibm #mainframe #cobol #debug #trap #bug #returncode #maxcc #jcl #sdsf #job

 

segunda-feira, 19 de agosto de 2024

Conversão do REAL um grande trabalho da informática mainframe


A resiliência e a tenacidade técnica dos Analistas de Sistemas Mainframe, que em quatro dias conseguiram virar a chave, convertendo sistemas críticos para a conversão de moeda, do URV para o REAL. 



Feriado bancário na Sexta-feira, mas Segunda-feira estava tudo no ar, funcionando, quatro dias de loucura no Departamento de Informatica, muita pizza, companheirismo, horas-extra, mas sensação de dever cumprido. 




 Programas em COBOL, PLI e Natural em Sistemas Mainframe alterados para a conversão da Moeda, sem perdas ou prejuízos aos clientes e empresas. Sendo um Caso de Estudo de Sucesso, visto de perto pelas autoridades europeias, que passado 7 anos repetiram o processo na Conversão do Euro.

#ibm #mainframe #real #urv #conversao #cobol #natural #jcl #pli #db2 #adabas #job #sistemas #dev #programador #sucesso
 

domingo, 18 de agosto de 2024

Inteligência Artificial na Segurança Bancária sem Mistérios

Bellacosa Mainframe e a inteligencia artificial na seguranca bancaria


☕ Um Café no Bellacosa Mainframe

Inteligência Artificial na Segurança Bancária sem Mistérios

O Guia do Programador COBOL Padawan para Entender Biometria, Fraudes, Autenticação Contínua e os Escudos Digitais da Frota Estelar

Imagine, jovem programador COBOL Padawan, que você está sentado diante de um terminal 3270 em uma madrugada silenciosa.

Ao lado do teclado, uma caneca de café ainda quente. Na tela verde, um programa aparentemente simples processa uma transferência bancária. Ele recebe uma conta de origem, uma conta de destino, um valor e uma data. Depois de algumas validações, o sistema autoriza ou rejeita a operação.

Durante décadas, essa lógica pareceu suficiente.

O cliente informava a senha correta, o saldo era consultado, os limites eram verificados e a transação seguia seu caminho pelos corredores eletrônicos do banco.

Mas a galáxia financeira mudou.

Hoje, o usuário pode estar acessando o banco por um celular, conectado a uma rede pública, utilizando reconhecimento facial, fazendo um PIX para um novo destinatário e movimentando um valor muito diferente de seu padrão habitual.

Ao mesmo tempo, o criminoso pode possuir a senha verdadeira, o CPF, o número do telefone, documentos vazados, gravações da voz da vítima e até uma cópia artificial de seu rosto produzida por inteligência artificial.

A pergunta deixou de ser apenas:

“A senha está correta?”

Agora o banco precisa perguntar:

“Essa operação parece realmente estar sendo realizada pelo cliente?”

Essa mudança representa uma das maiores transformações na história da segurança bancária.

A segurança deixou de ser apenas um portão na entrada do sistema. Ela passou a acompanhar o cliente durante toda a jornada.

É como se os sistemas financeiros tivessem aprendido uma antiga lição da Frota Estelar:

Não basta identificar quem entrou na nave. É necessário observar o que essa pessoa faz depois de entrar.

Prepare o café, ajuste seu comunicador e abra uma nova sessão no TSO. Nossa missão será entender como inteligência artificial, biometria, autenticação multifator, análise comportamental, modelos de risco e mainframes trabalham juntos para proteger o sistema financeiro moderno.


1. O velho modelo: usuário, senha e confiança

Durante muito tempo, a segurança digital funcionou com uma lógica simples.

O usuário informava:

  • identificação;

  • senha;

  • eventualmente um código adicional.

Se tudo estivesse correto, o acesso era concedido.

Em pseudocódigo COBOL, poderíamos imaginar algo assim:

IF SENHA-INFORMADA = SENHA-CADASTRADA
    MOVE 'S' TO ACESSO-AUTORIZADO
ELSE
    MOVE 'N' TO ACESSO-AUTORIZADO
END-IF

A lógica é clara, objetiva e fácil de compreender.

O problema é que ela responde apenas a uma pergunta:

A credencial apresentada corresponde à credencial armazenada?

Ela não responde:

  • quem digitou a senha;

  • onde a senha foi digitada;

  • em qual dispositivo;

  • em qual horário;

  • em qual contexto;

  • com qual intenção;

  • se o comportamento é compatível com o histórico do cliente.

Se um criminoso roubar a senha verdadeira, o sistema tradicional poderá tratá-lo como usuário legítimo.

Esse é um dos princípios fundamentais para compreender a segurança moderna:

Uma credencial válida não significa necessariamente uma identidade legítima.

Senhas podem ser descobertas por phishing, engenharia social, vazamentos de dados, malware, observação física, reutilização em vários serviços ou manipulação psicológica.

Um cliente pode entregar voluntariamente um código de segurança acreditando estar falando com um funcionário do banco.

Nesse caso, tecnicamente, as informações estão corretas. Porém, a operação continua sendo fraudulenta.

A segurança bancária moderna precisou evoluir de uma validação estática para uma avaliação contínua de risco.


2. O criminoso não precisa arrombar a porta

Existe uma imagem clássica do invasor digital: alguém tentando quebrar uma senha, explorar uma falha ou invadir um servidor.

Esse tipo de ataque continua existindo.

Porém, muitos golpes atuais seguem um caminho mais silencioso.

O fraudador pode convencer a própria vítima a:

  • instalar um aplicativo;

  • compartilhar a tela;

  • fornecer um código;

  • transferir dinheiro;

  • cadastrar um novo dispositivo;

  • autorizar um pagamento;

  • entregar informações pessoais.

O criminoso não precisa destruir os escudos da nave.

Ele pode convencer o oficial de segurança a desativá-los.

Essa é a essência da engenharia social.

Os ataques modernos exploram não apenas sistemas, mas também emoções humanas:

  • medo;

  • urgência;

  • autoridade;

  • curiosidade;

  • ganância;

  • confiança;

  • pressão psicológica.

Uma mensagem pode dizer:

“Sua conta será bloqueada em dez minutos.”

Outra pode afirmar:

“Identificamos uma compra suspeita. Confirme seus dados agora.”

O cliente, preocupado, segue as instruções do próprio fraudador.

Por isso, proteger apenas a senha é insuficiente. O sistema precisa avaliar o contexto completo da operação.


3. A autenticação não termina no login

No modelo antigo, o login era considerado o grande momento da segurança.

A sequência era:

Identificação
      ↓
Senha
      ↓
Acesso autorizado

Depois do acesso, o sistema passava a confiar no usuário.

No modelo moderno, a sequência é muito mais ampla:

Identificação
      ↓
Senha ou credencial
      ↓
Biometria
      ↓
Dispositivo
      ↓
Localização
      ↓
Comportamento
      ↓
Análise de risco
      ↓
Monitoramento da sessão
      ↓
Reavaliação a cada operação

A autenticação tornou-se contínua.

Isso significa que uma sessão pode começar com baixo risco e, alguns minutos depois, apresentar sinais suspeitos.

Por exemplo:

  1. O cliente acessa o aplicativo em seu celular habitual.

  2. Consulta o saldo.

  3. Navega normalmente.

  4. Em seguida, cadastra um novo favorecido.

  5. Solicita um empréstimo.

  6. Transfere imediatamente todo o valor.

  7. O destino é uma conta nunca utilizada.

  8. O comportamento de digitação é diferente.

  9. O aparelho parece estar sendo controlado remotamente.

Cada ação, isoladamente, pode ser legítima.

Porém, o conjunto forma um padrão de alto risco.

A inteligência artificial consegue observar essa sequência em tempo real e recalcular a probabilidade de fraude.

Em outras palavras, o sistema deixa de perguntar apenas:

“Quem entrou?”

E passa a perguntar constantemente:

“O que está acontecendo agora?”


4. Zero Trust: nunca confiar automaticamente

Um dos conceitos mais importantes da segurança moderna é o chamado Zero Trust.

O nome pode parecer severo, mas sua lógica é bastante racional:

Nunca confie automaticamente. Sempre verifique.

Isso não significa tratar todos os clientes como criminosos.

Significa não depender de uma única prova de identidade.

Mesmo um usuário autenticado precisa continuar sendo avaliado.

Na Frota Estelar, possuir um uniforme não seria suficiente para acessar o núcleo de dobra. O sistema também verificaria:

  • identidade;

  • patente;

  • autorização;

  • localização;

  • horário;

  • missão;

  • contexto;

  • nível de risco.

No setor bancário, acontece algo semelhante.

Uma transferência pode exigir verificações adicionais conforme o risco.

Por exemplo:

EVALUATE NIVEL-RISCO
    WHEN 'BAIXO'
        PERFORM AUTORIZAR-TRANSACAO
    WHEN 'MEDIO'
        PERFORM SOLICITAR-SEGUNDO-FATOR
    WHEN 'ALTO'
        PERFORM BLOQUEAR-TRANSACAO
        PERFORM GERAR-ALERTA
    WHEN OTHER
        PERFORM ENCAMINHAR-ANALISE-MANUAL
END-EVALUATE

Esse exemplo mostra um ponto importante: segurança moderna não é apenas “permitir” ou “negar”.

Ela pode aplicar diferentes respostas:

  • liberar;

  • solicitar biometria;

  • solicitar token;

  • limitar valor;

  • atrasar a operação;

  • enviar alerta;

  • bloquear temporariamente;

  • encaminhar para análise humana.

O sistema adapta a proteção ao risco observado.


5. A IA não procura apenas criminosos

Muitas pessoas imaginam que a inteligência artificial possui uma lista de fraudadores conhecidos e compara cada usuário com essa lista.

Isso pode fazer parte do processo, mas é apenas uma pequena parte.

Na prática, a IA busca principalmente anomalias.

Uma anomalia é algo diferente do padrão esperado.

Considere um cliente que, durante vários anos:

  • acessa o aplicativo entre 7h e 22h;

  • utiliza sempre o mesmo celular;

  • mora no interior de São Paulo;

  • movimenta valores entre R$ 50 e R$ 1.000;

  • realiza pagamentos para poucos destinatários conhecidos.

Agora imagine a seguinte operação:

  • acesso às 3h17;

  • novo aparelho;

  • nova localização;

  • uso de VPN;

  • tentativa de empréstimo;

  • transferência de R$ 48.000;

  • destinatário recém-cadastrado.

Nenhum desses elementos, sozinho, prova uma fraude.

Um cliente pode viajar, trocar de celular ou realizar uma transferência elevada.

Mas o conjunto aumenta fortemente o risco.

A IA analisa dezenas ou centenas de sinais ao mesmo tempo.

Ela não pergunta simplesmente:

“Essa pessoa é criminosa?”

Ela pergunta:

“Esse comportamento é compatível com o histórico e o contexto esperado?”

Essa diferença é essencial.


6. Machine Learning: ensinando o sistema a reconhecer padrões

O aprendizado de máquina, ou Machine Learning, permite que sistemas identifiquem padrões a partir de grandes volumes de dados.

Um sistema antifraude pode aprender com:

  • transações legítimas;

  • fraudes confirmadas;

  • horários;

  • valores;

  • localização;

  • dispositivos;

  • destinatários;

  • canais utilizados;

  • comportamento de navegação;

  • velocidade das ações;

  • respostas a autenticações;

  • histórico de contestação.

Imagine milhões de transações sendo processadas diariamente.

Nenhum analista humano conseguiria revisar cada uma em tempo real.

A inteligência artificial consegue calcular rapidamente a probabilidade de uma operação ser legítima ou suspeita.

Um modelo simplificado poderia considerar:

Dispositivo conhecido: risco reduzido
Localização habitual: risco reduzido
Valor muito elevado: risco aumentado
Novo favorecido: risco aumentado
Horário incomum: risco aumentado
Biometria válida: risco reduzido
Aparelho comprometido: risco elevado

O resultado final pode ser transformado em um score.

Exemplo:

Score de risco: 12 de 100
Decisão: autorizar

Outro caso:

Score de risco: 87 de 100
Decisão: bloquear e solicitar validação

Para o programador COBOL iniciante, pense no score como um campo calculado a partir de várias condições.

MOVE ZERO TO SCORE-RISCO

IF DISPOSITIVO-NOVO = 'S'
    ADD 20 TO SCORE-RISCO
END-IF

IF LOCALIZACAO-INCOMUM = 'S'
    ADD 25 TO SCORE-RISCO
END-IF

IF VALOR-ACIMA-PADRAO = 'S'
    ADD 30 TO SCORE-RISCO
END-IF

IF BIOMETRIA-VALIDA = 'S'
    SUBTRACT 20 FROM SCORE-RISCO
END-IF

Os modelos reais são muito mais complexos, mas o princípio permanece semelhante: sinais são combinados para apoiar uma decisão.


7. Biometria: muito além da impressão digital

A biometria utiliza características humanas para validar a identidade.

As formas mais conhecidas incluem:

  • impressão digital;

  • reconhecimento facial;

  • voz;

  • íris;

  • geometria da mão.

A grande vantagem é que características biométricas são mais difíceis de compartilhar, esquecer ou digitar acidentalmente em um site falso.

Entretanto, biometria não deve ser tratada como solução mágica.

Uma fotografia pode ser roubada. Uma voz pode ser gravada. Um rosto pode ser reproduzido por deepfake.

Por isso, sistemas modernos utilizam mecanismos chamados de prova de vida, ou liveness detection.

A prova de vida tenta verificar se existe uma pessoa real diante do dispositivo.

Ela pode observar:

  • profundidade facial;

  • movimentos naturais;

  • reflexos;

  • textura da pele;

  • resposta a comandos;

  • movimentação dos olhos;

  • sincronização labial;

  • pequenas variações impossíveis em uma fotografia estática.

Um sistema pode pedir:

“Mova o rosto para a esquerda.”

Ou analisar silenciosamente características tridimensionais.

O objetivo é diferenciar uma pessoa real de:

  • fotografia;

  • vídeo;

  • máscara;

  • tela reproduzindo outro rosto;

  • conteúdo sintético.

Curiosidade de bordo: em histórias de ficção científica, scanners biométricos quase sempre reconhecem rostos instantaneamente. Na vida real, iluminação, câmera, ângulo, envelhecimento e qualidade do sensor tornam o problema muito mais complexo.


8. Biometria comportamental: a assinatura invisível

A biometria tradicional analisa características físicas.

A biometria comportamental analisa como uma pessoa interage com o sistema.

Ela pode observar:

  • ritmo de digitação;

  • tempo entre teclas;

  • força aplicada na tela;

  • velocidade do toque;

  • inclinação do aparelho;

  • forma de segurar o celular;

  • movimento do mouse;

  • padrão de rolagem;

  • tempo de leitura;

  • sequência de navegação.

Imagine duas pessoas digitando a mesma senha.

A primeira digita rapidamente, utilizando os dois polegares.

A segunda faz pausas, utiliza um dedo e pressiona determinadas teclas por mais tempo.

O texto é igual, mas o comportamento é diferente.

Essas diferenças formam uma espécie de assinatura invisível.

Outro exemplo:

O cliente legítimo normalmente abre o aplicativo, verifica o saldo, consulta o extrato e depois faz uma transferência.

O fraudador pode entrar diretamente na opção de empréstimo, contratar o valor máximo e transferir imediatamente.

O caminho percorrido dentro da aplicação também é um sinal.

A grande vantagem da biometria comportamental é que ela pode funcionar silenciosamente, sem exigir ações adicionais do usuário.

O cliente legítimo percebe menos fricção.

O fraudador encontra mais barreiras.


9. Autenticação contextual: onde, quando, como e com quê

A autenticação contextual analisa as circunstâncias da operação.

Entre os sinais avaliados estão:

  • localização;

  • endereço IP;

  • operadora;

  • rede Wi-Fi;

  • horário;

  • idioma;

  • fuso horário;

  • modelo do dispositivo;

  • versão do sistema;

  • navegador;

  • resolução da tela;

  • presença de VPN;

  • histórico do aparelho.

Imagine um cliente que mora em Campinas e acessa o banco às 14h.

Cinco minutos depois, ocorre outro acesso a partir de outro continente.

Fisicamente, isso seria impossível.

Esse tipo de evento pode ser classificado como viagem impossível.

O sistema pode bloquear a nova sessão ou solicitar validação adicional.

Outro exemplo:

Um cliente sempre utiliza o aplicativo em um aparelho Android específico. De repente, ocorre um acesso em um emulador, com sistema modificado e ferramentas de automação.

Esse contexto aumenta o risco, mesmo que a senha esteja correta.

A autenticação contextual não substitui a senha ou a biometria. Ela adiciona mais evidências.

É como uma investigação vulcana: nenhuma conclusão é baseada em uma única pista.


10. Token e autenticação multifator

A autenticação multifator combina diferentes tipos de prova.

Os fatores costumam ser divididos em três categorias:

Algo que você sabe

  • senha;

  • PIN;

  • resposta secreta.

Algo que você possui

  • celular;

  • cartão;

  • token físico;

  • aplicativo autenticador.

Algo que você é

  • rosto;

  • impressão digital;

  • voz;

  • íris.

Usar dois ou mais fatores reduz o risco de uma única credencial comprometida permitir acesso completo.

Porém, até a autenticação multifator pode ser atacada.

Códigos podem ser interceptados. Usuários podem ser convencidos a aprovar notificações. Chips podem ser clonados ou transferidos ilegalmente.

Por isso, o setor caminha para uma combinação mais ampla:

Senha
+
Dispositivo
+
Biometria
+
Contexto
+
Comportamento
+
Análise de risco

Quanto mais coerentes forem os sinais, maior a confiança.

Quanto mais contraditórios, maior a necessidade de verificação.


11. A luta contra falsos positivos

Bloquear fraudes é importante.

Mas bloquear clientes legítimos também causa problemas.

Imagine um cliente tentando pagar uma cirurgia, comprar uma passagem ou transferir dinheiro em uma emergência. Se o banco bloquear a operação sem necessidade, a experiência será péssima.

Isso é chamado de falso positivo.

Um falso positivo ocorre quando uma operação legítima é classificada como fraude.

Já um falso negativo ocorre quando uma fraude é classificada como legítima.

O grande desafio é equilibrar os dois.

Se o sistema for rígido demais, bloqueia clientes honestos.

Se for permissivo demais, deixa passar fraudes.

A inteligência artificial ajuda a encontrar um equilíbrio mais preciso.

Em vez de criar uma regra fixa como:

Toda transferência acima de R$ 10.000 deve ser bloqueada.

O sistema pode analisar:

  • renda do cliente;

  • histórico;

  • destinatário;

  • horário;

  • dispositivo;

  • localização;

  • motivo;

  • frequência;

  • comportamento.

Para um cliente, R$ 10.000 pode ser altamente incomum.

Para outro, pode ser uma operação diária.

A análise precisa ser contextual.


12. Aprendizado contínuo: o inimigo também evolui

Fraudadores testam constantemente novas técnicas.

Quando os bancos melhoram a autenticação, surgem novos golpes de engenharia social.

Quando os sistemas detectam determinados padrões, os criminosos tentam imitá-los.

Quando a biometria facial avança, aparecem deepfakes mais sofisticados.

É uma corrida permanente.

Por isso, modelos antifraude precisam ser atualizados continuamente.

O ciclo pode ser representado assim:

Fraude acontece
      ↓
Caso é investigado
      ↓
Padrão é identificado
      ↓
Modelo é ajustado
      ↓
Novas transações são protegidas
      ↓
Resultados são monitorados

Esse processo exige participação humana.

Analistas investigam alertas, confirmam fraudes, corrigem classificações e ajudam a melhorar os modelos.

A inteligência artificial não elimina o especialista.

Ela amplia sua capacidade.

Um analista que antes revisava cem casos pode concentrar-se nos casos mais críticos, enquanto o sistema automatiza a triagem inicial.


13. Inteligência artificial generativa na segurança bancária

Além dos modelos tradicionais de Machine Learning, a inteligência artificial generativa também pode apoiar equipes de segurança.

Ela pode:

  • resumir alertas;

  • explicar motivos de bloqueio;

  • organizar evidências;

  • gerar relatórios;

  • auxiliar investigações;

  • consultar políticas internas;

  • traduzir documentos;

  • correlacionar eventos;

  • apoiar equipes de atendimento.

Imagine um analista recebendo milhares de logs.

Uma IA pode produzir um resumo:

“A operação foi classificada como alto risco devido a novo dispositivo, localização incomum, valor 14 vezes superior à média e cadastramento recente do beneficiário.”

Isso reduz o tempo necessário para entender o caso.

Porém, decisões críticas não devem depender cegamente de uma resposta gerada.

Modelos generativos podem cometer erros, interpretar dados incorretamente ou produzir explicações convincentes, porém falsas.

Por isso, devem operar com:

  • dados confiáveis;

  • limites claros;

  • revisão humana;

  • rastreabilidade;

  • controle de acesso;

  • monitoramento.

Na ponte da nave, a IA pode ser um excelente oficial científico. Mas o comando final ainda exige responsabilidade.


14. LGPD, privacidade e governança

Quanto mais dados são analisados, maior a responsabilidade.

Sistemas antifraude podem processar:

  • identidade;

  • localização;

  • comportamento;

  • dispositivo;

  • histórico financeiro;

  • biometria;

  • dados de navegação.

Essas informações são extremamente sensíveis.

No Brasil, a LGPD estabelece princípios para o tratamento de dados pessoais.

Os bancos precisam considerar:

  • finalidade;

  • necessidade;

  • transparência;

  • segurança;

  • prevenção;

  • responsabilização;

  • direitos do titular.

Não basta dizer:

“Usamos muitos dados porque segurança é importante.”

A instituição precisa demonstrar:

  • por que os dados são necessários;

  • como são protegidos;

  • quem pode acessá-los;

  • por quanto tempo são mantidos;

  • como decisões são tomadas;

  • como incidentes são tratados.

Também existem exigências relacionadas a:

  • prevenção à lavagem de dinheiro;

  • conhecimento do cliente;

  • monitoramento de operações;

  • auditoria;

  • gestão de riscos;

  • identidade digital;

  • controles internos.

A segurança precisa proteger o cliente sem transformar o sistema em uma máquina de vigilância sem limites.

Esse equilíbrio é um dos maiores desafios éticos e regulatórios da era da IA.


15. IA explicável e responsabilidade

Imagine receber a seguinte mensagem:

“Sua transação foi bloqueada pela inteligência artificial.”

Isso não explica nada.

Em sistemas críticos, decisões precisam ser auditáveis.

O banco deve conseguir responder:

  • qual modelo tomou a decisão;

  • qual versão estava em uso;

  • quais dados foram considerados;

  • quais sinais aumentaram o risco;

  • quem revisou o caso;

  • qual política foi aplicada.

Esse campo é conhecido como Explainable AI, ou IA explicável.

Nem todo modelo complexo é fácil de explicar. Porém, instituições financeiras precisam buscar formas de tornar decisões compreensíveis e rastreáveis.

Um relatório pode mostrar:

Motivos principais do bloqueio:

1. Novo dispositivo.
2. Localização incompatível.
3. Transferência 20 vezes superior à média.
4. Beneficiário cadastrado há menos de cinco minutos.
5. Comportamento de navegação fora do padrão.

Isso ajuda:

  • analistas;

  • auditores;

  • reguladores;

  • atendimento;

  • clientes;

  • equipes jurídicas.

A responsabilidade não pode ser transferida para a máquina.

Dizer “o algoritmo decidiu” não encerra a discussão.


16. Onde entra o mainframe?

Agora chegamos ao território familiar do programador COBOL Padawan.

Muitos grandes bancos continuam utilizando mainframes para processar operações críticas.

O IBM Z pode participar de funções como:

  • manutenção de contas;

  • atualização de saldos;

  • processamento de cartões;

  • liquidação;

  • crédito;

  • cadastro;

  • movimentação financeira;

  • auditoria;

  • processamento em lote;

  • integração com redes externas.

A inteligência artificial não necessariamente substitui esses sistemas.

Ela pode atuar ao redor deles ou integrada a eles.

Uma arquitetura simplificada poderia ser:

Aplicativo móvel
      ↓
API de autenticação
      ↓
Biometria e análise de dispositivo
      ↓
Motor antifraude com IA
      ↓
Score de risco
      ↓
API bancária
      ↓
CICS / IMS / Db2 / COBOL
      ↓
Autorização ou rejeição

O programa COBOL pode receber um indicador de risco.

Exemplo:

01  DADOS-TRANSACAO.
    05 CONTA-ORIGEM        PIC 9(10).
    05 CONTA-DESTINO       PIC 9(10).
    05 VALOR-TRANSACAO     PIC 9(11)V99.
    05 SCORE-RISCO         PIC 9(03).
    05 STATUS-BIOMETRIA    PIC X.
    05 DISPOSITIVO-NOVO    PIC X.

IF SCORE-RISCO GREATER THAN 80
    MOVE 'B' TO STATUS-TRANSACAO
    PERFORM REGISTRAR-BLOQUEIO
ELSE
    PERFORM PROCESSAR-TRANSFERENCIA
END-IF

Esse é apenas um exemplo didático.

Em uma arquitetura real, a decisão pode envolver motores especializados, regras, APIs, filas, eventos, banco de dados, monitoração e aprovação humana.

O ponto principal é:

O mainframe não está separado da inteligência artificial. Ele pode ser parte central da cadeia de decisão.

A IA funciona como sensor e oficial de análise.

O core bancário funciona como motor transacional.

Ambos precisam conversar de maneira rápida, confiável e segura.


17. Passo a passo de uma transação moderna

Vamos acompanhar uma transferência do início ao fim.

Passo 1 — O cliente abre o aplicativo

O sistema identifica:

  • modelo do aparelho;

  • versão do sistema;

  • endereço IP;

  • localização aproximada;

  • integridade do dispositivo;

  • histórico de uso.

Passo 2 — O cliente autentica

Pode utilizar:

  • senha;

  • PIN;

  • impressão digital;

  • reconhecimento facial;

  • token.

Passo 3 — O comportamento é observado

O sistema analisa:

  • velocidade de navegação;

  • forma de digitação;

  • sequência de telas;

  • padrão de toque;

  • tempo de resposta.

Passo 4 — A transferência é criada

São coletados:

  • valor;

  • destinatário;

  • banco;

  • horário;

  • frequência;

  • histórico entre as contas.

Passo 5 — A IA calcula o risco

O modelo compara a operação com:

  • padrão do cliente;

  • padrões de fraude;

  • comportamento de contas semelhantes;

  • alertas recentes;

  • reputação do dispositivo;

  • sinais de comprometimento.

Passo 6 — O motor de decisão atua

A operação pode ser:

  • aprovada;

  • aprovada com limite;

  • submetida a biometria;

  • submetida a segundo fator;

  • colocada em espera;

  • bloqueada;

  • enviada para análise.

Passo 7 — O core bancário processa

O sistema transacional verifica:

  • saldo;

  • limite;

  • situação da conta;

  • regras financeiras;

  • disponibilidade;

  • consistência.

Passo 8 — Tudo é registrado

Logs e trilhas de auditoria armazenam:

  • decisão;

  • horário;

  • modelo;

  • score;

  • fatores utilizados;

  • resultado final.

Passo 9 — O sistema aprende

Se a operação for confirmada como fraude, o caso pode alimentar melhorias futuras.

Se o cliente confirmar que era legítima, o sistema também aprende.

Esse ciclo acontece milhões de vezes.


18. Dicas para o programador COBOL Padawan

Mesmo que você não trabalhe diretamente com IA, existem conhecimentos importantes para sua carreira.

Entenda a origem dos dados

Pergunte sempre:

  • quem gerou o score;

  • quando foi calculado;

  • qual o formato;

  • qual a validade;

  • o que fazer se estiver ausente.

Nunca confie cegamente em um campo externo

Um score recebido por API precisa ser validado.

IF SCORE-RISCO NOT NUMERIC
    PERFORM TRATAR-ERRO
END-IF

Registre decisões importantes

Operações críticas precisam de auditoria.

Não basta bloquear. É necessário registrar por quê.

Trate indisponibilidade

O que acontece se o motor de IA estiver fora do ar?

O sistema deve:

  • bloquear tudo;

  • liberar operações de baixo valor;

  • usar regras locais;

  • encaminhar para contingência?

Essa decisão precisa ser definida antecipadamente.

Evite decisões sem explicação

Um campo “RISCO-ALTO” pode ser insuficiente.

Sempre que possível, receba códigos de motivo.

01 — Dispositivo novo
02 — Valor anormal
03 — Localização suspeita
04 — Beneficiário recente

Proteja dados sensíveis

Logs não devem expor:

  • senha;

  • token;

  • biometria;

  • número completo de cartão;

  • informações pessoais desnecessárias.

Pense em performance

Uma análise antifraude não pode levar vários segundos durante uma compra.

Tempo de resposta é parte da experiência e da arquitetura.

Conheça o fluxo completo

O programador não deve enxergar apenas o programa COBOL.

Ele deve compreender:

  • canal digital;

  • API;

  • mensageria;

  • motor de risco;

  • CICS;

  • Db2;

  • logs;

  • monitoração;

  • atendimento;

  • auditoria.

É assim que um Padawan se transforma em arquiteto da Frota.


19. Curiosidades da galáxia antifraude

Curiosidade 1 — Seu jeito de usar o celular pode identificá-lo

A forma como você inclina o aparelho, toca a tela e digita pode compor um padrão comportamental.

Curiosidade 2 — Uma transação legítima pode parecer suspeita

Comprar uma passagem internacional, trocar de telefone e fazer uma transferência elevada no mesmo dia pode gerar alertas, mesmo sendo legítimo.

Curiosidade 3 — Fraude não é apenas invasão de conta

Também pode envolver:

  • abertura de conta falsa;

  • documentos adulterados;

  • crédito obtido ilegalmente;

  • lavagem de dinheiro;

  • uso de contas de terceiros;

  • identidades sintéticas.

Curiosidade 4 — O cliente pode estar autenticado e ainda assim ser vítima

Em golpes de falsa central, a própria vítima realiza a operação sob orientação do criminoso.

Nesse caso, senha, biometria e dispositivo podem estar corretos.

A análise comportamental e contextual torna-se ainda mais importante.

Curiosidade 5 — Regras antigas ainda têm valor

A IA não elimina regras tradicionais.

Muitas arquiteturas combinam:

  • regras fixas;

  • modelos estatísticos;

  • Machine Learning;

  • listas de bloqueio;

  • análise humana.

A melhor defesa costuma ser híbrida.


20. Easter egg para quem chegou até aqui

Em algum ponto desta missão, talvez você tenha percebido que o sistema antifraude se comporta como o computador da USS Enterprise.

Ele observa milhares de sensores, compara padrões, calcula probabilidades e alerta a tripulação quando algo foge do esperado.

Mas existe uma diferença importante.

Nos episódios clássicos, o computador frequentemente anunciava:

“Intruder alert.”

Nos bancos modernos, o alerta pode ser muito mais discreto.

Talvez o cliente apenas receba uma solicitação de biometria adicional.

Talvez a transferência seja atrasada por alguns segundos.

Talvez um analista receba uma notificação.

Talvez um programa COBOL execute um simples:

MOVE 'N' TO TRANSACAO-AUTORIZADA

Por trás desse único caractere podem existir:

  • milhões de registros;

  • dezenas de algoritmos;

  • centenas de sinais;

  • decisões regulatórias;

  • motores de risco;

  • APIs;

  • mainframes;

  • criptografia;

  • auditoria;

  • análise humana.

O humilde MOVE 'N' pode ser o último escudo antes de uma fraude milionária.

Essa é a beleza invisível dos sistemas corporativos.


Conclusão: os novos escudos da Frota Financeira

A segurança bancária não pode mais depender apenas de senhas.

O cenário moderno exige uma combinação de:

  • inteligência artificial;

  • biometria;

  • autenticação multifator;

  • análise comportamental;

  • contexto;

  • tokens;

  • monitoramento contínuo;

  • governança;

  • auditoria;

  • intervenção humana.

A IA permite analisar enormes volumes de transações em tempo real, identificar comportamentos anormais, calcular riscos e responder antes que o prejuízo aconteça.

A biometria ajuda a validar identidade.

A análise comportamental observa como o cliente interage.

A autenticação contextual avalia onde, quando e em qual dispositivo a operação ocorre.

O mainframe garante que a transação seja processada com consistência, disponibilidade e segurança.

Nenhuma dessas tecnologias funciona perfeitamente sozinha.

A verdadeira força está na integração.

Assim como uma nave da Frota Estelar depende de sensores, escudos, computadores, motores, oficiais e protocolos, um banco moderno depende de várias camadas trabalhando em conjunto.

Para o programador COBOL iniciante, a principal lição é clara:

O código que processa uma transação é apenas uma parte de uma missão muito maior.

Por trás de cada autorização existem decisões de segurança, dados, modelos, regras, APIs, auditoria e responsabilidade.

Aprender COBOL continua sendo importante.

Mas compreender o ecossistema ao redor do COBOL é o que transforma um simples programador em um profissional preparado para os sistemas financeiros do futuro.

Quando você encontrar no código um campo chamado SCORE-RISCO, STATUS-BIOMETRIA, IND-FRAUDE ou COD-MOTIVO-BLOQUEIO, não o veja apenas como mais uma variável.

Veja-o como uma mensagem enviada pelos sensores da nave.

Analise.

Valide.

Registre.

Proteja.

E nunca se esqueça da principal diretriz da segurança moderna:

Confiança não é um estado permanente. É uma conclusão que precisa ser reavaliada continuamente.

Vida longa ao COBOL.

Vida longa ao mainframe.

E que os escudos permaneçam ativos em todas as transações da galáxia financeira.


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