☁️ z/OS 2.3 — O Mainframe que Aprendeu a Falar Cloud, REST e IA 🤖💙

Por Bellacosa Mainframe — onde tradição e inovação dividem a mesma LPAR ☕

---

O z/OS 2.3, lançado oficialmente em setembro de 2017, marcou o início da era cognitiva e containerizada do Mainframe.
Enquanto o z/OS 2.2 abriu as portas para DevOps e automação, o 2.3 trouxe o que podemos chamar de "transformação digital de dentro pra fora": APIs nativas, integração com cloud híbrida, suporte a linguagens abertas e gerenciamento autônomo de recursos.

Sim, o z/OS 2.3 é aquele tiozão que um dia programava em Assembler e, do nada, aparece falando Python, gerenciando containers e exportando logs para o Splunk. 😎

Vamos decodificar juntos os avanços, as mudanças de arquitetura e as curiosidades dignas de café e nostalgia.

---

🧭 1. Contexto histórico — o z/OS na era do z14 e da IA

O z/OS 2.3 foi projetado para o IBM z14, lançado no mesmo ano — uma joia de engenharia com até 170 processadores, 32 TB de memória e suporte completo a cripto on-chip.

Dados principais:

• 📅 Lançamento: setembro de 2017

• 🧱 Compatível com: zEnterprise EC12, z13, z13s e z14

• 🧠 Objetivo central: simplificar, automatizar e conectar o z/OS ao ecossistema híbrido e cognitivo

• 🧩 Suporte fim (EOS): setembro de 2022

O slogan interno da IBM era quase poético:

“From Stability to Agility.”
Ou seja, transformar a robustez lendária do mainframe em agilidade sem sacrificar confiabilidade.

---

💾 2. Memória e endereçamento — 64 bits na veia e no coração

O z/OS 2.3 consolidou o modelo 64-bit total, o que significa:

• Todas as principais áreas do sistema (LPA, CSA, SQA, Pageable link packs) passaram a operar em espaço de 64 bits.

• Suporte a 2 TB por address space e melhorias no paging inteligente.

• Memory Objects otimizados com menos overhead em z/Architecture.

📊 Resultado técnico: workloads como DB2 e IMS aumentaram 10 a 15% de throughput apenas pela reorganização do gerenciamento de memória.

💡 Bellacosa Curiosidade: o 2.3 foi o primeiro z/OS que praticamente aposentou o “modo 31 bits” no nível de sistema — mas ele ainda vive escondido em alguns programas legados (sim, aquele Assembler do século passado ainda funciona!).

---

⚙️ 3. PR/SM, HiperDispatch e créditos de CPU — inteligência no balanceamento

O PR/SM (Processor Resource/System Manager) e o HiperDispatch evoluíram consideravelmente no 2.3:

Destaques técnicos:

• Dynamic Capping: redistribui créditos de CPU em tempo real com base no workload WLM.

• SMF 70-1 passou a registrar novos campos de “LPAR entitlements” e “core utilization efficiency”.

• Workload Manager (WLM) ganhou consciência cognitiva — adaptando pesos automaticamente segundo padrões históricos de uso.

• PR/SM agora reconhece diferenças entre Integrated Facility for Linux (IFL), zIIP, ICF e CP, otimizando rotas de execução.

🎩 Easter Egg técnico: no SMF 72-3, um novo campo “WLM Decision Cycle Time” foi introduzido — uma pista do nascimento do Intelligent Resource Management, base do z/OS AI Framework do z16.

---

🧰 4. Aplicativos internos — o z/OS aprende a automatizar a si mesmo

O z/OS 2.3 levou o z/OSMF (z/OS Management Facility) ao próximo nível.
Antes um painel de controle, agora ele era uma plataforma completa de automação e APIs RESTful.

🌐 z/OSMF 2.3 — o cérebro orquestrador:

• Novo Workflow Editor com suporte a JSON Templates e execução remota.

• z/OSMF Workflows as a Service — rodar fluxos em outras LPARs.

• REST APIs públicas para gerenciamento de datasets, JES, e parmlibs.

• z/OSMF Lite Mode — uma versão enxuta para ambientes de teste e POCs.

• ZOSMF Plug-ins: começou a era da extensibilidade via plugins customizados.

💬 Bellacosa Nota Técnica: essa mudança abriu espaço para integração nativa com Jenkins, Ansible e UrbanCode Deploy, nascendo o conceito de Mainframe DevOps Pipeline.

---

🧩 5. Softwares e subsistemas — o ecossistema se reinventa

🔹 JES2 2.3

• Suporte completo a Unicode e UTF-8.

• Dynamic Checkpoint Rebuild (não precisava mais reiniciar para reconstruir spool).

• Novo job hold reason codes (para debugging mais detalhado).

• Preparado para JES2 running em z/OSMF APIs — sim, o spool agora tinha REST!

🔹 RACF 2.3

• Autenticação multifator experimental (MFA via IBM TouchToken e RSA).

• Políticas de senha mais granulares via IRRPRMxx.

• Novos registros SMF 83 para auditoria de MFA e certificados digitais.

🔹 UNIX System Services

• OpenSSH 7.4, Python 3.6, Node.js 8 e Zowe compatibility layer.

• Melhorias no zFS (z/OS File System) com asynchronous write cache.

• Enhanced fork — 25% mais rápido em execução de scripts longos.

🔹 DFSMS 2.3

• Tiering automático baseado em ML heuristics.

• Catalog search engine redesenhado (adeus à lentidão crônica do IDCAMS LISTCAT 😅).

• DFSMShsm otimizado para fast recall e HSM journaling.

---

🧠 6. Instruções de máquina e o poder do z14

Com o z14, vieram instruções novas e poderosas, que o z/OS 2.3 aproveitou ao máximo:

• Crypto on-chip AES-GCM e SHA-3 (sem precisar de Crypto Express externo).

• Vector Packed Decimal (VPD) — aceleração matemática de 8 a 10x.

• Hardware-assisted garbage collection para Java.

• Machine Check Enhancements (MCE): detecção proativa de falhas em memória.

📈 Em benchmarks internos, workloads Java no z/OS 2.3 rodando em z14 mostraram ganhos de 30% de performance, com menos 40% de uso de CPU.

---

🧩 7. z/OS Connect EE e a era das APIs REST

O z/OS Connect Enterprise Edition (v3) virou cidadão de primeira classe no 2.3.
Com ele, CICS, IMS e DB2 passaram a se comunicar com o mundo moderno via REST e JSON.

• Suporte nativo a Swagger/OpenAPI 2.0

• API Toolkit para criação visual de endpoints

• Conversão automática de COBOL copybooks para JSON

• Integração direta com API Gateway e IBM DataPower

💬 Bellacosa Curiosidade: durante os testes internos, engenheiros IBM chamavam o z/OS Connect EE de “Alexa do CICS” — porque ele transformava transações em conversas entre sistemas. 😂

---

🔒 8. Segurança e criptografia — o z/OS mais paranoico da história

O z/OS 2.3 trouxe uma revolução silenciosa na segurança:

• Pervasive Encryption: suporte completo a datasets criptografados com chaves AES-256 no DFSMS.

• ICSF (Crypto Services Facility) expandido para ECC e SHA-512.

• AT-TLS com SNI e suporte a TLS 1.3 (beta).

• SMF 119 — logs detalhados para auditorias TLS e IPsec.

💡 Bellacosa Insight: foi o primeiro passo para o “zero trust” real no mainframe.

---

🧙‍♂️ 9. Curiosidades e bastidores (as fofoquices técnicas que a IBM não conta 😏)

• Internamente, o projeto era chamado de “Project Aurora”, porque o z/OS 2.3 nascia junto ao z14, codinome Mills (em homenagem a Frederick P. Brooks).

• O time do z/OSMF implementou a primeira interface REST testada via Postman.

• Foi a primeira vez que o z/OS foi testado rodando em um ambiente virtual distribuído híbrido (z14 + z13).

• Algumas demos internas mostravam um chatbot RACF — sim, um protótipo de IA respondendo “quem tem acesso ao dataset X?”. 😂

---

🚀 10. Conclusão — o z/OS 2.3 e o nascimento do Mainframe Híbrido

O z/OS 2.3 é o ponto onde o mainframe deixou de ser apenas um sistema operacional robusto e virou um ecossistema digital inteligente.
Ele abriu caminho para o Zowe, para a observabilidade moderna, e para o DevSecOps mainframe, que hoje são realidade no z/OS 3.x.

💬 O 2.3 foi o último z/OS da velha guarda — e o primeiro da nova geração.
Um verdadeiro divisor de eras entre o batch e o cognitivo, entre o 3270 e o JSON.

---

Bellacosa Mainframe ☕
🧠 Onde bits têm alma, spool tem ritmo e o JES dança conforme o WLM.
💬 E você, padawan — lembra a primeira vez que rodou um workflow no z/OSMF 2.3 e ele simplesmente funcionou?
Conta aí: foi magia, medo ou “só pode ser bruxaria IBM”? 😄

Criptografia : Quando um Programador Descobre que o AES-256 Nunca Levou um ABEND

 

Bellacosa Mainframe apresenta criptografia

☕ Um Café no Bellacosa Mainframe

Criptografia sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o AES-256 Nunca Levou um ABEND... Mas as Decisões da Arquitetura Derrubaram Todo o Sistema Antes do Primeiro EXEC CICS

"Não entre em pânico. Tenha sempre uma toalha... e nunca armazene a chave criptográfica no mesmo dataset dos dados."
— Guia do Viajante das Galáxias, edição especial para Administradores RACF.

---

Introdução

Existe uma velha piada entre administradores de sistemas:

"A criptografia é perfeita... até alguém colocar a senha em um arquivo TXT chamado SENHAS.TXT."

Parece brincadeira.

Mas praticamente todos os grandes vazamentos de dados dos últimos anos seguiram exatamente esse roteiro.

Pouquíssimos ataques realmente quebraram algoritmos criptográficos.

Quase todos contornaram a criptografia.

Isso muda completamente a forma como devemos enxergar segurança.

Durante décadas, aprendemos que bastava usar um algoritmo forte.

AES.

RSA.

SHA.

TLS.

Fim do problema.

Mas a realidade é muito mais interessante.

Na verdade, criptografia não é um software.

Também não é um hardware.

Muito menos um botão que alguém ativa.

Ela é uma decisão arquitetural.

E é justamente aí que mora o verdadeiro desafio.

Hoje vamos fazer uma viagem pelo universo da criptografia usando uma analogia que qualquer profissional de Mainframe consegue entender.

Prepare seu terminal 3270.

Pegue seu café.

Vamos descobrir por que um ambiente IBM Z parece muito mais com a Millennium Falcon do que você imaginava.

---

O Universo Não Quebra AES

Imagine a seguinte situação.

Você trabalha em um banco.

O banco anuncia:

"Todos os dados utilizam AES-256."

Excelente.

Mas logo depois você descobre que:

• a chave AES está gravada em um arquivo JCL;

• o backup está em texto puro;

• o Load Balancer descriptografa tudo;

• o administrador copia os datasets antes da criptografia.

Parabéns.

Você possui uma Ferrari estacionada numa garagem sem porta.

A Ferrari continua excelente.

Mas qualquer um entra e leva.

Essa é exatamente a diferença entre:

Segurança criptográfica

e

Segurança arquitetural.

---

A Criptografia é Como um Cofre

Imagine um enorme cofre de banco.

O aço possui 50 centímetros.

Blindagem militar.

Fechadura quântica.

Sensores.

Laser.

Tudo perfeito.

Agora imagine que alguém pendurou a chave do lado de fora.

Acabou.

Ninguém precisou explodir o cofre.

Apenas abriu a porta.

É exatamente isso que acontece diariamente em milhares de empresas.

---

Bellacosa Mainframe Explica

Vamos imaginar que um Data Center seja uma cidade.

No centro existe o Mainframe.

Ao redor:

• CICS

• Db2

• MQ

• RACF

• z/OS

• VSAM

• IMS

• APIs

• Web Services

Todos conversam.

Todos trocam informações.

Todos precisam confiar uns nos outros.

Agora imagine que essa cidade tenha oito decisões importantes para sobreviver.

São exatamente as oito decisões mostradas na imagem.

---

Primeira Decisão — Escolhendo o Algoritmo

Todo iniciante acredita que criptografia significa:

AES.

Fim.

Mas escolher algoritmo é parecido com escolher linguagem de programação.

Você faria um sistema bancário novo usando COBOL de 1974 sem manutenção?

Provavelmente não.

Então por que ainda existem aplicações usando:

• MD5

• SHA-1

• DES

• RC4

Porque segurança envelhece.

Assim como hardware.

Assim como software.

Um algoritmo forte hoje pode virar legado amanhã.

---

Curiosidade

DES possuía apenas 56 bits.

Na década de 70 parecia impossível quebrar.

Hoje existem placas de vídeo domésticas capazes de fazer bilhões de operações por segundo.

O impossível virou exercício de laboratório.

---

Easter Egg nº 1

No universo Star Wars seria como proteger a Estrela da Morte usando apenas uma fechadura mecânica.

O problema nunca foi o aço.

Foi esquecer um pequeno ponto vulnerável...

Luke Skywalker agradece.

---

Segunda Decisão — Dados em Repouso

Imagine um VSAM.

Imagine um Db2.

Imagine milhares de datasets.

Agora imagine que alguém roubou o storage.

Sem criptografia:

todos os arquivos podem ser lidos.

Com criptografia:

o disco parece um monte de números aleatórios.

É exatamente isso que chamamos de:

Data at Rest.

---

No IBM Z isso evoluiu para algo espetacular.

Pervasive Encryption.

Em vez de perguntar:

"Quais dados devo criptografar?"

A IBM mudou a pergunta para:

"Por que ainda existe alguma informação sem criptografia?"

Essa mudança de filosofia foi revolucionária.

---

Curiosidade

Pervasive Encryption foi um dos maiores diferenciais apresentados no IBM z14.

Ela tornou possível criptografar praticamente todo o ambiente com impacto mínimo graças ao CPACF e aos aceleradores criptográficos.

Foi uma mudança de paradigma: a criptografia deixou de ser exceção e passou a ser o comportamento padrão.

---

Terceira Decisão — Dados em Trânsito

Muitos administradores antigos ainda pensam:

"Dentro da empresa ninguém invade."

Essa frase envelheceu muito mal.

Hoje existem:

Cloud.

Containers.

APIs.

Microservices.

Kubernetes.

Docker.

VPN.

Internet.

Zero Trust.

Tudo conversa.

Tudo trafega pela rede.

Logo...

Tudo precisa de TLS.

Inclusive entre servidores internos.

---

Analogia Bellacosa

Imagine vários programas COBOL.

Programa A

↓

Programa B

↓

Programa C

↓

MQ

↓

Db2

↓

IMS

Cada conversa precisa ser protegida.

Caso contrário basta alguém "escutar" a rede.

É como ouvir uma conversa telefônica.

---

Easter Egg nº 2

No Guia do Mochileiro das Galáxias existe um peixe Babel que traduz qualquer idioma.

TLS faz algo parecido.

Ele permite que dois sistemas conversem em segurança enquanto o restante do universo apenas observa ruído criptográfico.

---

Quarta Decisão — O Verdadeiro Tesouro São as Chaves

Aqui está o maior erro encontrado em auditorias.

Programadores fazem isto:

01 AES-KEY PIC X(32)
VALUE "123456789ABCDEF..."

Pronto.

A criptografia acabou.

Porque a chave virou parte do programa.

É como esconder a chave do cofre dentro do próprio cofre.

---

No Mainframe existe um verdadeiro "Banco Central das Chaves".

Ele chama-se:

ICSF.

Integrated Cryptographic Service Facility.

Ele conversa diretamente com:

Crypto Express.

CPACF.

RACF.

Certificados.

PKI.

Tokens.

Assinaturas digitais.

Toda a inteligência criptográfica mora ali.

---

Curiosidade

Crypto Express possui hardware resistente a ataques físicos.

Se alguém tentar abrir o equipamento, ele pode apagar automaticamente informações sensíveis armazenadas internamente.

É literalmente um cofre eletrônico.

---

Quinta Decisão — End-to-End Encryption

Imagine enviar uma carta.

Sem criptografia ponta-a-ponta.

Pessoa A

↓

Correios

↓

Carteiro

↓

Centro de Distribuição

↓

Destino

Todos conseguem abrir o envelope.

Agora imagine um envelope que somente o destinatário consegue abrir.

Nem o correio consegue.

Esse é o conceito de End-to-End Encryption.

---

WhatsApp.

Signal.

iMessage.

Todos utilizam esse princípio.

---

No ambiente corporativo isso reduz enormemente:

• espionagem;

• vazamentos internos;

• ataques contra intermediários;

• inspeção indevida de dados sensíveis.

---

Sexta Decisão — Backup Também é Produção

Essa talvez seja a maior surpresa para iniciantes.

Empresas gastam milhões protegendo produção.

Depois gravam backups em texto puro.

É como construir um bunker nuclear e deixar uma cópia da chave embaixo do tapete da recepção.

---

Backups precisam da mesma proteção que produção.

Ou até maior.

Porque normalmente contêm:

• todos os clientes;

• todos os históricos;

• todos os documentos;

• todas as senhas;

• todas as contas.

---

Bellacosa Mainframe

DFSMS.

DFDSS.

Storage Protect.

FDR.

Fitas.

Cloud Object Storage.

Tudo isso também precisa de criptografia.

Não existe "backup seguro" sem gerenciamento correto de chaves.

---

Sétima Decisão — Onde o TLS Termina?

Essa é uma decisão de arquitetura.

Imagine:

Cliente

↓

HTTPS

↓

Load Balancer

↓

HTTP

↓

Servidor

O usuário vê o cadeado.

Mas internamente...

Tudo está aberto.

Agora imagine:

HTTPS

↓

Load Balancer

↓

HTTPS

↓

API Gateway

↓

HTTPS

↓

CICS

↓

HTTPS

↓

Db2

Muito melhor.

Quanto menor o trecho sem criptografia, menor a superfície de ataque.

---

O Conceito de Zero Trust

Durante décadas dizia-se:

"Confie na rede interna."

Hoje a filosofia mudou.

Zero Trust afirma:

Nunca confie. Sempre verifique.

Até mesmo um servidor interno precisa provar quem é.

Essa mentalidade se encaixa perfeitamente em ambientes híbridos, APIs e aplicações distribuídas.

---

Oitava Decisão — Nem Todo Dado Vale Ouro

Essa talvez seja a decisão mais inteligente.

Não adianta gastar recursos criptografando imagens públicas.

Mas:

CPF.

PIX.

Cartão.

Biometria.

Prontuário médico.

Credenciais RACF.

Tokens OAuth.

Esses precisam de proteção máxima.

---

Esse conceito chama-se:

Classificação da Informação.

Sem classificação não existe segurança eficiente.

---

A IA Mudou o Cenário

Em 2026 a Inteligência Artificial trouxe um novo desafio.

Os agentes de IA conseguem:

• acessar APIs;

• consultar bancos;

• ler documentos;

• consumir logs;

• integrar sistemas.

Se eles receberem permissões excessivas, a criptografia pode continuar perfeita e, ainda assim, dados sensíveis serem expostos por meio de uma consulta autorizada.

Por isso surgiram conceitos como:

• AI Governance;

• Secret Management;

• Identity Federation;

• Least Privilege para Agentes;

• Auditoria de Prompts;

• Vaults para Credenciais.

A IA não precisa quebrar a criptografia.

Basta receber a chave por engano.

---

Criptografia no Universo IBM Z

O IBM Z foi projetado para tratar criptografia como parte da infraestrutura.

Entre seus principais recursos estão:

• CPACF (Central Processor Assist for Cryptographic Function): aceleração criptográfica por hardware diretamente nos processadores, reduzindo o impacto de desempenho de operações como AES e SHA.

• Crypto Express: módulos HSM dedicados para operações de alta segurança, geração e proteção de chaves, assinaturas digitais e criptografia assimétrica.

• ICSF (Integrated Cryptographic Service Facility): camada de software que integra aplicações COBOL, CICS, Db2 e RACF aos recursos criptográficos do hardware.

• RACF: controla autenticação, autorização e integra-se ao gerenciamento de certificados e políticas de acesso.

• Pervasive Encryption: permite criptografar datasets, bancos de dados, sistemas de arquivos e outros recursos de forma transparente.

Essa combinação faz do IBM Z uma das plataformas mais robustas para ambientes regulados, como bancos, seguradoras e governos.

---

Passo a Passo para um Programador COBOL Iniciante

Se você está começando agora, siga uma evolução prática:

1. Entenda a diferença entre criptografia, hash e assinatura digital. Eles resolvem problemas diferentes.

2. Aprenda onde a criptografia é aplicada: dados em repouso, em trânsito e em uso.

3. Nunca codifique chaves diretamente no programa COBOL. Utilize serviços apropriados como ICSF ou um gerenciador de segredos.

4. Conheça TLS e certificados digitais, mesmo que seu foco seja desenvolvimento COBOL. Grande parte das integrações modernas depende deles.

5. Estude RACF e gerenciamento de identidades, pois autenticação e autorização caminham junto com a criptografia.

6. Entenda o papel do CPACF e do Crypto Express, percebendo como o hardware acelera e protege operações criptográficas.

7. Aprenda sobre Pervasive Encryption e como ela protege datasets e bancos de dados sem exigir alterações nas aplicações.

8. Estude Zero Trust. A arquitetura de segurança moderna assume que nenhum componente é confiável por padrão.

---

Curiosidades que Pouca Gente Conhece

• Um hash (SHA-256) não é criptografia reversível. Seu objetivo é verificar integridade, não esconder dados.

• AES é um algoritmo simétrico: a mesma chave cifra e decifra.

• RSA e ECC são algoritmos assimétricos: utilizam pares de chaves pública e privada.

• O TLS normalmente combina criptografia assimétrica (para troca segura de chaves) e simétrica (para transmissão eficiente dos dados).

• O IBM Z consegue executar bilhões de operações criptográficas por dia com aceleração em hardware, protegendo transações financeiras em escala global.

• Muitos ataques famosos exploraram credenciais roubadas ou segredos mal armazenados, e não fraquezas nos algoritmos criptográficos.

---

O Grande Easter Egg Bellacosa Mainframe

Imagine que o Data Center seja a nave USS Enterprise.

O RACF é o oficial de segurança.

O ICSF é o cofre da Federação.

O Crypto Express é o motor de dobra criptográfico.

O CICS é o centro de operações.

O Db2 é a memória da nave.

O MQ é o sistema de comunicações.

O CPACF é o computador que acelera tudo.

E o programador COBOL?

É o engenheiro-chefe, responsável por garantir que todas essas peças funcionem em perfeita harmonia.

Porque, no fim das contas, a segurança não depende apenas da tecnologia. Ela depende das decisões tomadas por quem projeta e desenvolve o sistema.

---

Conclusão

Existe uma frase muito conhecida na engenharia de software:

"Sistemas raramente falham por causa da tecnologia; eles falham por causa das decisões."

Na criptografia acontece exatamente o mesmo.

AES continua extremamente seguro.

TLS continua extremamente seguro.

SHA-256 continua extremamente seguro.

O que costuma falhar é a arquitetura construída ao redor deles.

Uma chave armazenada junto aos dados, um backup sem criptografia, um ponto de término TLS mal definido ou um segredo exposto em um repositório Git são suficientes para transformar uma infraestrutura sofisticada em um castelo de cartas.

Para o programador COBOL que está entrando no universo do IBM Z, a grande lição é compreender que segurança deixou de ser responsabilidade exclusiva do administrador de sistemas. Ela faz parte do ciclo completo de desenvolvimento, desde a escrita do primeiro EXEC CICS até a proteção dos datasets, APIs, certificados, backups e integrações.

Como diria o Guia do Viajante das Galáxias:

"Não entre em pânico."

Mas acrescente uma nova regra ao manual do viajante dos Data Centers:

"Nunca subestime o poder de uma boa decisão arquitetural. Os melhores algoritmos do mundo não conseguem proteger um sistema projetado para confiar em tudo."

É essa mentalidade — muito mais do que qualquer algoritmo isolado — que diferencia um simples desenvolvedor de um verdadeiro arquiteto de soluções seguras em ambientes IBM Mainframe.