 |
| 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,50Você 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ÃOO 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
│
▼
ISSUERVisa 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 : 031700Sim.
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:
AUTHSua 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 / DECLINEUm 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_CODEO programa consulta:
SELECT STATUS,
ACCOUNT_ID,
EXPIRATION_DATE
FROM CARD
WHERE CARD_TOKEN = :WS-CARD-TOKENE descobre:
STATUS = ACTIVEÓtimo.
Mas poderia encontrar:
BLOCKED
CANCELLED
EXPIRED
LOST
STOLENNesse caso, dependendo das regras:
DECLINEDObserve 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.00A compra solicitada é:
100.00Temos 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$ 400Dois 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
│
▼
COMMITMas imagine:
CREATE AUTHORIZATION → OK
RESERVE LIMIT → OK
WRITE SOMETHING → ERRORNão podemos deixar metade da operação concluída.
Precisamos de:
ROLLBACKA 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.000Matematicamente:
7000 < 20000Entã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 PATTERNSImagine:
23:10 São Paulo
R$ 37,50
23:18 São Paulo
R$ 83,00
23:22 Tokyo
R$ 9.700Não precisamos ser Hercule Poirot para levantar uma sobrancelha.
Nosso sistema poderia calcular:
RISK SCORE = 947E possuir regras como:
000-300 LOW
301-700 MEDIUM
701-850 HIGH
851-1000 DECLINE/REVIEWAtualmente 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-IFUma 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 LOWERQuando 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 = PENDINGMas 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
│
▼
POSTINGFinalmente:
POSTED TRANSACTIONPor 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.000Sua conta final acaba sendo:
R$ 873,42Agora 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 TRANSACTIONEsse é 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
CICSTransaçõ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
│
▼
RECONCILIATIONUm 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=BSET001Cada programa possui responsabilidade específica.
Isso permite restart, controle, auditoria e operacionalização muito melhores do que construir um monstro chamado:
FAZTUDO.CBLcom 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 SALDOEm 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 12xNosso sistema registra:
PURCHASE_ID = 9838172
TOTAL = 1200.00
QTY = 12E teremos:
01/12 100
02/12 100
03/12 100
...
12/12 100Parece 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 CONDITIONSRACF 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 ACCESSO 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 APPROVEDE 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 UNAVAILABLEO 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 SharingFalhou 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 / NOVelocidade, 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
↓
RECONCILIATIONAqui 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/scalabilityPercebe 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
ACCOUNTDepois:
PURCHASE
PAYMENT
LIMITFinalmente:
STATEMENTNí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
STATEMENTAprendemos:
SELECT
INSERT
UPDATE
DELETE
COMMIT
ROLLBACKNã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 CardAgora nosso COBOL deixou de ser apenas batch.
Temos um pequeno sistema transacional.
Nível 5 — MQ
A compra aprovada produz:
CARD.PURCHASE.APPROVEDOutro consumidor recebe.
Depois outro.
Aprendemos arquitetura assíncrona.
Nível 6 — Batch
Criamos:
POSTING
BILLING
PAYMENT PROCESSING
STATEMENT GENERATION
RECONCILIATIONFinalmente o aluno entende por que empresas ainda executam workloads batch gigantescos.
Nível 7 — Segurança
Introduzimos:
RACF
AUDIT
CRYPTOGRAPHY
TOKENIZATIONAgora 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 LATENCYE 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 = 500Disparamos simultaneamente:
PURCHASE A = 400
PURCHASE B = 400Se ambas forem aprovadas incorretamente, descobrimos uma falha de concorrência.
Outro teste:
INSERT AUTHORIZATION = SUCCESS
UPDATE LIMIT = FAILUREO sistema ficou inconsistente?
Se sim:
faltou tratar corretamente a unidade de trabalho.
Outro:
MQ unavailableA 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:17o BELLACARD começa a apresentar:
AUTH RESPONSE TIME
120ms
180ms
350ms
900ms
2.1sNenhum 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 JOBexecutado 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-13Ningué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:
APROVADOVocê 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 ║
╚══════════════════════════════════════╝
│
▼
APPROVEDO 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.
