 |
| Bellacosa Mainframe trabalhando com jcl datasets o parametro disp |
☕ O Holocron do DISP: O Pequeno Parâmetro de JCL que Decide o Destino de Bilhões de Registros no IBM Z
"Todo Padawan COBOL aprende SHR, OLD, NEW e MOD na primeira semana. O problema é que a maioria só descobre o verdadeiro significado dessas quatro letras depois do primeiro incidente em produção às 02h17 da madrugada."
Há algo fascinante no universo IBM Z.
As coisas mais poderosas quase sempre parecem pequenas.
Um simples DD Statement.
Um DSN.
Um SPACE.
Um UNIT.
E escondido entre vírgulas aparentemente inocentes, encontramos um dos maiores guardiões do processamento batch corporativo:
DISP=(...)
Para muitos desenvolvedores iniciantes, DISP é apenas uma exigência burocrática do JCL.
Para um analista de produção experiente, um administrador de armazenamento, um Sysprog z/OS ou um veterano de operações, DISP é outra coisa completamente diferente.
DISP é um contrato.
Um acordo silencioso entre a aplicação, o Allocation Manager do z/OS, o Catalog Manager, o SMS, o RACF, o JES2, o DFSMS e, em alguns casos, o próprio destino profissional do programador que escreveu o JCL.
O Primeiro Ensinamento do Holocron
O formato completo parece simples.
DISP=(status,normal,abnormal)
Mas nele estão escondidas três decisões críticas.
Primeira decisão:
Como acessar o dataset?
Segunda decisão:
O que fazer quando tudo der certo?
Terceira decisão:
O que fazer quando tudo der errado?
E no mundo corporativo, convenhamos, a terceira pergunta costuma ser muito mais importante.
DISP não é um parâmetro. É governança.
Quando um Job chega ao JES2, ele inicia uma pequena jornada.
Converter.
Interpreter.
Allocation.
SMS.
Catalog.
Open.
Execution.
E é justamente durante a fase de Allocation que DISP deixa de ser texto e passa a ser política operacional.
O sistema precisa responder perguntas difíceis:
O dataset existe?
Está catalogado?
O usuário possui permissão RACF?
Existe alguém usando esse arquivo?
Posso criar outro?
Preciso esperar?
Posso deletar em caso de ABEND?
O programador enxerga:
DISP=OLD
O z/OS enxerga:
"Preciso obter um ENQ exclusivo sobre esse recurso, validar segurança, localizar volumes, conversar com SMS e garantir que ninguém mais toque nesse arquivo."
DISP=SHR — A Grande Ilusão do Compartilhamento
Todo curso ensina:
SHR significa compartilhado.
Correto.
Mas incompleto.
SHR significa:
Shared Allocation
Não significa:
Shared Update
Não significa:
Ausência de Lock
Não significa:
Concorrência segura
Imagine uma biblioteca pública.
Todos podem ler o mesmo livro.
Mas ninguém pode arrancar páginas enquanto outra pessoa está lendo.
É exatamente assim que funciona.
Em datasets sequenciais tradicionais, SHR costuma conviver bem.
Já em VSAM, RLS, Image Copies do DB2, GDGs ou arquivos manipulados por utilitários específicos, a história muda bastante.
O programador júnior pensa:
"SHR deixa todo mundo acessar."
O Sysprog pensa:
"Qual será o modo do ENQ?"
Porque internamente existe algo parecido com:
QNAME=SYSDSN
RNAME=CLIENTE.MASTER
MODE=SHR
E isso faz toda a diferença.
DISP=OLD — O Parâmetro Mais Injustiçado do Mainframe
Existe um mito muito antigo.
OLD significa atualização.
Não.
OLD significa:
Alocação Exclusiva.
Ponto.
Você pode abrir um dataset com DISP=OLD apenas para leitura.
Pode fazer backup.
Pode reorganizar.
Pode executar IDCAMS.
Pode executar IEBCOPY.
Pode fazer SORT.
Pode executar DFSORT.
Pode simplesmente garantir que ninguém mexa naquele arquivo durante sua execução.
Na prática, OLD é o equivalente ao programador veterano dizendo:
"Esse arquivo é meu por enquanto. Todos os outros aguardem."
E é justamente aí que começam algumas das histórias mais curiosas das centrais de produção.
Quem nunca viu:
IEC161I
ou
WAITING FOR DATASET
durante quatro horas seguidas?
Normalmente existe um DISP=OLD escondido em algum lugar.
DISP=NEW — O Nascimento de um Dataset
NEW é quase poético.
Ele representa criação.
Nascimento.
Um novo objeto no universo z/OS.
Mas NEW possui exigências.
Não basta desejar.
É necessário informar:
SPACE.
DCB.
UNIT.
Ou confiar no SMS.
Exemplo clássico:
DISP=(NEW,CATLG,DELETE)
SPACE=(CYL,(10,5))
DCB=(RECFM=FB,LRECL=80)
Exemplo moderno:
DATACLAS=FB80
STORCLAS=FAST
MGMTCLAS=PROD
Hoje o SMS resolve muito do trabalho.
Mas o princípio permanece.
NEW espera algo importante:
O dataset não deve existir.
Caso contrário:
IEC141I
aparece para lembrar que o universo IBM Z não gosta de duplicidades.
DISP=MOD — O Diário que Nunca Termina
Minha analogia favorita continua sendo a do diário.
Imagine um caderno.
Você não rasga páginas antigas.
Você apenas continua escrevendo.
É isso que MOD faz.
Posiciona no EOF.
Acrescenta registros.
Mantém histórico.
Parece inofensivo.
Até descobrirmos um arquivo de auditoria criado em 2009.
Hoje com 780 GB.
Com backup demorando três horas.
E restore demorando mais quatro.
Tudo porque alguém escreveu:
DISP=MOD
e nunca mais voltou para revisar.
O Poder Oculto do Segundo e Terceiro Parâmetros
É aqui que mora a verdadeira maturidade técnica.
Considere:
DISP=(NEW,CATLG,DELETE)
Sucesso?
Cataloga.
ABEND?
Delete.
Elegante.
Limpo.
Seguro.
Agora observe:
DISP=(NEW,PASS,DELETE)
Esse é um dos favoritos dos veteranos.
O arquivo passa de STEP em STEP.
Nunca é catalogado.
Nunca polui o catálogo corporativo.
No final do Job desaparece.
Quase zen.
Outro clássico pouco lembrado:
DISP=(OLD,KEEP,KEEP)
Nada muda.
Tudo permanece.
Independentemente do resultado.
O Sysprog Não Lê DISP. Ele Faz Perguntas.
Ao olhar um DD Statement, um Sysprog experiente não pensa em SHR ou OLD.
Ele pensa:
Haverá contenção?
Existe risco de SB37?
O SMS conseguirá alocar?
O RACF permitirá acesso?
O restart será possível?
O GDG crescerá indefinidamente?
O backup continuará viável?
O catálogo ficará consistente?
Um Job crítico ficará esperando às 02h17 da manhã?
Porque muitos incidentes de produção começam exatamente assim:
DISP=(...)
E terminam com uma reunião às 09h00 envolvendo operações, infraestrutura, armazenamento, segurança e o desenvolvedor que jurava ter apenas "copiado um JCL antigo".
O Último Conselho ao Padawan COBOL
Aprender SHR, OLD, NEW e MOD é fácil.
Entender ENQ.
Catalog Management.
SMS.
RACF.
GDG.
VSAM.
Restart.
Contenção.
Boas práticas operacionais.
Isso leva anos.
O verdadeiro profissional de IBM Z não escreve apenas programas.
Ele administra recursos compartilhados de uma plataforma responsável por processar cartões de crédito, aposentadorias, seguros, bolsas de valores, transações bancárias e sistemas governamentais de países inteiros.
E talvez seja justamente essa a grande beleza do Mainframe.
No IBM Z, até uma pequena linha de JCL pode carregar responsabilidades suficientes para sustentar bilhões de registros, milhares de empresas e décadas de história computacional.
E tudo isso começa com uma única palavra.
DISP.
Este é o tipo de conhecimento que transforma um simples usuário de JCL em alguém capaz de compreender os mecanismos invisíveis que mantêm o coração batch do IBM Z pulsando silenciosamente há mais de meio século.
