✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
💻 Zowe: O Guia Completo de Server, CLI, SDK e Explorer para Mainframe
Se você está entrando no universo Zowe, seja para modernizar aplicações z/OS ou integrar ambientes DevOps, este guia é para você. Vamos destrinchar componentes do Zowe, pacotes de instalação, SDKs, CLI, Explorer e políticas de suporte, do jeito Bellacosa Mainframe: direto, didático e cheio de dicas de prova IBM.
1️⃣ O que é Zowe?
Zowe é um framework open source que permite que desenvolvedores, mesmo sem profundo conhecimento de z/OS, acessem e integrem recursos mainframe usando CLI, APIs REST e GUI.
Ele suporta tanto z/OS nativo quanto ambientes containerizados (Docker/Kubernetes), trazendo agilidade e modernidade para o mainframe.
Principais objetivos:
Tornar z/OS acessível a desenvolvedores modernos
Permitir integração com DevOps e pipelines CI/CD
Oferecer APIs REST, CLI e GUI para operações mainframe
2️⃣ Zowe Server Components
O Zowe Server é distribuído em vários componentes que podem rodar no z/OS ou em containers.
Principais componentes:
Componente
Função
Plataforma
ZLUX
GUI web para navegação e dashboards
z/OS / Container
API Gateway
Mediação e roteamento de APIs REST
z/OS / Container
ZSS (Zowe Security Server)
Autenticação, autorização e gerenciamento de tokens
z/OS
File Explorer API
Serviços REST para manipulação de arquivos USS e PDS
z/OS / Container
⚠️ Nota: O Zowe CLI não é um servidor — ele roda no cliente.
Pacotes de distribuição do Zowe Server
Zowe Server pode ser instalado usando diferentes formatos:
SMP/E Package – Método clássico IBM para z/OS (RECEIVE → APPLY → ACCEPT)
Convenience Build (.pax file) – Binários compactados para extração e instalação em USS
Docker Container – Permite execução em containers Linux/Kubernetes
Dica Bellacosa: .msi e .deb não são usados para Zowe Server; eles são apenas para clientes ou sistemas externos.
3️⃣ Instalando Zowe via SMP/E
O SMP/E package contém:
FMID do Zowe (compactado em .pax)
Program Directory
Jobs auxiliares para instalação
Passo a passo:
Transferir o arquivo .pax para o USS
Extrair o conteúdo
Usar SMP/E commands: RECEIVE, APPLY, ACCEPT
Aplicar PTFs de correções ou atualizações
Atenção: após a instalação, é necessário criar instância Zowe, configurar segurança e iniciar started tasks. Não basta instalar o FMID.
4️⃣ Zowe CLI – A linha de comando
O Zowe CLI é um cliente que roda em Windows, Linux ou macOS.
Ele permite que você consuma APIs REST, interaja com USS, DB2, Jobs e muito mais, sem precisar abrir TSO ou ISPF.
Dica Bellacosa: Python SDK usa pip e Node.js SDK usa npm. Não confunda os dois!
6️⃣ Zowe Explorer – GUI no VSCode
O Zowe Explorer é uma extensão para VSCode, permitindo interações gráficas com z/OS.
Requisitos:
VSCode instalado
Perfis Zowe ou Zowe Team configurados (TCP/IP + credenciais)
Funcionalidades:
Navegação visual de USS e PDS
Execução de jobs TSO
Extensibilidade via VSCode APIs ou Zowe Explorer APIs
Dica: extensões adicionais podem ser criadas para expandir o Zowe Explorer.
7️⃣ Suporte das versões Zowe
A política de suporte segue o modelo clássico Active / Maintenance / End-of-Support:
Versão
Status
Releases / Correções
V3.x.x
Active
Novas funcionalidades a cada 6 semanas + fixes críticos e de segurança
V2.x.x
Maintenance
Apenas fixes críticos e de segurança, sem novas funcionalidades
V1.x.x
End-of-Support
Nenhum fix, nenhuma atualização
Atenção a pegadinhas de prova IBM:
Active = novas features + fixes
Maintenance = apenas fixes críticos
End-of-Support = nada
8️⃣ Conclusão
Zowe é a porta de entrada moderna para o mainframe, combinando:
Zowe Server (z/OS ou container)
Zowe CLI (Windows/Linux/macOS)
Zowe SDKs (Python/Node.js)
Zowe Explorer (GUI VSCode)
Se você quer dominar DevOps mainframe, integração z/OS e modernização de aplicações, Zowe é o seu aliado.
💡 Dica final Bellacosa Mainframe: memorize Server vs Client vs SDK vs Explorer, entenda instalação, perfis e suporte, e nunca confunda pip vs npm vs SMP/E. Isso salva em prova IBM e na vida real.
Bellacosa Mainframe apresenta o ibm mainframe parte I
☕ Um Café no Bellacosa Mainframe
Capítulo I — Não Entre em Pânico!
O Maior Equívoco da História da Computação
NÃO ENTRE EM PÂNICO.
Estas talvez sejam as duas palavras mais importantes que um Programador COBOL Padawan pode ler antes de iniciar sua jornada pelo universo do Mainframe.
Respire.
Guarde sua toalha... digo... seu manual de JCL.
Pegue seu café.
Ajuste o brilho do terminal 3270.
Estamos prestes a atravessar um buraco de minhoca tecnológico.
Nosso destino?
O computador mais mal compreendido da galáxia corporativa.
Bem-vindo ao Guia do Mochileiro Mainframe
Se algum explorador interestelar pousasse na Terra e resolvesse aprender computação apenas lendo redes sociais, provavelmente encontraria algumas "verdades absolutas":
"Mainframe morreu."
"COBOL é linguagem dos dinossauros."
"Tudo roda na nuvem."
"Hoje é só Kubernetes."
Depois de alguns minutos, esse viajante concluiria:
— Interessante... então quem processa bilhões de dólares por dia?
Silêncio.
— Quem controla cartões de crédito?
Silêncio novamente.
— Quem executa milhões de transações bancárias por segundo?
Mais silêncio.
Então alguém responderia timidamente:
"...o mainframe."
É exatamente aqui que começa nossa aventura.
A Galáxia Está Cheia de Mitos
Toda civilização cria histórias.
Algumas são lendas.
Outras são mitos.
No universo da computação existe uma das maiores delas.
Ela diz:
"Os mainframes desapareceram."
Curiosamente, essa história é contada há mais de quarenta anos.
Enquanto isso...
os mainframes continuam trabalhando.
Sem reclamar.
Sem aparecer em manchetes.
Sem precisar de marketing.
É como aquele velho engenheiro da nave que nunca aparece nas fotos da tripulação, mas sem ele ninguém sairia da órbita.
O Grande Mal-Entendido
Imagine uma nave espacial gigantesca.
Ela possui:
milhares de sistemas
centenas de motores
redundância completa
escudos
sensores
computadores
Agora imagine alguém dizendo:
"Vamos substituir tudo isso por milhares de scooters voadoras."
É exatamente isso que aconteceu nos anos 90.
O mercado acreditou que centenas de pequenos servidores substituiriam completamente os grandes computadores corporativos.
Parecia lógico.
Mais barato.
Mais moderno.
Mais distribuído.
Na teoria.
Na prática...
descobriu-se que distribuir problemas também significa distribuir falhas.
O Universo Não Liga para Marketing
Existe uma lei cósmica pouco conhecida.
Ela diz:
A Física ignora PowerPoint.
Da mesma forma...
A Engenharia ignora Marketing.
Você pode afirmar mil vezes que um sistema é moderno.
Mas, quando um banco precisa processar:
50 milhões de PIX
cartões
TED
DOC
compensação
folha salarial
previdência
...a matemática começa a fazer perguntas difíceis.
Disponibilidade.
Integridade.
Consistência.
Latência.
Escalabilidade.
Nesse momento, slogans deixam de funcionar.
Arquitetura passa a importar.
A Diferença Entre Impressionar e Funcionar
No universo existem dois tipos de tecnologia.
Aquela que impressiona.
E aquela que funciona durante cinquenta anos.
Nem sempre são a mesma coisa.
Um smartphone impressiona.
Um data center impressiona.
Uma IA generativa impressiona.
Mas existe uma pergunta mais interessante:
Quem continua funcionando depois de quarenta anos sem interromper os negócios do planeta?
É aqui que surge o protagonista desta história.
O Computador Invisível
Você provavelmente nunca viu um IBM Z pessoalmente.
Muita gente nunca verá.
Mesmo assim...
é extremamente provável que você já tenha utilizado um hoje.
Talvez dezenas de vezes.
Quando passou seu cartão.
Quando fez um PIX.
Quando consultou saldo.
Quando comprou uma passagem aérea.
Quando utilizou o SUS.
Quando declarou imposto.
Quando acessou uma seguradora.
Existe uma boa chance de algum pedaço dessa transação ter passado por um mainframe.
O computador mais importante da sua vida provavelmente é aquele que você nunca viu.
O Paradoxo da Invisibilidade
Existe um fenômeno curioso.
Quanto melhor um sistema funciona...
menos ele aparece.
Ninguém abre um jornal para ler:
"Hoje o banco funcionou normalmente."
Isso não vira notícia.
A notícia aparece quando algo quebra.
O sucesso do mainframe é justamente sua discrição.
Ele trabalha em silêncio.
Há décadas.
O Zoológico da Computação
Vamos imaginar que toda a computação seja um grande zoológico galáctico.
Ali vivem criaturas muito diferentes.
O notebook.
Ágil.
Curioso.
Explorador.
O smartphone.
Pequeno.
Sempre conectado.
O servidor Linux.
Versátil.
Escalável.
Os clusters Kubernetes.
Organizados como colônias de insetos altamente cooperativos.
E então...
bem no centro...
existe uma criatura gigantesca.
Silenciosa.
Elegante.
Que não precisa provar nada para ninguém.
Esse é o Mainframe.
Ele não corre.
Ele não faz barulho.
Mas sustenta praticamente toda a infraestrutura econômica da civilização.
Supercomputador?
Não exatamente.
Aqui encontramos outro erro muito comum.
As pessoas confundem:
Supercomputador
com
Mainframe.
São espécies completamente diferentes.
Um supercomputador foi criado para resolver problemas científicos.
Ele pergunta:
"Quantos cálculos posso fazer por segundo?"
Já um mainframe pergunta:
"Quantas empresas conseguem dormir tranquilas porque eu não falhei hoje?"
Parece sutil.
Mas muda absolutamente tudo.
Um procura velocidade.
O outro procura confiança.
Como explica Wilhelm G. Spruth, sistemas científicos são otimizados para poder computacional, enquanto sistemas comerciais são projetados para sustentar operações críticas de governos e empresas com foco em disponibilidade, segurança e processamento contínuo.
O Maior Erro da História
Durante décadas, muita gente comparou o Mainframe usando apenas uma métrica:
MIPS.
Depois:
GHz.
Depois:
Número de CPUs.
Era como comparar um cargueiro interestelar com um caça apenas pela velocidade máxima.
São máquinas construídas para missões completamente diferentes.
O cargueiro não foi feito para vencer corridas.
Foi feito para garantir que a carga chegue inteira.
Sempre.
O Clube dos Cinco Noves
Existe um número mágico.
99,999%.
Parece pequeno.
Mas representa uma obsessão.
Cinco noves significam apenas alguns minutos de indisponibilidade por ano.
Essa não é apenas uma especificação técnica.
É uma filosofia.
Todo projeto.
Todo transistor.
Toda linha de código.
Toda decisão de arquitetura pergunta:
"Isso aumenta ou diminui a disponibilidade?"
Esse pensamento moldou toda a evolução do System z.
O Verdadeiro Combustível da Nave
Curiosamente...
o combustível do Mainframe nunca foi eletricidade.
Foi confiança.
Empresas não investem bilhões porque gostam de computadores grandes.
Elas investem porque precisam dormir.
Quando bilhões de reais passam por um sistema todos os dias...
a confiança vale muito mais do que velocidade.
O Relatório que Desafia o Consenso
Foi exatamente isso que Wilhelm G. Spruth procurou demonstrar em seu relatório System z and z/OS Unique Characteristics.
Em vez de discutir propaganda ou modismos, ele reuniu dezenas de características técnicas — arquitetura, confiabilidade, segurança, virtualização, I/O, gerenciamento de cargas, CICS, Parallel Sysplex e muitas outras — para mostrar que o mainframe incorporava tecnologias avançadas muito antes de elas se popularizarem em outras plataformas.
A mensagem central do autor pode ser resumida assim:
Muitas tecnologias consideradas "modernas" nasceram ou amadureceram primeiro no universo do mainframe.
Essa afirmação não significa que outras plataformas não evoluíram. Significa apenas que, em diversas áreas, o IBM Z percorreu esse caminho muito antes.
O Que Nos Espera Pela Frente?
Nossa viagem está apenas começando.
Nos próximos capítulos, visitaremos setores fascinantes dessa gigantesca nave tecnológica:
Como uma arquitetura criada em 1964 continua evoluindo sem quebrar compatibilidade.
Por que a recuperação automática de falhas é tratada como parte do hardware.
Como milhares de transações compartilham o mesmo ambiente de execução no CICS.
O segredo do Parallel Sysplex para unir vários mainframes em um único sistema lógico.
Como LPARs, PR/SM e WLM inspiraram conceitos modernos de virtualização e gerenciamento de recursos.
Por que I/O, segurança e disponibilidade são tratados como cidadãos de primeira classe.
Cada parada revelará que o IBM Z não é apenas um computador poderoso, mas o resultado de décadas de engenharia orientada à continuidade dos negócios.
Diário de Bordo do Padawan COBOL
Antes de seguir para o próximo capítulo, guarde três lições:
✅ Nem toda tecnologia importante aparece nas manchetes.
✅ Nem toda inovação nasce na plataforma mais popular.
✅ Em engenharia, longevidade não é sinônimo de obsolescência; muitas vezes é evidência de uma arquitetura excepcionalmente bem concebida.
Agora ajuste o cinturão da cadeira do terminal 3270, mantenha sua curiosidade sempre à mão e lembre-se da regra número um de qualquer explorador da galáxia dos computadores comerciais:
Não entre em pânico. O mainframe está exatamente onde sempre esteve: discretamente mantendo a civilização funcionando.
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
☕ Bellacosa Mainframe Blog — z/OS 1.4: A Consolidação da Era 64 bits e a Maturidade da z/Architecture Por Vagner Bellacosa — Café quente, spool limpo e memória virtual de sobra
🕰️ z/OS 1.4 – O equilíbrio entre estabilidade e inovação
O z/OS 1.4, lançado oficialmente em outubro de 2003, marcou o fechamento do primeiro ciclo de maturação do novo sistema operacional da IBM.
Se o z/OS 1.0 (2000) foi o nascimento da z/Architecture, o 1.4 foi o momento em que o mainframe se estabilizou em 64 bits, ganhou robustez corporativa, e começou a se integrar de forma mais natural com o mundo distribuído — redes, Java, web e segurança digital.
Essa versão estreou junto com o IBM z990 (System z9 “T-Rex”), trazendo uma combinação de força bruta e refinamento técnico que consolidou o mainframe como plataforma universal de TI corporativa.
⚙️ Ficha técnica — z/OS 1.4
Categoria
Detalhes
Lançamento oficial
Outubro de 2003
Hardware de referência
IBM z990 (System z9 EC)
Arquitetura
z/Architecture 64 bits madura
Versões JES
JES2 1.13 / JES3 1.13
Modo de endereçamento
24, 31 e 64 bits simultâneos
Kernel / Base MVS
MVS núcleo estabilizado com z/OS UNIX Services aprimorado
Firmware PR/SM
Nível 70.x – com suporte a Dynamic LPAR Resource Management
Gerenciamento de CPU
Créditos dinâmicos com balanceamento automático via WLM
Uso de memória
Expansão plena de real storage 64-bit com suporte a “Large Pages”
O z/OS 1.3 (2002) já tinha estabilizado o modo 64-bit, mas ainda dependia de ajustes na performance e integração com workloads mistos.
O 1.4 trouxe grandes mudanças no núcleo e nos serviços de sistema, como:
Melhorias em gerenciamento de memória 64-bit
Introdução de Large Pages (1MB), reduzindo page faults e aumentando a eficiência em aplicações Java e DB2.
Novos algoritmos de Real Storage Manager (RSM) para cache em memória expandida.
Agora com Dynamic LPAR Resource Management, permitindo redistribuição automática de CPUs e memória entre partições sem reinicialização.
Implementação de LPAR groups e políticas de CPU weight dinâmico — o embrião do que seria o Shared Processor Pools no z10.
Suporte a novas instruções de máquina z990
Instruções avançadas para criptografia AES, compressão, e inteiros de 64 bits otimizados.
Introdução do HiperDispatch experimental, melhorando a afinidade CPU-thread.
Melhoria em instruções de E/S para FICON e OSA-Express2 (rede gigabit).
Nova camada de segurança
O RACF 1.9 passou a integrar o LDAP nativamente, facilitando autenticação unificada.
Introdução do z/OS Security Server como produto-base.
Criptografia SSL acelerada via CPACF (Crypto Processor Assist Facility) do z990.
Otimização de Workload Manager (WLM)
Novo modo Goal Mode adaptativo, com redistribuição automática de recursos por performance class.
Integração nativa com Sysplex Distributor, abrindo caminho para balanceamento de cargas TCP/IP em larga escala.
🧠 Avanços em memória e performance
O z/OS 1.4 trouxe uma das maiores evoluções em real storage management desde o MVS/ESA.
A IBM aprimorou o RSM (Real Storage Manager) e introduziu o conceito de dataspaces expandidos em 64 bits, permitindo:
Maior isolamento entre aplicações batch, CICS e USS;
Cache persistente para DB2 e VSAM em memória real;
Redução drástica de page swapping;
Uso de hiperspaces 64-bit para armazenar tabelas de alta frequência.
O impacto disso foi enorme: aplicações como DB2 V8 e CICS TS 2.3 atingiram ganhos de 20 a 35% de throughput em relação à versão anterior, apenas pela nova forma de gestão de memória.
🔌 Integração e aplicações internas
O z/OS 1.4 trouxe a maturidade das camadas de integração corporativa:
UNIX System Services (USS) mais estável e rápido, com suporte pleno a threads POSIX 64-bit;
Java SDK 1.4.1 integrado com suporte a Just-In-Time (JIT) otimizado para Telum e CPACF;
WebSphere Application Server V5 nativo;
z/OSMF ainda não existia, mas o RMF Monitor III ganhou interface mais amigável e ferramentas de diagnóstico refinadas.
No backend, DB2 V8 ganhou suporte total a Unicode e 64-bit buffers, e o IMS 8 evoluiu para melhor desempenho em message queues.
🔐 Segurança, rede e conectividade
O z/OS 1.4 consolidou a IBM como líder em segurança corporativa:
Introdução do Integrated Cryptographic Service Facility (ICSF) compatível com novos processadores cripto do z990.
Melhorias em SSL/TLS e RACF Digital Certificate Management.
TCP/IP Stack revisada — melhor throughput, NAT, IPv6 experimental, e melhor integração com Sysplex Distributor.
A pilha de rede já operava em modo multi-stack, o que significava que uma única LPAR podia servir múltiplos contextos TCP/IP, algo essencial para ambientes com múltiplos clientes.
⚙️ Firmware PR/SM e créditos de CPU
O PR/SM (hypervisor de hardware) passou a operar com Dynamic Resource Balancing, alocando CPU e memória com base no workload WLM.
Foi aqui que surgiram os créditos dinâmicos de CPU, mecanismo que mede o “crédito” de uso de partições e ajusta o peso de cada uma sem interrupção — o ancestral do Dynamic Capacity Upgrade on Demand (CUoD).
Isso trouxe dois ganhos imediatos:
Melhor aproveitamento da CPU física (menos idle time).
Redução de custos de licenciamento (LPARs mais equilibradas).
☕ Curiosidades e bastidores Bellacosa
O z/OS 1.4 foi a última versão da linha 1.x antes da chegada do z/OS 1.5, que seria o precursor direto do z/OS 2.1.
Internamente na IBM, essa versão era apelidada de “Rock Solid Release”, devido à sua estabilidade absurda — muitas empresas permaneceram nela por mais de uma década.
Foi também o primeiro z/OS amplamente adotado em bancos e seguradoras como plataforma de e-business.
O WebSphere 5.0 foi o primeiro middleware certificado para rodar 100% dentro do USS em produção crítica.
Alguns programadores veteranos brincavam:
“No z/OS 1.4, você liga o café, e o IPL termina antes de esfriar.”
🔍 Resumo técnico comparativo
Item
z/OS 1.3
z/OS 1.4
Arquitetura
64 bits (inicial)
64 bits madura
PR/SM
Estático com updates
Dinâmico (realocação sem IPL)
WLM
Goal Mode básico
Goal Mode adaptativo
Memória
Padrão 4K pages
Suporte a Large Pages (1MB)
RACF
v1.8
v1.9 + LDAP
Criptografia
CPACF inicial
CPACF AES + SSL integrado
Java
1.3
1.4.1 + JIT
TCP/IP
IPv4
IPv4 + IPv6 parcial
USS
Threads limitadas
Multi-thread 64-bit
🧭 Conclusão Bellacosa
O z/OS 1.4 foi o ponto de inflexão que transformou o mainframe moderno em uma plataforma realmente integrada, segura e escalável.
Foi ali que o casamento entre hardware (z990) e software (z/OS) atingiu maturidade plena, pavimentando o caminho para a automação e virtualização avançada que conhecemos hoje.
“Enquanto o mercado falava de servidores Linux, o z/OS 1.4 já entregava uptime de 99,999%, criptografia em hardware e Java nativo em 2003. O resto do mundo ainda estava acordando; o mainframe já estava tomando o segundo café.” ☕
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988