Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning

🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões

Versão técnica: RMF, SMF e a arte de não tunar errado

O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:

1. Quem acha que faz performance tuning

2. Quem sabe onde olhar primeiro

Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.

---

🎯 Regra zero do workshop

Nunca comece pelo parâmetro. Comece pela observação.

Antes de qualquer ALTER, DEFINE ou SET:

• Qual workload?

• Qual período?

• O que mudou?

• Existe baseline?

Sem isso, tuning vira superstição técnica.

---

🧠 CPU: o falso vilão

Onde olhar no RMF

RMF CPU Activity Report (Postprocessor)

Campos clássicos:

• % Busy

• % LPAR Utilization

• % Logical Processor Dispatch

• % IFA / zIIP / zAAP (quando aplicável)

Interpretação que o workshop ensina

• CPU alta com response time estável → sistema saudável

• CPU média com response time degradando → gargalo fora da CPU

• CPU baixa + atraso → WLM ou I/O

📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.

---

⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB

RMF Workload Activity Report

Campos críticos:

• Service Class Period

• Velocity

• Average Response Time

• Delay Reasons

Exemplo típico visto no workshop:

Service Class: ONLINE_HI
Velocity Goal: 50
Achieved Velocity: 12
Delay: I/O 65%, Enqueue 20%

👉 Conclusão correta:

• Não adianta subir prioridade

• Não adianta mexer em CPU

• O gargalo não é WLM, é dependência externa

💡 Lição central:

WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.

---

📊 RMF Monitor III: o “agora dói aqui”

Uso correto (e erro comum)

Monitor III serve para:

• Incidente ativo

• Observação em tempo real

• Confirmação de suspeita

Não serve para:

• Análise histórica

• Decisão estrutural

• Justificativa pós-morte

Campos típicos:

• Address Space Delay

• Device Response Time

• Enqueue Waits

📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.

---

🗃️ SMF: onde a discussão acaba

SMF 30 – Address Space Accounting

Usado para responder:

• Quem consumiu CPU?

• Quanto?

• Em qual período?

Exemplo prático:

SMF30:
CPU Time: baixo
Elapsed Time: alto

👉 Indício claro:

• Espera externa

• I/O

• Lock

• Dependência de outro job

---

SMF 70 / 72 – CPU e WLM

SMF 72 é o coração do tuning orientado a SLA.

Campos essenciais:

• Service Class Performance Index

• Delay Breakdown

• Period Transitions

📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.

---

SMF 74 – I/O e Storage

Onde muitos problemas se revelam.

Campos observados:

• Device Response Time

• Pending Time

• Channel Utilization

Exemplo clássico:

• CPU “sobrando”

• Response time alto

• 3390 com Pending elevado

👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.

---

⚠️ Casos clássicos discutidos no workshop

🔥 “O batch atrasou tudo”

RMF mostra:

• Batch em baixa prioridade

• Online atrasando

SMF revela:

• Batch segurando enqueue crítico

• Online esperando lock

👉 Ajuste correto:

• Revisar serialização

• Reavaliar janela batch

• Não subir prioridade às cegas

---

🔥 “Depois da mudança ficou lento”

Primeira pergunta ensinada no workshop:

Qual foi o último change?

Sem resposta clara:

• tuning suspenso

• investigação começa

📌 Lição dura:

Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.

---

🚀 O que o workshop realmente forma

Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.

Quem sai sabendo:

• Correlacionar RMF + SMF

• Defender decisão com dados

• Evitar tuning destrutivo

• Criar baseline útil

No CPD, isso vira reputação.

---

🧠 Frase final  

“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”

O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.

📘 REPOST: CICS Command Level para padawans

 

CICS Command Level for Padawans

📘 CICS Command Level para padawans

Um guia passo a passo para entender o que é CICS, aprender e planejar um roteiro de estudos com o orquestrador do online em Mainframe.

#ibm #mainframe #cobol #cics #t3270 #vsam #bms #ksds #esds #ceda #ceci #cemt 

Post no Linkedin

1

 

Bellacosa Mainframe conheça o banco de dados DB2 

💥 SEU COBOL TURBINADO MUITO ALÉM DO QSAM — É UM MOTOR DE GUERRA: O VERDADEIRO PAPEL DO DB2 NO IBM z17 QUE QUASE NINGUÉM TE EXPLICOU

---

Se você é dev COBOL sênior e ainda trata o Db2 como “apenas o banco”, deixa eu ser direto:

💀 Você está subestimando o componente mais crítico do seu sistema.

O IBM Db2 no mundo do z/OS — especialmente em arquiteturas modernas como o z17 — não é storage.

👉 É um motor transacional de alta precisão, otimizado ao longo de décadas para um único propósito:
não falhar quando dinheiro, tempo e reputação estão em jogo.

---

🧠 CAPÍTULO 1 — A ORIGEM: ONDE TUDO COMEÇOU

Antes de você escrever seu primeiro:

EXEC SQL SELECT ...

Já existia uma revolução acontecendo dentro da IBM.

---

🕰️ Linha do tempo real (sem romantização)

• 1970 → Modelo relacional (Edgar Codd)
• 1974 → System R (protótipo)
• 1983 → Db2 nasce no mainframe
• Hoje → roda bilhões de transações/dia

---

💀 Easter egg histórico

Db2 não foi feito para ser popular…
foi feito para ser confiável quando ninguém pode errar

Enquanto outros bancos nasceram para aplicações,
👉 Db2 nasceu para instituições

---

🧱 CAPÍTULO 2 — O QUE É DB2 NO MUNDO REAL

Vamos simplificar brutalmente:

👉 Db2 = gerenciador de estado confiável

---

💡 Não é só banco

Ele cuida de:

• consistência (ACID)
• concorrência (locking)
• recuperação (logging + recovery)
• performance (optimizer absurdo)

---

💻 Exemplo COBOL raiz

EXEC SQL
   UPDATE CONTA
   SET SALDO = SALDO - :VALOR
   WHERE ID = :ID
END-EXEC

👉 Parece simples…

Mas por trás disso o Db2:

• trava registros 🔒
• registra log 📝
• garante rollback 🔁
• otimiza acesso ⚡

---

💀 Insight Bellacosa

“Você escreve SQL…
o Db2 executa uma coreografia complexa que você nem vê.”

---

⚙️ CAPÍTULO 3 — DB2 NO IBM z17 (O QUE MUDA)

No z17, Db2 não está sozinho.

Ele trabalha integrado com:

• CICS
• RACF
• WLM
• Parallel Sysplex

---

🔥 Resultado

👉 Você tem:

• escalabilidade horizontal
• altíssima disponibilidade
• latência mínima

---

💣 Easter egg técnico

Um Db2 mal tunado no z/OS não só fica lento…
ele aumenta o custo do mainframe 💸

---

🔄 CAPÍTULO 4 — COMO DB2 PENSA (E VOCÊ NÃO PERCEBE)

Quando você roda:

SELECT * FROM CLIENTE WHERE ID = 10;

👉 Db2 não executa direto.

Ele:

1. Analisa estatísticas (RUNSTATS)
2. Escolhe plano (optimizer)
3. Decide índice vs scan
4. Define estratégia de acesso

---

💀 Insight crítico

“Db2 não executa sua query…
ele decide COMO executar.”

---

🔬 CAPÍTULO 5 — PASSO A PASSO REAL (COBOL + DB2)

---

🧩 Fluxo real

1. COBOL chama SQL
2. DBRM é usado
3. Package executa
4. Db2 processa
5. Resultado retorna

---

💻 Exemplo completo mental

EXEC SQL
   SELECT NOME
   INTO :WS-NOME
   FROM CLIENTE
   WHERE ID = :WS-ID
END-EXEC

---

🔥 O que acontece por trás:

• acesso via índice
• lock aplicado
• leitura buffer pool
• retorno otimizado

---

💀 Insight

“Seu programa parece simples…
o Db2 está fazendo engenharia de alta complexidade.”

---

🧠 CAPÍTULO 6 — FEATURES QUE DEV COBOL IGNORA (E NÃO DEVERIA)

---

⏳ Time Travel Query

Consultar passado:

SELECT * FROM CLIENTE
FOR SYSTEM_TIME AS OF '2020-01-01';

👉 Auditoria sem esforço

---

⚡ MQT (Materialized Query Table)

• pré-calcula resultado
• acelera relatórios

---

🔄 Continuous Ingest

• dados entrando sem travar sistema

---

🤖 Db2 AI (z/OS)

• tuning automático
• previsão de problemas

---

💀 Insight

“Se você não usa essas features…
você está usando só 30% do Db2.”

---

🔐 CAPÍTULO 7 — LOCKING (O PONTO QUE MAIS QUEBRA SISTEMA)

---

💡 O problema

Dois programas acessando o mesmo dado.

---

💥 Resultado possível

• lock
• wait
• deadlock 💀

---

💻 Exemplo clássico

Programa A trava linha
Programa B espera
Sistema degrada

---

💀 Insight definitivo

“A maioria dos problemas de produção não é SQL…
é concorrência mal entendida.”

---

🧠 CAPÍTULO 8 — DB2 NÃO É LEGADO

Vamos acabar com esse mito.

---

❌ Visão errada

“Db2 é coisa antiga”

---

✅ Realidade

Db2 hoje tem:

• REST API
• JSON
• AI
• integração cloud

---

💀 Insight

“Db2 não ficou para trás…
ele simplesmente não fez barulho.”

---

🔥 CAPÍTULO FINAL — A VERDADE QUE NINGUÉM TE CONTA

Se você trabalha com COBOL + Db2:

👉 Você não está mantendo legado

👉 Você está operando infraestrutura crítica global

---

💣 Frase final estilo Bellacosa

“Enquanto o mundo fala de microservices…
o Db2 continua garantindo que o dinheiro chegue no destino.”

 

☕💣 Lab: SEU PRIMEIRO PLANTÃO NO MAINFRAME — LABORATÓRIO COMPLETO DE LÓGICA DE PROGRAMAÇÃO IBM Z PARA INICIANTES 💣☕

 

Bellacosa Mainframe Laboratorio de Logica de Programação Mainframe

☕💣 “SEU PRIMEIRO PLANTÃO NO MAINFRAME” — LABORATÓRIO COMPLETO DE LÓGICA DE PROGRAMAÇÃO IBM Z PARA INICIANTES 💣☕

Aprenda a pensar como um programador de alta plataforma antes mesmo de dominar COBOL

---

🔥 OBJETIVO DO LABORATÓRIO

Neste laboratório você irá aprender:

✅ Como pensar em lógica Mainframe
✅ Como funciona o raciocínio batch
✅ Variáveis
✅ Validações
✅ Estruturas de repetição
✅ Sections e Paragraphs
✅ Procedures
✅ Subrotinas
✅ Modularização
✅ Boas práticas de alta plataforma
✅ Erros clássicos de iniciantes
✅ Como programadores IBM Z organizam sistemas reais

---

☕ CENÁRIO DO LABORATÓRIO

Você foi contratado para trabalhar em um banco.

Sua missão:

💣 PROCESSAR UM ARQUIVO DE CLIENTES

Cada registro possui:

NOME
IDADE
SALDO
STATUS

O programa deve:

1. Ler registros

2. Validar dados

3. Calcular bônus

4. Gerar relatório

5. Exibir totais

---

🔥 PRIMEIRA LIÇÃO — PENSAR COMO MAINFRAME

Antes do código:

☕ O PROGRAMADOR MAINFRAME PENSA EM FLUXO

---

Entrada

Arquivo de clientes

---

Processamento

Validar
Calcular
Atualizar
Contabilizar

---

Saída

Relatório
Arquivo atualizado
Totais

---

💣 ISSO É O DNA DO BATCH

No Mainframe:

• entrada

• processamento

• saída

são sagrados.

---

☕ ETAPA 1 — DECLARANDO VARIÁVEIS

No Mainframe tudo precisa ser previsível.

---

🔥 TIPOS MAIS COMUNS

Texto

01 WS-NOME            PIC X(30).

---

Número inteiro

01 WS-IDADE           PIC 9(03).

---

Valores monetários

01 WS-SALDO           PIC 9(07)V99.

---

Indicadores lógicos

01 WS-FIM-ARQUIVO     PIC X VALUE 'N'.

---

☕ DICA BELLACOSA MAINFRAME

🔥 Nome de variável precisa explicar a intenção

RUIM:

01 A PIC 9(5).

BOM:

01 WS-TOTAL-CLIENTES PIC 9(5).

---

💣 O MAINFRAME SOBREVIVE POR LEGIBILIDADE

Quem mantém sistemas bancários precisa entender rápido o código.

---

☕ ETAPA 2 — ESTRUTURA DO PROGRAMA

O COBOL corporativo normalmente segue:

IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION

---

🔥 O CORAÇÃO DA LÓGICA

PROCEDURE DIVISION

Aqui vive:

• fluxo

• validação

• cálculos

• repetições

---

☕ ETAPA 3 — SECTIONS E PARAGRAPHS

SECTION

Agrupa grandes áreas do programa.

---

PARAGRAPH

Divide tarefas menores.

---

💣 EXEMPLO CORPORATIVO

PROCESSAMENTO-SECTION.

    PERFORM LE-ARQUIVO
    PERFORM VALIDA-DADOS
    PERFORM CALCULA-BONUS
    PERFORM GRAVA-RELATORIO.

---

☕ VANTAGEM DISSO

✅ Organização
✅ Manutenção
✅ Reuso
✅ Facilidade de debugging
✅ Clareza

---

🔥 ETAPA 4 — LEITURA DE REGISTROS

Todo batch gira em torno disso.

---

💣 MODELO CLÁSSICO MAINFRAME

PERFORM UNTIL WS-FIM-ARQUIVO = 'S'

    PERFORM LE-REGISTRO

    IF WS-FIM-ARQUIVO NOT = 'S'
       PERFORM PROCESSA-REGISTRO
    END-IF

END-PERFORM.

---

☕ O QUE O INICIANTE PRECISA ENTENDER

O batch:

• lê

• processa

• repete

até acabar o arquivo.

---

🔥 ETAPA 5 — LAÇOS DE REPETIÇÃO

☕ 1. PERFORM UNTIL

Mais usado em batch.

---

Exemplo

PERFORM UNTIL WS-FIM = 'S'

Repete até condição ser verdadeira.

---

☕ 2. PERFORM VARYING

Semelhante ao FOR.

---

Exemplo

PERFORM VARYING WS-INDICE FROM 1 BY 1
UNTIL WS-INDICE > 10

---

☕ 3. PERFORM TIMES

Executa quantidade fixa.

---

Exemplo

PERFORM 5 TIMES
   DISPLAY 'MAINFRAME'
END-PERFORM.

---

💣 ERRO CLÁSSICO DE INICIANTE

Criar loop infinito.

Exemplo perigoso:

PERFORM UNTIL WS-FIM = 'S'

Sem alterar WS-FIM.

Resultado:

• CPU presa

• JOB travado

• consumo absurdo

---

☕ ETAPA 6 — VALIDAÇÕES

🔥 MAINFRAME AMA VALIDAÇÃO

Sistemas bancários precisam ser paranoicos.

---

☕ TIPOS DE VALIDAÇÃO

---

Campo vazio

IF WS-NOME = SPACES

---

Número inválido

IF WS-IDADE IS NUMERIC

---

Faixa permitida

IF WS-IDADE >= 18

---

Status permitido

IF WS-STATUS = 'A'

---

💣 DICA CORPORATIVA

Sempre valide:

• entrada

• arquivo

• cálculo

• retorno

• integração

---

☕ ETAPA 7 — CÁLCULO DE BÔNUS

Regra:

Se saldo > 1000:

• bônus = 10%

---

🔥 EXEMPLO

IF WS-SALDO > 1000
   COMPUTE WS-BONUS = WS-SALDO * 0.10
ELSE
   MOVE 0 TO WS-BONUS
END-IF.

---

☕ ETAPA 8 — MODULARIZAÇÃO

💣 O SEGREDO DOS SISTEMAS GIGANTES

Separar responsabilidades.

---

🔥 EXEMPLO

LEITURA
VALIDAÇÃO
PROCESSAMENTO
RELATÓRIO
FINALIZAÇÃO

---

☕ ISSO REDUZ

✅ Bugs
✅ Retrabalho
✅ Confusão
✅ Dependência de pessoas

---

☕ ETAPA 9 — SUBROTINAS

Grandes empresas usam MUITO isso.

---

🔥 O QUE É SUBROTINA?

Programa auxiliar reutilizável.

---

Exemplo

CALCULA-JUROS
VALIDA-CPF
FORMATA-DATA

---

💣 VANTAGEM

Um único módulo pode ser usado por:

• banco

• cartão

• seguros

• investimentos

---

☕ CHAMADA DE SUBROTINA

CALL 'CALCJURO'

---

☕ ETAPA 10 — FUNÇÕES

Funções retornam valores.

---

🔥 EXEMPLO

FUNCTION CURRENT-DATE

---

☕ MUITAS FUNÇÕES MODERNAS COBOL

• data

• matemática

• string

• conversão

---

💣 O QUE O INICIANTE PRECISA EVITAR

---

🔥 1. GOTO EM EXCESSO

Código vira espaguete.

---

🔥 2. NOMES RUINS

Dificultam manutenção.

---

🔥 3. DUPLICAÇÃO

Mesmo código repetido.

---

🔥 4. FALTA DE VALIDAÇÃO

Causa bugs perigosos.

---

🔥 5. TENTAR FAZER TUDO NUM BLOCO

Divida em procedures.

---

☕ LABORATÓRIO PRÁTICO — FLUXO COMPLETO

💣 OBJETIVO

Processar 3 clientes.

---

🔥 PASSO 1 — INICIALIZAÇÃO

MOVE 0 TO WS-TOTAL
MOVE 'N' TO WS-FIM

---

🔥 PASSO 2 — LOOP PRINCIPAL

PERFORM UNTIL WS-FIM = 'S'

---

🔥 PASSO 3 — LEITURA

READ CLIENTE-ARQ

---

🔥 PASSO 4 — VALIDAÇÃO

IF WS-SALDO IS NUMERIC

---

🔥 PASSO 5 — PROCESSAMENTO

COMPUTE WS-BONUS = WS-SALDO * 0.10

---

🔥 PASSO 6 — ACUMULADOR

ADD WS-BONUS TO WS-TOTAL

---

🔥 PASSO 7 — RELATÓRIO

DISPLAY WS-TOTAL

---

☕ RESULTADO FINAL ESPERADO

O programa:

• processa clientes

• valida dados

• calcula bônus

• gera total

---

💣 ISSO É O INÍCIO DA ENGENHARIA MAINFRAME

Você acabou de praticar:

✅ lógica imperativa
✅ lógica procedural
✅ lógica estruturada

---

☕ COMO PROGRAMADORES MAINFRAME PENSAM?

Eles perguntam:

O dado entrou correto?
O arquivo está íntegro?
A rotina está modularizada?
O batch aguenta milhões de registros?
O operador conseguirá diagnosticar erro?

---

🔥 ISSO É ALTA PLATAFORMA

Não é apenas programar.

É:

• previsibilidade

• confiabilidade

• rastreabilidade

• engenharia

---

☕ CURIOSIDADES DO MUNDO REAL

---

💣 Muitos bancos ainda usam lógica escrita nos anos 80

E continuam funcionando.

---

💣 Um erro de loop pode consumir milhões em CPU

Por isso revisão é levada extremamente a sério.

---

💣 COBOL foi desenhado para manutenção humana

Legibilidade sempre foi prioridade.

---

💣 Grandes batches processam bilhões de registros

Tudo baseado nessa lógica.

---

☕ DESAFIO FINAL PARA O ALUNO

Tente adicionar:

✅ validação de idade
✅ tratamento de saldo negativo
✅ contador de clientes inválidos
✅ relatório final formatado
✅ cálculo de média

---

🔥 MISSÃO CONCLUÍDA

Você deu os primeiros passos no raciocínio que move:

• bancos

• governos

• cartões

• seguradoras

• bolsas financeiras

---

💣 A GRANDE VERDADE DO MAINFRAME

Antes de aprender comandos…

☕ O PROGRAMADOR IBM Z PRECISA APRENDER A PENSAR COMO ENGENHEIRO.

 

Bellacosa Mainframe e a Logica de Programação Mainframe

☕💣 “ANTES DO COBOL EXISTIA O CAOS” — A VERDADEIRA HISTÓRIA DA LÓGICA DE PROGRAMAÇÃO NO MAINFRAME IBM Z 💣☕

Do código selvagem ao raciocínio estruturado que move bancos, governos e o planeta inteiro

Quando alguém começa no universo Mainframe IBM Z, normalmente pensa:

• “Vou aprender COBOL”

• “Vou aprender JCL”

• “Vou aprender DB2”

• “Vou aprender CICS”

Mas existe algo MUITO mais importante antes disso:

🔥 APRENDER A PENSAR COMO UM PROGRAMADOR DE ALTA PLATAFORMA

E aqui está um segredo que poucos contam aos iniciantes:

Mainframe não é só tecnologia.

Mainframe é DISCIPLINA DE RACIOCÍNIO.

Os grandes sistemas bancários, cartões de crédito, previdência, folha de pagamento, companhias aéreas e bolsas financeiras sobreviveram décadas porque foram construídos sobre uma lógica extremamente organizada.

E essa organização nasceu de três grandes pilares:

---

☕ 1. O PARADIGMA IMPERATIVO — “FAÇA ISSO, DEPOIS AQUILO”

O começo de tudo

O paradigma imperativo é a forma mais antiga e natural de programação.

Ele funciona como uma receita de bolo:

1. Pegue farinha

2. Misture ovos

3. Ligue o forno

4. Asse por 40 minutos

Na programação:

1. Leia o arquivo
2. Valide o registro
3. Atualize o saldo
4. Grave o resultado

O computador executa instruções em sequência.

---

🔥 Origem histórica

O paradigma imperativo nasceu praticamente junto com os computadores comerciais.

Décadas de 1940 e 1950:

• Assembly

• Linguagem de máquina

• Primeiros compiladores

Tudo era baseado em:

“Mandar o computador fazer algo”

Daí o nome:

Imperativo = comando

---

☕ Como isso chegou ao Mainframe?

Os primeiros sistemas IBM comerciais funcionavam exatamente assim:

• Ler cartão perfurado

• Processar linha por linha

• Atualizar arquivos

• Imprimir relatórios

O mundo corporativo nasceu imperativo.

E até hoje grande parte do processamento batch do z/OS continua seguindo essa lógica.

---

💣 Exemplo simples de lógica imperativa

Objetivo:

Somar salários

Pseudocódigo:

LER FUNCIONARIO
SOMAR SALARIO
GRAVAR TOTAL

COBOL simplificado:

ADD SALARIO TO TOTAL-SALARIOS.

O foco está na ação.

---

☕ Curiosidade histórica

Os primeiros programadores literalmente desenhavam fluxos em papel gigantesco.

Fluxogramas eram fundamentais porque:

• Memória era caríssima

• CPU era limitada

• Um erro podia desperiçar horas de processamento

Por isso nasceu uma obsessão no Mainframe:

🔥 RACIOCINAR ANTES DE CODIFICAR

Algo que muitos ambientes modernos perderam.

---

☕ 2. O PARADIGMA PROCEDURAL — “DIVIDA O PROBLEMA”

Com o crescimento dos sistemas, surgiu um problema gigantesco:

O código virou um monstro impossível de manter

Programas tinham:

• 20 mil linhas

• 50 mil linhas

• 100 mil linhas

Sem organização.

Então surgiu a ideia revolucionária:

“Separar o programa em procedimentos”

---

🔥 O que é programação procedural?

É dividir o sistema em partes menores.

Exemplo:

PROCEDIMENTO-VALIDA-CLIENTE
PROCEDIMENTO-CALCULA-JUROS
PROCEDIMENTO-GRAVA-ARQUIVO

Cada parte faz uma tarefa específica.

---

☕ Isso mudou o Mainframe para sempre

O COBOL abraçou completamente o paradigma procedural.

Por isso existem:

• SECTION

• PARAGRAPH

• PERFORM

Exemplo clássico:

PERFORM CALCULA-TOTAL.
PERFORM IMPRIME-RELATORIO.

---

💣 O nascimento do “programador corporativo”

Aqui nasceu o conceito moderno de desenvolvimento empresarial.

Antes:

• um programador fazia tudo

Depois:

• equipes dividiam responsabilidades

• módulos eram reaproveitados

• manutenção ficou possível

Isso permitiu o crescimento dos bancos nos anos 70 e 80.

---

☕ Exemplo prático procedural

Sistema de folha de pagamento

Divisão lógica:

1. Ler funcionário
2. Calcular INSS
3. Calcular IR
4. Calcular salário líquido
5. Gravar resultado

Cada bloco vira um procedimento.

---

🔥 Exemplo COBOL

PERFORM LE-FUNCIONARIO
PERFORM CALCULA-INSS
PERFORM CALCULA-IR
PERFORM CALCULA-LIQUIDO
PERFORM GRAVA-ARQUIVO

Observe:

O programa ficou legível

E legibilidade no Mainframe vale ouro.

---

☕ Curiosidade importante

Muitos sistemas bancários antigos ainda possuem procedimentos escritos nos anos 80 rodando ATÉ HOJE.

E continuam funcionando porque a estrutura procedural ajudou na manutenção.

Isso é um dos motivos pelos quais:

Mainframe envelhece melhor que muita plataforma moderna.

---

☕ 3. O PARADIGMA PROCEDURAL ESTRUTURADO — “PAREM DE USAR GOTO”

Aqui entramos numa das maiores revoluções da computação.

Durante décadas, programas eram cheios de:

GOTO
JUMP
DESVIO
SALTO

Isso criava o famoso:

💣 “SPAGHETTI CODE”

Código impossível de entender.

---

🔥 O problema do GOTO

Imagine isto:

SE ERRO VAI PRA LINHA 900
SE SUCESSO VAI PRA 1200
SE FALHA VOLTA PRA 300

Ninguém entendia nada.

Sistemas corporativos viravam labirintos.

---

☕ Surge a programação estruturada

Nos anos 60 e 70, cientistas como:

• Edsger Dijkstra

• Niklaus Wirth

começaram uma revolução:

“Programas devem ter estrutura lógica clara”

---

🔥 Conceitos fundamentais

A programação estruturada trouxe:

Sequência

FAÇA A
FAÇA B
FAÇA C

---

Decisão

SE SALDO < 0
   COBRAR TAXA
SENAO
   CONTINUAR

---

Repetição

ENQUANTO HOUVER REGISTRO
   PROCESSAR

---

☕ Isso mudou o COBOL moderno

O COBOL começou a abandonar:

GO TO ERRO.

e passou a usar:

IF ERRO
   PERFORM TRATA-ERRO
END-IF

---

💣 O nascimento da manutenção moderna

A programação estruturada permitiu:

• menor número de bugs

• manutenção segura

• auditoria

• rastreabilidade

• estabilidade bancária

Sem isso:

• internet banking seria inviável

• PIX seria inviável

• processamento massivo seria caótico

---

☕ Exemplo estruturado em COBOL

Antes (caótico)

IF SALDO LESS THAN ZERO
   GO TO ERRO.

---

Depois (estruturado)

IF SALDO < ZERO
   PERFORM TRATA-ERRO
ELSE
   PERFORM PROCESSA-CONTA
END-IF

Muito mais claro.

---

🔥 O grande segredo do Mainframe

O Mainframe não sobreviveu décadas por acaso.

Ele sobreviveu porque criou uma cultura baseada em:

• previsibilidade

• organização

• rastreabilidade

• clareza

• controle

Isso nasceu diretamente da programação estruturada.

---

☕ COMO UM INICIANTE DEVE ESTUDAR LÓGICA MAINFRAME?

Aqui está uma sequência extremamente poderosa.

---

🔥 ETAPA 1 — PENSAR EM FLUXO

Antes de escrever COBOL:

Pergunte:

O que entra?
O que processa?
O que sai?

Esse é o DNA do batch.

---

🔥 ETAPA 2 — DIVIDIR O PROBLEMA

Nunca tente resolver tudo de uma vez.

Separe:

• leitura

• validação

• cálculo

• gravação

• relatório

---

🔥 ETAPA 3 — ELIMINAR CAOS

Evite:

• desvios desnecessários

• lógica duplicada

• código confuso

---

🔥 ETAPA 4 — ESCREVER PARA O FUTURO

No Mainframe:

Você não escreve código para hoje.

Você escreve código que alguém manterá em 2045.

Esse pensamento muda tudo.

---

☕ EXEMPLO REAL DE RACIOCÍNIO MAINFRAME

Imagine um processamento bancário noturno.

Entrada

Arquivo com:

• contas

• saldos

• movimentações

---

Processamento

O sistema:

1. lê registro

2. valida dados

3. calcula juros

4. aplica tarifas

5. atualiza saldo

6. grava resultado

7. gera relatório

---

🔥 ISSO É LÓGICA MAINFRAME

Fluxo.
Controle.
Previsibilidade.

Não existe “mágica”.

Existe engenharia.

---

☕ CURIOSIDADES QUE POUCOS INICIANTES SABEM

💣 COBOL foi criado para legibilidade humana

A ideia era que gestores conseguissem ler partes do código.

Por isso comandos parecem inglês.

---

💣 O GOTO quase destruiu sistemas corporativos

Houve programas tão caóticos que ninguém conseguia corrigir bugs sem quebrar outra coisa.

---

💣 Mainframe ajudou a criar engenharia de software moderna

Muitos conceitos de:

• modularização

• auditoria

• processamento seguro

• versionamento lógico

amadureceram em ambientes corporativos IBM.

---

💣 Batch influenciou computação moderna

Pipelines modernos, ETL, processamento distribuído e até workflows cloud possuem heranças conceituais do batch mainframe.

---

🔥 DIFERENÇA ENTRE OS 3 PARADIGMAS

Paradigma	Ideia Central	Problema Resolvido
Imperativo	Mandar executar	Fazer o computador trabalhar
Procedural	Dividir tarefas	Organizar sistemas
Estruturado	Controlar fluxo	Evitar caos

---

☕ O QUE O INICIANTE PRECISA ENTENDER

Aprender COBOL sem lógica é perigoso.

Porque você vira:

“digitador de sintaxe”

Mas o mercado precisa de:

🔥 PROFISSIONAIS QUE ENTENDEM PROCESSAMENTO CORPORATIVO

Quem domina lógica:

• entende batch

• entende online

• entende integração

• entende performance

• entende debugging

• entende negócios

---

💣 A GRANDE VERDADE SOBRE O MAINFRAME

O Mainframe não é antigo porque usa COBOL.

O Mainframe é DURADOURO porque foi construído em cima de princípios sólidos de engenharia.

E esses princípios começam aqui:

• paradigma imperativo

• paradigma procedural

• programação estruturada

---

☕ CONCLUSÃO — O DIA EM QUE VOCÊ COMEÇA A “PENSAR MAINFRAME”

O verdadeiro programador de alta plataforma não é aquele que decora comandos.

É aquele que consegue olhar um problema empresarial gigante e pensar:

entrada
processamento
controle
segurança
saída
rastreabilidade

Quando isso acontece…

🔥 VOCÊ PAROU DE APRENDER COBOL

E COMEÇOU A APRENDER ENGENHARIA DE SOFTWARE CORPORATIVA.

 

Bellacosa Mainframe dominando o cics dicas e truques para padawans

Um Café no Bellacosa Mainframe

2,167 subscribers

Dominando o CICS: Dicas Essenciais para um DEV Jr em Mainframe

Bellacosa Mainframe

4,424 followers

July 23, 2025

Salve jovem padawan, continuando nosso caminho explorando a Alta Plataforma, compartilhando algumas histórias, causos e curiosidade. Além claro de dicas técnicas para evoluir na Stack Mainframe. Este artigo pretende apresentar mais detalhes do OLTP.

O CICS é o coração transacional de milhares de sistemas corporativos pelo mundo. Por trás das aplicações bancárias, financeiras, de seguros e do setor público, o CICS garante integridade, disponibilidade e desempenho para aplicações críticas. Trabalhar bem com CICS é mais do que saber programar em COBOL: exige boas práticas, sensibilidade técnica e visão de arquitetura.

Aqui vão 10 dicas práticas e estratégicas para você se desenrascar no uso do CICS no seu dia a dia:

---

1. Conheça a Estrutura do EIB (Execute Interface Block)

Saber conhecer todas as funcionalidades do CICS, ajuda a criar novas estrategias para solucionar as demandas. Saiba que todo programa CICS, seja em COBOL, PLI ou Natural tem acesso a uma estrutura automática chamada EIB, que guarda informações como:

• EIBDATE – Data atual
• EIBTIME – Horário de início da transação
• EIBTRNID – ID da transação
• EIBCPOSN – Código de posição do cursor

Dica: Use essas variáveis para rastrear execuções e criar logs úteis para debugging sem poluir seus programas com variáveis auxiliares.

---

2. Use Comandos CICS com Tratamento de Erros

Além dos bugs traps do COBOL, o CICS oferece soluções para controlar erros. Lembre-se disso uma anomalia deve ser tratada em código, não deixe o Z/OS trata-la para você, acredite em mim, surpresas desagradáveis aparecem. Nunca subestime um EXEC CICS RECEIVE, WRITE, SEND ou READ sem o devido HANDLE CONDITION.

Dica: Sempre implemente tratamento para NOTFND, MAPFAIL, PGMIDERR e SYSIDERR, mesmo em programas simples.

---

3. Modularize Programas com Comarea e Channels

Separe seu programa por SECTIONs,. cada estrutura em sua seção, assim fica mais facil a manutenção e evoluções. Evite programões monolíticos. Quebre lógicas complexas em subprogramas usando COMMAREA ou, em sistemas modernos, CHANNELS & CONTAINERS.

Dica: Channels são ideais para novos programas, com mais de um container e suporte a dados maiores que 32k.

---

4. Use o CEDA com Consciência.

Na linha de comando do CICS, existem muitas ferramentas, que devemos conhecer e utilizar para estarmos no "Estado da Arte" na codificação de programas Online. O CEDA é o utilitário de administração de recursos do CICS. Ao registrar mapas BMS, programas ou transações:

Dica: Sempre preencha os campos:

• Group: para identificar o módulo
• Language: COBOL, PLI, etc.
• Dynam: YES para programas que serão carregados sob demanda
• Use Newcopy: Após compilar, não esqueça de dar CEMT SET PROGRAM(PROGNAME) NEW

---

5. Use o CEMT para Investigar em Tempo Real

Lembre-se sempre o programa compilado vai para a Loadlib do CICS, o programa na memoria ainda é a versão antiga, por isso devemos fazer o REFRESH manualmente. O comando CEMT permite administrar e consultar o status de quase tudo no CICS e atualizar para a versão mais recente da Loadlib. Alguns exemplos:

• CEMT I TRANS(TRN1) – Consulta transação
• CEMT I PROG(PROG1) – Consulta programa
• CEMT SET PROG(PROG1) NEW – Atualiza módulo compilado, REFRESH.

Dica: Automatize comandos CEMT via scripts em macros de terminal ou CLISTs úteis para refresh em lote.

---

6. Atente-se à Segurança: TransID e Programas

Todo cuidado é pouco. Devemos codificar prevendo o passo-a-passo do usuario, não deixando caminhos alternativos aberto. Bloqueando possíveis injeção de código e usando e abusando do RACF. Programação defensiva e com segurança em CICS não é só papel do RACF. Certifique-se de:

• Definir programas com EXECUTION KEY(CICS), quando possível
• Restringir transações via RACF profiles (FACILITY, SURROGAT, etc.)
• Evitar deixar transações expostas como CEMT, CICS, CSMT

---

7. Mapeie o Fluxo com Ferramentas como InterTest ou Abend-AID

Dica: Use ferramentas como InterTest para depuração interativa e Abend-AID para leitura de dumps mais amigável, com call-stack, EIB, COMMAREA decodificada, etc.

---

8. Mantenha Seus Mapas BMS Atualizados

Sempre que alterar campos em uma tela, recompilar o BMS e não esquecer:

• Executar a assemblagem (DFHMSD)
• Atualizar o CEDA
• Dar NEWCOPY no programa associado

Dica: Gere mapa simbólico .SYM para usar como COPY no COBOL – garante alinhamento com os nomes dos campos.

---

9. Use Transações Utilitárias a seu favor

• CECI – Execução interativa de comandos
• CECS – Exibe o status dos comandos
• CEBR – Exibe conteúdo de TS/TD Queues

Dica: Faça testes rápidos com CECI EXEC CICS SEND TEXT ou WRITEQ TS para prototipagem.

---

10. Invista em Performance

• Prefira acesso a TSQ/TDQ local quando possível
• Use ENQ/DEQ para controle de concorrência leve
• Mantenha CICS region tunada com buffers e threads adequados
• Reuse COMMAREAs com responsabilidade, evitando sobrecarga de dados inúteis

---

Bônus: Curiosidades do CICS

• O CICS nasceu em 1969 para o setor bancário.
• O nome "CICS" é pronunciado como "Kiks".
• É o transacional mais usado no mundo, rodando bilhões de transações por dia.

---

Conclusão

Chegamos ao final desta pequena jornada, visite sempre nossa Newsletter Um Café no Bellacosa Mainframe, procuro responder pedidos, solicitações e melhorar sempre. Caso encontre algo, que discorde, entre em contato, esse é um trabalho em curso, de tempos em tempos, reviso, incluindo mais assuntos e corrigindo algumas gralhas, que sismam em aparecer.

Concluindo e pense com carinho, dominar o CICS é essencial para qualquer analista de sistemas z/OS. Ele vai muito além da tela verde e do COBOL: é um ecossistema poderoso, que exige disciplina, segurança, performance e organização. Ao aplicar essas dicas, você entrega sistemas mais robustos e confiáveis, e se destaca como profissional Mainframe.