 |
| Bellacosa Mainframe e o zos connect |
☕ Um Café no Bellacosa Mainframe
24 Horas no Bellacosa Mainframe: Jack Bauer, COBOL e a API que precisava entrar no CICS antes que o relógio chegasse a zero
⏱️ z/OS Connect, REST, JSON, OpenAPI, CICS, IMS, Db2, RACF, SAF, zIIP, OpenTelemetry e o estranho caso em que Jack Bauer descobriu que reescrever 35 anos de COBOL levaria um pouco mais de 24 horas
03:17:42
O telefone toca.
Isso nunca é bom.
Especialmente quando você trabalha com mainframe.
Do outro lado da linha alguém pronuncia aquelas palavras capazes de provocar mais medo em um programador COBOL do que S0C7, SOC4, deadlock no Db2 e café descafeinado juntos:
— Precisamos modernizar o legado.
Silêncio.
O relógio aparece na tela.
03:17:43
03:17:44
03:17:45
Você olha para o terminal 3270.
O CICS está funcionando.
O Db2 está funcionando.
O programa COBOL que consulta clientes está funcionando há décadas.
Milhões de transações passaram por ele.
Então surge a pergunta que deveria ser feita antes de qualquer projeto de modernização:
Se funciona, por que exatamente queremos reescrevê-lo?
Do outro lado alguém responde:
— Porque precisamos acessar isso pelo aplicativo mobile.
Jack Bauer entra na sala.
Olha para o COBOL.
Olha para o arquiteto.
Olha para o relógio.
E diz:
— Então vocês não precisam reescrever o COBOL. Precisam de uma API.
TIC. TIC. TIC. TIC.
Bem-vindo ao mundo do IBM z/OS Connect.
Pegue o café.
Temos 24 horas para colocar REST, JSON e OpenAPI diante de um programa COBOL que nasceu quando ninguém imaginava que um telefone serviria para fazer transferências bancárias.
⏱️ 04:00 — O problema nunca foi necessariamente o COBOL
Imagine que nosso banco fictício possui um programa chamado:
CLIENTE
Ele recebe:
01 CLIENTE-REQUEST.
05 CLIENTE-ID PIC 9(09).
E devolve:
01 CLIENTE-RESPONSE.
05 CLIENTE-NOME PIC X(40).
05 CLIENTE-LIMITE PIC 9(09)V99.
05 CLIENTE-STATUS PIC X(01).
Nada particularmente revolucionário.
Talvez esse programa execute dentro do CICS e consulte Db2.
Durante décadas alguma aplicação tradicional soube perfeitamente como conversar com ele.
Então chega uma equipe responsável pelo novo aplicativo mobile.
Ela não sabe o que é:
COMMAREA
EBCDIC
PIC X
PIC 9
COMP
COMP-3
EXEC CICS LINK
TSO
ISPF
3270
E existe uma boa notícia:
ela provavelmente não precisa saber.
A aplicação mobile quer algo como:
GET /clientes/123456789
e espera receber:
{
"id": 123456789,
"nome": "JOAO DA SILVA",
"limite": 15000.00,
"status": "ATIVO"
}
Aqui aparece o problema arquitetural.
Não temos necessariamente um sistema antigo incapaz de executar a regra de negócio.
Temos dois mundos falando idiomas diferentes.
De um lado:
HTTP
REST
JSON
OpenAPI
OAuth
JWT
Cloud
Mobile
Microservices
Do outro:
COBOL
CICS
IMS
Db2
copybooks
SAF
RACF
Jack Bauer olha para os dois lados.
— Precisamos de um tradutor.
É aqui que entra o IBM z/OS Connect.
⏱️ 05:00 — Afinal, o que diabos é z/OS Connect?
Para um COBOLzeiro começando agora, eu gosto desta definição:
IBM z/OS Connect é uma camada de integração que permite disponibilizar recursos e aplicações do z/OS através de APIs REST e também permite que aplicações z/OS consumam APIs externas.
Leia novamente a última parte.
Porque ela é frequentemente esquecida.
Não existe apenas:
MUNDO MODERNO
│
▼
API
│
▼
MAINFRAME
Também pode existir:
MAINFRAME
│
▼
API
│
▼
MUNDO EXTERNO
Esses dois caminhos nos levam a dois conceitos fundamentais:
API PROVIDER
API REQUESTER
Guarde esses nomes.
Jack Bauer certamente guardaria.
Ele só não teria tempo de anotá-los.
⏱️ 06:00 — API Provider: quando o mundo bate à porta do CICS
O API Provider resolve aproximadamente este cenário:
Mobile
│
Web
│
Cloud
│
▼
REST / JSON
│
▼
z/OS Connect
│
▼
CICS / IMS / Db2
│
▼
COBOL
Imagine novamente nosso programa de consulta de clientes.
O aplicativo envia:
GET /clientes/123456789
z/OS Connect recebe essa requisição.
Ele possui informações suficientes para entender que aquela operação está relacionada a determinado serviço no mainframe.
O JSON pode ser transformado para a estrutura esperada pelo programa.
O programa COBOL executa.
Depois acontece o caminho inverso:
COBOL
│
estrutura tradicional
│
▼
z/OS Connect
│
JSON
▼
aplicação
Perceba a beleza arquitetural.
O COBOL não precisa acordar numa segunda-feira e dizer:
“A partir de hoje sou desenvolvedor REST.”
Ele continua fazendo aquilo para o qual foi criado.
⏱️ 07:00 — Não estamos transformando COBOL em REST
Essa diferença parece pequena, mas é gigantesca.
Uma simplificação perigosa seria dizer:
COBOL → REST
Não.
O programa COBOL continua sendo COBOL.
Estamos criando uma interface moderna para uma capacidade existente.
Pense assim:
CONTRATO
OpenAPI
│
▼
REST / JSON
│
▼
z/OS Connect
│
mapping / routing
│
▼
estrutura COBOL
│
▼
CICS
│
▼
COBOL
Isso nos leva a uma das ideias mais importantes deste café:
Modernização não significa necessariamente reescrita.
Às vezes modernizar significa tornar acessível aquilo que já funciona.
⏱️ 08:00 — A reunião em que alguém quer reescrever tudo
Você conhece a cena.
Sala de reunião.
PowerPoint.
Café ruim.
Alguém aponta para um desenho cheio de caixas coloridas e diz:
— Temos que eliminar o legado.
Pergunte:
— Por quê?
Talvez a resposta seja:
— Porque precisamos disponibilizar consulta de saldo no celular.
Mas o programa de consulta de saldo funciona?
— Sim.
Está performando?
— Sim.
É confiável?
— Sim.
Possui décadas de regras de negócio?
— Sim.
Então talvez o problema não seja:
CONSULTAR-SALDO
Talvez o problema seja somente:
COMO ACESSAR CONSULTAR-SALDO
São problemas completamente diferentes.
Reescrever pode ser necessário em alguns casos.
Mas não deveria ser automaticamente sinônimo de modernização.
⏱️ 09:00 — O tesouro escondido dentro daquele COBOL feio
Aqui mora uma coisa que os novatos precisam aprender cedo.
Você abre um programa de 15 mil linhas.
Encontra:
IF WS-CODIGO = 37
AND WS-TIPO = 'X'
AND WS-DATA < 19981231
MOVE 'S' TO WS-EXCECAO
END-IF
Sua primeira reação pode ser:
— Que porcaria é essa?
Calma.
Talvez esse IF exista porque:
uma lei mudou;
houve uma fusão bancária;
determinado produto foi descontinuado;
aconteceu um incidente em produção;
alguma regra fiscal antiga precisa continuar sendo respeitada;
existem contratos históricos;
alguém descobriu uma exceção em 1999.
Código legado não contém apenas instruções.
Ele contém arqueologia empresarial.
Às vezes aquelas linhas horrorosas são conhecimento institucional fossilizado.
O perigo da reescrita é acreditar que compreendemos tudo simplesmente porque entendemos a sintaxe.
⏱️ 10:00 — OpenAPI entra na CTU
O próximo personagem da história é o OpenAPI.
Podemos pensar nele como um contrato descrevendo nossa API.
Por exemplo:
paths:
/clientes/{id}:
get:
summary: Consulta cliente
parameters:
- name: id
in: path
required: true
Ele documenta coisas como:
endpoint
método HTTP
parâmetros
estrutura de entrada
estrutura de saída
códigos de resposta
Isso permite que diferentes equipes compartilhem um contrato comum.
O desenvolvedor mobile não precisa perguntar:
— Qual é o offset do campo CLIENTE-ID na COMMAREA?
Ele pergunta:
— Qual é o contrato da API?
Essa mudança cultural é enorme.
⏱️ 11:00 — O copybook encontra JSON
Agora chegamos a uma das partes mais interessantes.
No mainframe podemos encontrar:
01 CUSTOMER-DATA.
05 CUSTOMER-ID PIC 9(09).
05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-BALANCE PIC S9(9)V99 COMP-3.
No universo web:
{
"customerId": 12345,
"customerName": "MARIA",
"customerBalance": 3450.25
}
Veja o abismo cultural.
O frontend não quer saber que COMP-3 existe.
Aliás, se você explicar packed decimal durante a daily do React, talvez seja expulso da reunião.
O z/OS Connect pode participar justamente da transformação entre esses formatos.
Conceitualmente:
JSON
↓
mapping
↓
estrutura nativa
↓
COBOL
↓
estrutura nativa
↓
mapping
↓
JSON
E isso é maravilhoso porque preserva uma regra fundamental:
não obrigue todas as aplicações da empresa a conhecer os detalhes internos umas das outras.
⏱️ 12:00 — API Requester: plot twist!
Metade da temporada passou.
Hora da reviravolta.
Até agora o mundo estava chamando o mainframe.
Mas e se o COBOL precisar chamar o mundo?
Imagine um programa bancário precisando consultar uma cotação externa.
A API moderna oferece:
GET /exchange/USD/BRL
Resposta:
{
"currency": "USD",
"rate": 5.42
}
Agora temos:
COBOL
│
▼
z/OS Connect
│
▼
REST / JSON
│
▼
API EXTERNA
É o API Requester.
Isso muda muito a percepção do mainframe.
Ele deixa de ser apenas:
“a máquina que os outros sistemas chamam”.
Também pode tornar-se consumidor de serviços modernos.
⏱️ 13:00 — Provider e Requester juntos
Agora nosso desenho fica muito mais interessante:
API PROVIDER
Mobile / Cloud ─── REST ───► z/OS Connect
│
▼
CICS / IMS / Db2
│
▼
COBOL
│
│
API REQUESTER
│
▼
REST API
│
▼
Serviço externo
Isso é integração bidirecional.
O mainframe deixa de parecer uma ilha.
Ele passa a participar da arquitetura distribuída da empresa.
⏱️ 14:00 — Mas espere: INTERNET → COBOL?
Jack Bauer para no corredor.
Olha para você.
— Você colocou a internet na frente da minha transação bancária?
Boa pergunta.
Porque API sem segurança é apenas uma maneira moderna de criar um incidente.
Aqui entram mecanismos como:
TLS
JWT
SAF
RACF
autenticação
autorização
controle por operação
A ideia não deveria ser:
INTERNET
│
▼
COBOL
Mas algo conceitualmente muito mais parecido com:
REQUEST
│
▼
TLS
│
▼
AUTENTICAÇÃO
│
▼
AUTORIZAÇÃO
│
▼
z/OS Connect
│
▼
SAF / RACF
│
▼
RECURSO
O velho castelo ganhou uma porta moderna.
Não removemos os guardas.
⏱️ 15:00 — Autorização granular
Existe uma diferença importante entre:
VAGNER PODE ACESSAR A API
e:
VAGNER PODE EXECUTAR ESTA OPERAÇÃO?
Considere:
GET /contas/123
versus:
POST /transferencias
Consultar saldo e transferir dinheiro são operações completamente diferentes.
Em segurança empresarial queremos aproximar-nos do princípio:
least privilege
Ou seja:
conceder apenas aquilo que determinado usuário ou identidade realmente necessita.
Isso também mostra por que API modernization não é simplesmente instalar um servidor HTTP na LPAR e comemorar.
Existe arquitetura por trás.
⏱️ 16:00 — O telefone toca novamente
— Jack, a API está lenta.
Pronto.
Começou a produção.
Agora precisamos responder:
onde estão os 800 milissegundos?
Pode ser:
Mobile
↓
rede
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
Sem observabilidade, todos apontam para o vizinho.
O pessoal web:
— Mainframe está lento.
O mainframe:
— Aqui está normal.
A rede:
— Não é comigo.
O DBA:
— A query levou 2 ms.
E assim nasce uma war room de oito horas.
⏱️ 17:00 — OpenTelemetry encontra SMF
O universo moderno fala muito em:
metrics
logs
traces
OpenTelemetry
Prometheus
Grafana
O mainframe possui sua própria tradição de observabilidade:
SMF
RMF
CICS statistics
CICS monitoring
logs
z/OS Connect vive justamente numa região onde esses universos podem se encontrar.
E existe algo poeticamente maravilhoso nisso.
A turma cloud-native descobre distributed tracing.
O velho sysprog toma um gole de café e responde:
— Interessante. Nós também gostamos de saber para onde foi nosso CPU desde antes de você nascer.
Easter egg número 1: nunca diga a um sysprog veterano que observabilidade foi inventada junto com Kubernetes.
Você poderá assistir a uma palestra improvisada de quatro horas sobre SMF.
⏱️ 18:00 — E aquele papo de 99% no zIIP?
Aqui precisamos impedir um pequeno atentado conceitual.
Você poderá ler que mais de 99% do processamento relacionado ao z/OS Connect pode ser elegível para zIIP em determinadas condições de execução nativa.
Então alguém inevitavelmente concluirá:
“Excelente! 99% do meu COBOL vai para zIIP!”
NÃO.
Jack Bauer bate na mesa.
O relógio para durante dois segundos dramáticos.
A afirmação refere-se ao processamento do z/OS Connect, não magicamente a toda carga que existe atrás dele.
Pense:
HTTP processing
JSON transformation
z/OS Connect runtime
│
└────► alta elegibilidade zIIP
Depois:
CICS
COBOL
Db2
outros componentes
possuem suas próprias características e regras.
Esse detalhe é fundamental quando alguém começa a transformar arquitetura técnica em planilha financeira.
⏱️ 19:00 — Containers chegam ao mainframe
Outra surpresa para quem pensa que mainframe significa somente:
JCL + STARTED TASK + 3270
O ecossistema moderno do z/OS Connect também contempla deployment containerizado em cenários suportados.
Entram conceitos como:
OCI containers
OpenShift
z/OS Container Extensions
IBM Z
Ou seja, podemos encontrar arquiteturas muito diferentes.
Mas cuidado.
Não conclua:
“Então qualquer componente pode ser colocado em qualquer lugar.”
Características, features e restrições podem variar conforme o modelo de implantação e versão.
Regra do velho Bellacosa:
Antes de transformar um slide de arquitetura em implementação, leia a documentação da versão que realmente será instalada.
Essa frase evita mais incidentes que muita ferramenta cara.
⏱️ 20:00 — E IBM MQ?
Aqui mora outra armadilha interessante.
Em material introdutório é comum vermos juntos:
CICS
IMS
Db2
IBM MQ
Mas suporte depende da feature e geração utilizada.
O ecossistema histórico do z/OS Connect possui diferenças entre gerações e recursos.
Portanto:
“z/OS Connect suporta X” não é uma informação completa sem perguntar versão, feature e cenário.
Isso vale para MQ e praticamente qualquer produto empresarial com anos de evolução.
Easter egg número 2: em mainframe, a resposta para “isso é suportado?” frequentemente começa com:
“Depende do release.”
Se alguém responder imediatamente “sim” sem perguntar versão, comece a ficar desconfiado.
⏱️ 21:00 — API Management não é z/OS Connect
Outra confusão clássica.
Podemos ter:
CONSUMIDORES
│
▼
API MANAGEMENT
│
▼
z/OS Connect
│
▼
CICS / IMS / Db2
API Management pode cuidar de coisas como:
catálogo
lifecycle
analytics
policies
plans
governança
consumidores
z/OS Connect possui foco específico na integração entre APIs e recursos z/OS.
São papéis complementares.
Pense num aeroporto.
API Management administra boa parte da relação com passageiros, rotas, regras e portas.
z/OS Connect é o intérprete altamente especializado que sabe conversar com aquela aeronave de 300 toneladas chamada CICS.
⏱️ 22:00 — Passo a passo mental para criar nossa API
Vamos montar uma operação conceitual.
Temos:
Programa: CLIENTE
Ambiente: CICS
Entrada: CLIENTE-ID
Saída:
CLIENTE-NOME
CLIENTE-LIMITE
CLIENTE-STATUS
Passo 1 — Descubra a capacidade de negócio
Não comece pelo REST.
Pergunte:
O que esse programa realmente faz?
Resposta:
CONSULTAR CLIENTE
Passo 2 — Entenda entrada e saída
Localize copybooks e estruturas.
05 CLIENTE-ID PIC 9(09).
Saída:
05 CLIENTE-NOME PIC X(40).
05 CLIENTE-LIMITE PIC 9(09)V99.
05 CLIENTE-STATUS PIC X.
Passo 3 — Pense na API como contrato
Por exemplo:
GET /clientes/{id}
Passo 4 — Defina representação externa
{
"id": 123,
"nome": "MARIA",
"limite": 8000.00,
"status": "ATIVO"
}
Passo 5 — Configure o mapping
Conceitualmente:
id
↕
CLIENTE-ID
nome
↕
CLIENTE-NOME
limite
↕
CLIENTE-LIMITE
Passo 6 — Configure segurança
Pergunte:
Quem chama?
Como autentica?
Qual identidade chega ao z/OS?
Qual operação pode executar?
Qual recurso SAF protege?
Passo 7 — Teste
Não teste somente:
HTTP 200
Teste também:
dados inválidos
cliente inexistente
timeout
indisponibilidade CICS
falha Db2
credencial inválida
usuário sem autorização
campos limites
concorrência
volume
Passo 8 — Observe
Descubra antes da produção:
latência
throughput
CPU
zIIP
erros
timeouts
dependências
Passo 9 — Documente
OpenAPI não deveria ser decoração.
É parte do contrato entre equipes.
Passo 10 — Só então coloque Jack Bauer de plantão
Preferencialmente não coloque.
Se precisarmos dele, alguma coisa já deu muito errado.
⏱️ 23:00 — O verdadeiro significado de modernização
Agora chegamos à parte que considero mais importante.
Existe uma narrativa confortável:
VELHO = RUIM
NOVO = BOM
Computação real não funciona assim.
Um programa COBOL criado em 1992 pode estar executando uma regra crítica perfeitamente.
Uma aplicação criada há seis meses em Kubernetes pode ser uma catástrofe arquitetural.
Idade não é qualidade.
Tecnologia nova não é automaticamente modernização.
A pergunta deveria ser:
Que problema de negócio estamos tentando resolver?
Se o problema for:
“Precisamos disponibilizar capacidades do mainframe para novos canais.”
Talvez a resposta seja integração.
Não reescrita.
⏱️ 23:42 — O castelo Bellacosa
Imagine o mainframe como um castelo gigantesco.
Dentro dele vivem:
COBOL
CICS
IMS
Db2
RACF
JES2
Durante décadas quem quisesse entrar precisava conhecer os costumes locais:
3270
TSO
ISPF
JCL
copybook
COMMAREA
EBCDIC
Então construímos uma recepção moderna.
Na porta está escrito:
HTTPS
REST
JSON
OpenAPI
O visitante chega.
— Quero consultar a conta 123.
Ele envia:
GET /accounts/123
A recepção entende.
Traduz.
Entra no castelo.
O velho COBOL recebe sua estrutura.
Executa.
Consulta Db2.
Devolve os dados.
A recepção traduz novamente.
O visitante recebe:
{
"account": 123,
"balance": 8542.71
}
E vai embora.
Ele nunca soube que CICS existia.
E o CICS nunca precisou aprender React.
Isso é desacoplamento.
⏱️ 23:50 — A curiosidade que muda tudo
Perceba uma consequência filosófica interessante.
Uma aplicação pode ter:
30 anos de idade
e possuir uma interface criada ontem.
Portanto:
A idade da implementação não determina a idade da interface.
Essa frase merece ficar colada perto do monitor.
Podemos ter:
React
│
REST
│
API Gateway
│
z/OS Connect
│
CICS
│
COBOL
│
Db2
Qual é a idade desse sistema?
2026?
2015?
2002?
1989?
A resposta correta talvez seja:
todas elas.
Sistemas empresariais são cidades.
Não são casas.
Uma cidade possui prédios de 1890, metrô de 1970, fibra óptica de 2025 e alguém pagando café pelo celular dentro de um edifício construído quando telefone ainda tinha fio.
Ninguém diz:
“Precisamos demolir Lisboa porque algumas construções são antigas.”
Integramos.
Restauramos.
Substituímos onde necessário.
Preservamos onde faz sentido.
⏱️ 23:55 — Cinco dicas do velho COBOLzeiro
Se você está começando em COBOL e z/OS Connect, guarde estas ideias.
1. Aprenda HTTP e REST.
Você não precisa virar desenvolvedor frontend, mas precisa entender:
GET
POST
PUT
DELETE
headers
status codes
JSON
TLS
2. Aprenda OpenAPI.
O contrato é parte central desse novo mundo.
3. Continue estudando COBOL profundamente.
API nenhuma elimina a necessidade de entender aquilo que existe atrás dela.
4. Aprenda segurança.
Especialmente:
SAF
RACF
TLS
JWT
identidade
autenticação
autorização
least privilege
5. Aprenda observabilidade.
Porque depois do primeiro:
HTTP 200 OK
virá inevitavelmente:
“Por que demorou 1,7 segundo?”
E alguém precisará descobrir.
⏱️ 23:58 — O último plot twist
Jack Bauer finalmente encontra o responsável pelo incidente.
Não era o COBOL.
Não era o CICS.
Não era o Db2.
Não era RACF.
Era uma aplicação distribuída fazendo 47 chamadas redundantes para a mesma API para montar uma única tela.
O sysprog olha para Jack.
Jack olha para o sysprog.
O sysprog pergunta:
— Quer café?
— Quanto tempo temos?
00:01:42
— Dá.
⏱️ 23:59 — O relógio chega ao fim
Agora podemos resumir toda nossa arquitetura:
IBM z/OS CONNECT
│
┌──────────────┴──────────────┐
│ │
▼ ▼
API PROVIDER API REQUESTER
mundo → z/OS z/OS → mundo
REST/JSON COBOL
│ │
▼ ▼
z/OS Connect z/OS Connect
│ │
▼ ▼
CICS / IMS / Db2 REST APIs
│ │
▼ ▼
COBOL Cloud / SaaS
Ao redor disso existem:
OpenAPI
mapping
security
SAF
RACF
TLS
JWT
OpenTelemetry
SMF
zIIP
containers
OpenShift
API Management
DevOps
Mas existe uma ideia ainda maior envolvendo tudo isso:
MODERNIZAÇÃO
│
▼
não significa obrigatoriamente
│
▼
REESCRITA
Modernização pode significar:
PRESERVAR
│
▼
CAPACIDADES DE NEGÓCIO
│
▼
DESACOPLAR
│
▼
EXPOR POR CONTRATOS MODERNOS
│
▼
INTEGRAR
│
▼
EVOLUIR
☕ Epílogo — 00:00:00
O relógio finalmente chega a zero.
A API está funcionando.
O aplicativo mobile consulta o cliente.
O request entra como REST.
z/OS Connect recebe JSON.
A estrutura chega ao CICS.
O programa COBOL executa.
Db2 responde.
A informação volta.
O usuário vê seu saldo no smartphone.
Ele toca na tela e reclama:
— Nossa, tecnologia moderna é incrível.
No datacenter, silenciosamente, um programa COBOL escrito quando Windows 3.1 era novidade acabou de fazer o trabalho pesado.
Ele não recebeu aplausos.
Não apareceu no aplicativo.
Ninguém colocou seu nome na keynote.
Ele simplesmente executou outra transação.
Como fez milhões de vezes.
Jack Bauer fecha o notebook.
O operador olha para a console.
CICS STATUS: ACTIVE
Tudo normal.
Então o velho COBOLzeiro toma o último gole de café e deixa uma anotação para o turno seguinte:
Não confundam modernização com demolição. Às vezes o sistema não precisa de um coração novo. Precisa apenas de uma porta nova.
Na porta está escrito:
REST
JSON
OpenAPI
Atrás dela continua existindo:
PROCEDURE DIVISION.
PERFORM PROCESSAR-NEGOCIO.
GOBACK.
00:00:01
O telefone toca novamente.
— Temos outro problema.
— Qual?
— Agora querem colocar IA acessando a API.
O COBOLzeiro olha para Jack Bauer.
Jack Bauer olha para o relógio.
O relógio começa novamente:
24:00:00
23:59:59
23:59:58...
E em algum lugar muito distante do CPD alguém abre um PowerPoint chamado:
AI MAINFRAME MODERNIZATION
FINAL_v7_REAL_FINAL_AGORA_VAI.pptx
O operador suspira.
— Passa o café.
Easter egg final: se você trabalha em TI há tempo suficiente, sabe que o arquivo FINAL_v7_REAL_FINAL_AGORA_VAI jamais é a versão final.
E talvez essa seja a única constante mais confiável que o próprio mainframe.
☕
Sem comentários:
Enviar um comentário