 |
| Bellacosa Mainframe e o ambiente de testes em mainframe |
☕ Um Café no Bellacosa Mainframe
🧀 WALLACE & GROMIT E A MÁQUINA QUE FABRICAVA AMBIENTES DE MAINFRAME
COBOL, Db2, IMS, CICS, test data, ambientes efêmeros, service virtualization, CI/CD, DevOps, shift-left, RACF — e o dia em que Wallace descobriu que automatizar o build não adiantava muito quando Gromit precisava esperar três dias pelo ambiente de testes.
Sob a tutela de Wallace & Gromit — porque, no mainframe, construir uma máquina gigantesca para economizar cinco minutos pode parecer absurdo... até descobrirmos que estamos perdendo três dias esperando um DBA.
🎬 PRÓLOGO — UMA MANHÃ TRANQUILA EM WEST WALLABY STREET
Wallace acordou com uma ideia brilhante.
Isso normalmente era perigoso.
Ele levantou da cama, apertou alguns botões e anunciou:
— Gromit! Precisamos modernizar o mainframe!
Gromit abaixou o jornal lentamente.
Sobre a mesa havia um programa COBOL.
Nada particularmente assustador.
IDENTIFICATION DIVISION.
PROGRAM-ID. CRD001.
PROCEDURE DIVISION.
EXEC SQL
SELECT LIMITE_CREDITO,
STATUS_CLIENTE
INTO :WS-LIMITE,
:WS-STATUS
FROM CLIENTE
WHERE CLIENTE_ID = :WS-ID
END-EXEC.
Wallace explicou:
— Só precisamos alterar uma regra!
Gromit olhou novamente para o programa.
Parecia simples.
Alterar.
Compilar.
Testar.
Entregar.
Wallace então abriu outro papel.
Para testar aquela pequena alteração seriam necessários:
uma região CICS;
um subsistema Db2;
tabelas atualizadas;
dados de clientes;
packages;
plans;
permissões RACF;
filas MQ;
datasets;
programas dependentes;
eventualmente IMS;
talvez uma API externa;
e um ambiente que não estivesse sendo usado por outro projeto.
Gromit fechou os olhos.
A alteração levaria talvez duas horas.
Conseguir tudo necessário para testá-la poderia levar dois dias.
E aqui começa nossa história.
Porque um dos grandes problemas do desenvolvimento moderno no mainframe não está necessariamente no COBOL.
Está no tempo entre:
EU TERMINEI O PROGRAMA
e:
EU CONSIGO TESTAR O PROGRAMA
Pegue seu café.
Wallace já está construindo uma máquina.
Isso nunca termina de maneira simples.
🧀 CAPÍTULO 1 — O COBOL NÃO É NECESSARIAMENTE O GARGALO
Existe uma ideia curiosa no mercado:
Sistemas mainframe são lentos para mudar porque COBOL é antigo.
Isso é uma simplificação perigosa.
Um programador experiente pode fazer rapidamente uma alteração COBOL relativamente pequena.
O verdadeiro fluxo pode ser:
REQUISITO
↓
COBOL
↓
COMPILE
↓
LINK
↓
DEPLOY
↓
CICS
↓
Db2
↓
DADOS
↓
INTEGRAÇÕES
↓
TESTE
Agora imagine que cada seta possa envolver outra equipe.
O programador termina.
Precisa do DBA.
O DBA precisa preparar alguma coisa.
Depois precisa do administrador CICS.
Depois segurança.
Depois alguém precisa restaurar dados.
Depois descobrem que SIT está ocupado.
A aplicação levou duas horas para mudar.
O processo levou quatro dias.
Wallace olharia para isso e imediatamente construiria uma máquina com 47 engrenagens, três chaleiras, duas correias transportadoras e provavelmente um dispensador automático de queijo.
Gromit faria algo melhor:
mediria onde está o tempo perdido.
⏱️ CAPÍTULO 2 — O TEMPO QUE NINGUÉM COLOCA NO DASHBOARD
Suponha que uma mudança tenha este lead time:
Programação ................ 4 h
Build ...................... 1 h
Teste ...................... 3 h
Esperando ambiente ......... 18 h
Esperando dados ............ 10 h
Esperando deploy ........... 12 h
Esperando aprovação ........ 8 h
Temos:
TRABALHO EFETIVO ........... 8 h
ESPERA ..................... 48 h
A empresa poderia comprar uma ferramenta que faça o programador produzir código 25% mais rapidamente.
Fantástico.
Talvez economize uma hora.
Ou poderia reduzir pela metade as filas.
Economizaria 24 horas.
É por isso que uma métrica interessante para DevOps é:
Developer Waiting Time
Quanto tempo um desenvolvedor passa esperando alguma coisa necessária para continuar?
Isso pode revelar gargalos invisíveis.
É quase como aplicar conceitos de filas e workload management ao próprio processo de desenvolvimento.
Wallace quer melhorar a máquina.
Gromit primeiro observa onde a máquina está parada.
🏭 CAPÍTULO 3 — DEV, SIT, UAT E A ÚNICA REGIÃO CICS DA VILA
Imagine uma organização com:
DEV
↓
SIT
↓
UAT
↓
PRE-PROD
↓
PROD
Parece organizado.
Até descobrirmos que dezenas de desenvolvedores compartilham os mesmos ambientes.
Na segunda-feira:
SIT reservado para Projeto A.
Terça:
indisponível para manutenção.
Quarta:
Projeto B executando regressão.
Quinta:
dados inconsistentes.
Sexta:
release freeze.
Nosso programador COBOL pensa:
Posso testar na próxima semana?
Aqui surge um princípio fundamental:
Ambiente de teste também é recurso computacional.
E recurso computacional pode ser provisionado, configurado, versionado e automatizado.
Essa mudança de pensamento é enorme.
🗄️ CAPÍTULO 4 — Db2: TER O BANCO NÃO SIGNIFICA TER O TESTE
Wallace consegue finalmente um ambiente Db2.
Ele comemora.
Gromit aponta para a tabela CLIENTE.
Há três clientes.
Todos ativos.
Nosso programa precisa testar:
CLIENTE NORMAL
CLIENTE BLOQUEADO
CLIENTE INEXISTENTE
CLIENTE VIP
CONTA ENCERRADA
LIMITE EXCEDIDO
SALDO NEGATIVO
CARTÃO EXPIRADO
CARTÃO ROUBADO
TRANSAÇÃO DUPLICADA
Temos ambiente.
Não temos dados úteis.
Essa diferença é fundamental.
Um banco de desenvolvimento com milhões de registros inúteis pode ser pior para QA do que alguns milhares cuidadosamente preparados.
E simplesmente copiar produção cria outro conjunto de problemas:
LGPD
PCI DSS
dados pessoais
dados financeiros
segredos
volume
permissões
mascaramento
retenção
auditoria
Portanto surge uma disciplina importantíssima:
Test Data Management
🧩 CAPÍTULO 5 — NÃO COPIE APENAS A TABELA CUSTOMER
Suponha:
CUSTOMER
│
├── ACCOUNT
│ ├── TRANSACTION
│ └── PAYMENT
│
└── CARD
└── AUTHORIZATION
Você seleciona 100 clientes.
Excelente.
Mas se copiar somente CUSTOMER, sua aplicação pode procurar contas que não existem.
Se copiar ACCOUNT, mas esquecer TRANSACTION, outro teste quebra.
Se copiar CARD, talvez precise preservar relações com autorizações.
Portanto um bom subconjunto de dados precisa manter consistência referencial e semântica.
Não queremos apenas dados.
Queremos uma pequena representação coerente do mundo.
🌳 CAPÍTULO 6 — IMS: AGORA GROMIT DESCOBRIU UMA ÁRVORE
Db2 normalmente nos faz pensar em tabelas.
IMS DB introduz outro modelo mental.
Imagine:
CUSTOMER
│
├── ACCOUNT
│ ├── TRANSACTION
│ └── PAYMENT
│
└── ADDRESS
Aqui podemos estar lidando com estruturas hierárquicas.
O programador COBOL pode encontrar operações DL/I como:
GU
GN
GNP
De maneira simplificada:
GU — Get Unique
Procure algo específico.
GN — Get Next
Continue navegando.
GNP — Get Next within Parent
Continue dentro de determinado contexto hierárquico.
Mas IMS não termina no banco.
Podemos encontrar:
IMS DB
IMS TM
DL/I
DBD
PSB
PCB
SSA
IMS Connect
Para um iniciante, isso parece uma sopa de siglas.
Wallace provavelmente tentaria resolver construindo uma máquina de sopa.
Gromit abriria o manual.
A lição é outra:
Quando virtualizamos ou reproduzimos um ambiente, precisamos compreender suas dependências.
Copiar alguns segmentos pode não reproduzir corretamente a situação necessária ao teste.
🏪 CAPÍTULO 7 — CICS: NENHUM PROGRAMA É UMA ILHA
Nosso programa executa:
EXEC CICS LINK
PROGRAM('PGM002')
COMMAREA(WS-COMMAREA)
END-EXEC.
Parece apenas uma chamada.
Mas PGM002 pode acessar Db2.
Depois MQ.
Depois outro programa.
Depois uma API.
Temos:
PGM001
│
▼
PGM002
│
├── Db2
│
├── MQ
│
└── PGM003
│
▼
API
Para testar PGM001, precisamos realmente de tudo isso?
Às vezes sim.
Mas nem sempre.
E aí Wallace encontra uma nova caixa de ferramentas.
🎭 CAPÍTULO 8 — MOCKS, STUBS E SERVICE VIRTUALIZATION
Imagine que PGM001 precise chamar um serviço antifraude.
Em produção:
COBOL
↓
CICS
↓
MQ
↓
ANTIFRAUDE
Mas nosso objetivo atual é testar somente uma regra COBOL.
Podemos substituir temporariamente uma dependência por um comportamento controlado.
Por exemplo:
COBOL
↓
SERVIÇO VIRTUAL
↓
RESPOSTA CONTROLADA
O serviço virtual pode responder:
{
"riskScore": 87,
"decision": "REVIEW"
}
Agora conseguimos testar nosso programa sem depender do sistema antifraude real.
Melhor ainda.
Podemos ordenar:
Agora devolva timeout.
Depois:
Agora devolva erro.
Depois:
Agora envie resposta inválida.
Assim podemos criar:
SUCCESS
TIMEOUT
DENIED
INVALID
DUPLICATE
UNAVAILABLE
Isso é extraordinariamente útil.
💣 CAPÍTULO 9 — GROMIT DESCOBRE QUE QUEBRAR O SISTEMA TAMBÉM É TESTAR
Testar não significa verificar apenas:
ENTRADA CORRETA → RESULTADO CORRETO
Precisamos descobrir:
O QUE ACONTECE QUANDO ALGO DÁ ERRADO?
Imagine:
TRANSACTION
│
▼
CICS
│
▼
COBOL
│
├── Db2 → SQLCODE -911
│
├── MQ → problema na fila
│
└── API → HTTP 503
Como o programa reage?
Faz rollback?
Tenta novamente?
Duplica uma transação?
Perde informação?
Produz mensagem compreensível?
Grava evidência suficiente?
Isso nos leva aos testes negativos.
Eles são particularmente valiosos porque muitos incidentes graves não acontecem durante o happy path.
Acontecem nas exceções.
🥚 EASTER EGG — 03:17
Wallace finalmente termina sua máquina.
Relógio:
03:17.
Gromit olha preocupado.
A API retorna timeout.
O MQ começa a acumular mensagens.
Db2 apresenta contenção.
CICS espera.
Wallace pergunta:
— Por que ninguém testou isso?
Porque todos testaram:
HTTP 200
SQLCODE 0
MQ OK
CICS OK
Ninguém perguntou:
E se três coisas falharem juntas?
O incidente das 03:17 nasceu exatamente no lugar onde terminava o happy path.
⚡ CAPÍTULO 10 — E SE O DESENVOLVEDOR PUDESSE PEDIR UM MAINFRAME?
Aqui chegamos a uma mudança conceitual enorme.
Modelo tradicional:
DEVELOPER
↓
TICKET
↓
SYSPROG
↓
DBA
↓
SECURITY
↓
CICS ADMIN
↓
WAIT
↓
ENVIRONMENT
Agora imagine:
DEVELOPER
↓
SELF-SERVICE
↓
TEMPLATE APROVADO
↓
PROVISION
↓
AMBIENTE DEV/TEST
Não estamos falando de entregar produção para o desenvolvedor.
Estamos falando de criar ambientes isolados e governados para desenvolvimento e testes.
O conceito pode incluir tecnologias de virtualização e ofertas destinadas a proporcionar ambientes z/OS de desenvolvimento e teste de maneira muito mais rápida.
A pergunta deixa de ser:
Qual LPAR está livre?
E passa a ser:
Qual configuração de ambiente eu preciso?
Essa mudança é gigantesca.
🧀 CAPÍTULO 11 — WALLACE INVENTA O MAINFRAME DESCARTÁVEL
Não descarte o IBM Z!
Calma.
Estamos falando do ambiente de desenvolvimento.
Imagine:
CREATE
↓
TEST
↓
COLLECT EVIDENCE
↓
DESTROY
Ou:
TEMPLATE
↓
ENVIRONMENT A
ENVIRONMENT B
ENVIRONMENT C
Cada squad pode trabalhar com isolamento muito maior.
Isso nos aproxima do conceito de ambientes efêmeros.
O ambiente nasce para cumprir determinada finalidade.
Executamos os testes.
Coletamos logs e evidências.
Depois ele pode ser removido.
Amanhã outro ambiente é criado novamente a partir de uma configuração conhecida.
🧬 CAPÍTULO 12 — INFRASTRUCTURE AS CODE ENCONTRA O COBOL
Wallace adora infraestrutura.
Especialmente se possuir alavancas.
DevOps prefere arquivos declarativos, APIs e automação.
Conceitualmente:
environment:
zos: enabled
cics: enabled
db2: enabled
ims: enabled
mq: enabled
Não estou dizendo que essa configuração fictícia cria magicamente um ambiente real.
Ela ilustra a ideia.
A infraestrutura deixa de existir apenas como conhecimento informal:
Pergunte ao José porque ele sabe configurar.
E passa a ser descrita de maneira reproduzível.
Isso gera:
padronização
repetibilidade
auditabilidade
automação
velocidade
🚀 CAPÍTULO 13 — RAPID PROTOTYPING
Agora alguém propõe:
Vamos expor esta transação CICS através de REST.
Antes:
REUNIÃO
↓
TICKET
↓
AMBIENTE
↓
CONFIGURAÇÃO
↓
TESTE
Com um laboratório disponível:
CICS
↓
COBOL
↓
Db2
↓
API
↓
JSON
↓
POSTMAN
Podemos experimentar.
Não funcionou?
Reconfiguramos.
Quebrou?
Restauramos.
A ideia é importante porque experimentação precisa ser barata.
Quando cada tentativa exige uma semana de burocracia, as pessoas naturalmente experimentam menos.
🔬 CAPÍTULO 14 — SHIFT LEFT NÃO É EMPURRAR UMA CAIXINHA NO POWERPOINT
Você provavelmente já viu:
DEV → TEST → QA → UAT → PROD
E alguém desenhou uma seta enorme:
← SHIFT LEFT
Pronto.
Transformação digital concluída.
Não.
Shift left significa descobrir problemas mais cedo.
Idealmente:
DEV
↓
UNIT TEST
↓
INTEGRATION TEST
↓
SYSTEM TEST
↓
UAT
↓
PROD
Quanto mais cedo encontramos:
erro de lógica
SQL incorreto
dependência quebrada
contrato incompatível
timeout
problema de dados
menor tende a ser o custo de correção.
Encontrar um erro cinco minutos depois de escrevê-lo é muito diferente de encontrá-lo durante uma janela de implantação.
Ou às 03:17.
🏭 CAPÍTULO 15 — GROMIT CONSTRÓI UM PIPELINE
Agora tudo começa a se encaixar.
git push
│
▼
BUILD
│
▼
STATIC ANALYSIS
│
▼
UNIT TEST
│
▼
PROVISION ENVIRONMENT
│
▼
DEPLOY
│
▼
TEST DATA
│
▼
INTEGRATION TEST
│
▼
REGRESSION
│
▼
EVIDENCE
│
▼
PROMOTION
Perceba uma diferença importantíssima.
O ambiente entrou no pipeline.
Antes o pipeline dizia:
Aqui está o executável.
Agora ele pode dizer:
Aqui está o software, o ambiente onde foi validado, os testes executados e suas evidências.
Isso é muito mais poderoso.
🗃️ CAPÍTULO 16 — MAS E O Db2?
Aqui existe uma armadilha clássica.
Aplicação:
APP V1
Banco:
SCHEMA V1
Nova aplicação:
APP V2
Mas ela depende de:
SCHEMA V2
Portanto DevOps não pode cuidar apenas do .CBL.
Precisamos pensar em:
DDL
SQL
BIND
PACKAGE
PLAN
SCHEMA
TEST DATA
MIGRATION
ROLLBACK
Banco de dados também possui ciclo de vida.
Isso é Database DevOps.
E atenção:
automação não significa:
Todo mundo pode executar ALTER em produção.
É justamente o contrário.
Uma boa automação transforma regras em guardrails.
🔐 CAPÍTULO 17 — WALLACE QUASE REMOVE O RACF
Wallace vê todos esses processos automatizados.
— Excelente! Agora todo mundo pode fazer tudo!
Gromit olha horrorizado.
Não.
Self-service não significa ausência de controle.
Continuamos precisando de:
RACF
SAF
least privilege
segregation of duties
audit trail
approvals
data protection
logging
evidence
A diferença é:
Antes
controle = pessoas executando tarefas repetitivas
Depois
controle = políticas + automação + evidência
Esse é um ponto essencial.
DevOps não elimina governança.
DevOps pode transformar governança em código e processos repetíveis.
🧠 CAPÍTULO 18 — MODERNIZAR NÃO SIGNIFICA JOGAR O COBOL FORA
Talvez esta seja a maior lição da aventura.
Durante anos ouvimos modernização descrita assim:
COBOL
↓
LEGACY
↓
REWRITE
↓
CLOUD
Mas existe outra possibilidade:
COBOL
CICS
Db2
IMS
MQ
↓
MODERN DEVELOPMENT EXPERIENCE
Podemos manter aplicações extremamente valiosas e modernizar tudo ao redor:
Git
CI/CD
APIs
automated testing
test virtualization
observability
DevSecOps
Infrastructure as Code
automated provisioning
modern IDEs
Isso é modernização sem obrigatoriamente reescrever tudo.
🔭 CAPÍTULO 19 — O MAINFRAME NÃO É MAIS APENAS O DESTINO
Esta é uma mudança profunda.
No modelo antigo:
PIPELINE
↓
MAINFRAME
O mainframe era o lugar onde o resultado finalmente chegava.
No modelo moderno:
PIPELINE
│
┌──────────┼──────────┐
▼ ▼ ▼
BUILD TEST ENVIRONMENT
│ │ │
└──────────┼──────────┘
▼
z/OS
O próprio ambiente mainframe participa do ciclo.
Provisionamento.
Build.
Teste.
Deploy.
Validação.
Evidência.
Tudo pode integrar uma cadeia de automação.
📊 CAPÍTULO 20 — O DASHBOARD QUE WALLACE ESQUECEU
Estamos acostumados a observar:
CPU
MSU
I/O
latência
throughput
availability
response time
Tudo correto.
Mas DevOps precisa olhar também:
lead time
deployment frequency
change failure
recovery time
test execution time
environment provisioning time
developer waiting time
Imagine descobrir:
Lead time ............... 120 horas
Programando ............. 12
Testando ................ 10
Esperando ambiente ...... 38
Esperando dados ......... 20
Esperando deploy ........ 25
Esperando aprovação ..... 15
Temos:
TRABALHO = 22 horas
ESPERA = 98 horas
Wallace estava tentando construir uma máquina para fazer COBOL 30% mais rápido.
Gromit apontou para as 98 horas.
Aí Wallace finalmente entendeu.
🛠️ CAPÍTULO 21 — PASSO A PASSO PARA COMEÇAR
Se você está começando em COBOL, não tente construir toda essa arquitetura amanhã.
Comece pequeno.
PASSO 1 — Mapeie uma aplicação
Descubra:
COBOL
↓
CICS?
↓
Db2?
↓
IMS?
↓
MQ?
↓
API?
PASSO 2 — Mapeie dependências
Pergunte:
Para testar este programa, do que realmente preciso?
PASSO 3 — Separe teste unitário de integração
Nem todo teste precisa do universo inteiro.
PASSO 4 — Identifique dados necessários
Crie casos:
NORMAL
BOUNDARY
INVALID
ERROR
TIMEOUT
DUPLICATE
PASSO 5 — Automatize o build
Compile sempre da mesma maneira.
PASSO 6 — Automatize testes repetitivos
Se alguém executa exatamente os mesmos passos diariamente, existe um ótimo candidato à automação.
PASSO 7 — Crie evidências
Guarde:
build
versão
logs
resultado
dados
timestamp
PASSO 8 — Meça espera
Talvez o maior gargalo não esteja onde todos imaginavam.
PASSO 9 — Virtualize dependências caras
Nem todo sistema externo precisa estar presente em todo teste.
PASSO 10 — Automatize ambientes gradualmente
Comece pelo que produz maior espera.
💡 CAPÍTULO 22 — CURIOSIDADES PARA O PADAWAN COBOL
Primeira curiosidade:
COBOL ser uma linguagem antiga não significa que todo processo ao redor dele precise continuar antigo.
Segunda:
Um programa de 200 linhas pode depender de uma arquitetura com dezenas de componentes.
Terceira:
Mais dados de teste não significa necessariamente melhores testes.
Quarta:
Conseguir provocar um erro propositalmente é uma habilidade extremamente valiosa de QA.
Quinta:
Automação não serve apenas para fazer alguma coisa mais rapidamente.
Ela também serve para fazer alguma coisa da mesma maneira todas as vezes.
Sexta:
Ambiente reproduzível é documentação executável.
Se conseguimos reconstruí-lo automaticamente, sabemos muito mais sobre ele do que quando sua configuração vive apenas na cabeça de algumas pessoas.
🧀 EPÍLOGO — WALLACE FINALMENTE APERTA O BOTÃO
Depois de dias trabalhando, Wallace apresenta sua nova invenção.
Uma máquina gigantesca ocupa toda a garagem.
Gromit observa.
Wallace aperta o botão.
Engrenagens começam a girar.
Git
↓
Build
↓
COBOL
↓
Test
↓
Environment
↓
CICS
↓
Db2
↓
IMS
↓
MQ
↓
Regression
↓
Evidence
Uma pequena luz verde acende.
Na tela:
BUILD SUCCESSFUL
UNIT TESTS: PASS
INTEGRATION: PASS
NEGATIVE TESTS: PASS
REGRESSION: PASS
ENVIRONMENT DESTROYED
Wallace sorri.
— Pronto, Gromit! Automatizamos o mainframe!
Gromit aponta para outra tela:
AVERAGE DEVELOPER WAITING TIME
BEFORE: 31 HOURS
AFTER: 47 MINUTES
Wallace finalmente percebe que aquela era a informação realmente importante.
Eles não tornaram o COBOL moderno.
O COBOL já estava fazendo aquilo para que havia sido criado.
Não substituíram Db2.
Não destruíram IMS.
Não aposentaram CICS.
Não migraram tudo para alguma tecnologia da moda apenas para poder colocar a palavra "modernização" num PowerPoint.
Eles fizeram algo talvez mais inteligente.
Modernizaram o caminho entre a ideia do programador e a evidência de que aquela ideia funciona.
Essa é uma das grandes fronteiras do DevOps no mainframe.
O problema não é necessariamente:
"Como fazemos COBOL parecer uma aplicação cloud?"
Talvez a pergunta correta seja:
"Como permitimos que uma aplicação COBOL, CICS, IMS ou Db2 participe de uma experiência moderna de desenvolvimento sem destruir as qualidades que fizeram esse ecossistema sobreviver por décadas?"
E a resposta passa por:
AUTOMAÇÃO
+
SELF-SERVICE
+
TEST DATA
+
SERVICE VIRTUALIZATION
+
SHIFT LEFT
+
CI/CD
+
AMBIENTES REPRODUZÍVEIS
+
SEGURANÇA
+
OBSERVABILIDADE
+
EVIDÊNCIA
Wallace guarda as ferramentas.
Gromit prepara o chá.
O programador COBOL faz um commit.
O pipeline começa a trabalhar.
Nenhum chamado precisa ser aberto apenas para descobrir se uma pequena alteração funciona.
E em algum lugar dentro do datacenter, silenciosamente, o relógio muda para:
03:16
Gromit olha para ele.
Espera.
03:17
Nada acontece.
Nenhum pager toca.
Nenhuma fila explode.
Nenhum operador corre.
Nenhum programador é acordado.
Gromit toma mais um gole de chá.
Talvez aquele tenha sido o melhor teste de todos.
☕ MORAL DO CAFÉ
Modernizar mainframe não significa necessariamente substituir aquilo que funciona.
Às vezes significa eliminar tudo aquilo que obriga pessoas altamente qualificadas a ficarem esperando.
Porque existe uma diferença enorme entre:
MAINFRAME LEGACY
e:
PROCESSO LEGACY
Não confunda os dois.
O IBM Z pode processar bilhões de transações.
CICS pode responder em frações de segundo.
Db2 pode atender workloads gigantescos.
IMS pode sustentar aplicações críticas durante décadas.
E mesmo assim...
o programador pode ficar três dias esperando um ambiente de teste.
Nesse caso, meu jovem padawan COBOL, talvez a coisa mais lenta do sistema não esteja rodando no mainframe.
Talvez esteja rodando no processo.
E é justamente aí que Wallace & Gromit começariam a construir a próxima máquina.
Welcome to the Mainframe. ☕🧀
