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

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

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. ☕🧀

Translate

sexta-feira, 3 de fevereiro de 2023