Translate

quinta-feira, 6 de agosto de 2015

Engenharia Militar : Capítulo VIII — Liderança, Moral e Disciplina: O Fator Humano na Engenharia dos Sistemas Críticos

Bellacosa Mainframe e a engenharia militar parte viii

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Capítulo VIII — Liderança, Moral e Disciplina: O Fator Humano na Engenharia dos Sistemas Críticos

Quando um Programador COBOL Descobre que o Maior Ativo de um Mainframe Nunca Foi o Hardware... Sempre Foram as Pessoas

A chuva caía sem parar.

O castelo permanecia cercado havia quase quatro meses.

As muralhas continuavam intactas.

Os depósitos ainda estavam abastecidos.

As armas funcionavam.

Os arqueiros permaneciam em suas posições.

Mesmo assim...

o velho comandante observava tudo com preocupação.

O jovem samurai aproximou-se.

— Mestre...

as defesas continuam fortes.

Por que parece preocupado?

O velho apontou para um soldado sentado próximo ao portão.

Depois para outro que dormia durante a guarda.

Depois para um grupo discutindo.

Em seguida respondeu:

— Porque os muros continuam firmes.

Mas começo a enxergar rachaduras onde nenhuma pedra consegue alcançar.

O jovem não compreendeu.

— Onde?

O comandante colocou a mão sobre o próprio peito.

— Aqui.

Dentro das pessoas.

Uma fortaleza não cai apenas quando suas muralhas desabam.

Ela cai quando seus defensores deixam de acreditar que vale a pena defendê-la.

Séculos depois...

08h17 da manhã.

Uma grande mudança em produção havia sido concluída com sucesso.

Nenhum ABEND.

Nenhum SQLCODE inesperado.

Nenhum problema no CICS.

Tudo parecia perfeito.

Então um operador perguntou:

— Alguém avisou a equipe do faturamento que o horário do processamento mudou?

Silêncio.

Naquele instante, o arquiteto percebeu que toda a engenharia havia funcionado.

O único problema estava justamente onde quase nunca aparece nos diagramas.

As pessoas.

Pegue seu café.

Hoje falaremos sobre o componente mais complexo de qualquer Data Center.

O ser humano.


1. A ilusão da tecnologia

Existe uma frase muito comum.

"Nosso problema é tecnológico."

Na maioria das vezes...

não é.

Grandes incidentes costumam nascer de:

comunicação deficiente;

documentação incompleta;

pressa;

treinamento insuficiente;

suposições equivocadas;

medo de perguntar;

falta de liderança.

O computador apenas revela problemas que já existiam entre as pessoas.


2. O comandante invisível

Quando pensamos em um comandante imaginamos alguém empunhando uma espada.

Na realidade...

bons líderes passam boa parte do tempo ouvindo.

Observando.

Perguntando.

Conectando especialistas.

Removendo obstáculos.

Na engenharia de software ocorre exatamente igual.

O melhor líder raramente é quem escreve mais código.

É quem permite que toda a equipe produza melhor.


3. Disciplina não é rigidez

Muitos confundem disciplina com autoritarismo.

Na engenharia militar disciplina significa previsibilidade.

Cada pessoa conhece:

sua missão;

seu horário;

seus procedimentos;

seus limites;

seus responsáveis.

No Data Center isso reduz riscos.

Quando todos seguem padrões, os incidentes tornam-se mais fáceis de investigar e resolver.


4. O Manual Existe por um Motivo

O jovem programador frequentemente pergunta:

"Por que preciso seguir exatamente este procedimento?"

Porque alguém, anos atrás, descobriu da maneira mais difícil o que acontece quando ele não é seguido.

Cada checklist.

Cada runbook.

Cada procedimento.

Cada convenção de nomenclatura.

Normalmente nasceu depois de um problema real.

A documentação é uma coleção de cicatrizes transformadas em conhecimento.


5. Moral é um Recurso Estratégico

Napoleão dizia que o moral pesa mais que muitos fatores materiais.

Um exército cansado, desorganizado e sem confiança dificilmente vence.

Em projetos de software acontece algo semelhante.

Equipes motivadas:

compartilham conhecimento;

pedem ajuda;

corrigem erros rapidamente;

documentam melhor;

ensinam iniciantes.

Já equipes desmotivadas escondem problemas, evitam responsabilidades e deixam de colaborar.


6. O Mestre e o Aprendiz

No Japão feudal existia uma longa tradição de aprendizado contínuo.

O conhecimento era transmitido por observação, prática e repetição.

No universo COBOL encontramos o mesmo modelo.

O veterano explica.

O novato observa.

Depois executa.

Depois ensina outro iniciante.

Assim o conhecimento sobrevive durante décadas.

Nenhum manual substitui completamente a experiência compartilhada.


7. O perigo do Herói Solitário

Existe um personagem presente em muitas equipes.

O Herói.

É a única pessoa que entende determinado sistema.

Resolve tudo.

Nunca documenta.

Nunca ensina.

Todos dependem dele.

No começo parece eficiente.

Com o tempo torna-se um enorme risco operacional.

Na engenharia militar isso seria equivalente a possuir apenas um engenheiro capaz de levantar a ponte levadiça.

Se ele desaparecer...

todo o castelo ficará vulnerável.


8. Conhecimento Distribuído

Organizações maduras distribuem conhecimento.

Promovem:

pair programming;

revisões de código;

treinamentos;

rotação de atividades;

documentação viva;

simulações.

O objetivo não é criar especialistas isolados.

É criar equipes resilientes.


9. O Valor da Confiança

Imagine um comandante que nunca acredita em seus oficiais.

Cada decisão precisa de aprovação.

Cada detalhe exige confirmação.

A velocidade desaparece.

Confiar não significa abandonar controle.

Significa desenvolver pessoas para que possam decidir corretamente.

No desenvolvimento de software isso acelera entregas sem comprometer qualidade.


10. O Erro como Professor

Em muitos ambientes existe medo de errar.

Consequência?

Problemas são escondidos.

Na engenharia madura ocorre o contrário.

O incidente é investigado.

Não para encontrar culpados.

Mas para descobrir causas.

Post-mortems bem conduzidos fortalecem toda a organização.

O erro deixa de ser vergonha.

Passa a ser oportunidade de aprendizado.


11. Goblin Slayer e a Confiança

Goblin Slayer possui enorme experiência.

Mesmo assim depende constantemente de sua equipe.

A Sacerdotisa protege.

A Arqueira observa.

O Anão improvisa.

O Lagarto cria novas soluções.

Cada integrante complementa os demais.

Nenhum vence sozinho.

Essa talvez seja uma das maiores lições da obra.

Competência individual importa.

Competência coletiva decide campanhas.


12. Shogun e a Liderança Silenciosa

Em Shogun, diversos líderes influenciam mais pelo exemplo do que pelos discursos.

Eles permanecem calmos durante crises.

Escutam antes de decidir.

Controlam emoções.

Inspiram confiança.

No Data Center, durante um incidente crítico, a serenidade do líder costuma definir o comportamento de toda a equipe.

Pânico é contagioso.

Calma também.


13. O Briefing

Antes de qualquer operação militar existe um briefing.

Objetivo.

Cronograma.

Riscos.

Responsáveis.

Plano alternativo.

Critérios de sucesso.

Mudanças em produção deveriam seguir exatamente essa lógica.

Quando todos entendem o contexto, as decisões tornam-se muito melhores.


14. A Debriefing

Depois da missão...

vem o debriefing.

O que funcionou?

O que não funcionou?

O que aprendemos?

Esse hábito transforma experiência em conhecimento organizacional.

Projetos que ignoram essa etapa repetem os mesmos erros durante anos.


15. Comunicação também é Engenharia

Uma mensagem mal escrita pode causar um incidente.

Uma documentação ambígua pode atrasar uma implantação.

Um requisito incompleto pode produzir semanas de retrabalho.

Comunicação não é habilidade secundária.

É parte da engenharia.

Programadores excelentes escrevem código claro.

Engenheiros excelentes também escrevem explicações claras.


16. O Peso da Cultura

Toda equipe desenvolve uma cultura.

Algumas valorizam aprendizado.

Outras valorizam culpa.

Algumas recompensam colaboração.

Outras recompensam competição.

A cultura invisível determina como as pessoas agem quando ninguém está observando.

Por isso ela é tão importante quanto qualquer arquitetura técnica.


17. Curiosidade Histórica

Os grandes castelos japoneses não dependiam apenas de samurais. Ferreiros, carpinteiros, cozinheiros, médicos, escribas, mensageiros, agricultores e artesãos desempenhavam funções essenciais para manter a fortaleza funcionando. Uma muralha impecável seria inútil se faltassem alimentos, manutenção ou comunicação.

Nos sistemas corporativos ocorre o mesmo. Analistas de negócios, operadores, DBAs, administradores de sistemas, especialistas em segurança, desenvolvedores, arquitetos e equipes de suporte formam um ecossistema onde cada função contribui para a continuidade da operação.


18. Easter Egg — O Manual Esquecido

Conta-se que um administrador veterano mantinha uma pasta bastante antiga.

Na capa estava escrito apenas:

NÃO JOGAR FORA

Durante anos ninguém abriu aquele material.

Parecia obsoleto.

Até que um incidente extremamente raro aconteceu.

Um equipamento antigo precisou ser reiniciado seguindo exatamente uma sequência específica.

O procedimento existia apenas naquele manual.

No final da última página havia uma anotação escrita à mão.

Se você está lendo isto,
é porque tivemos o mesmo problema novamente.

Boa sorte.

Bellacosa, 1998.

Todos riram.

Depois perceberam algo importante.

Documentação nunca envelhece.

Ela apenas espera o próximo profissional que precisará dela.


19. Checklist do Líder Técnico

Antes de considerar uma equipe preparada, pergunte:

✔ Todos conhecem os objetivos do projeto?

✔ Existe documentação atualizada?

✔ O conhecimento está distribuído?

✔ Há sucessores para funções críticas?

✔ Os procedimentos são claros?

✔ Os iniciantes recebem mentoria?

✔ Os incidentes geram aprendizado?

✔ A comunicação é transparente?

✔ As mudanças possuem briefing?

✔ Existe debriefing após implantações?

✔ As pessoas sentem segurança para fazer perguntas?

✔ A equipe aprende continuamente?


Conclusão — O Castelo Era Feito de Pessoas

Meses depois do fim do cerco, o jovem comandante caminhava pelas ruas do castelo.

As muralhas permaneciam majestosas.

As torres continuavam altas.

Os portões eram impressionantes.

Mesmo assim...

agora ele observava outra coisa.

Via os ferreiros reparando ferramentas.

Os cozinheiros preparando refeições.

Os mensageiros cruzando os corredores.

Os carpinteiros reforçando telhados.

Os arqueiros treinando novos soldados.

O velho engenheiro aproximou-se.

— O que você aprendeu?

O rapaz respondeu sorrindo.

— Passei meses acreditando que nossa fortaleza era feita de pedra.

Hoje entendo que ela sempre foi feita de pessoas.

Na sala de operações, o processamento encerrava mais um dia sem incidentes.

Não porque todos os servidores fossem perfeitos.

Nem porque todos os programas COBOL fossem impecáveis.

Mas porque centenas de profissionais trabalhavam juntos, compartilhando conhecimento, revisando procedimentos, ensinando novos colegas e aprendendo continuamente.

O jovem programador desligou seu terminal.

Pela primeira vez compreendeu que o maior patrimônio de um Data Center não estava nas CPUs, nos discos ou nos cabos de fibra óptica.

Estava na experiência acumulada de pessoas que, durante décadas, haviam transformado erros em procedimentos, dúvidas em documentação e desafios em conhecimento.

Porque uma fortaleza pode ser reconstruída.

Um servidor pode ser substituído.

Um programa pode ser recompilado.

Mas uma equipe que aprende junta...

essa se torna praticamente impossível de derrotar.

E é justamente essa equipe que mantém funcionando, dia após dia, os sistemas críticos sobre os quais milhões de pessoas confiam suas vidas financeiras, profissionais e pessoais.

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Uma campanha completa sobre estratégia, logística, inteligência, segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.

Consultar arquivo
25 documentos
2014–2016 linha histórica
IBM Z fortaleza digital
COBOL linguagem da missão
Arquivo estratégico

Um Data Center analisado como uma fortaleza em guerra

A série Engenharia Militar sem Mistérios para Programadores COBOL compara castelos, exércitos, muralhas, cadeias de comando, logística, inteligência e operações militares com os ambientes IBM Z responsáveis por bancos, governos, seguros, transportes e serviços essenciais.

Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL, Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF, monitoramento, contingência, liderança, documentação e continuidade operacional.

Sala de operações

Índice da campanha

25 documentos localizados
Índice permanente

Links completos da série Engenharia Militar

Esta relação permanece disponível no HTML da página para mecanismos de busca, leitores de tela, navegadores sem JavaScript e ferramentas de arquivamento.

  1. Engenharia Militar sem Mistérios para Programadores COBOL
  2. Prólogo — O Chamado do Guardião
  3. Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
  4. Capítulo II — Estratégia, Operação e Tática
  5. Capítulo III — A Cadeia de Comando
  6. Capítulo IV — Logística
  7. Capítulo V — As Muralhas Invisíveis
  8. Capítulo VI — Inteligência, Reconhecimento e Espionagem
  9. Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
  10. Capítulo VIII — Liderança, Moral e Disciplina
  11. Capítulo IX — Inovação, Evolução e o Futuro
  12. Capítulo X — O Legado do Engenheiro
  13. Capítulo XI — O Guardião Invisível
  14. Capítulo XII — A Fortaleza Invisível
  15. Capítulo XIII — Os Sentinelas da Madrugada
  16. Capítulo XIV — A Civilização Invisível
  17. Capítulo XV — Engenharia de Cerco
  18. Glossário IBM Z + Engenharia Militar
  19. Apêndice A — Correspondências Históricas e Técnicas
  20. Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
  21. Os 10 Animes Mais Emblemáticos Sobre Logística Militar
  22. Os 10 Animes Mais Emblemáticos Sobre Tática Militar
  23. Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
  24. Especial — Guerrilha Urbana
  25. Especial — Guerrilha no Campo e na Floresta
Bellacosa Mainframe — Arquivo de Engenharia Militar

Estratégia, disciplina, conhecimento, resiliência e continuidade aplicados aos sistemas que não podem parar.

quarta-feira, 5 de agosto de 2015

🧪🌈 Por que a Rainbow Sheep virou símbolo de DEBUG na indústria?

 


🧪🌈 Por que a Rainbow Sheep virou símbolo de DEBUG na indústria?

A resposta curta:
👉 Porque ela é impossível de ignorar, impossível de esquecer e perfeita para sinalizar “isso aqui não deveria estar acontecendo”.
A resposta longa — e saborosa — vem agora.


🌈🐑 1) A ORIGEM — dos animes para os logs

A Rainbow Sheep surgiu como gag visual em animes nonsense dos anos 90 e 2000.
Era usada assim:

  • Quando um personagem bugava emocionalmente → aparecia uma ovelhinha arco-íris pulando.

  • Quando uma mágica dava errado → a ovelha explodia em glitter.

  • Quando a lógica do universo quebrava → lá vinha ela, balindo em reverb.

E isso fez dela um símbolo muito claro de:

“algo saiu totalmente do normal e o universo está tentando avisar.”

Adivinha quem adorou isso?
👨‍💻👩‍💻 — Os devs, claro.




🧩 2) Como ela entrou na área de tecnologia

Por volta de 2010–2013, memes japoneses começaram a aparecer em:

  • Engines de game dev

  • Ferramentas internas de QA

  • Dashboards de times de teste

  • Scripts de build (sobretudo no mundo open source)

A Rainbow Sheep passou a ser usada como:

🐑💥 “Unexpected State Marker”

Um placeholder visual altamente chamativo para estados impossíveis:

  • Variável que nunca deveria ser nula

  • Loop que nunca deveria ser alcançado

  • Case default que não devia existir

  • Retorno que matematicamente é impossível

  • Condição que só dispara se o programador “fez c@#$%”

O dev que coloca isso pensa:

“Se isso aparecer… algo MUITO errado aconteceu.”

É o equivalente animado do clássico:
DISPLAY "WTF?!" do COBOL ou RAISE HELL no Python.


📟 3) E no Mainframe, Bellacosa?

Apareceu também!
Sim, senhor(a)!

Programadores colocavam mensagens internas tipo:

DISPLAY "RAINBOW SHEEP EVENT DETECTED - CHECK INDEXES"

ou
quando faziam debug de tabelas OCCURS e SEARCH:

IF IDX > TABLE-SIZE MOVE "RAINBOW-SHEEP" TO ERROR-FLAG END-IF

Surgiu até um apelido:

🐑🌈 “Ovelha de Dump”

Quando o programador via a string no SYSOUT, já sabia:
“algum júnior estourou o array de novo.”


🧠 4) Por que ela funciona tão bem como símbolo de debug?

1. Hipervisual

Cores saturadas chamam atenção no meio de um log cinza.

2. Impossível de confundir

Nada mais parece uma ovelha arco-íris psicodélica.

3. Memorável

Você lembra ONDE usa, quando usa e POR QUE apareceu.

4. Carrega humor

Ajuda devs a não enlouquecerem em dias de troubleshooting pesado.

5. Breakpoint Cultural

É um símbolo universal de “a lógica foi para o espaço”.
Dev de qualquer linguagem entende intuitivamente.


🔍 5) Curiosidades Bellacosa

  • 🎨 Primeiras artes usadas vinham de imageboards japoneses dos anos 2000.

  • 🐑 Alguns estúdios de anime realmente usavam ela para marcar frames quebrados internamente.

  • 🖥 A Unity e Godot tinham scripts compartilhados entre devs com ‘RainbowSheep()’ como função de debug.

  • 🌈 Virou até sticker em notebooks de testers profissionais.

  • 🔥 Há uma versão “Dark Mode” — a Black Rainbow Sheep, usada para bugs críticos em produção.


🥚 6) Easter Egg estilo Bellacosa

Se você criar no seu código:

EVALUATE TRUE WHEN IMPOSSIVEL DISPLAY "🌈🐑 SYSTEM LOGIC BREACHED" END-EVALUATE

Pode ter certeza:
25 anos depois alguém vai te agradecer… ou te xingar.
Ambos fazem parte da tradição. 😄


⭐ 7) Em resumo

A Rainbow Sheep virou símbolo de DEBUG porque representa:

O impossível, o inesperado, o bug que não devia existir — e que, por isso mesmo, precisa ser visto imediatamente.

E ainda deixa tudo mais leve.
Porque debugging já é difícil demais sem humor. 😉


segunda-feira, 3 de agosto de 2015

📜 As Crônicas da Berinjela Cósmica — Ibitinga, o Sítio e o Festival Gastronômico do Destino


📜 As Crônicas da Berinjela Cósmica — Ibitinga, o Sítio e o Festival Gastronômico do Destino

Ao estilo Bellacosa Mainframe, para o arquivo eterno do El Jefe Midnight.


Há histórias na vida que não seguem lógica, não pedem licença e nem esperam nosso paladar crescer.
Simplesmente acontecem.
E uma delas é o Festival da Berinjela de Ibitinga.

Na mesma linha temporal nebulosa — aquele buffer misterioso entre 1978 e 1980 — estávamos de novo no sítio da família amiga do meu pai. Um cenário bucólico, com cheiro de lenha queimando, milho secando no paiol, galinhas ciscando e a eterna brisa quente do interior.

Meu pai, todo animado, anunciou:

— “Minha mãe, dona Anna, vai nos visitar!”

Os sitiantes iluminaram o rosto como NPCs recebendo uma quest rara.

— “E o que ela gosta de comer?”

Meu pai, naquele momento inocente e desprevenido, olhou em volta.
Viu a horta.
E lá estavam: fileiras intermináveis de berinjelas roxas.

E soltou a sentença que mudaria o menu do universo:

— “Ah, minha mãe gosta de berinjela.”

Pronto.
Era o prenúncio do caos culinário.


🍆 O Dia da Grande Beringelada

Chegou o fim de semana.
Todos embarcamos no lendário Fusquinha vermelho, sacolejando na estrada de terra, entre sítios, porteiras, pastos e aquele cheiro de mato quente que entra pelas janelas.

Ao chegar, a cena parecia saída de um anime culinário:

Uma mesa colossal.
E tudo — absolutamente tudo — era feito com berinjela.

A dona da casa tinha se dedicado como uma chef Michelin do campo, e produziu um cardápio digno de ritual:

  • berinjela frita,

  • berinjela à milanesa,

  • berinjela ensopada,

  • berinjela grelhada,

  • berinjela com queijo,

  • berinjela recheada,

  • berinjela à parmegiana,

  • conserva de berinjela,

  • berinjela agridoce,

  • salada de berinjela,

  • e mais umas três variações místicas que desafiam a própria memória RAM.

Era uma orgia gastronômica berinjelesca, uma overdose vegetal pré-internet, pré-globalização e pré-trauma infantil reconhecível.


🐔 O Contrabando Gastronômico Sob a Mesa

Eu e Vivi, jovens padawans do paladar, não muito fãs do vegetal…
tivemos uma ideia brilhante: usar as galinhas como parceiras do crime.

Elas ciscavam sob a mesa, inocentes, ávidas, prontas.

E nós, discretos, diplomáticos, solidários:

— ops
pluft
— lá ia uma rodela de berinjela direto para o papo da galinha

O avianato agradecia.
Nosso paladar também.

Mas, justiça seja feita:
o pão caseiro, feito no forno à lenha, era um poema.
E a comida preparada no fogão do rancho tinha aquele sabor único que só existe quando a lenha canta, crepita e abençoa cada panela.

O carinho da família amiga era palpável.
Era mais que comida — era comunhão, era ritual, era acolhimento.


🐥 Entre Pintinhos, Poeira e Frutas do Pé

O resto do dia foi um daqueles típicos capítulos de infância rural:

  • correr atrás das galinhas,

  • acariciar pintinhos,

  • subir em árvores,

  • comer fruta direto do pé,

  • brincar na terra vermelha quente,

  • escutar histórias dos adultos,

  • sentir o tempo passar mais devagar.

Coisa simples.
Coisa que cura.
Coisa que marca.



🚽 O Episódio da Fossa (Prévia do Próximo Capítulo)

E já que estamos falando de autenticidade rural…

Ir ao banheiro na roça era apenas para os fortes.
Latrina.
Buraco.
Fossa profunda.
Cheiros indescritíveis.
Medos primitivos.

Mas isso, caro leitor…
tem seu próprio capítulo reservado, digno de trilogia.

sexta-feira, 31 de julho de 2015

🔥 JCL no z/OS V2R1 — o veterano entra oficialmente na era moderna

 

Bellacosa Mainframe apresenta JCL V2R1 Job Control Language

🔥 JCL no z/OS V2R1 — o veterano entra oficialmente na era moderna



📅 Datas importantes

  • Release (GA): julho de 2015

  • Final de suporte IBM: 30 de setembro de 2020

O z/OS V2R1 é o divisor de águas:
o mainframe entra de vez na era do híbrido,
e o JCL passa a conviver oficialmente com APIs, Linux, Java e DevOps — sem mudar uma vírgula.


🧬 Contexto histórico

Até o z/OS V1.x, o discurso era “modernização controlada”.
No V2R1, a IBM muda o tom:

  • z/Architecture madura

  • Cloud híbrida começando a ganhar corpo

  • Linux on Z crescendo

  • Middleware (CICS, MQ, DB2) totalmente integrado

  • Batch deixa de ser “janela noturna”

E no centro de tudo isso…

👉 o JCL segue sendo o contrato supremo de execução.

Bellacosa resumiria assim:

“O mundo ficou moderno.
O JCL já era.”



✨ O que há de novo no JCL no z/OS V2R1

Aqui está a elegância do V2R1:

❌ Nenhuma ruptura
✅ Consolidação total

🆕 1. JCL como pilar do batch moderno

No V2R1:

  • Batch passa a rodar 24x7

  • Jobs são acionados por:

    • schedulers corporativos

    • aplicações distribuídas

    • eventos externos

👉 O JCL deixa de ser “script” e vira infraestrutura operacional.


🆕 2. IF / THEN / ELSE vira padrão (não mais exceção)

  • Menos abuso de COND

  • Mais clareza no fluxo

  • Menos erro humano

O JCL começa a parecer… código bem escrito.


🆕 3. JES2 e DFSMS mais previsíveis

  • Spool mais estável

  • Melhor gerenciamento de workloads

  • Storage cada vez mais orientado a políticas

O resultado?
👉 menos tuning artesanal, mais previsibilidade.


🔧 Melhorias percebidas no dia a dia

✔ Batch rodando fora da madrugada
✔ Jobs mais legíveis
✔ Menos “JCL mágico” herdado
✔ Mais padronização
✔ RC tratado com mais seriedade

Nada mudou na linguagem.
Tudo mudou no modo de uso.


🥚 Easter Eggs (para mainframer raiz)

  • 🥚 JCL escrito no OS/390 rodando feliz no V2R1

  • 🥚 IEFBR14 continuava sendo usado sem culpa

  • 🥚 Comentários no JCL mais antigos que o próprio z/OS 😅

  • 🥚 O erro clássico seguia firme:

    • RC ignorado

    • DISP mal planejado

    • dataset em uso

👉 Compatibilidade é uma faca de dois gumes.


💡 Dicas Bellacosa para JCL no z/OS V2R1

🔹 Comece a pensar JCL como código corporativo
🔹 Padronize nomes de jobs e passos
🔹 Use IF / THEN / ELSE sempre que possível
🔹 Documente decisões históricas no JCL
🔹 Leia JESMSGLG com atenção religiosa

Esse job não é seu.
Você só é o guardião da vez.


📈 Evolução do JCL até o z/OS V2R1

EraPapel do JCL
OS/360Controle batch
MVSAutomação
OS/390Base corporativa
z/OS V1.xOrquestração
z/OS V2R1Entrada oficial no mundo híbrido

👉 No V2R1, o JCL cruza a fronteira do “legacy” e entra no moderno sem pedir permissão.


📜 Exemplo de JCL “cara de V2R1”

//BELLV21 JOB (ACCT),'JCL z/OS V2R1', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* //* JOB PENSADO PARA BATCH 24x7 //* //STEP01 EXEC PGM=COREPROC //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.WORK.TEMP SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Esse JCL pode rodar de dia, de noite ou por evento.
Ele não pergunta. Ele executa.”


🧠 Comentário final

O JCL no z/OS V2R1 representa o momento em que o mainframe diz ao mercado:

🔥 “Não vou mudar minha base para parecer moderno.
Vou integrar o moderno à minha base.”

E o JCL, silencioso como sempre, aceita a missão.

JCL não é linguagem do passado.
JCL é compromisso com o resultado.

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...