Translate

Mostrar mensagens com a etiqueta qsam. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta qsam. Mostrar todas as mensagens

quarta-feira, 10 de dezembro de 2025

☕ EXECIO no REXX Mainframe O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

 



EXECIO no REXX Mainframe

O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

“Quando o REXX toca no disco, o EXECIO está por trás.
E quando o disco fica lento, geralmente é culpa de quem não entendeu o EXECIO.”




🧠 Introdução – Onde o REXX encontra o mundo real

REXX é excelente para controle, decisão e orquestração.
Mas em algum momento ele precisa fazer o que todo batch faz desde 1964:

👉 Ler dados
👉 Escrever dados

É aí que entra o EXECIO.

Simples no nome.
Perigoso no impacto.


🕰️ Origem histórica – Por que o EXECIO nasceu?

Antes do EXECIO:

  • REXX era fortemente interativo

  • I/O era dependente de comandos externos

  • Ler arquivos sequenciais era lento e improvisado

Com a popularização do REXX no TSO/E e no batch, a IBM precisava de:

  • Um método padrão

  • Um comando eficiente

  • Compatível com DDNAME

  • Funcional tanto em TSO quanto em batch

Assim nasceu o EXECIO, no final dos anos 80, como ponte direta entre:

REXX ⇄ QSAM ⇄ MVS


📜 O que é EXECIO?

EXECIO é o comando REXX responsável por:

  • Ler registros de um DDNAME

  • Escrever registros em um DDNAME

  • Transferir dados entre datasets e variáveis REXX

Ele trabalha sempre com:

  • DDNAME alocado

  • Registros sequenciais

  • Stem variables


🧪 Sintaxe essencial

EXECIO <quantidade> DISKR <ddname> (STEM var. EXECIO <quantidade> DISKW <ddname> (STEM var.

Exemplo básico:

EXECIO * DISKR SYSIN (STEM linhas.

Aqui:

  • * = todas as linhas

  • DISKR = leitura

  • SYSIN = DDNAME

  • linhas. = onde os dados vão morar


🧩 Curiosidades que pouca gente comenta

🧩 1. EXECIO não entende “arquivo”

Ele entende DDNAME.

Se o DDNAME não existe:

  • RC pode ser enganoso

  • O erro aparece em mensagem

  • GETMSG vira obrigatório


🧩 2. EXECIO * carrega tudo na memória

EXECIO * DISKR BIGFILE (STEM big.

Se o arquivo tem:

  • 10 mil linhas → ok

  • 1 milhão → boa sorte

EXECIO * é confortável… até não ser.


🧩 3. A variável .0 manda mais que você

Após leitura:

say linhas.0

Ela contém quantos registros foram lidos.

Ignorar .0 é convite a loop errado.


🥚 Easter Eggs técnicos

🥚 1. Leitura parcial estratégica

EXECIO 1 DISKR INDD (STEM linha.

Ótimo para:

  • Ler cabeçalhos

  • Identificar layout

  • Decidir processamento sem ler tudo


🥚 2. EXECIO + Data Stack

É possível combinar:

  • EXECIO

  • PUSH / QUEUE

  • PARSE PULL

Criando pipelines “à moda antiga”.


🥚 3. EXECIO em SYSREXX

No batch, EXECIO:

  • Roda sem terminal

  • Depende totalmente do JCL

  • É mais rápido

  • É mais perigoso


🧠 Exemplo prático – Batch inteligente

EXECIO * DISKR INPUT (STEM in. DO i = 1 TO in.0 IF POS('ERRO', in.i) > 0 THEN DO SAY 'Erro detectado na linha' i EXIT 8 END END EXECIO in.0 DISKW OUTPUT (STEM in.

Esse REXX:

  • Analisa

  • Decide

  • Escreve

Tudo antes do COBOL rodar.


⚠️ Riscos reais do EXECIO

  • Arquivo grande → consumo de memória

  • DISKW sem controle → overwrite silencioso

  • DISKR sem validação → loop infinito

  • Falta de fechamento → dados inconsistentes

Boa prática Jedi

EXECIO 0 DISKW OUTDD

Força flush e fechamento correto.


🛡️ EXECIO e segurança

EXECIO respeita:

  • RACF

  • Permissões de dataset

  • Contexto do job

Mas:

REXX que escreve dados é tão poderoso quanto um utility IBM.

Controle de acesso é obrigatório.


☕ Comentário Bellacosa Mainframe

O EXECIO é o momento em que:

  • O REXX deixa de ser “script”

  • E passa a mexer em dados corporativos

Quem trata EXECIO como “detalhe”:

  • Cria batch frágil

  • Gera incidentes silenciosos

  • Descobre o erro em produção

EXECIO não é comando.
É compromisso com o dado.


🧠 Frase final para colar no monitor

Se o REXX leu, ele é responsável.
Se escreveu, ele é culpado até prova em contrário.

sexta-feira, 20 de setembro de 2024

Conheça a Stack Mainframe

Bem-vindo a Stack Mainframe, aprenda COBOL #ibm #mainframe #cobol #cics #db2 #sdsf #jes2 #job #jcl #rexx #qsam #vsam

sábado, 20 de julho de 2024

Road Map para Aprender Mainframe

O que um jovem padawan deve aprender para ser um especialista na Stack Mainframe. Um caminho com inúmeras possibilidades, requer esforço e dedicação, porém os frutos condizem ao esforço. Descubra o z/OS, codifique em COBOL, crie queries no SQL DB2 e vá além. #ibm #mainframe #cobol #cics #db2 #jcl #sdsf #qsam #vsam #query #sql #etl #jobs #procs #jes2 #lpar #sysplex

sábado, 13 de abril de 2024

Conheça unidade de armazenamento CARTRIDGE Storage


A
storage mainframe cartridge e robot de leitura

FUJIFILM Corporation e a IBM anunciaram o desenvolvimento de um sistema de armazenamento em fita nativo de 50 TB, apresentando a maior capacidade nativa de cartucho de fita de dados do mundo.




 

segunda-feira, 8 de abril de 2024

O COBOL em sua primeira reunião

Codasyl em 1959 o pontapé inicial do COBOL



Em 08 de Abril de 1959, foi dado o pontapé inicial da criação do COBOL. Muita coisa aconteceu desde então, surgiu o armazenamento em cartão perfurado, tape, disco e cartridge, surgiram o qsam, vsam, db2. Acompanhe-nos e descubra mais

sexta-feira, 20 de junho de 2014

☕🔥 ABEND S001 — O “ENIGMA DAS OPERAÇÕES DE I/O” NO z/OS

 

Bellacosa Mainframe e o abend s001

☕🔥 ABEND S001 — O “ENIGMA DAS OPERAÇÕES DE I/O” NO z/OS

Quando o Mainframe Diz:

“ALGUMA COISA DEU MUITO ERRADO COM ESSE DATASET.”

Se existe um ABEND que faz o Junior Padawan perceber que:

o mundo dos arquivos no z/OS é MUITO mais profundo do que parece…

é o misterioso:

🚨 S001

E normalmente ele aparece assim:

SYSTEM COMPLETION CODE=001

ou:

ABEND=S001

ou acompanhado de mensagens obscuras como:

IECxxxI
IOSxxxx

E então começa a jornada de sofrimento:

“O dataset está corrompido?”
“O JCL enlouqueceu?”
“O DCB foi amaldiçoado?”
“O disco morreu?”
“O que significa ESSA mensagem IEC criptografada?!”

☕ Respira.

Porque o S001 é um dos ABENDs mais antigos e misteriosos da linhagem IBM.

E um dos melhores para aprender:

I/O no z/OS

DCB

OPEN/CLOSE/EOV

datasets físicos

operações de leitura/escrita

mídia

estrutura de arquivos


🔥 O QUE É O S001?

O S001 é um:

🚨 INPUT/OUTPUT ERROR ABEND

Traduzindo:

O z/OS DETECTOU UMA FALHA DURANTE OPERAÇÃO DE I/O.


☕ O GRANDE SEGREDO

S001 normalmente NÃO é erro de COBOL.

É:

erro operacional/de dataset/dispositivo.


🔥 A FILOSOFIA DO S001

O mainframe tenta:

  • abrir

  • ler

  • escrever

  • posicionar

  • fechar

um dataset.

Algo dá errado no caminho.

Resultado:

💥 S001


☕ ANALOGIA BELLACOSA MAINFRAME

Imagine um bibliotecário automático tentando pegar um livro num arquivo gigantesco.

Mas:

  • a estante está errada

  • o livro sumiu

  • a etiqueta está corrompida

  • a gaveta travou

O sistema entra em colapso.

Isso é:

☠️ S001


🔥 O MUNDO ESCONDIDO DO I/O

No z/OS, arquivos não são “apenas arquivos”.

Existem:

  • control blocks

  • canais

  • volumes

  • tracks

  • cylinders

  • buffers

  • access methods

S001 nasce nesse território sombrio.


☕ O MOMENTO EXATO

Fluxo:

Programa executa READ/WRITE
 ↓
QSAM/VSAM/Access Method
 ↓
IOS (Input Output Supervisor)
 ↓
Falha operacional
 ↓
S001

🔥 O MAIOR VILÃO

🚨 DCB INCORRETO

Clássico absoluto.


☕ EXEMPLO

Dataset real:

RECFM=FB
LRECL=80

Programa/JCL espera:

VB 120

O OPEN pode até passar…

mas durante I/O:

💥 S001


🔥 O S001 E O “READ ALÉM DO LIMITE”

Outro clássico.

Programa tenta ler:

estrutura incompatível com o dataset real.

Resultado:

  • buffer inconsistente

  • erro físico/lógico

  • S001


☕ O S001 E O SORT

Lenda corporativa.

SORT cria dataset com:

RECFM diferente

Próximo programa assume outro layout.

Boom:

☠️ S001


🔥 O S001 E O VSAM

Agora entramos no reino Jedi obscuro.

VSAM pode gerar S001 por:

  • CI corruption

  • CA damage

  • index inconsistency

  • catalog mismatch


☕ O S001 E O “END OF VOLUME”

Outro clássico ancestral.

Datasets em múltiplos volumes:

  • fita

  • DASD

  • migração

Falha no EOV:

💥 S001


🔥 O S001 E O TAPE

Nos tempos antigos era MUITO comum.

Problemas físicos:

  • fita ruim

  • erro de leitura

  • posicionamento incorreto

  • bloco inválido

Resultado:

☠️ S001


☕ O S001 E O DISP

Outro cenário traiçoeiro.

//ARQ DD DISP=OLD

Mas dataset:

  • não suporta operação esperada

  • está inconsistente

  • está em estado incorreto


🔥 O S001 E O COBOL

COBOL geralmente é vítima, não culpado.

Exemplo:

READ CLIENTE

O READ dispara toda a cadeia:

  • access method

  • buffers

  • IOS

  • device manager

Se algo falha:

💥 S001


☕ O S001 E O “BLOCKSIZE ERRADO”

Outro clássico.

Bloco físico incompatível com expectativa do sistema.

Especialmente em:

  • utilitários antigos

  • transferências

  • IEBCOPY

  • FTP incorreto


🔥 O S001 FANTASMA

O mais cruel.

Programa funcionou:

por anos

Mas:

  • dataset corrompeu

  • volume mudou

  • SMS alterou classe

  • catálogo ficou inconsistente

Agora:

☠️ S001


☕ O S001 E O CATÁLOGO

Catálogo z/OS é praticamente um mapa do universo.

Se existir inconsistência:

  • VTOC

  • catálogo

  • dataset real

o I/O pode falhar.


🔥 O S001 E O “MIGRATED DATASET”

HSM/migração pode introduzir cenários estranhos:

  • recall falho

  • volume offline

  • dataset parcialmente restaurado

Resultado:

💥 S001


☕ COMO INVESTIGAR O S001 PASSO A PASSO


✅ PASSO 1 — IGNORE O COBOL INICIALMENTE

O ouro está nas mensagens do sistema.


✅ PASSO 2 — PROCURE IECxxxx

Exemplos:

IEC141I
IEC161I
IEC070I
IEC030I

Essas mensagens contam a história REAL.


✅ PASSO 3 — IDENTIFIQUE O DDNAME

Qual dataset falhou?

CLIENTE
SORTWK01
MASTER

✅ PASSO 4 — VERIFIQUE O DATASET REAL

Use:

ISPF 3.4
LISTDSI
IDCAMS LISTCAT

Confirme:

  • RECFM

  • LRECL

  • BLKSIZE

  • DSORG

  • volume


✅ PASSO 5 — REVISE O JCL

Especialmente:

DCB=
SPACE=
DISP=
UNIT=

🔥 O DUMP DO S001

Aqui mora a arqueologia mainframe.

Veteranos analisam:

  • DECB

  • DCB

  • IOSB

  • channel status

  • sense bytes


☕ O QUE SÃO SENSE BYTES?

Códigos vindos do hardware/dispositivo.

Sim.

O mainframe conversa diretamente com dispositivos físicos.


🔥 O IOS — O MUNDO INVISÍVEL

Input Output Supervisor

Camada lendária do z/OS responsável pelo I/O físico.

S001 frequentemente nasce aqui.


☕ O S001 E O “ABEND 001-04”

Subcódigos importam MUITO.

Exemplo:

001-04
001-0C
001-18

Cada um aponta um tipo diferente de falha I/O.


🔥 O MAIOR ERRO DO PADAWAN

Recompilar COBOL.

Frequentemente o problema está em:

  • dataset

  • disco

  • DCB

  • catálogo

  • SMS

  • mídia

  • VSAM


☕ O SEGREDO DOS VETERANOS

Veteranos primeiro perguntam:

“QUAL FOI A MENSAGEM IEC?”

Porque:

o S001 sozinho quase nunca conta toda a verdade.


🔥 COMO EVITAR S001


✅ Validar DCB


✅ Revisar RECFM/LRECL


✅ Padronizar layouts


✅ Monitorar VSAM


✅ Revisar SORTs


✅ Validar catálogos


✅ Evitar FTP incorreto


✅ Monitorar volumes/discos


☕ CURIOSIDADE HISTÓRICA

O S001 vem da era:

IBM OS/360

Década de:

🏛️ 1960

Naquele tempo:

  • fitas magnéticas

  • canais físicos

  • controladoras reais

  • operações mecânicas

faziam parte do cotidiano.

O S001 era quase uma entidade sobrenatural dos operadores.


🔥 EASTER EGG MAINFRAME

Veteranos brincam:

“S001 significa:

Alguma Coisa Muito Estranha Aconteceu Com Seu Arquivo.”


☕ O MAIOR ENSINAMENTO DO S001

Ele ensina algo profundo:

no z/OS, arquivos são entidades físicas e arquiteturais complexas.

Não basta:

OPEN INPUT
READ

Existe um universo inteiro entre:

o COBOL e o disco físico.


🔥 A VERDADE FINAL

O S0C7 pune dados inválidos.
O S0C4 pune memória inválida.
O S913 pune acessos proibidos.
O S837 pune falta de espaço.

Mas…

☕ O S001 É O MOMENTO EM QUE O UNIVERSO DE I/O DO z/OS DECIDE QUE ALGUMA COISA NA ESTRUTURA DO DATASET OU DO DISPOSITIVO NÃO FAZ MAIS SENTIDO.


domingo, 3 de outubro de 2010

💽 Tracks, Cilindros e DASD no IBM Mainframe

Bellacosa Mainframe Storage e DASD 3390



💽 Tracks, Cilindros e DASD no IBM Mainframe

Arquitetura, não nostalgia

“O mainframe não mede storage em tracks e cilindros porque é antigo.
Ele faz isso porque sabe exatamente o que está fazendo.”


1️⃣ A origem da filosofia: quando hardware importava (e ainda importa)

Desde os primórdios do IBM System/360 (1964), o mainframe foi projetado com um princípio inegociável:

👉 Controle total do I/O

Naquela época:

  • Disco era caro

  • CPU era valiosa

  • I/O era o gargalo

💡 Conclusão da IBM:

“Se o gargalo é I/O, precisamos dominar o disco até o último detalhe físico.”

Assim nascem os conceitos de:

  • Track

  • Cilindro

  • Bloco

  • Extent

Nada disso é acaso. É engenharia.


2️⃣ O que é um TRACK (pista) – o átomo do DASD

📀 Track é:

  • Uma circunferência física no platter do disco

  • Unidade mínima de alocação real

  • Otimizada para leitura e escrita sequencial

Características importantes:

  • Contém um ou mais blocos

  • O tamanho em bytes não é fixo

  • Depende de:

    • Dataset (PS, PO, VSAM)

    • BLKSIZE

    • Tipo de acesso

📏 Referência clássica (3390):

  • ≈ 56 KB por track (didático, não absoluto)

🧪 Easter egg técnico:

Mesmo quando você pede espaço em MB,
o DFSMS converte tudo para tracks internamente 😎


3️⃣ O que é um CILINDRO – o segredo da performance

🛢️ Cilindro =
Conjunto de tracks alinhados verticalmente em todos os pratos do disco.

Por que isso é genial?

  • O braço do disco não precisa se mover

  • Menos seek

  • Mais throughput

  • Menos latência

📌 Em mainframe:

Performance não é pico, é constância.


IBM HD 3390

4️⃣ Modelos clássicos de DASD IBM (história viva)

📦 IBM 2311 / 2314

  • Anos 60 / 70

  • Discos removíveis

  • Origem dos conceitos de cilindro

📦 IBM 3330 – “Merlin”

  • Gigante físico

  • Primeiro “big storage”

📦 IBM 3380

  • Alta densidade

  • Base para sistemas bancários dos anos 80

📦 IBM 3390 (o eterno)

  • Padrão até hoje (logicamente)

  • Modelos:

    • 3390-3 (~2,8 GB)

    • 3390-9 (~8,4 GB)

  • Referência de cálculo de tracks/cilindros

📦 DS8000 (atual)

  • Storage virtualizado

  • Cache massivo

  • Flash

  • Mas… emula 3390
    😏

O mainframe moderniza sem quebrar o passado.


5️⃣ Evolução: do ferro ao virtual (sem perder o controle)

Hoje:

  • Não existe mais “disco girando” como antes

  • Temos:

    • Cache

    • Flash

    • Virtualização

    • Striping interno

Mas o z/OS continua falando em:

  • Track

  • Cilindro

  • Extent

💡 Por quê?

Porque:

  • SMF mede I/O em tracks

  • WLM calcula impacto por volume

  • SMS aloca espaço físico previsível

  • Batch depende disso


6️⃣ Alocação no dia a dia (JCL raiz)

Exemplo clássico:

//ARQ1 DD DSN=MEU.ARQUIVO,
//         DISP=(NEW,CATLG,DELETE),
//         SPACE=(CYL,(10,5),RLSE),
//         DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

📌 Tradução para o padawan:

  • 10 cilindros primários

  • 5 cilindros secundários

  • Espaço real

  • Custo previsível

  • Impacto conhecido


7️⃣ Performance: onde o mainframe humilha

Linux / Unix:

  • Você pede “10 GB”

  • O filesystem decide tudo

  • Fragmentação invisível

  • Latência variável

Mainframe:

  • Você define:

    • Onde

    • Quanto

    • Como cresce

  • O sistema sabe:

    • Quantos seeks

    • Quantos tracks

    • Quanto I/O será gerado

📊 Resultado:

  • SLA calculável

  • Batch que termina no horário

  • Sistema que envelhece bem


8️⃣ Uso prático: quem realmente se beneficia disso?

🏦 Bancos
✈️ Companhias aéreas
🏛️ Governos
💳 Clearing e pagamentos
📊 BI batch massivo

Onde:

  • Erro não é opção

  • Retry não existe

  • Previsibilidade é rei


9️⃣ Curiosidades e Easter Eggs de mainframer

🧠 Você sabia?

  • SPACE=(TRK,…) ainda é usado em sistemas críticos

  • VSAM define espaço em CI/CA, mas mapeia para tracks

  • SMF Type 42 mede EXCP por dataset

  • EAV permite volumes gigantes, mas o cálculo continua físico

  • O termo DASD é mais velho que “storage” 😄


🔚 Conclusão Bellacosa Mainframe ☕

Falar de tracks e cilindros não é nostalgia.
É respeito à física, engenharia de verdade e responsabilidade operacional.

“Mainframe não abstrai o problema.
Ele encara o problema de frente.”

E é por isso que, décadas depois,
ele ainda roda o mundo.




segunda-feira, 12 de fevereiro de 2007

Comandos COBOL para Manipulação de Arquivos: ACCESS MODE, FILE-CONTROL, FILE STATUS, OPEN, READ, START, WRITE, REWRITE, DELETE e CLOSE

Bellacosa Mainframe e comandos de mainupalação de datasets em Mainframe



Comandos COBOL para Manipulação de Arquivos: ACCESS MODE, FILE-CONTROL, FILE STATUS, OPEN, READ, START, WRITE, REWRITE, DELETE e CLOSE

Quando um programa COBOL trabalha com arquivos QSAM ou VSAM, existe um conjunto de comandos fundamentais que controlam toda a entrada, saída e atualização dos dados.

Esses comandos aparecem diariamente em sistemas:

  • bancários;

  • seguradoras;

  • cartões;

  • governo;

  • ERP;

  • processamento batch.


Visão Geral

FILE-CONTROL
     ↓
OPEN
     ↓
READ / START
     ↓
WRITE / REWRITE / DELETE
     ↓
CLOSE

FILE-CONTROL

Fica na:

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.

Responsável por:

  • associar arquivos;

  • definir organização;

  • definir acesso;

  • definir FILE STATUS.


Exemplo

SELECT ARQCLIENTE
       ASSIGN TO CLIENTE
       ORGANIZATION IS INDEXED
       ACCESS MODE IS DYNAMIC
       RECORD KEY IS CLI-ID
       FILE STATUS IS WS-FS.

ACCESS MODE

Define como o programa acessará o arquivo.


SEQUENTIAL

Leitura em sequência.

ACCESS MODE IS SEQUENTIAL

Fluxo:

REG1
 ↓
REG2
 ↓
REG3

Muito usado em:

  • QSAM

  • Batch


RANDOM

Acesso direto pela chave.

ACCESS MODE IS RANDOM

Exemplo:

PROCURA CLIENTE 1000

Vai diretamente ao registro.


DYNAMIC

Mistura Sequential e Random.

ACCESS MODE IS DYNAMIC

Muito comum em VSAM.


FILE STATUS

Retorno das operações do arquivo.


Declaração

01 WS-FS PIC XX.

Associação

FILE STATUS IS WS-FS

Status comuns

CódigoSignificado
00Sucesso
10EOF
22Chave duplicada
23Registro não encontrado
35Arquivo inexistente
39Definição incompatível
92Erro lógico
93Arquivo não aberto

OPEN

Abre o arquivo.


INPUT

Somente leitura.

OPEN INPUT ARQCLI

OUTPUT

Cria novo arquivo.

OPEN OUTPUT ARQSAIDA

I-O

Leitura e atualização.

OPEN I-O ARQVSAM

EXTEND

Acrescenta registros.

OPEN EXTEND ARQREL

READ

Lê um registro.


QSAM

READ ARQCLI

Com EOF

READ ARQCLI
   AT END
      MOVE 'S' TO EOF
END-READ

READ para VSAM

READ ARQVSAM

Lê o registro corrente.


READ NEXT

Muito usado em VSAM KSDS.


Exemplo

READ ARQVSAM NEXT RECORD

Fluxo

Registro 100
 ↓
READ NEXT
 ↓
Registro 101

START

Posiciona o ponteiro em uma chave.

Funciona apenas em arquivos indexados.


Exemplo

START ARQVSAM
   KEY IS >= WS-CHAVE
END-START

Fluxo

Chave procurada = 1000
       ↓
Posiciona no primeiro >= 1000

Muito usado para pesquisas.


WRITE

Grava novo registro.


Exemplo

WRITE REG-CLIENTE

Em arquivo sequencial

Registro gravado no final

Em VSAM

Registro incluído pela chave

Possível erro

FS = 22

Chave duplicada.


REWRITE

Atualiza registro existente.


Exemplo

REWRITE REG-CLIENTE

Fluxo

READ
 ↓
ALTERA DADOS
 ↓
REWRITE

Exemplo completo

READ ARQVSAM

MOVE 5000 TO CLI-SALDO

REWRITE REG-CLIENTE

DELETE

Remove registro.

Disponível em arquivos indexados.


Exemplo

DELETE ARQVSAM

Fluxo

READ
 ↓
DELETE
 ↓
Registro removido

Muito usado em:

  • VSAM KSDS

  • RRDS


Não funciona em QSAM

Arquivos sequenciais não suportam DELETE.


CLOSE

Fecha arquivo.


Exemplo

CLOSE ARQCLI

Sempre execute CLOSE

Evita:

  • perda de dados;

  • buffers pendentes;

  • inconsistências.


Exemplo Completo VSAM

OPEN I-O ARQCLI

MOVE 1000 TO WS-ID

START ARQCLI
   KEY >= WS-ID

READ ARQCLI NEXT RECORD

IF WS-FS = '00'

   MOVE 'NOVO NOME'
      TO CLI-NOME

   REWRITE REG-CLIENTE

END-IF

CLOSE ARQCLI

Ciclo de Vida de um Arquivo COBOL

FILE-CONTROL
      ↓
OPEN
      ↓
START
      ↓
READ
      ↓
WRITE
      ↓
REWRITE
      ↓
DELETE
      ↓
CLOSE

Resumo Rápido

ComandoFunção
FILE-CONTROLDefine arquivo
ACCESS MODETipo de acesso
FILE STATUSRetorno da operação
OPENAbre arquivo
READLê registro
READ NEXTPróximo registro
STARTPosiciona por chave
WRITEInclui registro
REWRITEAtualiza registro
DELETERemove registro
CLOSEFecha arquivo

Dica de Programador Mainframe

Para arquivos QSAM, normalmente você verá:

OPEN INPUT
READ
WRITE
CLOSE

Para arquivos VSAM KSDS, os comandos mais comuns são:

OPEN I-O
START
READ NEXT
WRITE
REWRITE
DELETE
CLOSE

Esses são os comandos fundamentais que formam a base de praticamente todos os programas COBOL que manipulam arquivos no ambiente IBM Z.


domingo, 11 de fevereiro de 2007

O que é Dataset QSAM?

 

Bellacosa Mainframe o q é dataset QSAM

O que é Dataset QSAM?

QSAM significa:

Queued Sequential Access Method

É um dos métodos de acesso a arquivos mais antigos, importantes e utilizados da história do mainframe.

Praticamente todo programador COBOL batch trabalha com QSAM em algum momento.


Definição simples

QSAM é:

o método de acesso usado para ler e gravar arquivos sequenciais no z/OS.

Quando falamos de um dataset sequencial (PS), normalmente estamos falando de um arquivo acessado através do QSAM.


Analogia simples

Imagine uma fita cassete.

Você precisa ouvir:

Música 1
 ↓
Música 2
 ↓
Música 3
 ↓
Música 4

Não pode pular diretamente para a música 4.

O QSAM funciona da mesma forma.


Fluxo QSAM

Registro 1
    ↓
Registro 2
    ↓
Registro 3
    ↓
Registro 4

Leitura sequencial.


Onde o QSAM é usado?

Principalmente em:

  • COBOL Batch

  • PL/I

  • Assembler

  • Easytrieve

  • SORT

  • Syncsort

  • DFSORT

  • JCL


Tipo de Dataset

Normalmente:

PS (Physical Sequential)

Exemplo de Dataset QSAM

BANCO.CLIENTES.ARQ

Conteúdo:

00001JOAO SILVA
00002MARIA SOUZA
00003CARLOS LIMA

Como o COBOL acessa?

Na ENVIRONMENT DIVISION:

SELECT ARQCLI
ASSIGN TO CLIENTE
ORGANIZATION IS SEQUENTIAL.

Na FILE SECTION

FD ARQCLI.

01 REG-CLIENTE.
   05 CLI-ID    PIC 9(5).
   05 CLI-NOME  PIC X(30).

Leitura QSAM

READ ARQCLI

A cada READ:

Registro 1
 ↓
Registro 2
 ↓
Registro 3

Escrita QSAM

WRITE REG-CLIENTE

O novo registro é gravado no final do arquivo.


Operações principais

OPEN

OPEN INPUT ARQCLI

READ

READ ARQCLI

WRITE

WRITE REG-CLIENTE

CLOSE

CLOSE ARQCLI

Como o JCL participa?

//CLIENTE DD DSN=BANCO.CLIENTES.ARQ,
//            DISP=SHR

Fluxo:

JCL
 ↓
DDNAME
 ↓
QSAM
 ↓
COBOL

O que é Buffering?

O QSAM utiliza buffers em memória.

Em vez de ler um registro por vez:

Disco
 ↓
Buffer
 ↓
Programa

Isso melhora muito a performance.


O que significa "Queued"?

O sistema mantém uma fila de registros em memória.

Por isso o nome:

Queued Sequential Access Method

QSAM x BSAM

QSAM

Mais simples.

O sistema controla os buffers.

Programa
 ↓
QSAM
 ↓
Disco

BSAM

Mais baixo nível.

O programador controla os buffers.

Programa
 ↓
Buffer Manual
 ↓
Disco

QSAM x VSAM

QSAM

Acesso sequencial.

1
↓
2
↓
3
↓
4

VSAM KSDS

Acesso por chave.

PROCURA CHAVE 00003
       ↓
Registro encontrado

Vantagens do QSAM

✅ Simples

✅ Excelente para batch

✅ Muito rápido

✅ Fácil programação COBOL

✅ Baixo consumo de recursos


Desvantagens

❌ Não possui índice

❌ Não acessa diretamente um registro específico

❌ Necessita percorrer registros anteriores


Casos de uso clássicos

Folha salarial

Funcionário 1
Funcionário 2
Funcionário 3
...

Relatórios

Cliente 1
Cliente 2
Cliente 3
...

Processamento bancário

Transação 1
Transação 2
Transação 3
...

Exemplo Batch Completo

OPEN INPUT ARQCLI

PERFORM UNTIL EOF = 'S'

   READ ARQCLI
      AT END
         MOVE 'S' TO EOF

      NOT AT END
         PERFORM PROCESSAR

   END-READ

END-PERFORM

CLOSE ARQCLI

Curiosidades

1. Grande parte dos batchs do mundo ainda utiliza QSAM

2. O QSAM existe desde os primeiros sistemas OS/360

3. Muitos bancos processam bilhões de registros QSAM diariamente

4. DFSORT e Syncsort trabalham intensamente com datasets QSAM


Erros comuns de iniciantes

Esquecer OPEN


Não tratar EOF


Layout incompatível


DDNAME diferente do ASSIGN


Não verificar FILE STATUS


Resumo rápido

ConceitoSignificado
QSAMQueued Sequential Access Method
Tipo de ArquivoSequencial (PS)
AcessoSequencial
Comando COBOLREAD / WRITE
PerformanceAlta
ÍndiceNão
Uso PrincipalBatch
BufferAutomático

Conclusão

O QSAM é o método de acesso padrão para datasets sequenciais no z/OS. Ele utiliza buffers automáticos e acesso sequencial aos registros, sendo a base de grande parte dos programas COBOL batch executados diariamente nos ambientes IBM Z.


sexta-feira, 12 de janeiro de 2007

O que é Blockagem em Dataset QSAM?

 


O que é Blockagem em Dataset QSAM?

Quando começamos a estudar datasets no mainframe, rapidamente aparecem termos como:

  • RECFM;

  • LRECL;

  • BLKSIZE;

  • blockagem.

No começo parece algo extremamente técnico.

Mas a ideia é mais simples do que parece.

E entender blockagem é fundamental para:

  • performance;

  • uso de disco;

  • processamento batch;

  • COBOL;

  • SORT;

  • QSAM.


Primeiro: o que é QSAM?

QSAM significa:

Queued Sequential Access Method

É um método de acesso usado no z/OS para trabalhar com arquivos sequenciais.

Ele é muito utilizado em:

  • COBOL;

  • JCL;

  • relatórios batch;

  • processamento financeiro.


O que é um registro?

Antes da blockagem, precisamos entender:

registro.

Um registro representa:

uma linha de dados.

Exemplo:

JOAO      0001500
MARIA     0003200
CARLOS    0009800

Cada linha é um registro.


O problema sem blockagem

Imagine um dataset com:

  • milhões de registros;

  • cada registro com 80 bytes.

Se o disco gravasse:

  • 1 registro por vez,

o sistema faria milhões de operações de I/O.

Isso seria:

  • lento;

  • caro;

  • ineficiente.


Então nasceu a blockagem

A ideia é simples:

agrupar vários registros em um único bloco físico.


Analogia fácil

Imagine transportar livros.

Sem blockagem:

  • 1 livro por viagem.

Com blockagem:

  • vários livros dentro de uma caixa.

Resultado:

  • menos viagens;

  • mais eficiência.


O que é um bloco?

Bloco é:

um conjunto de registros gravados juntos no disco.


Exemplo simples

Imagine:

  • registro = 80 bytes

  • bloco = 800 bytes

O sistema consegue armazenar:

10 registros dentro do mesmo bloco

Porque:

10 × 80 = 800

Onde isso aparece?

Na definição do dataset:

RECFM=FB
LRECL=80
BLKSIZE=800

Entendendo os parâmetros


RECFM=FB

Formato:

Fixed Block

Registros fixos com blockagem.


LRECL=80

Cada registro possui:
80 bytes.


BLKSIZE=800

Cada bloco possui:
800 bytes.


Resultado

O sistema grava:

10 registros por bloco.


Por que isso melhora performance?

Porque o disco trabalha melhor lendo:

  • grandes blocos;
    do que:

  • registros individuais.


Benefícios da blockagem


1. Menos I/O

Reduz acessos físicos ao disco.


2. Mais velocidade

Leitura e gravação mais rápidas.


3. Melhor uso do disco

Menos desperdício.


4. Melhor performance batch

Especialmente em:

  • SORT;

  • COBOL;

  • grandes arquivos.


O que acontece sem blockagem?

Exemplo:

RECFM=F
LRECL=80

Aqui:

  • registros fixos;

  • sem blocagem.

Cada registro é gravado separadamente.


Isso é ruim?

Nem sempre.

Mas normalmente:

  • FB é mais eficiente que F.


Blockagem em VB

Também existe em datasets variáveis.

Exemplo:

RECFM=VB

Nesse caso:

  • registros possuem tamanhos diferentes;

  • mas continuam agrupados em blocos.


O que é BLKSIZE?

BLKSIZE significa:

Block Size

Define:

o tamanho físico do bloco.


Exemplo visual

Sem blockagem:

[REG]
[REG]
[REG]
[REG]

Com blockagem:

[BLOCO: REG REG REG REG]

Quem define a blockagem?

Pode ser:

  • programador;

  • JCL;

  • sistema;

  • SMS do z/OS.


O sistema pode calcular sozinho?

Sim.

Hoje muitos ambientes usam:

BLKSIZE=0

O z/OS calcula automaticamente o melhor tamanho.


Isso é muito usado atualmente

Porque:

  • reduz erros;

  • otimiza performance;

  • simplifica configuração.


Exemplo de JCL

//ARQ DD DSN=USUARIO.TESTE,
//    DISP=(NEW,CATLG),
//    RECFM=FB,
//    LRECL=80,
//    BLKSIZE=800

O que isso cria?

Dataset:

  • registros fixos;

  • 80 bytes;

  • 10 registros por bloco.


Como COBOL lê isso?

O COBOL normalmente não “vê” a blockagem diretamente.

O QSAM e o z/OS fazem isso automaticamente.


O programador trabalha com registros

O sistema operacional cuida dos blocos.


O que é blocking factor?

Também chamado:

fator de blockagem.

Indica:
quantos registros cabem no bloco.


Exemplo

LRECL = 80
BLKSIZE = 800

Fator:

800 ÷ 80 = 10

Então:

blocking factor = 10


Erros comuns de iniciantes


1. Confundir bloco com registro

Registro = linha lógica
Bloco = agrupamento físico


2. Ignorar BLKSIZE

Isso pode afetar performance.


3. Pensar que COBOL controla tudo

Quem gerencia blockagem é:

  • QSAM;

  • z/OS.


4. Definir BLKSIZE errado

Pode gerar desperdício ou erros.


Curiosidades incríveis

1. Blockagem existe desde os primeiros mainframes

Porque I/O sempre foi crítico.


2. Grandes bancos dependem fortemente disso

Performance batch seria inviável sem blockagem.


3. O conceito influenciou vários sistemas modernos

Mesmo hoje muitos bancos de dados usam ideias parecidas.


4. Um bom BLKSIZE pode melhorar muito performance

Principalmente em arquivos gigantes.


Como visualizar atributos do dataset?

No ISPF 3.4:

  • digite I;

  • veja:

    • RECFM;

    • LRECL;

    • BLKSIZE.

Ou via comando:

LISTDS 'USUARIO.ARQ'

Resumo rápido

ConceitoSignificado
RegistroLinha lógica
BlocoGrupo de registros
BlockagemAgrupar registros
BLKSIZETamanho do bloco
LRECLTamanho do registro
FBFixo com bloco
VBVariável com bloco

Conclusão

A blockagem em datasets QSAM é uma técnica usada pelo z/OS para melhorar eficiência e performance no acesso aos dados.

Em vez de gravar registros individualmente, o sistema agrupa vários registros em blocos físicos, reduzindo operações de I/O e acelerando o processamento batch.

Entender blockagem é um passo essencial para dominar:

  • datasets;

  • COBOL;

  • JCL;

  • SORT;

  • arquitetura interna do mainframe IBM Z.