Bellacosa Mainframe apresenta o Ibm Z e ISeries

☕ Um Café no Bellacosa Mainframe

Nathan Bateman Abriu o Rack — E Descobriu que IBM Z, IBM i e AIX Não Eram Três Mainframes Brigando Pelo Mesmo Corpo

Ou: por que comparar um z/OS, um AS/400 e um AIX apenas pelo tamanho do gabinete é como olhar Ava, Kyoko e Nathan em Ex Machina e concluir que todos são apenas “pessoas em uma casa bonita”

Há uma cena invisível em quase toda conversa sobre plataformas IBM. Alguém aponta para um rack preto, vê uma tela verde, encontra um programa COBOL e anuncia, com a segurança de quem acabou de descobrir fogo:

— Ah, então isso é mainframe.

Nathan Bateman, o bilionário-programador de Ex Machina, provavelmente soltaria uma risada curta, colocaria mais gelo no copo e responderia:

— Você viu a carcaça. Agora tente descobrir o que está pensando lá dentro.

Essa é a pergunta que separa o programador que decorou três siglas daquele que começa a entender o mapa do data center. Porque IBM Z, IBM i — antigo AS/400/iSeries — e AIX não são concorrentes idênticos vestidos com logos diferentes. Eles atendem a necessidades distintas, têm culturas operacionais próprias e, principalmente, tratam o software de maneiras muito diferentes.

Para o padawan COBOL, isso é ouro. Afinal, o mesmo MOVE, o mesmo IF, o mesmo PERFORM e até o mesmo EXEC SQL podem parecer familiares em mais de um ambiente. Porém, o que acontece antes do programa começar — e depois do GOBACK — muda bastante.

Hoje vamos entrar na casa de Nathan Bateman, abrir três portas e descobrir qual plataforma existe atrás de cada uma.

Não mexa no drone. E não aceite uma bebida sem olhar o log de auditoria.

Prólogo — O erro começa quando chamamos tudo de “mainframe”

Vamos cortar o primeiro cabo errado da conversa.

IBM Z é uma família de computadores e uma arquitetura própria: a z/Architecture. É o sucessor histórico dos grandes sistemas IBM que começaram a moldar a computação empresarial no século passado. É onde vivem, entre muitos outros, z/OS, CICS, IMS, Db2 for z/OS, JES2, RACF e aquela floresta de JCL que um dia todo iniciante jura que nunca irá entender.

IBM i, por outro lado, é um sistema operacional. Seu nome antigo era OS/400; ele rodou em máquinas chamadas AS/400, depois iSeries e System i. Hoje ele roda em servidores IBM Power.

AIX também é um sistema operacional. É o UNIX corporativo da IBM e também roda em servidores IBM Power.

Guarde esta frase como se fosse a senha do quarto de Ava:

IBM i e AIX podem dividir o mesmo hardware IBM Power. IBM Z é outra plataforma, com outra arquitetura, outra linhagem e outra lógica operacional.

Portanto, quando alguém disser “eu trabalho com iSeries”, você pode traduzir mentalmente:

“Esta pessoa provavelmente trabalha com IBM i em um servidor IBM Power.”

Quando alguém disser “eu trabalho com AIX”, a tradução é:

“Esta pessoa trabalha com UNIX corporativo em IBM Power.”

E quando alguém disser “eu trabalho com mainframe IBM Z”, aí sim estamos falando do universo z/OS, LPAR, Sysplex, CICS, IMS, Db2 for z/OS, canais e transações que carregam o país nas costas enquanto o Twitter discute se COBOL morreu em 1998.

Spoiler: o COBOL não morreu. Ele só não teve tempo de responder porque estava fechando o lote noturno.

1. Os três suspeitos na sala de vidro

Nathan observa três máquinas por trás de uma parede de vidro. À primeira vista, todas fazem algo muito parecido: armazenam dados, executam programas, conversam com redes e atendem usuários.

Mas propósito não é aparência.

Plataforma	O que ela é de fato	Pergunta que ela responde melhor
IBM Z	Arquitetura e plataforma de grande porte	“Como processar transações críticas em enorme escala com controle e disponibilidade?”
IBM i	Sistema operacional integrado no IBM Power	“Como executar o negócio com banco, segurança e aplicações profundamente integrados?”
AIX	UNIX corporativo no IBM Power	“Como hospedar cargas UNIX críticas, flexíveis e altamente virtualizadas?”

Ava, em Ex Machina, não era apenas um robô com rosto bonito. Ela era resultado da integração entre modelo, dados, sensores, objetivos e manipulação do ambiente.

O IBM i tem um pouco desse espírito: ele não é só “um sistema que roda programas”. Banco, objetos, segurança, linguagens e administração foram pensados como partes de uma mesma casa.

O IBM Z, por sua vez, parece mais o prédio inteiro: redundância, portas reforçadas, elevadores independentes, câmeras, energia protegida e procedimentos para que uma falha em um cômodo não derrube a cidade.

Já o AIX é a oficina UNIX premium de Nathan: poderosa, configurável e muito capaz — mas exige que o operador conheça as ferramentas, os módulos e o que está conectando em cada ponto.

2. IBM Z: o sistema que nasceu para não perder a compostura

O IBM Z foi feito para situações em que “depois a gente vê” não é uma frase aceitável.

Imagine uma autorização de cartão. O cliente aproxima o celular da maquininha. Em poucos instantes, o banco precisa verificar conta, cartão, limite, risco, regras antifraude, saldo, condições de parcelamento, registros legais e comunicação com outras redes.

Se o sistema responder errado, alguém perde dinheiro.

Se responder duas vezes, alguém perde dinheiro duas vezes.

Se gravar metade da transação, o time de suporte ganha uma madrugada inesquecível.

É nesse tipo de cenário que o Z mostra seu talento.

No z/OS, uma transação CICS pode chamar um programa COBOL, executar SQL no Db2, atualizar registros, produzir logs de recuperação e devolver uma resposta em milissegundos. Tudo isso com mecanismos de isolamento, segurança e recuperação que foram aprimorados por décadas.

Não é apenas “uma CPU muito rápida”. É uma plataforma que trata processamento, memória, I/O, criptografia, virtualização e recuperação como partes do mesmo crime a ser solucionado.

Os processadores do Z não são todos iguais

No mundo x86, é comum alguém dizer: “a máquina tem tantos cores”. No Z, essa frase é só o começo da investigação.

Existem diferentes tipos de processadores para diferentes trabalhos:

CP: o processador central que executa z/OS e cargas tradicionais.
zIIP: processador especializado que pode receber trabalho elegível de Db2, Java, XML, compressão, rede e outros serviços.
IFL: processador destinado a Linux on IBM Z.
ICF: voltado à Coupling Facility, peça importante de um Parallel Sysplex.
SAP: processador que cuida de I/O e ajuda a evitar que a CPU principal perca tempo carregando malas.

Para o iniciante, pense assim: em vez de obrigar o gerente do banco a descarregar o caminhão, atender o caixa, conferir o cofre e preencher o relatório, o Z tem equipes especializadas.

É por isso que comparar um IBM Z com outro servidor só pelo número de cores é uma comparação incompleta. A pergunta correta é:

Quantas transações, com que latência, com qual nível de integridade, segurança, recuperação e disponibilidade essa arquitetura sustenta?

No IBM z17, por exemplo, a tecnologia Telum II trabalha com cores de alta frequência, grandes caches, aceleração de IA e recursos de I/O integrados. O objetivo não é vencer uma competição de marketing de GHz; é responder rápido a cargas transacionais e decisões de risco no momento em que elas acontecem.

Nathan olharia para um painel de fraude em tempo real e diria:

— A inteligência não vale nada se ela chegar depois que o dinheiro saiu.

E ele estaria certo.

3. Um pequeno programa COBOL, uma grande diferença de ambiente

Veja este esqueleto conceitual:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. APROVA-PAGAMENTO.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-VALOR              PIC 9(9)V99.
       01  WS-LIMITE             PIC 9(9)V99.
       01  WS-STATUS             PIC X(01).

       PROCEDURE DIVISION.
           IF WS-VALOR <= WS-LIMITE
               MOVE 'A' TO WS-STATUS
           ELSE
               MOVE 'N' TO WS-STATUS
           END-IF

           GOBACK.

O COBOL acima pode fazer sentido em muitas plataformas. Mas o universo ao redor dele muda tudo.

No z/OS, esse programa talvez seja chamado pelo CICS. Os valores podem vir de um COMMAREA ou de um container. O limite pode ser consultado em Db2 for z/OS. A atualização pode envolver COMMIT controlado pela transação. O acesso pode estar protegido por RACF e o programa pode ter sido compilado, link-editado e implantado por uma cadeia de DevOps corporativa.

No IBM i, ele pode acessar Db2 for i, bibliotecas e objetos do sistema de maneira muito integrada. A lógica pode coexistir com RPG, CL e SQL em uma operação empresarial completa.

No AIX, o COBOL pode fazer parte de uma aplicação UNIX: chamado por shell scripts, integrado a Java, conectado a Db2 ou Oracle, executado em um ambiente de middleware e automação.

O programa é parecido. A cidade onde ele mora, não.

4. IBM i: onde o banco de dados mora dentro da casa

O IBM i é uma das plataformas mais mal compreendidas por quem nunca trabalhou nela. Muita gente imagina que ele é um mainframe menor, um servidor antigo ou uma tela preta com RPG.

Ele é bem mais interessante.

No IBM i, o banco Db2 for i é parte integrante do sistema operacional. Isso muda a conversa. Em muitos ambientes, banco de dados é algo que você instala, configura, atualiza, monitora, licencia, integra e protege separadamente.

No IBM i, a relação é mais orgânica.

Você encontra:

bibliotecas;
objetos;
arquivos físicos;
arquivos lógicos;
índices;
programas;
filas;
perfis de usuário;
journals;
permissões;
SQL;
auditoria.

Tudo isso faz parte de uma mesma arquitetura.

A metáfora de Nathan Bateman aqui seria a casa de vidro: o que parece apenas decoração está conectado ao sistema inteiro. Uma porta não é só uma porta; ela depende de sensores, regras, permissões e controle central.

No IBM i, um usuário não recebe apenas permissão genérica para “entrar no sistema”. Ele pode ter autoridade sobre objetos específicos: usar, alterar, executar, apagar, administrar.

Isso é muito valioso para uma empresa que roda ERP, estoque, faturamento, produção, transporte, folha e contas a receber.

Exemplo prático: a distribuidora que não pode errar

Pense numa empresa de distribuição. Um vendedor lança um pedido. O sistema precisa:

validar o cliente;
verificar crédito;
reservar estoque;
calcular imposto;
aplicar desconto autorizado;
gerar faturamento;
atualizar contas a receber;
enviar a ordem à expedição;
preservar rastreabilidade.

Em muitos IBM i, essa operação vive em um ecossistema altamente integrado de RPG, COBOL, CL, SQL e Db2 for i.

Não significa que todo IBM i seja mágico, moderno ou bem escrito. Também existem monstros de código, regras de negócio escondidas em 47 programas e aquela sub-rotina que ninguém toca porque “foi o Seu Mário quem fez em 1994”.

Mas a plataforma oferece uma base extremamente coesa.

Easter egg: o Seu Mário não desapareceu. Ele virou um CALL 'MARIO01' sem documentação, executado apenas na última sexta-feira útil do mês.

5. AS/400, iSeries e IBM i: a linha do tempo que confunde novatos

Se você ouvir todos estes nomes, não entre em pânico:

AS/400;
OS/400;
iSeries;
System i;
IBM i;
Power Systems.

Eles pertencem à mesma história, mas não são sinônimos perfeitos.

Nome	Significado prático
AS/400	Linha histórica de servidores IBM lançada em 1988
OS/400	Sistema operacional original da linha
iSeries / System i	Nomes posteriores da família
IBM i	Nome atual do sistema operacional
IBM Power	Família atual de hardware onde IBM i pode rodar

A frase moderna e tecnicamente melhor é:

“A aplicação roda em IBM i sobre IBM Power.”

É como dizer que um programa COBOL roda em z/OS sobre IBM Z. Separar software e hardware ajuda a desmontar mitos.

6. AIX: o UNIX que não veio brincar de servidor de arquivos

Se IBM i é uma cidade empresarial integrada, o AIX é uma cidade UNIX planejada para cargas corporativas robustas.

AIX significa Advanced Interactive eXecutive. Ele é o UNIX proprietário da IBM para Power Systems e tem uma longa presença em bancos, telecomunicações, SAP, Oracle, middleware, grandes aplicações Java e infraestruturas que exigem alta disponibilidade.

Para um profissional que conhece Linux, muita coisa parece familiar:

shell;
processos;
permissões;
scripts;
TCP/IP;
sistemas de arquivos;
automação;
compiladores;
serviços em background.

Mas AIX tem seu próprio sotaque. Você encontrará ferramentas e conceitos como:

SMIT, a interface administrativa clássica;
LPAR, a partição lógica;
VIOS, o Virtual I/O Server;
LVM, o gerenciador de volumes;
NIM, para instalação e administração em rede;
mksysb, para imagem de backup;
errpt, para investigar erros;
nmon, para observação de desempenho;
PowerHA, para alta disponibilidade.

Se o IBM i frequentemente diz “eu já trouxe muitas peças encaixadas”, o AIX diz:

“Eu lhe dou um UNIX empresarial muito sólido. Agora me diga como você quer construir sua solução.”

Isso faz dele excelente para ambientes que precisam de flexibilidade, integração com produtos de mercado e uma operação UNIX madura.

7. O segredo: IBM i e AIX podem morar no mesmo IBM Power

Aqui está uma das cenas mais legais desse filme.

Você pode ter um servidor IBM Power dividido em partições lógicas — LPARs — e cada uma delas executar um sistema operacional diferente.

Por exemplo:

LPAR	Sistema	Papel
LPAR 1	IBM i	ERP, estoque e faturamento
LPAR 2	AIX	Middleware ou banco corporativo
LPAR 3	Linux	APIs, containers e observabilidade
LPAR 4	VIOS	Virtualização de I/O e acesso a storage

Isso é feito com tecnologias como PowerVM e VIOS. A máquina física fornece CPU, memória, adaptadores de rede e storage; o hypervisor reparte esses recursos com isolamento e controle.

É parecido com apartamentos no mesmo edifício, mas com paredes estruturais muito mais sérias que as de uma VM comum criada numa tarde de sexta-feira.

O IBM Power11 possui modelos compactos, como os de 2U, e modelos empresariais de rack completo. Um Power S1122 pode chegar a 60 cores e 4 TB de memória; no topo, um Power E1180 pode chegar a 256 cores e 64 TB de memória DDR5.

E aqui vem a lição que Nathan daria batendo na mesa:

Hardware compartilhado não significa destino compartilhado.

IBM i e AIX podem usar o mesmo Power. Ainda assim, um programa RPG, um batch COBOL, uma aplicação AIX e uma API Linux terão comportamentos, equipes, ferramentas e exigências diferentes.

8. Velocidade: por que GHz é a isca perfeita para iniciantes

“Qual é mais rápido?”

É uma pergunta legítima. Também é perigosamente incompleta.

O z17 possui tecnologia de core de frequência muito alta; Power11 trabalha, conforme modelo e tipo de processador, aproximadamente na faixa de 3,8 a 4,4 GHz. Mas GHz sozinho não mede valor de negócio.

Imagine dois cozinheiros.

Um corta vegetais muito rápido. O outro coordena uma cozinha inteira, recebe ingredientes, evita desperdício, mantém higiene, entrega cem pratos juntos e não deixa a sobremesa cair no chão.

Quem é “mais rápido”?

Depende do trabalho.

Em sistemas corporativos, desempenho depende de:

instruções executadas por ciclo;
cache;
latência de memória;
largura de banda;
quantidade de cores;
SMT e threads;
I/O;
rede;
acesso a disco ou NVMe;
qualidade do SQL;
índices;
locks;
desenho das transações;
concorrência;
configuração de virtualização.

Um SELECT lento não melhora porque você gritou “4 GHz!” perto do rack.

Ele pode estar lento porque:

não há índice adequado;
o predicado não é indexável;
há contenção;
a aplicação abre e fecha conexão demais;
o programa busca uma linha de cada vez;
a tabela cresceu sem revisão;
o buffer pool está pressionado;
o storage está esperando;
o commit é feito no lugar errado.

Para o COBOL iniciante, esta é uma regra de ouro:

Antes de pedir mais CPU, descubra se o programa está trabalhando ou esperando.

Nathan não culparia Ava por ser lenta antes de olhar os sensores, a rede, as permissões e o código que definia o comportamento dela. O mesmo vale para seu batch noturno.

9. Tamanho e energia: nem um monstro, nem uma torradeira

O IBM Z pode ocupar de um a vários racks de data center. Um grande z17 é uma máquina de porte físico e elétrico relevante. Isso não é defeito; é consequência da capacidade, das redundâncias, dos canais de I/O e da infraestrutura construída para cargas críticas.

Os servidores IBM Power possuem uma faixa física maior:

modelos menores de 2U;
modelos de 4U;
sistemas maiores compostos por múltiplas gavetas e rack completo.

Mas não caia na pegadinha de comparar apenas consumo instantâneo.

Se um IBM Z consolida centenas de servidores, reduz licenças, elimina camadas redundantes, diminui operações manuais e concentra transações de forma segura, seu custo energético deve ser avaliado contra todo o ambiente substituído, não contra um servidor pequeno isolado.

Da mesma forma, um IBM Power com IBM i pode manter uma operação de negócio inteira em uma plataforma compacta, estável e administrável por uma equipe menor do que uma arquitetura espalhada em dezenas de máquinas.

A métrica madura não é:

“Quantos watts esse gabinete consome?”

É:

“Quanto trabalho crítico, com qual disponibilidade e com quantos componentes, esse ambiente entrega por watt, por metro quadrado e por pessoa operacional?”

10. Segurança: três filosofias, uma mesma obrigação

A imagem que inspirou esta conversa acerta ao destacar segurança, mas precisa de nuance.

No IBM Z, o z/OS usa o conceito de SAF, uma estrutura que permite integrar produtos de segurança. O exemplo clássico é o RACF. Ele controla identidades, recursos, grupos, permissões, auditoria e acesso a elementos importantes do ambiente.

No IBM i, a segurança é fortemente orientada a objetos, perfis e authorities. O sistema sabe que uma biblioteca, arquivo, programa, fila ou objeto não são apenas arquivos soltos jogados em diretórios.

No AIX, você encontra o universo UNIX corporativo: usuários, grupos, permissões, ACLs, RBAC, LDAP, Kerberos, PAM, SSH, ferramentas de auditoria e integração com soluções de identidade.

Nenhum deles dispensa administração.

Uma senha fraca continua sendo uma senha fraca em qualquer arquitetura. Um perfil excessivamente privilegiado continua perigoso. E o usuário *ALLOBJ, o UID 0, ou um ID com poder total em z/OS pode transformar uma operação tranquila em roteiro de suspense.

Easter egg de segurança: se Nathan Bateman tivesse usado segregação de funções, auditoria independente e menos acesso irrestrito dentro de casa, Ex Machina talvez tivesse virado um documentário de conformidade de 42 minutos.

11. O mapa para o programador COBOL padawan

Se você está começando, não tente decorar tudo em uma noite. Siga um caminho.

Passo 1 — Descubra onde seu programa vive

Pergunte:

Roda em z/OS, IBM i ou AIX?
É online ou batch?
É COBOL puro, COBOL com SQL, COBOL CICS ou COBOL chamado por outro processo?
Qual banco está envolvido?
Como ele recebe entrada e entrega saída?

Essas perguntas são melhores que “qual tela eu abro?”.

Passo 2 — Aprenda a unidade de organização local

No z/OS, você encontrará datasets, membros, JCL, PROCs, jobs, spool e logs.

No IBM i, encontrará bibliotecas, objetos, filas, comandos CL, jobs e subsistemas.

No AIX, encontrará diretórios, arquivos, permissões UNIX, processos, scripts, serviços, logs e ferramentas de administração.

Não é necessário virar administrador. Mas um programador que sabe onde procurar ganha autonomia.

Passo 3 — Descubra o caminho da alteração

Antes de mudar uma linha de COBOL, descubra:

qual é o fonte;
qual copybook é usado;
como o programa é compilado;
como é ligado ou empacotado;
quais tabelas, arquivos ou filas ele usa;
como o teste é executado;
onde aparecem mensagens e erros;
qual é o plano de retorno caso dê errado.

O jovem padawan não diz “funciona na minha máquina” em ambiente corporativo. Ele diz:

“Entendi a trilha de build, o impacto e a evidência de teste.”

Passo 4 — Aprenda uma transação inteira

Não fique apenas no MOVE.

Escolha um fluxo pequeno e siga o fio:

Entrada → validação → consulta → regra de negócio
       → atualização → COMMIT/ROLLBACK → saída → log

Faça isso em CICS/Db2, IBM i/Db2 for i ou AIX/banco relacional, conforme o seu ambiente. A linguagem COBOL será uma parte da história; o fluxo de negócio será a história inteira.

12. O veredito de Nathan Bateman

IBM Z não é “um IBM i grandão”.

IBM i não é “um mainframe pequenininho”.

AIX não é “Linux caro”.

Cada frase dessas apaga justamente o que torna as plataformas interessantes.

O IBM Z é uma plataforma de transação, disponibilidade, I/O, segurança e escala empresarial extrema.

O IBM i é uma plataforma integrada, onde aplicações e dados de negócio vivem muito perto do sistema operacional.

O AIX é um UNIX corporativo robusto, flexível e profundamente ligado à capacidade de virtualização e confiabilidade do IBM Power.

E todos continuam relevantes porque empresas reais ainda têm contas para fechar, produtos para entregar, impostos para calcular, cargas para processar, fraudes para bloquear e clientes que não aceitam a mensagem “tente novamente mais tarde”.

Nathan olha para o rack, para o dashboard e para o programa COBOL aberto no terminal.

— Então qual deles é o mais poderoso?

A resposta do programador COBOL que já começou a entender seria:

— Depende da missão. O erro é escolher a máquina antes de entender o problema.

E, pela primeira vez naquela noite, Nathan ficaria em silêncio.

Checklist final — Antes de chamar tudo de mainframe

IBM Z é plataforma e arquitetura; IBM i e AIX são sistemas operacionais.
IBM i e AIX podem rodar no mesmo IBM Power em LPARs distintas.
IBM Z roda z/OS, z/VM, Linux on IBM Z e outros sistemas específicos.
GHz não mede sozinho a capacidade de um ambiente corporativo.
IBM i possui integração profunda com Db2 for i, objetos e segurança.
AIX é UNIX corporativo, não apenas “um Linux diferente”.
No Z, processadores especializados ajudam a distribuir tipos de trabalho.
Segurança não é marca de produto: é arquitetura, configuração, processo e gente.
Para COBOL, aprenda sempre o ecossistema ao redor do programa.
Antes de mexer em produção, descubra o caminho completo: fonte, build, dados, teste, log e retorno.

No fim, a lição é menos sobre máquinas e mais sobre maturidade técnica: quem entende apenas a linguagem escreve programas; quem entende a plataforma ajuda a manter o negócio vivo.

Translate

quarta-feira, 2 de fevereiro de 2022