Bellacosa Mainframe apresenta o idcams para o vsam

☕ Um Café no Bellacosa Mainframe

Melvin Udall Entra no IDCAMS — O Homem que Não Aceitava Arquivo Fora de Ordem, Índice Sem `BLDINDEX` nem `RC=8` Sem Explicação

Ou: como o VSAM deixou de ser “aquele arquivo do COBOL” e revelou uma cidade inteira de CIs, CAs, catálogos, índices alternativos, backups, reorganizações e pequenos desastres esperando alguém escrever `DELETE ... PURGE` no dataset errado

Há pessoas que olham para um arquivo VSAM e dizem: “é só um arquivo”.

Melvin Udall, o escritor rabugento de Melhor Impossível, olharia para essa frase, ajustaria as luvas, evitaria encostar no terminal compartilhado e responderia algo como:

“Não. ‘Só um arquivo’ é o que você diz cinco minutos antes de apagar a produção.”

E, desta vez, Melvin estaria certo.

Para o programador COBOL iniciante, VSAM parece inicialmente uma sigla misteriosa usada por veteranos quando querem tornar uma reunião mais silenciosa. Você vê algo assim no programa:

SELECT ARQ-CLIENTE
    ASSIGN TO VSAM-CLIENTE
    ORGANIZATION IS INDEXED
    ACCESS MODE IS DYNAMIC
    RECORD KEY IS CLI-CPF.

E pensa: “Pronto. Tenho um arquivo indexado. O COBOL abre, lê, grava e fecha.”

Sim. Mas isso é como ver a porta de um banco e concluir que compreendeu tesouraria, segurança, auditoria, cofre, sistema antifraude, ar-condicionado do datacenter e o senhor que aparece às três da manhã perguntando por que o batch não fechou.

O programa COBOL usa o VSAM. Mas alguém precisou criar esse VSAM. Alguém precisa verificar se o arquivo existe, descobrir sua chave, conferir o espaço disponível, copiar seus registros, refazer índices, investigar mensagens estranhas e reorganizá-lo quando ele envelhece mal.

Esse alguém — ao menos na maior parte dos ambientes z/OS — conversa com o IDCAMS.

E, se Melvin Udall fosse o responsável pelo VSAM, ele não permitiria uma única chave fora de posição, um único índice alternativo esquecido ou um único RC=8 sendo tratado com a clássica frase corporativa: “mas o job terminou”.

Prólogo — O arquivo que não era apenas um arquivo

VSAM significa Virtual Storage Access Method. É uma tecnologia criada pela IBM para organizar e acessar dados no ambiente de mainframe com eficiência, previsibilidade e capacidade de sobreviver ao tipo de volume que faz uma planilha do Excel pedir aposentadoria.

Sua origem está na evolução dos sistemas IBM da família OS/VS. Antes do VSAM, havia modelos de arquivos mais separados e especializados, como sequenciais tradicionais e ISAM. Cada qual tinha seu estilo, suas limitações e seu conjunto de utilitários.

O VSAM trouxe uma visão mais integrada.

Em vez de tratar o armazenamento como uma sequência de registros soltos, ele introduziu uma organização formada por:

Estruturas lógicas;
Componentes de dados;
Componentes de índice;
Catálogos;
Unidades internas de leitura e gravação;
Controle de espaço;
Possibilidade de acesso direto por chave;
Estruturas alternativas de busca.

O VSAM não nasceu para ser “bonito” no sentido moderno da palavra. Ele nasceu para ser confiável, eficiente e administrável em ambientes nos quais perder ou duplicar uma transação não era um bug simpático: era um problema bancário, fiscal, logístico ou governamental.

E aqui começa a primeira lição Melvin Udall para o jovem padawan COBOL:

“Você pode não querer entender como o arquivo foi criado. O arquivo não tem a mesma obrigação em relação a você.”

1. IDCAMS: o administrador do condomínio VSAM

IDCAMS significa Integrated Data Cluster Access Method Services.

Pense nele como o administrador rigoroso do condomínio VSAM. Ele não processa a folha de pagamento nem calcula juros. Ele prepara o prédio onde esses dados irão morar, consulta as plantas, verifica rachaduras, copia apartamentos, troca placas, recria portarias e avisa quando alguém tentou estacionar um caminhão dentro da sala.

O IDCAMS é executado em JCL:

//IDCAMS   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  comandos IDCAMS
/*

Cada DD tem seu papel:

DD	Função
`EXEC PGM=IDCAMS`	Executa o utilitário IDCAMS
`SYSPRINT`	Recebe relatórios, mensagens e diagnósticos
`SYSIN`	Recebe os comandos que você quer executar
DDs adicionais	Podem indicar arquivos de entrada, saída, backup ou carga

O SYSIN é onde vivem comandos como:

DEFINE
DELETE
LISTCAT
REPRO
PRINT
VERIFY
EXAMINE
EXPORT
IMPORT
BLDINDEX
ALTER
SET

Um conselho de sobrevivência: nunca trate SYSPRINT como decoração. É ali que o IDCAMS explica o que fez, o que não fez e por que decidiu que seu plano era uma má ideia.

O RC do job indica a gravidade geral. As mensagens explicam a causa.

Melvin colocaria isso em uma moldura:

“Código de retorno não é diagnóstico. É apenas a campainha tocando.”

2. Os quatro moradores principais: KSDS, ESDS, RRDS e LDS

Antes de criar um arquivo, você precisa saber que tipo de VSAM faz sentido.

Tipo	Como organiza	Uso típico
KSDS	Por chave	Clientes, contas, produtos, contratos
ESDS	Ordem de inclusão	Logs, eventos, trilhas de auditoria
RRDS	Número relativo de registro	Tabelas com posições fixas
LDS	Sequência bruta de bytes	Produtos especializados e estruturas próprias

O rei do cotidiano COBOL é o KSDS — Key Sequenced Data Set.

Nele, os registros são organizados pela chave. Se CPF é a chave, o VSAM sabe encontrar o cliente sem precisar ler todos os demais.

Exemplo de dados:

CPF          NOME
01234567890  ANA SILVA
12345678901  BRUNO COSTA
98765432100  CARLA MENDES

O KSDS mantém uma estrutura de índice que permite localizar o registro pela chave.

No COBOL, isso aparece em operações como:

MOVE WS-CPF-PROCURADO TO CLI-CPF
READ ARQ-CLIENTE
    KEY IS CLI-CPF
    INVALID KEY
        DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ

Mas a magia não acontece porque o COBOL “leu rápido”. Ela acontece porque o VSAM foi corretamente definido, carregado e mantido.

3. Cluster, DATA e INDEX: a casa, os móveis e o mapa

O principal objeto VSAM é o cluster.

No caso de um KSDS, há normalmente dois componentes físicos importantes:

DATA component: onde os registros estão;
INDEX component: onde estão chaves e ponteiros para localizar os registros.

A aplicação geralmente acessa o nome do cluster:

BELLACOSA.COBOL.CLIENTES.KSDS

Mas, internamente, podem existir:

BELLACOSA.COBOL.CLIENTES.KSDS.DATA
BELLACOSA.COBOL.CLIENTES.KSDS.INDEX

Imagine uma biblioteca.

O DATA é a sala onde estão os livros.

O INDEX é o catálogo que diz em qual corredor e estante o livro está.

Se o índice tem problema, o livro pode continuar fisicamente ali, mas encontrá-lo fica muito mais difícil. Se você tem uma chave definida incorretamente, é como organizar livros pelo terceiro caractere do sobrenome do autor e fingir que aquilo faz sentido.

Melvin Udall chamaria isso de “uma arquitetura concebida por alguém que odeia leitores”.

4. Criando um KSDS com `DEFINE CLUSTER`

Vamos criar um cadastro de clientes cuja chave é um CPF de 11 bytes a partir da posição zero do registro.

//CRIAKSDS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE CLUSTER -
    (NAME(BELLACOSA.COBOL.CLIENTES.KSDS) -
     INDEXED -
     KEYS(11 0) -
     RECORDSIZE(150 300) -
     CYLINDERS(5 2) -
     FREESPACE(20 10) -
     SHAREOPTIONS(2 3) -
     CONTROLINTERVALSIZE(4096)) -
    DATA -
    (NAME(BELLACOSA.COBOL.CLIENTES.KSDS.DATA)) -
    INDEX -
    (NAME(BELLACOSA.COBOL.CLIENTES.KSDS.INDEX))
/*

Agora vamos fazer aquilo que evita incidentes: entender o que foi escrito.

Parâmetro	O que ele faz
`NAME`	Define o nome lógico do cluster
`INDEXED`	Indica que é um KSDS
`KEYS(11 0)`	Chave de 11 bytes iniciando na posição zero
`RECORDSIZE(150 300)`	Tamanho mínimo e máximo de registro
`CYLINDERS(5 2)`	Espaço primário e secundário em cilindros
`FREESPACE(20 10)`	Reserva espaço para futuras inclusões
`SHAREOPTIONS(2 3)`	Define comportamento de compartilhamento
`CONTROLINTERVALSIZE(4096)`	Tamanho de cada Control Interval
`DATA`	Nome explícito do componente de dados
`INDEX`	Nome explícito do componente de índice

O parâmetro mais traiçoeiro é:

KEYS(11 0)

Ele significa:

A chave tem 11 bytes;
Ela começa no deslocamento zero.

Se no seu layout COBOL o CPF começa no byte 20, a definição deveria ser algo semelhante a:

KEYS(11 20)

Eis um exemplo de layout:

01  REG-CLIENTE.
    05 CLI-CODIGO          PIC 9(08).
    05 CLI-DT-CADASTRO     PIC 9(08).
    05 CLI-CPF             PIC 9(11).
    05 CLI-NOME            PIC X(60).
    05 CLI-EMAIL           PIC X(60).

Nesse caso, o CPF não começa no byte zero. Você precisa calcular a posição real com precisão. Não é chute, não é sensação, não é “acho que começa ali perto”.

Em mainframe, “quase certo” é apenas uma forma educada de dizer “errado”.

5. CI e CA: onde o VSAM realmente acomoda os registros

Dois conceitos assustam muita gente no início:

CI — Control Interval;
CA — Control Area.

Vamos simplificar sem mentir.

Um CI é como uma página organizada onde o VSAM coloca vários registros. É uma unidade de I/O: quando o VSAM lê ou grava, ele trabalha em torno dessas unidades.

Um CA é um conjunto de CIs.

Assim:

Cluster
  └── Control Area
        ├── Control Interval
        │     ├── Registro 1
        │     ├── Registro 2
        │     └── Espaço livre
        ├── Control Interval
        └── Control Interval

Quando você insere um registro em um KSDS, ele precisa caber em algum CI na posição correta da chave.

Se não há espaço suficiente, o VSAM pode realizar um CI Split. Se a situação envolve uma estrutura maior, pode ocorrer um CA Split.

Isso não significa automaticamente corrupção ou desastre. É o VSAM reorganizando espaço para continuar atendendo inclusões.

Mas muitos splits podem criar fragmentação e aumentar o custo de I/O.

É por isso que existe:

FREESPACE(20 10)

A ideia é reservar espaço para que futuras inserções entre chaves existentes tenham onde ficar.

O primeiro número representa espaço livre dentro dos CIs;
O segundo define uma reserva de CIs livres em cada CA.

Se seu arquivo é carregado uma vez, raramente recebe inclusões e é muito lido, exagerar no FREESPACE desperdiça espaço.

Se ele recebe inserções constantes, principalmente em posições intermediárias da chave, um FREESPACE pequeno pode transformar seu KSDS em uma cidade que cresceu sem plano diretor.

Melvin provavelmente teria uma opinião sobre bairros construídos sem planejamento.

6. `REPRO`: a mudança de casa dos registros

REPRO é o subcomando usado para copiar dados.

Para fazer uma carga inicial de um arquivo sequencial para um KSDS:

//CARGA    EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//ENTRADA  DD DSN=BELLACOSA.COBOL.CLIENTES.SEQ,
//            DISP=SHR
//SYSIN    DD *
  REPRO -
    INFILE(ENTRADA) -
    OUTDATASET(BELLACOSA.COBOL.CLIENTES.KSDS)
/*

Atenção: a carga inicial de KSDS deve respeitar a ordem da chave.

Se os registros chegam assim:

98765432100
01234567890
12345678901

o VSAM não ficará encantado. Em uma carga convencional, a ordem esperada é crescente:

01234567890
12345678901
98765432100

O REPRO também pode copiar de VSAM para VSAM:

REPRO -
  INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) -
  OUTDATASET(BELLACOSA.COBOL.CLIENTES.NOVO.KSDS)

Ou descarregar um VSAM para sequencial:

REPRO -
  INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) -
  OUTFILE(SAIDA)

É um comando essencial para carga, backup lógico de registros, migração e reorganização.

7. `LISTCAT`: o raio-X de quem não acredita em boatos

Quando alguém diz “acho que esse arquivo é KSDS”, não responda “acho que sim”.

Use LISTCAT.

//LISTA    EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  LISTCAT -
    ENT(BELLACOSA.COBOL.CLIENTES.KSDS) -
    ALL
/*

A saída pode revelar:

Tipo do VSAM;
Nome de cluster;
Componentes DATA e INDEX;
Tamanho de CI;
Chave e posição;
Espaço primário e secundário;
Espaço usado;
Volumes;
Datas de criação e referência;
Parâmetros de compartilhamento;
Relações com AIX e PATH.

Para listar um grupo:

LISTCAT LEVEL(BELLACOSA.COBOL) ALL

É uma ferramenta excelente para ambientes de teste abandonados por gerações anteriores. Você começa procurando um KSDS e descobre seis versões, três índices alternativos, um PATH sem dono e um dataset chamado TESTE.FINAL.DEFINITIVO.NOVO2.

A arqueologia do mainframe é real.

8. `PRINT`: quando olhar o dado é melhor do que imaginar o dado

PRINT permite visualizar conteúdo do dataset.

//PRINT    EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  PRINT -
    INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) -
    CHARACTER
/*

Também pode usar:

PRINT INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) HEX
PRINT INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) DUMP

Cada formato tem seu momento:

CHARACTER ajuda quando há texto;
HEX ajuda quando há campos binários, COMP, COMP-3 ou caracteres estranhos;
DUMP é mais técnico e detalhado.

Um registro pode parecer correto em tela, mas possuir bytes inesperados. Um campo COMP-3 gravado com layout errado pode deixar o dado aparentemente normal em parte do processo e explodir em um S0C7 na etapa seguinte.

O hex não mente. Ele apenas não se esforça para ser simpático.

9. `DELETE`: a palavra que Melvin não deixaria você digitar sem backup

Excluir um cluster inteiro é simples:

//APAGA    EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DELETE BELLACOSA.COBOL.CLIENTES.KSDS CLUSTER
/*

Se há condições especiais, pode aparecer:

DELETE BELLACOSA.COBOL.CLIENTES.KSDS CLUSTER PURGE

PURGE é um parâmetro que exige cuidado. Não é um tempero para fazer o comando “funcionar melhor”. É uma autorização mais agressiva para remover o objeto sob certas condições.

Antes de executar qualquer exclusão, faça o ritual que Melvin transformaria em lei:

Confira o HLQ;
Confirme ambiente de teste, homologação ou produção;
Faça LISTCAT;
Verifique AIX e PATH associados;
Garanta backup;
Leia o JCL como se ele tivesse sido escrito por seu inimigo;
Só então submeta.

Um DELETE errado pode terminar em segundos. A explicação ao gerente, ao auditor e ao time de recuperação costuma durar muito mais.

10. Backup lógico: `EXPORT`, `IMPORT` e a diferença entre guardar dados e preservar uma estrutura

Há duas ideias que muitos iniciantes misturam:

Copiar os registros;
Preservar uma imagem lógica do VSAM.

Com REPRO, você normalmente copia dados. É ótimo para descarregar e recarregar registros.

Com EXPORT, você cria uma exportação lógica que pode ser restaurada por IMPORT.

Exemplo de exportação:

//EXPORT   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//BACKUP   DD DSN=BELLACOSA.BACKUP.CLIENTES.EXPORT,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=FB,LRECL=4096,BLKSIZE=0)
//SYSIN    DD *
  EXPORT BELLACOSA.COBOL.CLIENTES.KSDS -
         OUTFILE(BACKUP) -
         TEMPORARY
/*

E a restauração:

//IMPORT   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//BACKUP   DD DSN=BELLACOSA.BACKUP.CLIENTES.EXPORT,
//            DISP=SHR
//SYSIN    DD *
  IMPORT -
    INFILE(BACKUP) -
    OUTDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) -
    NEW
/*

Em produção, empresas podem usar DFSMShsm, FDR, CA Disk, ferramentas de backup corporativo, storage replication e procedimentos de disaster recovery. O IDCAMS não substitui automaticamente toda essa arquitetura.

Mas ele é importantíssimo para backup lógico, migração, laboratório e recuperação controlada.

A verdade impopular é:

Backup não testado é um arquivo de ficção científica.

Se ninguém executou um IMPORT em ambiente seguro, ninguém sabe com certeza se aquele backup salvará o dia.

11. Alternate Index: encontrar um cliente sem usar a chave principal

Suponha que seu KSDS usa CPF como chave primária. Isso é ótimo quando o usuário tem o CPF.

Mas e se o negócio pede pesquisa por agência, cidade, código do produto ou e-mail?

Você poderia criar outro arquivo inteiro. Mas isso aumenta duplicação, manutenção e risco de inconsistência.

A solução VSAM é o AIX — Alternate Index.

O AIX cria uma segunda porta de busca para o mesmo cluster base.

Primeiro, define-se o índice alternativo:

//DEFAIX   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE ALTERNATEINDEX -
    (NAME(BELLACOSA.COBOL.CLIENTES.AIXAG) -
     RELATE(BELLACOSA.COBOL.CLIENTES.KSDS) -
     KEYS(4 80) -
     NONUNIQUEKEY -
     UPGRADE -
     RECORDSIZE(30 30) -
     CYLINDERS(2 1)) -
    DATA -
    (NAME(BELLACOSA.COBOL.CLIENTES.AIXAG.DATA)) -
    INDEX -
    (NAME(BELLACOSA.COBOL.CLIENTES.AIXAG.INDEX))
/*

Aqui, a chave alternativa tem quatro bytes e começa na posição 80 do registro base.

Depois, constrói-se o conteúdo:

//BLDAIX   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  BLDINDEX -
    INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) -
    OUTDATASET(BELLACOSA.COBOL.CLIENTES.AIXAG)
/*

Finalmente, criamos o PATH:

//CRPATH   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE PATH -
    (NAME(BELLACOSA.COBOL.CLIENTES.PATHAG) -
     PATHENTRY(BELLACOSA.COBOL.CLIENTES.AIXAG))
/*

O programa passa a acessar o PATH, que conduz ao AIX e, finalmente, ao registro no cluster base.

`UNIQUEKEY` ou `NONUNIQUEKEY`?

Se o campo é CPF, talvez seja único:

UNIQUEKEY

Se é agência, cidade, sobrenome ou situação do cliente, vários registros podem compartilhar o valor:

NONUNIQUEKEY

E não esqueça o parâmetro mais importante em muitos cenários:

UPGRADE

Com UPGRADE, o VSAM atualiza o AIX quando o cluster base é alterado. Sem isso, seu índice alternativo pode envelhecer em silêncio.

Ele continuará existindo. Ele poderá até continuar retornando resultados. Mas poderá contar uma história que já não corresponde à realidade.

Melvin Udall chamaria isso de “uma relação de trabalho completamente normal”.

12. `VERIFY`: quando uma queda deixa o VSAM desconfiado de si mesmo

Quando um job sofre abend, uma região cai ou há encerramento anormal, um VSAM pode precisar de verificação para alinhar certos controles internos.

O comando típico é:

//VERIFY   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  VERIFY DATASET(BELLACOSA.COBOL.CLIENTES.KSDS)
/*

Dependendo do cenário:

VERIFY DATASET(BELLACOSA.COBOL.CLIENTES.KSDS) RECOVER

O VERIFY pode ajudar com informações de fim lógico e condições relacionadas a encerramento impróprio. Mas ele não é um super-herói de capa azul capaz de recuperar tudo.

Ele não substitui:

Diagnóstico;
Backup;
Recuperação corporativa;
Análise de mensagens;
Reparo de aplicação que escreveu dados errados.

Use VERIFY porque há evidência de que ele se aplica, não porque o job apresentou uma mensagem assustadora e alguém sugeriu “rodar um verify para ver se melhora”.

13. `EXAMINE`: o CSI dentro do Control Interval

Se VERIFY é uma checagem focada em consistência de término, EXAMINE é o investigador forense.

//EXAMINE  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  EXAMINE NAME(BELLACOSA.COBOL.CLIENTES.KSDS) -
          INDEXTEST -
          DATATEST
/*

Em termos simples:

INDEXTEST verifica aspectos do componente de índice;
DATATEST verifica aspectos do componente de dados;
A análise pode revelar inconsistências estruturais, problemas internos e situações que exigem recuperação ou reconstrução.

Quando ouvir “o arquivo está corrompido”, não transforme isso em verdade antes de investigar.

Pode haver:

Falha de I/O;
Problema de catálogo;
Cluster aberto indevidamente;
Compartilhamento mal definido;
AIX desatualizado;
Registro gravado com layout incompatível;
Programa que fez REWRITE de forma incorreta;
Erro de chave;
Erro de concorrência;
Falha após abend;
Estrutura realmente danificada.

A frase “VSAM corrompeu” é frequentemente o equivalente técnico de “alguém mexeu aí”.

E Melvin Udall não aceitaria “alguém” como nome de responsável.

14. Reorganização: o famoso REORG que não é um botão mágico

Você escreveu “rerog”, provavelmente referindo-se a REORG — reorganização.

No VSAM, geralmente não há um único comando universal chamado simplesmente REORG, como existe em outros contextos, por exemplo no Db2. A reorganização de um VSAM costuma ser construída por etapas.

O processo clássico é:

1. Descarregar os dados com REPRO
2. Excluir ou renomear o cluster antigo
3. Criar novamente o cluster com DEFINE
4. Recarregar dados ordenados com REPRO
5. Reconstruir AIX com BLDINDEX
6. Validar e liberar o arquivo

Primeiro, descarregamos:

//UNLOAD   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//OUTSEQ   DD DSN=BELLACOSA.TEMP.CLIENTES.UNLOAD,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=FB,LRECL=300,BLKSIZE=0)
//SYSIN    DD *
  REPRO -
    INDATASET(BELLACOSA.COBOL.CLIENTES.KSDS) -
    OUTFILE(OUTSEQ)
/*

Depois recriamos:

//REDEFINE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DELETE BELLACOSA.COBOL.CLIENTES.KSDS CLUSTER

  DEFINE CLUSTER -
    (NAME(BELLACOSA.COBOL.CLIENTES.KSDS) -
     INDEXED -
     KEYS(11 0) -
     RECORDSIZE(150 300) -
     CYLINDERS(10 5) -
     FREESPACE(20 10)) -
    DATA -
    (NAME(BELLACOSA.COBOL.CLIENTES.KSDS.DATA)) -
    INDEX -
    (NAME(BELLACOSA.COBOL.CLIENTES.KSDS.INDEX))
/*

Por fim, carregamos novamente:

//RELOAD   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INSEQ    DD DSN=BELLACOSA.TEMP.CLIENTES.UNLOAD,
//            DISP=SHR
//SYSIN    DD *
  REPRO -
    INFILE(INSEQ) -
    OUTDATASET(BELLACOSA.COBOL.CLIENTES.KSDS)
/*

Se existir AIX, execute BLDINDEX novamente.

Quando uma reorganização faz sentido?

Muitos CI Splits;
Muitos CA Splits;
Degradação perceptível no acesso;
Espaço livre mal dimensionado;
Crescimento histórico desorganizado;
Alteração estrutural planejada;
Migração entre ambientes;
Limpeza de estrutura após processo de recuperação.

Mas reorganizar não é penitência semanal. Se o sistema sempre volta a fragmentar rapidamente, investigue o padrão de inserção, tamanho do CI, chave, espaço livre, volume, concorrência e lógica de carga.

Não adianta trocar o tapete se a máquina continua derramando óleo.

15. `ALTER`, `SET` e os pequenos comandos que salvam jobs repetíveis

O ALTER permite modificar alguns atributos catalogados, como renomear objetos em contextos permitidos.

Exemplo conceitual:

ALTER BELLACOSA.COBOL.CLIENTES.KSDS -
      NEWNAME(BELLACOSA.COBOL.CLIENTES.KSDS.OLD)

Mas não tente usar ALTER para transformar qualquer atributo estrutural que você decidiu mudar numa terça-feira. Chave, posição da chave e aspectos fundamentais da organização normalmente exigem recriação controlada.

IDCAMS também permite alguma lógica de controle com IF, THEN, ELSE, DO, END e SET.

Por exemplo, em um ambiente de testes, você pode desejar apagar um arquivo e considerar aceitável que ele já não exista:

DELETE BELLACOSA.COBOL.CLIENTES.KSDS CLUSTER
IF LASTCC = 8 THEN -
   SET MAXCC = 0

Isso não significa “ignore todos os erros”. Significa tratar conscientemente uma condição esperada.

Leia os retornos com maturidade:

RC	Interpretação inicial
0	Operação concluída
4	Aviso ou condição menor
8	Erro relevante; leia as mensagens
12	Erro sério
16	Falha grave

A maior armadilha do iniciante é olhar somente o MAXCC.

Um RC=0 pode significar que o IDCAMS executou perfeitamente uma instrução que você escreveu errada para o objetivo de negócio.

Um RC=8 pode ser esperado em um DELETE de um dataset inexistente em teste.

O mainframe não premia quem decora números. Ele premia quem lê contexto.

16. Curiosidades escondidas no catálogo

Curiosidade número um: o VSAM não se orienta apenas pelo nome digitado no JCL. Ele depende do catálogo para saber o que aquele nome representa, onde está e quais são seus atributos.

Curiosidade número dois: um KSDS não é “um arquivo ordenado” no sentido ingênuo. É uma estrutura que mantém registros, chaves, índices, intervalos e regras de expansão.

Curiosidade número três: o AIX não precisa carregar uma cópia completa do registro base. Ele funciona como uma rota alternativa de acesso.

Curiosidade número quatro: muitos problemas atribuídos ao COBOL aparecem, na verdade, na fronteira entre definição IDCAMS, layout do registro, política de acesso e operação.

Curiosidade número cinco: a chave do VSAM não é necessariamente a chave de negócio mais “bonita”. Ela é uma decisão arquitetural. CPF pode funcionar para busca individual; data de movimento pode servir para lote; uma chave composta pode representar agência + conta + dígito. O importante é entender o padrão de acesso que o sistema precisa atender.

17. O mapa mental definitivo do jovem programador COBOL

Quando você olha um VSAM, pense nesta sequência:

COBOL
  ↓
DDNAME / JCL
  ↓
Cluster VSAM
  ├── DATA
  ├── INDEX
  ├── CI
  └── CA
  ↓
Catálogo
  ↓
Disco / Storage

Se houver pesquisa alternativa:

Aplicação
  ↓
PATH
  ↓
Alternate Index
  ↓
Cluster Base
  ↓
Registro

E se houver incidente:

Mensagens no joblog
  ↓
SYSPRINT do IDCAMS
  ↓
LISTCAT
  ↓
VERIFY ou EXAMINE, se aplicável
  ↓
Backup / REPRO / EXPORT / recuperação

Esse mapa evita a visão limitada de que “VSAM é uma cláusula no SELECT”.

Não é.

VSAM é uma estrutura de dados, uma decisão de armazenamento, um conjunto de controles operacionais e, muitas vezes, uma cápsula do tempo contendo décadas de regras de negócio.

Epílogo — Melvin Udall fecha o job

No fim do dia, Melvin Udall não ficaria impressionado porque você soube escrever:

DEFINE CLUSTER

Ele perguntaria:

Você sabe onde começa sua chave?
Conferiu RECORDSIZE contra o copybook?
Sua carga está ordenada?
Sabe se existe AIX?
Reconstruiu o índice após a reorganização?
Leu o SYSPRINT?
Testou o backup?
Sabe o que fará se o arquivo estiver aberto pelo CICS?
Tem certeza absoluta de que esse DELETE aponta para teste?

E, se você respondesse “acho que sim”, ele provavelmente encerraria a conversa.

Porque em VSAM, como em produção, “acho” é uma palavra perigosa.

A boa notícia é que ninguém precisa nascer sabendo CI, CA, AIX, PATH, REPRO, VERIFY e EXAMINE. Você aprende uma camada por vez. Primeiro cria. Depois carrega. Depois consulta. Depois copia. Depois investiga. Depois entende por que os veteranos ficam muito quietos quando alguém menciona PURGE.

O jovem programador COBOL evolui quando deixa de apenas abrir e fechar arquivos.

Ele evolui quando percebe que, atrás de cada READ, existe uma cidade inteira trabalhando para que o registro correto apareça no instante correto.

E, nesse dia, até Melvin Udall talvez permita um café ao seu lado.

Talvez.

Translate

quarta-feira, 13 de abril de 2022