 |
| Bellacosa Mainframe uma overview do ims 360 ao ims 15 |
☕ Um Café no Bellacosa Mainframe
Do IMS/360 ao IMS 15 no IBM z16
A Evolução da Arquitetura que Inspirou os Sistemas Corporativos Modernos — Um Guia Definitivo para um Programador COBOL Padawan
Durante décadas, muita gente acreditou que os sistemas corporativos nasceram com Java, Oracle, APIs REST ou Kubernetes. Outros imaginam que microserviços, filas de mensagens, observabilidade e processamento distribuído são invenções da computação moderna.
A realidade é muito mais interessante.
Muito antes da internet existir, antes da Web, antes do Linux e até antes do banco de dados relacional se popularizar, engenheiros da IBM já haviam construído uma arquitetura extremamente sofisticada sobre o IBM System/360. Essa arquitetura possuía processamento online, banco de dados, recuperação automática, auditoria, processamento batch, filas de mensagens e milhares de usuários simultâneos.
O nome dela era simplesmente:
IMS – Information Management System
A imagem que analisamos nesta conversa é um excelente exemplo dessa arquitetura clássica. Embora o diagrama tenha sido desenhado há mais de cinquenta anos, praticamente todos os conceitos presentes nele continuam vivos no IBM Z moderno.
Hoje vamos desmontar essa arquitetura peça por peça e reconstruí-la utilizando a visão de um programador COBOL Padawan, entendendo não apenas "como funciona", mas também "por que continua funcionando".
O nascimento do IMS
Pouca gente conhece essa curiosidade.
O IMS não nasceu para bancos.
Nem para bancos financeiros.
Nem para seguradoras.
Ele nasceu por causa da NASA.
No final da década de 1960, a IBM precisava criar um sistema capaz de controlar milhões de componentes utilizados no Programa Apollo.
Imagine controlar parafusos.
Cabos.
Circuitos.
Motores.
Bombas.
Sensores.
Tudo precisava ser localizado em segundos.
Foi então que surgiu um banco de dados hierárquico extremamente rápido.
Esse projeto evoluiu e tornou-se o IMS.
Curiosamente, poucos anos depois, bancos, seguradoras, companhias aéreas e governos passaram a utilizá-lo.
Até hoje.
 |
| Bellacosa Mainframe e o workflow do ims dl/i |
Entendendo o workflow
Observe a estrutura geral.
Ela é extremamente organizada.
Entradas
↓
Processamento Online
↓
Banco de Dados
↓
Batch
↓
Relatórios
Parece simples.
Mas escondia uma engenharia impressionante.
Cada bloco tinha uma responsabilidade específica.
Exatamente como fazemos hoje utilizando microserviços.
A diferença é que isso já existia décadas antes do termo "microservice" ser inventado.
Os Inputs
Na parte superior aparecem três caixas.
INPUT
INPUT
INPUT
Essas entradas podiam ser praticamente qualquer coisa.
Um terminal 3270.
Uma leitora de cartões.
Uma fita magnética.
Outro computador.
Uma aplicação externa.
Hoje poderíamos substituir essas caixas por:
API REST
IBM MQ
Kafka
Event Streams
Mobile App
Browser
Portal Web
IoT
O conceito continua exatamente igual.
Alguém envia uma informação.
O sistema precisa processá-la.
O verdadeiro cérebro: IMS Transaction Manager
No desenho original aparece:
IMS/360
Hoje ele seria:
IMS TM 15
Ele recebe transações.
Gerencia filas.
Controla sessões.
Executa programas COBOL.
Protege os dados.
Controla concorrência.
Garante integridade.
É praticamente um servidor de aplicações.
Muito antes do WebSphere existir.
Os famosos Message Processing Programs (MPP)
Na lateral aparece uma inscrição discreta.
Message Processing Programs
Esse pequeno detalhe representa uma das maiores ideias da computação corporativa.
O usuário envia uma mensagem.
O IMS coloca essa mensagem em uma fila.
Depois escolhe automaticamente qual programa COBOL deve executá-la.
Hoje isso lembra imediatamente:
Controller REST
Lambda
Azure Function
Cloud Function
Microserviço
Na prática é exatamente isso.
Só que rodando em um IBM Z.
O ciclo de uma transação
Imagine um operador alterando uma ordem de produção.
O fluxo interno acontece assim.
Terminal
↓
Mensagem
↓
Fila IMS
↓
MPP
↓
COBOL
↓
IMS DB
↓
Resposta
O usuário vê apenas alguns segundos.
Mas centenas de mecanismos internos entram em ação.
Locks.
Recovery.
Logs.
Buffers.
Commit.
Checkpoint.
Tudo acontece automaticamente.
Os módulos internos
Dentro da aplicação aparecem vários nomes.
STATUS
CHANGE
SPLIT
INQUIRY
ADD
Não são apenas palavras.
Cada uma representa uma operação de negócio.
STATUS
Consulta.
CHANGE
Atualização.
ADD
Inclusão.
INQUIRY
Pesquisa.
SPLIT
Divisão de pedidos.
Perceba uma curiosidade.
Hoje chamaríamos isso de:
GET
POST
PUT
PATCH
As ideias mudaram de nome.
Não de essência.
Os bancos de dados
A aplicação conversa com três bancos.
Isso já demonstra uma preocupação enorme com organização.
Manufacturing Order Database
Banco principal.
Pedidos.
Clientes.
Produção.
Ordens.
Materiais.
Part Number Cross Reference
Uma base auxiliar.
Ela permite descobrir equivalências.
Imagine:
Parafuso antigo
↓
Parafuso novo
Ou
Fornecedor A
↓
Fornecedor B
Hoje chamaríamos isso de Master Data Management.
Manufacturing Planning Database
Aqui mora o planejamento.
Capacidade.
Estoque.
Cronograma.
Previsão.
Hoje esse banco conversa diretamente com sistemas ERP.
Easter Egg nº 1
Muita gente acredita que Data Warehouse nasceu nos anos 90.
Na verdade não.
Observe o bloco:
Unload and Select
Ele já fazia exatamente isso.
Extraía dados.
Selecionava informações.
Preparava estatísticas.
Produzia relatórios.
É praticamente um ETL primitivo.
O IMS LOG
Este talvez seja o componente mais importante de toda arquitetura.
Toda alteração gera um registro.
Nada acontece sem ser registrado.
É graças ao LOG que existem:
Recovery
Rollback
Auditoria
Sincronização
Checkpoint
Hoje fazemos exatamente isso.
Oracle.
Db2.
SQL Server.
PostgreSQL.
Todos utilizam o mesmo princípio.
Easter Egg nº 2
Se você já ouviu falar em WAL (Write Ahead Log) do PostgreSQL...
Parabéns.
Você já conhece o IMS LOG.
O conceito é praticamente idêntico.
IMS Utilities
Após registrar tudo no LOG entram as Utilities.
Elas realizam tarefas fundamentais.
Reorganização.
Validação.
Compressão.
Recovery.
Carga.
Descarga.
Verificação.
Sem Utilities, um ambiente IMS simplesmente não sobrevive.
O mundo Batch
Na parte inferior aparece outro universo.
Os Batch Programs.
Hoje muitos iniciantes imaginam que Batch significa tecnologia antiga.
Não.
Batch significa processamento em massa.
Todos os grandes bancos ainda executam milhares de jobs batch diariamente.
Mudaram apenas as ferramentas.
Report Writer
Responsável pelos relatórios.
No passado.
Impressoras
Papel contínuo
Listagens verdes
Hoje.
Power BI.
Cognos.
Grafana.
Excel.
PDF.
O objetivo continua igual.
Transformar dados em informação.
Selected Report Writer
Relatórios específicos.
Por exemplo.
Pedidos atrasados.
Pedidos acima de R$ 1 milhão.
Produção do turno noturno.
Database Statistics
Outro detalhe interessante.
O sistema produzia estatísticas do banco.
Quantidade de registros.
Espaço ocupado.
Fragmentação.
Performance.
Hoje isso lembra:
RUNSTATS
EXPLAIN
Catalog Statistics
SMF
RMF
OMEGAMON
POSR
No desenho aparece uma sigla curiosa.
POSR
Dependendo da instalação, poderia representar um sistema interno responsável pela consolidação de relatórios operacionais.
É praticamente um pequeno Data Mart.
Observe que ele recebe dados extraídos.
Processa.
Produz relatórios.
Hoje isso seria um pipeline analítico.
Atualizando para o IBM z16
Na versão moderna do diagrama acrescentamos diversos componentes.
Observe como tudo evoluiu.
Entradas
Agora temos.
3270
REST
JSON
MQ
Kafka
Mobile
Cloud
Eventos
Mas todos continuam convergindo para o mesmo lugar.
IMS TM.
Segurança
Hoje um ambiente corporativo possui:
RACF
TLS
AT-TLS
MFA
Criptografia
SMF
Auditoria
LGTO
Compliance
Zero Trust
No desenho antigo isso estava implícito.
Hoje tornou-se um bloco próprio.
DevOps
Outro componente inexistente no desenho original.
Agora encontramos.
Git
GitHub
GitLab
Jenkins
UrbanCode
DBB
Zowe CLI
Ansible
Terraform
Pipelines
Observe.
Nenhum deles substitui o IMS.
Eles apenas automatizam seu gerenciamento.
Observabilidade
Outro grande avanço.
Hoje monitoramos praticamente tudo.
OMEGAMON
Instana
Operations Analytics
SMF
RMF
Grafana
OpenTelemetry
Anomalias
Machine Learning
No IMS/360 isso era feito através de relatórios.
Hoje fazemos em tempo real.
Integração
Outro enorme salto.
O IMS moderno conversa naturalmente com:
Db2
MQ
IMS Connect
REST
SOAP
JSON
Cloud Pak for Data
Data Lake
IBM Cloud
AWS
Azure
Kafka
OpenShift
O IMS deixou de ser um ambiente isolado.
Hoje participa do ecossistema corporativo inteiro.
O maior equívoco sobre o Mainframe
Existe uma frase repetida há décadas.
"O Mainframe é um computador antigo."
Errado.
Na verdade.
O Mainframe é uma arquitetura extremamente moderna cuja origem é antiga.
É diferente.
O IBM z16 possui:
IA embarcada.
Criptografia por hardware.
Processadores especializados.
Linux.
Containers.
Kubernetes.
OpenShift.
APIs.
Cloud.
Mas continua executando IMS.
Porque a arquitetura foi bem projetada.
Easter Egg nº 3
Sabe o que mais impressiona?
Se um programador COBOL de 1985 voltasse hoje, ele provavelmente reconheceria a lógica de um sistema IMS em poucos minutos.
Agora imagine o contrário.
Um desenvolvedor moderno tentando entender um programa IMS de 1985.
Ele descobriria que quase tudo o que considera "novo" já existia em alguma forma:
Os nomes mudaram. Os princípios permaneceram.
Passo a passo para um Padawan dominar o IMS
Não tente aprender tudo de uma vez. Construa conhecimento em camadas.
Nível 1 – Fundamentos
Entenda o que é o IBM Z e o z/OS.
Aprenda JCL, datasets e utilitários básicos.
Conheça a diferença entre processamento online e batch.
Nível 2 – IMS TM
Descubra o que é uma transação IMS.
Estude Message Processing Programs (MPP).
Aprenda o fluxo: entrada → fila → programa → resposta.
Nível 3 – IMS DB
Compreenda bancos de dados hierárquicos.
Estude segmentos, hierarquias e DBD/PSB.
Pratique navegação usando chamadas DL/I.
Nível 4 – Operação
Aprenda a interpretar logs.
Estude checkpoints e recovery.
Conheça as principais IMS Utilities.
Nível 5 – Modernização
Curiosidades que quase ninguém conhece
O IMS é um dos softwares comerciais mais antigos ainda em desenvolvimento contínuo.
Milhões de transações financeiras diárias no mundo passam por aplicações IMS sem que o usuário perceba.
Bancos de dados hierárquicos continuam sendo extremamente eficientes para cargas transacionais previsíveis.
O IMS foi projetado quando memória e processamento eram recursos escassos, o que explica sua impressionante eficiência até hoje.
Muitas arquiteturas modernas de mensageria reproduzem conceitos que o IMS já implementava há décadas.
Conclusão
A imagem histórica que analisamos não é apenas um diagrama técnico; ela representa uma filosofia de engenharia. Ela mostra que sistemas corporativos robustos são construídos com responsabilidades bem definidas, processamento confiável, recuperação planejada e forte disciplina arquitetural.
Ao atualizarmos esse desenho para um ambiente IBM z16 com IMS 15, percebemos que a essência permanece intacta. Entradas continuam chegando ao Transaction Manager, programas COBOL continuam executando regras de negócio, bancos de dados continuam preservando a integridade das informações e processos batch continuam alimentando análises e relatórios. A diferença é que agora tudo isso convive com APIs REST, JSON, IBM MQ, Event Streams, DevOps, observabilidade em tempo real, OpenShift, inteligência artificial e integração com nuvens híbridas.
Essa é a maior lição para um programador COBOL Padawan: tecnologias vêm e vão, mas boas arquiteturas atravessam gerações. O IMS sobreviveu porque foi projetado com princípios sólidos. Entender esse legado não é estudar apenas o passado; é compreender os alicerces sobre os quais a computação corporativa moderna continua sendo construída.
