Translate

Mostrar mensagens com a etiqueta batch mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta batch mainframe. Mostrar todas as mensagens

quarta-feira, 12 de novembro de 2025

🔥☕ O BATCH VAI FECHAR EM 40 MINUTOS! LABORATÓRIO PRÁTICO DE ENGENHARIA DE SOFTWARE PARA PROGRAMADOR

 

Bellacosa Mainframe laboratorio pratico engenharia de software mainframe

🔥☕ O BATCH VAI FECHAR EM 40 MINUTOS!

LABORATÓRIO PRÁTICO DE ENGENHARIA DE SOFTWARE PARA PROGRAMADOR COBOL JUNIOR NO IBM Z 💣💾

🏛️ Missão Enterprise

Você acaba de entrar no plantão noturno de um grande banco.

O fechamento batch começou.

O JES2 está carregado.
O DB2 processando milhões de transações.
O operador já abriu chamado.
O scheduler está pressionando a janela batch.

E agora…

💥 um programa COBOL começou a falhar em produção.

Sua missão:

✅ diagnosticar
✅ corrigir
✅ melhorar
✅ estabilizar
✅ preparar o sistema para sobreviver no mundo enterprise


🎯 OBJETIVOS DO LAB

Ao final deste laboratório você entenderá:

✅ mentalidade enterprise no IBM Z
✅ engenharia de software aplicada ao COBOL
✅ análise de ABEND
✅ legibilidade de código
✅ modularização
✅ tratamento de erro
✅ observabilidade
✅ restartabilidade
✅ debugging operacional

⏱️ Duração estimada: 30 a 40 minutos


☕ CENÁRIO DO AMBIENTE

Plataforma

ItemTecnologia
Sistema Operacionalz/OS
LinguagemCOBOL
BatchJES2
BancoDB2
OnlineCICS
SegurançaRACF
SchedulerControl-M

🚨 INCIDENTE INICIAL

O operador envia a seguinte mensagem:

JOB FINCLOSE ABEND S0C7
STEP001 FAILED

☕ O QUE É S0C7?

💥 erro de conversão numérica

Normalmente causado por:

  • campo inválido

  • lixo em variável

  • dado alfanumérico em campo numérico

  • corrupção de entrada


🔥 MISSÃO #1 — ANALISAR O CÓDIGO LEGADO

PROGRAMA RECEBIDO

IDENTIFICATION DIVISION.
PROGRAM-ID. FIN001.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-TOTAL PIC 9(09)V99 VALUE 0.

01 WS-VALOR PIC 9(05)V99.

PROCEDURE DIVISION.

MOVE 'ABCDE' TO WS-VALOR.

ADD WS-VALOR TO WS-TOTAL.

DISPLAY WS-TOTAL.

STOP RUN.

🎯 ATIVIDADE

Identifique:

✅ o problema
✅ o risco operacional
✅ o impacto em produção


✅ SOLUÇÃO

MOVE 'ABCDE' TO WS-VALOR

causa:

💥 S0C7

Porque:

  • WS-VALOR é numérico

  • ABCDE é alfanumérico


☕ DICA MAINFRAME

No mundo enterprise:

um campo inválido pode parar uma cadeia inteira de batch.


🔥 MISSÃO #2 — CRIANDO VALIDAÇÃO ENTERPRISE

REFATORAÇÃO

IF WS-ENTRADA NUMERIC
   MOVE WS-ENTRADA TO WS-VALOR
ELSE
   DISPLAY 'ERRO DADO INVALIDO'
   MOVE 0 TO WS-VALOR
END-IF.

🎯 O QUE FOI MELHORADO?

✅ proteção operacional
✅ estabilidade
✅ previsibilidade
✅ observabilidade


☕ CURIOSIDADE MAINFRAME

Muitos incidentes bancários históricos começaram com:

💀 um único campo inválido


🔥 MISSÃO #3 — O MONSTRO DAS 15 MIL LINHAS

Você recebeu um programa com:

☠️ GO TO
☠️ IF aninhado
☠️ sem comentários
☠️ sem modularização


EXEMPLO RUIM

IF A = 1
   IF B = 2
      IF C = 3
         MOVE 1 TO X.

🎯 ATIVIDADE

Refatore para estilo enterprise.


✅ SOLUÇÃO

IF CLIENTE-ATIVO
   PERFORM PROCESSA-CLIENTE
END-IF.

☕ DICA MAINFRAME

Código enterprise precisa ser:

✅ legível
✅ auditável
✅ sustentável
✅ fácil de alterar


🔥 MISSÃO #4 — ANALISANDO PERFORMANCE

O JOB ESTÁ DEMORANDO 5 HORAS

O operador reclama:

BATCH WINDOW ESTOURANDO

🎯 O QUE INVESTIGAR?

✅ SORT excessivo
✅ leitura duplicada
✅ acesso DB2
✅ EXCP
✅ loops
✅ índices


☕ DICA MAINFRAME

No IBM Z:

💸 CPU = dinheiro real


🔥 MISSÃO #5 — TRATAMENTO DE SQLCODE

CÓDIGO RECEBIDO

EXEC SQL
   SELECT NOME
   INTO :WS-NOME
   FROM CLIENTES
END-EXEC.

🎯 PROBLEMA

Nenhum tratamento de erro.


✅ SOLUÇÃO ENTERPRISE

EXEC SQL
   SELECT NOME
   INTO :WS-NOME
   FROM CLIENTES
END-EXEC.

IF SQLCODE = 100
   DISPLAY 'CLIENTE NAO ENCONTRADO'
ELSE
   IF SQLCODE NOT = 0
      DISPLAY 'ERRO DB2'
      DISPLAY SQLCODE
   END-IF
END-IF.

☕ CURIOSIDADE

SQLCODE -911

Pode indicar:

💥 deadlock
💥 timeout
💥 rollback automático


🔥 MISSÃO #6 — OBSERVABILIDADE

CÓDIGO SEM LOG

PERFORM PROCESSA.

🎯 PROBLEMA

Quando falhar:

☠️ ninguém entende o que aconteceu


✅ SOLUÇÃO

DISPLAY 'INICIO PROCESSAMENTO'

PERFORM PROCESSA

DISPLAY 'FIM PROCESSAMENTO'

☕ REGRA DE OURO

Se não logou…

não aconteceu.


🔥 MISSÃO #7 — ENGENHARIA DE SOFTWARE REAL

O QUE O JUNIOR PENSA

“Meu programa compilou.”


O QUE O ENGENHEIRO PENSA

✅ restart
✅ rollback
✅ auditoria
✅ rastreabilidade
✅ suporte
✅ manutenção
✅ observabilidade
✅ performance


☕ DESAFIO FINAL

O banco informa:

“Agora o programa processará 80 milhões de registros.”


O QUE VOCÊ ANALISA?

✅ batch window
✅ EXCP
✅ buffering
✅ índices DB2
✅ paralelismo
✅ checkpoint/restart
✅ SORT
✅ consumo CPU


🏛️ LIÇÃO FINAL DO LAB

No IBM Z:

☕ COBOL não é apenas linguagem.

É engenharia de sobrevivência enterprise.


💣 FRASE FINAL

“O verdadeiro programador mainframe não escreve apenas código.

Ele sustenta o mundo invisível que continua funcionando enquanto bilhões dormem.” ☕🔥

quinta-feira, 30 de outubro de 2025

☕💣 “EU SÓ QUERIA PROGRAMAR EM COBOL…” — O DIA EM QUE DESCOBRI QUE O MAINFRAME IBM Z É UMA CIDADE VIVA E NÃO UM COMPUTADOR 💣☕

 

Bellacosa Mainframe introduz a Engenharia de Software para programador cobol junior padawan

☕💣 “EU SÓ QUERIA PROGRAMAR EM COBOL…” — O DIA EM QUE DESCOBRI QUE O MAINFRAME IBM Z É UMA CIDADE VIVA E NÃO UM COMPUTADOR 💣☕

Existe um momento inevitável na vida de todo programador COBOL junior.

Um momento quase místico.

Você entra no mundo mainframe achando que vai:

✅ escrever alguns IFs
✅ compilar programas
✅ mexer em arquivos
✅ fazer SELECT no DB2
✅ rodar JCL
✅ ir embora feliz

Então um dia…

🔥 produção cai.

E você descobre uma verdade brutal:

O IBM Z não é apenas um computador.

É um ecossistema vivo.

Uma megacidade digital.

Um organismo enterprise colossal.

E o COBOL que você escreve é apenas uma pequena engrenagem dentro de uma máquina absurda que move bancos, bolsas, seguradoras, aeroportos, governos e cartões de crédito do planeta inteiro.

É nesse momento que nasce o verdadeiro programador enterprise.


🏛️ O MAIOR ERRO DO PROGRAMADOR JUNIOR

O iniciante normalmente acredita que:

“Se compilou, então está pronto.”

No mundo real do IBM Z…

isso não significa absolutamente nada.

Porque sistemas enterprise não vivem em laboratório.

Eles vivem em guerra.


🔥 A ILUSÃO DO “MEU PROGRAMA FUNCIONA”

O junior testa:

DISPLAY 'OK'

O resultado aparece.

Ele sorri.

Missão cumprida.

Mas no datacenter real existem coisas que o padawan ainda não consegue enxergar:


💥 O QUE REALMENTE ACONTECE EM PRODUÇÃO

Enquanto seu programa roda…

O JES2 está:

  • controlando spool

  • gerenciando filas

  • liberando jobs

  • priorizando workload


O WLM está:

  • redistribuindo CPU

  • controlando service classes

  • protegendo workloads críticos


O DB2 está:

  • gerenciando locks

  • buffer pools

  • GETPAGE

  • logging

  • rollback

  • contention


O CICS está:

  • coordenando milhares de transações

  • protegendo integridade

  • monitorando resposta online


O RACF está:

  • validando permissões

  • protegendo datasets

  • auditando acessos


O z/OS está:

  • coordenando memória

  • I/O

  • canais

  • discos

  • prioridades

  • dispatching


☕ E VOCÊ?

Você adicionou:

MOVE 'S' TO WS-STATUS

e achou que estava “programando”.

🔥💀


🏛️ O DIA EM QUE O JUNIOR ENCONRA O CAOS

Todo programador mainframe tem um batismo de fogo.

Normalmente começa assim:


🚨 “O FECHAMENTO FALHOU”

02:17 da manhã.

O operador abre chamado crítico.

A tela do console começa a cuspir mensagens:

IEC141I 013-20
S0C7
DSNT408I SQLCODE = -911

O batch noturno travou.

O scheduler congestionou.

A cadeia seguinte não inicia.

O gerente quer resposta.

O suporte quer diagnóstico.

O sysprog quer evidência.

E o programador junior descobre algo aterrorizante:

ninguém quer saber se o programa “compilava”.


🔥 O MAINFRAME NÃO PREMIA CÓDIGO BONITO

Ele premia:

✅ estabilidade
✅ previsibilidade
✅ rastreabilidade
✅ recuperação
✅ auditabilidade
✅ sobrevivência operacional


☕ O VERDADEIRO PAPEL DO PROGRAMADOR ENTERPRISE

O programador COBOL enterprise não escreve apenas lógica.

Ele constrói sistemas capazes de sobreviver:

  • ao tempo

  • a milhões de transações

  • a mudanças de regra

  • a incidentes

  • a auditorias

  • a integrações

  • a falhas humanas

  • a pressão operacional


💣 O QUE O JUNIOR NÃO VÊ NO INÍCIO

O junior pensa:

“Meu programa lê um arquivo.”

O veterano vê:

  • EXCP

  • buffering

  • RECFM

  • LRECL

  • blocking factor

  • checkpoint

  • restart

  • throughput

  • janela batch

  • impacto WLM


☕ EXEMPLO REAL DE MATURIDADE

Junior:

READ CLIENTES

Veterano:

“Quantos milhões de registros?”

“Qual o impacto no batch window?”

“Existe restart?”

“Tem controle de duplicidade?”

“O SORT é realmente necessário?”

“Qual o custo CPU?”

“Esse acesso explode GETPAGE?”

“O operador consegue diagnosticar?”

“O job é restartável?”

“Tem rollback?”


🔥 A GRANDE VIRADA MENTAL

O verdadeiro crescimento no mainframe acontece quando você entende:

COBOL é só a superfície.

Por trás dele existe:

🏛️ arquitetura
🏛️ engenharia
🏛️ operação
🏛️ performance
🏛️ observabilidade
🏛️ resiliência
🏛️ governança


☕ ENGENHARIA DE SOFTWARE NO IBM Z É DIFERENTE

No mundo distribuído muitas vezes existe a cultura do:

“deploy agora, corrige depois.”

No IBM Z isso pode significar:

💥 milhões perdidos
💥 fila bancária travada
💥 cartão recusado
💥 compensação atrasada
💥 processamento interrompido

Por isso o mainframe criou uma cultura quase militar de qualidade operacional.


🔥 O CÓDIGO PRECISA CONTAR UMA HISTÓRIA

O junior escreve código para máquina.

O veterano escreve código para:

  • o próximo programador

  • o suporte

  • o operador

  • a auditoria

  • o sysprog

  • o DBA

  • o time de produção


☕ O VERDADEIRO TERROR DO MAINFRAME

Não é S0C7.

Não é S322.

Não é SQLCODE -911.

O verdadeiro terror é:

um sistema crítico impossível de manter.


💣 O MONSTRO DAS 20 MIL LINHAS

Todo programador mainframe eventualmente encontra:

☠️ um programa COBOL monstruoso
☠️ sem comentários
☠️ sem modularização
☠️ cheio de GO TO
☠️ sem tratamento de erro
☠️ alterado por 30 anos

E então percebe:

engenharia de software não é luxo.

É sobrevivência.


☕ O MAINFRAME É UMA ESCOLA DE MATURIDADE

O IBM Z força o programador a evoluir.

Porque ali:

  • performance importa

  • estabilidade importa

  • disciplina importa

  • análise importa

  • responsabilidade importa

Você deixa de ser apenas alguém que “faz programa”.

E começa a pensar como engenheiro de sistemas enterprise.


🔥 O MOMENTO EM QUE TUDO MUDA

Existe um instante específico em que o junior evolui.

É quando ele para de perguntar:

“Como faço isso funcionar?”

E começa a perguntar:

“Como faço isso sobreviver em produção pelos próximos 15 anos?”

Nesse momento…

nasce um verdadeiro profissional mainframe.


☕ LIÇÃO FINAL DO DATACENTER

O IBM Z não ensina apenas tecnologia.

Ele ensina:

🏛️ responsabilidade
🏛️ engenharia
🏛️ disciplina
🏛️ resiliência
🏛️ pensamento sistêmico

Porque no fim…

o COBOL nunca foi apenas sobre código.

Foi sobre sustentar o mundo invisível que continua funcionando enquanto bilhões de pessoas dormem sem imaginar que existe um mainframe mantendo tudo vivo.


sexta-feira, 27 de março de 2015

☕🔥 BOAS PRÁTICAS COBOL — A DIFERENÇA ENTRE “CÓDIGO QUE FUNCIONA” E “CÓDIGO QUE SOBREVIVE 30 ANOS”

 

Bellacosa Mainframe e as Boas praticas em cobol

☕🔥 BOAS PRÁTICAS COBOL — A DIFERENÇA ENTRE “CÓDIGO QUE FUNCIONA” E “CÓDIGO QUE SOBREVIVE 30 ANOS”

O material enviado é excelente porque toca num dos assuntos mais importantes do mundo Enterprise:

COBOL não é só linguagem.
COBOL é engenharia de continuidade operacional.

E isso muda completamente a maneira de programar.

No mercado bancário, seguradoras, adquirentes, cartões, previdência, governo e clearing houses…

o programa COBOL NÃO é feito para durar meses.

Ele é feito para durar décadas.

Muitos sistemas bancários críticos hoje ainda possuem módulos escritos entre:

  • 1978

  • 1986

  • 1992

  • 1999

e continuam processando:

  • PIX

  • TED

  • SWIFT

  • cartão

  • folha

  • empréstimo

  • câmbio

  • risco

  • antifraude

  • compensação

  • open finance

com volumes absurdos.


☕ O GRANDE SEGREDO DO COBOL CORPORATIVO

Em sistemas Enterprise:

O custo da MANUTENÇÃO é MUITO maior que o custo da implementação inicial.

Em bancos:

  • 70% a 90% do trabalho é manutenção

  • não projeto novo

Então o verdadeiro objetivo do COBOL é:

  • previsibilidade

  • legibilidade

  • estabilidade

  • rastreabilidade

  • auditabilidade

  • recuperação

  • facilidade de troubleshooting

e NÃO “código bonito”.


☕ O QUE DIFERENCIA UM JÚNIOR DE UM PROGRAMADOR COBOL ENTERPRISE?

Junior:

  • “funciona”

Senior:

  • “isso vai sobreviver 20 anos?”

Especialista banco:

  • “isso vai sobreviver 20 anos SEM derrubar batch?”

Arquiteto:

  • “isso vai sobreviver auditoria BACEN?”


☕ 1 — IDENTIFICATION DIVISION NÃO É ENFEITE

O texto fala algo extremamente importante:

Muita gente ignora IDENTIFICATION DIVISION.

No mundo real isso é gravíssimo.

Porque em bancos:

  • programas possuem milhares de versões

  • dezenas de equipes

  • auditorias

  • SOX

  • BACEN

  • LGPD

  • rastreabilidade


EXEMPLO CORPORATIVO REAL

IDENTIFICATION DIVISION.
PROGRAM-ID. CRD0450.

AUTHOR. V BELLACOSA.
INSTALLATION. BANK XYZ.
DATE-WRITTEN. 2026-05-21.

REMARKS.
* PROCESSA BAIXA DE PARCELAS
* MODULO UTILIZADO NO FECHAMENTO D+1
* INTEGRADO COM CICS E DB2
* CHAMADO PELO SCHEDULER CA7

☕ POR QUE ISSO É IMPORTANTE?

Imagine:

Batch falhou às 02:15 da manhã.

Operação liga para suporte.

O operador precisa descobrir:

  • o que o programa faz

  • qual sistema impactado

  • qual cadeia batch

  • quem mantém

  • dependências

Sem IDENTIFICATION adequada:

  • caos

Com documentação:

  • troubleshooting rápido


☕ 2 — COMENTÁRIOS NÃO DEVEM EXPLICAR “O QUE”

Esse trecho do artigo é ouro puro.

Programador ruim comenta:

* SOMA VALOR
ADD WS-VALOR TO WS-TOTAL

Isso é inútil.

O COBOL já é quase inglês.


☕ O QUE DEVE SER COMENTADO?

REGRA DE NEGÓCIO

Exemplo bancário:

* BACEN CIRCULAR 4588
* JUROS DEVEM SER ESTORNADOS
* QUANDO LIQUIDACAO OCORRER EM D-1
* CHAMADO 458921 - TIME RISCO

IF WS-DT-LIQ < WS-DT-VENC
   SUBTRACT WS-JUROS
      FROM WS-SALDO
END-IF

Isso salva vidas em produção.

Porque explica:

  • por que existe

  • quem pediu

  • qual regra

  • qual auditoria

  • qual legislação


☕ 3 — NOMENCLATURA EM COBOL É CIÊNCIA

O texto explica muito bem padrões de nomes.

Em sistemas bancários grandes:

nomenclatura é arquitetura.


☕ EXEMPLO RUIM

01 X.
01 Y.
01 TOTAL1.
01 CONT.

Isso destrói manutenção.


☕ EXEMPLO ENTERPRISE

01 WS-VR-TOTAL-PAGAMENTO    PIC S9(13)V99 COMP-3.
01 WS-QT-PARCELAS-ATRASO    PIC 9(05) COMP.
01 WS-DT-LIQUIDACAO         PIC 9(08).
01 WS-ST-CLIENTE-INAD       PIC X(01).

Agora qualquer pessoa entende:

  • VR = valor

  • QT = quantidade

  • DT = data

  • ST = status


☕ PADRÃO BANCÁRIO MAIS COMUM

Prefixos clássicos

PrefixoSignificado
WSWorking-Storage
LKLinkage
DFHCICS
SQLDb2
INEntrada
OUTSaída
ACAcumulador
CTContador
FLGFlag

☕ 4 — EVALUATE É UMA DAS MAIORES ARMAS DO COBOL MODERNO

O artigo mostra um IF gigantesco.

Isso é MUITO comum em sistemas antigos.


☕ O PROBLEMA DOS IFs GIGANTES

Eles causam:

  • difícil manutenção

  • bugs

  • nesting infernal

  • scope errado

  • END-IF perdido

  • regressão


☕ COMO BANCOS MODERNIZAM ISSO?

Com:

EVALUATE WS-TP-MOVIMENTO

   WHEN '01'
      PERFORM 100-CREDITO

   WHEN '02'
      PERFORM 200-DEBITO

   WHEN '03'
      PERFORM 300-ESTORNO

   WHEN OTHER
      PERFORM 900-ERRO

END-EVALUATE

☕ BENEFÍCIOS

1. Legibilidade absurda

2. Menos bugs

3. Fácil inclusão de novas regras

4. Melhor debugging

5. Melhor análise de fluxo


☕ 5 — END-IF SALVOU O MAINFRAME

O artigo cita delimitadores de escopo.

Isso foi uma revolução.

Antes:

IF A = B
   IF C = D
      MOVE 1 TO X.

O ponto encerrava TUDO.

Isso gerava:

  • bugs monstruosos

  • IF acidentalmente fechado

  • corrupção lógica


☕ BOA PRÁTICA MODERNA

IF WS-SALDO > ZERO

   IF WS-LIMITE > ZERO
      PERFORM 100-LIBERA
   END-IF

END-IF

☕ REGRA DE OURO DOS BANCOS

NUNCA dependa de ponto para fechar escopo.

Sempre:

  • END-IF

  • END-EVALUATE

  • END-PERFORM

  • END-READ

  • END-EXEC


☕ 6 — CÓDIGO MORTO É VENENO CORPORATIVO

O artigo fala sobre código comentado antigo.

Isso é uma praga em mainframe.


☕ EXEMPLO REAL

* COMPUTE WS-JUROS = WS-SALDO * 0.12
MOVE ZERO TO WS-JUROS

10 anos depois:

  • ninguém sabe qual regra vale

  • auditoria confunde

  • manutenção vira inferno


☕ MELHOR PRÁTICA

Use:

  • ChangeMan

  • Endevor

  • Git

  • ISPW

Versionamento existe para isso.


☕ O CÓDIGO DEVE REPRESENTAR:

o presente

Não o passado arqueológico do sistema.


☕ 7 — COPYBOOKS: O DNA DO MAINFRAME

O artigo comenta reuso moderado.

Esse é um dos temas mais importantes do COBOL bancário.


☕ O QUE É COPYBOOK?

É um INCLUDE reutilizável.


☕ EXEMPLO

COPY CLIENTE.
COPY DFHAID.
COPY SQLCA.

☕ PRINCIPAIS COPYBOOKS BANCÁRIOS

1. Layouts de arquivos

CNAB:

  • 240

  • 400


2. Áreas CICS

DFHCOMMAREA

3. Estruturas Db2

DCLGEN

4. APIs corporativas

PIX
SWIFT
Open Finance


☕ PERIGO DO EXCESSO DE COPYBOOK

Já vi programas com:

  • 120 COPYs

  • impossível entender fluxo

Isso gera:

  • compilação lenta

  • impacto gigante

  • acoplamento monstruoso


☕ BOA PRÁTICA

Reuse:

  • layouts

  • APIs

  • estruturas comuns

  • tratamento corporativo

NÃO reuse:

  • lógica besta

  • MOVE ZERO

  • regras triviais


☕ 8 — COMP, COMP-3 E PERFORMANCE

O artigo toca num ponto extremamente avançado.

Muita gente não entende isso.


☕ DISPLAY vs COMP vs COMP-3

DISPLAY

PIC 9(10)

Armazenado:

  • caractere por caractere

Mais lento.


☕ COMP

PIC S9(9) COMP

Binário.

Muito mais rápido.

Ideal:

  • contadores

  • loops

  • índices


☕ COMP-3

PIC S9(11)V99 COMP-3

Packed decimal.

Perfeito para:

  • financeiro

  • bancos

  • dinheiro

Porque:

  • precisão decimal exata


☕ POR QUE BANCOS AMAM COMP-3?

Porque dinheiro NÃO pode ter erro binário.

Exemplo clássico:

Floating Point

0.1 + 0.2 = 0.3000000000004

Em banco:

  • isso seria catastrófico


☕ COBOL RESOLVE ISSO

Com decimal packed:

01 WS-VALOR PIC S9(09)V99 COMP-3.

Precisão decimal real.


☕ 9 — NÍVEL 88 É SUBESTIMADO

O artigo comenta condition names.

Isso é uma maravilha do COBOL.


☕ SEM NÍVEL 88

IF WS-ST-CLIENTE = 'A'

'A' significa o quê?


☕ COM NÍVEL 88

01 WS-ST-CLIENTE PIC X(01).

   88 CLIENTE-ATIVO VALUE 'A'.
   88 CLIENTE-BLOQUEADO VALUE 'B'.
   88 CLIENTE-INADIMPLENTE VALUE 'I'.

Agora:

IF CLIENTE-INADIMPLENTE

Fica quase inglês.


☕ 10 — PRINCIPAIS SOLUÇÕES BANCÁRIAS COBOL

Agora vamos entrar no mundo REAL Enterprise.


☕ ARQUITETURA MAIS COMUM EM BANCOS

ONLINE

CICS + COBOL + Db2

Processa:

  • saldo

  • PIX

  • TED

  • cartão

  • ATM

  • mobile


☕ BATCH

JCL + COBOL + SORT + IDCAMS + Db2 Utilities

Processa:

  • fechamento

  • extrato

  • billing

  • juros

  • risco

  • liquidação


☕ MIDDLEWARE

MQ
Kafka
IBM Integration Bus
z/OS Connect

Integra:

  • APIs

  • microsserviços

  • nuvem

  • mobile


☕ SEGURANÇA

RACF

Controla:

  • datasets

  • transações

  • usuários

  • APIs


☕ ALTA DISPONIBILIDADE

Sysplex
GDPS
Parallel Sysplex


☕ MONITORAMENTO

OMEGAMON
MainView
SYSVIEW


☕ DEVOPS MAINFRAME

Endevor
ISPW
Git + DBB
Jenkins
UrbanCode


☕ EXEMPLO REAL — TRANSAÇÃO PIX

PASSO A PASSO


1 — APP MOBILE

Cliente envia PIX.


2 — API GATEWAY

Chama:

  • z/OS Connect

  • MQ

  • CICS


3 — CICS

Executa transação COBOL.


4 — COBOL

Valida:

  • saldo

  • limite

  • antifraude

  • horário

  • BACEN


5 — Db2

Atualiza:

  • saldo

  • ledger

  • histórico


6 — MQ/Kafka

Publica evento.


7 — Batch Noturno

Concilia:

  • compensação

  • liquidação

  • auditoria


☕ O QUE ISSO ENSINA?

Que COBOL moderno NÃO vive isolado.

Ele é:

  • coração transacional

  • motor financeiro

  • camada de consistência


☕ CONCLUSÃO

O artigo enviado aborda algo fundamental:

boas práticas COBOL não existem para “embelezar código”.

Elas existem para:

  • manter sistemas vivos

  • reduzir risco operacional

  • evitar incidentes bancários

  • facilitar auditoria

  • garantir continuidade

  • permitir manutenção segura

E isso é exatamente o motivo pelo qual:

  • bancos

  • bolsas

  • seguradoras

  • governos

  • adquirentes

continuam confiando bilhões de dólares ao COBOL diariamente.


quinta-feira, 22 de março de 2007

O que é DSN em JCL?

 

Bellacosa Mainframe explicando dsn em jcl

O que é DSN em JCL?

No ambiente Mainframe, DSN significa:

Data Set Name

Ou seja:

Nome de um Dataset

O parâmetro DSN= é um dos mais utilizados em JCL e serve para informar qual arquivo (dataset) será utilizado por um programa, utility ou procedimento.


Definição Simples

Pense no DSN como o caminho de um arquivo no Windows.

Windows:

C:\ARQUIVOS\CLIENTES.TXT

Mainframe:

USER.PROJETO.CLIENTES

Esse nome é o DSN.


Exemplo Básico

//ARQENT DD DSN=USER.PROJETO.CLIENTES,
//       DISP=SHR

Onde:

DSN=USER.PROJETO.CLIENTES

é o dataset utilizado.


Significado da Sigla

SiglaSignificado
DSData Set
NName
DSNData Set Name

Estrutura de um DSN

Um dataset é composto por qualificadores.

Exemplo:

EMPRESA.FINANCEIRO.CLIENTES

Cada parte possui significado.

EMPRESA
   ↓
FINANCEIRO
   ↓
CLIENTES

Exemplo Corporativo

BANCO.PRODUCAO.COBOL
BANCO.TESTE.COBOL
BANCO.CLIENTES.VSAM
BANCO.JCL.PROC

Uso em DD Statements

O uso mais comum.

//ENTRADA DD DSN=USER.ARQ.ENTRADA,
//            DISP=SHR

Dataset Sequencial

//SAIDA DD DSN=USER.ARQ.SAIDA,
//          DISP=OLD

Dataset VSAM

//CLIENTE DD DSN=BANCO.CLIENTE.KSDS,
//            DISP=SHR

Dataset GDG

//RELAT DD DSN=USER.RELATORIO.GDG(+1),
//          DISP=(NEW,CATLG)

Dataset Temporário

//SORTWK DD DSN=&&TEMP,
//           DISP=(NEW,PASS)

O dataset existe apenas durante o Job.


DSN e DISP

Normalmente aparecem juntos.

//ARQ DD DSN=USER.CLIENTES,
//        DISP=SHR

Onde:

DSN = Nome do Dataset

DISP = Como será utilizado

DSN em Criação de Arquivos

//SAIDA DD DSN=USER.NOVO.ARQUIVO,
//          DISP=(NEW,CATLG,DELETE),

O dataset será criado.


DSN em SYSUT1 e SYSUT2

Muito comum em utilities.

//SYSUT1 DD DSN=USER.ARQ.ORIGEM,
//            DISP=SHR
//SYSUT2 DD DSN=USER.ARQ.DESTINO,
//            DISP=(NEW,CATLG)

DSN em IDCAMS

//ARQVSAM DD DSN=EMPRESA.CLIENTE.KSDS

DSN em SORT

//SORTIN DD DSN=USER.CLIENTES,
//           DISP=SHR

//SORTOUT DD DSN=USER.CLIENTES.ORD,
//            DISP=(NEW,CATLG)

DSN e Catálogo

O catálogo do z/OS mantém informações sobre o dataset.

Quando informamos:

DSN=USER.CLIENTES

o sistema consulta o catálogo para localizar o arquivo.


Regras para Nomes

Um DSN:

✅ Pode ter até 44 caracteres

✅ Pode possuir vários qualificadores

✅ Usa ponto (.) como separador


Exemplo:

EMPRESA.FINANCEIRO.ARQUIVOS.CLIENTES

Qualificadores

Cada qualificador pode ter:

1 a 8 caracteres

Exemplo:

EMPRESA
FINANCE
CLIENTES

Caracteres Permitidos

Normalmente:

A-Z
0-9
@
#
$

Exemplo Real

//STEP01 EXEC PGM=COBOLPGM

//ENTRADA DD DSN=BANCO.PROD.CLIENTES,
 //          DISP=SHR

//SAIDA DD DSN=BANCO.PROD.RELATORIO,
 //         DISP=(NEW,CATLG,DELETE)

Erros Comuns

Dataset Não Existe

IEC141I
DATA SET NOT FOUND

Nome Incorreto

JCL ERROR

Dataset Em Uso

DATA SET IN USE

Boas Práticas

✅ Utilizar nomenclatura padronizada

✅ Separar Produção e Teste

✅ Usar qualificadores significativos

✅ Evitar nomes genéricos


Curiosidade

O conceito de DSN existe desde os primeiros sistemas OS/360 da IBM nos anos 1960. Mesmo após décadas de evolução tecnológica, ele continua sendo uma das estruturas fundamentais do z/OS, organizando bilhões de datasets utilizados diariamente por bancos, seguradoras e governos.


Resumo Rápido

ComandoFunção
DSN=USER.ARQDataset existente
DSN=ARQ(+1)Nova geração GDG
DSN=&&TEMPDataset temporário
DSN=ARQ.VSAMArquivo VSAM
DSN=ARQ.SEQArquivo sequencial

Conclusão

O DSN (Data Set Name) é o nome lógico de um dataset no Mainframe. Utilizado principalmente em instruções DD do JCL, ele identifica arquivos sequenciais, VSAM, GDGs, bibliotecas, datasets temporários e diversos outros recursos do z/OS. Dominar o uso de DSN é um dos primeiros passos para compreender JCL, Batch e administração de arquivos em ambientes Mainframe.


sexta-feira, 16 de fevereiro de 2007

O que é Processamento Batch em Mainframe?

 

Bellacosa Mainframe o que é processamento batch em Mainframe

O que é Processamento Batch em Mainframe?

O processamento Batch é uma das tecnologias mais importantes da história da computação corporativa e continua sendo responsável por processar bilhões de transações diariamente em bancos, seguradoras, governos e grandes empresas.

Batch significa:

Processamento em Lote

Ou seja, um conjunto de dados é processado automaticamente, sem interação direta do usuário durante a execução.


Definição Simples

Imagine que uma empresa precisa:

  • calcular salários;

  • gerar extratos;

  • processar PIX;

  • atualizar saldos;

  • emitir boletos.

Em vez de fazer isso um registro por vez, o sistema reúne milhares ou milhões de registros e processa tudo em lote.

Isso é Batch.


Analogia Simples

Imagine uma lavanderia industrial.

Processamento Online

Roupa entra
↓
Lavagem imediata
↓
Entrega

Processamento Batch

1000 roupas chegam
↓
Acumula tudo
↓
Processa em lote
↓
Entrega

Batch x Online

BatchOnline
Sem usuárioCom usuário
Processamento em loteTempo real
Grande volumePequeno volume
Horários programadosSob demanda
Alta performanceBaixa latência

Exemplo Online

Cliente consulta saldo:

ATM
↓
CICS
↓
DB2
↓
Resposta

Tudo acontece em segundos.


Exemplo Batch

Fim do dia:

Milhões de contas
↓
Atualizar juros
↓
Gerar extratos
↓
Criar relatórios

Arquitetura Batch no Mainframe

JCL
 ↓
Scheduler
 ↓
JOB
 ↓
Programa COBOL
 ↓
QSAM / VSAM / DB2
 ↓
Relatórios

Componentes Principais

JCL

Job Control Language

Controla a execução.


COBOL

Executa as regras de negócio.


Dataset

Contém os dados.


Scheduler

Agenda a execução.


JES2/JES3

Gerencia filas e spool.


Como um Batch Funciona?

Fluxo típico:

Entrada
 ↓
Leitura
 ↓
Validação
 ↓
Processamento
 ↓
Gravação
 ↓
Relatórios

Exemplo Real

Banco processando pagamentos:

Arquivo PIX
 ↓
COBOL
 ↓
Validação
 ↓
Atualização DB2
 ↓
Relatório

Exemplo de JCL

//PAGTO JOB ...

//STEP1 EXEC PGM=PAGPIX

//ENTRADA DD DSN=BANCO.PIX.INPUT

//SAIDA   DD DSN=BANCO.PIX.OUTPUT

O que acontece?

O z/OS:

  1. Aloca datasets

  2. Carrega programa

  3. Executa COBOL

  4. Gera SYSOUT

  5. Finaliza Job


Ciclo de Vida de um Job Batch

SUBMIT
  ↓
INPUT QUEUE
  ↓
EXECUTION QUEUE
  ↓
RUNNING
  ↓
OUTPUT QUEUE
  ↓
PURGE

Onde vemos isso?

No SDSF:

ST
DA
I
H
O

Horário de Batch

Tradicionalmente:

22:00
 ↓
06:00

Conhecido como:

Janela Batch


Por que à noite?

Menos usuários online.

Mais recursos disponíveis.


Tipos de Batch


Batch Sequencial

Processa arquivo inteiro.

Registro 1
Registro 2
Registro 3

Batch DB2

Processa tabelas.

SELECT
UPDATE
INSERT
DELETE

Batch VSAM

Processa registros indexados.


Batch ETL

Extrai, transforma e carrega dados.

Muito usado em Data Warehouse.


Schedulers Mais Conhecidos


IBM Workload Scheduler (IWS)

Antigo OPC/TWS.


Control-M

Muito usado em bancos.


CA-7

Broadcom.


ESP

Scheduler corporativo.


Automic

Ambientes distribuídos e Mainframe.


Dependências Batch

Um Job pode depender de outro.


Exemplo

JOB-A
 ↓
JOB-B
 ↓
JOB-C

JOB-B só executa se:

JOB-A RC=0000

Return Code (RC)

Código de retorno do Job.


Exemplos

RCSignificado
0000Sucesso
0004Aviso
0008Erro
0012Erro grave
0016Falha crítica

ABEND em Batch

Se ocorrer:

S0C7
S806
SB37

O Job pode parar.


Logs do Batch

Disponíveis no:

SYSOUT
JESMSGLG
JESJCL
JESYSMSG

Exemplo de Fluxo Bancário

PIX RECEBIDOS
        ↓
JOB BATCH
        ↓
ATUALIZA DB2
        ↓
GERA EXTRATO
        ↓
ENVIA RELATÓRIO

Vantagens do Batch

✅ Processa milhões de registros

✅ Excelente performance

✅ Automatização

✅ Baixo custo operacional

✅ Alta confiabilidade


Desvantagens

❌ Não é tempo real

❌ Dependência de janelas

❌ Recuperação pode ser complexa


Curiosidades

1. Alguns bancos processam mais de 10 bilhões de registros por noite

2. Muitos batchs executam há mais de 30 anos sem interrupção

3. O conceito de processamento em lote existe desde a era dos cartões perfurados

4. Grande parte do fechamento bancário mundial ainda depende de batchs COBOL


Erros Comuns de Iniciantes

Confundir Batch com Online


Ignorar Return Codes


Não analisar SYSOUT


Não tratar ABENDs


Não entender dependências do Scheduler


Resumo Rápido

ConceitoFunção
BatchProcessamento em lote
JCLControle execução
COBOLRegras negócio
DatasetDados
SchedulerAgendamento
RCCódigo retorno
SYSOUTLogs
JES2Gerência filas
IWSScheduler IBM
Control-MScheduler corporativo

Conclusão

O processamento Batch é o coração operacional de muitas empresas que utilizam Mainframe IBM Z. Ele permite processar enormes volumes de dados de forma automatizada, segura e eficiente, sendo responsável por atividades críticas como fechamento bancário, folha de pagamento, faturamento, conciliações financeiras e geração de relatórios corporativos.


terça-feira, 16 de janeiro de 2007

O que é JES2?

 

Bellacosa Mainframe e o que é jes2

O que é JES2?

Quando alguém começa a estudar mainframe, rapidamente encontra nomes como:

  • JOB;

  • spool;

  • batch;

  • SDSF;

  • JES2.

E logo surge a pergunta:

Quem controla os JOBs no z/OS?

A resposta normalmente é:

JES2

Ele é um dos componentes mais importantes do ambiente mainframe.


O que significa JES2?

JES2 significa:

Job Entry Subsystem 2

Em português:

Subsistema de Entrada de Jobs


Definição simples

O JES2 é o componente do z/OS responsável por:

  • receber JOBs;

  • controlar execução batch;

  • gerenciar spool;

  • controlar impressões;

  • organizar filas de processamento.


Uma analogia fácil

Imagine um grande aeroporto.

Existem:

  • aviões;

  • filas;

  • pistas;

  • autorização de decolagem;

  • controle de tráfego.

O JES2 funciona como:

a torre de controle dos JOBs do mainframe.

Ele decide:

  • quem entra;

  • quem espera;

  • quem executa;

  • quem terminou.


O que é um JOB?

JOB é um processamento batch.

Exemplo:

  • folha salarial;

  • fechamento bancário;

  • relatórios;

  • backup;

  • processamento financeiro.


O que o JES2 faz?


1. Recebe JOBs

Quando o usuário executa:

SUBMIT

o JOB vai para o JES2.


2. Coloca em fila

O JES2 organiza:

  • prioridade;

  • classe;

  • recursos;

  • ordem de execução.


3. Controla spool

Armazena:

  • SYSOUT;

  • logs;

  • relatórios;

  • mensagens.


4. Inicia execução

Quando recursos ficam disponíveis:
o JES2 libera o JOB.


5. Finaliza processamento

Depois:

  • guarda saída;

  • libera recursos;

  • mantém logs.


O que é spool?

Spool significa:

Simultaneous Peripheral Operations Online

É uma área temporária onde ficam:

  • saídas;

  • relatórios;

  • SYSOUT;

  • mensagens batch.


Analogia simples

Imagine:

uma fila de impressão gigante.

O JES2 organiza tudo antes da saída final.


Fluxo simplificado do JES2

USUÁRIO
   ↓
SUBMIT
   ↓
JES2
   ↓
FILA
   ↓
EXECUÇÃO
   ↓
SPOOL
   ↓
OUTPUT

O JES2 executa o JOB?

Não diretamente.

Quem executa é:

o initiator.

O JES2:

  • controla;

  • agenda;

  • organiza.


O que é initiator?

Processo que executa JOBs batch.

O JES2 entrega JOBs para ele.


O que é classe no JES2?

Os JOBs podem possuir:

  • classes;

  • prioridades;

  • políticas.

Exemplo:

//JOBNAME JOB CLASS=A

Isso ajuda o sistema a organizar workload

Por exemplo:

  • jobs rápidos;

  • jobs pesados;

  • produção;

  • testes.


O que é SYSOUT?

Saída gerada pelo JOB.

Exemplo:

  • relatórios;

  • mensagens;

  • logs COBOL.


Onde visualizar JOBs?

Principalmente via:

SDSF


Painéis famosos do SDSF


ST

Status dos JOBs.


DA

Jobs ativos.


O

Output.


H

Held output.


Como um JOB entra no JES2?

Exemplo simples:

//MEUJOB JOB ...
//STEP1 EXEC PGM=IEFBR14

Usuário executa:

SUBMIT

O JES2 recebe o JOB.


O que é HOLD?

JOB fica parado aguardando liberação.


O que é CANCEL?

Cancela JOB.


O que é purge?

Remove JOB do spool.


O que é output class?

Classe da saída SYSOUT.

Exemplo:

//SYSOUT=A

O JES2 controla impressoras?

Historicamente:
sim.

Hoje também controla:

  • saída eletrônica;

  • spool digital;

  • relatórios.


JES2 vs JES3

Existem dois grandes subsistemas históricos:


JES2

Mais popular.

Mais simples e distribuído.


JES3

Controle mais centralizado.

Hoje JES2 domina a maioria dos ambientes.


O JES2 ainda é usado?

Muito.

Principalmente em:

  • bancos;

  • seguradoras;

  • governos;

  • processamento financeiro.


Curiosidades incríveis

1. O JES2 existe há décadas

E continua essencial.


2. Bilhões de JOBs passam pelo JES2

Todos os anos.


3. Grande parte do sistema financeiro depende dele

Principalmente batch noturno.


4. O spool é uma das áreas mais críticas do z/OS

Sem spool o batch praticamente para.


O que iniciantes costumam confundir?


1. Pensar que JES2 executa programas diretamente

Quem executa é o initiator.


2. Confundir JES2 com SDSF

JES2 = subsistema
SDSF = interface de monitoramento.


3. Ignorar classes

Elas afetam:

  • prioridade;

  • execução;

  • workload.


4. Confundir spool com dataset comum

Spool possui gerenciamento especial.


Como o JES2 aparece no dia a dia?

Praticamente em tudo:

  • COBOL;

  • batch;

  • SORT;

  • backups;

  • DB2;

  • relatórios;

  • automação.


Mensagens famosas do JES2


$HASP

Prefixo clássico do JES2.

Exemplo:

$HASP373 JOB STARTED

$HASP395

JOB finalizado.


Essas mensagens são lendárias no mundo mainframe


Por que aprender JES2?

Porque ele é:

o coração do processamento batch do z/OS.

Quem entende JES2 entende:

  • batch;

  • spool;

  • execução de JOBs;

  • operação mainframe.


Resumo rápido

ConceitoSignificado
JES2Gerenciador de JOBs
JOBProcessamento batch
SpoolÁrea de saída temporária
SYSOUTSaída do JOB
InitiatorExecuta JOB
SDSFInterface de monitoramento
CLASSPrioridade/categoria

Conclusão

O JES2 é um dos componentes mais importantes do z/OS.

Ele funciona como a central de controle do processamento batch, organizando JOBs, spool, filas e execução dentro do ambiente mainframe IBM Z.

Mesmo após décadas de existência, continua sendo peça fundamental da computação corporativa moderna.