🟦 IBM Mainframe & COBOL 4.00

O elo entre o COBOL clássico e o mundo moderno

“COBOL 4 não é ruptura.
É a IBM dizendo: ‘vamos modernizar… sem quebrar nada’.”
— Bellacosa, depois de recompilar 3 milhões de linhas

---

🧬 Contexto histórico: onde o COBOL 4.00 se encaixa

O Enterprise COBOL for z/OS 4.0 faz parte da família COBOL 4.x, que surgiu no início da década de 2010, num momento crítico:

• Mainframes mais poderosos (z10, z196)

• Arquitetura 64 bits amadurecendo

• Pressão por performance, modernização e integração

• COBOL 3 ainda dominante… mas envelhecendo

👉 O COBOL 4 não veio para “mudar a linguagem”.
Veio para mudar o compilador.

---

📅 Data de lançamento (contexto realista)

• Enterprise COBOL for z/OS 4.0: final de 2007 e primordios da primeira década de 2010.

• Consolidação real aconteceu nas versões 4.1 / 4.2

• Foi o degrau obrigatório antes do COBOL 5.x

💡 Tradução Bellacosa:

Se você saiu do COBOL 3 direto para o 5, o 4 foi o “meio do caminho” que você pulou… e pagou depois.

---

🖥️ Equipamentos mainframe indicados

COBOL 4 foi feito para explorar hardware moderno da IBM:

Mainframes ideais:

• IBM z10

• IBM z196

• IBM zEC12

• Totalmente compatível com zEnterprise

Por quê?

Porque o COBOL 4:

• Gera código mais otimizado

• Explora melhor o pipeline do processador

• Se beneficia de novas instruções de CPU

🥚 Easter-egg:

Recompilar COBOL antigo em COBOL 4 sem mudar uma linha já dava ganho de performance.

---

🔄 O que muda em relação ao COBOL 3.x?

🧠 1️⃣ Compilador totalmente redesenhado

• Novo backend

• Melhor otimização de código

• Melhor uso de registradores

👉 O código fonte parece igual.
👉 O código objeto não é.

---

⚙️ 2️⃣ Melhor suporte a arquitetura moderna

• Preparação para 64 bits

• Melhor alinhamento de dados

• Base para o futuro COBOL 5 (LE-only)

---

📊 3️⃣ Performance real

• Redução de CPU em batch

• Melhor performance em loops

• Melhor otimização de PERFORM

🥚 Easter-egg:

Muitos shops recompilaram só para economizar MIPS.

---

🧨 4️⃣ Mais rigor (menos permissividade)

Alguns “pecados antigos” começaram a ser cobrados:

• Dados mal definidos

• Uso implícito perigoso

• Código que “sempre funcionou” 😅

👉 COBOL 4 começa a expor bugs escondidos há 20 anos.

---

🧪 Exemplo simples (nada muda… mas muda tudo)

IDENTIFICATION DIVISION.
PROGRAM-ID. EXEMPLO4.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-TOTAL PIC 9(9) VALUE 0.

PROCEDURE DIVISION.
    PERFORM 10 TIMES
        ADD 1 TO WS-TOTAL
    END-PERFORM
    DISPLAY WS-TOTAL
    STOP RUN.

➡ Em COBOL 3: funciona
➡ Em COBOL 4: funciona mais rápido

💡 O ganho está no objeto gerado, não no código.

---

🛠️ Dicas técnicas Bellacosa Approved™

✔ Recompile, mesmo sem modernizar

• COBOL 4 já entrega valor só na recompilação

✔ Use parâmetros certos:

• OPTIMIZE

• ARCH

• SSRANGE (para pegar erro escondido)

✔ Teste batch crítico

• Principalmente cálculos

• Principalmente datas

• Principalmente arredondamentos

✔ Compare CPU antes/depois

• Você vai se surpreender

---

⚠️ Armadilhas clássicas

🚨 Código que dependia de comportamento indefinido
🚨 Campos mal alinhados
🚨 MOVE CORRESPONDING em estruturas duvidosas
🚨 Arredondamento implícito não documentado

🥚 Easter-egg cruel:

COBOL 4 não cria bug.
Ele revela.

---

🧠 Curiosidades de bastidor

• COBOL 4 foi o primeiro passo sério rumo ao LE-only

• Muitas empresas ficaram “presas” no 4 por anos

• Ele é visto como a versão mais estável da transição

• Serviu de base para o radical COBOL 5

---

🧘 Primeiros passos para o Padawan

Se você está começando agora:

1️⃣ Entenda COBOL clássico primeiro
2️⃣ Saiba compilar e linkar
3️⃣ Entenda parâmetros de compilação
4️⃣ Recompile código antigo e observe
5️⃣ Leia o listing — ele ensina mais que o código

“Quem lê o listing, domina o mainframe.”

---

🧠 Visão Bellacosa Final™

O COBOL 4.00 não é famoso.
Não é revolucionário.
Não é hype.

Mas ele é:

• Estável

• Inteligente

• O verdadeiro ponto de virada técnico do COBOL moderno

Se o COBOL fosse uma saga:

• COBOL 3 = trilogia clássica

• COBOL 4 = o episódio de transição

• COBOL 5 = o reboot corajoso

E lembre-se, Padawan:

“Modernizar não é reescrever.
É entender o que funciona… e deixar melhor.”

 

☕ Um Café no Bellacosa Mainframe — z/OS 1.9: o gigante mais inteligente e autônomo da era System z

 

☕ Um Café no Bellacosa Mainframe — z/OS 1.9: o gigante mais inteligente e autônomo da era System z

---

🕰️ Ano de lançamento

O IBM z/OS 1.9 foi lançado em setembro de 2007, acompanhando o IBM System z10 em seu ciclo de desenvolvimento — embora também suportasse o System z9.
Essa versão simboliza o amadurecimento da plataforma z/Architecture, consolidando avanços em autonomia, automação, segurança e processamento paralelo inteligente.

---

⚙️ Introdução técnica

Enquanto o z/OS 1.7 havia trazido a plena transição para 64 bits, o z/OS 1.9 foi a versão que deu “consciência situacional” ao sistema operacional.
Ele começou a analisar sua própria performance, otimizar cargas automaticamente e dialogar melhor com o hardware via novas interfaces do PR/SM e do z/Architecture.

Seu lema interno na IBM era:

“Think, adapt, optimize — autonomic computing starts here.”

E fazia jus ao nome. O 1.9 é considerado o primeiro z/OS verdadeiramente autonomic, aquele que gerencia, ajusta e distribui recursos de forma dinâmica, sem intervenção manual constante.

---

🧠 Avanços de arquitetura e uso de memória

Com suporte pleno a 64 bits, o z/OS 1.9 trouxe avanços notáveis:

• Melhor gerenciamento de memória virtual, com page fixing otimizado e melhor cache awareness;

• Expansão do suporte a Large Memory Objects (LMO), beneficiando cargas Java, DB2 e WebSphere;

• Hipervisores e LPARs podiam agora consumir memória dinamicamente sem reboot, via Dynamic Storage Reconfiguration (DSR);

• O sistema passou a entender afinidade de CPU/memória — recurso crucial para evitar latências em ambientes SMP (Symmetric Multi Processing).

Na prática, isso resultou em redução de page faults, melhor throughput em batch workloads e resposta mais rápida para transações CICS e IMS.

---

🧩 Aplicativos internos e softwares embarcados

O z/OS 1.9 trouxe grandes renovações no ecossistema IBM interno:

• RACF (Security Server): novos controles de senha, expiração adaptativa, integração com LDAPv3 e criptografia AES-256 para chaves simétricas.

• JES2 e JES3: otimizações no gerenciamento de spool e segurança, com controle refinado de job classes.

• DFSORT e ICETOOL: passaram a explorar SIMD (Single Instruction, Multiple Data) da z/Architecture para aceleração de sorting.

• RMF (Resource Measurement Facility): agora suportava métricas em tempo real integradas ao WLM — base para os primeiros dashboards de auto-tuning.

• UNIX System Services (USS): maior compatibilidade com padrões POSIX, suporte a NFSv4 e novas APIs de rede para integração WebSphere/DB2.

• Communications Server (TCP/IP stack): suporte robusto a IPv6, IPSec nativo, e QoS (Quality of Service) ajustável via WLM.

---

🔬 Instruções de máquina e firmware

O System z9 e o z/OS 1.9 trabalharam juntos para explorar novas instruções da z/Architecture:

• Criptografia assistida por hardware (CPACF v2) — aceleração de AES, SHA e RSA diretamente no processador;

• Instruções de controle de cache e pipeline, otimizando acessos concorrentes a memória;

• Suporte a “Restartable Instructions”, garantindo integridade mesmo em falhas intermediárias;

• Sincronização estendida (Compare-and-Swap, Fetch-and-Add) — base para virtualização eficiente e paralelismo seguro.

No firmware, o PR/SM (Processor Resource/System Manager) ganhou um salto em inteligência:

• Capacidade de redistribuição automática de processadores lógicos entre LPARs com base no WLM;

• Suporte aprimorado a zAAPs (Application Assist Processors) e zIIPs (Integrated Information Processors);

• Introdução do Group Capacity Limit e Soft Capping Dinâmico — controle refinado de consumo de CPU por partição.

Essa combinação tornou o z/OS 1.9 um sistema operacional mais previsível, justo e elástico, precursor direto das políticas de cloud elástica do z/OS moderno.

---

🧮 Créditos de CPU e desempenho

No z/OS 1.9, os créditos de CPU (entitlement) ganharam vida nova:

• Introdução do WLM Goal Mode aprimorado, que realoca créditos em tempo real;

• Possibilidade de mover créditos entre LPARs sem intervenção;

• Integração total com IRD (Intelligent Resource Director) — permitindo que o sistema negocie recursos entre workloads.

A consequência?
Mais performance em workloads DB2, WebSphere e CICS com menor custo por MIPS — e maior eficiência energética (conceito que começava a ser prioridade).

---

🧭 Curiosidades e bastidores

• O z/OS 1.9 foi a primeira versão totalmente construída sobre z/Architecture, sem dependências de compatibilidade com 31 bits.

• A IBM apelidou o projeto internamente de “Nova”, pois a meta era “iluminar” a inteligência dentro do mainframe.

• Foi a última versão a rodar confortavelmente em System z9 BC, antes que o z/OS 1.10 se tornasse exclusivo de z10 e superiores.

• Alguns engenheiros da época chamavam o WLM + IRD de “mini-cérebro”, por sua capacidade de autoajuste.

---

☕ Dica Bellacosa Mainframe

Se você é curioso sobre autotuning, WLM e virtualização, o z/OS 1.9 é uma joia de estudo.
Ele é leve o suficiente para rodar em ambientes zPDT/Hercules e rico o bastante para mostrar o início real da era autonomic — onde o mainframe aprendeu a pensar sozinho.
Além disso, suas métricas de RMF são excelentes para treinar operadores e analistas de performance.

---

📜 Resumo técnico rápido

Item	Descrição
Versão	z/OS 1.9
Ano de lançamento	2007
Hardware principal	IBM System z9 / início do z10
Arquitetura	z/Architecture (64-bit)
PR/SM	Redistribuição automática de CPU e memória
Processadores	Suporte total a zAAP e zIIP
WLM	Goal Mode dinâmico e autoajuste
Segurança	RACF com AES-256 e LDAPv3
Rede	IPv6, IPSec, QoS dinâmico
Curiosidade	Primeira versão “autonomic”, cognitiva e autoajustável da IBM

---

💬 “O z/OS 1.9 foi quando o mainframe deixou de apenas trabalhar — e começou a pensar.”

 

CICS TS 3.2 Bellacosa Mainframe

🔥 CICS Transaction Server for z/OS 3.x

---

☕ Midnight Lunch no túnel do tempo

Imagine estar na sala de operações em meados dos anos 2000.
O CICS já não era mais apenas “aquele trem verde de 3270”.
Ele estava virando servidor transacional corporativo global, lidando com Web, Java e conectividade aberta — e as versões 3.x foram decisivas nessa transição.

Aqui está tudo que você precisa saber sobre essa série — com história, contexto, curiosidades e um exemplo para “sentir” o impacto real.

---

📅 Versões e Linha do Tempo

CICS Transaction Server for z/OS 3.x engloba versões que marcaram a década de 2000:

Versão	Lançamento (aprox.)	Destaques principais
3.1	2005	Entrada forte em Web, HTTP, segurança e integração C/C++
3.2	2007	Melhor suporte a conectividade, ESDS/VSAM grandes, APIs threadsafe

📌 Note que os releases 3.x não têm tabelas públicas fáceis de EOS (End of Service), mas já estão largamente fora de suporte oficial há muitos anos.

---

CICS 3.2

🧠 O que há de novo no 3.x

✅ 1. Suporte avançado a Web & HTTP

CICS 3.1 foi um divisor de águas:
pela primeira vez os ambientes CICS puderam servir requisições HTTP nativamente, abrindo caminho para aplicações web centradas em transações já existentes.

💬 Bellacosa diz:
“Antes disso, CICS era green screen ou nada. Depois disso, ele começou a conversar com o mundo inteiro.”

---

✅ 2. Segurança fortalecida

Antes de microserviços e OAuth, o CICS 3.1 trouxe mecanismos de autenticação e autorização integrados ao HTTP, simplificando a gestão de usuários e integração com LDAP/RACF.

---

✅ 3. Web Services e SOAP no mainstream

Embora SOAP estivesse surgindo em outros lugares, o CICS 3.1 o integrou de forma sólida, permitindo que as aplicações transacionais fossem expostas como serviços.

📌 Esse passo foi chave para tudo que veio depois em JSON, REST e APIs nativas.

---

✅ 4. Threadsafe Core APIs

No 3.2, a IBM investiu pesado em APIs threadsafe para:

• arquivos VSAM

• journals

• WebSphere MQ

Esse foi um reflexo da necessidade de alta concorrência e escalabilidade.

---

✅ 5. Capacidade ampliada de VSAM e dados grandes

O CICS 3.2 elevou limites históricos:
suporte a arquivos ESDS maiores que 4 GB e tabelas de dados compartilhado maiores que 2 GB.

💬 Comentário Bellacosa:
“Isso significa que sistemas antes fragmentados podiam por fim lidar com conjuntos de dados corporativos gigantescos sem gargalo.”

---

🧪 Melhorias e Mudanças Significativas

🔹 Conectividade TCP/IP madura

Web services + HTTP + TCP/IP tornaram o CICS porta de entrada para arquiteturas distribuídas.

🔹 Usabilidade do CICSPlex SM

Novas vistas de gerenciamento e integração com sistemas de workload distribuído chegaram com 3.2.

🔹 Tradução e interoperabilidade com C/C++ e Java

O CICS começou a ser plataforma de escolha para mixed–language applications num momento em que Java só começava a ganhar tração em corporações.

---

🧠 Curiosidades e Eastereggs Bellacosa

🍺 O “Web CICS” nasceu aqui:
Antes de 3.x, “CICS e Web” era um hack. Depois, virou padrão.

🍺 Threadsafe foi go-to para MQ:
APIs threadsafe mudaram como MQ e VSAM eram acessados dentro de CICS.

🍺 Arquitetura híbrida antes da nuvem:
CICS 3.x já pensava como um servidor de aplicativos moderno, mesmo quando “nuvem” ainda era buzzword futurista.

---

📉 Final de Vida (EOS) — Resumo

Estas versões 3.x já estão fora de suporte há muitos anos — de fato, o foco IBM passou para as séries 4.x e depois 5.x/6.x. A tabela oficial indica o fim do serviço das versões 5.* como referência de política, confirmando que nada abaixo disso terá suporte continuado.

---

📜 História com Exemplo (Bellacosa Way)

Imagine um sistema bancário em 2006:

Você tinha centenas de telas 3270 e milhares de COBOL + BMS.
De repente:

📍 Você habilita HTTP: agora as aplicações web internas da intranet chamam CICS direto.
📍 Você expõe serviços SOAP: aplicativos distribuídos começam a falar com CICS.
📍 Você usa APIs threadsafe com MQ: integração com middleware vira rotina.

💬 Bellacosa comenta:
“Foi aqui que muitos sistemas que deveriam morrer em 5 anos, ainda estão de pé.”

---

💡 Dicas e Recomendações

✅ Entenda como HTTP foi integrado: é o ancestral das integrações REST/JSON que vieram depois.
✅ Aprenda sobre funções threadsafe: quase tudo de moderno em CICS tem raízes nisso.
✅ Use CICSPlex SM: aprendê-lo aqui facilita todo o resto.

---

📌 Conclusão Bellacosa

O CICS TS 3.x foi mais do que uma linha de releases. Foi o momento em que o CICS virou servidor de aplicativos transacionais corporativo — antes disso, ele era “transação e tela”; depois disso, virou plataforma integrada para Web, middleware e aplicações modernas.

🔥 Sem 3.x, não haveria 5.x moderno.
Sem 3.x, o CICS continuaria preso ao passado.

 

Bellacosa Mainframe e as origem das mensagens Hasp

A Origem das Mensagens $HASP no Mainframe

Quem trabalha com:

• JES2;

• SDSF;

• operações z/OS;

• processamento batch;

rapidamente encontra mensagens como:

$HASP373 JOB12345 STARTED

ou:

$HASP395 JOB12345 ENDED

Essas mensagens são extremamente famosas no mundo mainframe.

Mas pouca gente conhece sua verdadeira origem histórica.

---

O que significa $HASP?

HASP significa:

Houston Automatic Spooling Priority

---

Origem histórica

O HASP nasceu nos anos 1960.

Naquela época, os mainframes IBM começaram a enfrentar um grande problema:

• muitas impressoras;

• leitores de cartão;

• filas batch;

• dispositivos lentos;

• grande volume de JOBs.

Era necessário criar um sistema que organizasse:

• spool;

• prioridades;

• entrada e saída batch.

---

Então surgiu o HASP

O sistema foi desenvolvido originalmente pela:

Universidade de Houston

Por isso:

Houston Automatic Spooling Priority.

---

O objetivo inicial

Melhorar:

• gerenciamento de filas;

• uso de impressoras;

• throughput batch;

• desempenho operacional.

---

O que o HASP fazia?

Ele controlava:

• spool;

• impressão;

• leitores de cartão;

• execução batch;

• prioridades.

---

A IBM gostou tanto da ideia…

…que incorporou o HASP ao sistema operacional.

Com o tempo ele evoluiu para:

JES2.

---

Relação entre HASP e JES2

Historicamente:

HASP
   ↓
HASP II
   ↓
JES2

---

Então JES2 veio do HASP?

Sim.

O JES2 é descendente direto do antigo HASP.

Por isso até hoje as mensagens continuam usando:

$HASP

---

O que significa o símbolo "$"?

No JES2:

"$"

normalmente indica:

• comandos;

• mensagens do subsistema.

---

Exemplo clássico

$HASP100

Mensagem do JES2/HASP.

---

Mensagens famosas do HASP

---

$HASP373

JOB iniciado.

Exemplo:

$HASP373 MEUJOB STARTED

---

$HASP395

JOB finalizado.

Exemplo:

$HASP395 MEUJOB ENDED

---

$HASP250

JOB aguardando execução.

---

$HASP099

Mensagens gerais do JES2.

---

Por que as mensagens continuaram?

Compatibilidade histórica.

O mainframe IBM possui uma característica lendária:

preservar compatibilidade por décadas.

Então:

• programas antigos;

• automações;

• operadores;

• documentações;

continuaram usando:

$HASP.

---

Isso virou tradição no mainframe

Hoje:

• operadores reconhecem mensagens HASP instantaneamente;

• automações monitoram $HASP;

• sistemas batch dependem delas.

---

O que as mensagens HASP informam?

Elas mostram:

• início de JOB;

• fim de JOB;

• status batch;

• spool;

• erros;

• filas;

• impressoras;

• initiators.

---

Onde aparecem?

Principalmente em:

• SDSF;

• JESMSGLG;

• consoles z/OS;

• logs operacionais.

---

Exemplo real no SDSF

$HASP373 PAYROLL STARTED
$HASP395 PAYROLL ENDED - RC=0000

---

O que é RC?

Return Code.

Indica:

• sucesso;

• warning;

• erro.

---

As mensagens HASP ainda são usadas?

Muito.

Praticamente todos os ambientes JES2 modernos continuam exibindo:

$HASP.

---

O HASP existia antes do z/OS?

Sim.

Muito antes.

Ele surgiu ainda na era:

• OS/360;

• cartões perfurados;

• impressoras line printer.

---

O que era spool naquela época?

Os JOBs eram enviados por:

• cartões;

• leitores físicos;

• impressoras gigantes.

O HASP ajudava a organizar tudo.

---

Curiosidade histórica incrível

Antes do HASP…

muitos sistemas processavam tarefas quase manualmente.

O HASP revolucionou:

automação batch.

---

O que é HASP II?

Evolução do HASP original.

Mais avançado e mais eficiente.

Foi a base direta do:

JES2.

---

JES2 ainda usa conceitos do HASP?

Sim.

Muitos conceitos continuam:

• spool;

• filas;

• classes;

• prioridades;

• mensagens.

---

Curiosidades incríveis

1. HASP nasceu em universidade

E virou padrão mundial.

---

2. O prefixo $HASP sobrevive há décadas

Mesmo após várias gerações do z/OS.

---

3. Operadores experientes decoram códigos HASP

---

4. Muitas automações monitoram mensagens HASP em tempo real

---

O que iniciantes costumam confundir?

---

1. Pensar que HASP é produto separado

Hoje ele está incorporado ao JES2.

---

2. Achar que mensagens $HASP são erros

Muitas são apenas status normais.

---

3. Confundir JES2 com HASP

JES2 é evolução do HASP.

---

4. Ignorar mensagens JESMSGLG

Ali ficam muitas mensagens HASP importantes.

---

Como isso aparece no dia a dia?

Em praticamente toda operação batch:

• submit;

• spool;

• execução;

• término;

• cancelamento.

---

Exemplo clássico de fluxo

SUBMIT
   ↓
$HASP100
   ↓
$HASP373
   ↓
EXECUÇÃO
   ↓
$HASP395

---

Por que aprender isso?

Porque entender HASP ajuda a compreender:

• origem do JES2;

• spool;

• batch;

• história do z/OS;

• evolução operacional do mainframe.

---

Resumo rápido

Conceito	Significado
HASP	Houston Automatic Spooling Priority
Origem	Universidade de Houston
Evoluiu para	JES2
$HASP373	JOB started
$HASP395	JOB ended
Spool	Gerenciamento batch
JES2	Descendente do HASP

---

Conclusão

As mensagens $HASP são herança direta de um dos sistemas mais importantes da história do mainframe.

Criado originalmente na Universidade de Houston, o HASP revolucionou o gerenciamento batch e evoluiu para o JES2 moderno, mantendo até hoje suas mensagens clássicas dentro do ambiente z/OS IBM Z.

 

Bellacosa Mainframe o que é spool

O que é Spool?

Quando alguém começa a estudar mainframe, rapidamente encontra palavras como:

• JES2;

• SDSF;

• SYSOUT;

• batch;

• spool.

E normalmente surge a pergunta:

O que exatamente é spool?

A resposta é simples:

spool é uma área temporária usada para armazenar saídas e entradas de JOBs.

Mas por trás disso existe um dos mecanismos mais importantes do z/OS.

---

O que significa Spool?

Spool significa:

Simultaneous Peripheral Operations Online

---

Definição simples

O spool funciona como:

uma área intermediária de armazenamento temporário.

Ele guarda:

• relatórios;

• SYSOUT;

• logs;

• mensagens;

• saídas batch;

• arquivos de impressão.

---

Uma analogia fácil

Imagine uma impressora de escritório.

Várias pessoas enviam documentos ao mesmo tempo.

A impressora não imprime tudo imediatamente.

Então existe:

uma fila temporária.

O spool funciona exatamente assim.

---

O que o spool faz?

Ele:

• recebe saídas dos JOBs;

• organiza filas;

• armazena temporariamente;

• libera saída quando necessário.

---

Onde o spool é usado?

Principalmente em:

• JES2;

• JES3;

• SDSF;

• processamento batch.

---

Fluxo simples do spool

JOB
 ↓
EXECUÇÃO
 ↓
SYSOUT
 ↓
SPOOL
 ↓
SDSF
 ↓
USUÁRIO

---

O que fica armazenado no spool?

---

SYSOUT

Saída do JOB.

---

Logs

Mensagens do sistema.

---

Relatórios

Resultados batch.

---

Mensagens JES2

Status e execução.

---

Dumps

Informações de erro e ABEND.

---

O que é SYSOUT?

SYSOUT significa:

saída do sistema.

Exemplo:

//SYSOUT DD SYSOUT=*

---

O que acontece quando um JOB termina?

O resultado normalmente vai para:

spool.

Depois o usuário visualiza via:

SDSF.

---

O spool é um dataset?

Internamente o spool usa estruturas especiais do sistema.

Ele não funciona como um dataset comum.

---

Quem controla o spool?

Normalmente:

JES2

ou:

JES3.

---

O SDSF acessa o spool

Ele permite:

• visualizar;

• pesquisar;

• administrar saídas.

---

Como visualizar spool?

No SDSF:

• ST;

• O;

• H;

• LOG.

---

Exemplo no SDSF

NP JOBNAME JOBID OWNER STATUS

Selecionando o JOB aparecem:

• JESMSGLG;

• JESJCL;

• JESYSMSG;

• SYSOUT.

---

Arquivos clássicos do spool

---

JESJCL

JCL interpretado.

---

JESMSGLG

Mensagens JES2.

---

JESYSMSG

Mensagens do sistema.

---

SYSOUT

Relatórios da aplicação.

---

CEEDUMP

Dump em caso de erro.

---

O que é HOLD?

Saída pode ficar:

retida no spool.

Aguardando:

• análise;

• impressão;

• liberação.

---

O que é purge?

Remover saída do spool.

---

O spool ocupa disco?

Sim.

O spool utiliza armazenamento DASD.

---

Por que o spool é importante?

Porque praticamente todo processamento batch depende dele.

Sem spool:

• JOBs falham;

• relatórios somem;

• impressão para;

• operações batch quebram.

---

O que é spool full?

Quando o espaço do spool acaba.

Isso pode causar:

• paralisação batch;

• falha de JOBs;

• problemas críticos.

---

Operadores monitoram spool constantemente

Especialmente em:

• bancos;

• processamento noturno;

• grandes batchs.

---

Como o spool ajuda performance?

Ele desacopla:

• execução;

• impressão;

• leitura;

• saída.

Tudo pode acontecer em momentos diferentes.

---

Analogia simples

Sem spool:

• JOB teria de esperar impressora.

Com spool:

• JOB termina rapidamente;

• impressão acontece depois.

---

O spool ainda é usado hoje?

Muito.

Mesmo com:

• PDFs;

• relatórios digitais;

• cloud;

• automação.

O conceito continua essencial.

---

O que é spool dataset?

Área interna usada pelo JES2 para armazenar spool.

---

O que é spool offload?

Transferência do spool para:

• backup;

• arquivamento;

• retenção.

---

O que é output class?

Classe de saída.

Exemplo:

//SYSOUT=A

Define:

• prioridade;

• destino;

• tratamento da saída.

---

O que é writer?

Processo responsável por:

• imprimir;

• transferir;

• processar saídas spool.

---

Curiosidades incríveis

1. O spool existe desde os primeiros mainframes

---

2. O conceito influenciou sistemas modernos de fila

---

3. Grandes bancos geram milhões de páginas de spool diariamente

---

4. Muitos problemas operacionais começam por spool cheio

---

Erros comuns de iniciantes

---

1. Confundir spool com dataset comum

Spool possui gerenciamento especial.

---

2. Apagar spool importante

Pode remover logs críticos.

---

3. Ignorar SYSOUT

Ali ficam mensagens fundamentais.

---

4. Não monitorar espaço spool

Isso pode derrubar batchs.

---

Como o spool aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• JCL;

• batch;

• relatórios;

• DB2;

• SORT;

• automação.

---

Exemplo real

Programa COBOL:

DISPLAY 'PROCESSAMENTO OK'

Mensagem aparece no:

spool.

---

Como acessar rapidamente?

No SDSF:

ST

Selecionar JOB:

?

---

Por que aprender spool?

Porque ele é:

uma das bases do processamento batch no z/OS.

Quem entende spool entende:

• JES2;

• SDSF;

• SYSOUT;

• operações;

• troubleshooting.

---

Resumo rápido

Conceito	Significado
Spool	Área temporária batch
SYSOUT	Saída do JOB
JES2	Gerencia spool
SDSF	Visualiza spool
HOLD	Retém saída
PURGE	Remove spool
Output Class	Classe de saída

---

Conclusão

O spool é um dos mecanismos mais importantes do ambiente mainframe IBM Z.

Ele permite armazenar, organizar e controlar entradas e saídas de JOBs batch com eficiência, garantindo que o processamento no z/OS aconteça de forma rápida, organizada e confiável.

 

Bellacosa Mainframe introduz o SDSF

Introdução ao SDSF

Quando alguém começa a trabalhar no ambiente z/OS, rapidamente encontra uma ferramenta extremamente importante chamada:

SDSF

Ela é uma das interfaces mais usadas no dia a dia do mainframe.

Praticamente todo operador, programador COBOL, analista de produção ou administrador z/OS utiliza SDSF constantemente.

---

O que significa SDSF?

SDSF significa:

Spool Display and Search Facility

Em português:

Facilidades de Visualização e Pesquisa do Spool

---

Definição simples

O SDSF é uma ferramenta do z/OS usada para:

• monitorar JOBs;

• visualizar spool;

• acompanhar execução batch;

• consultar SYSOUT;

• administrar tarefas do sistema.

---

Uma analogia fácil

Imagine um aeroporto.

O JES2 seria:

a torre de controle.

O SDSF seria:

o painel onde os operadores acompanham todos os voos em tempo real.

---

O que o SDSF monitora?

Ele mostra:

• JOBs ativos;

• JOBs finalizados;

• spool;

• logs;

• tarefas do sistema;

• started tasks;

• mensagens do JES2.

---

O que é spool?

Spool é a área onde ficam:

• relatórios;

• SYSOUT;

• mensagens;

• logs batch.

O SDSF é a principal interface para visualizar isso.

---

Como acessar o SDSF?

Normalmente pelo:

ISPF

Ou digitando:

SDSF

na linha de comando TSO.

---

O que aparece ao abrir?

O SDSF possui vários painéis.

Os mais famosos são:

• ST

• DA

• I

• O

• H

• LOG

---

Painel ST

Status

Mostra:

• JOBs;

• started tasks;

• tarefas ativas.

---

Exemplo

COMMAND INPUT ===>
NP JOBNAME  JobID    Owner    Status

---

Painel DA

Display Active

Mostra:

• tarefas em execução;

• uso ativo do sistema.

---

Painel I

Input Queue

Mostra JOBs aguardando execução.

---

Painel O

Output Queue

Mostra saídas SYSOUT.

---

Painel H

Held Output

JOBs ou outputs em HOLD.

---

Painel LOG

Mostra logs do sistema.

Muito usado por operadores.

---

O que é um JOB?

JOB é um processamento batch.

Exemplos:

• fechamento bancário;

• folha salarial;

• backups;

• relatórios.

---

Como visualizar um JOB?

No painel ST:

1. localizar JOB;

2. colocar:

?

ou:

S

3. pressionar ENTER.

---

O que aparece?

• JESMSGLG;

• JESJCL;

• JESYSMSG;

• SYSOUT;

• relatórios;

• logs COBOL.

---

Arquivos famosos dentro do spool

---

JESJCL

Mostra JCL interpretado.

---

JESMSGLG

Log do JES2.

---

JESYSMSG

Mensagens do sistema.

---

SYSOUT

Saída da aplicação.

---

Como cancelar JOB?

Comandos no SDSF:

C

---

Como colocar HOLD?

H

---

Como liberar JOB?

A

---

Como apagar spool?

P

ou:

PURGE

---

O SDSF é apenas visualização?

Não.

Dependendo da autorização RACF, ele permite:

• controlar JOBs;

• cancelar tarefas;

• liberar spool;

• administrar sistema.

---

O SDSF usa JES2?

Sim.

O SDSF é uma interface que conversa com:

• JES2;

• JES3;

• z/OS.

---

O SDSF substitui o JES2?

Não.

---

JES2

Gerencia JOBs.

---

SDSF

Monitora e controla via interface.

---

Como o SDSF aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• batch;

• produção;

• operações;

• automação;

• suporte.

---

Exemplo prático

Fluxo simples:

SUBMIT JOB
     ↓
JES2 recebe
     ↓
JOB executa
     ↓
SDSF monitora
     ↓
Usuário visualiza SYSOUT

---

O que é SYSOUT?

Saída gerada pelo JOB:

• relatórios;

• mensagens;

• resultados.

---

O que é STC?

Started Task.

Tarefas permanentes do sistema:

• CICS;

• DB2;

• VTAM;

• JES2.

---

O SDSF mostra uso do sistema?

Sim.

Dependendo do ambiente:

• CPU;

• memória;

• iniciadores;

• spool;

• workload.

---

O que é OWNER?

Dono do JOB.

---

O que é JOBID?

Identificador único do JOB.

Exemplo:

JOB12345

---

Curiosidades incríveis

1. Operadores passam horas no SDSF

É uma das telas mais usadas do z/OS.

---

2. O SDSF virou padrão operacional do mainframe

---

3. Grandes bancos monitoram milhares de JOBs simultaneamente

---

4. Muitos incidentes críticos são analisados via SDSF

---

Erros comuns de iniciantes

---

1. Confundir SDSF com JES2

SDSF = interface
JES2 = subsistema batch

---

2. Apagar spool sem cuidado

Isso pode remover logs importantes.

---

3. Não entender classes e status

Muito importante para operações.

---

4. Pensar que SDSF serve apenas para visualizar JOB

Ele também administra tarefas.

---

Dicas importantes

Aprenda primeiro:

• ST;

• DA;

• O;

• LOG.

---

Aprenda comandos básicos:

• S;

• ?;

• C;

• H;

• P.

---

Leia JESMSGLG sempre

Ajuda muito no troubleshooting.

---

Como o SDSF ajuda programadores COBOL?

Permite:

• ver ABENDs;

• analisar SYSOUT;

• validar execução batch;

• consultar RC.

---

O que é RC?

Return Code

Código de retorno do JOB.

Exemplo:

CC 0000

Indica sucesso.

---

Por que aprender SDSF?

Porque ele é:

uma das ferramentas mais importantes do z/OS.

Quem domina SDSF entende:

• batch;

• spool;

• JOBs;

• troubleshooting;

• operações mainframe.

---

Resumo rápido

Conceito	Significado
SDSF	Monitor de spool/JOBs
ST	Status
DA	Active tasks
O	Output
H	Held output
SYSOUT	Saída do JOB
JOBID	Identificação do JOB
RC	Return Code

---

Conclusão

O SDSF é uma das ferramentas centrais do ambiente mainframe IBM Z.

Ele permite monitorar, visualizar e administrar JOBs, spool e tarefas do sistema em tempo real, sendo essencial para operações, desenvolvimento COBOL e administração do z/OS.

 

Bellacosa Mainframe e o que é jes2

O que é JES2?

Quando alguém começa a estudar mainframe, rapidamente encontra nomes como:

• JOB;

• spool;

• batch;

• SDSF;

• JES2.

E logo surge a pergunta:

Quem controla os JOBs no z/OS?

A resposta normalmente é:

JES2

Ele é um dos componentes mais importantes do ambiente mainframe.

---

O que significa JES2?

JES2 significa:

Job Entry Subsystem 2

Em português:

Subsistema de Entrada de Jobs

---

Definição simples

O JES2 é o componente do z/OS responsável por:

• receber JOBs;

• controlar execução batch;

• gerenciar spool;

• controlar impressões;

• organizar filas de processamento.

---

Uma analogia fácil

Imagine um grande aeroporto.

Existem:

• aviões;

• filas;

• pistas;

• autorização de decolagem;

• controle de tráfego.

O JES2 funciona como:

a torre de controle dos JOBs do mainframe.

Ele decide:

• quem entra;

• quem espera;

• quem executa;

• quem terminou.

---

O que é um JOB?

JOB é um processamento batch.

Exemplo:

• folha salarial;

• fechamento bancário;

• relatórios;

• backup;

• processamento financeiro.

---

O que o JES2 faz?

---

1. Recebe JOBs

Quando o usuário executa:

SUBMIT

o JOB vai para o JES2.

---

2. Coloca em fila

O JES2 organiza:

• prioridade;

• classe;

• recursos;

• ordem de execução.

---

3. Controla spool

Armazena:

• SYSOUT;

• logs;

• relatórios;

• mensagens.

---

4. Inicia execução

Quando recursos ficam disponíveis:
o JES2 libera o JOB.

---

5. Finaliza processamento

Depois:

• guarda saída;

• libera recursos;

• mantém logs.

---

O que é spool?

Spool significa:

Simultaneous Peripheral Operations Online

É uma área temporária onde ficam:

• saídas;

• relatórios;

• SYSOUT;

• mensagens batch.

---

Analogia simples

Imagine:

uma fila de impressão gigante.

O JES2 organiza tudo antes da saída final.

---

Fluxo simplificado do JES2

USUÁRIO
   ↓
SUBMIT
   ↓
JES2
   ↓
FILA
   ↓
EXECUÇÃO
   ↓
SPOOL
   ↓
OUTPUT

---

O JES2 executa o JOB?

Não diretamente.

Quem executa é:

o initiator.

O JES2:

• controla;

• agenda;

• organiza.

---

O que é initiator?

Processo que executa JOBs batch.

O JES2 entrega JOBs para ele.

---

O que é classe no JES2?

Os JOBs podem possuir:

• classes;

• prioridades;

• políticas.

Exemplo:

//JOBNAME JOB CLASS=A

---

Isso ajuda o sistema a organizar workload

Por exemplo:

• jobs rápidos;

• jobs pesados;

• produção;

• testes.

---

O que é SYSOUT?

Saída gerada pelo JOB.

Exemplo:

• relatórios;

• mensagens;

• logs COBOL.

---

Onde visualizar JOBs?

Principalmente via:

SDSF

---

Painéis famosos do SDSF

---

ST

Status dos JOBs.

---

DA

Jobs ativos.

---

O

Output.

---

H

Held output.

---

Como um JOB entra no JES2?

Exemplo simples:

//MEUJOB JOB ...
//STEP1 EXEC PGM=IEFBR14

Usuário executa:

SUBMIT

O JES2 recebe o JOB.

---

O que é HOLD?

JOB fica parado aguardando liberação.

---

O que é CANCEL?

Cancela JOB.

---

O que é purge?

Remove JOB do spool.

---

O que é output class?

Classe da saída SYSOUT.

Exemplo:

//SYSOUT=A

---

O JES2 controla impressoras?

Historicamente:
sim.

Hoje também controla:

• saída eletrônica;

• spool digital;

• relatórios.

---

JES2 vs JES3

Existem dois grandes subsistemas históricos:

---

JES2

Mais popular.

Mais simples e distribuído.

---

JES3

Controle mais centralizado.

Hoje JES2 domina a maioria dos ambientes.

---

O JES2 ainda é usado?

Muito.

Principalmente em:

• bancos;

• seguradoras;

• governos;

• processamento financeiro.

---

Curiosidades incríveis

1. O JES2 existe há décadas

E continua essencial.

---

2. Bilhões de JOBs passam pelo JES2

Todos os anos.

---

3. Grande parte do sistema financeiro depende dele

Principalmente batch noturno.

---

4. O spool é uma das áreas mais críticas do z/OS

Sem spool o batch praticamente para.

---

O que iniciantes costumam confundir?

---

1. Pensar que JES2 executa programas diretamente

Quem executa é o initiator.

---

2. Confundir JES2 com SDSF

JES2 = subsistema
SDSF = interface de monitoramento.

---

3. Ignorar classes

Elas afetam:

• prioridade;

• execução;

• workload.

---

4. Confundir spool com dataset comum

Spool possui gerenciamento especial.

---

Como o JES2 aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• batch;

• SORT;

• backups;

• DB2;

• relatórios;

• automação.

---

Mensagens famosas do JES2

---

$HASP

Prefixo clássico do JES2.

Exemplo:

$HASP373 JOB STARTED

---

$HASP395

JOB finalizado.

---

Essas mensagens são lendárias no mundo mainframe

---

Por que aprender JES2?

Porque ele é:

o coração do processamento batch do z/OS.

Quem entende JES2 entende:

• batch;

• spool;

• execução de JOBs;

• operação mainframe.

---

Resumo rápido

Conceito	Significado
JES2	Gerenciador de JOBs
JOB	Processamento batch
Spool	Área de saída temporária
SYSOUT	Saída do JOB
Initiator	Executa JOB
SDSF	Interface de monitoramento
CLASS	Prioridade/categoria

---

Conclusão

O JES2 é um dos componentes mais importantes do z/OS.

Ele funciona como a central de controle do processamento batch, organizando JOBs, spool, filas e execução dentro do ambiente mainframe IBM Z.

Mesmo após décadas de existência, continua sendo peça fundamental da computação corporativa moderna.