Bellacosa Mainframe ilustra a importancia do Sysprog Mainframe

☕🖥️ O SYSprog z/OS NÃO É “SÓ MAIS UM PROFISSIONAL DE TI” — É O ENGENHEIRO QUE IMPEDE O MUNDO DE PARAR ☕🖥️

Existe uma frase silenciosa no universo corporativo que pouca gente fora do mainframe entende:

“Quando o mainframe para, a empresa inteira descobre que ele existia.”

E é exatamente aí que entra uma das profissões mais raras, mais complexas e mais subestimadas da tecnologia moderna:

o z/OS System Programmer.

Muita gente imagina TI como:

• frontend colorido,
• startup hype,
• app mobile,
• container,
• influencer de LinkedIn falando “cloud-native”.

Enquanto isso…

em algum datacenter refrigerado absurdamente caro:

• bilhões de transações financeiras continuam passando,
• cartões continuam autorizando,
• PIX continua existindo,
• companhias aéreas continuam operando,
• seguradoras continuam processando,
• governos continuam funcionando.

E frequentemente tudo isso está apoiado em:

IBM Z + z/OS.

---

☕ O MAINFRAME NÃO MORREU. ELE VIROU INFRAESTRUTURA CIVILIZACIONAL.

O erro mais comum do iniciante é imaginar o mainframe como:

“computador velho dos anos 70”.

Na prática?

O IBM Z moderno possui:

• criptografia por hardware,
• IA embarcada,
• Linux,
• containers,
• OpenShift,
• APIs REST,
• automação,
• integração cloud híbrida,
• throughput monstruoso,
• uptime absurdo.

O mainframe não compete com notebook.

Ele compete com:

PARAR O MUNDO.

---

☕ O QUE UM z/OS SYSTEM PROGRAMMER REALMENTE FAZ?

O sysprog não é apenas “administrador”.

Ele é:

• engenheiro operacional,
• arquiteto de disponibilidade,
• especialista em recuperação,
• analista de performance,
• guardião de segurança,
• cirurgião de infraestrutura crítica.

É o profissional que:

• instala,
• mantém,
• corrige,
• automatiza,
• protege,
• recupera,
• ajusta
  o z/OS.

Se um desenvolvedor cria a aplicação…

o sysprog garante:

que a infraestrutura continue respirando.

---

☕ EXEMPLO REAL — O CAOS QUE UM SYSprog EVITA

Imagine:

• um banco internacional,
• Black Friday,
• milhões de acessos,
• PIX em massa,
• cartões autorizando em tempo real.

Agora imagine:

• uma falha de storage,
• perda de path FICON,
• congestionamento WLM,
• JES spool lotado,
• RACF falhando autenticação.

O usuário final só verá:

“Aplicativo indisponível”.

Mas nos bastidores:

• operadores entram em emergência,
• sysprogs analisam RMF,
• storage teams validam control units,
• dumps começam a ser coletados,
• IPLs são discutidos,
• GDPS talvez seja ativado.

E é exatamente nessas horas que nasce o verdadeiro valor do sysprog.

---

☕ O MAIOR ERRO DO INICIANTE

O novato geralmente pensa:

“Vou aprender COBOL e pronto.”

Não.

O universo enterprise é MUITO maior.

O profissional moderno precisa entender:

• sistema operacional,
• segurança,
• storage,
• automação,
• redes,
• recuperação,
• tuning,
• workflows,
• APIs,
• cloud híbrida.

O z/OS moderno virou:

uma plataforma enterprise gigantesca.

---

☕ A TRILHA REAL PARA VIRAR SYSprog

Aqui está algo que pouca gente fala claramente:

Você NÃO vira sysprog em:

• 2 semanas,
• bootcamp mágico,
• vídeo motivacional.

É uma construção gradual.

---

☕ FASE 1 — APRENDER A “LÍNGUA” DO MAINFRAME

Antes de tudo:

• TSO/ISPF,
• JCL,
• SDSF,
• datasets,
• VSAM,
• catálogo,
• JES2.

Sem isso o aluno fica perdido.

É como tentar virar piloto sem entender painel de avião.

---

☕ DICA DE OURO

Muita gente tenta estudar apenas teoria.

Erro fatal.

Mainframe precisa:

laboratório.

Mesmo usando:

• Hercules,
• TK4/TK5,
• zPDT,
• ADCD,
• ambientes educacionais,

o importante é:

• errar,
• quebrar,
• restaurar,
• analisar.

Sysprog nasce no troubleshooting.

---

☕ O VERDADEIRO TERROR: SMP/E

Todo sysprog veterano respeita uma entidade quase mística chamada:

SMP/E.

O sistema de manutenção do z/OS.

E aqui o iniciante descobre:

• coexistência,
• target zones,
• distribution zones,
• HOLDDATA,
• APPLY,
• ACCEPT,
• regressões.

Um patch errado pode:

• quebrar IPL,
• destruir JES,
• afetar RACF,
• causar outage enterprise.

Por isso:

quem domina SMP/E vira ouro no mercado.

---

☕ RACF — A MURALHA DO IMPÉRIO

Hoje:

• LGPD,
• PCI,
• compliance,
• auditoria,
• segurança bancária

são prioridades absolutas.

E no mainframe:

RACF é religião.

O sysprog moderno precisa entender:

• perfis,
• grupos,
• permissões,
• datasets,
• certificados digitais,
• SAF,
• auditoria.

Porque segurança enterprise não aceita improviso.

---

☕ O SYSprog MODERNO PRECISA APRENDER PYTHON

Aqui vem o choque cultural.

Muita gente pensa:

“Mainframe é só COBOL.”

Errado.

Hoje o sysprog moderno usa:

• Python,
• APIs,
• automação,
• Ansible,
• z/OSMF,
• REST,
• OpenShift.

O mundo mudou.

O profissional preso apenas em:

• painel verde,
• comandos manuais,
• operação artesanal

começa a ficar para trás.

---

☕ O FUTURO É AUTOMAÇÃO

Antigamente:

• sysprog fazia tudo manualmente.

Hoje:

• pipelines automatizados,
• workflows,
• Infrastructure as Code,
• provisionamento automático,
• automação operacional

viraram tendência forte.

Por isso a IBM empurra:

• Ansible for IBM Z,
• z/OSMF,
• OpenShift,
• integração híbrida.

---

☕ WLM — O “CÉREBRO INVISÍVEL” DO z/OS

Uma das áreas mais fascinantes do mainframe moderno é o:

Workload Manager.

O WLM decide:

• quem recebe CPU,
• prioridade,
• resposta,
• throughput,
• metas de serviço.

Enquanto sistemas distribuídos frequentemente brigam com escalabilidade…

o z/OS já fazia gerenciamento inteligente de workload há décadas.

---

☕ O UNIVERSO HARDCORE: IODF, IOCDS E FICON

Aqui chegamos no território lendário dos sysprogs veteranos.

Essa é a camada:

• hardware,
• canais,
• control units,
• topologia física,
• storage enterprise.

Pouquíssimos profissionais dominam profundamente:

• HCD,
• IODF,
• IOCDS,
• FICON,
• channel subsystem.

Quando alguém domina isso:

o mercado inteiro percebe.

---

☕ O FUTURO PROFISSIONAL PRECISA ENTENDER UMA VERDADE

Mainframe NÃO é tecnologia do passado.

Mainframe é:

tecnologia da continuidade operacional.

E isso muda completamente a mentalidade.

Enquanto startups pensam:

“deploy rápido”.

O mainframe pensa:

“não podemos parar”.

---

☕ A MENTALIDADE CERTA PARA CRESCER

O profissional que evolui no mainframe normalmente possui:

• disciplina,
• curiosidade,
• paciência,
• lógica,
• gosto por troubleshooting,
• gosto por documentação,
• responsabilidade.

Porque:

ambiente enterprise não perdoa improviso.

---

☕ O QUE ESTUDAR HOJE?

Se eu aconselhasse alguém começando AGORA:

Base obrigatória

• z/OS
• TSO/ISPF
• JCL
• JES2
• SDSF

---

Depois

• RACF
• SMP/E
• USS
• TCP/IP
• SMS

---

Avançado

• WLM
• RMF
• Sysplex
• GDPS
• HCD/IOCDS

---

Modernização

• Python
• REXX
• Ansible
• z/OSMF
• APIs REST
• OpenShift

---

☕ A IMPORTÂNCIA DO ZXPLORE

O ZXPLORE é extremamente forte porque organiza:

• trilhas,
• progressão,
• fundamentos,
• especializações.

Ela ajuda o aluno a:

• não estudar aleatoriamente,
• construir base sólida,
• entender arquitetura enterprise.

E no mainframe:

base sólida vale mais que modinha tecnológica.

---

☕ CONCLUSÃO — O SYSprog É O “ENGENHEIRO CIVIL” DA COMPUTAÇÃO ENTERPRISE

Se o desenvolvedor constrói aplicações…

o sysprog sustenta:

• a fundação,
• a energia,
• a segurança,
• a continuidade,
• a estabilidade.

Ele é o profissional que trabalha silenciosamente para garantir:

• disponibilidade,
• resiliência,
• recuperação,
• performance,
• segurança.

E talvez essa seja a parte mais fascinante do universo IBM Z:

Enquanto o mundo inteiro fala sobre inovação…

o mainframe continua:

• processando trilhões,
• protegendo bancos,
• sustentando governos,
• mantendo infraestruturas críticas vivas.

Como diria no estilo Bellacosa Mainframe:

“Cloud impressiona em apresentações.
Mainframe impressiona quando o caos começa.” ☕🖥️

 

Bellacosa Mainframe e o IMS System Programmer

☕🔥💣 IMS SYSTEM PROGRAMMER: O LADO BRUTAL DO MAINFRAME QUE SEGURA O MUNDO EM PÉ

O que realmente faz um especialista IMS na IBM — e por que poucos conseguem dominar esse universo

Quando alguém escuta:

“IMS System Programmer”

muita gente imagina apenas:

• instalar software

• rodar jobs

• olhar logs

😄

Mas a realidade é MUITO mais pesada.

Na prática, um especialista IMS trabalha literalmente no coração operacional do sistema financeiro mundial.

Porque quando:

• ATM para

• autorização de cartão falha

• telecom cai

• fila IMS trava

• Shared Queue degrada

• DBRC perde sincronismo

o problema não é “apenas TI”.

💣 O impacto pode custar milhões em minutos.

E é exatamente aí que entra o profissional IMS.

---

🚀 Instalar, Atualizar e Manter IMS com SMP/E

Essa é uma das tarefas mais clássicas — e perigosas — do mundo z/OS.

O:

SMP/E

(System Modification Program Extended)

é o sistema responsável por instalar e manter software no mainframe IBM.

No mundo distribuído você baixa instalador.

No mainframe você trabalha com:

• FMID

• HOLDDATA

• APPLY

• ACCEPT

• CSI

• zones

Ou seja:

engenharia cirúrgica de software corporativo.

---

☠️ O Terror do APPLY CHECK

Veteranos conhecem o ritual:

SET BDY(TGT1).
APPLY CHECK.

E então começa a tensão.

Porque um PUT errado pode:

💣 quebrar IMS
💣 afetar CICS
💣 impactar DB2
💣 gerar incompatibilidades de SYSPLEX

SMP/E não é apenas “instalação”.

É controle absoluto de manutenção em ambiente crítico.

---

🌳 Configurar IMS Transaction Manager

Aqui começa o verdadeiro mundo IMS.

O:

IMS TM

(Transaction Manager)

é o cérebro transacional do ambiente.

Ele controla:

• mensagens

• filas

• transações

• scheduling

• regiões online

• comunicação terminal/programa

Quando alguém faz:

💳 pagamento
🏧 saque
📱 consulta saldo

há grandes chances de um IMS TM estar trabalhando por trás.

---

⚡ IMS Shared Queue — O Monstro do Paralelismo

O Shared Queue foi criado para ambientes gigantescos.

Ele permite que múltiplos IMS compartilhem:

• filas

• mensagens

• workload

em ambiente SYSPLEX.

Isso traz:

✅ escalabilidade
✅ failover
✅ balanceamento
✅ alta disponibilidade

Mas também traz:

😄 pesadelos operacionais.

Porque quando Shared Queue degrada…

o caos pode ficar lindo.

---

🧠 Common Service Layer — A Cola do Ecossistema

O:

CSL

(Common Service Layer)

é a camada que integra diversos componentes IMS modernos.

Ela fornece:

• Operations Manager

• Structured Call Interface

• Resource Manager

Sem CSL, ambientes modernos IMS praticamente não existem mais.

É ele quem permite gerenciamento mais centralizado e inteligente.

---

🔥 DBRC — O Guardião da Integridade

Se existe uma entidade sagrada no IMS…

ela se chama:

DBRC

(Database Recovery Control)

O DBRC controla:

• recovery

• logs

• image copy

• autorização de banco

• integridade operacional

Ele sabe:

✅ quais logs existem
✅ quais backups são válidos
✅ qual banco pode abrir
✅ quais datasets estão consistentes

Sem DBRC:

💣 recovery vira inferno.

---

☕ Easter Egg Mainframe

Veteranos dizem:

“No dia que o RECON quebra…
o DBA envelhece 10 anos.”

😄

E honestamente?

Não é exagero.

---

🌐 IMS Connect — O Portal Entre Mundos

Hoje o IMS conversa com:

• APIs REST

• Java

• JSON

• mobile banking

• cloud híbrida

E quem faz muita dessa ponte é o:

IMS Connect

Ele permite integração TCP/IP moderna com o velho mundo DL/I.

Ou seja:

📱 aplicativo no celular
→ API REST
→ IMS Connect
→ IMS TM
→ COBOL
→ DL/I

Cyberpunk corporativo puro.

---

📊 Monitorar IMS com RMF e SMF

No mundo distribuído muita gente olha dashboard bonito.

No mainframe…

o profissional IMS olha:

• SMF

• RMF

• throughput

• EXCP

• CPU

• enqueue

• response time

Porque aqui performance é religião.

---

🚀 SMF — O DNA do z/OS

O:

SMF

(System Management Facility)

registra praticamente tudo.

É o “gravador de caixa preta” do mainframe.

Você consegue analisar:

• uso CPU

• transações

• I/O

• locks

• workload

• comportamento do IMS

---

⚡ RMF — O Olho da Performance

O:

RMF

(Resource Measurement Facility)

mede:

• CPU

• canais

• memória

• coupling facility

• workload

Num ambiente IMS gigantesco, RMF é praticamente um estetoscópio do sistema.

---

💣 Analisar Abends e Problemas Complexos

Aqui mora a parte mais brutal da profissão.

Porque quando aparece:

U0777
S0C4
DFSxxxx
ABEND878

o especialista IMS entra em modo guerra.

Ele precisa analisar:

• dumps

• logs

• traces

• control blocks

• storage overlays

• waits

• contention

Muitas vezes sob pressão absurda.

---

🌳 Alta Disponibilidade — Onde o IMS Brilha

IMS foi criado para:

missão crítica contínua.

Então arquiteturas IMS modernas usam:

• SYSPLEX

• Shared Queue

• Coupling Facility

• XRF

• Fast Path

• HALDB

para entregar:

✅ uptime gigantesco
✅ failover rápido
✅ workload sharing
✅ resiliência extrema

---

🚀 Disaster Recovery — O Dia do Juízo Final

Todo ambiente sério IMS possui:

DR TEST

Porque eventualmente:

• data center cai

• storage falha

• rede quebra

• região inteira desaparece

E o IMS precisa sobreviver.

O time testa:

• recovery

• restart

• log apply

• DBRC

• reconnect

• queue rebuild

Tudo sob cronômetro.

---

⚔️ O Arsenal Obrigatório do Profissional IMS

---

🟦 JCL

O idioma operacional do z/OS.

Sem JCL você literalmente não entra no jogo.

---

🟩 TSO/ISPF

O cockpit do operador mainframe.

---

🟨 JES2

Gerencia jobs, spool e execução batch.

---

🟪 REXX

O canivete suíço do mainframe.

Automação.

Monitoramento.

Operação.

Recovery.

---

🟥 SYSPLEX

O conceito que permite múltiplos z/OS trabalharem como um único sistema gigante.

Fundamental para IMS moderno.

---

☕ O Grande Segredo do Mundo IMS

O mercado moderno adora falar sobre:

• cloud

• microservices

• kubernetes

• serverless

Mas existe um detalhe curioso:

Boa parte das transações financeiras globais ainda depende de profissionais que dominam:

• IMS

• DL/I

• DBRC

• Shared Queue

• SYSPLEX

• SMP/E

Tecnologias criadas décadas atrás…

mas ainda absurdamente eficientes.

---

🚀 O Último Bastião da Engenharia Hardcore

Talvez seja isso que torne o universo IMS tão fascinante.

Ele não foi construído para ser bonito.

Foi construído para:

• sobreviver

• escalar

• performar

• resistir

E enquanto muita tecnologia moderna luta para manter estabilidade básica…

o velho IMS continua processando bilhões de transações silenciosamente.

Como um dinossauro mecânico escondido no subsolo do sistema financeiro mundial.

IBM Z Resiliency Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

 

Bellacosa Mainframe expande as ideias em IBM Z Resiliency

☕ Um Café no Bellacosa Mainframe

O Holocron da IBM Z Resiliency

Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

"O melhor programa COBOL não é apenas aquele que produz o resultado correto. É aquele que continua produzindo o resultado correto mesmo quando discos falham, servidores reiniciam, links caem, operadores cometem erros e o datacenter enfrenta uma crise."

---

Introdução

Quando um desenvolvedor COBOL começa sua jornada no IBM Z, normalmente sua preocupação é bastante simples:

• aprender PROCEDURE DIVISION;

• entender WORKING-STORAGE;

• fazer READ e WRITE em arquivos VSAM;

• acessar Db2;

• executar um programa via JCL;

• tratar um SQLCODE.

Tudo isso é importante.

Mas existe uma realidade muito maior que normalmente só é descoberta anos depois.

Seu programa não vive sozinho.

Ele faz parte de um enorme ecossistema composto por:

• IBM Z Hardware

• z/OS

• JES2

• WLM

• CICS

• IMS

• Db2

• MQ

• RACF

• GDPS

• Parallel Sysplex

• Storage

• Redes

• Operação

• Monitoramento

• Backup

• Disaster Recovery

Todo esse conjunto possui um único objetivo:

Nunca deixar o negócio parar.

É justamente isso que a IBM chama de Resiliency.

---

O maior equívoco do desenvolvedor iniciante

O Padawan COBOL costuma pensar:

"Meu programa compilou."

Depois:

"Funcionou no teste."

Depois:

"Funcionou em produção."

Fim da história.

Na realidade...

A história apenas começou.

Porque a pergunta correta nunca é:

"O programa funciona?"

A pergunta correta é:

"Ele continua funcionando quando alguma coisa dá errado?"

Essa mudança de mentalidade separa um programador júnior de um engenheiro de software para ambientes críticos.

---

O mundo perfeito não existe

Imagine um banco.

Às 10 horas da manhã.

Existem:

• 8 milhões de clientes conectados.

• milhares de caixas eletrônicos.

• PIX.

• cartões.

• internet banking.

• aplicativos móveis.

• APIs REST.

• Open Finance.

Nesse momento:

uma CPU apresenta defeito.

O que acontece?

Se você respondeu:

"O banco para."

Você ainda está pensando como quem programa um computador doméstico.

No IBM Z, o esperado é que ninguém perceba.

Esse é o verdadeiro significado da palavra Resiliency.

---

Resiliência não significa nunca falhar

Essa é outra confusão muito comum.

Nenhum computador é perfeito.

Discos quebram.

Memórias apresentam defeitos.

Cabos rompem.

Fontes queimam.

Operadores erram comandos.

Aplicações possuem bugs.

Até meteoros poderiam destruir um datacenter.

Resiliência significa:

Aceitar que falhas acontecerão e projetar o sistema para continuar operando apesar delas.

---

O conceito mais importante

A IBM define resiliência como:

Capacidade de fornecer os serviços necessários diante da adversidade sem impacto significativo.

Perceba um detalhe.

Ela não fala em hardware.

Ela não fala em COBOL.

Ela fala em:

Serviço.

O cliente quer sacar dinheiro.

Ele não quer saber quantas CPUs existem.

---

O iceberg invisível

Quando você executa:

EXEC SQL
SELECT SALDO
END-EXEC

Você enxerga apenas uma linha.

Por trás dela existem dezenas de componentes trabalhando juntos.

Seu programa depende de:

• compilador COBOL;

• runtime;

• Db2;

• buffer pools;

• storage;

• cache;

• canais FICON;

• discos;

• processadores;

• WLM;

• z/OS;

• JES;

• rede;

• segurança RACF.

A resiliência protege toda essa cadeia.

---

O verdadeiro custo de um downtime

Muitos iniciantes imaginam:

"Se o sistema parar por cinco minutos não faz diferença."

Na prática, cinco minutos podem significar:

• milhões de transações não realizadas;

• PIX rejeitados;

• compras canceladas;

• multas;

• perda de reputação;

• ações caindo na bolsa.

O Redbook mostra que o custo de uma interrupção vai muito além da infraestrutura. Há perdas diretas de receita, custos fixos durante a parada e impactos intangíveis, como perda de confiança dos clientes e danos à marca.

---

O famoso RAS

Quase todo Sysprog conhece esta sigla.

Reliability

Confiabilidade.

Quanto menor a chance de quebrar.

Availability

Disponibilidade.

Mesmo quebrando,

continua funcionando.

Serviceability

Facilidade para manutenção.

Trocar peças.

Atualizar firmware.

Fazer manutenção.

Sem parar o ambiente.

---

O COBOL participa da Resiliência?

Sim.

Muito mais do que parece.

Um programa COBOL mal escrito pode derrubar um ambiente inteiro.

Por exemplo:

• LOOP infinito.

• COMMIT inexistente.

• Deadlock.

• Consumo exagerado de CPU.

• SQL sem índice.

• Arquivos bloqueados.

• Storage leak.

• Falta de tratamento de exceção.

Resiliência também é responsabilidade do desenvolvedor.

---

O que um Padawan precisa aprender

Primeira fase.

Programar.

Segunda fase.

Programar corretamente.

Terceira fase.

Programar para recuperação.

Quarta fase.

Programar pensando na infraestrutura.

Quinta fase.

Programar pensando no negócio.

Essa evolução leva anos.

---

A importância do COMMIT

Imagine:

Você atualiza:

100.000 registros.

No registro 99.999 ocorre uma queda elétrica.

Sem COMMIT.

Tudo volta.

Com COMMIT periódico.

A perda é mínima.

O programa consegue reiniciar.

Esse pequeno detalhe pode economizar horas de processamento.

---

Checkpoints

Batchs gigantes normalmente possuem checkpoints.

Imagine um processamento de:

40 milhões de clientes.

No cliente 39 milhões ocorre uma falha.

Sem checkpoint.

Tudo recomeça.

Com checkpoint.

Continua do ponto salvo.

É resiliência aplicada ao desenvolvimento.

---

Idempotência

Uma palavra moderna.

Mas extremamente útil.

Se o mesmo programa executar novamente,

ele não deve:

duplicar pagamentos;

duplicar TED;

duplicar PIX;

duplicar lançamentos.

Grandes sistemas financeiros dependem disso.

---

Tratamento de exceções

Nunca escreva:

IF SQLCODE NOT = 0
    DISPLAY 'ERRO'
END-IF

Isso não resolve nada.

Um bom programa:

• registra logs;

• identifica contexto;

• faz rollback quando necessário;

• encerra de forma segura;

• permite recuperação.

---

O papel do WLM

O Workload Manager decide quem recebe prioridade.

Imagine:

• Folha de pagamento.

• PIX.

• Batch estatístico.

Quem deve receber CPU primeiro?

O WLM responde.

Seu programa faz parte dessa fila.

---

Parallel Sysplex

Talvez seja a tecnologia mais famosa do IBM Z.

Vários sistemas trabalham como se fossem um único computador.

Se um deles cair,

os demais continuam.

O usuário nem percebe.

Parece magia.

Na realidade,

é engenharia.

---

GDPS

Geographically Dispersed Parallel Sysplex.

Imagine:

São Paulo inteiro sem energia.

Outro datacenter assume.

Essa é a ideia.

Algumas empresas conseguem continuar operando mesmo após perder completamente um site.

---

Zero Data Loss

Um conceito impressionante.

Perder:

zero.

Nem um registro.

Nem um pagamento.

Nem um PIX.

Nem um centavo.

Nem um byte.

É um objetivo que depende de arquiteturas de replicação síncrona e soluções como GDPS e tecnologias de espelhamento de armazenamento.

---

Curiosidade

Muitos bancos realizam manutenção durante o horário comercial.

Você nem percebe.

Enquanto um sistema recebe manutenção,

outro assume.

Depois ocorre o inverso.

Esse processo chama-se:

Rolling Maintenance.

---

Easter Egg nº 1

O maior inimigo da disponibilidade nem sempre é o hardware.

É o operador.

Estudos da indústria mostram que erros humanos continuam entre as causas mais frequentes de indisponibilidade.

Por isso existem:

• automação;

• procedimentos;

• scripts;

• validações;

• System Automation;

• Runbooks.

---

Easter Egg nº 2

Os engenheiros IBM costumam perseguir um objetivo curioso.

Eliminar o que chamam de:

Single Point of Failure

Qualquer componente único que possa derrubar todo o ambiente.

Vale para:

• CPU;

• disco;

• switch;

• cabo;

• storage;

• operador;

• documentação.

Até pessoas podem ser um "Single Point of Failure" quando apenas um especialista conhece um procedimento crítico.

---

Easter Egg nº 3

Um COBOL pode ser resiliente mesmo sendo escrito há 40 anos.

Se:

• estiver bem estruturado;

• tratar exceções;

• possuir restart;

• possuir checkpoints;

• respeitar transações;

ele continua extremamente moderno.

---

O que estudar depois deste curso

Depois de entender Resiliency, o caminho natural é aprofundar-se na própria stack IBM Z.

Infraestrutura

• IBM Z Hardware

• CPC

• LPAR

• PR/SM

• HMC

Sistema Operacional

• z/OS

• JES2

• SDSF

• WLM

• SMF

• RMF

Armazenamento

• DFSMS

• DFSMShsm

• Copy Services

• Metro Mirror

• Global Mirror

Redes

• VTAM

• TCP/IP

• DVIPA

• Sysplex Distributor

Middleware

• CICS

• IMS

• Db2

• MQ

Alta Disponibilidade

• Parallel Sysplex

• Coupling Facility

• Data Sharing

• GDPS

Operação

• IBM System Automation

• OMEGAMON

• IBM Z Operations Analytics

---

As habilidades modernas do desenvolvedor COBOL

O mercado mudou.

Hoje um desenvolvedor COBOL pode agregar muito mais valor quando conhece:

• APIs REST com z/OS Connect;

• JSON e XML;

• Git;

• GitHub;

• DevOps;

• CI/CD;

• testes automatizados;

• observabilidade;

• OpenTelemetry;

• containers para ferramentas de apoio;

• Ansible;

• Zowe;

• VS Code;

• automação operacional;

• inteligência artificial aplicada ao desenvolvimento.

---

Os perigos de ignorar a resiliência

Quem pensa apenas em "fazer funcionar" costuma criar sistemas frágeis.

Os principais riscos são:

• perda de dados;

• duplicidade de transações;

• indisponibilidade prolongada;

• degradação de desempenho;

• dificuldade de recuperação;

• manutenção cara;

• dependência de especialistas;

• aumento do risco operacional.

Em ambientes financeiros, esses problemas podem gerar prejuízos milionários.

---

Como evoluir de Padawan para Mestre

Uma evolução sólida pode seguir esta trilha:

Nível 1 — Fundamentos

• COBOL

• JCL

• VSAM

• Db2

• CICS

Nível 2 — Sistema

• z/OS

• SDSF

• JES2

• TSO/ISPF

• WLM

Nível 3 — Arquitetura

• Parallel Sysplex

• Coupling Facility

• Data Sharing

• ARM

• SFM

Nível 4 — Continuidade de Negócios

• RAS

• HA

• DR

• RTO

• RPO

• GDPS

Nível 5 — Modernização

• APIs

• z/OS Connect

• DevOps

• Observabilidade

• IA

• Automação

---

A maior lição do IBM Z Resiliency

Depois de estudar esse tema, muitos desenvolvedores descobrem que escrever código representa apenas uma pequena parte do trabalho. Um programa COBOL faz sentido somente quando está inserido em uma arquitetura capaz de sobreviver a falhas, manter dados íntegros e continuar entregando serviços ao negócio.

É por isso que os profissionais mais valorizados no ecossistema IBM Z não são apenas excelentes programadores. Eles entendem infraestrutura, operação, banco de dados, middleware, redes, automação e continuidade de negócios. Eles sabem que um COMMIT bem posicionado, um tratamento adequado de exceções ou um checkpoint inteligente podem ter tanto impacto quanto uma nova funcionalidade.

No fim da jornada, o verdadeiro Mestre do IBM Z não é aquele que escreve o código mais sofisticado. É aquele que projeta soluções que continuam funcionando quando o inesperado acontece. Essa é a essência da IBM Z Resiliency: construir sistemas preparados para enfrentar falhas sem interromper aquilo que realmente importa — o negócio de milhões de pessoas.

 

Bellacosa Mainframe e diferenças entre SysAdmin e SysProg no mundo Mainframe

☕⚔️ SYSADMIN vs SYSPROG — A GUERRA SILENCIOSA DENTRO DO MAINFRAME IBM Z 🖥️🔥

Existe uma confusão clássica no universo mainframe:

Muita gente acha que Sysadmin e Sysprog são a mesma coisa.

Não são.

Na prática, eles vivem no mesmo ecossistema…
mas enxergam o IBM Z de maneiras completamente diferentes.

É quase como comparar:

• o comandante operacional da cidade
  com

• o engenheiro que entende a arquitetura secreta da cidade

Os dois são críticos.
Os dois podem salvar produção.
Os dois trabalham próximos.

Mas o nível de profundidade e responsabilidade muda drasticamente.

---

🖥️ O SYSADMIN — O GUARDIÃO DA OPERAÇÃO

O Sysadmin é o profissional focado na:

• estabilidade operacional

• administração diária

• automação

• disponibilidade

• segurança operacional

• monitoramento

• troubleshooting

• continuidade do ambiente

Ele é extremamente operacional.

Seu foco é:

“O ambiente precisa continuar funcionando.”

---

⚙️ O QUE O SYSADMIN FAZ?

📊 Monitora o ambiente

• JES2

• spool

• initiators

• jobs

• filas

• alerts

• automação

• mensagens de console

• recursos do sistema

---

🔥 Atua em incidentes

Quando algo falha:

• job para

• CICS degrada

• MQ trava

• storage satura

• batch atrasa

o Sysadmin entra rapidamente para estabilizar produção.

---

🤖 Automatiza tarefas

Usa:

• REXX

• OPS/MVS

• System Automation

• NetView

• Control-M

• scripts USS

• z/OSMF workflows

Porque operação manual em ambiente crítico é risco.

---

🔐 Atua junto da segurança

Interage com:

• RACF

• permissões

• certificados

• auditoria

• acessos operacionais

Mas normalmente não redefine arquitetura de segurança.

---

🧠 PERFIL DO SYSADMIN

O Sysadmin pensa como:

• operador estratégico

• bombeiro operacional

• analista de continuidade

• especialista em estabilidade

Ele precisa reagir rápido.

Seu diferencial é:

• visão operacional

• troubleshooting

• resposta a incidentes

• observabilidade

• capacidade de estabilizar caos

---

⚡ O SYSPROG — O ENGENHEIRO DO KERNEL CORPORATIVO

Agora começa outro nível.

O Sysprog (System Programmer) é o profissional responsável pela:

• arquitetura interna do z/OS

• customização profunda

• instalação de produtos

• tuning sistêmico

• integração de subsistemas

• manutenção estrutural

• engenharia interna do ambiente

O Sysprog não apenas usa o sistema.

Ele literalmente molda o sistema.

---

☠️ O QUE O SYSPROG FAZ?

🧩 Instala e customiza produtos

• SMP/E

• APPLY

• ACCEPT

• HOLDDATA

• maintenance

• FIXCAT

• PTF

• APAR

Ele mantém o ecossistema do z/OS atualizado.

---

⚙️ Trabalha com internals do z/OS

Aqui o negócio fica sério.

O Sysprog lida com:

• PARMLIB

• PROCLIB

• exits

• APF

• LPA

• nucleus

• subsystem interfaces

• cross-memory

• dump analysis

• IPL process

• HCD/HCM

• coupling facility

• WLM policy

• SRM tuning

É engenharia pesada.

---

🔥 Analisa problemas sistêmicos profundos

Quando o problema deixa de ser operacional…

e vira comportamento estrutural…

o Sysprog entra.

Exemplo:

• loop sistêmico

• storage corruption

• S0C complexos

• waits anormais

• IOS contention

• deadlocks internos

• problemas de dispatching

• degradação de nucleus

• erros de microcode

• conflitos de exits

Aqui já estamos perto do “motor do avião”.

---

🧠 Faz performance tuning avançado

O Sysprog trabalha diretamente com:

• RMF

• SMF

• WLM

• cache structures

• coupling facility

• HiperDispatch

• zIIP

• memory tuning

• paging strategies

Pequenos ajustes podem economizar milhões em MSU.

---

☕ A DIFERENÇA FILOSÓFICA

🖥️ SYSADMIN

Pergunta:

“Como mantenho isso funcionando hoje?”

---

⚙️ SYSPROG

Pergunta:

“Como isso realmente funciona por dentro?”

---

🔥 ANALOGIA PERFEITA

SYSADMIN

É o comandante da nave.

Ele monitora tudo em tempo real.
Mantém operação viva.
Responde emergências.
Coordena estabilidade.

---

SYSPROG

É o engenheiro que construiu os motores da nave.

Ele entende:

• arquitetura

• energia

• núcleo

• comportamento interno

• limites físicos do sistema

---

📚 CONHECIMENTO TÉCNICO

SYSADMIN normalmente domina:

• JES2

• SDSF

• RACF

• automação

• monitoramento

• operação

• TCP/IP

• scheduling

• storage operacional

• incidentes

---

SYSPROG normalmente domina:

• SMP/E

• dumps

• IPCS

• exits

• assembler

• internals do z/OS

• performance profunda

• Sysplex internals

• WLM architecture

• subsystem engineering

---

⚡ QUEM TEM MAIS RESPONSABILIDADE?

Os dois possuem responsabilidades críticas.

Mas o impacto estrutural do Sysprog costuma ser maior.

Porque um erro de Sysadmin pode:

• derrubar operação

Já um erro de Sysprog pode:

• impedir IPL

• corromper ambiente

• afetar todo Sysplex

• quebrar subsistemas críticos

• comprometer estabilidade sistêmica

Por isso Sysprog é uma das funções mais respeitadas do mainframe.

---

🚀 O MAINFRAME MODERNO MUDOU TUDO

Hoje a fronteira ficou menos rígida.

O Sysadmin moderno já trabalha com:

• observabilidade

• automação avançada

• DevOps

• APIs

• OpenTelemetry

• cloud híbrida

Enquanto o Sysprog moderno também atua em:

• Linux on Z

• containers

• automação cognitiva

• z/OSMF

• workflows REST

• integração híbrida

Mas ainda existe uma verdade absoluta:

---

☠️ QUANDO O CAOS FICA PROFUNDO…

Primeiro chamam o Sysadmin.

Se ele não resolver…

chamam o Sysprog.

E quando o Sysprog fica em silêncio olhando o console…

todo mundo na sala fica nervoso.