Bellacosa Mainframe e o idcams criando gdgs

☕ Um Café no Bellacosa Mainframe

Jimi Dini Entrou no Catálogo — O Dia em que um GDG Criou uma Geração, Sofreu ABEND e Descobriu que IDCAMS Não É Um Curandeiro de Arquivos

Ou: como deixar de chamar todo arquivo com `G0001V00` de “backup”, entender por que `(+1)` pode virar confusão e descobrir que o verdadeiro rock-and-roll do batch é saber o que ficou no catálogo depois do `RC=12`

Prólogo — a fita cassete que se chamava ontem

Imagine Jimi Dini, uma criatura de camisa de flanela, café frio e paciência limitada para apresentações com setenta slides, entrando na sala de operações às três da manhã. No monitor, um job de fechamento acabou de cair com ABEND. O operador aponta para a tela e decreta:

— Relaxa. O arquivo está no GDG.

Jimi olha para o spool, toma um gole de café e responde:

— “No GDG” quer dizer o quê? Está criado? Catalogado? É a geração ativa? É a de ontem? Está pendurada em deferred roll-in? Ou alguém só viu um G0042V00 no volume e resolveu chamar isso de plano de recuperação?

É aqui que começa a educação sentimental do programador COBOL. GDG não é uma palavra mágica para “backup”; IDCAMS não é uma ambulância que ressuscita dado errado; e o catálogo não é um detalhe administrativo que alguém do storage resolve quando o seu JCL ficou feio. Os três formam uma parte muito importante da segurança operacional do batch.

Vamos desmontar essa história sem misticismo — mas com respeito pelo momento em que um DELETE ... PURGE é digitado no ambiente errado e a sala inteira fica subitamente muito silenciosa.

1. GDG: uma estante, não uma pasta com nome bonito

GDG significa Generation Data Group. É um grupo de datasets relacionados, mantidos em ordem de geração pelo z/OS. Pense numa coleção de edições de jornal: a base é o título da coleção; cada GDS (Generation Data Set) é uma edição física.

Base lógica:

BELLACOSA.FOLHA.RELATORIO

Gerações físicas que o sistema administra:

BELLACOSA.FOLHA.RELATORIO.G0001V00
BELLACOSA.FOLHA.RELATORIO.G0002V00
BELLACOSA.FOLHA.RELATORIO.G0003V00

O sufixo G0003V00 não é um ornamento que você inventa no teclado. Ele é formado pelo sistema: o número da geração e, quando necessário, o número de versão. A grande vantagem aparece quando o programa não precisa conhecer esse nome físico. Ele só pede a edição que precisa.

Referência no JCL	Tradução humana
`(+1)`	“Vou criar a próxima edição.”
`(0)`	“Quero a edição mais recente ativa.”
`(-1)`	“Quero a imediatamente anterior.”
`(-2)`	“Quero a de duas execuções atrás.”
`G0042V00`	“Quero exatamente esta edição física.”

Para um lote diário de extratos, isto é ouro. O job de hoje cria (+1). O processo de conferência lê (0). Uma rotina de comparação lê (-1). O JCL expressa intenção, não uma data carimbada à mão numa convenção de nomes que um dia alguém vai esquecer de atualizar.

Mas atenção: GDG administra gerações, não prova que o conteúdo está certo. Se o COBOL calculou juros usando uma taxa incorreta, você não possui um backup apenas porque o arquivo se chama G0088V00. Você possui uma versão perfeitamente organizada de um erro.

2. IDCAMS: o cartório do condomínio de datasets

IDCAMS, Access Method Services, é a ferramenta que conversa com o catálogo e administra vários objetos de dados. Ele é famoso entre programadores por criar VSAM, mas chamar IDCAMS de “o programa que cria KSDS” é como chamar um cartório de “o lugar onde se reconhece firma”. Verdadeiro, mas dramaticamente incompleto.

Com IDCAMS, podemos, entre outras coisas:

definir e alterar bases GDG;
listar entradas do catálogo;
criar, apagar e alterar clusters VSAM;
copiar ou carregar dados com REPRO;
trabalhar com índices alternativos;
investigar atributos que o JCL sozinho não torna tão visíveis.

O esqueleto clássico é:

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

Guarde uma regra de sobrevivência: se IDCAMS voltar com condição diferente de zero, não pare no RC=8. Abra o SYSPRINT. O retorno é o alarme; as mensagens são o laudo médico. Elas costumam revelar se a base já existe, se uma geração possui retenção, se houve problema de autorização RACF ou se o catálogo localizou algo diferente do que você imaginava.

3. Criando a base: antes de nascer a primeira geração

Definir a base GDG não cria um arquivo de negócio. Cria a regra de vida das futuras gerações no catálogo.

//DEFGDG   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE GENERATIONDATAGROUP -
    (NAME(BELLACOSA.FOLHA.RELATORIO) -
     LIMIT(7) -
     NOEMPTY -
     SCRATCH -
     NOPURGE)
/*

Também é válido escrever DEFINE GDG. Eu, porém, gosto de começar com GENERATIONDATAGROUP: evita que o jovem padawan imagine que está definindo um dataset sequencial. Está definindo a base, a estante e suas regras.

`LIMIT(7)`: quantas edições cabem na estante?

LIMIT determina o número de gerações ativas. Para um job diário, LIMIT(7) pode representar uma semana. Para fechamento mensal, LIMIT(13) costuma cobrir doze meses e o atual. Para uma interface cuja correção pode levar noventa dias, talvez sete seja uma receita para uma conversa desagradável com auditoria.

O limite não deve nascer do folclore — “sempre fizemos 30” —, mas de perguntas concretas: por quantos dias pode ocorrer reprocessamento? Há retenção legal? Quem recupera um arquivo se o parceiro rejeitar a carga depois de duas semanas? Há espaço para isso? Em GDG clássico, o limite pode chegar a 255; um GDG estendido pode suportar até 999, sujeito à política do ambiente.

`NOEMPTY`: retire o mais antigo, não a banda inteira

Com NOEMPTY, quando chega uma nova geração acima do limite, apenas a mais velha sofre roll-off — deixa de fazer parte da base. É o comportamento normal em processamento contínuo.

Com LIMIT(3), ao criar a quarta geração:

antes: G0001, G0002, G0003
depois: G0002, G0003, G0004

EMPTY é outra conversa: quando o limite estoura, todas as gerações existentes saem da base. Há usos específicos para ciclos fechados, mas para relatório diário isso equivale a contratar Jimi Dini para organizar os arquivos e entregar-lhe um lança-chamas. Use NOEMPTY como padrão mental até que alguém explique, por escrito, por que EMPTY é necessário.

`SCRATCH`, `NOSCRATCH`, `PURGE` e `NOPURGE`: o que acontece quando a geração cai da estante?

Quando uma geração sofre roll-off, ela pode simplesmente deixar a base ou também ser removida do armazenamento:

SCRATCH: remove o dataset físico conforme o processamento aplicável;
NOSCRATCH: não o apaga automaticamente; ele pode continuar existindo e, no cenário SMS, ficar recatalogado fora da base como rolled off;
NOPURGE: respeita retenção/data de expiração;
PURGE: pode ultrapassar essa barreira de retenção.

Para operação comum, NOEMPTY, SCRATCH e NOPURGE são uma combinação honesta: remove somente a geração mais velha, libera espaço e não atropela proteção de retenção. Mas ela exige que seu LIMIT seja correto. Se a empresa precisa manter sessenta dias, LIMIT(7) com SCRATCH não é automação; é descarte programado.

4. O COBOL encontra o JCL: quem faz o quê?

O COBOL não deveria carregar a preocupação com o nome absoluto da geração. Ele abre um DDNAME. O JCL decide o dataset. O catálogo resolve a geração. Esta separação é uma das pequenas elegâncias do mainframe.

JCL que cria uma geração:

//GERAEXTR EXEC PGM=PGMEXTR
//STEPLIB  DD DSN=BELLACOSA.LOADLIB,DISP=SHR
//SYSOUT   DD SYSOUT=*
//EXTRATO  DD DSN=BELLACOSA.BATCH.EXTRATO(+1),
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10),RLSE),
//            DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)

No programa:

SELECT ARQ-EXTRATO ASSIGN TO EXTRATO
       ORGANIZATION IS SEQUENTIAL
       FILE STATUS IS WS-FS-EXTRATO.

O programa escreve em EXTRATO. Não precisa saber se virou G0042V00. E isto dá liberdade para a equipe ajustar as regras de infraestrutura sem reescrever lógica de negócio.

Na execução seguinte, o mais novo pode ser lido assim:

//ENTRADA DD DSN=BELLACOSA.BATCH.EXTRATO(0),DISP=SHR

E a comparação com o anterior:

//HOJE    DD DSN=BELLACOSA.BATCH.EXTRATO(0),DISP=SHR
//ONTEM   DD DSN=BELLACOSA.BATCH.EXTRATO(-1),DISP=SHR

Esse é um ponto em que a vida do iniciante melhora: (+1) é para criar; (0) é a geração ativa mais recente; (-1) é a anterior. Não tente tratar (+1) como “o arquivo de hoje para leitura em qualquer etapa paralela”. O momento do catalogamento e o fluxo do job importam.

5. A cena do crime: job caiu ao criar `(+1)`

Agora chegamos à pergunta que separa quem decorou sintaxe de quem começa a entender operação.

O job aloca:

BELLACOSA.BATCH.EXTRATO(+1)

O z/OS reserva o nome físico, o programa começa a escrever e então acontece um ABEND: um S0C7, falta de espaço, falha de I/O, queda de subsistema ou aquela rotina antiga que decide que o valor HIGH-VALUES é uma proposta de carreira.

Pode sobrar uma geração física criada, por exemplo G0042V00, sem que ela tenha sido incluída como geração ativa na base. Esse é um estado conhecido como deferred roll-in. Na prática, o arquivo pode estar no DASD, mas (0) ainda aponta para a geração anterior.

O primeiro impulso de alguém é executar de novo. Às vezes funciona. Às vezes transforma um incidente simples numa investigação arqueológica.

Primeiro, investigue:

//LISTGDG  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  LISTCAT ENT(BELLACOSA.BATCH.EXTRATO) ALL
  LISTCAT LVL(BELLACOSA.BATCH.EXTRATO) ALL
/*

Depois, leia o spool: JESMSGLG, JESJCL, SYSPRINT e os SYSOUTs do programa. Você quer saber: a geração existe? O conteúdo foi fechado corretamente? O job morreu antes ou depois de gravar? A geração deveria sobreviver? Há outro job dependente em execução?

Se a GDS estiver íntegra e for realmente a geração que deve entrar na base, IDCAMS oferece a correção de catálogo:

//ROLLIN   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  ALTER BELLACOSA.BATCH.EXTRATO.G0042V00 ROLLIN
/*

O ROLLIN torna a geração ativa no GDG. É a ferramenta certa para a pergunta certa: “a geração existe e está boa, mas não foi associada à base”. Não a use como ritual automático após todo ABEND. Se o programa morreu depois de gravar metade do arquivo, colocar essa geração no GDG é apenas catalogar oficialmente um problema.

6. Reexecutar, corrigir ou recuperar? Três verbos, três decisões

Jimi Dini escreveria isto na parede da sala de controle: não conserte catálogo antes de decidir se o dado merece ser preservado.

Caso A — o conteúdo está correto, mas a geração não entrou

Valide volume, tamanho, quantidade de registros, totais de controle e sinal de término da aplicação. Se tudo estiver íntegro, ALTER ... ROLLIN pode ser a escolha adequada.

Caso B — o conteúdo está errado

Não “edite” a geração em silêncio para fingir que nada ocorreu. Corrija a causa, gere uma nova (+1) e documente o reprocessamento. A beleza do GDG é justamente preservar a sequência. Uma geração nova, correta e auditável costuma ser muito mais defensável que uma cirurgia clandestina na geração anterior.

Caso C — a geração está incompleta ou descartável

Depois de confirmação operacional, a geração física pode precisar ser excluída e o job reexecutado de maneira controlada. Isto não deve ser decidido pelo programador isolado em produção: há scheduler, dependências, retenção, RACF e possíveis consumidores do arquivo.

O vilão frequente é o segundo job disparado antes que o primeiro tenha sido tratado. Em GDS SMS no DASD, o mecanismo de GDS reclaim pode reutilizar uma geração pendente quando outro job tenta criar o mesmo (+1). Isso pode sobrescrever conteúdo anterior. Portanto, interrompa dependentes, entenda o estado e só então rerode.

7. `ALTER`, `LISTCAT`, `DELETE`: ferramentas, não martelos

LISTCAT é sua lanterna:

LISTCAT ENT(BELLACOSA.BATCH.EXTRATO) ALL

Ele permite enxergar atributos da base, limite e gerações. Use antes de tomar decisão destrutiva.

ALTER ajusta a política:

ALTER BELLACOSA.BATCH.EXTRATO LIMIT(45)

Isso aumenta a capacidade futura de retenção. Não traz de volta dados que já sofreram scratch. Também vale lembrar: reduzir limite pode provocar roll-off das gerações mais antigas. Não trate um ALTER LIMIT como ajuste cosmético.

DELETE faz exatamente o que o nome promete:

DELETE BELLACOSA.BATCH.EXTRATO.G0042V00

apaga uma geração específica; enquanto:

DELETE BELLACOSA.BATCH.EXTRATO GDG

atinge a base GDG. Isso é reconstrução, não manutenção corriqueira. Antes de qualquer DELETE, confirme ambiente, HLQ, entrada de catálogo, volumes e autorização. O personagem que diz “é só um GDG de teste” merece ao menos uma segunda verificação — porque o ambiente de teste costuma ter um nome suspeitosamente parecido com produção numa sexta-feira.

8. `VERIFY` não é varinha mágica

Outro equívoco comum: ouvir que IDCAMS possui VERIFY e concluir que ele corrige qualquer GDG. Não. VERIFY está ligado à verificação de consistência de estruturas VSAM e catálogo em cenários próprios. Ele não confere se a regra de cálculo do seu COBOL estava correta; não repõe registros faltantes num arquivo sequencial; não transforma uma GDS truncada em extrato válido.

Para GDG, pense assim:

Sintoma	Ação inicial correta
Arquivo lógico aponta para a geração errada	`LISTCAT`, avaliar estado e `ROLLIN` se aplicável
Geração não existe	Investigar job, retenção, scratch, backup e catálogo
Dados têm erro de negócio	Corrigir programa/parâmetro e reprocessar para nova geração
Retenção está pequena	`ALTER LIMIT`, com avaliação de espaço e auditoria
Estrutura VSAM está inconsistente	Acionar procedimento VSAM/storage; pode envolver `VERIFY`
Catálogo parece corrompido	Escalar ao storage/system programmer; não recriar base no improviso

O IDCAMS é excelente, mas não substitui diagnóstico. Ele administra registros de catálogo; seu processo operacional decide o que é dado confiável.

9. Passo a passo do jovem padawan antes de mexer num GDG

Quando um job com GDG falhar, siga este roteiro:

Pare o reflexo de rerodar. Veja se existem dependentes e evite duas tentativas criando o mesmo (+1).
Leia o ABEND e o spool. Descubra a causa, não só o código final.
Liste a base. Use LISTCAT ENT(nome-da-base) ALL.
Identifique a geração física. Ela existe? Está ativa, rolled off ou pendente?
Valide o conteúdo. Totais, contagem, trailer, retorno da aplicação, volume e integridade esperada.
Escolha conscientemente. ROLLIN se a geração boa não entrou; novo (+1) se deve reprocessar; descarte controlado se está incompleta.
Registre a decisão. Ticket, evidência de totals e horário da intervenção valem ouro na auditoria.
Libere a cadeia somente após a consistência. O próximo consumidor não deve descobrir o problema por acidente.

10. Curiosidades para contar no café — sem quebrar produção

Uma GDG pode ser muito mais antiga que boa parte do código Java que hoje a consome. E ainda assim ela resolve um problema moderno: versionamento de dados em lote. A diferença é que, no z/OS, esse versionamento está acoplado a catálogo, retenção, JCL, segurança e operação de grandes volumes — não a uma pasta chamada backup_final_agora_vai_3.

Outra curiosidade: o sufixo absoluto existe para quando uma referência precisa ser imutável. Usar (0) é ótimo para “a mais recente”; usar G0042V00 é apropriado quando uma auditoria, reconciliação ou reexecução exige provar que foi aquela geração, e não a que veio depois.

Por fim, GDG não elimina backup, disaster recovery, retenção corporativa ou cópia para fita/cloud. Ele ajuda a manter versões operacionais de datasets. Backup protege contra outra classe de problemas: perda de volume, desastre, corrupção ampla, retenção longa e erros que só foram percebidos quando todas as gerações úteis já saíram da estante.

Epílogo — o som que fica depois do ABEND

No fim da madrugada, Jimi Dini fecha o SYSPRINT, confere o LISTCAT e deixa uma frase para o programador COBOL iniciante:

— O mainframe não é antigo; ele só não confia em improviso.

GDG oferece uma cronologia clara. IDCAMS administra a cronologia no catálogo. JCL declara como cada etapa usa essa cronologia. COBOL processa os registros. Quando algo falha, a resposta madura não é “reroda e vê”. É descobrir o que foi alocado, o que foi catalogado, o que está íntegro e qual ação preserva tanto o negócio quanto a rastreabilidade.

Quando você entende isso, (+1) deixa de ser uma sequência estranha entre parênteses. Ele se torna uma promessa operacional: “esta é a próxima versão do dado; trate-a com o respeito que ela terá quando alguém precisar explicar seu conteúdo daqui a três meses.

Translate

quarta-feira, 21 de abril de 2021