 |
| Bellacosa Mainframe fala do mainframe do futuro |
☕ Um Café no Bellacosa Mainframe
⚓ ALMIRANTE GRACE HOPPER E O MAINFRAME QUE SE RECUSAVA A FICAR NO PASSADO
COBOL, Git, APIs, MQ, Kafka, CI/CD, Jenkins, OpenShift, observabilidade, segurança, IA e a estranha descoberta de que modernizar um mainframe não significa necessariamente jogar fora aquilo que funciona.
🎬 PRÓLOGO — O jovem programador e a máquina do tempo
Imagine seu primeiro dia trabalhando com mainframe.
Você aprendeu algumas coisas sobre COBOL.
Já sabe que existe:
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
Descobriu que PIC X(10) não é uma fotografia de dez pixels e que COMP-3 provavelmente vai persegui-lo em algum momento da carreira.
Então você entra no ambiente corporativo.
TSO.
ISPF.
Datasets.
JCL.
JES2.
SDSF.
CICS.
Db2.
VSAM.
De repente surge uma senhora usando uniforme da Marinha dos Estados Unidos.
Ela olha para aquele monte de tecnologia e pergunta:
— Muito bem, jovem. E onde está o Git?
Silêncio.
— Git?
— Sim. E o pipeline?
Mais silêncio.
— E como essa aplicação publica uma API?
Agora o iniciante começa a suar.
— Almirante Hopper... eu só queria aprender COBOL.
Bem-vindo ao Bellacosa Mainframe.
Pegue o café.
Porque hoje vamos descobrir que aprender COBOL é apenas a porta de entrada para uma cidade tecnológica gigantesca.
E nossa guia será ninguém menos que Grace Murray Hopper, pioneira da computação, uma das figuras históricas associadas ao desenvolvimento dos primeiros compiladores e cuja trajetória ajudou a estabelecer ideias que influenciaram profundamente o nascimento das linguagens de programação de alto nível e do próprio COBOL.
Se Hopper estivesse diante de um IBM Z moderno, provavelmente reconheceria imediatamente uma ideia que atravessou toda a história da computação:
A melhor tecnologia não é necessariamente aquela que substitui tudo. É aquela que permite evoluir sem destruir o que já funciona.
⚓ CAPÍTULO 1 — COBOL NÃO É O MAINFRAME
Esse é nosso primeiro ensinamento.
Muita gente começando mistura três conceitos:
COBOL
MAINFRAME
SISTEMA LEGADO
Como se fossem sinônimos.
Não são.
COBOL é uma linguagem.
Mainframe é uma plataforma computacional.
Legado é um conceito relacionado a sistemas existentes que carregam história, regras, dependências e valor para a organização.
Uma aplicação COBOL pode executar em diferentes plataformas.
E um IBM Z executa muito mais do que COBOL.
Dentro de um ambiente moderno podemos encontrar:
COBOL
PL/I
Assembler
Java
Python
REXX
Shell
JavaScript
SQL
Além de tecnologias como:
CICS
IMS
Db2
VSAM
MQ
z/OS Connect
z/OSMF
USS
Portanto, quando alguém pergunta:
"Como modernizamos o COBOL?"
talvez esteja fazendo a pergunta errada.
A pergunta melhor é:
Como modernizamos a maneira como essa aplicação é desenvolvida, integrada, testada, entregue, observada e mantida?
Essa pequena diferença muda tudo.
🧱 CAPÍTULO 2 — NÃO DEMOLIREMOS A CATEDRAL
Imagine uma aplicação bancária escrita em COBOL há 30 anos.
Ela possui:
2 milhões de linhas de código
centenas de programas
milhares de regras
copybooks
Db2
VSAM
CICS
jobs batch
interfaces
arquivos
relatórios
Alguém entra na reunião e diz:
— Está velho. Vamos reescrever tudo em Java.
Grace Hopper lentamente coloca a xícara sobre a mesa.
Silêncio na sala.
O problema não é Java.
O problema é imaginar que idade do código determina automaticamente ausência de valor arquitetural.
Aquele COBOL pode conter regras acumuladas durante décadas:
IF CLIENTE-VIP
AND SALDO > LIMITE-MINIMO
AND CARTAO-ATIVO
AND NOT BLOQUEIO-FRAUDE
PERFORM AUTORIZAR-COMPRA.
Parece simples.
Mas talvez existam outros 300 critérios espalhados pelo sistema.
Quando reescrevemos uma aplicação, não estamos simplesmente traduzindo:
COBOL → Java
Estamos tentando transportar:
30 anos de decisões
30 anos de exceções
30 anos de legislação
30 anos de bugs corrigidos
30 anos de conhecimento institucional
É como desmontar uma catedral pedra por pedra porque alguém não gosta da cor da porta.
Modernização inteligente começa perguntando:
O que realmente precisa mudar?
💻 CAPÍTULO 3 — O PROGRAMADOR COBOL GANHA UMA NOVA OFICINA
Durante décadas, uma imagem clássica do desenvolvimento mainframe foi:
TSO
↓
ISPF
↓
EDIT
↓
JCL
↓
COMPILADOR
↓
LINK-EDIT
↓
LOADLIB
Isso continua válido.
Aliás, iniciante: aprenda isso.
Não pule ISPF.
Não pule JCL.
Não pule SDSF.
Você precisa entender a máquina antes de automatizá-la.
Mas a oficina moderna ganhou ferramentas novas.
Podemos ter:
VS Code / IDz
↓
Git
↓
Pull Request
↓
Code Review
↓
CI/CD
↓
Build
↓
Tests
↓
Deploy
↓
z/OS
Perceba algo maravilhoso.
O COBOL continua lá.
O que mudou foi o processo ao redor dele.
🌳 CAPÍTULO 4 — GIT ENCONTRA O COBOL
Imagine dois programadores modificando PGM001.
No modelo tradicional, o controle pode depender bastante da ferramenta de SCM mainframe utilizada e dos procedimentos da empresa.
Com Git temos conceitos como:
repository
branch
commit
merge
pull request
tag
Por exemplo:
main
│
├──── feature/nova-regra-cartao
│
│ ↓
│
│ alterações
│
│ ↓
│
│ commit
│
│ ↓
│
└──────── merge
O grande ganho não é apenas guardar código.
Git permite registrar a história das mudanças.
Quem alterou?
Quando?
Por quê?
Qual ticket motivou?
Qual revisão aprovou?
Qual versão entrou em produção?
Isso conversa perfeitamente com uma filosofia antiga do Bellacosa Mainframe:
Código também é documento histórico.
Aquele comentário de manutenção:
* 2026-09-17 BELLACOSA
* AJUSTE REGRA DE AUTORIZACAO
continua útil.
Mas agora existe também uma trilha externa muito mais poderosa.
⚙️ CAPÍTULO 5 — CI/CD: O ROBÔ QUE NÃO ESQUECE PASSOS
Suponha que exista um procedimento com 17 passos para publicar uma aplicação.
Humano fazendo:
1
2
3
4
5
6
...
16
17
Depois de seis meses alguém executa:
1
2
3
4
6
Cadê o passo 5?
Produção descobre.
Pipeline existe justamente para transformar procedimentos repetitivos em processos executáveis.
COMMIT
↓
BUILD
↓
TEST
↓
SECURITY
↓
PACKAGE
↓
DEPLOY
Ferramentas como Jenkins podem orquestrar esse fluxo.
Mas atenção para uma distinção importante:
Jenkins não é o compilador COBOL.
Ele é um orquestrador.
Pode dizer:
execute build
Depois:
execute tests
Depois:
deploy
É quase como um maestro.
Os instrumentos continuam sendo outros.
📜 CAPÍTULO 6 — JCL NÃO MORREU; GANHOU UM ROBÔ
Aqui surge uma das minhas partes favoritas.
Alguém olha CI/CD e imagina:
"Então jogamos fora o JCL."
Não necessariamente.
Podemos fazer:
Jenkins
↓
z/OSMF
↓
JES2
↓
JCL
↓
Compiler
O pipeline pode submeter um JOB.
Depois acompanhar seu retorno:
RC=0000
Tudo certo.
Prossegue.
Se receber:
RC=0008
o pipeline pode parar.
Perceba a beleza histórica disso.
Temos tecnologias de gerações completamente diferentes cooperando:
JCL + REST
COBOL + Git
JES2 + Jenkins
CICS + JSON
Db2 + APIs
O mainframe não precisa fingir que nasceu ontem.
Ele simplesmente aprende a conversar com quem nasceu ontem.
🧠 CAPÍTULO 7 — DEPENDÊNCIAS: QUANDO O COPYBOOK ESPIRRA
Imagine:
COPY CUSTOMER.
Esse copybook é utilizado por 137 programas.
Você muda um campo.
Parabéns.
Agora começa a diversão.
Quem precisa recompilar?
É aqui que ferramentas modernas de build e análise de dependências tornam-se valiosas.
Podemos representar:
CUSTOMER
│
├── PROG001
├── PROG014
├── PROG087
└── PROG231
Em vez de depender exclusivamente de:
"Pergunta para o João, ele trabalha aqui desde 1998."
transformamos conhecimento institucional em informação processável por ferramentas.
Essa é uma das formas mais profundas de modernização.
Automatizar conhecimento.
🌐 CAPÍTULO 8 — O COBOL DESCOBRE A INTERNET SEM APRENDER JSON
Agora nosso programa precisa atender um aplicativo móvel.
O programador iniciante entra em pânico.
— Vou precisar colocar JSON dentro do COBOL?
Calma.
Imagine:
MOBILE
↓
HTTPS
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
O cliente pode enviar:
{
"conta": "1234567890"
}
Nosso programa pode continuar trabalhando com estruturas tradicionais:
01 LK-CONTA PIC X(10).
Uma camada intermediária realiza a transformação.
E temos um conceito importantíssimo:
Modernizar a interface não exige necessariamente modernizar internamente toda a aplicação.
Isso permite expor funções existentes como serviços modernos sem imediatamente reescrever décadas de lógica.
📬 CAPÍTULO 9 — IBM MQ: NEM TODO MUNDO PRECISA RESPONDER AGORA
Agora imagine uma compra.
Precisamos saber imediatamente se ela foi autorizada.
Isso é naturalmente síncrono:
COMPRA
↓
CICS
↓
COBOL
↓
APROVADA
Mas depois precisamos:
enviar e-mail
dar pontos
atualizar analytics
notificar aplicativo
alimentar antifraude
Será que tudo precisa acontecer antes de devolver "COMPRA APROVADA"?
Não.
Podemos desacoplar:
COMPRA
↓
CICS
↓
APROVADA
↓
MQ
│
├── Cashback
├── Notification
├── Analytics
└── Fraud
Se o cashback estiver indisponível por cinco minutos, não necessariamente precisamos impedir a compra.
MQ ajuda a construir esse desacoplamento e confiabilidade.
📡 CAPÍTULO 10 — EVENTOS: "ALGO ACONTECEU!"
Agora avançamos.
Em vez de perguntar constantemente:
O cliente mudou?
O cliente mudou?
O cliente mudou?
podemos produzir:
CLIENTE_ALTERADO
Esse evento pode ser consumido por diferentes sistemas.
IBM Z
│
CLIENTE_ALTERADO
│
▼
Kafka
│
┌────────┼────────┐
▼ ▼ ▼
CRM AI Analytics
O sistema mainframe torna-se participante de uma arquitetura orientada a eventos.
Esse é um belo exemplo de modernização sem apagar o passado.
🧪 CAPÍTULO 11 — "FUNCIONOU NA MINHA LPAR" NÃO É TESTE
O iniciante modifica o programa.
Compila.
RC=0000
E anuncia:
— Funcionou!
Hopper ergue uma sobrancelha.
Compilar não significa funcionar corretamente.
Precisamos testar comportamento.
DADO
cliente VIP
E
saldo disponível = 10.000
QUANDO
compra = 8.000
ENTÃO
resultado esperado = APROVADO
Testes automatizados permitem verificar continuamente regras conhecidas.
E aqui existe algo profundo.
Em sistemas legados, testes automatizados podem se tornar documentação viva.
Quando alguém perguntar daqui a cinco anos:
"Cliente VIP pode fazer isso?"
o teste ajuda a responder.
🔐 CAPÍTULO 12 — DEVSECOPS: SEGURANÇA NÃO É O ÚLTIMO PASSO
O modelo ruim:
DEV
↓
TEST
↓
PROD
↓
SEGURANÇA DESCOBRE
Modelo melhor:
COMMIT
│
┌──────────┼──────────┐
▼ ▼ ▼
BUILD TEST SECURITY
Podemos procurar:
vulnerabilidades;
credenciais expostas;
problemas de dependências;
configurações inseguras;
violações de políticas.
E no mainframe continuamos tendo controles fundamentais envolvendo RACF, ACF2 ou Top Secret, certificados, TLS, SMF, auditoria e autorização.
DevSecOps não substitui RACF.
Ele amplia a segurança para todo o ciclo de desenvolvimento.
🔭 CAPÍTULO 13 — OBSERVABILIDADE: O TELEFONE NÃO É DASHBOARD
Antigamente, o melhor sistema de monitoramento de algumas empresas era:
produção caiu
↓
usuário percebe
↓
usuário telefona
↓
War Room
Não recomendo.
Mainframes possuem décadas de experiência em monitoramento operacional.
SMF, RMF, OMEGAMON, SDSF e outras ferramentas já forneciam visibilidade muito antes de "observability" virar palavra de conferência.
A evolução moderna é conectar os mundos.
Imagine:
Celular
↓
API
↓
Kubernetes
↓
Kafka
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
O usuário diz:
Está lento.
Quem é culpado?
Sem telemetria, começa o campeonato corporativo:
Cloud: "é o mainframe!"
Mainframe: "é a rede!"
Rede: "é a aplicação!"
Aplicação: "é o banco!"
Banco: "não sou eu!"
Todos inocentes.
O usuário continua esperando.
📊 CAPÍTULO 14 — MÉTRICAS, LOGS E TRACES
Três conceitos aparecem constantemente:
METRICS
LOGS
TRACES
Métricas respondem perguntas como:
quantas transações?
qual latência?
qual CPU?
quantos erros?
qual throughput?
Logs contam eventos:
programa iniciado
cliente não encontrado
timeout
erro SQL
Traces mostram a viagem da transação.
Por exemplo:
TRACE-ID = 0317
Sim.
Nosso easter egg apareceu.
Quem acompanha o Bellacosa Mainframe sabe que quando alguma coisa estranha acontece às 03:17, provavelmente teremos uma investigação.
Nosso trace percorre:
Mobile 20 ms
Gateway 7 ms
Java 31 ms
z/OS Connect 11 ms
CICS 4 ms
COBOL 3 ms
Db2 817 ms
Pronto.
Em vez de:
"O mainframe está lento."
temos:
"Esta operação específica está gastando aproximadamente 817 ms no acesso ao Db2."
Isso é uma War Room baseada em evidências.
🔬 CAPÍTULO 15 — OPENTELEMETRY E A TRANSAÇÃO VIAJANTE
OpenTelemetry aparece justamente para ajudar a padronizar telemetria distribuída.
A ideia simplificada:
Aplicações
↓
telemetria
↓
OpenTelemetry
│
├── metrics
├── logs
└── traces
Depois podemos integrar essa informação a plataformas de observabilidade.
Prometheus, Grafana, Elastic, Splunk, Dynatrace e outros componentes podem participar do ecossistema, dependendo da arquitetura adotada.
Mas nunca esqueça:
dashboard bonito não é observabilidade.
Observabilidade útil significa conseguir investigar comportamento.
📦 CAPÍTULO 16 — NÃO COLOQUE TUDO NUM CONTAINER SÓ PORQUE É MODERNO
Outra reunião.
Alguém anuncia:
— Vamos containerizar tudo!
Hopper procura a saída.
Containers são excelentes.
Kubernetes é excelente para determinados workloads.
OpenShift também.
Mas arquitetura não deveria ser religião.
Podemos perfeitamente ter:
EMPRESA
│
┌───────────┴───────────┐
▼ ▼
OpenShift z/OS
│ │
Java / Node CICS / IMS
│ │
Microservices COBOL
│ │
└───────── API ─────────┤
MQ │
Kafka │
▼
Db2/VSAM
Isso é arquitetura híbrida.
Cada workload executa onde faz sentido.
🌱 CAPÍTULO 17 — STRANGLER FIG: MODERNIZANDO SEM EXPLODIR PRODUÇÃO
Temos:
SISTEMA-CARTAO
com:
autorização
faturamento
cashback
notificação
relatórios
antifraude
Em vez de:
DELETE EVERYTHING;
podemos modernizar progressivamente.
Primeiro retiramos notificações:
COBOL
↓
evento
↓
Kafka
↓
Notification Service
Depois talvez cashback.
Depois outra função.
O core de autorização permanece enquanto houver razões econômicas e técnicas para mantê-lo.
Essa estratégia lembra o chamado Strangler Fig Pattern.
A arquitetura nova cresce progressivamente ao redor da existente.
🗄️ CAPÍTULO 18 — NÃO ESQUEÇA ONDE MORA O TESOURO
Aplicações são importantes.
Mas dados talvez sejam ainda mais importantes.
No mainframe encontramos:
Db2
VSAM
IMS DB
datasets
A modernização precisa considerar como esses dados serão disponibilizados sem criar vinte cópias descontroladas da verdade.
Podemos usar:
APIs
eventos
CDC
replicação
CDC significa Change Data Capture.
Quando alguma coisa relevante muda, podemos capturar essa alteração e propagá-la para outros ecossistemas.
Isso ajuda analytics, integração, data lakes e aplicações de IA.
🤖 CAPÍTULO 19 — IA ENTRA NO MAINFRAME, MAS SEM A MOTOSSERRA
Então chega 2026.
Alguém digita:
"Converta meus 14 milhões de linhas COBOL para Java."
Talvez seja prudente esconder o botão ENTER.
IA pode ser extremamente interessante para legado, mas há aplicações mais inteligentes do que tradução indiscriminada.
Por exemplo:
COBOL legado
↓
IA
│
├── explicar código
├── documentar
├── localizar regras
├── sugerir testes
├── explicar erros
├── analisar dependências
└── auxiliar manutenção
Imagine encontrar um programa de 9.000 linhas.
Em vez de começar lendo linha 1 e terminar três cafés depois na linha 9.000, ferramentas assistidas por IA podem ajudar a construir um mapa inicial.
Mas atenção.
IA pode errar.
Em sistemas críticos precisamos continuar tendo:
revisão humana
testes
evidências
controle de versão
segurança
auditoria
O compilador não aceita:
TRUST ME BRO.
Produção também não deveria aceitar.
🛠️ CAPÍTULO 20 — AUTOMAÇÃO E INFRASTRUCTURE AS CODE
Procedimentos operacionais frequentemente vivem em documentos:
Entre no ISPF, escolha opção X, abra Y, copie Z...
Funciona.
Até alguém esquecer uma linha.
Automação permite transformar procedimentos em código.
Ferramentas como Ansible podem participar da administração e automação de ambientes IBM Z.
A filosofia passa a ser:
ESTADO DESEJADO
↓
AUTOMAÇÃO
↓
ESTADO REAL
Uma palavra importante aqui é:
idempotência.
Simplificando para o iniciante:
Executar a automação novamente não deveria destruir tudo; ela deve procurar manter ou alcançar o estado definido.
Isso transforma conhecimento operacional em algo reproduzível.
🗺️ CAPÍTULO 21 — O MAPA DO MAINFRAME MODERNO
Agora podemos juntar nosso quebra-cabeça.
USUÁRIOS
│
Mobile / Web
│
▼
API Gateway
│
┌──────────┴──────────┐
▼ ▼
OpenShift z/OS Connect
│ │
Microservices ▼
│ CICS
├────── MQ ───────────┤
│ │
├──── Kafka ──────────┤
│ ▼
│ COBOL
│ │
│ ┌─────┴─────┐
│ ▼ ▼
│ Db2 VSAM
│
▼
Analytics / AI
Por trás:
Developer
↓
VS Code / IDz
↓
Git
↓
Pull Request
↓
Pipeline
↓
Build
↓
Tests
↓
Security
↓
Deploy
↓
IBM Z
E observando tudo:
OBSERVABILITY
│
┌────────┼────────┐
▼ ▼ ▼
Metrics Logs Traces
Agora temos a visão completa.
🎓 CAPÍTULO 22 — ROTEIRO PARA QUEM ESTÁ COMEÇANDO
Não tente aprender tudo simultaneamente.
Isso seria como tentar aprender mecânica estudando um Boeing inteiro.
Construa camadas.
Etapa 1 — Fundamentos
Aprenda:
COBOL
JCL
TSO
ISPF
datasets
JES2/SDSF
Entenda como um programa nasce e executa.
Etapa 2 — Dados
Aprenda:
VSAM
SQL
Db2
Depois explore IMS se fizer sentido para seu ambiente.
Etapa 3 — Online
Estude:
CICS
transações
programas
COMMAREA
channels/containers
Etapa 4 — Integração
Aprenda:
REST
JSON
APIs
MQ
z/OS Connect
Etapa 5 — Engenharia moderna
Entre em:
Git
branch
commit
merge
CI/CD
Jenkins
automated testing
Etapa 6 — Arquitetura
Estude:
microservices
event-driven
Kafka
containers
Kubernetes
OpenShift
hybrid cloud
Etapa 7 — Operação
Aprenda:
SMF
RMF
logs
metrics
traces
OpenTelemetry
observability
Etapa 8 — Segurança
Entenda:
RACF
identidade
autorização
TLS
certificados
DevSecOps
auditoria
Etapa 9 — Automação
Explore:
z/OSMF
REST APIs
Ansible
Infrastructure as Code
Etapa 10 — IA
Finalmente:
code explanation
documentation
test generation
code assistance
incident analysis
legacy discovery
Agora você não é simplesmente alguém que aprendeu sintaxe COBOL.
Você começou a entender engenharia de aplicações IBM Z.
🧭 CAPÍTULO 23 — A LIÇÃO DA ALMIRANTE
Nosso jovem programador finalmente olha novamente para seu pequeno programa:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY 'HELLO WORLD'.
STOP RUN.
No começo da história aquilo parecia ser COBOL.
Agora ele consegue imaginar todo o mundo ao redor:
Git
│
▼
COBOL
│
▼
Build
│
▼
Tests
│
▼
Pipeline
│
▼
CICS
│
┌───────┼───────┐
▼ ▼ ▼
API MQ Kafka
│ │
▼ ▼
OpenShift Cloud
│ │
└───────┬───────┘
▼
Observability
Grace Hopper então aponta para a tela.
A verdadeira modernização não está em trocar uma palavra por outra.
Não está em:
COBOL → Java
ou:
Mainframe → Cloud
A transformação está em construir pontes:
LEGADO ↔ MODERNO
BATCH ↔ API
CICS ↔ MOBILE
COBOL ↔ GIT
JCL ↔ CI/CD
JES2 ↔ REST
MQ ↔ MICROSERVICES
DB2 ↔ ANALYTICS
IBM Z ↔ CLOUD
SMF ↔ OBSERVABILITY
PROGRAMADOR ↔ AUTOMAÇÃO
☕ EPÍLOGO — A CATEDRAL CONTINUA ABERTA
Existe uma mania curiosa na tecnologia de declarar coisas mortas.
COBOL morreu.
Mainframe morreu.
Batch morreu.
SQL morreu.
Data center morreu.
Toda década alguém publica um novo obituário.
Enquanto isso, sistemas continuam processando transações.
Talvez o iniciante deva aprender uma lição diferente.
Tecnologia empresarial raramente evolui simplesmente apagando o passado.
Ela evolui em camadas.
O COBOL permanece.
Mas agora está no Git.
O JCL permanece.
Mas um pipeline pode submetê-lo.
O CICS permanece.
Mas uma API pode chamá-lo.
O MQ permanece.
Mas pode conectar arquiteturas distribuídas.
O Db2 permanece.
Mas seus dados podem alimentar analytics e IA.
O IBM Z permanece.
Mas não precisa permanecer isolado.
Essa talvez seja uma das ideias mais importantes para quem começa a carreira em mainframe:
Você não está estudando apenas uma tecnologia antiga. Está estudando como décadas diferentes da história da computação conseguem continuar trabalhando juntas.
E isso muda a pergunta.
Não pergunte apenas:
"Como programo COBOL?"
Pergunte:
"Como uma mudança que fiz neste COBOL percorre Git, build, testes, segurança, CI/CD, CICS, APIs, integração, dados e observabilidade até chegar ao cliente?"
Quando conseguir responder essa pergunta, você terá atravessado uma fronteira importante.
Deixou de olhar somente para as 80 colunas.
Começou a enxergar a arquitetura.
E, em algum lugar da sala de máquinas, nossa Almirante provavelmente estaria satisfeita.
Antes de sair, porém, Hopper olha novamente para o dashboard.
Uma transação desconhecida apareceu.
Horário:
03:17:00
TRACE-ID:
BELLACOSA-0317
Origem:
UNKNOWN
Ela pega o café.
— Bellacosa...
— Sim, Almirante?
— Temos um incidente.
Continua no próximo JOB.
//BELLACOS JOB (0317),'COFFEE',
// CLASS=A,
// MSGCLASS=X
//*
//* NEVER UNDERESTIMATE OLD CODE
//* THAT STILL RETURNS RC=0000
//*
☕ Um Café no Bellacosa Mainframe
Porque modernizar não é esquecer de onde viemos. É garantir que aquilo que construímos ontem ainda consiga conversar com o amanhã.
PS: Este artigo foi pensado para responder a seguinte pergunta.
Como uma empresa moderna desenvolve, integra, automatiza, observa e moderniza aplicações que rodam nesse mainframe?
