 |
| Bellacosa Mainframe e uma visão sobre sistemas e arquiteturas |
☕ Um Café no Bellacosa Mainframe
🧙♂️ YUJI E A DUNGEON DOS SISTEMAS ABERTOS — QUANDO O MAINFRAME DESCOBRIU QUE O UNIX NÃO ERA O CHEFÃO FINAL
COBOL, mainframe, microinformática, Unix, RISC, cliente-servidor, sistemas abertos, padrões, 4GL, TCO, auditoria, Shadow IT — e o dia em que Yuji descobriu que o servidor barato podia sair muito caro.
🎬 PRÓLOGO — YUJI ENCONTROU UM COMPUTADOR DEBAIXO DA MESA
Yuji entrou silenciosamente no Departamento Financeiro.
Como sempre, ninguém percebeu sua chegada.
Atrás dele caminhavam alguns slimes.
— Puru puru.
Yuji olhou para uma mesa.
Havia um computador.
Olhou para outra.
Outro computador.
Mais adiante encontrou mais seis.
Então um dos slimes apareceu trazendo uma informação:
Detectado aplicativo desconhecido.
Yuji parou.
— Aplicativo desconhecido?
O slime respondeu:
FINANCEIRO_FINAL.XLS
Outro slime apareceu.
FINANCEIRO_FINAL2.XLS
Mais um:
FINANCEIRO_FINAL_AGORA_VAI.XLS
Yuji ficou alguns segundos olhando para aquilo.
Finalmente perguntou:
— Qual deles fecha o balanço da empresa?
Silêncio.
Era o final dos anos 1990.
Durante décadas, a empresa conhecera perfeitamente seu grande computador central. Programas COBOL eram desenvolvidos, compilados, testados e colocados em produção seguindo procedimentos relativamente controlados.
Então chegaram os computadores pessoais.
Baratos.
Fáceis de instalar.
Espalharam-se pelas mesas.
Depois vieram redes locais, servidores departamentais, Unix, arquiteturas RISC, cliente-servidor, bancos de dados distribuídos e Internet.
A capacidade computacional escapara do castelo.
E ninguém sabia exatamente quantos monstros havia agora na floresta.
Yuji acabara de encontrar uma nova dungeon:
a microinformática corporativa.
🏰 CAPÍTULO 1 — QUANDO O COMPUTADOR MORAVA NO CASTELO
Programador COBOL iniciante, antes de falarmos sobre Unix, RISC ou sistemas abertos, precisamos voltar algumas décadas.
Durante grande parte da história da computação empresarial, processamento era algo centralizado.
Imagine uma empresa possuindo um grande computador:
TERMINAL ─┐
TERMINAL ─┤
TERMINAL ─┤
TERMINAL ─┼──── MAINFRAME ──── DADOS
TERMINAL ─┤
TERMINAL ─┤
TERMINAL ─┘
Os usuários trabalhavam em terminais.
O terminal frequentemente tinha pouca capacidade de processamento local. Ele permitia ao usuário interagir com aplicações executadas no computador central.
É daí que aparece uma palavra importantíssima naquele período:
HOST.
Host é o sistema que hospeda e executa serviços ou workloads utilizados por outros sistemas ou usuários.
No mundo corporativo clássico, o mainframe era frequentemente esse host.
Centenas ou milhares de pessoas poderiam compartilhar recursos da mesma máquina.
Um bancário consultava uma conta.
Outro registrava uma transferência.
Um programa batch processava arquivos.
Outro atualizava banco de dados.
Tudo acontecia sobre uma infraestrutura centralizada.
Para quem está começando em COBOL, pense em:
COBOL
↓
CICS
↓
Db2 / IMS / VSAM
↓
z/OS
↓
IBM Z
Naturalmente, essa é uma simplificação, mas ela ajuda a visualizar a ideia.
O mainframe não significa apenas "computador grande".
Sua importância está na capacidade de administrar grandes quantidades de trabalho compartilhado de maneira controlada.
🖥️ CAPÍTULO 2 — O PC ESCAPOU DO CPD
Então aconteceu algo revolucionário.
Computadores ficaram menores e baratos.
O processamento começou a sair do CPD e chegar às mesas.
Era uma transformação profunda porque a informação deveria estar:
onde as pessoas precisavam dela para tomar decisões.
Imagine o Departamento Financeiro.
Antes, alguém poderia solicitar um relatório ao CPD.
Depois teria que esperar sua execução.
Com um PC e uma planilha, o gerente podia manipular informações imediatamente.
Isso era fantástico.
Mas havia um efeito colateral.
Antes:
USUÁRIO
│
▼
SISTEMA CORPORATIVO
│
▼
MAINFRAME
Agora:
USUÁRIO
│
├── planilha
├── banco local
├── aplicativo comprado
├── programa feito pelo departamento
└── arquivos locais
O poder computacional estava sendo democratizado.
E toda democratização tecnológica cria novas possibilidades — inclusive novas maneiras de fazer besteira.
👻 CAPÍTULO 3 — YUJI DESCOBRE O ANCESTRAL DO SHADOW IT
Um slime apareceu diante de Yuji.
Detectada aplicação crítica.
Yuji perguntou:
— Está no mainframe?
— Não.
— Servidor Unix?
— Não.
— Sistema oficial?
— Não.
— Quem desenvolveu?
O slime respondeu:
Carlos, do Financeiro.
— Carlos é programador?
Não.
— Documentação?
Não encontrada.
— Backup?
Talvez.
Yuji suspirou.
Bem-vindo ao ancestral do Shadow IT.
Shadow IT é tecnologia utilizada dentro de uma organização sem conhecimento, aprovação ou governança adequada da área responsável.
Hoje podemos imaginar:
SaaS contratado sem autorização;
armazenamento em cloud pessoal;
aplicações low-code;
ferramentas de IA;
bancos de dados externos;
APIs não autorizadas.
Nos anos 1990, poderia ser algo muito mais simples:
Access;
Excel;
Lotus 1-2-3;
dBase;
FoxPro;
Visual Basic;
programas shareware;
bancos de dados locais.
Uma planilha começava ajudando uma pessoa.
Depois ajudava cinco.
Depois cinquenta.
Até que alguém descobria:
“Sem aquela planilha não conseguimos fechar o mês.”
Acabamos de criar um sistema crítico sem Change Management, documentação ou governança.
🔎 CAPÍTULO 4 — NASCE A NECESSIDADE DE AUDITAR A MICROINFORMÁTICA
Quando existem dez computadores, talvez alguém saiba onde estão.
Quando existem dez mil, temos outro problema.
Auditoria de microinformática começou a ganhar enorme importância justamente porque empresas acumulavam grandes quantidades de equipamentos e software distribuídos.
O auditor precisava responder perguntas básicas.
Quantos computadores existem?
Onde estão?
Quem utiliza cada equipamento?
Qual configuração possuem?
Que software está instalado?
Existem licenças?
Existe antivírus?
Existe backup?
Quem possui privilégios administrativos?
Existem programas não autorizados?
Existem dados corporativos armazenados localmente?
Observe que a auditoria não estava procurando simplesmente "computadores".
Estava tentando descobrir riscos.
Imagine um PC contendo dados financeiros críticos.
Se o disco falhar amanhã, o que acontece?
Essa pergunta vale muito mais que saber a marca do computador.
🧙 CAPÍTULO 5 — O MAINFRAME ENCONTRA O UNIX
Enquanto PCs conquistavam as mesas, outro personagem ganhava espaço nos data centers:
Unix.
Unix tinha uma longa história acadêmica e empresarial e tornou-se extremamente importante em workstations e servidores.
Nos anos 1990, Unix frequentemente aparecia associado às arquiteturas RISC.
RISC significa:
Reduced Instruction Set Computer.
A filosofia RISC buscava trabalhar com conjuntos de instruções relativamente simples e eficientes, favorecendo determinadas estratégias de implementação e pipeline.
Entre as arquiteturas que se tornaram importantes estavam:
IBM POWER
Sun SPARC
HP PA-RISC
DEC Alpha
MIPS
Imagine nosso mundo de fantasia.
Vários reinos surgiram dizendo:
“Não precisamos daquele castelo gigantesco. Podemos construir fortalezas menores.”
Era o começo de uma mudança significativa na distribuição da capacidade computacional.
⚔️ CAPÍTULO 6 — MERCEDES-BENZ CONTRA FUSCA
Em determinado debate daquela época surgiu uma comparação maravilhosa.
Representantes do mundo mainframe compararam:
MAINFRAME = MERCEDES-BENZ
UNIX = FUSCA
Segundo o argumento, ambos poderiam levar você ao destino.
Mas a Mercedes ofereceria mais:
conforto;
segurança;
confiabilidade;
qualidade dos componentes.
É uma metáfora interessante.
Mas existe um problema.
Yuji provavelmente perguntaria:
— Qual é a missão?
Porque não faz sentido discutir qual veículo é melhor sem perguntar para quê ele será usado.
Se você precisa transportar uma pessoa alguns quilômetros, talvez o veículo simples seja suficiente.
Agora imagine:
“Precisamos processar milhões de transações financeiras, continuamente, com controles rígidos e altíssima disponibilidade.”
A conversa muda.
Tecnologia empresarial deve ser analisada pelo workload.
Essa é uma palavra que você deve guardar.
Workload
É a carga de trabalho computacional que um sistema precisa executar.
Pode ser:
transações CICS
batch COBOL
consultas Db2
servidor Web
analytics
IA
processamento científico
mensageria
APIs
Portanto:
Não existe plataforma universalmente melhor. Existe plataforma mais adequada para determinado conjunto de requisitos.
💰 CAPÍTULO 7 — O SERVIDOR BARATO QUE FICOU CARO
Unix tinha uma vantagem comercial poderosa.
Servidores menores podiam custar significativamente menos que grandes sistemas centralizados.
Então alguém fazia a comparação:
MAINFRAME
US$ $$$$$$$$
UNIX
US$ $$$
Pronto.
Unix venceu?
Calma.
Yuji mandaria seus slimes procurar o restante da conta.
Porque preço de aquisição não é igual a custo total.
Surge então uma ideia fundamental:
TCO — Total Cost of Ownership
TCO significa custo total de propriedade.
Imagine um servidor custando:
US$ 20.000
Mas durante cinco anos você precisará pagar por:
administradores
energia
storage
backup
rede
licenciamento
monitoramento
suporte
patching
segurança
downtime
migrações
Agora multiplique isso por 100 servidores.
O servidor barato pode gerar uma infraestrutura cara.
Essa discussão dos anos 1990 reapareceria décadas depois com cloud.
🌐 CAPÍTULO 8 — CLIENTE-SERVIDOR MUDA A DUNGEON
Uma das grandes arquiteturas daquele período foi o modelo client/server.
Em vez de concentrar praticamente todo processamento no host, distribuímos responsabilidades.
Exemplo:
CLIENTE
│
│ solicitação
▼
SERVIDOR
│
▼
BANCO DE DADOS
O cliente poderia cuidar da interface.
O servidor executaria regras ou serviços.
O banco armazenaria dados.
Isso possibilitava distribuir capacidade computacional.
Imagine uma aplicação COBOL tradicional:
3270
│
▼
CICS
│
├── COBOL
│
▼
Db2
No mundo distribuído poderíamos encontrar:
Windows Client
│
▼
Unix Server
│
▼
Database
Mas cuidado.
Distribuir processamento também distribui complexidade.
Agora precisamos administrar:
rede
protocolos
clientes
servidores
versões
drivers
bancos
autenticação
compatibilidade
Toda camada adicionada resolve alguma coisa e potencialmente cria outra dungeon.
🔌 CAPÍTULO 9 — SISTEMAS ABERTOS E O PODER DOS PADRÕES
Chegamos a uma das ideias mais importantes daquela transformação:
sistemas abertos.
Um sistema aberto não significa necessariamente que absolutamente tudo nele seja open source.
A questão central está em utilizar interfaces, protocolos e padrões que facilitem interoperabilidade.
Imagine três fornecedores criando três equipamentos.
Sem padrões:
A ── protocolo A
B ── protocolo B
C ── protocolo C
Integrá-los é complicado.
Com padrões:
A ─┐
B ─┼── PADRÃO
C ─┘
Os produtos continuam diferentes.
Mas existe uma linguagem comum.
Pense na Internet.
Equipamentos completamente diferentes conseguem conversar usando protocolos padronizados.
Isso reduz dependência tecnológica e facilita integração.
🧩 CAPÍTULO 10 — PADRÃO NÃO MATA CRIATIVIDADE
Uma preocupação daquela época era:
“Se tudo for padronizado, produtos serão iguais?”
Não.
Um padrão normalmente determina como determinados componentes devem interagir, não como todo produto precisa ser construído.
Considere USB.
Fabricantes podem criar milhares de dispositivos diferentes.
O padrão define determinadas regras de comunicação.
O mesmo raciocínio aparece em:
TCP/IP
HTTP
SQL
POSIX
REST
JSON
Unicode
Padronização cria uma fronteira de interoperabilidade.
Dentro dessa fronteira ainda existe enorme espaço para inovação.
Em outras palavras:
o padrão define a porta; não determina como você deve decorar a casa.
🧬 CAPÍTULO 11 — O MAINFRAME COMEÇA A ABSORVER O MUNDO ABERTO
Aqui está uma ironia histórica maravilhosa.
Naquele período, sistemas abertos eram frequentemente apresentados como alternativa ao mainframe.
Mas o mainframe não ficou congelado.
Ele começou a incorporar tecnologias e interfaces associadas ao mundo aberto.
Décadas depois encontramos no ecossistema IBM Z:
COBOL
CICS
IMS
Db2
VSAM
JCL
convivendo com:
Unix
Java
Python
REST
JSON
Git
APIs
containers
Linux
DevOps
OpenShift
O resultado não foi simplesmente:
NOVO substitui VELHO
Foi frequentemente:
NOVO integra VELHO
Essa diferença é essencial para entender modernização de mainframe.
Modernizar não significa necessariamente jogar tudo fora.
🐉 CAPÍTULO 12 — O UNIX ESCONDIDO DENTRO DO MAINFRAME
Para um programador COBOL iniciante isso pode parecer estranho.
Mas o z/OS possui UNIX System Services — USS.
Isso significa que o ambiente z/OS incorpora um ambiente Unix compatível com padrões relevantes.
Podemos pensar conceitualmente em dois mundos convivendo:
z/OS
┌───────────────────┐
│ TSO / ISPF │
│ JCL │
│ COBOL │
│ CICS │
│ Db2 │
│ │
│ UNIX System │
│ Services │
│ shell │
│ filesystem │
└───────────────────┘
Imagine explicar isso para alguém no meio da guerra comercial dos anos 1990:
“Um dia você poderá encontrar ferramentas Unix convivendo dentro do ambiente do mainframe IBM.”
Yuji provavelmente apenas responderia:
— Skill adquirida.
🧠 CAPÍTULO 13 — O HARDWARE FICOU BARATO; O HUMANO NÃO
Outra observação extremamente importante daquele debate dizia, aproximadamente:
O custo do programador aumentava enquanto o custo do hardware despencava.
Os percentuais específicos podem variar conforme período e metodologia, mas o princípio econômico é importante.
Nos primórdios:
CPU = caríssima
memória = caríssima
disco = caríssimo
Portanto programadores economizavam recursos obsessivamente.
Com a redução do preço do hardware, outra variável ganhou enorme importância:
produtividade humana.
Imagine economizar US$ 5.000 em hardware e criar uma arquitetura que exige mais US$ 200.000 em manutenção.
Você economizou?
Não.
Apenas deslocou o custo.
E aqui entram as linguagens de quarta geração.
🪄 CAPÍTULO 14 — AS 4GL PROMETEM MAGIA
As chamadas 4GL — Fourth Generation Languages buscavam aumentar produtividade.
A ideia geral era permitir que o desenvolvedor descrevesse mais e programasse menos detalhes.
Entre tecnologias associadas ao universo 4GL estavam ferramentas como:
Natural
FOCUS
Informix-4GL
Progress
Oracle Forms
O objetivo econômico era simples:
menos código
↓
menos esforço
↓
maior produtividade
↓
menor custo
Natural, por exemplo, tornou-se particularmente conhecido em grandes ambientes corporativos e frequentemente apareceu junto do banco Adabas.
Para um programador COBOL, a comparação é interessante.
COBOL tende a ser bastante explícito.
Uma ferramenta de nível mais alto pode abstrair detalhes.
Mas abstração não elimina complexidade.
Ela apenas a desloca.
Esse princípio continua válido em 2026 com:
low-code
no-code
frameworks
cloud services
IA generativa
Cada geração promete:
“Agora qualquer pessoa poderá desenvolver.”
E algum tempo depois aparece outra profissão dizendo:
“Precisamos governar tudo isso.”
💾 CAPÍTULO 15 — A GUERRA DOS DISCOS
Durante a discussão histórica aconteceu um momento quase digno de anime.
O representante da HP defendia a tecnologia Unix/RISC.
Surgiu então a questão de problemas relacionados a discos.
A resposta foi aproximadamente:
Tecnologia nova sempre possui problemas.
Então veio a IBM:
“Roupa suja se lava em casa.”
Critical hit.
A IBM defendia que investia enormes recursos em pesquisa e testes para garantir confiabilidade.
Por trás da provocação comercial existe uma discussão séria.
Quanto vale confiabilidade?
Imagine dois discos:
DISCO A = R$ 1.000
DISCO B = R$ 4.000
Qual é mais barato?
Você ainda não sabe.
Precisamos descobrir:
taxa de falha
performance
redundância
suporte
tempo de recuperação
impacto da indisponibilidade
Se a falha do disco A provoca uma interrupção de R$ 5 milhões, aquela economia inicial torna-se irrelevante.
Por isso, em sistemas críticos:
confiabilidade possui valor econômico.
⚙️ CAPÍTULO 16 — COBOL ENSINA UMA LIÇÃO SOBRE CUSTO
Imagine este programa:
IDENTIFICATION DIVISION.
PROGRAM-ID. CLIENTE.
PROCEDURE DIVISION.
DISPLAY 'PROCESSANDO CLIENTE'.
STOP RUN.
Compilar e executar esse programa é fácil.
Mas um sistema empresarial não é apenas seu código.
Ele depende de:
dados
segurança
JCL
bibliotecas
interfaces
procedimentos
monitoramento
documentação
operações
backup
recuperação
Essa é uma das razões pelas quais substituir aplicações legadas pode ser muito mais complicado do que alguém imagina.
O código talvez tenha 30 anos.
Mas durante esses 30 anos a empresa acumulou milhares de regras de negócio.
O programa não é simplesmente software velho.
Pode ser conhecimento empresarial executável.
☁️ CAPÍTULO 17 — VINTE ANOS DEPOIS, CLOUD REPETE A DISCUSSÃO
Troque algumas palavras:
1998 2026
Mainframe Data Center
Unix/RISC Cloud
Client/server Microservices
Servidor Container
4GL Low-code/IA
E várias discussões retornam.
Alguém diz:
“Cloud é mais barata.”
Yuji pergunta:
— Para qual workload?
Outro diz:
“Microservices são melhores.”
— Para qual problema?
Outro:
“IA vai substituir todo desenvolvimento.”
Yuji olha para seus slimes.
— Requisitos?
Silêncio.
A grande lição é que tecnologia empresarial precisa ser analisada economicamente e tecnicamente.
📊 CAPÍTULO 18 — PASSO A PASSO PARA COMPARAR DUAS TECNOLOGIAS
Se amanhã alguém disser:
“Precisamos sair do mainframe porque X é mais barato.”
Não comece uma guerra religiosa.
Pegue café.
Abra uma planilha.
E siga os slimes de Yuji.
Passo 1 — Identifique o workload
Pergunte:
O que está sendo executado?
Batch?
CICS?
Db2?
Web?
Analytics?
Passo 2 — Meça volume
Quantas transações?
Quantos usuários?
Quanto armazenamento?
Qual crescimento anual?
Passo 3 — Determine SLA
Quanto tempo o sistema pode ficar indisponível?
1 hora?
10 minutos?
1 minuto?
praticamente nunca?
Passo 4 — Analise integração
Com quantos sistemas ele conversa?
Passo 5 — Analise segurança
Quem acessa?
Quais dados existem?
Há requisitos regulatórios?
Passo 6 — Calcule TCO
Não compare apenas hardware.
Inclua:
software
licenças
pessoas
infraestrutura
suporte
energia
migração
treinamento
backup
segurança
downtime
Passo 7 — Calcule risco de migração
Migrar também custa.
E falhar na migração custa ainda mais.
🔥 CAPÍTULO 19 — A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL
Você provavelmente ouvirá muitas vezes:
“COBOL morreu.”
“Mainframe morreu.”
“Servidor morreu.”
“Data center morreu.”
“Programador morreu.”
Tecnologia adora anunciar funerais.
Curiosamente, vários cadáveres continuam processando folha de pagamento.
O programador COBOL não deveria defender mainframe simplesmente porque trabalha com mainframe.
Isso seria torcida.
O profissional deve compreender:
requisito
workload
custo
risco
SLA
arquitetura
integração
Se Unix resolver melhor determinado problema, use Unix.
Se cloud resolver melhor, use cloud.
Se IBM Z resolver melhor, use IBM Z.
A pergunta profissional não é:
“Qual tecnologia eu amo?”
É:
“Qual problema preciso resolver?”
🥚 EASTER EGG — INCIDENTE 03:17
Às 03:17 da madrugada, Yuji recebeu uma mensagem.
JOB ABEND
Ele abriu o log.
IEF450I
PAYROLL STEP01
ABEND=S0C7
Um slime perguntou:
— Devemos migrar para Unix?
Yuji respondeu:
— Não. Primeiro descubra quem colocou caracteres alfanuméricos naquele campo numérico.
O slime desapareceu.
Alguns minutos depois:
ROOT CAUSE FOUND.
Moral da história:
arquitetura moderna não corrige dado ruim.
🧭 CAPÍTULO 20 — A PREVISÃO MAIS IMPORTANTE DOS ANOS 1990
No final daquele debate surgiu uma conclusão:
Mainframe e Unix terão que conviver.
E talvez essa tenha sido a previsão mais lúcida de todas.
Porque o futuro não se tornou:
MAINFRAME
X
UNIX
VENCEDOR: ???
Tornou-se:
INTERNET
│
APIs
│
┌──────────┴──────────┐
│ │
CLOUD IBM Z
│ │
containers CICS
Linux COBOL
Java Db2
Python IMS
│ │
└──────── EVENTOS ────┘
A palavra fundamental passou a ser:
INTEGRAÇÃO.
🧙♂️ EPÍLOGO — YUJI NÃO ESCOLHEU UM REINO
Ao terminar a auditoria, Yuji reuniu seus slimes.
Um encontrou mainframes.
Outro encontrou Unix.
Outro encontrou PCs.
Outro encontrou bancos de dados.
E aquele slime particularmente curioso voltou carregando:
FINANCEIRO_FINAL_DEFINITIVO_V7.XLS
Yuji olhou para ele.
— Isso é importante?
O slime respondeu:
Responsável pelo fechamento financeiro mensal da empresa.
— Backup?
Não.
— Documentação?
Não.
— Controle de acesso?
Não.
— Quem criou?
Funcionário aposentado em 1997.
Yuji ficou em silêncio.
Finalmente pronunciou:
— Esta é a aplicação mais perigosa que encontramos.
Não estava no mainframe.
Não estava no Unix.
Não custara milhões.
Provavelmente ninguém sequer sabia oficialmente que existia.
E essa talvez seja a maior lição desta dungeon.
A história da computação empresarial não é simplesmente uma sequência na qual tecnologias novas matam tecnologias antigas.
É uma história de redistribuição de responsabilidades.
O mainframe centralizou.
O PC descentralizou.
Unix distribuiu.
Cliente-servidor separou responsabilidades.
Sistemas abertos conectaram plataformas.
Padrões reduziram barreiras.
4GLs aumentaram produtividade.
Internet conectou organizações.
Cloud abstraiu infraestrutura.
Containers abstraíram ambientes.
IA começou a abstrair parte do trabalho intelectual.
Mas cada nova abstração também criou novos riscos.
Por isso aquela frase aparentemente simples dos anos 1990 continua extraordinariamente moderna:
Tecnologia não tem concorrência. Ela existe porque tem função.
Para o programador COBOL iniciante, eu acrescentaria uma segunda:
Nunca compare tecnologias pelo nome. Compare workloads, requisitos, riscos e custos.
E uma terceira, aprendida depois de décadas entrando em war rooms:
Se alguém disser que encontrou uma solução simples para substituir um sistema de 30 anos, pergunte primeiro se ele já encontrou todas as dependências.
Yuji levantou-se.
Os slimes começaram a abandonar a dungeon.
Um deles voltou correndo.
— Puru puru!
Nova skill detectada:
SHADOW_IT_DETECTION
Yuji observou a tela.
Havia agora uma aplicação chamada:
CONTROLE_CLIENTES_IA_FINAL_V3.xlsx
Ele suspirou.
Vinte e oito anos haviam passado.
A tecnologia mudara completamente.
O problema de auditoria continuava praticamente o mesmo.
☕ Bem-vindo ao Bellacosa Mainframe.
Aqui o COBOL pode ter décadas de idade, o Unix pode morar dentro do mainframe, o servidor barato pode custar uma fortuna e o arquivo mais perigoso da empresa talvez ainda esteja escondido debaixo da mesa de alguém.
E, se o incidente começar exatamente às 03:17, procure o slime.
Ele provavelmente já encontrou o log.
