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:

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.

☕🔎🖥️

Translate

quinta-feira, 6 de junho de 2024