☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

domingo, 23 de outubro de 2022

Pastel, Algodão-Doce e Giovanna — Pequenas Máquinas do Tempo

 


☕ Um Café no Bellacosa Mainframe

Pastel, Algodão-Doce e Giovanna — Pequenas Máquinas do Tempo

Ou: como uma feira paulista, uma estação de trem, uma velha máquina de algodão-doce e os olhos azuis de uma jovem de 1999 continuaram executando um programa dentro da memória quase trinta anos depois

START GIOVANNA1999


Alguns programas nunca foram feitos para terminar.

Há momentos em que os milhões de chimpanzés que habitam minha cabeça fazem silêncio.

É raro.

Normalmente existe uma chuva permanente de ideias, pensamentos, lembranças, absurdos, projetos e associações aparentemente impossíveis. Um chimpanzé pensa em mainframe, outro em história, outro em alguma viagem realizada décadas atrás, enquanto um quarto provavelmente tenta descobrir por que determinada palavra japonesa parece portuguesa.

Mas existem pequenos gatilhos capazes de interromper tudo.

Não importa quanto tempo tenha passado.

Não importa onde eu esteja.

O gatilho acontece e o CPD para.

Um deles é o pastel.

Sim.

Pastel.



Aquela pequena massa frita que talvez algum historiador do futuro considere simples demais para merecer registro, mas que qualquer paulista criado entre feiras livres sabe que pertence a uma categoria muito mais elevada da existência.

Pastel não é apenas comida.

Pastel é memória.

E, no meu caso, pastel também é Giovanna.



O sacramento dominical do paulista

Para compreender essa história, talvez seja necessário explicar às gerações futuras o que significava uma feira livre paulista.

Imagino algum leitor em 2126 consultando este texto enquanto um robô doméstico sintetiza sua refeição molecularmente perfeita e perguntando:

— Mas por que alguém sairia de casa para comprar legumes numa rua?

Porque era muito melhor assim, meu caro descendente.

A feira tinha sons.

Cheiros.

Gente gritando preços.

Crianças.

Senhoras discutindo a qualidade do tomate.

Sacolas.

Caixas.

Frutas cortadas para degustação.

E, em algum ponto estratégico daquele pequeno caos urbano, estava a barraca de pastel.

Ao lado dela, quase obrigatoriamente, caldo de cana.

Ou garapa.

Cada região adotava sua palavra.

O pastel chegava quente demais para ser comido imediatamente, embora invariavelmente tentássemos.

A primeira mordida quebrava a casquinha crocante e libertava uma pequena nuvem de vapor capaz de queimar o céu da boca de qualquer pessoa impaciente.

Dentro poderia haver carne.

Queijo.

Palmito.

Pizza.

Frango.

Ou dezenas de outras invenções.

Mas havia ainda um ingrediente secreto que jamais aparecia na placa:

o óleo.

Não qualquer óleo.

O óleo ancestral da feira.

Depois de fritar uma quantidade arqueológica de pastéis, aquele óleo parecia possuir memória própria.

O pastel de queijo carregava talvez uma lembrança distante do pastel de carne.

A carne poderia ter conhecido o palmito.

O palmito certamente havia cruzado com algum pastel de pizza.

Era quase uma rede neural gastronômica treinada durante milhares de frituras.

E aquilo era delicioso.



O velho japonês que a história transformou em “chinês”

Existe ainda uma história humana por trás das barracas de pastel paulistas.

São Paulo recebeu uma enorme imigração japonesa ao longo do século XX. Essas famílias chegaram, trabalharam, criaram filhos, atravessaram preconceitos, guerras, transformações econômicas e adaptações culturais.

Em determinado período de nossa história, especialmente sob o peso do preconceito antijaponês relacionado à Segunda Guerra Mundial, identidades precisaram ser escondidas, adaptadas ou reinterpretadas.

No imaginário popular paulista surgiu então aquela figura que muitas crianças da minha geração conheceram simplesmente como:

“o chinês da feira”.

Muitas vezes era japonês.

Ou descendente de japoneses.

A história real é muito mais complexa que essa pequena frase, naturalmente. Envolve imigração, racismo, sobrevivência, assimilação e empreendedorismo.

Mas décadas depois algo extraordinário havia acontecido.

O pastel tinha deixado de parecer japonês, chinês ou estrangeiro.

Tornara-se simplesmente paulista.

Talvez essa seja uma das coisas mais bonitas da cultura.

Ela mistura pessoas, histórias, ingredientes e circunstâncias até que ninguém consiga mais separar completamente as origens.

O resultado vira tradição.



1991 — Pastel, Márcia e Freddie Mercury

Minha história pessoal com pastel também possui algumas pequenas ramificações.

Em 1991, ano em que Freddie Mercury morreu, houve Márcia.

Márcia era filha de uma pasteleira.

Tivemos um breve relacionamento.



É curioso como o cérebro cataloga acontecimentos. Alguém poderia imaginar que uma relação com a filha de uma mulher que fazia pastéis seria suficiente para criar a grande associação gastronômica da minha vida.

Não foi.

O cérebro decidiu outra coisa.

Passaram-se alguns anos.

Outra cidade entrou no mapa.

Outro tempo.

Outra jovem.

E então o índice foi criado definitivamente.

https://eljefemidnightlunch.blogspot.com/2021/11/marcia-pastel-freddie-mercury-o.html



Amparo SP

Chegamos a Amparo, interior de São Paulo.

Cidade marcada pelo ciclo do café e por uma arquitetura que ainda guarda fragmentos daquela época em que fortunas atravessavam o interior paulista junto com trilhos, fazendas e estações ferroviárias.

Ali existia uma pastelaria próxima à antiga estação.

Sua própria existência carregava história.

Originalmente aquele tipo de estabelecimento atendia viajantes que chegavam ou partiam pelos trens. Pessoas desciam carregando malas, notícias, saudades, negócios e expectativas.

Comiam alguma coisa.

Tomavam alguma bebida.

Esperavam.

Depois seguiam viagem.

Quando a ferrovia perdeu importância e os trens desapareceram daquela rotina, estabelecimentos como aquele deveriam, segundo a lógica econômica, desaparecer também.

Mas alguns sobrevivem.

Mudam de dono.

Mudam detalhes.

Perdem parte da história.

Ganham outras histórias.

E continuam funcionando.

São pequenos fósseis comerciais vivos.


Em 1999, aquela pastelaria ainda vendia pastéis.

E eu estava lá.

Mas não estava sozinho.



Giovanna

Giovanna tinha lindos olhos azuis.

Quanto ao cabelo, existe uma divergência histórica que provavelmente jamais será resolvida.

Para mim, castanho-claro.

Para ela, loiro-escuro.

Considerando que este é meu registro para a posteridade, deixarei documentadas ambas as versões para que futuros arqueólogos não iniciem uma guerra acadêmica sobre o assunto.

Era 1999.

Éramos jovens.

E havia Amparo para zanzar.

Gosto da palavra zanzar porque ela descreve perfeitamente aquilo.

Não estávamos realizando uma missão.

Não havia roteiro turístico.

Não havia aplicativo indicando os dez lugares obrigatórios para fotografar.

Não precisávamos registrar cada minuto para provar aos outros que tínhamos estado ali.

Nós simplesmente andávamos.

Sentávamos num banco de praça.

Conversávamos.

Explorávamos alguma construção antiga dos tempos áureos do café.

Entrávamos numa loja de R$ 1,99.

Comíamos alguma coisa.

Voltávamos a andar.

Hoje parece extraordinariamente simples.

Talvez fosse justamente isso que tornasse aquilo extraordinário.


A pastelaria da estação

Em algum momento dessas tardes havia pastel.

Não sei se naquele instante pensei:

“Preciso memorizar isto porque daqui a quase trinta anos ainda vou lembrar.”

Certamente não.

Ninguém vive assim.

Grandes acontecimentos normalmente anunciam sua importância.

Casamentos possuem cerimônias.

Formaturas possuem fotografias.

Viagens possuem passagens.

Nascimentos possuem documentos.

Mas ninguém entrega um certificado dizendo:

ATENÇÃO: esta tarde aparentemente banal será importante para você em 27 anos. Favor prestar atenção.

A vida simplesmente acontece.

Comemos o pastel.

Conversamos.

Talvez tenhamos rido de alguma bobagem cujo conteúdo desapareceu completamente da minha memória.

E seguimos andando.

O problema — ou talvez a maravilha — é que meu cérebro executou silenciosamente:

COMMIT;

A transação foi gravada.

Pastel passou a apontar para Giovanna.

E nunca mais consegui desfazer essa associação.


O índice secreto da memória

Se nossa memória funcionasse como um banco de dados organizado, talvez existisse algo parecido com:

GIOVANNA → AMPARO → 1999

Mas memória humana é uma péssima DBA.

Ela cria índices sem consultar ninguém.

No meu caso, aparentemente fez:

PASTEL → GIOVANNA

AMPARO → GIOVANNA

PRAÇA → GIOVANNA

LOJA DE 1,99 → GIOVANNA

E ainda faltava um dos mais poderosos.

ALGODÃO-DOCE → GIOVANNA


A máquina impossível de algodão-doce

Amparo possuía outra pequena maravilha.

Uma velha máquina de algodão-doce.

Na minha lembrança, era uma máquina antiquíssima, do começo do século XX, mantida funcionando graças ao empenho de alguém que se recusava a permitir que aquele artefato simplesmente desaparecesse.

Talvez algum pesquisador futuro consiga determinar sua fabricação, modelo e história com maior precisão.

Para mim, naquele momento, importava outra coisa:

ela ainda funcionava.

Aquilo era maravilhoso.

Uma máquina criada em outro tempo continuava executando perfeitamente sua função.

Açúcar entrava.

O mecanismo girava.

E surgia uma nuvem doce.

Como alguém que passou boa parte da vida trabalhando com mainframes, reconheço hoje uma filosofia familiar:

— Isso ainda está funcionando?

— Sim.

— Há quanto tempo?

— Ninguém sabe exatamente.

— Não deveríamos substituir?

— Não toque.

Há coisas que sobrevivem simplesmente porque alguém continuou cuidando delas.

E aquela máquina continuava produzindo algodão-doce para novas gerações.


Açúcar transformado em nuvem

Algodão-doce é uma invenção maravilhosa justamente porque é quase completamente absurda.

Pegamos açúcar.

Transformamos em fios.

Enrolamos numa vareta.

E produzimos uma nuvem comestível.

Não existe praticamente nenhuma justificativa adulta para aquilo.

Não é sofisticado.

Não demonstra status.

Não é uma experiência gastronômica complexa.

Não precisamos discutir terroir.

Não há harmonização.

É açúcar.

É infância.

É diversão.

É inútil.

E talvez por isso seja tão importante.

Em algum momento de 1999, Giovanna e eu também comemos algodão-doce.

O segundo índice foi criado.

Décadas depois, ainda funciona.


START GIOVANNA1999

Hoje posso estar vivendo um dia completamente diferente.

Outro século.

Outra rotina.

Outros problemas.

Outras pessoas.

Outro eu.

Então aparece um pastel.

Mordo.

A casquinha quebra.

Sinto o recheio quente.

O cheiro chega.

E algum chimpanzé responsável pelo arquivo morto da minha memória abandona sua mesa, corre por um corredor empoeirado do CPD cerebral e grita:

— CHEFE! ENCONTREI UMA COISA!

Antes que minha parte racional compreenda o que aconteceu, o JOB já foi submetido:

START GIOVANNA1999

E estou novamente em Amparo.

Não fisicamente.

Mas suficientemente perto.

Vejo a praça.

A estação.

As construções.

Uma loja de R$ 1,99.

Pastéis.

Algodão-doce.

Olhos azuis.

E aquele cabelo castanho-claro que, caso Giovanna algum dia leia isto, certamente continuará alegando ser loiro-escuro.

Alguns bugs não precisam ser corrigidos.


A felicidade que não sabia que era felicidade

Com o passar dos anos comecei a perceber algo.

As lembranças mais persistentes nem sempre pertencem aos acontecimentos que, na época, pareciam mais importantes.

Viajei.

Conheci lugares extraordinários.

Vi monumentos.

Atravessei países.

Vivi acontecimentos históricos.

Trabalhei com tecnologias gigantescas.

Conheci muita gente.

Entretanto, algumas memórias que atravessaram décadas são absurdamente pequenas.

Um gosto.

Uma rua.

Uma conversa.

Um banco de praça.

Um alimento simples.

Talvez exista uma explicação.

Há momentos que lembramos porque alguma coisa extraordinária aconteceu.

Mas existem outros que lembramos porque, sem perceber naquele instante, estávamos extraordinariamente felizes fazendo coisas absolutamente ordinárias.

Esses são perigosos.

Não precisam de fotografias.

Não precisam de aniversários.

Não precisam sequer que pensemos conscientemente neles.

Ficam esperando.

Até que algum cheiro, música, palavra ou sabor encontre a chave.


A garapa de Luxor e o pastel de Amparo

Anos depois eu sentiria algo semelhante muito longe dali.

No Egito, em Luxor, antiga Tebas, encontrei caldo de cana.

Garapa.

Em meio a uma viagem cercada por milhares de anos de história, templos, faraós e monumentos capazes de atravessar civilizações, uma coisa aparentemente banal conseguiu me atingir profundamente:

caldo de cana.

Porque sabor não respeita geografia.

Também não respeita calendário.

Uma bebida simples podia aproximar o Egito do Brasil durante alguns segundos.

Assim como um pastel comprado décadas depois pode aproximar 2026 de 1999.

Talvez comida seja uma das máquinas do tempo mais eficientes inventadas pela humanidade.


Não era sobre o pastel

Naturalmente, nunca foi realmente sobre pastel.

Também não era sobre algodão-doce.

Nem sobre a loja de R$ 1,99.

Nem sequer apenas sobre Giovanna.

Era sobre aquele conjunto específico de circunstâncias que jamais poderá ser reproduzido exatamente.

Aquela idade.

Aquela cidade.

Aquele momento histórico.

Aquela companhia.

A ausência de pressa.

A possibilidade de simplesmente caminhar sem destino.

O futuro ainda não havia acontecido.

Muitas decisões ainda não tinham sido tomadas.

Muitas pessoas ainda não tinham chegado.

Outras ainda não tinham partido.

Nós não sabíamos disso.

Estávamos apenas vivendo uma tarde.


Para quem estiver lendo isto no futuro

Talvez você seja um descendente.

Talvez seja alguém que encontrou este texto perdido pela internet.

Talvez nem saiba quem foram aquelas pessoas.

Isso pouco importa.

Quero lhe deixar algo muito mais importante do que os nomes.

Quando estiver vivendo um momento simples, não o despreze por ser simples.

Coma o pastel.

Compre o algodão-doce.

Sente no banco.

Entre naquela lojinha aparentemente inútil.

Caminhe sem destino.

Converse.

Observe os prédios.

Ria da bobagem.

Não transforme necessariamente tudo em fotografia.

Não tente fazer cada segundo parecer extraordinário.

Apenas esteja lá.

Porque você não sabe quais desses momentos seu cérebro escolherá guardar.

Daqui a vinte, quarenta ou sessenta anos talvez você não consiga lembrar o assunto daquela conversa.

Talvez esqueça a roupa.

Talvez o estabelecimento desapareça.

A estação poderá virar museu.

A loja poderá ser demolida.

A velha máquina finalmente poderá parar.

Até as pessoas poderão seguir caminhos completamente diferentes.

Mas então, numa tarde qualquer, alguém colocará um pastel diante de você.

Você dará a primeira mordida.

E alguma coisa acontecerá.

O presente ficará silencioso.

Uma porta será aberta.

E por alguns segundos você terá novamente vinte e tantos anos.

Estará numa praça.

Ao seu lado haverá alguém que o tempo levou para outro caminho.

Você poderá quase ouvir sua voz.

Talvez até veja aqueles olhos.

Então compreenderá uma coisa que eu demorei muitos anos para aprender:

a vida não é formada apenas pelos grandes acontecimentos que contamos aos outros.

Boa parte dela está escondida nas pequenas coisas que aparentemente não mereciam ser guardadas.

Mas foram.

Meu pastel guardou uma cidade.

Meu algodão-doce guardou uma época.

Uma velha máquina guardou uma tarde.

E Giovanna acabou guardada em todos eles.

Talvez a memória seja justamente isso.

Um gigantesco CPD administrado por milhões de chimpanzés, cheio de arquivos sem documentação, programas que ninguém ousa apagar e índices criados sem qualquer lógica aparente.

De vez em quando um deles encontra uma fita esquecida.

Coloca para rodar.

O CPD inteiro fica em silêncio.

E nós chamamos aquilo de saudade.


Epílogo — O último pastel

Algum dia comerei meu último pastel.

Naturalmente não saberei que é o último.

Provavelmente reclamarei que tem pouco recheio.

Talvez esteja quente demais.

Talvez o óleo esteja naquele glorioso estágio arqueológico em que já possui conhecimento acumulado de quinze mil pastéis anteriores.

Vou morder.

A casquinha fará crack.

O vapor subirá.

E espero que, onde quer que meus milhões de chimpanzés estejam naquele momento, algum deles ainda conheça o comando.

START GIOVANNA1999

Então, por alguns segundos, pouco importará quantas décadas tenham passado.

Haverá novamente uma estação.

Uma pastelaria.

Uma praça.

Uma loja de R$ 1,99.

Uma máquina centenária transformando açúcar em nuvem.

Uma jovem de olhos azuis.

Um sujeito olhando para o cabelo dela e insistindo que aquilo era castanho-claro.

E uma tarde qualquer de 1999 que ninguém presente sabia ser histórica.

Não foi histórica para o Brasil.

Não mudou São Paulo.

Não apareceu nos jornais.

Não modificou o destino de Amparo.

Mas ficou registrada em algum lugar muito menor e, paradoxalmente, muito mais resistente.

Minha memória.

Se você estiver lendo isto muitas décadas depois de mim, talvez aquela pastelaria não exista mais.

Talvez aquela máquina esteja finalmente num museu.

Talvez ninguém mais saiba quem foi Giovanna.

Agora você sabe.

Ela foi uma jovem de olhos azuis que, durante algumas tardes de 1999, zanzou comigo por Amparo.

E isso bastou para que, décadas depois, um simples pastel ainda fosse capaz de parar o CPD.

Não subestime as pequenas felicidades.

Algumas delas executam para sempre.

sexta-feira, 21 de outubro de 2022

A Terra dos Badges — Quando Dilbert Entrou no IBM Z, Dogbert Criou um Dashboard e Catbert Descobriu que um S0C7 Não Liga para Seu LinkedIn

 

Bellacosa Mainframe e a terra dos badges

☕ Um Café no Bellacosa Mainframe

A Terra dos Badges — Quando Dilbert Entrou no IBM Z, Dogbert Criou um Dashboard e Catbert Descobriu que um S0C7 Não Liga para Seu LinkedIn

Ou: por que aprender mainframe de verdade ainda exige mais do que clicar em “Complete Course”, ganhar uma medalha digital e posar ao lado de um Easy Button

Imagine a seguinte cena.

Você é um programador COBOL iniciante. Acabou de descobrir que existe uma máquina chamada IBM Z capaz de processar transações de banco, cartões, seguros, governos, companhias aéreas e boa parte das coisas que fazem o mundo não virar uma feira livre toda segunda-feira às oito da manhã.

Você está animado.

Abre o portal de aprendizado. Há uma trilha. Depois outra trilha. Depois um badge. Depois uma comunidade. Depois um webinar. Depois uma campanha. Depois uma proposta de publicar um post usando um kit de redes sociais. Depois um convite para chamar outro colega. E, antes de ter submetido seu primeiro JCL com erro de sintaxe, aparece uma medalha digital dizendo que você está “engajado”.

Nesse momento, Dilbert pergunta:

— “Então agora eu sei COBOL?”

Dogbert, vestido de consultor estratégico, responde:

— “Não. Mas seu nível de advocacy subiu 14%, e isso cabe maravilhosamente no gráfico trimestral.”

Catbert, o malvado diretor de RH, entra carregando uma prancheta:

— “Excelente. Vamos chamá-lo de Mainframe Evangelist Associate Bronze. Não precisa entender DISP=(NEW,CATLG,DELETE) agora. Isso fica para a próxima jornada.”

E é exatamente aqui que mora uma discussão importante sobre IBM Z, LinuxONE, badges, comunidades, treinamento e a diferença entre parecer que você está aprendendo e realmente conseguir trabalhar quando o lote bancário resolve explodir às 2h17 da madrugada.

O assunto não é “mainframe é ruim”, “IBM não presta” ou “badge não serve para nada”. Isso seria tão infantil quanto dizer que COBOL é ultrapassado porque seu editor tem menos emojis do que o celular. O assunto é mais sério:

como formar gente capaz de operar, evoluir e defender uma plataforma crítica sem transformar a jornada inteira em um parque de diversões corporativo de medalhas, slogans e dashboards?

Vamos abrir o SYSOUT, chamar Igor para buscar café e entender essa história sem atirar no escuro.



1. IBM Z não vendeu apenas computadores: vendeu uma civilização

Para entender o problema, o jovem padawan COBOL precisa primeiro respeitar o tamanho da coisa.

Durante muitas décadas, comprar um mainframe IBM não significava apenas instalar uma máquina no datacenter. Significava entrar em uma civilização técnica inteira. Você comprava ou contratava uma combinação de:

  • hardware;

  • z/OS;

  • JES2;

  • TSO/ISPF;

  • RACF;

  • CICS;

  • IMS;

  • Db2;

  • MQ;

  • VSAM;

  • COBOL, PL/I, Assembler, REXX e JCL;

  • storage;

  • rede;

  • backup;

  • recuperação de desastre;

  • suporte;

  • treinamento;

  • consultoria;

  • processos;

  • documentação;

  • certificações;

  • e siglas em quantidade suficiente para fazer um dicionário parecer um panfleto de pizzaria.

Isso não aconteceu por maldade. Um banco não pode processar milhões de transações, manter saldo consistente, impedir fraude, recuperar uma região CICS, proteger dados pessoais e fechar o dia financeiro usando a filosofia “vamos subir em produção e ver no que dá”.

No IBM Z, a complexidade muitas vezes é uma defesa contra o caos.

Quando você trabalha com transações, integridade, auditoria, criptografia, disponibilidade e compatibilidade de décadas, simplicidade absoluta não existe. A pergunta correta não é “por que é tão complexo?”, mas:

qual parte dessa complexidade protege o negócio, e qual parte só protege uma burocracia que aprendeu a se reproduzir?

Esta é a divisão central do artigo que motivou nossa conversa.

Complexidade que gera valorComplexidade que só atrapalha
COMMIT e ROLLBACK coerentesPedir acesso por e-mail para descobrir um tutorial
RACF protegendo recursosDepender de um “dono da planilha”
WLM priorizando workloadsDocumentação fragmentada em cinco portais
JCL controlando execução batchProcesso opaco para testar software
Db2 preservando integridadeBadge usada como substituto de experiência
CICS coordenando transaçõesCaminho de entrada cheio de rituais vazios

O problema nunca foi exigir que alguém aprenda o que está fazendo antes de alterar o sistema que paga aposentadorias ou liquida cartões. O problema é confundir segurança com inacessibilidade.



2. O Undo: uma pequena tecla que mudou a filosofia da computação

Parece estranho começar uma conversa sobre mainframe falando de Undo, mas a metáfora é excelente.

Nos primeiros tempos da computação, a máquina mandava e o humano obedecia. Se você fazia algo errado, o sistema dizia, em termos técnicos:

“Parabéns. Agora conviva com as consequências.”

O Undo trouxe outra ideia: pessoas erram. Pessoas experimentam. Pessoas aprendem destruindo coisas pequenas antes de serem autorizadas a mexer em coisas grandes.

Essa é uma mudança civilizatória no design de sistemas.

Um bom ambiente de aprendizado não elimina consequências; ele reduz o preço do erro. Você pode montar um JCL errado, receber JCL ERROR, abrir o SDSF, ler a mensagem, corrigir e tentar novamente. Ninguém perdeu dinheiro, nenhum cliente ficou sem cartão, e você aprendeu algo que não esquecerá.

É por isso que laboratório vale mais do que slogan.

Um curso pode explicar:

ADD WS-VALOR TO WS-TOTAL

Mas só um exercício real ensina que:

  • o campo pode ter tamanho inadequado;

  • o valor pode chegar inválido;

  • o arquivo pode não abrir;

  • o FILE STATUS pode trazer uma surpresa;

  • o job pode nem chegar a executar;

  • e o problema talvez esteja no JCL, não no COBOL.

Dogbert chamaria isso de “experiência de aprendizagem baseada em atrito produtivo”. Nós chamamos de “tomar uma paulada educativa do SYSOUT”.



3. Badge é certificado de passagem, não diploma de sobrevivência

Vamos falar com justiça: badges não são inúteis.

Para quem está começando, uma badge pode ajudar a:

  • descobrir um tema;

  • manter disciplina;

  • organizar o estudo;

  • demonstrar interesse inicial;

  • obter visibilidade;

  • abrir conversa com recrutador, professor, gestor ou mentor;

  • provar que concluiu uma trilha específica.

Você próprio pode ter uma coleção saudável de cursos e credenciais e, ainda assim, continuar estudando. Isso não é contradição. É maturidade.

A falha aparece quando a empresa faz esta conta errada:

Badge obtida=profissional pronto\text{Badge obtida} = \text{profissional pronto}

Não é.

A conta mais honesta é:

Badge obtida=evideˆncia de que uma atividade definida foi concluıˊda\text{Badge obtida} = \text{evidência de que uma atividade definida foi concluída}

Pode ser uma boa evidência. Pode ser o primeiro degrau. Mas ainda não responde perguntas fundamentais:

  • a pessoa consegue ler um programa COBOL desconhecido?

  • sabe diferenciar erro de compilação de erro de execução?

  • consegue localizar um S0C7?

  • sabe o que fazer diante de um SQLCODE -805?

  • entende a diferença entre CANCEL COBOL e CANCEL CICS?

  • sabe por que um COMMIT feito no momento errado pode estragar uma unidade de trabalho?

  • sabe investigar se o problema está no programa, no Db2, no dataset, na região CICS, no JCL ou na parametrização?

Se a resposta for “não”, não há vergonha alguma. Todo mundo começa em algum ponto. O problema é entregar ao iniciante um crachá dourado e fingir que ele saiu da academia pronto para comandar a nave.



4. Dilbert, Dogbert e Catbert montam um programa de advocacy

Easter egg corporativo: quando “ouvir as pessoas” vira mais um processo, uma métrica e um formulário — enquanto a impressora continua quebrada no fundo da sala. Inspirado em Dilbert

Vamos montar uma empresa fictícia: a MegaZ Corporation.

Dilbert recebe a missão de fortalecer o ecossistema técnico. Ele propõe:

— “Vamos criar ambientes de prática, documentação clara, pipelines de CI, testes repetíveis e acesso para estudantes.”

Dogbert olha a proposta e diz:

— “Isso é caro, lento e difícil de colocar num slide.”

Então ele lança o plano alternativo:

  1. criar um portal colorido;

  2. dividir o aprendizado em pequenas jornadas;

  3. dar pontos por assistir vídeos;

  4. entregar badges;

  5. premiar quem fizer posts;

  6. contar publicações como “atos de advocacy”;

  7. mostrar crescimento de engajamento;

  8. marcar uma reunião para celebrar a reunião que discutiu o engajamento.

Catbert acrescenta:

— “E vamos exigir experiência de marketing para o cargo que deveria expandir uma plataforma técnica. Conhecer IBM Z será desejável, mas opcional.”

Parece piada, mas aponta para um risco real: medir divulgação com mais rigor do que medir competência, acesso e contribuição técnica.

Existe advocacy bom. Você, leitor, pode escrever um artigo ensinando um novato a entender JCL, explicar por que COBOL não é um fóssil, traduzir um ABEND para linguagem humana ou mostrar uma carreira possível. Isso tem valor.

Mas advocacy se torna teatro quando o participante apenas replica uma narrativa pronta para ganhar um ponto.

Advocacy técnico de verdadeAdvocacy de dashboard
Publica laboratório reproduzívelRepublica arte pronta
Explica um erro e a correçãoUsa uma frase promocional
Mostra fonte, JCL e logMostra badge e slogan
Ajuda alguém a destravarGera uma métrica de campanha
Revela limites do produtoSó divulga vitórias

O teste é simples: alguém consegue fazer algo útil com aquilo?

Se não consegue reproduzir, testar, instalar, entender ou investigar, talvez o conteúdo tenha sido marketing vestido de capacete.


5. “Funciona uma vez” não é sinônimo de suporte

Este ponto é ouro para qualquer programador COBOL iniciante.

Imagine que você escreveu um programa, compilou, executou e viu no terminal:

PROCESSAMENTO REALIZADO COM SUCESSO

Ótimo. Mas isso não prova que o programa está pronto para produção.

Talvez você tenha testado apenas:

  • um CPF válido;

  • um arquivo existente;

  • uma conta com saldo;

  • uma data normal;

  • nenhum erro de I/O;

  • nenhum SQLCODE negativo;

  • nenhum volume de dados;

  • nenhuma concorrência;

  • nenhum reinício após falha.

Em ambiente profissional, “funcionou uma vez” é o começo da investigação, não o fim.

Com software para IBM Z e LinuxONE ocorre a mesma coisa. Um pacote pode:

  • compilar uma vez em s390x;

  • aparecer em uma demonstração;

  • ter uma imagem de marketing;

  • ser citado num anúncio de parceria;

…sem possuir suporte sustentável.

Suporte sustentável significa:

  • build repetível;

  • dependências versionadas;

  • testes automatizados;

  • integração contínua;

  • documentação de instalação;

  • evidência de desempenho;

  • responsável pelo produto;

  • processo de correção;

  • caminho claro para escalar incidentes;

  • manutenção quando a próxima versão quebrar alguma coisa.

A diferença é enorme:

Frase de marketingPergunta do profissional
“Roda em IBM Z”Em qual versão, com quais limites e suporte?
“Compatível com s390x”Há CI contínuo para garantir isso?
“Demonstrado em LinuxONE”A instalação é reproduzível?
“Integrado ao ecossistema”Quem corrige quando quebra?
“Parceria anunciada”Existe compromisso técnico contínuo?

Um pacote abandonado não fica mantido porque três pessoas receberam badge. Um bug de compilador não se corrige com um webinar. Um iniciante sem ambiente de testes não aprende porque recebeu um post pronto para publicar.


6. A métrica que falta: quantos viraram mainframers de verdade?

Empresas adoram métricas de funil:

  • inscritos;

  • visualizações;

  • cursos iniciados;

  • cursos concluídos;

  • membros em comunidades;

  • badges emitidas;

  • posts publicados;

  • webinars realizados;

  • atos de advocacy.

Essas métricas não são mentiras. Elas só são incompletas.

Elas contam atividade próxima do botão. Clicar em “inscrever-se” gera um registro. Terminar um curso gera outro. Publicar um post gera outro. Tudo tem data, hora e gráfico.

Mas a pergunta difícil é esta:

quantos desses alunos se tornaram profissionais que trabalham, permanecem e evoluem no ecossistema?

A trajetória real é bem mais longa:

Curiosidade
   ↓
Curso
   ↓
Laboratório prático
   ↓
Acesso a ambiente realista
   ↓
Primeiro projeto ou estágio
   ↓
Capacidade de diagnosticar e entregar
   ↓
Responsabilidade em produção
   ↓
Carreira sustentável
   ↓
Transferência de conhecimento

É chato medir isso porque leva anos, envolve empregadores diferentes e não cabe em uma apresentação trimestral. Mas é exatamente isso que importa para resolver a alegada escassez de profissionais.

O jovem padawan não deve desprezar uma badge. Deve apenas fazer a pergunta certa:

— “Depois da badge, qual problema real eu consigo resolver?”

Se você não consegue responder, seu próximo passo não é colecionar mais cinco. É procurar prática.


7. O plano de estudo que Dogbert não colocaria no dashboard

Se você está começando em COBOL e mainframe, faça o contrário da colecionação compulsiva de credenciais. Use cursos como mapa, não como destino.

Passo 1 — Aprenda o mínimo de COBOL que permite ler um programa

Comece por:

  • divisões;

  • WORKING-STORAGE;

  • PIC;

  • MOVE;

  • IF;

  • PERFORM;

  • READ;

  • WRITE;

  • DISPLAY;

  • FILE STATUS;

  • COMP-3;

  • nível 88.

Seu objetivo inicial não é criar um sistema bancário. É olhar um programa e dizer: “sei onde entra, onde lê, onde calcula, onde grava e onde pode quebrar”.

Passo 2 — Entenda JCL antes de tentar ser herói

JCL não é um detalhe externo. É a instrução que coloca seu programa na estrada.

Aprenda a identificar:

  • JOB;

  • EXEC;

  • DD;

  • DSN;

  • DISP;

  • SPACE;

  • DCB;

  • SYSOUT;

  • STEPLIB;

  • SYSIN;

  • SYSOUT;

  • retorno RC;

  • JCL ERROR.

Quando algo falhar, não chute. Abra o SDSF e leia a sequência de mensagens. O log é o narrador da tragédia; ignore-o e você será apenas o ator que entrou no palco errado.

Passo 3 — Faça pequenos erros de propósito

Crie um programa simples e teste:

  • arquivo inexistente;

  • chave duplicada;

  • campo numérico com dado inválido;

  • divisão por zero;

  • condição de fim de arquivo;

  • retorno SQL negativo;

  • dataset sem espaço;

  • JCL com DD incorreto.

O objetivo é aprender o que o sistema diz quando algo quebra.

Passo 4 — Use as badges como trilha, não como troféu

Ao terminar uma credencial, pergunte:

  1. O que eu consigo explicar sem consultar o curso?

  2. O que consigo fazer num laboratório?

  3. Que erro eu sei reconhecer agora?

  4. Que conceito consigo ensinar a outra pessoa?

  5. Onde esta habilidade apareceria num incidente real?

Se você não consegue responder, revise. Não corra para a próxima medalha.


8. Curiosidade escondida: o mainframe já praticava várias ideias modernas

Existe uma ironia divertida nessa história.

Muita gente imagina que o mundo moderno inventou tudo: isolamento, automação, observabilidade, controle de carga, segurança centralizada, continuidade e governança.

O IBM Z olha para isso e diz:

— “Interessante. Em que ano vocês descobriram?”

WLM organiza prioridades. RACF centraliza proteção. CICS coordena transações. Db2 mantém integridade. JES2 gerencia batch. Sysplex trabalha disponibilidade e escala. Ferramentas de automação e monitoramento há décadas lidam com coisas que hoje reaparecem em slides de cloud como grandes revelações.

O problema do IBM Z não é falta de engenharia moderna. Muitas vezes, é a dificuldade de permitir que novas pessoas encontrem essa engenharia sem precisar atravessar uma floresta de portais, permissões, contratos e cerimônias.

A máquina não precisa ficar banal para ficar mais acessível.


Epílogo — Catbert emite o badge, mas o S0C7 emite a verdade

No final da reunião, Dogbert apresenta o dashboard:

  • 10 mil novos inscritos;

  • 2 mil badges;

  • 400 posts;

  • 800 atos de advocacy;

  • gráfico verde;

  • seta para cima;

  • aplausos.

Catbert anuncia uma nova credencial: “Certified Frictionless Ecosystem Explorer — Platinum”.

Então, do canto da sala, chega uma mensagem:

ABEND=S0C7
PROGRAM=FATUR001
STEP=PGM001

Silêncio.

O S0C7 não sabe quantos seguidores você tem. O -805 não respeita seu banner de LinkedIn. O IEC141I não se impressiona com sua coleção de medalhas. A região CICS não volta porque alguém escreveu “I’m proud to be an advocate”.

Ela volta porque alguém entende o problema, lê a evidência, faz a pergunta certa, testa a correção e sabe o impacto de cada decisão.

Badges podem abrir a porta. Cursos podem iluminar o corredor. Comunidades podem oferecer companhia na caminhada. Marketing pode chamar gente nova para dentro.

Mas, para atravessar a sala de máquinas, ainda será preciso aprender a ler o painel.

E talvez essa seja a lição mais saudável para o programador COBOL iniciante: não despreze a trilha, não despreze a credencial e não despreze a comunidade. Apenas não confunda o mapa com a viagem, o crachá com a profissão, nem o aplauso do dashboard com o momento em que você finalmente consegue fechar o chamado.



quinta-feira, 20 de outubro de 2022

DB2I RUN sem Mistérios : O Guia do Programador COBOL Padawan para Executar um Programa Db2, Entender PLAN, PACKAGE, LOAD MODULE e o JCL que Trabalha nos Bastidores

 

Bellacosa Mainframe e o db2i run sem misterios

☕ Um Café no Bellacosa Mainframe

DB2I RUN sem Mistérios

O Guia do Programador COBOL Padawan para Executar um Programa Db2, Entender PLAN, PACKAGE, LOAD MODULE e o JCL que Trabalha nos Bastidores

Imagine a cena.

Você está diante de um terminal 3270. O fundo é negro, os caracteres brilham em ciano e, no alto da tela, aparece uma palavra aparentemente inocente:

RUN

Logo ao lado, outra informação chama a atenção:

SSID: DB9G

No centro da tela existem apenas cinco campos:

1 DATA SET NAME
2 PASSWORD
3 PARAMETERS
4 PLAN NAME
5 WHERE TO RUN

Para um programador COBOL padawan, isso pode parecer apenas um formulário antigo para executar um programa. Mas essa tela é muito mais profunda do que aparenta.

Ela é a porta final de uma cadeia que envolve:

  • COBOL;

  • SQL;

  • Db2 Precompiler;

  • DBRM;

  • compilação;

  • binder;

  • load module;

  • package;

  • collection;

  • plan;

  • TSO;

  • ISPF;

  • DSN Command Processor;

  • JES;

  • JCL;

  • Language Environment;

  • subsistema Db2.

Ao pressionar Enter, você não está simplesmente “rodando um programa”.

Você está convocando várias camadas do z/OS para localizar um executável, conectar-se a um subsistema Db2, encontrar um plano, carregar packages, validar autorizações, criar uma thread e finalmente executar as instruções SQL.

Prepare a caneca, jovem padawan, porque hoje vamos abrir o capô dessa tela clássica e descobrir o que realmente acontece nos bastidores.


Be

1. O que é o painel RUN do DB2I?

O painel mostrado pertence ao DB2I, sigla para:

Db2 Interactive

O DB2I é uma interface baseada em painéis ISPF que facilita diversas tarefas relacionadas ao Db2 for z/OS.

Entre suas funções tradicionais estão:

  • executar comandos SQL;

  • utilizar o SPUFI;

  • gerar DCLGEN;

  • realizar precompile;

  • compilar programas;

  • executar BIND;

  • executar programas;

  • acessar utilitários;

  • gerar JCL.

O painel RUN é usado para iniciar um programa aplicativo que utiliza Db2.

Esse programa pode ter sido escrito em:

  • COBOL;

  • PL/I;

  • Assembler;

  • C;

  • C++;

  • outra linguagem suportada pelo ambiente.

No universo Bellacosa Mainframe, o cenário mais comum é um programa COBOL contendo SQL estático:

       EXEC SQL
           SELECT NOME_CLIENTE
             INTO :WS-NOME-CLIENTE
             FROM CLIENTES
            WHERE COD_CLIENTE = :WS-COD-CLIENTE
       END-EXEC.

Esse SQL não é executado diretamente pelo compilador COBOL. Antes disso, o programa precisa atravessar várias etapas.


2. A jornada completa do programa COBOL/Db2

Antes de chegar ao painel RUN, normalmente o programa percorreu este caminho:

Fonte COBOL com EXEC SQL
              |
              v
      Db2 Precompiler
              |
      +-------+--------+
      |                |
      v                v
Fonte COBOL         DBRM
modificado          gerado
      |                |
      v                |
Compilador COBOL      |
      |                |
      v                |
Object Module         |
      |                |
      v                v
Binder             BIND PACKAGE
      |                |
      v                v
Load Module        Package Db2
      |                |
      +-------+--------+
              |
              v
           Execução

O painel RUN aparece somente no final dessa viagem.

Ele não substitui as etapas anteriores.

Se o programa não foi corretamente preparado, o painel não fará milagres.


3. O que significa SSID?

No topo da tela aparece:

SSID: DB9G

SSID significa:

Subsystem Identifier

É o identificador do subsistema Db2 no qual o programa será executado.

Em um grande ambiente corporativo podem existir vários subsistemas:

DB2D
DB2T
DB2H
DB2P
DB9G
DB01
D91A

Uma empresa pode usar uma convenção como:

DB2D = Desenvolvimento
DB2T = Teste
DB2H = Homologação
DB2P = Produção

Mas isso não é obrigatório.

Cada instalação cria seus próprios padrões.

Por que isso é tão importante?

Porque o mesmo programa pode existir em vários ambientes.

Imagine:

Programa: CADCLI01
Plano: PLNCLI01
Tabela: CLIENTES

No desenvolvimento, a tabela pode conter 500 clientes fictícios.

Na produção, pode conter 20 milhões de registros reais.

Executar o programa no SSID errado pode provocar:

  • leitura de dados reais;

  • atualização indevida;

  • SQLCODE -204;

  • SQLCODE -805;

  • SQLCODE -551;

  • bloqueios;

  • commits inesperados;

  • incidentes operacionais.

Antes de pressionar Enter, sempre confirme:

Qual é o LPAR?
Qual é o SSID?
Qual é o ambiente?
Qual é o plano?
Qual é o qualifier das tabelas?

Uma simples letra no SSID pode separar um teste inocente de uma madrugada inteira em war room.


4. Campo 1 — DATA SET NAME

O primeiro campo é:

1 DATA SET NAME ===>

Esse campo informa onde se encontra o programa executável.

No z/OS, o executável normalmente está em uma biblioteca de carga:

VAGNER.COBOL.LOAD

O programa pode estar armazenado como membro:

VAGNER.COBOL.LOAD(CADCLI01)

Fonte não é executável

O fonte COBOL pode estar em:

VAGNER.COBOL.SOURCE(CADCLI01)

Mas o programa executável está em:

VAGNER.COBOL.LOAD(CADCLI01)

Esses objetos não são a mesma coisa.

O fonte é texto.

O load module é código de máquina preparado para execução.

Exemplo

Se o programa se chama:

CADCLI01

e foi linkeditado na biblioteca:

VAGNER.DB2.LOAD

o campo pode receber:

'VAGNER.DB2.LOAD(CADCLI01)'

Em algumas configurações, o painel pode pedir apenas a biblioteca ou ter outra convenção de preenchimento.

Por que as aspas são importantes?

No TSO, quando você informa:

VAGNER.DB2.LOAD

sem aspas, o sistema pode acrescentar automaticamente o seu prefixo de usuário.

Se seu user ID for:

VAGNER

o sistema pode interpretar:

VAGNER.VAGNER.DB2.LOAD

Com aspas:

'VAGNER.DB2.LOAD'

o nome é tratado como absoluto.

Erros comuns

Biblioteca inexistente

IKJ56228I DATA SET NOT IN CATALOG

Possíveis causas:

  • nome digitado incorretamente;

  • data set não catalogado;

  • aspas ausentes;

  • HLQ errado;

  • biblioteca excluída.

Membro inexistente

MEMBER CADCLI01 NOT FOUND

Possíveis causas:

  • o programa não foi linkeditado;

  • o link-edit falhou;

  • o membro foi criado com outro nome;

  • a biblioteca informada é a biblioteca de fontes;

  • o executável está em outro PDSE.

Versão antiga

Esse é um dos erros mais traiçoeiros.

Você altera o fonte:

VAGNER.COBOL.SOURCE(CADCLI01)

compila e acredita estar executando a nova versão.

Mas o painel aponta para:

VAGNER.OLD.LOAD(CADCLI01)

O programa roda normalmente, porém com comportamento antigo.

O programador então olha o fonte e pensa:

“Isso é impossível. Eu alterei essa linha.”

O mainframe responde silenciosamente:

“Você alterou o fonte certo, mas executou o load errado.”


5. Campo 2 — PASSWORD

O segundo campo é:

2 PASSWORD ===>

A própria tela explica:

Required if data set is password protected

Esse campo pertence a um tempo em que data sets podiam ser protegidos diretamente por senha.

Hoje, a segurança normalmente é controlada por:

  • RACF;

  • ACF2;

  • Top Secret;

  • SAF.

Na maioria dos ambientes modernos, esse campo permanece vazio.

Atenção

Essa senha não é necessariamente:

  • senha do TSO;

  • senha do RACF;

  • senha do Db2;

  • senha do usuário SQL;

  • senha de aplicativo.

Ela seria a senha associada diretamente ao data set.

É uma relíquia histórica, quase um fóssil vivo dentro do painel.

Easter egg histórico

O fato de o campo ainda existir mostra como o z/OS preserva compatibilidade.

Em outros ambientes, uma interface antiga seria simplesmente removida.

No mainframe, ela pode permanecer por décadas porque ainda existe a possibilidade de algum processo legado depender dela.

No reino IBM Z, compatibilidade não é nostalgia.

É estratégia operacional.


6. Campo 3 — PARAMETERS

O terceiro campo é:

3 PARAMETERS ===>

Aqui são informados parâmetros enviados ao programa.

Exemplo:

CONSULTA,000123

O programa pode interpretar isso como:

Operação = CONSULTA
Cliente  = 000123

Mas o COBOL não entende automaticamente vírgulas, palavras ou intenções.

Ele recebe bytes.

A aplicação precisa possuir uma lógica específica para interpretar o parâmetro.


7. Como o COBOL recebe parâmetros?

Existem diferentes formas, dependendo do ambiente e da implementação.

Uma forma conceitual seria usar ACCEPT FROM PARM:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CADCLI01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01  WS-PARAMETRO          PIC X(100).
       01  WS-OPERACAO           PIC X(10).
       01  WS-COD-CLIENTE        PIC X(06).

       PROCEDURE DIVISION.

           ACCEPT WS-PARAMETRO FROM PARM

           DISPLAY 'PARAMETRO RECEBIDO: ' WS-PARAMETRO

           UNSTRING WS-PARAMETRO
               DELIMITED BY ','
               INTO WS-OPERACAO
                    WS-COD-CLIENTE
           END-UNSTRING

           DISPLAY 'OPERACAO: ' WS-OPERACAO
           DISPLAY 'CLIENTE : ' WS-COD-CLIENTE

           GOBACK.

Explicando o exemplo

ACCEPT WS-PARAMETRO FROM PARM

Recebe o conteúdo passado durante a execução.

UNSTRING

Divide o conteúdo utilizando a vírgula como delimitador.

Entrada:

CONSULTA,000123

Resultado:

WS-OPERACAO    = CONSULTA
WS-COD-CLIENTE = 000123

Cuidado com espaços

Estes parâmetros podem parecer iguais:

CONSULTA,000123
CONSULTA, 000123
CONSULTA ,000123

Mas não são necessariamente iguais.

O segundo pode gerar:

WS-COD-CLIENTE = ' 00012'

dependendo do tamanho do campo.

O terceiro pode gerar:

WS-OPERACAO = 'CONSULTA '

Por isso, programas robustos normalmente usam:

  • FUNCTION TRIM;

  • validação;

  • teste de tamanho;

  • verificação de conteúdo numérico;

  • mensagens claras de erro.


8. Parâmetro em JCL

Em JCL, um parâmetro pode aparecer assim:

//STEP01 EXEC PGM=CADCLI01,PARM='CONSULTA,000123'

Quando a execução ocorre através do processador DSN, pode surgir como:

RUN PROGRAM(CADCLI01) PLAN(PLNCLI01)
    PARMS('CONSULTA,000123')

A palavra usada pode variar conforme a interface e o comando específico, mas o conceito é o mesmo: entregar uma cadeia de caracteres ao programa.


9. Campo 4 — PLAN NAME

O quarto campo é:

4 PLAN NAME ===>

A tela informa:

Required if different from program name

Esse campo é um dos mais importantes e também um dos mais confundidos por iniciantes.

Programa e plano não são a mesma coisa

Considere:

Programa: CADCLI01
Plano: PLNCLI01

O programa é o executável COBOL.

O plano é um objeto do Db2 usado durante a execução.

O programa pode ter o mesmo nome do plano, mas continuam sendo objetos completamente diferentes.


10. DBRM, PACKAGE, COLLECTION e PLAN

Para entender o plano, precisamos conhecer quatro conceitos.

DBRM

DBRM significa:

Database Request Module

Ele é gerado pelo Db2 Precompiler.

Contém informações sobre o SQL extraído do programa.

Exemplo:

CADCLI01

O DBRM pode ser armazenado em:

VAGNER.DBRMLIB(CADCLI01)

PACKAGE

O package é criado pelo comando:

BIND PACKAGE

Exemplo:

BIND PACKAGE(COLCLI)
     MEMBER(CADCLI01)
     ACTION(REPLACE)
     ISOLATION(CS)
     VALIDATE(BIND)
     RELEASE(COMMIT)

Esse comando pega o DBRM e cria um package dentro da collection COLCLI.

O package pode ser identificado como:

COLCLI.CADCLI01

COLLECTION

A collection é um agrupador lógico de packages.

Exemplos:

COLDEV
COLTST
COLPRD
COLCLI
COLFIN

A mesma aplicação pode ter packages em collections diferentes:

COLDEV.CADCLI01
COLTST.CADCLI01
COLPRD.CADCLI01

PLAN

O plan é criado pelo comando:

BIND PLAN

Exemplo:

BIND PLAN(PLNCLI01)
     PKLIST(COLCLI.*)
     ACTION(REPLACE)
     ISOLATION(CS)
     VALIDATE(BIND)

O plan aponta para os packages que poderão ser utilizados.

A relação fica assim:

Programa CADCLI01
        |
        v
Plan PLNCLI01
        |
        v
Collection COLCLI
        |
        v
Package CADCLI01
        |
        v
SQL preparado

11. Exemplo detalhado de BIND PACKAGE

BIND PACKAGE(COLCLI)
     MEMBER(CADCLI01)
     ACTION(REPLACE)
     ISOLATION(CS)
     VALIDATE(BIND)
     RELEASE(COMMIT)
     EXPLAIN(YES)

PACKAGE(COLCLI)

Define a collection onde o package será criado.

MEMBER(CADCLI01)

Informa o membro do DBRM.

ACTION(REPLACE)

Se o package já existir, será substituído.

Outras possibilidades incluem:

ACTION(ADD)

ISOLATION(CS)

Define o nível de isolamento Cursor Stability.

Isso influencia locking e concorrência.

VALIDATE(BIND)

Solicita validação dos objetos no momento do bind.

Alternativamente:

VALIDATE(RUN)

algumas verificações podem ser adiadas até a execução.

RELEASE(COMMIT)

Libera determinados recursos no commit.

EXPLAIN(YES)

Grava informações do access path nas tabelas de EXPLAIN, quando configuradas.


12. Exemplo detalhado de BIND PLAN

BIND PLAN(PLNCLI01)
     PKLIST(COLCLI.*)
     ACTION(REPLACE)
     ISOLATION(CS)
     VALIDATE(BIND)
     RETAIN

PLAN(PLNCLI01)

Nome do plano.

PKLIST(COLCLI.*)

Permite que o plano utilize os packages da collection COLCLI.

O asterisco significa múltiplos packages.

ACTION(REPLACE)

Substitui o plano existente.

RETAIN

Pode preservar determinadas autorizações anteriores, conforme as regras do ambiente e da operação realizada.


13. Erro clássico: SQLCODE -805

Quando o Db2 não encontra o package necessário, pode ocorrer:

SQLCODE = -805

A mensagem normalmente menciona:

  • collection;

  • package;

  • consistency token;

  • plan.

Possíveis causas:

  • package não foi criado;

  • package foi criado em outra collection;

  • plan aponta para collection errada;

  • programa foi recompilado;

  • bind não foi refeito;

  • package está em outro subsistema;

  • versão incorreta.

Exemplo

Programa:

CADCLI01

Plan:

PLNCLI01

Package existente:

COLDEV.CADCLI01

Mas o plan aponta para:

COLTST.*

Resultado:

-805

Checklist para resolver

Verifique:

1. Qual programa foi executado?
2. Qual plan foi informado?
3. Qual collection está no PKLIST?
4. O package existe?
5. O consistency token corresponde?
6. O bind ocorreu no mesmo SSID?

14. Erro clássico: SQLCODE -818

O SQLCODE -818 indica incompatibilidade entre o executável e o DBRM/package.

Em termos simples:

Load Module versão A
Package versão B

O programa e o package não pertencem à mesma geração.

Isso pode acontecer quando alguém executa:

Precompile
Compile
Link-edit

mas esquece:

BIND PACKAGE

Ou faz o contrário:

BIND PACKAGE

usando um DBRM antigo, mas executa um load novo.

A solução correta

Refaça a cadeia de forma consistente:

1. Precompile
2. Compile
3. Link-edit
4. Bind Package
5. Bind ou Rebind Plan, se necessário
6. Execute novamente

Easter egg do consistency token

Durante o precompile, o Db2 gera um identificador usado para garantir que:

executável e SQL preparado pertencem à mesma família

É quase como um selo de autenticidade.

O -818 é o Db2 dizendo:

“Esses dois artefatos afirmam ser parentes, mas o DNA não confere.”


15. Campo 5 — WHERE TO RUN

O quinto campo é:

5 WHERE TO RUN ===> FOREGROUND

As opções indicadas são:

FOREGROUND
BACKGROUND
EDITJCL

Cada uma representa um modo diferente de execução.


16. FOREGROUND

Em foreground, o programa executa dentro da sessão TSO atual.

WHERE TO RUN ===> FOREGROUND

Vantagens

  • execução imediata;

  • ideal para pequenos testes;

  • mensagens aparecem rapidamente;

  • não exige consultar o spool;

  • ótimo para laboratórios.

Desvantagens

  • ocupa a sessão;

  • um loop pode travar o terminal;

  • saída extensa pode ser difícil de acompanhar;

  • não é adequado para grandes processamentos;

  • pode ser difícil analisar dumps.

Use foreground para

  • um SELECT simples;

  • testar conexão;

  • validar plan/package;

  • executar um programa pequeno;

  • verificar SQLCODE;

  • testar parâmetros.

Evite foreground para

  • milhões de registros;

  • relatórios longos;

  • programas com muitos DDs;

  • atualizações massivas;

  • programas sujeitos a abend;

  • processos demorados.


17. BACKGROUND

Em background, o DB2I gera e submete um job.

WHERE TO RUN ===> BACKGROUND

O fluxo passa a ser:

DB2I
  |
  v
JCL gerado
  |
  v
SUBMIT
  |
  v
JES2
  |
  v
Initiator
  |
  v
Programa COBOL/Db2
  |
  v
Spool

Vantagens

  • libera a sessão TSO;

  • saída fica no spool;

  • facilita análise;

  • suporta DD statements;

  • ideal para processos longos;

  • permite guardar dumps e logs.

Depois da submissão, o usuário pode consultar o SDSF.

Exemplo:

SDSF
ST

E localizar o job pelo nome ou owner.


18. EDITJCL

A opção EDITJCL é uma das mais educativas.

WHERE TO RUN ===> EDITJCL

O DB2I gera o JCL, mas permite que o programador o revise antes da submissão.

Isso é excelente para compreender o que o painel esconde.

É como escolher:

FOREGROUND = ligue o motor agora
BACKGROUND = ligue o motor e siga a rota
EDITJCL    = abra o capô antes de sair

19. Primeiro exemplo de JCL — Execução simples com IKJEFT01

//VAGRUN01 JOB (DB2),'RUN COBOL DB2',
//             CLASS=A,
//             MSGCLASS=X,
//             MSGLEVEL=(1,1),
//             NOTIFY=&SYSUID
//*------------------------------------------------------*
//* EXECUCAO DO PROGRAMA CADCLI01 NO DB2 DB9G
//*------------------------------------------------------*
//RUNDB2   EXEC PGM=IKJEFT01,DYNAMNBR=20
//STEPLIB  DD DISP=SHR,DSN=VAGNER.DB2.LOAD
//         DD DISP=SHR,DSN=DB9G.SDSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB9G)
  RUN PROGRAM(CADCLI01) PLAN(PLNCLI01)
  END
/*

Agora vamos analisar linha por linha.


20. JOB statement

//VAGRUN01 JOB (DB2),'RUN COBOL DB2',

VAGRUN01

É o nome do job.

Dependendo da instalação, o nome pode precisar começar com o user ID.

(DB2)

É a informação contábil.

Pode representar:

  • centro de custo;

  • projeto;

  • departamento;

  • conta de cobrança.

'RUN COBOL DB2'

É a descrição do job.


21. CLASS

//             CLASS=A,

Define a classe de execução.

A classe influencia:

  • prioridade;

  • initiator;

  • regras locais;

  • recursos;

  • janela operacional.

O significado de CLASS=A varia entre empresas.

Em um ambiente, pode ser teste rápido.

Em outro, pode ser processamento normal.

Nunca assuma que a classe tem o mesmo significado em todos os z/OS.


22. MSGCLASS

//             MSGCLASS=X,

Define a classe de saída no spool.

Ela controla onde e como as mensagens do job serão armazenadas ou tratadas.


23. MSGLEVEL

//             MSGLEVEL=(1,1),

Controla quais instruções JCL e mensagens serão impressas no spool.

O primeiro valor está relacionado às instruções JCL.

O segundo, às mensagens de alocação e término.

Para diagnóstico, (1,1) costuma ser bastante útil.


24. NOTIFY

//             NOTIFY=&SYSUID

Solicita notificação ao usuário que submeteu o job.

&SYSUID é substituído pelo user ID.

Quando o job termina, pode surgir uma mensagem como:

VAGRUN01 ENDED - RC=0000

25. EXEC PGM=IKJEFT01

//RUNDB2 EXEC PGM=IKJEFT01,DYNAMNBR=20

IKJEFT01 permite executar comandos TSO em batch.

É frequentemente utilizado para chamar o processador DSN.

DYNAMNBR=20

Define a quantidade de alocações dinâmicas disponíveis.

Alguns processos TSO/Db2 podem precisar alocar data sets dinamicamente.

Valores exatos seguem os padrões do ambiente.


26. STEPLIB

//STEPLIB DD DISP=SHR,DSN=VAGNER.DB2.LOAD
//        DD DISP=SHR,DSN=DB9G.SDSNLOAD

A STEPLIB indica onde o sistema deve procurar programas e módulos.

Primeira biblioteca

VAGNER.DB2.LOAD

Contém o programa da aplicação:

CADCLI01

Segunda biblioteca

DB9G.SDSNLOAD

Pode conter módulos de carga do Db2.

O nome real varia conforme a instalação.

Ordem importa

O z/OS procura os módulos na ordem das bibliotecas.

Se o mesmo programa existir em duas bibliotecas, a primeira ocorrência pode ser utilizada.

Isso pode causar o fantasma da versão antiga.


27. SYSTSPRT

//SYSTSPRT DD SYSOUT=*

Recebe mensagens produzidas pelo ambiente TSO e pelo processador de comandos.

Pode conter informações importantes sobre:

  • início do DSN;

  • conexão com subsistema;

  • execução;

  • mensagens de erro;

  • término.


28. SYSPRINT

//SYSPRINT DD SYSOUT=*

É uma saída comum para mensagens impressas por programas e utilitários.

Nem todo programa usa SYSPRINT, mas ela costuma ser incluída por convenção.


29. SYSOUT

//SYSOUT DD SYSOUT=*

Pode receber mensagens produzidas pela aplicação.

Se o COBOL possuir:

DISPLAY 'INICIO DO PROGRAMA'

a saída pode aparecer em SYSOUT, conforme a configuração de runtime.


30. SYSUDUMP

//SYSUDUMP DD SYSOUT=*

Solicita dump em caso de abend.

É útil para investigar erros como:

S0C4
S0C7
S0CB
S806

O dump pode mostrar:

  • PSW;

  • registradores;

  • área de memória;

  • offset;

  • módulo;

  • traceback.


31. SYSTSIN

//SYSTSIN DD *
  DSN SYSTEM(DB9G)
  RUN PROGRAM(CADCLI01) PLAN(PLNCLI01)
  END
/*

Essa DD contém os comandos enviados ao IKJEFT01.

DSN SYSTEM(DB9G)

Inicia o processador DSN e conecta ao subsistema DB9G.

RUN PROGRAM(CADCLI01)

Solicita a execução do programa.

PLAN(PLNCLI01)

Indica o plano Db2.

END

Encerra o processador DSN.


32. Segundo exemplo de JCL — Programa com parâmetros

//VAGRUN02 JOB (DB2),'RUN COM PARAMETRO',
//             CLASS=A,
//             MSGCLASS=X,
//             NOTIFY=&SYSUID
//*
//RUNDB2   EXEC PGM=IKJEFT01,DYNAMNBR=30
//STEPLIB  DD DISP=SHR,DSN=VAGNER.DB2.LOAD
//         DD DISP=SHR,DSN=DB9G.SDSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//CEEOUT   DD SYSOUT=*
//CEEDUMP  DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB9G)
  RUN PROGRAM(CADCLI01) -
      PLAN(PLNCLI01) -
      PARMS('CONSULTA,000123')
  END
/*

Continuação com hífen

O hífen indica continuação lógica do comando DSN.

RUN PROGRAM(CADCLI01) -
    PLAN(PLNCLI01) -
    PARMS('CONSULTA,000123')

Isso melhora a leitura.

Cuidado com aspas

O parâmetro está entre aspas:

'CONSULTA,000123'

Aspas mal posicionadas podem provocar erro de sintaxe ou alterar o conteúdo entregue.


33. Terceiro exemplo de JCL — Programa com arquivo de entrada e saída

//VAGRUN03 JOB (DB2),'PROCESSA CLIENTES',
//             CLASS=A,
//             MSGCLASS=X,
//             MSGLEVEL=(1,1),
//             NOTIFY=&SYSUID
//*------------------------------------------------------*
//* PROGRAMA COBOL DB2 COM ARQUIVO DE ENTRADA E SAIDA
//*------------------------------------------------------*
//RUNDB2   EXEC PGM=IKJEFT01,DYNAMNBR=50,REGION=0M
//STEPLIB  DD DISP=SHR,DSN=VAGNER.DB2.LOAD
//         DD DISP=SHR,DSN=DB9G.SDSNLOAD
//*
//ENTRADA  DD DISP=SHR,
//            DSN=VAGNER.CLIENTES.ENTRADA
//*
//SAIDA    DD DISP=(NEW,CATLG,DELETE),
//            DSN=VAGNER.CLIENTES.SAIDA,
//            SPACE=(CYL,(1,1),RLSE),
//            DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)
//*
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//CEEOUT   DD SYSOUT=*
//CEEDUMP  DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB9G)
  RUN PROGRAM(PROCCLI1) -
      PLAN(PLNPROC1) -
      PARMS('PROCESSAR')
  END
/*

34. DD ENTRADA

//ENTRADA DD DISP=SHR,
//           DSN=VAGNER.CLIENTES.ENTRADA

O nome ENTRADA deve corresponder ao nome usado no COBOL:

       SELECT ARQ-ENTRADA
           ASSIGN TO ENTRADA.

DISP=SHR

O data set já existe e será compartilhado para leitura.

DSN

É o nome do arquivo.


35. DD SAIDA

//SAIDA DD DISP=(NEW,CATLG,DELETE),

NEW

O arquivo será criado.

CATLG

Se o step terminar normalmente, o data set será catalogado.

DELETE

Se o step falhar, o data set será excluído.

Esse trio é um clássico:

DISP=(NEW,CATLG,DELETE)

36. SPACE

//          SPACE=(CYL,(1,1),RLSE),

CYL

A unidade de alocação será cilindro.

(1,1)

  • 1 cilindro primário;

  • 1 cilindro secundário.

RLSE

Libera espaço não utilizado ao final.


37. DCB

//          DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)

RECFM=FB

Registros de tamanho fixo e blocados.

LRECL=200

Cada registro possui 200 bytes.

BLKSIZE=0

Solicita ao sistema um tamanho de bloco adequado.


38. REGION=0M

//RUNDB2 EXEC PGM=IKJEFT01,DYNAMNBR=50,REGION=0M

REGION=0M solicita o máximo de memória permitido pelas regras do sistema.

Não significa memória infinita.

O z/OS ainda aplica:

  • limites da instalação;

  • políticas;

  • WLM;

  • storage disponível;

  • regras do job class.


39. Language Environment: CEEOUT e CEEDUMP

//CEEOUT  DD SYSOUT=*
//CEEDUMP DD SYSOUT=*

O Language Environment fornece serviços comuns para linguagens como COBOL, PL/I e C.

CEEOUT

Recebe saídas relacionadas ao Language Environment.

CEEDUMP

Recebe dump formatado pelo Language Environment.

Em muitos casos, o CEEDUMP é mais fácil de analisar do que um dump bruto.


40. Um programa COBOL/Db2 de exemplo

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CADCLI01.

       DATA DIVISION.

       WORKING-STORAGE SECTION.

       EXEC SQL
           INCLUDE SQLCA
       END-EXEC.

       01  WS-PARAMETRO.
           05 WS-OPERACAO       PIC X(10).
           05 WS-COD-CLIENTE    PIC 9(06).

       01  WS-NOME-CLIENTE      PIC X(40).
       01  WS-STATUS-CLIENTE    PIC X.

       PROCEDURE DIVISION.

       0000-PRINCIPAL.

           DISPLAY '*** INICIO CADCLI01 ***'

           ACCEPT WS-PARAMETRO FROM PARM

           DISPLAY 'OPERACAO: ' WS-OPERACAO
           DISPLAY 'CLIENTE : ' WS-COD-CLIENTE

           EXEC SQL
               SELECT NOME_CLIENTE,
                      STATUS_CLIENTE
                 INTO :WS-NOME-CLIENTE,
                      :WS-STATUS-CLIENTE
                 FROM CLIENTES
                WHERE COD_CLIENTE = :WS-COD-CLIENTE
           END-EXEC

           EVALUATE SQLCODE
               WHEN 0
                   DISPLAY 'CLIENTE ENCONTRADO'
                   DISPLAY 'NOME  : ' WS-NOME-CLIENTE
                   DISPLAY 'STATUS: ' WS-STATUS-CLIENTE

               WHEN 100
                   DISPLAY 'CLIENTE NAO ENCONTRADO'

               WHEN OTHER
                   DISPLAY 'ERRO SQL'
                   DISPLAY 'SQLCODE : ' SQLCODE
                   DISPLAY 'SQLSTATE: ' SQLSTATE
                   DISPLAY 'SQLERRMC: ' SQLERRMC
           END-EVALUATE

           EXEC SQL
               COMMIT
           END-EXEC

           DISPLAY '*** FIM CADCLI01 ***'

           GOBACK.

41. SQLCA

A instrução:

       EXEC SQL
           INCLUDE SQLCA
       END-EXEC.

inclui a SQL Communication Area.

Ela contém informações sobre o último comando SQL executado.

Campos importantes:

SQLCODE
SQLSTATE
SQLERRMC
SQLERRD
SQLWARN

SQLCODE

Código de retorno tradicional.

Exemplos:

0     Sucesso
+100  Não encontrado
-204  Objeto não definido
-305  Indicador necessário
-551  Sem autorização
-805  Package não encontrado
-811  Mais de uma linha retornada
-818  Timestamp inconsistente
-911  Rollback por deadlock ou timeout
-913  Execução sem rollback completo

42. SQLCODE +100

O +100 não significa abend.

Significa, geralmente:

não foi encontrada nenhuma linha

No exemplo:

SELECT NOME_CLIENTE
  FROM CLIENTES
 WHERE COD_CLIENTE = 123456

Se o cliente não existir:

SQLCODE = +100

O programa deve tratar isso como condição de negócio.


43. SQLCODE -204

OBJECT NOT DEFINED

Pode ocorrer quando:

  • tabela não existe;

  • qualifier está errado;

  • subsistema é incorreto;

  • tabela existe em outro schema;

  • alias não está disponível.

Exemplo:

SELECT *
FROM CLIENTES;

O Db2 pode procurar:

VAGNER.CLIENTES

quando a tabela real é:

APPDB.CLIENTES

Uma solução seria qualificar:

SELECT *
FROM APPDB.CLIENTES;

44. SQLCODE -551

Indica falta de autorização.

Exemplo:

AUTHORIZATION ID VAGNER DOES NOT HAVE SELECT PRIVILEGE

Verifique:

  • grant direto;

  • role;

  • grupo RACF;

  • secondary auth ID;

  • autorização do package;

  • autorização do plan.

O Db2 pode executar com diferentes contextos de autorização, dependendo do bind e do ambiente.


45. S806 — módulo não encontrado

Se o sistema não localizar o executável, pode ocorrer:

ABEND S806

Verifique:

  • STEPLIB;

  • JOBLIB;

  • nome do programa;

  • biblioteca de load;

  • link-edit;

  • membro;

  • APF, quando aplicável;

  • ordem das bibliotecas.

Exemplo:

RUN PROGRAM(CADCLI01)

mas o membro se chama:

CADCLIO1

Note a diferença entre zero e letra O.

Esse erro é tão clássico quanto café frio ao lado do terminal.


46. S0C7 — dado numérico inválido

Um S0C7 ocorre quando o programa tenta usar como número algo que não é numérico.

Exemplo:

01 WS-VALOR PIC 9(05).

Mas o conteúdo é:

12A45

Uma operação matemática pode gerar:

S0C7

Parâmetros malformados podem causar esse problema.

Entrada:

CONSULTA,00A123

Se o programa mover diretamente para um campo numérico, o abend pode surgir.


47. S0C4 — endereço inválido

O S0C4 costuma estar relacionado a:

  • subscrito fora da tabela;

  • ponteiro inválido;

  • linkage incorreto;

  • área não inicializada;

  • comprimento errado;

  • acesso indevido à memória.

Pode acontecer se o programa espera um parâmetro de 100 bytes, mas recebe uma estrutura incompatível.


48. Commit e rollback

O painel RUN pode iniciar programas que atualizam dados reais.

Exemplo:

UPDATE CLIENTES
   SET STATUS_CLIENTE = 'I'
 WHERE ULTIMO_ACESSO < CURRENT DATE - 5 YEARS;

Se o programa executar:

       EXEC SQL
           COMMIT
       END-EXEC.

as alterações serão confirmadas.

Antes de executar um programa de atualização, confirme:

1. Estou no ambiente correto?
2. O WHERE está correto?
3. O parâmetro está correto?
4. Existe backup?
5. Existe estratégia de rollback?
6. Qual será a frequência de commit?
7. O programa foi testado com poucos registros?

Rollback

Se ocorrer erro antes do commit:

       EXEC SQL
           ROLLBACK
       END-EXEC.

pode desfazer as alterações da unidade de trabalho.

Mas atenção: a capacidade de rollback depende dos commits já realizados.

Depois de confirmado, um commit não é apagado por um rollback posterior.


49. Foreground não significa ausência de infraestrutura

Mesmo em foreground, o programa ainda utiliza:

  • thread Db2;

  • packages;

  • buffer pools;

  • logs;

  • locks;

  • WLM;

  • Language Environment;

  • storage;

  • catalog;

  • directories;

  • módulos de runtime;

  • autorização SAF.

A diferença está na forma de iniciar e acompanhar a execução.

Foreground = sessão TSO
Background = job JES

O Db2 continua sendo o mesmo motor.


50. IKJEFT01, IKJEFT1A e IKJEFT1B

Você pode encontrar JCLs usando:

IKJEFT01
IKJEFT1A
IKJEFT1B

Todos pertencem ao universo de execução TSO em batch.

As diferenças estão principalmente no comportamento de término e propagação de códigos de retorno.

Em ambientes corporativos, siga o padrão oficial.

Não substitua um pelo outro apenas porque “parece parecido”.

Um JCL homologado pode depender do comportamento específico de retorno.


51. Um roteiro seguro antes de pressionar Enter

Passo 1 — Confirme o SSID

SSID: DB9G

Saiba se ele representa:

  • desenvolvimento;

  • teste;

  • homologação;

  • produção.

Passo 2 — Confirme o load module

No ISPF 3.4:

VAGNER.DB2.LOAD

Verifique:

CADCLI01

Passo 3 — Confirme a data

Veja se o membro foi atualizado após a última compilação.

Passo 4 — Confirme o package

O package foi criado ou rebindeado?

Passo 5 — Confirme o plan

O plano aponta para a collection correta?

Passo 6 — Valide parâmetros

Confira vírgulas, espaços, tamanhos e valores.

Passo 7 — Escolha o modo correto

FOREGROUND
BACKGROUND
EDITJCL

Passo 8 — Revise os DDs

O programa precisa de:

ENTRADA
SAIDA
SYSIN
SYSOUT
ARQERRO

Passo 9 — Execute com poucos dados

Primeiro teste com um conjunto reduzido.

Passo 10 — Analise resultado e SQLCODE

RC=0000 não garante que a regra de negócio funcionou corretamente.

Um programa pode terminar com RC zero e ainda ter tratado incorretamente um +100.


52. O grande easter egg do painel

A frase:

Required if different from program name

esconde uma convenção histórica.

Muitas instalações utilizavam nomes iguais:

Programa = CADCLI01
DBRM     = CADCLI01
Package  = CADCLI01
Plan     = CADCLI01

Isso facilitava a administração, mas confundia iniciantes.

O padawan olhava para quatro objetos chamados CADCLI01 e imaginava que eram o mesmo.

Não são.

Programa = executável
DBRM     = SQL extraído
Package  = SQL preparado
Plan     = caminho para packages

Podem compartilhar o mesmo nome, mas possuem naturezas diferentes.

É como ter quatro pessoas chamadas João trabalhando no mesmo datacenter.

O nome é igual.

A função não.


53. O verdadeiro valor do EDITJCL

Para aprender, a melhor opção muitas vezes é:

EDITJCL

Ela mostra o JCL que o painel geraria.

Isso permite estudar:

  • JOB card;

  • EXEC;

  • STEPLIB;

  • SYSTSIN;

  • SYSTSPRT;

  • SYSOUT;

  • parâmetros;

  • DDs;

  • comandos DSN.

Depois de revisar, você pode:

  • salvar o JCL em uma biblioteca;

  • documentar;

  • versionar;

  • adaptar;

  • submeter novamente;

  • transformar em PROC;

  • integrar a uma esteira.

O painel deixa de ser uma caixa-preta e vira uma ferramenta de ensino.


54. Do DB2I ao DevOps moderno

Hoje, o mesmo fluxo pode ser automatizado por ferramentas como:

  • IBM Dependency Based Build;

  • zBuilder;

  • Jenkins;

  • GitHub Actions;

  • GitLab CI;

  • UrbanCode Deploy;

  • Endevor;

  • ISPW;

  • IBM Developer for z/OS;

  • VS Code;

  • Zowe CLI.

Um pipeline pode executar:

Checkout
Precompile
Compile
Link-edit
Bind Package
Test
Deploy
Run
Validate

Mas por trás da automação continuam existindo os mesmos conceitos:

  • fonte;

  • DBRM;

  • load;

  • package;

  • plan;

  • ambiente;

  • autorização.

Quem entende o painel RUN compreende melhor o que o pipeline está automatizando.

A modernização não elimina os fundamentos.

Ela os organiza, automatiza e observa.


Conclusão

O painel DB2I RUN parece pequeno, quase humilde.

Cinco campos, um SSID e uma tecla Enter.

Mas atrás dele existe um dos mais ricos ecossistemas da computação corporativa.

Ao preencher:

DATA SET NAME
PASSWORD
PARAMETERS
PLAN NAME
WHERE TO RUN

você está conectando:

Programa COBOL
Load Module
Language Environment
DSN Command Processor
Plano Db2
Package
Collection
Subsistema
JES
TSO
ISPF
JCL

O painel não compila o programa.

Não cria magicamente o package.

Não corrige um bind quebrado.

Não sincroniza um load antigo.

Ele apenas reúne as peças que já deveriam estar preparadas.

Quando tudo está alinhado, o resultado pode ser:

RC=0000
SQLCODE=0

Quando algo está fora do lugar, entram em cena os grandes vilões:

-204
-551
-805
-818
S806
S0C4
S0C7

A grande lição para o programador COBOL padawan é simples:

Nunca veja o RUN apenas como uma tela de execução. Veja-o como o ponto de encontro entre o mundo do COBOL e o mundo do Db2.

Quando você entende load module, DBRM, package, collection, plan, SSID, JCL e DSN, deixa de ser alguém que apenas pressiona Enter.

Você passa a compreender cada peça da engrenagem.

E nesse momento, jovem padawan, a tela verde deixa de ser um mistério.

Ela se transforma em mapa.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...