 |
| Bellacosa Mainframe do celular ao mainframe como funciona o mainframe após o login no app do mobile |
☕ Um Café no Bellacosa Mainframe
Do Celular ao Mainframe: A Jornada Secreta de uma Transação Bancária
O guia do Programador COBOL Padawan para compreender APIs, segurança, mensageria, CICS, Db2 e a ponte invisível entre o aplicativo moderno e o coração do IBM Z
Imagine a seguinte cena.
Você está sentado em uma cafeteria, talvez esperando o início de uma aula sobre COBOL, quando o garçom coloca sobre a mesa uma xícara de café fumegante e a conta. Você abre o aplicativo do banco, aponta a câmera para um QR Code, confirma o valor, informa a senha e toca no botão:
Pagar
Alguns segundos depois, aparece a mensagem:
Transação realizada com sucesso.
Missão cumprida.
O café foi pago, o comerciante recebeu o dinheiro e você provavelmente não pensará mais no assunto.
Mas, para nós, tripulantes curiosos da Frota Estelar do Mainframe, essa pequena operação levanta uma pergunta fascinante:
O que realmente aconteceu entre o toque na tela e a mensagem de sucesso?
A resposta é muito mais interessante do que parece.
O seu pedido atravessou a internet, passou por muralhas digitais, apresentou credenciais, foi analisado por mecanismos de segurança, atravessou gateways, talvez entrou em uma fila de mensagens, foi traduzido de JSON para uma estrutura COBOL, chegou ao z/OS, encontrou uma transação CICS, executou regras de negócio, consultou o Db2, atualizou registros, gerou logs, acionou sistemas antifraude e retornou pelo mesmo caminho.
Tudo isso em poucos segundos — frequentemente em frações de segundo.
O que parece um simples toque na tela é, na verdade, uma missão espacial completa.
Prepare o café, ajuste o comunicador e ocupe sua estação na ponte. Hoje vamos viajar do celular ao mainframe.
1. O aplicativo é apenas a janela da nave
Para o usuário, o aplicativo parece ser o banco inteiro.
Ele mostra saldo, extrato, investimentos, cartões, empréstimos e pagamentos. Entretanto, o aplicativo normalmente não mantém o saldo verdadeiro da conta nem executa sozinho as regras financeiras mais importantes.
Ele é, antes de tudo, uma camada de apresentação.
Sua função é permitir que o usuário:
veja informações;
informe dados;
confirme operações;
receba mensagens;
interaja com os serviços do banco.
Podemos comparar o aplicativo ao painel da ponte da USS Enterprise.
Quando o capitão toca em um comando, o painel não produz energia, não move os motores de dobra e não calcula sozinho a rota. Ele apenas envia instruções para sistemas muito mais profundos da nave.
Da mesma maneira, quando você toca em “Consultar saldo”, o aplicativo envia uma solicitação para os sistemas centrais.
Um pedido poderia ser representado assim:
{
"agencia": "1234",
"conta": "567890",
"operacao": "CONSULTAR_SALDO"
}
Esse formato é chamado de JSON, abreviação de JavaScript Object Notation.
Ele se tornou muito popular porque é:
legível;
leve;
fácil de transmitir;
compatível com praticamente qualquer linguagem;
adequado para APIs modernas.
Para um desenvolvedor mobile, JSON é algo natural.
Para um programa COBOL criado há décadas, porém, a realidade pode ser bastante diferente.
2. Antes de viajar, a mensagem entra em um túnel criptografado
A solicitação não deveria viajar pela internet como texto aberto.
Seria desastroso transmitir algo assim:
CONTA=567890
SENHA=123456
VALOR=5000
Qualquer pessoa capaz de interceptar o tráfego poderia ler os dados.
Por isso, aplicativos bancários utilizam conexões protegidas por HTTPS, geralmente com TLS — Transport Layer Security.
O TLS cria um canal criptografado entre o dispositivo e o servidor.
Antes de transmitir os dados principais, cliente e servidor realizam um processo de negociação. Simplificando bastante, eles verificam certificados, escolhem algoritmos criptográficos e estabelecem chaves para proteger a sessão.
Depois disso, quem interceptar os pacotes não verá diretamente os dados da transação. Verá conteúdo criptografado, sem significado imediato.
É como se a mensagem fosse colocada em uma cápsula de transporte protegida por um campo de força.
O TLS oferece três garantias fundamentais:
Confidencialidade: terceiros não devem conseguir ler a mensagem.
Integridade: alterações durante o caminho devem ser detectadas.
Autenticidade: o aplicativo precisa ter confiança de que está falando com o servidor legítimo.
Aqui temos uma primeira lição para o COBOL Padawan:
Segurança não começa quando a solicitação chega ao mainframe. Ela começa antes mesmo de o primeiro pacote deixar o celular.
3. A internet não é uma linha reta
Quando o usuário toca em “Confirmar”, os dados não saltam diretamente para o mainframe.
Eles podem atravessar:
a rede Wi-Fi ou móvel;
a operadora de telecomunicações;
roteadores;
provedores;
redes de distribuição;
balanceadores;
zonas de segurança;
Data Centers;
ambientes de nuvem;
redes internas corporativas.
Cada salto acrescenta possibilidades de atraso, falha ou ataque.
É por isso que arquiteturas financeiras são construídas com redundância.
Se um caminho falhar, outro poderá ser utilizado. Se um servidor parar, outro assumirá. Se uma região inteira ficar indisponível, mecanismos de recuperação podem direcionar o tráfego para outro ambiente.
Para o usuário, tudo isso é invisível.
Ele vê apenas uma animação girando na tela.
4. WAF: a muralha da fortaleza
Ao se aproximar da infraestrutura do banco, a requisição pode encontrar um WAF — Web Application Firewall.
O WAF funciona como uma muralha especializada na proteção de aplicações web e APIs.
Um firewall tradicional costuma observar endereços, portas e protocolos. O WAF procura compreender também o conteúdo da requisição.
Ele pode identificar padrões relacionados a:
SQL Injection;
Cross-Site Scripting;
automações maliciosas;
exploração de vulnerabilidades;
requisições deformadas;
bots;
tentativas de manipulação de parâmetros;
tráfego anormal.
Considere uma entrada esperada:
conta=12345
Agora imagine que um invasor tente enviar:
conta=' OR 1=1 --
Esse tipo de sequência pode estar associado a uma tentativa de SQL Injection.
Em uma aplicação mal construída, o conteúdo poderia ser incorporado indevidamente a um comando SQL. Um WAF pode reconhecer esse padrão e bloquear a requisição antes que ela chegue às camadas internas.
Mas atenção: o WAF não elimina a necessidade de programação segura.
Ele é uma defesa adicional, não uma desculpa para escrever código vulnerável.
No universo da Frota Estelar, poderíamos dizer:
O campo de força protege a nave, mas isso não significa que a tripulação possa deixar todas as portas internas abertas.
5. API Gateway: a central de controle de tráfego
Depois da fronteira de segurança, a solicitação pode chegar a um API Gateway.
O API Gateway funciona como uma recepção altamente inteligente para as APIs.
Ele pode executar tarefas como:
validar tokens;
autenticar clientes;
aplicar limites de requisições;
registrar chamadas;
escolher o serviço de destino;
controlar versões de APIs;
transformar cabeçalhos;
aplicar políticas;
distribuir carga;
rejeitar tráfego inválido.
Imagine que o banco possua APIs diferentes:
/api/saldo
/api/pix
/api/cartoes
/api/investimentos
/api/emprestimos
O Gateway examina a requisição e a envia ao serviço correto.
Ele também pode evitar abuso por meio de rate limiting.
Por exemplo, se um dispositivo tentar realizar dez mil consultas em poucos segundos, o Gateway poderá limitar ou bloquear o tráfego.
Outra função importante é a validação de credenciais.
Muitos sistemas usam padrões como:
OAuth 2.0;
OpenID Connect;
tokens JWT;
certificados digitais;
chaves de API.
O Gateway não substitui todos os controles posteriores, mas atua como um dos primeiros pontos de decisão.
Podemos compará-lo à estação de transporte da Enterprise.
Nem todo mundo pode informar:
“Energize!”
Antes, é necessário confirmar identidade, destino e autorização.
6. O celular fala JSON; o COBOL fala estruturas
Aqui começamos a chegar a uma das partes mais fascinantes da viagem.
O aplicativo moderno costuma enviar dados em JSON:
{
"cliente": 98765,
"valor": 250.75,
"moeda": "BRL"
}
Um programa COBOL pode esperar uma estrutura definida assim:
01 WS-REQUISICAO.
05 WS-CLIENTE PIC 9(05).
05 WS-VALOR PIC S9(07)V99 COMP-3.
05 WS-MOEDA PIC X(03).
Perceba a diferença.
No JSON, os campos têm nomes, separadores e valores textuais.
No COBOL, a estrutura possui posições, tamanhos e formatos definidos.
O campo WS-CLIENTE ocupa cinco dígitos.
O campo WS-VALOR pode estar armazenado em formato decimal compactado, indicado por COMP-3.
O campo WS-MOEDA possui três caracteres.
Essas definições frequentemente ficam em um Copybook.
Um Copybook é um arquivo reutilizável que contém descrições de dados ou trechos de código.
Exemplo:
COPY REQPIX.
O compilador inclui o conteúdo do Copybook no programa.
Em ambientes corporativos, Copybooks podem representar:
solicitações;
respostas;
registros de clientes;
layouts de arquivos;
áreas de comunicação;
mensagens;
estruturas de banco.
Essa precisão é uma das grandes forças do COBOL.
Cada campo possui tamanho e significado claramente definidos.
Por outro lado, ela cria um desafio de integração: alguém precisa traduzir os dados flexíveis do mundo JSON para o layout rigoroso do mundo COBOL.
7. z/OS Connect: o tradutor da Federação
Uma das tecnologias capazes de construir essa ponte é o z/OS Connect.
Ele permite expor ativos do IBM Z por meio de APIs e integrar APIs com aplicações existentes.
De maneira simplificada, o fluxo pode ser:
Aplicativo
↓
API REST
↓
JSON
↓
z/OS Connect
↓
Estrutura COBOL
↓
CICS
↓
Programa de negócio
Na volta:
Programa COBOL
↓
Estrutura de resposta
↓
z/OS Connect
↓
JSON
↓
Aplicativo
O desenvolvedor do aplicativo não precisa saber como um campo COMP-3 é representado internamente.
O programador COBOL não precisa transformar manualmente toda requisição HTTP.
Cada lado trabalha com abstrações adequadas ao seu universo.
Esse é um ponto fundamental da modernização:
Modernizar não significa necessariamente reescrever tudo. Muitas vezes significa tornar um ativo existente acessível por novas interfaces.
Um programa COBOL que processa contas há décadas pode continuar executando sua lógica, enquanto uma API moderna fornece acesso controlado a essa capacidade.
Não é preciso desmontar o núcleo de dobra para instalar uma tela nova na ponte.
8. EBCDIC, UTF-8 e a Torre de Babel digital
Outro detalhe importante é a codificação de caracteres.
Aplicações modernas normalmente utilizam UTF-8.
Muitos ambientes mainframe utilizam EBCDIC em diversas áreas.
Uma letra não é armazenada simplesmente como “uma letra”. Ela é representada por um valor numérico.
Em codificações diferentes, o mesmo valor pode representar caracteres diferentes.
Portanto, a integração precisa tratar corretamente:
letras;
números;
caracteres especiais;
acentos;
símbolos;
espaços;
sinais;
quebras de linha.
Imagine enviar o nome:
João Gonçalves
Uma conversão incorreta poderia produzir caracteres ilegíveis.
Parece um detalhe pequeno, mas erros de codificação podem causar:
campos corrompidos;
falhas de validação;
rejeição de mensagens;
problemas em arquivos;
divergência entre sistemas;
erros difíceis de reproduzir.
Dica Bellacosa:
Quando uma integração produz “hieróglifos alienígenas”, investigue encoding antes de acusar os Klingons.
9. Comunicação síncrona: esperar pela resposta
Nem toda operação segue o mesmo estilo de comunicação.
Na comunicação síncrona, o cliente envia uma solicitação e espera a resposta.
Exemplo:
Aplicativo → Consultar saldo → Sistema
Aplicativo ← Saldo atual ← Sistema
O usuário está aguardando.
Por isso, o tempo de resposta é importante.
Uma consulta de saldo que demora trinta segundos causa péssima experiência, mesmo que tecnicamente seja concluída.
No fluxo síncrono, uma falha em qualquer ponto pode ser percebida imediatamente pelo usuário:
timeout;
serviço indisponível;
erro de autenticação;
falha interna;
resposta inválida.
Arquiteturas síncronas são simples de compreender, mas podem criar dependência direta entre os participantes.
Se o sistema de destino não responder, o chamador também ficará esperando.
É aqui que a mensageria oferece outra abordagem.
10. IBM MQ: o correio confiável da galáxia
O IBM MQ permite que aplicações troquem mensagens por meio de filas.
Em vez de exigir que origem e destino estejam disponíveis exatamente no mesmo instante, a aplicação coloca uma mensagem em uma fila.
Exemplo:
Aplicação A
↓ PUT
Fila MQ
↓ GET
Aplicação B
Se a Aplicação B estiver temporariamente indisponível, a mensagem poderá permanecer na fila até que o processamento seja retomado.
Isso é chamado de desacoplamento.
A origem não precisa conhecer todos os detalhes internos do consumidor.
Ela precisa saber em qual fila colocar a mensagem e qual contrato respeitar.
Em ambientes financeiros, essa confiabilidade é extremamente valiosa.
Imagine uma ordem de pagamento.
Perder a mensagem seria inaceitável.
Processá-la duas vezes também seria perigoso.
O MQ fornece recursos como:
persistência;
confirmação;
unidades de trabalho;
filas;
canais;
recuperação;
segurança;
entrega controlada.
Entretanto, aqui cabe uma correção importante a uma simplificação muito comum.
Dizer que qualquer sistema de mensageria “garante automaticamente exatamente uma vez” pode ser enganoso.
Na prática, a semântica de entrega depende da configuração, da transação, do desenho da aplicação e do tratamento de erros.
Uma aplicação robusta deve estar preparada para lidar com reprocessamentos.
Por isso existe um conceito essencial chamado idempotência.
Uma operação idempotente pode ser repetida sem produzir efeitos indevidos.
Por exemplo, uma transação pode ter um identificador único:
ID-TRANSACAO = PIX-20240718-0000123456
Antes de processar, o sistema verifica se aquele identificador já foi concluído.
Se já foi, não debita novamente.
Isso ajuda a prevenir duplicidades.
O MQ transporta mensagens com grande confiabilidade, mas a regra de negócio também precisa participar da proteção.
11. Kafka: o diário de bordo dos eventos
Kafka e MQ podem coexistir, mas não são exatamente a mesma coisa.
O Kafka é muito utilizado como plataforma de eventos e streaming.
Uma transação aprovada pode gerar um evento:
{
"evento": "PIX_REALIZADO",
"contaOrigem": "12345",
"valor": 250.75,
"timestamp": "2024-07-18T18:30:00"
}
Diversos consumidores podem ler esse evento:
motor antifraude;
sistema de notificações;
plataforma analítica;
Data Lake;
auditoria;
monitoramento;
campanhas;
modelos de inteligência artificial.
Em vez de um sistema ligar diretamente para todos os outros, ele publica o evento.
Cada consumidor reage conforme sua responsabilidade.
É como o diário de bordo da nave.
Um acontecimento é registrado, e diferentes departamentos usam a informação:
segurança analisa riscos;
engenharia mede impacto;
comando acompanha a missão;
ciência estuda padrões.
O Kafka é especialmente útil quando muitos consumidores precisam observar o mesmo fluxo de eventos.
12. Finalmente, o IBM Z
Depois de atravessar camadas externas, a solicitação pode chegar ao ambiente IBM Z.
Aqui é importante desfazer um mito:
Mainframe não significa um computador antigo isolado em uma sala escura.
O IBM Z moderno participa de arquiteturas híbridas, APIs, nuvem, inteligência artificial, containers, DevOps e automação.
Sua grande especialidade continua sendo processar cargas críticas com:
alta disponibilidade;
segurança;
escalabilidade;
consistência;
grande volume de transações;
capacidade de recuperação;
isolamento de workloads.
O mainframe não está escondido no passado.
Ele está silenciosamente sustentando o presente.
13. z/OS: o comandante da nave
O z/OS é o sistema operacional que coordena o ambiente.
Ele gerencia recursos como:
memória;
processadores;
dispositivos;
arquivos;
usuários;
segurança;
tarefas;
subsistemas;
workloads;
comunicação.
Dentro do z/OS podem coexistir diversos componentes:
CICS;
Db2;
IMS;
MQ;
JES2;
RACF;
Unix System Services;
ferramentas de monitoramento;
produtos de terceiros.
Para o iniciante, isso pode parecer intimidador.
Mas pense na Enterprise.
A nave possui engenharia, comando, segurança, comunicações, ciência e medicina. Cada departamento executa uma função específica, mas todos fazem parte da mesma missão.
O z/OS coordena essa tripulação tecnológica.
14. RACF: quem é você e o que pode fazer?
O RACF é um dos sistemas de segurança associados ao ambiente z/OS.
Ele pode participar de decisões como:
identificação do usuário;
autenticação;
acesso a recursos;
associação a grupos;
proteção de datasets;
proteção de transações;
controle de comandos;
auditoria.
É importante separar dois conceitos:
Autenticação: confirmar quem você é.
Autorização: determinar o que você pode fazer.
Um usuário pode estar corretamente autenticado e ainda assim não possuir autorização para consultar determinado recurso.
No cenário bancário, a autorização não se limita ao usuário humano.
Também pode envolver:
identidade da aplicação;
certificado;
região CICS;
conexão;
transação;
serviço;
perfil de segurança.
Esse modelo de camadas reduz a chance de um único erro liberar acesso irrestrito.
Na Frota Estelar, não basta possuir um uniforme. Para acessar o núcleo de dobra, é necessária autorização específica.
15. WLM: nem todas as missões têm a mesma prioridade
O Workload Manager, ou WLM, ajuda o z/OS a administrar recursos conforme objetivos de serviço.
Em momentos de grande carga, diferentes tipos de trabalho competem por CPU, memória, canais e outros recursos.
O sistema precisa decidir quais atividades devem receber prioridade.
Uma possível classificação seria:
pagamentos em tempo real;
consultas de clientes;
processamento de cartões;
relatórios internos;
tarefas batch;
testes;
rotinas de menor urgência.
O WLM trabalha com políticas e metas.
O objetivo não é simplesmente “dar tudo para o programa mais importante”, mas equilibrar o ambiente para atender níveis de serviço.
Essa inteligência é uma das razões pelas quais ambientes mainframe conseguem manter cargas críticas mesmo sob pressão intensa.
Imagine um alerta vermelho na Enterprise.
O sistema de suporte à vida terá prioridade sobre a impressora do bar do Ten Forward.
Da mesma forma, uma transação financeira urgente pode receber mais atenção que um relatório administrativo não crítico.
16. CICS: a torre de controle das transações
O CICS é um monitor de processamento de transações.
Ele foi projetado para executar grande quantidade de transações curtas, concorrentes e controladas.
Uma transação CICS pode:
receber dados;
identificar o programa;
executar lógica;
acessar Db2;
ler ou atualizar VSAM;
enviar mensagens MQ;
conversar com outros serviços;
confirmar ou desfazer alterações;
retornar uma resposta.
O CICS administra aspectos que, em uma aplicação isolada, seriam difíceis de implementar com a mesma robustez.
Podemos imaginá-lo como uma torre de controle.
Milhares de “naves” chegam e partem.
A torre precisa:
saber quem está chegando;
escolher a pista;
evitar colisões;
controlar recursos;
reagir a falhas;
manter o tráfego fluindo.
Uma transação CICS pode ter um identificador de quatro caracteres, por exemplo:
CSLD
Esse identificador pode estar associado a um programa:
PGMSALDO
Ao receber a transação, o CICS chama o programa correspondente.
17. COMMAREA, Channels e Containers
O programa precisa receber os dados da solicitação.
Historicamente, muitas aplicações CICS utilizam a COMMAREA.
Exemplo:
LINKAGE SECTION.
01 DFHCOMMAREA.
05 CA-CONTA PIC X(10).
05 CA-OPERACAO PIC X(02).
05 CA-VALOR PIC S9(09)V99 COMP-3.
05 CA-STATUS PIC X(02).
O programa acessa os dados recebidos por essa área.
A COMMAREA possui limitações de tamanho e exige atenção rigorosa ao layout.
Outra abordagem é utilizar Channels e Containers.
Um Channel pode conter múltiplos Containers. Isso permite organizar dados de maneira mais flexível.
Por exemplo:
CHANNEL: CH-PAGAMENTO
CONTAINER: CT-CABECALHO
CONTAINER: CT-CLIENTE
CONTAINER: CT-TRANSACAO
CONTAINER: CT-RESPOSTA
Para integrações modernas e estruturas maiores, Channels e Containers podem oferecer vantagens importantes.
Mas a COMMAREA continua sendo parte essencial da história e da realidade de muitas aplicações.
18. O programa COBOL entra em cena
Agora chegamos ao coração da regra de negócio.
O programa COBOL poderá:
validar os dados recebidos;
confirmar o tipo de operação;
consultar informações;
verificar limites;
calcular valores;
atualizar bancos ou arquivos;
gerar respostas;
tratar erros.
Um fluxo simplificado poderia ser:
PROCEDURE DIVISION USING DFHCOMMAREA.
PERFORM VALIDAR-REQUISICAO
IF CA-STATUS = '00'
PERFORM CONSULTAR-CONTA
END-IF
IF CA-STATUS = '00'
PERFORM PROCESSAR-OPERACAO
END-IF
PERFORM MONTAR-RESPOSTA
EXEC CICS RETURN END-EXEC.
O código real será mais complexo, mas essa estrutura revela uma característica poderosa do COBOL: a lógica pode ser organizada para se aproximar da linguagem do negócio.
VALIDAR-CLIENTE.
VERIFICAR-SALDO.
CALCULAR-LIMITE.
REGISTRAR-PAGAMENTO.
MONTAR-RESPOSTA.
Para um iniciante, isso é valioso.
COBOL foi criado para permitir que programas de negócio fossem compreendidos com maior clareza.
19. Db2: onde os dados ganham consistência
O programa pode acessar o Db2 for z/OS.
Uma consulta simplificada seria:
EXEC SQL
SELECT SALDO_ATUAL
INTO :WS-SALDO
FROM CONTAS
WHERE AGENCIA = :WS-AGENCIA
AND CONTA = :WS-CONTA
END-EXEC.
Depois do comando SQL, o programa deve verificar o resultado.
EVALUATE SQLCODE
WHEN 0
MOVE '00' TO WS-STATUS
WHEN 100
MOVE '01' TO WS-STATUS
WHEN OTHER
MOVE '99' TO WS-STATUS
END-EVALUATE.
O SQLCODE informa o resultado da operação.
Alguns exemplos gerais:
0 Sucesso
+100 Nenhuma linha encontrada
Negativo Erro
Ignorar o SQLCODE é uma das maneiras mais rápidas de transformar uma missão simples em um episódio de desastre espacial.
Dica Bellacosa:
Depois de cada comando SQL, verifique o retorno. O silêncio do programa não significa sucesso; às vezes significa que o problema ainda não encontrou você.
20. ACID: as leis da física transacional
Uma operação financeira precisa manter consistência.
Considere uma transferência:
debitar a conta A;
creditar a conta B;
registrar o histórico;
gerar auditoria.
O sistema não pode debitar A e falhar antes de creditar B.
Essas operações devem fazer parte de uma unidade lógica.
As propriedades ACID ajudam a explicar o comportamento esperado.
Atomicidade
Ou tudo acontece, ou nada acontece.
Consistência
A transação leva o banco de um estado válido para outro estado válido.
Isolamento
Transações concorrentes não devem interferir de maneira incorreta umas nas outras.
Durabilidade
Após a confirmação, o resultado precisa sobreviver a falhas.
No CICS e no Db2, os conceitos de commit e rollback são fundamentais.
Quando tudo ocorre corretamente:
COMMIT
Quando algo falha:
ROLLBACK
O rollback desfaz alterações ainda não confirmadas dentro da unidade de trabalho.
É como uma viagem temporal controlada.
A missão deu errado? O sistema retorna ao último ponto consistente.
Infelizmente, sem a participação de Q.
21. O caminho de volta
Depois que o programa COBOL conclui a operação, ele monta uma resposta.
Exemplo:
01 WS-RESPOSTA.
05 WS-CODIGO PIC X(02).
05 WS-MENSAGEM PIC X(60).
05 WS-SALDO PIC S9(09)V99 COMP-3.
Essa estrutura retorna ao CICS.
Depois poderá passar por uma camada de integração, que a converte para JSON:
{
"codigo": "00",
"mensagem": "Transacao realizada com sucesso",
"saldo": 1750.25
}
A resposta percorre novamente:
COBOL
↓
CICS
↓
z/OS Connect ou serviço de integração
↓
API Gateway
↓
Internet protegida por TLS
↓
Aplicativo
Então aparece a mensagem na tela.
O usuário vê apenas:
Sucesso.
Nós vemos toda uma arquitetura trabalhando em conjunto.
22. O que acontece nos bastidores e quase ninguém vê
A imagem principal normalmente mostra os componentes mais conhecidos, mas uma arquitetura real pode envolver muito mais.
Balanceamento de carga
Distribui as requisições entre diversas instâncias.
Cache
Evita consultas repetitivas quando os dados permitem armazenamento temporário.
HSM
Protege chaves criptográficas em hardware especializado.
Antifraude
Analisa comportamento, dispositivo, localização, valor, horário e histórico.
Observabilidade
Registra métricas, logs e traces para acompanhar a jornada da solicitação.
SIEM
Correlaciona eventos de segurança e procura comportamentos suspeitos.
Auditoria
Mantém evidências sobre quem fez o quê, quando e a partir de onde.
Alta disponibilidade
Permite continuidade mesmo quando componentes falham.
Recuperação de desastre
Prepara o ambiente para eventos graves, incluindo perda de um Data Center.
A verdadeira arquitetura bancária é muito maior que uma linha entre celular e COBOL.
Ela se parece mais com uma frota completa.
23. Um exemplo completo: consulta de saldo
Vamos organizar o fluxo passo a passo.
Passo 1 — O usuário toca em “Saldo”
O aplicativo cria uma solicitação.
{
"conta": "567890",
"operacao": "SALDO"
}
Passo 2 — TLS protege a comunicação
Os dados seguem criptografados.
Passo 3 — O WAF analisa o tráfego
Requisições suspeitas podem ser bloqueadas.
Passo 4 — O API Gateway valida o acesso
O token é verificado, políticas são aplicadas e a API correta é selecionada.
Passo 5 — A integração traduz os dados
JSON é transformado na estrutura esperada pelo sistema central.
Passo 6 — A solicitação chega ao CICS
O CICS identifica a transação e chama o programa COBOL.
Passo 7 — O programa valida a conta
Campos obrigatórios, formato e regras básicas são analisados.
Passo 8 — O COBOL consulta o Db2
O saldo é recuperado.
Passo 9 — O retorno é tratado
O programa verifica SQLCODE, monta o status e prepara a resposta.
Passo 10 — A integração converte para JSON
A estrutura COBOL é traduzida.
Passo 11 — O aplicativo recebe o resultado
A tela exibe o saldo.
A consulta aparentemente simples mobilizou múltiplos componentes.
24. Outro exemplo: uma transferência PIX
Uma transferência é mais sensível que uma consulta.
O fluxo pode incluir:
autenticação reforçada;
validação de dispositivo;
checagem de limite;
análise antifraude;
validação do destinatário;
verificação de saldo;
débito;
crédito;
registro contábil;
geração de comprovante;
notificação;
auditoria;
publicação de eventos.
Em alguns casos, partes são síncronas e outras assíncronas.
O usuário precisa saber imediatamente se a operação foi aceita.
Entretanto, tarefas secundárias podem ocorrer depois, como:
alimentar o Data Lake;
atualizar relatórios;
enviar campanhas;
executar análises históricas.
Essa combinação reduz o tempo percebido pelo usuário sem sacrificar controles importantes.
25. Onde cada tecnologia realmente se encaixa
Um iniciante pode cair na armadilha de tentar escolher “a melhor tecnologia”.
Mas a pergunta correta é:
Qual problema cada tecnologia resolve?
O WAF protege aplicações expostas.
O API Gateway administra APIs.
O z/OS Connect ajuda a integrar APIs e ativos do IBM Z.
O MQ transporta mensagens com confiabilidade e desacoplamento.
O Kafka distribui eventos para múltiplos consumidores.
O RACF controla identidades e acessos no z/OS.
O WLM gerencia prioridades e objetivos de serviço.
O CICS executa transações.
O COBOL implementa regras de negócio.
O Db2 armazena e protege dados relacionais.
Eles não são necessariamente concorrentes.
São membros de uma tripulação.
O erro arquitetural acontece quando uma ferramenta é usada fora de sua missão.
Não peça ao tricorder para operar os motores de dobra.
26. Dicas para o Programador COBOL Padawan
Aprenda primeiro o fluxo, depois os produtos
Antes de decorar comandos, compreenda:
Entrada → Validação → Processamento → Persistência → Resposta
Domine estruturas de dados
Entenda profundamente:
PIC X;PIC 9;sinal;
casas decimais;
COMP;COMP-3;redefinições;
níveis;
Copybooks.
A integração depende do contrato de dados.
Trate códigos de retorno
Verifique:
SQLCODE;EIBRESP;EIBRESP2;códigos MQ;
status HTTP;
códigos de aplicação.
Não confunda erro técnico com erro de negócio
Erro técnico:
Db2 indisponível
Erro de negócio:
Saldo insuficiente
O tratamento deve ser diferente.
Pense em reprocessamento
Pergunte:
O que acontece se a mesma mensagem chegar novamente?
Evite mensagens vagas
Em vez de:
ERRO
Prefira códigos e mensagens que permitam diagnóstico.
TRX104 - LIMITE DIARIO EXCEDIDO
Nunca registre dados sensíveis sem necessidade
Logs não devem expor:
senhas;
tokens;
números completos de cartões;
chaves;
informações pessoais desnecessárias.
Conheça o caminho completo
Mesmo sendo programador COBOL, compreenda API, JSON, HTTP, mensageria e segurança.
Você não precisa dominar tudo imediatamente.
Mas precisa saber conversar com as outras equipes.
27. Curiosidades para levar ao Ten Forward
O COBOL nasceu antes do primeiro episódio de Star Trek
COBOL começou a ser desenvolvido em 1959.
Star Trek estreou em 1966.
Ou seja, quando a Enterprise iniciou sua missão televisiva, o COBOL já estava em operação.
JSON é muito mais jovem
JSON ganhou popularidade décadas depois do COBOL.
Mesmo assim, hoje os dois formatos trabalham juntos diariamente.
O código antigo pode sustentar a experiência mais moderna
Um aplicativo com biometria, animações e inteligência artificial pode depender de uma regra escrita originalmente muitos anos antes.
A interface muda.
A regra central continua valiosa.
Nem toda lentidão está no mainframe
Quando uma transação está lenta, o problema pode estar:
no celular;
na operadora;
no DNS;
no WAF;
no Gateway;
na rede;
no serviço de integração;
no banco;
em uma fila;
em um consumidor externo.
Diagnosticar exige observabilidade de ponta a ponta.
28. Easter eggs da ponte de comando
Em muitos ambientes de desenvolvimento, nomes de projetos, filas, servidores e transações escondem referências culturais.
Você poderá encontrar nomes como:
KIRK
SPOCK
SCOTTY
ENTERPRISE
VULCAN
NCC1701
Mas há uma regra informal importante:
O nome divertido pode existir no ambiente de testes. Em produção, a clareza operacional deve vencer a criatividade descontrolada.
Uma fila chamada:
Q.PIX.PROCESSAMENTO
é mais fácil de compreender durante um incidente do que:
Q.SPOCK.MIND.MELD
Embora, admitamos, a segunda seja muito mais divertida.
Outro easter egg conceitual aparece na própria arquitetura.
O z/OS Connect funciona como o comunicador universal.
O CICS atua como a torre de controle.
O RACF é a segurança da Frota.
O WLM é o oficial que define prioridades.
O Db2 é a memória histórica.
O MQ é o serviço de transporte.
O COBOL é o veterano que conhece todas as regras da missão.
E o programador?
O programador é o tripulante que precisa garantir que todos consigam trabalhar juntos.
29. Por que aprender isso em 2024?
Porque o mercado não precisa apenas de pessoas que saibam escrever uma tela ou um programa isolado.
Ele precisa de profissionais que compreendam sistemas.
Um desenvolvedor mobile pode criar uma excelente interface, mas precisa entender limites, autenticação, falhas e contratos.
Um desenvolvedor de APIs precisa compreender transações, idempotência, segurança e disponibilidade.
Um programador COBOL precisa entender JSON, REST, eventos e integração.
Um especialista de banco precisa conhecer concorrência, commit, rollback e performance.
Quanto mais você compreende a jornada completa, maior é sua capacidade de:
diagnosticar incidentes;
projetar integrações;
conversar com outras equipes;
evitar erros;
modernizar com segurança;
tomar decisões arquiteturais.
O profissional raro não é aquele que sabe tudo.
É aquele que entende como as partes se conectam.
30. Plano de estudo para atravessar essa ponte
Etapa 1 — Fundamentos web
Estude:
HTTP;
HTTPS;
métodos GET, POST, PUT e DELETE;
códigos de status;
headers;
JSON.
Etapa 2 — APIs
Aprenda:
REST;
contratos;
autenticação;
versionamento;
tratamento de erros;
OpenAPI.
Etapa 3 — COBOL estruturado
Domine:
divisão de dados;
PIC;Copybooks;
PERFORM;EVALUATE;tratamento de retorno;
subprogramas.
Etapa 4 — CICS
Explore:
transações;
programas;
COMMAREA;
Channels e Containers;
LINK;XCTL;RETURN;EIBRESP.
Etapa 5 — Db2
Pratique:
SQL embutido;
cursores;
SQLCODE;commit;
rollback;
locks;
índices.
Etapa 6 — Mensageria
Conheça:
filas;
produtores;
consumidores;
mensagens persistentes;
unidades de trabalho;
dead-letter queues;
idempotência.
Etapa 7 — Integração IBM Z
Estude:
z/OS Connect;
APIs para CICS;
transformação JSON;
contratos de dados;
segurança.
Etapa 8 — Observabilidade
Aprenda a seguir uma transação do início ao fim usando:
logs;
métricas;
traces;
identificadores de correlação.
Conclusão — O mainframe nunca esteve longe do seu celular
Quando você consulta o saldo, paga uma conta ou realiza uma transferência, não está usando apenas um aplicativo.
Está acionando uma cadeia sofisticada de tecnologias.
O celular oferece a experiência.
O TLS protege a viagem.
O WAF vigia a fronteira.
O API Gateway organiza o tráfego.
O z/OS Connect traduz os idiomas.
O MQ transporta mensagens confiáveis.
O Kafka espalha eventos.
O RACF protege os recursos.
O WLM administra prioridades.
O CICS coordena as transações.
O COBOL executa as regras.
O Db2 preserva os dados.
Cada componente cumpre uma missão.
E essa é talvez a maior lição para o Programador COBOL Padawan:
o mainframe não é uma ilha.
Ele é parte de um universo conectado.
Aprender COBOL continua sendo importante, mas o profissional moderno precisa enxergar além da Procedure Division. Precisa entender de onde os dados chegam, como são protegidos, como são traduzidos, como são processados e como retornam ao usuário.
A próxima vez que você tocar em “Confirmar” no aplicativo do banco, observe aqueles poucos segundos de espera.
Por trás da tela, uma frota inteira estará trabalhando.
Mensagens atravessarão redes.
Sistemas confirmarão identidades.
Filas protegerão transações.
Programas COBOL executarão regras consolidadas por décadas.
Bancos de dados preservarão a consistência.
E, em algum lugar de um Data Center, um mainframe continuará cumprindo silenciosamente sua missão:
processar com segurança aquilo que o mundo moderno não pode se permitir perder.
Vida longa ao COBOL.
Vida longa ao mainframe.
E que suas transações retornem sempre com SQLCODE = 0.
Sem comentários:
Enviar um comentário