Como Não Se Perder no Mainframe (e Ainda Brilhar em Produção) ☕

 

Bellacosa Mainframe apresenta um manual de sobrevivencia para um padawan em mainframe

🔥 Manual de Sobrevivência do Programador COBOL Iniciante

Como Não Se Perder no Mainframe (e Ainda Brilhar em Produção) ☕

Entrar no mundo COBOL Mainframe é como desembarcar em uma usina nuclear em pleno funcionamento: tudo é estável, poderoso… e absolutamente implacável com erros.

Mas respire.

Milhões de profissionais passaram por isso antes — e sobreviveram muito bem 😄
Este é o guia que eu gostaria que todo iniciante recebesse no primeiro dia.

---

🧠 1) Entenda onde você está pisando

Você não está em um ambiente comum de desenvolvimento.

Aqui existem:

✔ Sistemas rodando há décadas
✔ Código crítico para negócios bilionários
✔ Processos batch noturnos gigantescos
✔ Auditoria pesada
✔ Zero tolerância para “gambiarras”

No Mainframe:

“Se funciona há 20 anos, mexa com extremo respeito.”

---

🖥️ 2) Domine o ecossistema antes da linguagem

COBOL sozinho não faz nada.
Você precisa entender o ambiente z/OS:

• TSO/ISPF

• JCL

• Datasetes

• JOBs batch

• SDSF

• Conceitos de spool

• Bibliotecas PDS/PDSE

Sem isso, você fica perdido mesmo sabendo programar.

---

📜 3) Aprenda a ler código antigo (muito antigo)

Grande parte do seu trabalho inicial será manutenção.

Você verá:

😅 Variáveis com nomes estranhos
😅 GO TO espalhado
😅 Comentários de 1989
😅 Copybooks gigantes
😅 Lógica de negócio implícita

Dica de ouro:

👉 Comece pelo fluxo principal (MAIN-LOGIC)
👉 Siga os PERFORMs
👉 Ignore detalhes até entender o todo

---

🧱 4) Respeite os padrões da empresa

Cada organização tem seu próprio guia de estilo.

Nunca chegue “modernizando tudo”.

Faça primeiro:

✔ Entenda o padrão local
✔ Copie o estilo existente
✔ Siga nomenclaturas
✔ Use templates corporativos

No Mainframe, consistência vale mais que criatividade.

---

🧮 5) Entenda arquivos — eles são o coração do batch

Processamento batch gira em torno de datasets.

Você precisa dominar:

• Sequential files

• VSAM

• Leitura e escrita

• EOF (fim de arquivo)

• Layouts de registro

• Controle de erro

Um erro de layout pode destruir dados sem aviso.

---

🔁 6) PERFORM é seu melhor amigo

Evite ao máximo:

🚫 GO TO
🚫 Lógica confusa
🚫 Saltos imprevisíveis

Prefira fluxo estruturado:

✔ PERFORM UNTIL
✔ PERFORM VARYING
✔ Parágrafos bem nomeados

Código previsível é código seguro.

---

🧠 7) Use nomes que contam a história

Bons nomes reduzem metade do esforço de manutenção.

Compare:

❌ X1, X2, VARA
✔ WS-SALDO-CONTA
✔ FL-FIM-ARQUIVO
✔ CNT-REG-LIDOS

Se alguém entende sem perguntar, você venceu.

---

📦 8) COPYBOOKs são contratos

Copybooks definem layouts compartilhados.

Mexer neles pode impactar dezenas ou centenas de programas.

Antes de alterar:

⚠ Verifique dependências
⚠ Consulte responsáveis
⚠ Avalie impacto sistêmico

Alterar copybook sem análise é receita para incidente.

---

🛑 9) Teste como se produção dependesse disso

(porque depende)

Um JOB errado pode:

💸 Gerar pagamentos indevidos
📉 Corromper base de dados
📊 Produzir relatórios incorretos
🚨 Acionar auditoria

Teste cenários:

✔ Arquivo vazio
✔ Dados inválidos
✔ Limites máximos
✔ Exceções

---

📊 10) Leia o output do JOB — sempre

Após rodar, verifique:

• Return codes

• Mensagens

• Contagem de registros

• Warnings

• Dumps

Nunca assuma que “deu certo”.

---

🧯 11) Aprenda a interpretar ABENDs

ABEND não é fracasso — é informação.

Códigos como:

• S0C7 → erro numérico

• S0C4 → acesso inválido de memória

• S013 → problema de arquivo

Dominar isso acelera sua evolução absurdamente.

---

🤝 12) Faça amizade com operadores e analistas experientes

Mainframe é uma cultura colaborativa.

Operadores conhecem o comportamento real dos JOBs.
Veteranos conhecem os sistemas por dentro.

Uma conversa pode economizar dias de tentativa e erro.

---

⏳ 13) Tenha paciência — aprendizado é cumulativo

No início, tudo parece lento:

• Compilar leva tempo

• JOBs entram em fila

• Ambientes são controlados

• Mudanças passam por aprovação

Mas isso existe para garantir estabilidade.

---

☕ Filosofia final de sobrevivência

Ser programador COBOL não é apenas saber sintaxe.

É ser guardião de sistemas críticos.

Você está mantendo a infraestrutura invisível que faz o mundo financeiro e governamental funcionar.

“Se ninguém percebe seu trabalho, provavelmente está perfeito.”

---

⭐ Conclusão

O iniciante que sobrevive no Mainframe não é o mais brilhante — é o mais disciplinado.

Com o tempo, você descobrirá algo surpreendente:

👉 COBOL não é ultrapassado
👉 É simplesmente implacavelmente confiável

E dominar esse ambiente abre portas raras e valiosas.

 

Bellacosa Mainframe apresenta CI CD e DEVOPS 

🚀 CI/CD & DevOps

Uma análise Bellacosa Mainframe (com história, bastidores e verdades inconvenientes)

“Automatize tudo. O que sobrar, automatize de novo.”
— Filosofia não oficial do DevOps

CI/CD não é moda, não é ferramenta, não é YAML bonito no GitHub.
É mudança cultural, redução de sofrimento humano e, principalmente, fim do deploy manual de sexta-feira às 18h.

---

🧠 CI e CD: irmãos, não gêmeos

🔁 Continuous Integration (CI)

CI nasceu para resolver um problema clássico:

“Funciona na minha máquina.”

CI é integração contínua de código, feita com:

• branches curtas

• commits frequentes

• pull requests pequenos

• testes automáticos

👉 Resultado?
Menos conflito, menos retrabalho e menos ódio entre desenvolvedores.

📌 Fases clássicas da CI

• Plan – o que vamos fazer

• Code – escrever o código

• Build – compilar / empacotar

• Test – validar automaticamente

💡 Dica Bellacosa:
Se seu pipeline de CI demora mais que um café passado na hora… algo está errado ☕

---

🚚 Continuous Delivery (CD)

CD entra depois da CI, quando o código já funciona.

CD garante que:

• o software esteja sempre pronto para produção

• o deploy seja repetível, confiável e sem drama

• humanos não fiquem clicando “Next, Next, Finish”

📌 Fases clássicas da CD

• Release – versionamento

• Deploy – entrega automatizada

• Operate – operação e monitoramento

⚠️ Atenção:
CD ≠ Continuous Deployment

• Delivery: pronto para produção

• Deployment: vai direto para produção (sem pedir bênção)

---

🧬 CI/CD como código: o YAML que manda na sua vida

Quando pipelines viram código:

• versionamento acontece

• rollback fica fácil

• auditoria fica feliz

🧾 GitHub Actions

📅 Lançamento: novembro de 2019

• Já vem em todo repositório GitHub

• Usa YAML

• Marketplace recheado de actions prontas

📂 Estrutura clássica:

.github/
 └── workflows/
      └── pipeline.yml

💬 Comentário Bellacosa:
“Pipeline que não está versionado é script secreto de sysadmin disfarçado.”

---

🧑‍🤝‍🧑 Social Coding: menos ego, mais qualidade

CI/CD só funciona bem quando:

• pull requests são pequenos

• revisão é colaborativa

• erro vira aprendizado, não caça às bruxas

📈 Benefícios reais:

• código melhor

• menos bugs em produção

• mais confiança no deploy

🧠 Curiosidade:
Empresas que adotam CI de verdade fazem deploy dezenas de vezes por dia.
Quem não adota… faz change freeze 😬

---

🧱 Infraestrutura como Código (IaC)

📅 Conceito popularizado: ~2011 (com Puppet, Chef, depois Terraform)

IaC permite:

• subir ambientes em minutos

• destruir tudo e recriar sem chorar

• versionar infraestrutura

💡 Dica de ouro:
Se você não consegue recriar seu ambiente do zero… você não controla seu ambiente.

---

⚙️ Tekton: CI/CD raiz, Kubernetes feelings

📅 Lançamento: 2018 (Knative Build → Tekton)

Tekton é:

• CI/CD nativo Kubernetes

• Declarativo

• Baseado em CRDs

🧩 Conceitos-chave

• Task – unidade de trabalho

• Pipeline – encadeamento

• Step – comando

• Trigger – evento externo

• PipelineRun – execução real

💬 Fofoquinha técnica:
Tekton é poderoso, mas não é para iniciantes.
Quem aprende… vira referência. Quem não aprende… chama de “complicado demais”.

---

🔄 GitOps & Argo CD: Git manda, cluster obedece

📅 Argo CD: 2018

GitOps segue um princípio simples:

“Se não está no Git, não existe.”

Argo CD:

• observa o Git

• compara com o cluster

• reconcilia automaticamente

🔥 Easter Egg GitOps:
Deletou algo no cluster manualmente?
O Argo recria… sem pedir desculpa 😈

---

☁️ OpenShift Pipelines & GitOps

OpenShift:

• integra Tekton nativamente

• facilita CI/CD corporativo

• conversa bem com Argo CD

📌 Padrões GitOps suportados:

• On-Cluster Reconciler

• External Reconciler

💬 Comentário Bellacosa:
Mainframe tinha controle, rastreabilidade e auditoria antes de ser cool.
DevOps só deu nome bonito.

---

🔐 Compliance contínua: segurança sem freio de mão

Pipeline moderno inclui:

• scan de código

• scan de imagem

• gestão de segredos

• trilha de auditoria

💡 Dica de sobrevivência:
Segurança manual não escala.
Compliance contínua sim.

---

🧨 Verdades inconvenientes (Bellacosa Edition)

• Ferramenta não salva cultura ruim

• CI quebrado diariamente não é CI

• Pipeline lento é gargalo oculto

• Deploy manual é dívida técnica

• YAML sem comentário é armadilha futura

---

🧠 Conclusão Bellacosa Mainframe

CI/CD não é sobre:
❌ Jenkins
❌ GitHub Actions
❌ Tekton
❌ Argo CD

É sobre:
✅ previsibilidade
✅ automação
✅ qualidade
✅ confiança
✅ dormir tranquilo após o deploy

“O melhor deploy é aquele que ninguém percebe.”

 

Bellacosa Mainframe fala sobre restart em programa cobol mainframe

🔄 COBOL Batch no Mainframe: Checkpoint, Reprise e o Restart que salva a madrugada

“Batch não cai. Batch desmaia… e você tem que acordar ele do jeito certo.” ☕🧾🕒

No mundo distribuído, o povo reinicia “do zero” e chama isso de solução.
No Mainframe, isso é quase uma confissão de pecado técnico.

Quando dá ruim em batch, a pergunta não é “por que parou?” — isso é assunto pro pós-mortem.
A pergunta certa, ainda na especificação, é:

👉 Como eu reinicio?
👉 De onde eu reinicio?
👉 E o que eu garanto que não vai duplicar / corromper / relançar?

Bem-vindo ao trio de respeito:
✅ checkpoint
✅ reprise (restart)
✅ reposicionamento (arquivo/DB2)

---

🧠 Checkpoint: o “save game” do batch (só que aqui vale dinheiro)

Checkpoint não é “vamos salvar porque sim”. É um ponto de consistência.

Ele serve pra:

• memorizar onde o processamento estava (fase/etapa)

• guardar posições de leitura (arquivos sequenciais, VSAM, cursores/chaves DB2)

• fechar uma unidade lógica consistente (commit/rollback bem amarrado)

• permitir retomada sem retrabalho e sem “efeito duplicado”

📌 Tradução Bellacosa:

Checkpoint é onde você consegue provar pro auditor que não inventou saldo no escuro.

⚠️ O pecado mortal: checkpoint mal posicionado

Checkpoint ruim é pior que nada, porque ele te dá uma falsa sensação de segurança.

Não coloque checkpoint:

• no meio de uma atualização crítica

• antes de terminar uma consistência lógica

• em cada registro “porque sim” (CPU chorando, log estourando, IRLM te olhando feio)

Coloque checkpoint:

• depois de um bloco lógico fechado (ex.: lote de N registros com commit)

• quando “o mundo faz sentido” (estado consistente)

• antes de uma parte custosa, mas não no meio da cirurgia

---

♻️ Reprise (Restart): o batch voltando “com memória”

Reprise é o batch saber voltar sem refazer o que já foi feito e sem duplicar o que não pode duplicar.

Ela é necessária especialmente quando:

• o batch é longo (madrugada inteira)

• tem DB2 update (conta, saldo, lançamento, baixa, contabilização)

• o negócio não aceita “roda de novo e vê no que dá”

• existe risco de duplicidade (dois lançamentos iguais = fogo no parquinho)

📌 Restart não é só “rodar outra vez”.
Restart é retomar a transação do negócio, com rastreabilidade.

---

🧷 Reposicionamento: o detalhe que separa homem de menino

Restart sem reposicionamento é “restart de brincadeira”.

Você precisa voltar exatamente:

• no registro correto do arquivo

• na chave correta do VSAM

• no ponto certo do cursor DB2 (na prática: reiniciar lógica por chave/estado salvo)

🎯 O batch tem que saber:

• qual fase estava executando

• qual registro/chave estava sendo processado

• qual unidade de commit já foi confirmada

• qual parte não pode repetir

---

🧩 Arquitetura clássica de batch com reprise “de respeito”

Um ciclo bem resolvido (a operação agradece):

1. Inicialização / parâmetros

2. Validações

3. Detecta reprise (rodada normal ou restart?)

4. Carrega checkpoint (fase + posição + chaves)

5. Reposiciona entradas (arquivo/DB2)

6. Loop principal

   • regra de negócio

   • atualização (DB2/arquivos)

   • commit por unidade lógica

   • checkpoint em pontos definidos

7. Finalização

8. “Checkpoint final” (término normal)

📌 Easter egg de produção:

Se você não tem “checkpoint final de sucesso”, vai ter madrugada com restart de batch que já terminou — e ninguém acredita até acontecer.

---

🧨 O vilão silencioso: duplicidade

O inferno do batch não é “parar”.
O inferno é parar depois de atualizar metade.

Por isso, todo batch com reprise tem que decidir:

• vou garantir idempotência? (rodar de novo não duplica)

• vou garantir commit controlado? (unidades fechadas)

• vou guardar marcador de processado? (chave/flag/tabela de controle)

✅ Padrões usados:

• Tabela de controle com status por chave/lote

• Commit a cada N registros (N definido por volume, log, tempo)

• Chave de negócio + verificação (“já processei isso?”)

• Writes “safe” (criar saída nova e só no final fazer swap/rename)

---

📂 “Nem todo batch precisa de reprise” (mas todo batch precisa de juízo)

Batch que só:

• lê arquivo

• gera relatório

• faz sorting

• produz uma saída recriável

…muitas vezes reexecutar resolve.

Só que:

• nunca reexecute “por cima” de saída velha sem estratégia

• garanta limpeza/geração atômica (work datasets → output final)

📌 Dica prática:

Use datasets temporários e só “promova” pro nome final no fim. Batch que morre não deixa meia saída fingindo que tá certa.

---

🧾 Dicas Bellacosa de restart que evitam velório

• Checkpoint = fase + posição + contexto. Não guarde só o número do registro; guarde o porquê.

• Mensagem clara no log: “RESTART AT STEP X / KEY Y / FILE POS Z”. Operação ama isso.

• Commit e checkpoint têm que conversar: checkpoint sem commit consistente é cilada.

• Se atualiza DB2, trate o restart como requisito de negócio, não “extra”.

• Testar restart é obrigatório: simule abend no meio e valide se volta certo.

---

☕ Fechando no estilo madrugada

No Mainframe, reprise é arquitetura, checkpoint é disciplina, e restart é respeito.

Batch sem reprise em processo crítico é igual:

“depois eu vejo”
só que o “depois” geralmente é 03:17 com telefone tocando e gente jurando que “nunca aconteceu antes”.