terça-feira, 24 de fevereiro de 2026

🎩 Mainframe, Meu Caro… Ou o Clube do Blazer Cinza?

 

Bellacosa Mainframe pensando sobre o rigido acesso ao ambiente Mainframe, regras secretas e barreiras a entrada.

🎩 Mainframe, Meu Caro… Ou o Clube do Blazer Cinza?

Permita-me começar com a devida elegância britânica:
o mainframe não é para amadores.

Mas, convenhamos… também não precisa ser para masoquistas.

Há um fenômeno curioso que afasta jovens talentos do mundo Z. Não é a complexidade do JCL. Não é o COBOL. Muito menos o misticismo do CICS ou do DB2.

É o ambiente.

Sim, meu caro leitor. O ambiente.


🎩 1. O Dress Code que Assusta Mais que um S0C7

Eles criam startups milionárias usando camiseta de banda.

E então descobrem que, em certos ambientes mainframe, o traje ainda é quase litúrgico.

  • Camisa social.

  • Sapato polido.

  • Blazer no verão de 34 graus.

  • Ar condicionado digno da Antártida.

Para quem ganha salário inicial modesto, vestir-se “adequadamente” não é apenas estética — é investimento pesado.

Pergunta elegante, porém direta:

Será que o código compila melhor de gravata?


💰 2. O Salário Inicial e o Paradoxo da Experiência

O mercado repete:
“Precisamos de profissionais de mainframe.”

Mas quando o jovem aparece:

— “Experiência mínima de 3 anos.”
— “Vivência em ambiente produtivo crítico.”
— “Conhecimento profundo de legado bancário.”

Ora, excelência exige oportunidade.

O problema não é a régua alta.
O problema é não haver escada.

E aqui entra outro elemento delicado…


🤝 3. O Padrinho Invisível

Em muitos ambientes, entrar no mainframe ainda funciona como um clube inglês do século XIX:

  • Você precisa conhecer alguém.

  • Alguém precisa confiar em você.

  • Alguém precisa abrir a porta.

Sem padrinho ou madrinha técnica, o jovem talento permanece do lado de fora, admirando o prédio.

Isso não é elitismo consciente.
É inércia cultural.

Mas o efeito é o mesmo.


🏢 4. O Ambiente Cinzento e a Cultura do “Não Pode”

Mainframe é auditoria.
Mainframe é rastreabilidade.

Perfeito.

Mas às vezes o discurso vira:

  • Não pode isso.

  • Não pode aquilo.

  • Precisa abrir chamado.

  • Precisa autorização.

  • Precisa aprovação.

  • Precisa justificar.

O jovem desenvolvedor, acostumado a deploy contínuo, olha para isso e pensa:

“Eu vim programar ou pedir permissão para respirar?”

Governança é vital.
Mas excesso de burocracia mata entusiasmo.


Onibus, trens e metro lotados chegar cansando antes de começar a jornada

🚆 5. A Distância Física do Centro de Decisão

Os grandes ambientes Z estão, via de regra:

  • Em centros financeiros.

  • Em polos corporativos.

  • Em prédios monumentais.

O que isso significa?

  • 2h de transporte público.

  • Combustível caro.

  • Estacionamento impraticável.

  • Vida pessoal comprimida.

Enquanto isso, o desenvolvedor distribuído trabalha remoto, de qualquer lugar do mundo.

A pergunta inevitável surge:

Se o sistema roda no data center, por que o cérebro precisa rodar no trânsito?


🦁 6. A Fatia do Leão

E aqui entramos no ponto mais sensível — tratado com elegância, mas sem ingenuidade.

Consultorias intermediam.
Negociam contratos robustos.
Recebem valores consideráveis.

Mas o profissional na ponta muitas vezes recebe uma fração modesta daquilo que é faturado.

Isso cria:

  • Desmotivação.

  • Sensação de injustiça.

  • Falta de pertencimento.

O jovem percebe rapidamente quando é custo ou quando é investimento.


🤡 7. E o salario óhhhhh

Há algo quase shakespeariano na ironia: enquanto o mainframe sustenta bilhões em transações e preserva a espinha dorsal financeira do mundo, o poder aquisitivo de muitos de seus guardiões encolhe discretamente, ano após ano. 

O salário médio já não acompanha o custo do terno, do transporte, da atualização técnica constante. Trabalha-se com sistemas de altíssima criticidade, mas negocia-se remuneração como se fosse peça de museu. Não é decadência tecnológica — é desalinhamento de valor. E nenhum império se sustenta por muito tempo quando seus pilares começam a sentir o peso sem a devida recompensa.


🐎 8. Quando o projeto sai dos trilhos.

Há algo quase teatral — e não no bom sentido — no desfile dos agentes comerciais que adentram o salão com promessas mirabolantes, PowerPoints reluzentes e prazos heroicos assinados com tinta alheia. Vendem modernização instantânea, garantem integração mágica, juram dominar a ferramenta que mal pronunciam corretamente. 

Comprometem-se com cronogramas que fariam corar o próprio calendário gregoriano e, numa aritmética digna de fábula corporativa, acreditam que nove gestantes produzirão um bebê em um mês. Ao primeiro sopro de realidade, o “babado” desce elegante — porém pesado — para a equipe terceirizada, que herda prazos surreais, jornadas de doze horas e a eterna ladainha: “é a reta final, vamos dar o gás para o deploy”. 

O projeto termina, os aplausos sobem ao palco executivo, e o profissional, exausto, descobre que sua participação era temporária — quase ornamental — encerrada com um discreto, porém firme, chute administrativo.

🎯 Então, o que fazer?

Agora vem a parte nobre da conversa.
Criticar é fácil. Reformar é aristocrático.

1️⃣ Modernizar a Cultura, Não Apenas a Tecnologia

  • Dress code mais flexível.

  • Avaliar por entrega, não por aparência.

  • Ambiente menos sisudo e mais colaborativo.

Elegância não exige rigidez.


2️⃣ Criar Trilhas Reais de Entrada

  • Programas trainee específicos de mainframe.

  • Mentorias formais.

  • Labs práticos (inclusive com ambientes como Hercules).

  • Parcerias com universidades.

O talento não nasce com RACF configurado.

Ele precisa de oportunidade.


3️⃣ Trabalho Híbrido ou Remoto Estruturado

Se DevOps pode operar sistemas distribuídos remotamente,
o mainframe também pode evoluir seus modelos operacionais.

Segurança não é sinônimo de presença física.


4️⃣ Transparência na Cadeia de Valor

Consultorias são importantes.
Mas valorização real do especialista cria retenção.

Retenção cria excelência.
Excelência mantém o mainframe vivo.


5️⃣ Tornar o Mainframe Aspiracional

Hoje o jovem quer:

  • Impacto

  • Propósito

  • Reconhecimento

  • Crescimento rápido

E adivinhe?

Mainframe entrega tudo isso.

Mas alguém precisa contar essa história com paixão —
não apenas com manuais.


☕ Conclusão ao Estilo Bellacosa

Meu caro…

O problema do mainframe nunca foi tecnologia.

Foi narrativa.
Foi cultura.
Foi ambiente.

O Z não é antiquado.

Antiquada pode ser a forma como o apresentamos.

Se queremos novos talentos, precisamos:

  • Abrir portas.

  • Reduzir barreiras simbólicas.

  • Atualizar a mentalidade.

  • Valorizar quem executa.

O mainframe é majestoso.

Mas majestade não precisa ser sisudez.

Pode ser grandeza com leveza.

E talvez — apenas talvez — o próximo grande arquiteto Z esteja neste exato momento escolhendo entre:

  • Uma startup de camiseta
    ou

  • Um data center de blazer.

A decisão é nossa.

🎩☕ PS: Isso que nem entrei nos pontos neuvragicos dos deploys, tercereiziação, quarteirização, falta de documentação e em algumas instalaçoes com a aposentadoria de antigos pratas da casa, perde-se o conhecimento. Um outro fato dolorozado e que de tempos em tempos existem os cortes dolorosos, membro com altos salarios ficam sobre escrutinio, pressão e caçada de pelo em ovo.

Muitas das vezes ocorre o bornout e o membro se desliga voluntario. Mas isso já é polemico demais, fica para uma proxima rodada. Concorda comigo? Qual a sua opinião? Tem alguma inverdade ou exagerado? Como é sua visao do mundo DEV na Stack Mainframe, agora hibrida com Linux, Unix, Ansilnle, Rest, Open APi2, OpenApi3, Red Hat, OpenShift e muitas novidades culminando com o Zowe, Git e Visual Studio.


https://www.linkedin.com/posts/vagnerbellacosa_ibm-mainframe-peopleware-ugcPost-7432160677529722880-9oeF?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAF2qx0B5Ef0IGUpO8f7SxDHV-EQ5-EMG54

https://www.linkedin.com/pulse/mainframe-meu-caro-ou-o-clube-do-blazer-cinza-vagner-bellacosa-sueef/

:)

segunda-feira, 23 de fevereiro de 2026

📘 50 Erros que Você Pode Capturar com IF em JCL

 

Bellacosa Mainframe apresenta 50 erros em processo batch e maneira de capturar via if /cond

Controle Condicional de Verdade no z/OS

Por Vagner Bellacosa — El Jefe Midnight Lunch

Salve jovem padawan a vida no mundo batch não é facil. Pensando nisso, seus problemas acabaram, parcialmente, no artigo de hoje, fiz um apanhado, peguei um saco de gatos, misturei com aquele tempero nosso. Coloquei algumas dicas de amarração com return cond, conds e ifs. em resultado apresento a você

Se você ainda usa IF em JCL apenas para testar RC > 8, você está usando uma Ferrari para ir até a padaria da esquina.

O IF/THEN/ELSE/ENDIF no z/OS é uma das ferramentas mais poderosas do processamento batch moderno. Ele permite capturar desde simples return codes até falhas estruturais complexas dentro de procedures.

Neste artigo, vou listar 50 situações reais de produção que podem ser tratadas com IF em JCL — com explicação prática, mentalidade de produção e visão arquitetural.

Prepare o café ☕ — vamos para o campo de batalha.

Seus problemas acabaram



🧠 Primeiro: O que o IF consegue testar?

O IF pode avaliar:

  • Return codes (RC)

  • ABENDs

  • ABENDs específicos

  • Steps executados ou não

  • Steps dentro de procedures

  • Condições combinadas (AND / OR)

  • Variáveis simbólicas

  • Fluxos aninhados (nested IF)

Agora vamos aos 50 cenários.


🔴 PARTE 1 — ABENDs Específicos (Sistema)

Captura via:

IF ABENDCC = Sxxx THEN
  1. S806 — Programa não encontrado (STEPLIB incorreto)

  2. S0C7 — Erro numérico COBOL (Data exception)

  3. S0C4 — Violação de memória

  4. S0C1 — Instrução inválida

  5. S913 — Falha de autorização RACF

  6. S878 — Falta de memória virtual

  7. S80A — Falta de storage abaixo da linha

  8. S837 — Falta de espaço em disco

  9. S522 — Timeout de CPU

  10. Uxxxx — User abend específico da aplicação

Uso típico: gerar dump, enviar notificação, disparar rollback.


🔴 PARTE 2 — Qualquer ABEND

IF ABEND THEN
  1. Capturar qualquer falha anormal

  2. Acionar rotina de recovery

  3. Enviar alerta para operações

  4. Forçar rollback

  5. Gerar log especial

O IF permite separar erro técnico de erro lógico (RC alto).


🔴 PARTE 3 — RC de Step Específico

IF STEP1.RC NE 0 THEN
  1. RC diferente de zero

  2. RC maior que 4 (warning elevado)

  3. RC igual a 4 (tratamento especial de warning)

  4. RC igual a 8

  5. RC igual a 12

  6. RC maior que 16

  7. RC entre 4 e 8

  8. RC fora da faixa esperada

  9. RC crítico mas sem abend

  10. RC inesperado para aquele step

Permite tratamento diferenciado por programa.


🔴 PARTE 4 — RC Global (último step executado)

IF (RC > 8) THEN
  1. Falha acumulada

  2. Erro lógico geral

  3. Inconsistência de processamento

  4. Validação negativa

  5. Resultado parcial não aceitável

Esse é o controle clássico de continuidade de fluxo.


🔴 PARTE 5 — Step Não Executado

IF ¬STEP1.RUN THEN
  1. Step bypassado por COND

  2. Step ignorado por IF anterior

  3. Step pulado por restart

  4. Step cancelado por lógica condicional

  5. Step não iniciado por erro estrutural

Excelente para auditoria e rastreabilidade.


🔴 PARTE 6 — Step Executado

IF STEP1.RUN THEN
  1. Confirmar execução de etapa crítica

  2. Validar dependência

  3. Garantir execução de PROC

  4. Verificar step condicional

  5. Auditoria de fluxo

Muito usado em ambientes com compliance.


🔴 PARTE 7 — Condições Combinadas (AND)

IF (RC > 4 & RC < 16) THEN
  1. Intervalo de erro médio

  2. Dupla condição obrigatória

  3. RC alto e step executado

  4. Falha parcial e dependência satisfeita

  5. Tratamento gradual por severidade

Controle refinado de severidade.


🔴 PARTE 8 — Condições Alternativas (OR)

IF (RC = 8 | RC = 12) THEN
  1. Dois códigos críticos específicos

  2. Warning ou erro leve

  3. Dois tipos diferentes de inconsistência

  4. Cenários alternativos aceitáveis

  5. Multi-falhas com mesma ação corretiva

Permite lógica flexível sem duplicar código.


🔥 EXTRA — Dentro de Procedures

IF STEP1.PROCSTEP.RC > 8 THEN

Controle granular dentro de PROCs reutilizáveis.

Ambiente corporativo pesado usa isso diariamente.


⚠ Limitações Importantes

  1. IF não executa após S122 ou S222 (cancelamentos externos).

  2. IF não roda se COND no JOB já tiver terminado o job.

  3. Todo IF precisa de ENDIF.

  4. RC final do job pode ser afetado por JOBRC.


🏛 Quando Usar IF em vez de COND?

CenárioMelhor escolhaLógica simplesCONDLógica estruturadaIFMúltiplos cenáriosIFControle de variável simbólicaIFClareza e manutençãoIF


🎯 Conclusão

O IF no JCL não é apenas um detalhe sintático.

Ele é:

  • Arquitetura de controle

  • Ferramenta de resiliência

  • Mecanismo de tratamento de falha

  • Base para automação robusta

  • Ponte entre aplicação e scheduler

Quem domina IF domina o fluxo batch.

EXEC STEP 
    │
    ▼
  ABEND ?
    │
    ├── S122/S222 → STOP
    │
    └── Outro ABEND
         │
         ├── Próximo STEP tem COND=EVEN ? → EXECUTA
         └── Senão → FLUSH
   │
   ▼
COND no JOB ?
   │
   ├── Verdadeiro → STOP JOB
   └── Falso → Continua
   │   
   ▼
  IF ?
   │
   ├── Verdadeiro → Executa bloco
   └── Falso → ELSE ou FLUSH
   │
   ▼
COND no EXEC ?
   │
   ├── Verdadeiro → FLUSH STEP
   └── Falso → Executa STEP

E no mundo mainframe, quem domina o fluxo… domina a produção.

🧠 Visual Mental Simplificado

ABEND crítico?
   ↓
COND JOB?
   ↓
IF?
   ↓
COND EXEC?
   ↓
Executa ou FLUSH
Esses abends me deixam louco

https://www.linkedin.com/pulse/50-erros-que-voc%C3%AA-pode-capturar-com-em-jcl-vagner-bellacosa-zqm8f