Bellacosa Mainframe conversa sobre a confusao semantica entre Logica e Paradigma

A Confusão Semântica que Atravessa Gerações de Programadores

Jovem padawan, muitos programadores antes de você ouviram que “lógica de programação” é um tipo de linguagem ou paradigma. Não é. Lógica é a forma de pensar; paradigma é a forma de construir.

A confusão nasceu nas salas de aula, onde simplificar ajuda a começar, mas deixa cicatrizes conceituais. Assim, gerações repetem termos imprecisos sem perceber.

Quando você distingue pensamento algorítmico de modelo estrutural, o código deixa de ser magia e vira engenharia. Entenda isso cedo e evitará debates inúteis, documentação confusa e decisões ruins de arquitetura. 

Clareza conceitual é uma arma poderosa na Força — e também na manutenção de sistemas que precisam sobreviver décadas.

🧠 1) “Lógica de programação” NÃO é um paradigma

“Lógica de programação” é um termo didático.

Ele se refere à capacidade de:

• decompor um problema

• definir passos ordenados

• usar condições e repetições

• estruturar algoritmos

Ou seja: é uma habilidade mental, não um modelo formal de linguagem.

Você pode usar lógica de programação em:

• C

• COBOL

• Python

• Java

• Assembly

• até planilhas 😄

👉 Portanto, lógica ≠ paradigma

---

🏛️ 2) Paradigma procedural é o termo técnico correto

Na teoria da computação, linguagens são classificadas por paradigmas.

O procedural é um deles.

✔️ Paradigma Procedural

Baseia-se em:

• sequência de instruções

• procedimentos / funções

• alteração de estado

• fluxo de controle explícito

Exemplos clássicos:

• C

• Pascal

• COBOL

• Fortran

• PL/I

• ALGOL

👉 Em COBOL, por exemplo, a PROCEDURE DIVISION é a essência procedural.

---

📚 3) Por que o ensino usa “lógica procedural”?

Principalmente por motivos pedagógicos:

🎓 A) Iniciantes não precisam de teoria de paradigmas

É mais simples dizer:

“Vamos aprender lógica de programação”

do que:

“Vamos estudar um paradigma imperativo/procedural”

---

🎓 B) Nem sempre usam uma linguagem “pura”

Cursos iniciais misturam:

• pseudocódigo

• fluxogramas

• Portugol

• Scratch

• Python básico

Fica difícil falar de paradigma formal.

---

🎓 C) O objetivo é aprender a pensar, não a linguagem

Antes de aprender:

• OOP

• Funcional

• Concorrente

• Declarativo

o aluno precisa aprender a resolver problemas passo a passo.

---

⚙️ 4) Relação com o paradigma imperativo

Tecnicamente, procedural é um subtipo de outro paradigma:

👉 Imperativo

Imperativo
   ├── Procedural
   └── Orientado a Objetos

Ambos usam:

• comandos

• estado mutável

• execução sequencial

---

🏆 5) No mundo mainframe isso é muito claro

COBOL clássico é procedural puro:

• fluxo top-down

• parágrafos e seções

• controle explícito

• pouca abstração estrutural

Embora o COBOL moderno suporte OO, a cultura mainframe ainda é fortemente procedural.

---

✅ Conclusão

Dizemos “lógica de programação procedural” por tradição educacional — mas o termo técnico correto é:

👉 Paradigma procedural

Resumo rápido:

• 🧠 Lógica de programação = habilidade de pensar algoritmicamente

• 🏛️ Paradigma procedural = modelo formal de construção de programas

• 🎓 O ensino simplifica a terminologia para iniciantes

COBOL Imperativo, Procedural e Procedural Estruturado

Três fases da mesma linguagem (e três estados de espírito no CPD)

Ao estilo Bellacosa Mainframe, servido quente no El Jefe Midnight Lunch

---

☕ Introdução: o mesmo COBOL, três mentalidades

Quem olha de fora acha que COBOL é tudo igual desde 1959. Quem viveu mainframe sabe: o COBOL mudou — não tanto na sintaxe, mas na forma de pensar.

Imperativo, Procedural e Procedural Estruturado não são dialetos oficiais escritos em pedra. São estágios evolutivos, reflexo direto de:

• Limitações de hardware

• Pressões de negócio

• Maturidade da engenharia de software

Entender essas diferenças é entender por que tanto código legado funciona… e por que outro tanto assombra equipes até hoje.

---

🧠 COBOL no modo Imperativo — o nascimento selvagem

📅 Quando surgiu

Final dos anos 50 e início dos 60, junto com o próprio COBOL.

🎯 Ideia central

“Faça exatamente isso. Agora isso. Agora pule para lá.”

O foco é comando direto. O programa é uma lista de ordens explícitas para a máquina.

🧩 Características

• Uso intenso de GO TO

• Fluxo não linear

• Dependência forte da ordem física do código

• Parágrafos longos e multifuncionais

🧨 Comentário Bellacosa

Era compreensível. Memória era cara, CPU era lenta e ninguém pensava em manutenção a longo prazo.

Funcionou ontem? Então não mexe.

🥚 Easter Egg

Muito código imperativo ainda roda em produção porque ninguém tem coragem de tocar.

---

🧠 COBOL Procedural — organização por rotinas

📅 Quando ganhou força

Anos 60 e 70, com sistemas maiores e equipes crescendo.

🎯 Ideia central

“Organize o programa em procedimentos reutilizáveis.”

Aqui surge a noção clara de rotinas, chamadas e retorno.

🧩 Características

• Uso intenso de PERFORM

• Divisão do programa em parágrafos

• Fluxo mais previsível

• Ainda aceita GO TO (e muita gente abusou)

⚠️ O perigo oculto

Procedural não é automaticamente estruturado.

Você pode ter um código procedural organizado e ainda assim caótico.

🥚 Easter Egg

Parágrafos chamados 9999-FIM ou EXIT-PROG são herança direta dessa fase.

---

🧠 COBOL Procedural Estruturado — quando o COBOL vira engenharia

📅 Quando surgiu

Final dos anos 70 e anos 80, influenciado pela programação estruturada (Dijkstra, Böhm & Jacopini).

🎯 Ideia central

“Fluxo previsível é mais importante que truque de performance.”

Aqui o COBOL ganha disciplina formal.

🧩 Características

• Eliminação prática do GO TO

• Uso sistemático de:

  • IF / END-IF

  • EVALUATE / END-EVALUATE

  • PERFORM UNTIL / END-PERFORM

• Parágrafos pequenos e coesos

• Código que se lê como um roteiro lógico

🏦 Razão de negócio

• Auditoria

• Confiabilidade

• Manutenção por décadas

Bancos e seguradoras exigiram esse padrão.

---

📊 Comparativo rápido

Estilo	Controle de fluxo	Manutenção	Risco
Imperativo	Caótico	Difícil	Alto
Procedural	Médio	Melhor	Médio
Procedural Estruturado	Previsível	Excelente	Baixo

---

🛠️ Passo a passo: migrando o pensamento

1️⃣ Pare de pensar em linhas, pense em fluxo

Pergunte:

• Onde começa?

• Onde decide?

• Onde termina?

2️⃣ Um parágrafo, uma responsabilidade

Se o nome precisa de “E”, “OU” e “TAMBÉM”… está grande demais.

3️⃣ Substitua IFs aninhados por EVALUATE

Mais legível, mais auditável.

4️⃣ Use PERFORM como se fosse chamada de função

Mesmo sem parâmetros formais, o conceito é o mesmo.

---

🔐 Segredos de veterano

🔹 Código estruturado reduz incidentes noturnos.

🔹 Auditor confia mais em código previsível do que em código “esperto”.

🔹 Performance se resolve depois; clareza primeiro.

🔹 Todo sistema legado parece ruim… até você entender o contexto em que nasceu.

---

🧾 Curiosidades de bastidor

• Muitos padrões internos de bancos proíbem GO TO há mais de 30 anos.

• Há programas imperativos mais antigos que seus mantenedores.

• COBOL estruturado influenciou diretamente padrões de codificação em PL/I e até Java.

---

🥚 Easter Eggs do CPD

🕰️ Parágrafos numerados (1000-INICIO) são fósseis vivos.

🐘 Compiladores modernos reclamam de GO TO, mas ainda aceitam — respeito aos ancestrais.

☕ Quanto mais estruturado o código, menos café o time consome em fechamento.

---

✅ Boas práticas Bellacosa Mainframe

✔ Evite GO TO como se fosse vazamento em produção
✔ Prefira clareza a micro-otimização
✔ Nomeie parágrafos com linguagem de negócio
✔ Estruture pensando no próximo mantenedor
✔ Código bom é código explicável

---

🌙 Conclusão: não é sobre sintaxe, é sobre mentalidade

Imperativo, Procedural e Procedural Estruturado contam a história da maturidade do software corporativo.

O COBOL não ficou velho.
Ele ficou responsável.

E no mundo mainframe, responsabilidade é o que mantém sistemas rodando…

sem glamour, sem barulho e sem falhar.

— Bellacosa Mainframe, direto do CPD para o El Jefe Midnight Lunch 🌙

 

COBOL Estruturado: disciplina, elegância e sobrevivência no mundo mainframe

Ao melhor estilo Bellacosa Mainframe, direto dos porões do CPD para o El Jefe Midnight Lunch

---

☕ Introdução: quando o COBOL aprendeu a pensar

Durante décadas, o COBOL foi injustamente carimbado como uma linguagem verborrágica, rígida e cheia de GOTOs selvagens pulando de parágrafo em parágrafo como gremlins em madrugada de fechamento mensal. O COBOL estruturado surge justamente como a vacina contra esse caos.

Mais do que uma evolução sintática, COBOL estruturado é postura, disciplina mental e, acima de tudo, respeito ao próximo programador — normalmente você mesmo daqui a 6 meses.

---

🧠 O que é COBOL Estruturado, afinal?

COBOL estruturado é a aplicação dos princípios da programação estruturada ao COBOL clássico:

• Nada de saltos caóticos com GO TO

• Fluxo lógico previsível

• Blocos com início, meio e fim bem definidos

Ele se apoia em três pilares universais:

1. Sequência – código executado em ordem natural

2. Seleção – decisões claras (IF, EVALUATE)

3. Iteração – repetição controlada (PERFORM UNTIL, PERFORM VARYING)

Se você domina isso, domina qualquer código mainframe.

---

📜 Por que o COBOL estruturado é mais legível?

Porque ele conta uma história.

Compare:

• Parágrafos pequenos e objetivos

• END-IF, END-PERFORM explícitos

• Nomes semânticos (CALCULA-TOTAL, VALIDA-CPF)

O código deixa de ser um labirinto e vira um manual técnico executável.

💡 Dica Bellacosa: se o código parece um romance russo, algo está errado.

---

🛠️ Passo a passo para escrever COBOL estruturado

1️⃣ Planeje antes de codar

Desenhe o fluxo:

• O que entra?

• Quais decisões existem?

• Onde o processamento termina?

2️⃣ Quebre tudo em parágrafos pequenos

Um parágrafo = uma responsabilidade.

Errado:

• PROCESSA-TUDO

Certo:

• LE-ARQUIVO

• VALIDA-DADOS

• CALCULA-VALORES

• GRAVA-SAIDA

3️⃣ Use PERFORM como se fosse uma chamada de função

PERFORM VALIDA-DADOS
PERFORM CALCULA-TOTAL

Isso é COBOL estruturado em sua forma mais pura.

4️⃣ Elimine GO TO (sem dó)

Se você precisa de GO TO, provavelmente:

• O parágrafo está grande demais

• O fluxo está mal pensado

---

🧪 Segredos que veteranos não contam

🔹 Menos é mais: COBOL estruturado prefere muitos parágrafos pequenos a poucos gigantes.

🔹 IF aninhado demais é cheiro de problema: use EVALUATE.

🔹 Comentários explicam o porquê, não o como:

* Validação exigida pelo Bacen após incidente de 2009

🔹 Código bem estruturado envelhece melhor que documentação externa.

---

🧾 Curiosidades de bastidor (fofoca técnica)

• O impulso pela programação estruturada veio forte nos anos 70, após sistemas críticos se tornarem impossíveis de manter.

• Grandes bancos só aceitaram novas rotinas COBOL sem GO TO.

• Há sistemas em produção hoje que seguem padrões estruturados criados nos anos 80 — e funcionam melhor que muito microserviço moderno.

---

🥚 Easter Eggs do mundo mainframe

🕵️‍♂️ Já reparou que muitos sistemas usam parágrafos chamados MAIN-PARA ou 0000-INICIO? Isso é herança direta da transição do COBOL não estruturado.

🐘 Alguns compiladores modernos avisam quando você usa GO TO. É o mainframe te julgando silenciosamente.

☕ Programadores COBOL estruturado costumam dormir melhor em fechamento contábil.

---

✅ Boas práticas Bellacosa Mainframe (anote!)

✔ Um parágrafo não deve passar de uma tela
✔ Nomeie tudo com significado de negócio
✔ Prefira EVALUATE a IF encadeado
✔ Evite variáveis globais desnecessárias
✔ Código deve ser lido como um roteiro lógico

---

🌙 Conclusão: COBOL estruturado não é velho — é sábio

COBOL estruturado é como um bom uísque: não precisa de modinha, precisa de respeito. Ele entrega previsibilidade, estabilidade e clareza — exatamente o que sistemas críticos exigem.

No fim das contas, não é sobre COBOL.
É sobre engenharia, disciplina e responsabilidade.

E como todo bom código mainframe…

Ele não faz barulho. Ele simplesmente funciona.

— Bellacosa Mainframe, servido à meia-noite no El Jefe Midnight Lunch 🌙

 

Bellacosa Mainframe e o terminador de escopo em cobol

O que é Terminador de Escopo em COBOL?

Os Terminadores de Escopo (Scope Terminators) são palavras-chave usadas para indicar explicitamente onde termina uma instrução COBOL.

Eles foram introduzidos para resolver um problema clássico dos programas antigos:

saber exatamente onde um comando termina.

---

Antes dos Terminadores de Escopo

Nas versões antigas do COBOL era comum encontrar:

IF WS-SALDO > 0
   DISPLAY 'CLIENTE ATIVO'
ELSE
   DISPLAY 'CLIENTE INATIVO'.

Quando a lógica crescia, surgiam dúvidas:

Qual IF pertence a qual ELSE?

---

Problema dos IFs Aninhados

Exemplo:

IF A = 1
   IF B = 2
      DISPLAY 'OK'
ELSE
   DISPLAY 'ERRO'

Pergunta:

O ELSE pertence ao IF A ou ao IF B?

Nem sempre fica claro.

---

Solução

A IBM e os fabricantes de compiladores introduziram:

Terminadores de Escopo

---

Principais Terminadores

Comando	Terminador
IF	END-IF
EVALUATE	END-EVALUATE
PERFORM	END-PERFORM
READ	END-READ
WRITE	END-WRITE
REWRITE	END-REWRITE
SEARCH	END-SEARCH
STRING	END-STRING
UNSTRING	END-UNSTRING
COMPUTE	END-COMPUTE
EXEC	END-EXEC

---

END-IF

O mais conhecido.

---

Exemplo

IF WS-SALDO > 0

   DISPLAY 'ATIVO'

ELSE

   DISPLAY 'INATIVO'

END-IF

Agora não existe dúvida.

---

END-EVALUATE

Fecha um EVALUATE.

EVALUATE WS-OPCAO

   WHEN 1
      DISPLAY 'CONSULTA'

   WHEN 2
      DISPLAY 'ALTERACAO'

END-EVALUATE

---

END-PERFORM

Fecha um PERFORM INLINE.

PERFORM UNTIL EOF = 'S'

   READ ARQCLI

END-PERFORM

---

END-READ

Fecha um READ.

READ ARQCLI

   AT END
      MOVE 'S' TO EOF

END-READ

---

END-WRITE

Fecha um WRITE.

WRITE REG-SAIDA

   INVALID KEY
      DISPLAY 'ERRO'

END-WRITE

---

END-REWRITE

Muito usado com VSAM.

REWRITE REG-CLIENTE

   INVALID KEY
      DISPLAY 'ERRO'

END-REWRITE

---

END-SEARCH

Usado em tabelas.

SEARCH WS-TABELA

   WHEN WS-CODIGO = WS-CHAVE
      DISPLAY 'ACHOU'

END-SEARCH

---

END-STRING

Usado em concatenação.

STRING

   WS-NOME
   WS-SOBRENOME

   INTO WS-NOME-COMP

END-STRING

---

END-UNSTRING

Usado para separar campos.

UNSTRING WS-LINHA

   DELIMITED BY ';'

   INTO WS-CAMPO1
        WS-CAMPO2

END-UNSTRING

---

END-COMPUTE

Fecha um COMPUTE.

COMPUTE WS-TOTAL =
        WS-A + WS-B

   ON SIZE ERROR
      DISPLAY 'ERRO'

END-COMPUTE

---

END-EXEC

Muito usado com:

• DB2;

• CICS;

• IMS;

• MQ.

---

Exemplo:

EXEC SQL

   SELECT NOME
     INTO :WS-NOME
     FROM CLIENTES

END-EXEC

---

Como funciona?

Visualmente:

COMANDO
   ↓
BLOCO
   ↓
END-COMANDO

---

Exemplo Completo

Sem terminadores:

IF A = 1
   IF B = 2
      DISPLAY 'OK'
ELSE
   DISPLAY 'ERRO'

Difícil de entender.

---

Com terminadores:

IF A = 1

   IF B = 2
      DISPLAY 'OK'
   ELSE
      DISPLAY 'ERRO'
   END-IF

END-IF

Muito mais claro.

---

Vantagens

Melhor legibilidade

---

Menos erros

---

Mais fácil manutenção

---

Menos ambiguidades

---

Facilita revisões de código

---

Programação Estruturada

Os terminadores de escopo foram um marco na evolução do COBOL estruturado.

Eles ajudaram a substituir o uso excessivo de:

GO TO

---

COBOL Moderno

Hoje praticamente todos os compiladores modernos recomendam:

END-IF
END-EVALUATE
END-PERFORM

em vez de depender apenas de pontos finais.

---

Curiosidades

1. Os primeiros programas COBOL não possuíam terminadores de escopo

---

2. Muitos sistemas antigos ainda utilizam apenas pontos finais

---

3. END-IF foi uma das maiores melhorias de legibilidade do COBOL

---

4. Grandes bancos exigem terminadores de escopo em seus padrões de desenvolvimento

---

Erros comuns de iniciantes

Esquecer END-IF

---

Esquecer END-EVALUATE

---

Misturar pontos finais com terminadores

---

Fechar blocos na ordem errada

---

Resumo rápido

Comando	Terminador
IF	END-IF
EVALUATE	END-EVALUATE
PERFORM	END-PERFORM
READ	END-READ
WRITE	END-WRITE
REWRITE	END-REWRITE
SEARCH	END-SEARCH
STRING	END-STRING
UNSTRING	END-UNSTRING
COMPUTE	END-COMPUTE
EXEC	END-EXEC

---

Conclusão

Os Terminadores de Escopo são palavras-chave que indicam explicitamente o final de comandos estruturados em COBOL. Eles aumentam a legibilidade, reduzem ambiguidades e são fundamentais para o desenvolvimento moderno de aplicações COBOL em ambientes Mainframe IBM Z, especialmente em sistemas que utilizam CICS, DB2, VSAM e processamento batch.

 

Bellacosa Mainframe e o paradigma de programacao procedural estruturado

O que é Paradigma de Programação Procedural Estruturado?

Quando estudamos:

• COBOL;

• C;

• PL/I;

• programação batch;

• desenvolvimento no mainframe;

um conceito muito importante aparece:

programação procedural estruturada.

Ela foi uma enorme evolução na história da computação corporativa.

---

Primeiro: o que significa “procedural”?

Programação procedural é:

organizar programas em procedimentos e rotinas.

Exemplo:

VALIDAR
CALCULAR
GERAR-RELATORIO

Cada parte executa:

uma tarefa específica.

---

Então o que significa “estruturada”?

Estruturada significa:

organizar o código de forma clara, previsível e controlada.

Ela evita:

• confusão;

• desvios excessivos;

• código caótico;

• spaghetti code.

---

Definição simples

Programação procedural estruturada é:

um paradigma procedural que usa estruturas organizadas de fluxo e modularização.

Ela busca:

• clareza;

• manutenção;

• organização;

• legibilidade.

---

Analogia simples

Imagine uma cidade.

---

Código não estruturado

Ruas sem organização.
Tudo confuso.

---

Código estruturado

Cidade organizada:

• avenidas;

• sinais;

• setores;

• fluxo lógico.

---

Origem histórica

Nos primeiros sistemas:

• Assembly;

• COBOL antigo;

• FORTRAN antigo;

era comum usar muitos:

GO TO

Isso criava programas extremamente difíceis de manter.

---

Então surgiu a programação estruturada

Com conceitos como:

• blocos;

• procedimentos;

• loops;

• IF;

• modularização.

---

Objetivo principal

Eliminar:

spaghetti code.

---

O que é spaghetti code?

Código cheio de:

• desvios;

• GO TO;

• saltos;

• fluxo confuso.

Parecendo:

um prato de espaguete.

---

Exemplo não estruturado

GO TO A100
GO TO B200
GO TO C300

Fluxo difícil de entender.

---

Exemplo estruturado

IF SALDO > 0
   PERFORM PROCESSA
ELSE
   PERFORM ERRO
END-IF

Muito mais organizado.

---

Estruturas fundamentais da programação estruturada

---

Sequência

Execução linear.

---

Decisão

Escolha de caminhos.

---

Repetição

Loops controlados.

---

Fluxo estruturado clássico

INICIO
 ↓
LER DADOS
 ↓
VALIDAR
 ↓
PROCESSAR
 ↓
GERAR SAÍDA
 ↓
FIM

---

Como isso aparece no COBOL?

Muito fortemente.

---

Exemplo COBOL estruturado

PERFORM UNTIL EOF = 'S'

   READ CLIENTE
      AT END
         MOVE 'S' TO EOF
      NOT AT END
         PERFORM PROCESSA-CLIENTE
   END-READ

END-PERFORM

---

Isso é estruturado porque:

• possui fluxo claro;

• evita GO TO;

• usa blocos organizados.

---

O que é modularização?

Dividir programa em partes menores.

---

Exemplo

VALIDAR-CLIENTE
CALCULAR-JUROS
GERAR-RELATORIO

---

Benefícios

• manutenção;

• reutilização;

• clareza;

• testes mais fáceis.

---

O que é bloco estruturado?

Código delimitado logicamente.

---

Exemplos COBOL

IF / END-IF

EVALUATE

PERFORM UNTIL

---

Antes da programação estruturada

Muito código tinha:

GO TO

em excesso.

---

Problema disso

Fluxo imprevisível.

---

Programação estruturada ajudou a:

• reduzir bugs;

• melhorar manutenção;

• aumentar confiabilidade.

---

O COBOL moderno é estruturado?

Sim.

Principalmente usando:

• END-IF;

• EVALUATE;

• PERFORM;

• inline PERFORM.

---

Exemplo batch estruturado

LER ARQUIVO
 ↓
VALIDAR
 ↓
CALCULAR
 ↓
ATUALIZAR DB2
 ↓
GERAR RELATÓRIO

---

Como isso ajuda no mainframe?

Mainframes processam:

• milhões;

• bilhões de registros.

Precisam de:

• estabilidade;

• clareza;

• manutenção segura.

---

Programação estruturada trouxe exatamente isso

---

Características da programação procedural estruturada

---

Fluxo previsível

---

Menos GO TO

---

Uso de procedimentos

---

Modularização

---

Blocos organizados

---

Facilidade manutenção

---

Legibilidade

---

Vantagens

---

Código mais limpo

---

Mais fácil de entender

---

Menos erros

---

Melhor debugging

---

Excelente para batch

---

Muito usada em COBOL

---

Desvantagens

---

Sistemas gigantes ainda podem ficar complexos

---

Exige disciplina de programação

---

Modularização ruim pode dificultar manutenção

---

Procedural estruturado vs procedural antigo

---

Antigo

Muito:

GO TO

---

Estruturado

Mais:

IF
PERFORM
EVALUATE

---

Procedural estruturado vs orientação a objetos

---

Estruturado

Organiza:

procedimentos.

---

OO

Organiza:

objetos/classes.

---

Curiosidades incríveis

1. A programação estruturada revolucionou o desenvolvimento corporativo

---

2. Grande parte do COBOL moderno segue princípios estruturados

---

3. Muitos sistemas bancários antigos passaram por “reestruturação” para remover GO TO

---

4. Estruturação ajudou muito na manutenção de sistemas gigantes

---

Erros comuns de iniciantes

---

1. Usar GO TO demais

---

2. Criar procedimentos enormes

---

3. Misturar lógica demais

---

4. Não modularizar

---

Dicas importantes

Use:

• PERFORM;

• IF;

• EVALUATE.

---

Evite GO TO excessivo

---

Divida lógica em pequenas rotinas

---

Organize fluxo claramente

---

Como isso aparece no dia a dia?

Praticamente em:

• COBOL;

• batch;

• DB2 procedural;

• faturamento;

• bancos;

• folha salarial.

---

Exemplo simplificado completo

MAIN
 ↓
LER CLIENTES
 ↓
VALIDAR
 ↓
CALCULAR
 ↓
ATUALIZAR DB2
 ↓
GERAR RELATÓRIO
 ↓
FIM

---

Resumo rápido

Conceito	Significado
Procedural	Baseado em procedimentos
Estruturado	Fluxo organizado
Modularização	Dividir programa
PERFORM	Executa rotina
IF	Decisão
GO TO	Desvio fluxo
Spaghetti Code	Código confuso

---

Conclusão

O paradigma de programação procedural estruturado organiza programas em procedimentos claros e fluxos previsíveis, reduzindo complexidade e facilitando manutenção.

Ele é a base do COBOL moderno e do processamento batch corporativo no ambiente mainframe IBM Z.