Bellacosa Mainframe e o processamento do cartão de credito

☕ Um Café no Bellacosa Mainframe

💳 BELLACARD — Como seria um sistema de cartões de crédito dentro de um IBM Mainframe?

Do “BIP!” da maquininha ao COBOL, CICS, Db2, MQ, JCL, RACF, criptografia, antifraude, clearing, settlement e bilhões de transações que ninguém percebe.

Imagine a cena.

Você entra numa cafeteria, pede um café, aproxima o cartão da maquininha e...

BIP!

TRANSAÇÃO APROVADA
R$ 17,50

Você guarda o cartão, pega o café e continua a vida.

Talvez tenham se passado dois segundos.

Para o consumidor, acabou.

Para um programador mainframe curioso, porém, aconteceu uma pequena maravilha tecnológica.

Aqueles poucos segundos podem envolver terminal de pagamento, adquirente, rede de cartões, banco emissor, sistemas de autorização, criptografia, verificação do cartão, consulta de limites, regras de segurança, sistemas antifraude, bancos de dados, logs, mensagens entre plataformas e uma resposta que precisa percorrer boa parte desse caminho no sentido contrário.

E ainda não acabou.

Mais tarde haverá processamento financeiro, clearing, settlement, conciliação, lançamento da compra, fechamento da fatura, eventual parcelamento, pagamento, contabilização, estorno, contestação e talvez até um chargeback.

A humilde compra do café abriu uma pequena saga computacional.

E é exatamente por isso que cartões de crédito são um excelente laboratório para entender por que mainframes existem.

Então coloque café na caneca.

Hoje construiremos mentalmente o:

💳 BELLACARD — Credit Card Processing System for z/OS

Não será o projeto real de nenhum banco ou bandeira. Será uma arquitetura didática para entendermos como tecnologias como COBOL, CICS, Db2, MQ, JCL/JES2, RACF, criptografia, SMF, WLM e Parallel Sysplex podem participar de um grande sistema financeiro.

🏪 Capítulo 1 — Tudo começa com R$ 100

Imagine uma compra:

CLIENTE:       JOÃO
VALOR:         R$ 100,00
ESTABELECIMENTO: CAFÉ DO MAINFRAME
FORMA:         CARTÃO

O cartão é apresentado.

A maquininha não conhece necessariamente o saldo da conta do cliente.

O estabelecimento também não.

A adquirente não é necessariamente quem concedeu o crédito.

Existe uma cadeia.

Simplificando:

CARDHOLDER
    │
    ▼
MERCHANT
    │
    ▼
ACQUIRER
    │
    ▼
CARD NETWORK
    │
    ▼
ISSUER

Visa e Mastercard, por exemplo, operam redes que conectam os participantes do ecossistema.

O banco emissor é quem conhece o cartão, sua situação, conta relacionada, limite e diversas regras necessárias para decidir se aquela operação pode prosseguir.

Portanto, eventualmente surge uma pergunta:

“Banco, você autoriza esta compra?”

É aí que nosso BELLACARD acorda.

📨 Capítulo 2 — Uma mensagem bate à porta

Imagine que recebamos uma representação simplificada da operação:

TRANSACTION TYPE : PURCHASE
CARD TOKEN        : 987654321
AMOUNT            : 100.00
CURRENCY          : BRL
MERCHANT ID       : 785932
MCC               : 5812
COUNTRY            : BRA
ENTRY MODE         : CONTACTLESS
DATE               : 20260914
TIME               : 031700

Sim.

03:17.

Quem acompanha o Bellacosa Mainframe sabe que esse horário nunca aparece por acidente.

😏

Nosso primeiro easter egg já foi registrado.

Em sistemas reais, mensagens de cartões podem utilizar padrões e protocolos próprios do setor, incluindo famílias baseadas em ISO 8583, além de APIs e formatos modernos dependendo da integração.

Para nosso iniciante COBOL, entretanto, vamos imaginar simplesmente um registro chegando ao mainframe.

🖥️ Capítulo 3 — CICS, atenda a porta!

Dentro do z/OS poderíamos possuir uma transação CICS:

AUTH

Sua missão:

processar uma solicitação de autorização.

Conceitualmente:

REQUEST
   │
   ▼
 CICS
   │
   ▼
AUTHORIZATION PROGRAM
   │
   ├── VALIDATE CARD
   ├── CHECK STATUS
   ├── CHECK LIMIT
   ├── CHECK RULES
   ├── CHECK RISK
   │
   ▼
APPROVE / DECLINE

Um pseudocódigo COBOL extremamente simplificado poderia parecer:

       PROCEDURE DIVISION.

           PERFORM VALIDATE-REQUEST
           PERFORM READ-CARD
           PERFORM CHECK-CARD-STATUS
           PERFORM CHECK-AVAILABLE-LIMIT
           PERFORM CHECK-RISK

           IF WS-AUTHORIZED
               PERFORM CREATE-AUTHORIZATION
               PERFORM RESERVE-LIMIT
               MOVE '00' TO WS-RESPONSE-CODE
           ELSE
               MOVE '05' TO WS-RESPONSE-CODE
           END-IF.

Não copie isso para instalar amanhã no banco. 😁

Estamos construindo um modelo didático.

O importante é compreender o fluxo.

💳 Capítulo 4 — O cartão existe?

Nossa primeira pergunta parece ridícula:

O cartão existe?

Mas sistemas robustos começam validando o básico.

Podemos possuir algo conceitualmente semelhante a:

CARD
---------------------------
CARD_ID
ACCOUNT_ID
CARD_TOKEN
STATUS
EXPIRATION_DATE
PRODUCT_CODE
BLOCK_CODE

O programa consulta:

SELECT STATUS,
       ACCOUNT_ID,
       EXPIRATION_DATE
FROM CARD
WHERE CARD_TOKEN = :WS-CARD-TOKEN

E descobre:

STATUS = ACTIVE

Ótimo.

Mas poderia encontrar:

BLOCKED
CANCELLED
EXPIRED
LOST
STOLEN

Nesse caso, dependendo das regras:

DECLINED

Observe algo importante para quem está aprendendo COBOL.

O programa não está simplesmente “fazendo contas”.

Ele está implementando regras de negócio.

Essa é uma das essências do COBOL empresarial.

🏦 Capítulo 5 — A conta e o limite

Encontramos a conta:

ACCOUNT_ID       = 100238
CREDIT_LIMIT     = 10000.00
AVAILABLE_LIMIT  = 5800.00
CURRENT_BALANCE  = 3400.00
PENDING_AUTH     = 800.00

A compra solicitada é:

100.00

Temos limite.

Mas cuidado.

Não deveríamos simplesmente fazer:

SUBTRACT 100 FROM AVAILABLE-LIMIT.

Por quê?

Porque provavelmente existem milhares de transações concorrentes.

Imagine duas compras quase simultâneas.

AVAILABLE LIMIT = R$ 500

COMPRA A = R$ 400
COMPRA B = R$ 400

Dois programas consultam:

R$ 500 disponível.

A conclui:

aprovado.

B conclui:

aprovado.

Parabéns.

Acabamos de autorizar R$ 800 usando R$ 500.

Bem-vindo ao maravilhoso universo da concorrência transacional.

🔒 Capítulo 6 — COMMIT e ROLLBACK não são frescura

Aqui começamos a compreender por que sistemas transacionais possuem mecanismos tão sofisticados.

Nossa operação poderia ser tratada como uma Unit of Work.

BEGIN UOW
    │
    ├── READ ACCOUNT
    │
    ├── CHECK LIMIT
    │
    ├── CREATE AUTHORIZATION
    │
    ├── RESERVE LIMIT
    │
    └── WRITE AUDIT
           │
           ▼
         COMMIT

Mas imagine:

CREATE AUTHORIZATION → OK
RESERVE LIMIT        → OK
WRITE SOMETHING      → ERROR

Não podemos deixar metade da operação concluída.

Precisamos de:

ROLLBACK

A ideia fundamental é:

Ou a unidade lógica de trabalho acontece de maneira consistente, ou voltamos ao estado apropriado.

Esse é um dos conceitos que um programador COBOL iniciante deveria tatuar mentalmente.

Em aplicações financeiras, inconsistência pode significar dinheiro.

🧠 Capítulo 7 — O limite existe, mas devemos autorizar?

Não necessariamente.

Imagine:

LIMITE DISPONÍVEL: R$ 20.000
COMPRA:            R$ 7.000

Matematicamente:

7000 < 20000

Então aprova?

Talvez.

Agora acrescente:

CLIENTE NORMALMENTE COMPRA: Brasil
HORÁRIO:                     03:17
VALOR MÉDIO:                 R$ 80
COMPRA ATUAL:                R$ 7.000
PAÍS:                        outro país
MERCHANT:                    desconhecido

🚨

Entra o Risk/Fraud Engine.

🚨 Capítulo 8 — O Sherlock Holmes das transações

O sistema antifraude pode observar dezenas ou centenas de sinais.

Por exemplo:

VALUE
TIME
COUNTRY
MERCHANT
MCC
DEVICE
TRANSACTION VELOCITY
HISTORICAL BEHAVIOR
AUTHENTICATION
PREVIOUS DECLINES
GEOGRAPHICAL PATTERNS

Imagine:

23:10 São Paulo
R$ 37,50

23:18 São Paulo
R$ 83,00

23:22 Tokyo
R$ 9.700

Não precisamos ser Hercule Poirot para levantar uma sobrancelha.

Nosso sistema poderia calcular:

RISK SCORE = 947

E possuir regras como:

000-300   LOW
301-700   MEDIUM
701-850   HIGH
851-1000  DECLINE/REVIEW

Atualmente esse ambiente pode combinar regras determinísticas, estatística, análise comportamental e machine learning.

Mas COBOL continua perfeitamente capaz de executar regras determinísticas essenciais.

IF WS-RISK-SCORE > 850
    MOVE 'N' TO WS-AUTHORIZED
END-IF.

Às vezes não precisamos de inteligência artificial.

Precisamos apenas de:

IF COISA-ABSURDA
   NÃO-FAÇA
END-IF

Uma tecnologia revolucionária conhecida desde tempos imemoriais como bom senso programado.

⚡ Capítulo 9 — Tudo isso precisa ser rápido

Esse é um requisito extraordinário.

O consumidor está esperando.

Ele não quer ver:

PROCESSANDO...

PROCESSANDO...

PROCESSANDO...

enquanto o sistema gera um relatório gerencial de 400 páginas.

Por isso workloads diferentes possuem prioridades diferentes.

Entra o WLM — Workload Manager.

Conceitualmente:

AUTHORIZATION     CRITICAL
PAYMENT           HIGH
CUSTOMER QUERY    HIGH
REPORTING         MEDIUM
ANALYTICS BATCH   LOWER

Quando existe competição por recursos, o sistema operacional precisa compreender que:

autorizar a compra do cliente é mais urgente do que imprimir o relatório do chefe.

Embora alguns chefes possam discordar.

📨 Capítulo 10 — MQ: nem todo mundo precisa esperar

Imagine que a compra foi aprovada.

Precisamos responder imediatamente.

Mas também queremos:

registrar eventos;
enviar notificação;
alimentar analytics;
avisar sistemas antifraude;
atualizar outros ambientes;
produzir informações para aplicações móveis.

Seria absurdo fazer o consumidor esperar tudo isso.

Então:

CICS AUTH
    │
    ├──────────────► RESPONSE
    │
    │
    └──────────────► MQ
                         │
               ┌─────────┼─────────┐
               ▼         ▼         ▼
             FRAUD    ANALYTICS   ALERT
                                   │
                                   ▼
                           "Compra aprovada"

Aqui aparece uma das grandes ideias de arquitetura:

separe o caminho crítico das tarefas que podem acontecer assincronamente.

IBM MQ encaixa-se maravilhosamente nesse tipo de integração.

🧾 Capítulo 11 — APPROVED não significa “acabou”

Esse é provavelmente um dos conceitos mais interessantes do sistema.

A compra foi autorizada:

AUTHORIZATION

VALUE  = 100.00
STATUS = PENDING

Mas autorização e lançamento financeiro definitivo são coisas diferentes.

Posteriormente chegam informações financeiras que precisam ser conciliadas com aquela autorização.

Simplificando:

AUTHORIZATION
      │
      ▼
PRESENTMENT
      │
      ▼
MATCHING
      │
      ▼
POSTING

Finalmente:

POSTED TRANSACTION

Por que essa separação?

Porque o mundo real é bagunçado.

🏨 Capítulo 12 — O hotel de R$ 1.000 que virou R$ 873,42

Você chega a um hotel.

Pode ocorrer uma autorização inicial:

R$ 1.000

Sua conta final acaba sendo:

R$ 873,42

Agora nosso sistema precisa compreender que existe relacionamento entre as operações.

Situações semelhantes aparecem em:

hotéis;
locadoras;
restaurantes;
postos;
cancelamentos;
ajustes;
estornos.

Portanto:

AUTHORIZATION ≠ FINAL TRANSACTION

Esse é um daqueles detalhes que parecem insignificantes até você precisar construir o sistema.

Então tornam-se gigantescos.

📦 Capítulo 13 — E das profundezas surge o BATCH

Durante o dia, imagine:

CICS
CICS
CICS
CICS
CICS
CICS
CICS

Transações chegando continuamente.

Em paralelo ou em determinados ciclos, precisamos executar processamento massivo.

Entra:

JES2 + JCL + COBOL Batch

Poderíamos possuir uma cadeia didática:

RECEIVE CLEARING
       │
       ▼
VALIDATE
       │
       ▼
MATCH AUTHORIZATION
       │
       ▼
POST TRANSACTION
       │
       ▼
UPDATE ACCOUNT
       │
       ▼
BILLING
       │
       ▼
SETTLEMENT
       │
       ▼
RECONCILIATION

Um JCL fictício:

//BELCARD JOB ...
//STEP010 EXEC PGM=BCLR001
//STEP020 EXEC PGM=BVAL001
//STEP030 EXEC PGM=BMAT001
//STEP040 EXEC PGM=BPOS001
//STEP050 EXEC PGM=BBIL001
//STEP060 EXEC PGM=BSET001

Cada programa possui responsabilidade específica.

Isso permite restart, controle, auditoria e operacionalização muito melhores do que construir um monstro chamado:

FAZTUDO.CBL

com 187 mil linhas.

Embora algum arqueólogo de sistemas provavelmente já tenha encontrado algo parecido.

🧮 Capítulo 14 — A fábrica de faturas

Chegamos ao billing.

Para cada conta precisamos considerar:

SALDO ANTERIOR
+
COMPRAS
+
PARCELAS
+
ENCARGOS
+
JUROS
-
PAGAMENTOS
-
CRÉDITOS
-
ESTORNOS
=
NOVO SALDO

Em COBOL:

COMPUTE WS-NEW-BALANCE =
        WS-PREVIOUS-BALANCE
      + WS-PURCHASES
      + WS-INSTALLMENTS
      + WS-FEES
      + WS-INTEREST
      - WS-PAYMENTS
      - WS-CREDITS.

E aqui COBOL está em casa.

Valores decimais, regras empresariais, processamento de registros e grandes volumes de dados são precisamente o tipo de problema para o qual COBOL nasceu.

🇧🇷 Capítulo 15 — A entidade brasileira chamada PARCELAMENTO

Agora compramos:

R$ 1.200 em 12x

Nosso sistema registra:

PURCHASE_ID = 9838172
TOTAL       = 1200.00
QTY         = 12

E teremos:

Parece simples.

Até alguém perguntar:

“E se houver estorno na parcela 7?”

Ou:

“E se for estorno parcial?”

Ou:

“E se o cliente contestar a compra?”

Ou:

“E se houver renegociação?”

Ou:

“E se existir juros?”

Ou:

“E se o comerciante fizer refund?”

É assim que programas pequenos envelhecem e viram programas COBOL de 30 mil linhas.

Não necessariamente porque os programadores antigos eram malucos.

Frequentemente porque 30 anos de realidade foram sendo incorporados ao código.

Essa é uma lição importantíssima para quem entra hoje no mainframe.

Código legado muitas vezes é também:

regra de negócio fossilizada.

Não apague antes de descobrir por que existe.

🔐 Capítulo 16 — RACF: não, estagiário, você não pode consultar todos os cartões

Nosso BELLACARD contém informações extremamente sensíveis.

Precisamos controlar:

WHO
CAN DO WHAT
TO WHICH RESOURCE
UNDER WHICH CONDITIONS

RACF pode participar do controle de acesso ao ambiente z/OS.

Podemos proteger datasets, transações, usuários, grupos e diversos recursos.

Conceitualmente:

USER VAGNER
    │
    ├── AUTH → READ/EXECUTE
    ├── BILL → READ
    └── ADMIN → NO ACCESS

O princípio essencial é:

LEAST PRIVILEGE.

Um programa deve possuir apenas os acessos necessários.

Um operador também.

Um desenvolvedor também.

E definitivamente ninguém deveria possuir acesso porque:

“Vai que um dia eu precise.”

🔑 Capítulo 17 — E as chaves criptográficas?

Agora entramos em território ainda mais sensível.

Cartões envolvem criptografia, autenticação, tokens, PINs e material criptográfico.

A regra de ouro é:

chaves críticas não devem virar variáveis COBOL espalhadas pela aplicação.

Algo como:

01 SUPER-SECRET-KEY PIC X(32)
   VALUE 'MINHACHAVE123...'.

é praticamente uma carta de demissão escrita em COBOL.

😂

Ambientes financeiros utilizam infraestrutura criptográfica especializada e HSMs — Hardware Security Modules — para determinadas operações e proteção de chaves.

A aplicação solicita uma operação criptográfica.

O segredo permanece protegido.

🕵️ Capítulo 18 — “Eu não fiz essa compra.”

Três meses depois o cliente telefona:

Eu nunca fiz essa compra.

O sistema precisa reconstruir o passado.

Queremos saber:

QUANDO?
QUAL CARTÃO?
QUAL MERCHANT?
QUAL VALOR?
QUAL CANAL?
QUAL RESPOSTA?
QUAL SISTEMA?
QUAL REGRA?
QUAL RESULTADO?

Logs e trilhas de auditoria tornam-se fundamentais.

No universo z/OS, SMF e informações produzidas pelos subsistemas ajudam a construir observabilidade e auditoria.

Nosso sistema deveria conseguir reconstruir algo como:

03:17:00.103 REQUEST RECEIVED
03:17:00.108 CARD VALIDATED
03:17:00.112 STATUS ACTIVE
03:17:00.119 LIMIT OK
03:17:00.127 RISK SCORE 214
03:17:00.133 AUTH CREATED
03:17:00.139 LIMIT RESERVED
03:17:00.145 COMMIT
03:17:00.151 APPROVED

E aí descobrimos outra característica dos sistemas financeiros:

não basta fazer certo. Precisamos conseguir demonstrar posteriormente o que aconteceu.

🏰 Capítulo 19 — E se o mainframe cair?

Imagine milhões de pessoas tentando pagar almoço e recebendo:

HOST UNAVAILABLE

O problema deixa rapidamente de ser “um incidente de TI”.

Vira problema comercial, financeiro e reputacional.

Daí entram conceitos de alta disponibilidade e arquiteturas como Parallel Sysplex.

Didaticamente:

                 REQUESTS
                     │
                     ▼
               WORKLOAD ROUTING
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
       z/OS A                 z/OS B
        CICS                   CICS
          │                     │
          └──────────┬──────────┘
                     ▼
                   Db2
               Data Sharing

Falhou um componente?

A arquitetura é desenhada para evitar que isso necessariamente signifique:

TODO MUNDO PARA.

É aqui que redundância, recuperação, data sharing, workload management, automação operacional e engenharia de resiliência deixam de ser palavras bonitas de PowerPoint.

🏙️ Capítulo 20 — As duas cidades do cartão

Eu gosto de imaginar o BELLACARD dividido em duas grandes cidades.

⚡ Cidade Online

Seu prefeito é o CICS.

Sua pergunta principal:

POSSO COMPRAR?

REQUEST
   │
   ▼
CICS
   │
   ▼
CARD
LIMIT
RISK
RULES
   │
   ▼
YES / NO

Velocidade, disponibilidade e consistência dominam essa cidade.

🏭 Cidade Financeira

Aqui vivem:

Db2 + COBOL Batch + JES2 + MQ + sistemas contábeis.

Sua pergunta é diferente:

O QUE ACONTECEU COM O DINHEIRO?

AUTHORIZATION
      ↓
TRANSACTION
      ↓
POSTING
      ↓
ACCOUNT
      ↓
STATEMENT
      ↓
PAYMENT
      ↓
ACCOUNTING
      ↓
RECONCILIATION

Aqui cada centavo precisa encontrar seu destino.

🧩 Capítulo 21 — Afinal, onde cada tecnologia entra?

Agora nosso iniciante consegue enxergar o tabuleiro inteiro.

COBOL
│
├── business rules
├── authorization
├── billing
├── posting
└── batch processing

CICS
│
├── online transactions
├── transaction management
└── units of work

Db2
│
├── accounts
├── cards
├── authorizations
├── transactions
└── statements

MQ
│
├── asynchronous messaging
├── events
├── integration
└── notifications

JCL/JES2
│
├── batch
├── billing
├── reconciliation
└── settlement processing

RACF
│
└── access control

CRYPTO/HSM
│
└── sensitive cryptographic operations

SMF/MONITORING
│
├── auditing
└── observability

WLM
│
└── workload priorities

PARALLEL SYSPLEX
│
└── availability/scalability

Percebe a diferença?

Agora COBOL, CICS, Db2, MQ e JCL deixaram de ser matérias isoladas de um curso.

Cada tecnologia apareceu porque tínhamos um problema para resolver.

É assim que eu gosto de ensinar mainframe.

🎓 Capítulo 22 — Construindo o BELLACARD como projeto educacional

Eu transformaria essa arquitetura numa trilha prática.

O aluno começa pequeno.

Nível 1 — COBOL

Criar:

CUSTOMER
CARD
ACCOUNT

Depois:

PURCHASE
PAYMENT
LIMIT

Finalmente:

STATEMENT

Nível 2 — Arquivos

Guardar clientes e contas.

Começar sequencialmente.

Depois introduzir VSAM.

Agora o aluno entende por que acesso indexado importa.

Nível 3 — Db2

Migramos para:

CUSTOMER
ACCOUNT
CARD
AUTHORIZATION
TRANSACTION
PAYMENT
STATEMENT

Aprendemos:

SELECT
INSERT
UPDATE
DELETE
COMMIT
ROLLBACK

Não como comandos aleatórios de SQL.

Mas porque nosso banco precisa deles.

Nível 4 — CICS

Criamos:

AUTH = Authorization
ACCT = Account Inquiry
PAYM = Payment
BLCK = Block Card

Agora nosso COBOL deixou de ser apenas batch.

Temos um pequeno sistema transacional.

Nível 5 — MQ

A compra aprovada produz:

CARD.PURCHASE.APPROVED

Outro consumidor recebe.

Depois outro.

Aprendemos arquitetura assíncrona.

Nível 6 — Batch

Criamos:

POSTING
BILLING
PAYMENT PROCESSING
STATEMENT GENERATION
RECONCILIATION

Finalmente o aluno entende por que empresas ainda executam workloads batch gigantescos.

Nível 7 — Segurança

Introduzimos:

RACF
AUDIT
CRYPTOGRAPHY
TOKENIZATION

Agora nosso brinquedo começa a parecer uma plataforma empresarial.

Nível 8 — Operação

Provocamos problemas.

DB2 TIMEOUT
MQ QUEUE FULL
CICS ABEND
JOB RC=12
DATASET FULL
AUTHORIZATION LATENCY

E perguntamos:

O que o suporte N2 faria?

Depois:

E o N3?

Agora nasceu uma pequena War Room BELLACARD.

🔥 Capítulo 23 — O exercício mais importante: quebrar o sistema

Eu faria questão de criar erros propositalmente.

Por exemplo:

AVAILABLE LIMIT = 500

Disparamos simultaneamente:

PURCHASE A = 400
PURCHASE B = 400

Se ambas forem aprovadas incorretamente, descobrimos uma falha de concorrência.

Outro teste:

INSERT AUTHORIZATION = SUCCESS
UPDATE LIMIT         = FAILURE

O sistema ficou inconsistente?

Se sim:

faltou tratar corretamente a unidade de trabalho.

Outro:

MQ unavailable

A autorização precisa parar?

Talvez não.

Essa pergunta ensina arquitetura melhor que vinte slides.

👻 Capítulo 24 — O fantasma das 03:17

Chegamos ao easter egg.

Todos os dias exatamente às:

03:17

o BELLACARD começa a apresentar:

AUTH RESPONSE TIME
120ms
180ms
350ms
900ms
2.1s

Nenhum erro.

CPU normal.

Db2 aparentemente normal.

MQ normal.

CICS sem ABEND.

Mas a latência explode durante sete minutos.

Nosso programador iniciante recebe seu primeiro chamado:

INCIDENT #0317

SEVERITY: HIGH
DESCRIPTION:
Intermittent authorization latency.

Começa a investigação.

RMF.

SMF.

CICS statistics.

Db2 accounting.

WLM.

JES2.

Até descobrir...

Um antigo job chamado:

//MONSTR17 JOB

executado diariamente às 03:17, realizando uma consulta monstruosa contra tabelas utilizadas pelo sistema online.

O programa foi criado em 1997.

O comentário no topo:

      * DO NOT REMOVE.
      * BUSINESS REQUIREMENT.
      * JSMITH - 1997-04-13

Ninguém sabe quem é JSMITH.

Ninguém sabe qual era o requisito.

Mas todos têm medo de remover.

🤣

Bem-vindo ao mainframe corporativo.

🧠 Curiosidade — O verdadeiro patrimônio não é apenas o código

Esse é talvez o conhecimento mais importante de todo o artigo.

Quando alguém encontra um programa COBOL com milhares de linhas, pode pensar:

“Que coisa velha.”

Mas aquele programa pode conter décadas de:

regras;
exceções;
regulamentações;
incidentes;
fraudes descobertas;
produtos descontinuados;
produtos ainda ativos;
acordos comerciais;
tratamentos especiais;
correções;
conhecimento empresarial.

É quase arqueologia.

Um comentário de 1997 pode explicar por que determinada operação de 2026 ainda funciona.

Por isso modernização responsável começa com:

compreender antes de substituir.

🏛️ Capítulo 25 — O mainframe como cidade invisível

Voltamos finalmente à cafeteria.

Você aproximou o cartão.

BIP!

Apareceu:

APROVADO

Você levou seu café.

Talvez nunca pense novamente naquela transação.

Mas atrás daquele pequeno momento poderia existir conceitualmente uma cidade inteira:

                   💳 CARD
                      │
                      ▼
                 POS / APP
                      │
                      ▼
                  ACQUIRER
                      │
                      ▼
               CARD NETWORK
                      │
                      ▼
╔══════════════════════════════════════╗
║               IBM Z                  ║
║                                      ║
║              CICS                    ║
║                │                     ║
║       ┌────────┼────────┐            ║
║       ▼        ▼        ▼            ║
║     CARD     LIMIT     RISK          ║
║       │        │        │            ║
║       └────────┼────────┘            ║
║                ▼                     ║
║               Db2                    ║
║                │                     ║
║               MQ                     ║
║                                      ║
║   COBOL • JCL • JES2 • RACF • SMF   ║
║        WLM • CRYPTO • SYSPLEX        ║
╚══════════════════════════════════════╝
                      │
                      ▼
                   APPROVED

O consumidor viu:

APROVADO.

O mainframer vê:

arquitetura.

☕ Conclusão — o BIP que esconde uma catedral

Talvez essa seja uma das melhores maneiras de explicar mainframe para alguém que está começando.

Não comece dizendo:

“COBOL possui DIVISION, SECTION e PARAGRAPH.”

Comece dizendo:

“Você acabou de passar um cartão. Quer descobrir o que pode existir atrás daquele BIP?”

Então COBOL ganha propósito.

CICS ganha propósito.

Db2 ganha propósito.

MQ ganha propósito.

JCL ganha propósito.

RACF ganha propósito.

SMF ganha propósito.

WLM ganha propósito.

Parallel Sysplex ganha propósito.

O iniciante deixa de decorar siglas e começa a compreender problemas.

E tecnologia empresarial é exatamente isso:

uma coleção de soluções para problemas que ficaram grandes demais para serem resolvidos de qualquer jeito.

Da próxima vez que aproximar seu cartão e ouvir:

BIP!

talvez você enxergue algo diferente.

Não apenas uma compra.

Mas uma mensagem atravessando redes, chegando a sistemas que verificam identidade, estado, crédito e risco; uma unidade de trabalho sendo protegida; registros sendo preservados; eventos sendo produzidos; sistemas financeiros preparando o que acontecerá depois.

Tudo isso para devolver uma pequena palavra:

       ┌────────────────────────┐
       │                        │
       │       APPROVED         │
       │                        │
       │         RC=00          │
       │                        │
       └────────────────────────┘

E talvez exista, em algum canto de algum sistema que ninguém ousa desligar, um programa COBOL escrito décadas atrás, trabalhando silenciosamente para que seu café seja pago.

Sem aplausos.

Sem interface bonita.

Sem ninguém perceber.

Como tantas outras coisas no mainframe.

Porque a melhor infraestrutura é aquela que desaparece atrás do serviço que presta.

E enquanto o mundo vê apenas o BIP, nós sabemos que atrás dele pode existir uma verdadeira catedral transacional construída byte por byte, regra por regra e geração por geração de programadores.

☕ Um Café no Bellacosa Mainframe

Onde até uma compra de R$ 17,50 pode acabar em CICS, Db2, COBOL e uma War Room às 03:17.

☕ Um Café no Bellacosa Mainframe

🕵️ The Mentalist no Mainframe — O Caso dos R$ 100 que Atravessaram um Sistema de Cartões

Entenda como uma compra de R$ 100 atravessa POS, adquirente, bandeira, emissor, autorização, plafond, clearing, settlement, cobrança, contabilidade e reconciliação em um ambiente bancário e mainframe.

💳 Como funciona uma transação de cartão de crédito?

Uma compra aparentemente simples percorre diversos participantes e sistemas. O cliente apresenta o cartão ao estabelecimento, a maquininha envia a transação ao adquirente, a rede encaminha a solicitação ao emissor e o banco verifica cartão, conta, produto, plafond, regras e risco antes de autorizar ou recusar.

Depois da autorização, a transação ainda pode passar por reversal, clearing, settlement, faturamento, cobrança, contabilização, reconciliação, disputa e chargeback.

Principais assuntos: IBM Mainframe, IBM Z, COBOL, CICS, Db2, cartões de crédito, POS, adquirente, emissor, autorização, plafond, clearing, settlement, tarifas, cobrança, contabilidade e reconciliação.

🔎 Ler o artigo original: The Mentalist no Mainframe

The Mentalist no Mainframe

Artigo sobre processamento de cartões de crédito em ambientes bancários e IBM Mainframe, incluindo POS, adquirente, emissor, autorização, plafond, clearing, settlement, cobrança, contabilidade e reconciliação.

Ler o artigo completo no Bellacosa Mainframe

Translate

segunda-feira, 14 de setembro de 2026