 |
| Bellacosa Mainframe e o zos connect |
☕ Um Café no Bellacosa Mainframe
Sherlock Holmes, COBOL e o Mistério da API que Entrou no CICS sem Conhecer COMMAREA
🔎 z/OS Connect, REST, JSON, OpenAPI, CICS, IMS, Db2, segurança, modernização e o curioso caso em que Watson jurava que o legado precisava morrer — até Holmes encontrar uma porta chamada API
Londres, 221B Baker Street.
Chovia.
Naturalmente chovia.
Toda boa investigação envolvendo sistemas legados começa com chuva, café frio e alguém dizendo:
— Holmes, temos um problema grave.
Sherlock Holmes não levantou os olhos do terminal 3270.
— Grave, Watson?
— Gravíssimo. A diretoria descobriu APIs.
Holmes parou.
A sala ficou em silêncio.
Até o JES2 pareceu diminuir o número de mensagens no console.
Watson continuou:
— Agora querem modernizar tudo.
— Naturalmente.
— Disseram que temos de substituir o COBOL.
Holmes finalmente virou a cadeira.
— E qual é o problema do sistema atual?
Watson consultou as anotações.
— Processa milhões de transações por dia, roda há vinte anos, tem disponibilidade excelente, regras de negócio consolidadas, integração com CICS e Db2 e praticamente ninguém sabe exatamente tudo que ele faz.
Holmes acendeu imaginariamente seu cachimbo.
— Então, Watson, já temos nosso primeiro suspeito.
— O COBOL?
— Não. A palavra modernização.
E assim começa nossa investigação.
Porque uma das coisas mais interessantes sobre o IBM z/OS Connect é justamente esta: ele nos obriga a separar duas coisas que muita apresentação corporativa insiste em colocar dentro da mesma mala.
Modernizar não é necessariamente reescrever.
Às vezes o sistema já está fazendo exatamente aquilo que deveria fazer.
O problema é apenas que ninguém do lado de fora consegue conversar com ele usando as interfaces modernas que o restante da empresa adotou.
E é aí que entra o z/OS Connect.
O cadáver não estava morto
Vamos começar pelo mistério clássico.
Você possui um programa COBOL.
Algo parecido com isto:
IDENTIFICATION DIVISION.
PROGRAM-ID. CONSULTA-SALDO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CONTA PIC 9(08).
01 WS-SALDO PIC S9(11)V99 COMP-3.
01 WS-LIMITE PIC S9(11)V99 COMP-3.
01 WS-STATUS PIC X(01).
PROCEDURE DIVISION.
PERFORM CONSULTAR-CONTA
PERFORM CALCULAR-LIMITE
PERFORM RETORNAR-DADOS
GOBACK.
O programa funciona.
Ele talvez seja executado dentro do CICS.
Talvez consulte Db2.
Talvez utilize uma COMMAREA.
Talvez faça parte de uma transação que existe desde uma época em que telefone celular parecia um tijolo usado para ligar para Gordon Gekko.
Durante anos, o acesso era feito por uma aplicação 3270.
Algo como:
USUÁRIO
|
v
TERMINAL 3270
|
v
CICS
|
v
COBOL
|
v
Db2
Perfeito.
Até que chegou o aplicativo mobile.
O novo desenvolvedor pergunta:
— Qual endpoint devo chamar para consultar saldo?
O COBOLzeiro responde:
— Endpoint?
— Sim. Algo como:
GET /accounts/123456/balance
— Rapaz, eu tenho uma COMMAREA.
E os dois se observam como arqueólogos de civilizações diferentes.
É exatamente esse tipo de fronteira tecnológica que o z/OS Connect ajuda a resolver.
A primeira pista: o que é z/OS Connect?
Em termos simples, o IBM z/OS Connect permite conectar recursos do z/OS ao universo de APIs.
Isso significa criar uma ponte entre tecnologias como:
COBOL
CICS
IMS
Db2
z/OS
e o universo:
HTTP
REST
JSON
OpenAPI
OAuth
JWT
Cloud
Mobile
Web
Kubernetes
Visualmente:
Aplicação Web
|
Aplicação Mobile
|
Microsserviço
|
Sistema Cloud
|
v
REST / JSON
|
v
+----------------+
| z/OS Connect |
+----------------+
|
+------ CICS
|
+------ IMS
|
+------ aplicações z/OS
|
v
COBOL
|
v
Db2
Para Sherlock Holmes, isso seria a primeira evidência importante.
O COBOL não desapareceu.
Apenas ganhou um intérprete na porta.
Watson comete o primeiro erro: “Então z/OS Connect é um API Gateway?”
Não exatamente.
Esse é um daqueles erros suficientemente próximos da verdade para parecer corretos.
O z/OS Connect possui funções relacionadas a APIs, segurança e integração, mas sua função mais importante deve ser entendida como:
ligar APIs ao mundo z/OS.
Em uma arquitetura corporativa real, pode existir algo assim:
Internet
|
v
API Gateway corporativo
|
v
z/OS Connect
|
v
CICS
|
v
COBOL
O API Gateway pode cuidar de coisas como:
exposição externa;
políticas corporativas;
rate limiting;
analytics;
controle de consumidores;
roteamento;
autenticação de borda.
Enquanto o z/OS Connect trabalha próximo dos recursos do IBM Z.
Holmes provavelmente diria:
“Não confunda o mordomo com a porta da mansão, Watson. Ambos controlam quem entra, mas desempenham funções diferentes.”
API Provider: quando o mainframe oferece um serviço
Agora entramos em uma das funções mais importantes.
Imagine um CICS contendo transações como:
INQC Consulta Cliente
INQS Consulta Saldo
BLKC Bloqueia Cartão
LIMC Consulta Limite
No mundo antigo, uma aplicação talvez precisasse conhecer detalhes específicos do backend.
No mundo das APIs, podemos criar algo mais amigável:
GET /clientes/{id}
GET /contas/{id}/saldo
POST /cartoes/{id}/bloqueio
GET /cartoes/{id}/limite
Uma aplicação mobile poderia executar:
GET /contas/778899/saldo
E receber:
{
"conta": "778899",
"saldo": 28453.72,
"moeda": "BRL"
}
Por trás disso:
Mobile
|
| HTTPS
v
z/OS Connect
|
v
CICS
|
v
COBOL
|
v
Db2
A parte fascinante é esta:
o aplicativo não precisa saber que existe CICS.
E o COBOL não precisa saber que existe smartphone.
Cada lado trabalha dentro de seu próprio universo tecnológico.
Esse desacoplamento é uma das grandes virtudes da arquitetura.
Uma COMMAREA entra em Baker Street
Watson recebe uma estrutura COBOL:
01 DFHCOMMAREA.
05 CA-ACCOUNT PIC 9(08).
05 CA-CUSTOMER PIC X(40).
05 CA-BALANCE PIC S9(11)V99 COMP-3.
05 CA-LIMIT PIC S9(11)V99 COMP-3.
05 CA-STATUS PIC X(01).
Do outro lado chega:
{
"account": "12345678"
}
Watson pergunta:
— Holmes, como esse JSON vai entrar nessa estrutura?
Holmes aponta para o quadro.
É justamente aqui que entra o conceito de mapeamento e transformação de dados.
Porque os dois mundos possuem representações diferentes.
JSON entende coisas como:
string
number
boolean
array
object
null
COBOL possui:
PIC X
PIC 9
COMP
COMP-3
OCCURS
REDEFINES
SIGN
Imagine:
05 BALANCE PIC S9(11)V99 COMP-3.
Isso não é simplesmente “um número”.
Existe representação interna.
Existe sinal.
Existe escala decimal.
Existe formato binário ou decimal compactado dependendo da declaração.
Portanto, converter:
{
"balance": 1500.75
}
para uma estrutura COBOL envolve entender tipos e representação.
Não é magia.
É integração.
Easter egg nº 1: COMP-3 continua assustando quem vem da web
Um desenvolvedor JavaScript olha:
PIC S9(09)V99 COMP-3
e talvez pense:
“Por que o número está vestido de hieróglifo?”
O programador COBOL olha:
const value = data?.customer?.accounts?.[0]?.balance ?? 0;
e pensa exatamente a mesma coisa.
Cada geração cria sua própria magia negra.
OpenAPI: a ficha policial da API
Sherlock Holmes gostava de arquivos.
Dossiês.
Registros.
Descrições precisas.
OpenAPI provavelmente seria uma de suas tecnologias favoritas.
OpenAPI é uma especificação para descrever APIs HTTP.
Por exemplo:
paths:
/accounts/{accountId}/balance:
get:
summary: Returns account balance
parameters:
- name: accountId
in: path
required: true
responses:
'200':
description: Account found
'404':
description: Account not found
Esse arquivo pode descrever:
endpoints;
parâmetros;
métodos HTTP;
request;
response;
códigos de retorno;
schemas;
tipos de dados.
Para um programador COBOL iniciante, podemos fazer uma analogia.
Uma copybook define:
estrutura de dados
OpenAPI define:
estrutura da conversa.
A copybook responde:
“Como os dados estão organizados?”
OpenAPI responde:
“Como alguém chama esse serviço e o que ele recebe de volta?”
Não são equivalentes.
Mas ambos cumprem a função importantíssima de estabelecer contratos.
API-first: Holmes começa pela pergunta correta
Durante muitos anos, projetos de integração começavam assim:
Temos o programa ABC123. Como transformamos isso em uma API?
Funciona.
Mas arquiteturas modernas cada vez mais preferem começar de outra maneira:
Qual serviço o negócio precisa?
Imagine que precisamos oferecer consulta de saldo.
Primeiro definimos:
GET /accounts/{id}/balance
Depois definimos o retorno:
{
"account": "123456",
"availableBalance": 1800.42,
"currency": "BRL"
}
Só depois perguntamos:
Quem implementará isso?
Talvez:
CICS + COBOL
Talvez:
IMS
Talvez:
Db2
Talvez daqui a dez anos:
outra implementação.
O consumidor não precisa necessariamente saber.
Este é o poder de um contrato bem definido.
O grande mistério: modernização sem reescrita
Aqui chegamos ao coração do caso.
Considere um programa COBOL com:
25 anos de produção
4.000 regras de negócio
dezenas de integrações
tratamentos de exceção
rotinas fiscais
regras contábeis
auditoria
segurança
controle transacional
Alguém entra em uma reunião e diz:
— Precisamos reescrever porque é legado.
Holmes pergunta:
— O sistema está errado?
— Não.
— Está lento?
— Não.
— É instável?
— Não.
— Não suporta o volume?
— Suporta.
— Então por que reescrever?
— Porque não é moderno.
Silêncio.
Esse é exatamente o ponto no qual tecnologias como z/OS Connect ficam interessantes.
Talvez você não precise substituir:
COBOL
Talvez precise substituir:
a maneira como os consumidores acessam o COBOL.
Veja a diferença:
ANTES
3270
|
v
CICS
|
v
COBOL
Depois:
Mobile
Web
Cloud
Parceiro
Kubernetes
|
v
REST API
|
v
z/OS Connect
|
v
CICS
|
v
COBOL
A lógica continua funcionando.
A interface muda.
Isso é modernização por integração.
Mas Holmes encontra pegadas indo na direção contrária
Até agora falamos de aplicações externas chamando o mainframe.
Mas existe outro cenário.
O próprio z/OS pode precisar chamar APIs externas.
Imagine um programa COBOL processando uma transação de cartão.
Ele precisa consultar um sistema antifraude baseado em IA rodando em cloud.
Fluxo:
CICS
|
v
COBOL
|
v
Integração API
|
v
Serviço antifraude
|
v
Cloud
Pergunta:
Mainframe pode consumir APIs modernas?
Sim.
Isso quebra uma imagem antiga do mainframe como uma fortaleza completamente isolada.
Na realidade, ambientes modernos são híbridos.
Algo como:
CLOUD
+------------------+
| Fraud Detection |
+--------+---------+
^
|
REST
|
|
+----------------------------------+
| IBM Z |
| |
| COBOL ---- z/OS Connect |
| | |
| CICS |
| | |
| Db2 |
+----------------------------------+
Isso permite ao legado participar de ecossistemas modernos sem abandonar tudo aquilo que já faz bem.
Um pequeno caso para Watson investigar
Imagine uma transferência bancária.
O fluxo COBOL tradicional:
1. Validar conta de origem
2. Validar conta destino
3. Verificar saldo
4. Verificar limite
5. Executar débito
6. Executar crédito
7. Registrar auditoria
Agora surge uma nova regra:
Consultar sistema externo antifraude.
O programa pode enviar dados como:
{
"customer": "823718",
"amount": 12500.00,
"destination": "998812",
"channel": "MOBILE"
}
e receber:
{
"riskScore": 87,
"decision": "REVIEW"
}
O COBOL pode então continuar seu processamento.
Note o fenômeno.
O sistema não foi substituído.
Ele foi enriquecido por integração.
Segurança: Moriarty encontra a API
Toda vez que você cria uma nova interface, cria também uma nova superfície de ataque.
Moriarty ficaria muito interessado.
Imagine esta API:
POST /payments
Excelente.
Agora imagine que qualquer pessoa possa chamá-la.
Péssimo.
Logo entram conceitos como:
TLS
OAuth
JWT
autenticação
autorização
identidade
RACF
logging
auditoria
políticas
Uma arquitetura simplificada:
Aplicação
|
| token
v
API Gateway
|
v
z/OS Connect
|
v
Segurança z/OS
|
v
CICS
|
v
COBOL
A pergunta crítica deixa de ser apenas:
“A API funciona?”
e passa a incluir:
“Quem chamou?”
“Com qual identidade?”
“Qual recurso tentou acessar?”
“Estava autorizado?”
“O que foi executado?”
“Existe trilha de auditoria?”
Para quem já conhece RACF, a filosofia não é estranha.
RACF sempre quis saber:
USER
RESOURCE
ACCESS
APIs simplesmente ampliam esse problema para um novo universo.
Easter egg nº 2: Sherlock provavelmente seria sysprog
Holmes observa detalhes insignificantes para inferir causas complexas.
Um sysprog vê:
IEC141I
e começa a reconstruir mentalmente meia hora de atividade no sistema.
Watson vê apenas:
“Deu erro.”
Holmes vê:
dataset, volume, catalog, disposition, job, step, allocation, contexto.
A diferença entre novato e veterano frequentemente não é conhecer mais comandos.
É reconhecer padrões.
Sherlock Holmes seria absolutamente perigoso com acesso ao SDSF.
A armadilha do “REST em tudo”
Agora vem um dos pontos mais importantes.
APIs são ferramentas.
Não religião.
Imagine um batch processando:
10.000.000 registros
localmente.
Alguém decide modernizar:
Cada registro chamará uma REST API.
Então você substitui:
10 milhões de operações locais
por:
10 milhões de chamadas HTTP.
Agora adicionamos:
rede
TLS
serialização
desserialização
timeouts
retries
latência
conexões
rate limits
monitoramento distribuído
Watson exclama:
— Mas ficou moderno!
Holmes responde:
— E quarenta vezes mais lento.
Nem toda chamada deve virar API.
Existem cenários em que:
CALL
LINK
MQ
batch
arquivo
Db2
continuam sendo alternativas perfeitamente adequadas.
Arquitetura madura não pergunta:
“Qual tecnologia está na moda?”
Ela pergunta:
“Qual mecanismo resolve melhor este problema?”
Granularidade: o caso das 47 APIs
Imagine um aplicativo bancário mostrando a página inicial.
Ele precisa de:
nome
saldo
limite
cartões
investimentos
últimas transações
empréstimos
mensagens
O arquiteto mais empolgado cria:
GET /customer
GET /balance
GET /limit
GET /cards
GET /investments
GET /transaction1
GET /transaction2
GET /transaction3
GET /loan
GET /messages
A tela abre.
E dispara uma pequena invasão contra o próprio mainframe.
Mobile
|
|--> API
|--> API
|--> API
|--> API
|--> API
|--> API
|--> API
|--> API
|
v
z/OS
Isso pode gerar problemas de:
volume;
latência;
CPU;
conexão;
dependências;
falhas parciais;
escalabilidade.
Holmes diria:
“O fato de haver quarenta pegadas não significa que quarenta pessoas passaram pela sala. Talvez Watson tenha caminhado em círculos.”
Em APIs também.
Precisamos analisar granularidade.
Talvez a tela precise de uma API agregadora:
GET /customer-home
que retorne várias informações em uma chamada.
Não existe resposta universal.
Existe engenharia.
Observabilidade: onde estão escondidos os 4 segundos?
No velho ambiente:
CICS
|
COBOL
|
Db2
Se algo demorava, você analisava:
CICS statistics
SMF
RMF
Db2
CPU
I/O
locks
waits
Agora temos:
Smartphone
|
Internet
|
API Gateway
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
Usuário reclama:
“Consulta demorou quatro segundos.”
Watson aponta para COBOL.
Holmes pergunta:
— Por quê?
— Porque é legado.
— Evidência?
— Nenhuma.
Então começa a investigação.
Talvez:
Mobile 150 ms
Internet 420 ms
Gateway 30 ms
z/OS Connect 40 ms
CICS 4 ms
COBOL 7 ms
Db2 5 ms
serviço externo 3100 ms
Resultado:
COBOL estava inocente.
Esse tipo de ambiente exige observabilidade ponta a ponta.
Você precisa conseguir seguir a transação desde a origem até o backend.
Kubernetes entra pela janela
Agora podemos ligar z/OS Connect ao mundo cloud-native.
Imagine:
+--------------------------------+
| Kubernetes |
| |
| Pod |
| Spring Boot |
| |
+-------------+------------------+
|
| REST
v
z/OS Connect
|
v
CICS
|
v
COBOL
|
v
Db2
Isso não é contradição.
É arquitetura híbrida.
Durante anos venderam uma falsa escolha:
MAINFRAME OU CLOUD
Na prática, muitas organizações operam:
MAINFRAME E CLOUD.
Cada plataforma resolve determinado conjunto de problemas.
Kubernetes pode executar:
frontends
microsserviços
APIs
workers
integrações
serviços stateless
IBM Z pode continuar executando:
core banking
pagamentos
contabilidade
CICS
IMS
Db2
batch crítico
regras centrais
APIs conectam os dois universos.
O mistério dos microsserviços
Watson encontra uma API REST.
— Holmes! Descobri um microsserviço!
Holmes olha para o backend:
REST
|
v
z/OS Connect
|
v
Programa COBOL de 400 mil linhas
— Não, Watson.
REST não significa automaticamente microsserviço.
Um monólito pode expor APIs.
Um microsserviço pode nem sequer usar REST.
Arquitetura de microsserviços envolve características como:
autonomia;
limites funcionais;
implantação independente;
ownership;
domínio;
resiliência;
governança distribuída.
Colocar:
/api
na frente de uma aplicação não transforma automaticamente sua arquitetura.
E isso nem sempre é problema.
Monólitos bem estruturados podem ser excelentes.
A pergunta deveria ser:
O sistema atende adequadamente os requisitos?
Não:
Ele parece suficientemente moderno numa apresentação?
Passo a passo mental para estudar z/OS Connect
Agora vamos montar o nosso roteiro de investigador.
Sempre que você olhar uma arquitetura, comece identificando cinco personagens.
1. Quem chama?
Pode ser:
Mobile
Web
Java
Python
Node.js
Kubernetes
Parceiro
SaaS
COBOL
Esse é o consumer.
2. Qual é a API?
Pergunte:
Qual endpoint?
Qual método?
Qual request?
Qual response?
Qual autenticação?
Exemplo:
GET /accounts/{id}/balance
3. Quem executa a regra real?
Pode ser:
CICS
IMS
COBOL
Db2
outra aplicação z/OS
Esse é o backend.
4. Como os dados são transformados?
Exemplo:
JSON
|
v
accountId = "123456"
|
v
estrutura COBOL
|
v
PIC 9(06)
E no retorno:
COMP-3
|
v
transformação
|
v
JSON number
5. Como a identidade atravessa o caminho?
Pergunte:
Quem é o usuário?
Qual token?
Qual credencial?
Como chega ao z/OS?
Qual autorização existe?
6. Como diagnostico problemas?
Pergunte:
Onde vejo logs?
Como correlaciono chamadas?
Como meço latência?
Como encontro falhas?
Como identifico backend lento?
Se você consegue responder essas seis perguntas, já deixou de apenas “usar uma ferramenta”.
Começou a entender arquitetura.
Exemplo completo: o caso da conta desaparecida
Recebemos uma chamada:
GET /accounts/123456/balance
O consumidor espera:
{
"balance": 4200.75
}
Fluxo:
Mobile
|
v
API Gateway
|
v
z/OS Connect
|
v
CICS transaction
|
v
COBOL
|
v
Db2
COBOL executa:
EXEC SQL
SELECT BALANCE
INTO :WS-BALANCE
FROM ACCOUNT
WHERE ACCOUNT_ID = :WS-ACCOUNT-ID
END-EXEC.
Agora imagine:
SQLCODE = +100
Não encontrado.
No velho mundo, talvez você apresentasse:
ACCOUNT NOT FOUND
No mundo HTTP, podemos mapear semanticamente para:
HTTP 404
com:
{
"error": "ACCOUNT_NOT_FOUND"
}
Observe novamente a tradução de paradigmas.
Db2 fala:
SQLCODE +100
CICS/COBOL entende sua lógica.
HTTP fala:
404
O consumidor moderno entende JSON.
O papel da arquitetura é fazer esses mundos conversarem sem destruir as características de cada um.
Curiosidade: interfaces mudam muito mais rápido que regras de negócio
Isso explica por que sistemas legados permanecem durante décadas.
Imagine uma regra:
SE SALDO + LIMITE >= VALOR
AUTORIZAR TRANSAÇÃO
Ela pode existir desde 1995.
Enquanto a interface já passou por:
terminal
cliente-servidor
web
SOAP
mobile
REST
app
cloud
A regra mudou pouco.
A interface mudou seis vezes.
Isso explica uma ideia importantíssima em arquitetura:
isole aquilo que muda daquilo que permanece.
z/OS Connect ajuda justamente a separar:
regra central
de:
forma de acesso.
O antipadrão mais perigoso: API arqueológica
Imagine simplesmente pegar todas as transações antigas e expô-las diretamente:
TRN1 -> /trn1
TRN2 -> /trn2
TRN3 -> /trn3
TRN4 -> /trn4
Tecnicamente funciona.
Arquiteturalmente talvez seja um desastre.
Uma API deveria representar conceitos compreensíveis para consumidores.
Prefira coisas como:
/accounts
/customers
/payments
/cards
em vez de simplesmente publicar detalhes internos do CICS.
Porque se a API refletir profundamente a implementação interna, você cria acoplamento.
E então a suposta modernização apenas colocou JSON sobre a arquitetura antiga.
Holmes chamaria isso de:
o velho suspeito usando bigode falso.
Performance não desaparece porque usamos JSON
Outro erro comum é imaginar que APIs tornam performance um problema “do middleware”.
Não.
Cada request possui custo.
Podemos imaginar:
tempo total =
rede
+ TLS
+ gateway
+ processamento z/OS Connect
+ chamada CICS
+ execução COBOL
+ Db2
+ serialização
+ retorno
Se sua aplicação gerar:
20 requests
para cada usuário, e houver:
100.000 usuários simultâneos
a matemática rapidamente fica interessante.
Portanto, pense sempre em:
TPS
latência
concorrência
payload
CPU
conexões
timeouts
retries
O famoso velho mainframe continua cobrando aluguel por ciclo de CPU. 😄
Retry: o pequeno detalhe que pode duplicar dinheiro
Imagine:
POST /payments
O cliente envia uma transferência.
O backend processa.
Mas a resposta HTTP se perde.
O consumidor pensa:
Não funcionou.
Então faz retry.
Se o design não for cuidadoso, você pode executar a transferência duas vezes.
Por isso APIs transacionais precisam pensar em conceitos como:
idempotência
transaction IDs
correlation IDs
controle de duplicidade
Exemplo:
X-Transaction-ID: ABC123XYZ
O backend pode registrar:
ABC123XYZ já processada.
Isso é um excelente exemplo de como integração aparentemente simples toca profundamente em engenharia transacional.
O programador CICS veterano provavelmente sorrirá:
“Vocês acabaram de redescobrir problemas que resolvemos há quarenta anos.”
Sim.
Cloud-native frequentemente descobre que o velho mainframe já conhecia alguns monstros.
Apenas lhes dava outros nomes.
Easter egg nº 3: “Elementary, my dear Watson”
A frase mais associada a Sherlock Holmes:
“Elementary, my dear Watson.”
Curiosamente não aparece exatamente dessa forma nos contos originais de Arthur Conan Doyle.
É uma construção popularizada posteriormente.
Isso combina perfeitamente com tecnologia.
Várias “verdades históricas” de TI também se repetem até parecerem fatos:
Mainframe vai acabar.
COBOL vai desaparecer.
Batch é ultrapassado.
Tudo será cloud.
Tudo será microsserviço.
Décadas passam.
O mainframe continua processando.
COBOL continua executando.
Batch continua fechando o dia.
E alguém coloca Kubernetes na frente de tudo.
z/OS Connect como tradutor entre gerações
Talvez esta seja a melhor forma de compreender a tecnologia.
Imagine três gerações.
Geração 1
3270
CICS
COBOL
VSAM
Db2
Geração 2
Java
Web
SOAP
Application Servers
Geração 3
REST
JSON
OpenAPI
Cloud
Kubernetes
Mobile
Uma empresa raramente substitui uma geração inteira pela seguinte.
Ela acumula camadas.
Logo temos:
Mobile
|
Cloud
|
REST
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
E isso não é necessariamente feio.
Pode ser exatamente a arquitetura apropriada.
A grande lição para o programador COBOL iniciante
Se você está começando agora em COBOL, existe uma tentação perigosa.
Pensar:
Preciso aprender apenas COBOL.
Não.
Aprenda COBOL profundamente.
Mas aprenda também o mundo ao redor.
Entenda:
HTTP
REST
JSON
OpenAPI
APIs
TLS
OAuth
JWT
CICS
Db2
MQ
Git
CI/CD
containers
Kubernetes
Você não precisa se transformar em especialista em tudo.
Mas precisa entender como essas peças se encaixam.
Porque o profissional COBOL mais valioso não será necessariamente aquele que memoriza mais verbos da linguagem.
Será aquele que consegue olhar:
React
|
API
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
e compreender a transação inteira.
Esse profissional consegue conversar com:
dev web
arquiteto
sysprog
DBA
segurança
cloud
CICS admin
negócio
Ele se torna uma ponte humana entre tecnologias.
E pontes são valiosas quando existem dois mundos que precisam conversar.
O último diálogo em Baker Street
Watson fecha o notebook.
— Então conseguimos transformar nosso sistema COBOL em um sistema moderno?
Holmes balança a cabeça.
— Não exatamente.
— Não?
— O sistema já era moderno para o problema que resolvia.
Watson franze a testa.
Holmes continua:
— Apenas ensinamos o resto do mundo a conversar com ele.
No monitor aparece:
GET /accounts/123456/balance
A chamada atravessa HTTPS.
Passa pela camada de APIs.
Chega ao z/OS Connect.
Entra no CICS.
Executa COBOL.
Consulta Db2.
Volta.
{
"balance": 7250.00
}
O smartphone exibe:
Saldo disponível: R$ 7.250,00
Em algum lugar abaixo de milhares de camadas de software, um programa COBOL executa:
MOVE WS-SALDO TO CA-SALDO.
Ninguém no celular sabe.
Ninguém precisa saber.
Holmes sorri.
— Elementary, Watson.
— O quê?
— Modernização não significa demolir a mansão.
Holmes aponta para a tela.
— Às vezes basta instalar uma porta nova.
E talvez essa seja a melhor definição informal de z/OS Connect para quem vem do mundo COBOL:
uma porta moderna instalada em uma casa que continua sendo extraordinariamente boa em guardar as coisas mais valiosas da empresa.
No mundo do Bellacosa Mainframe, Watson finalmente aprende a regra:
LEGADO + API != LEGADO DISFARÇADO
LEGADO + BOA ARQUITETURA
=
CAPACIDADE REUTILIZADA
E quando algum consultor aparecer dizendo:
“Precisamos reescrever tudo.”
Não discuta.
Pegue a lupa.
Pergunte:
Qual é o problema real?
É a regra?
É a plataforma?
É a interface?
É a integração?
É performance?
É custo?
É competência?
Ou alguém simplesmente confundiu
idade com obsolescência?
Sherlock Holmes aprovaria.
O velho sysprog também.
E o COBOL?
O COBOL continuará rodando enquanto todos terminam a reunião.
☕🔎🖥️
