Descubra o que foi/é a Crise do Software.

Do que estou falando? Do caos atrás dos teclados, devido a instabilidade dos primeiros anos da computação com softwares imprecisos e os gastos milionários em CPDS. Esse termo foi cunhado na década de 70 do século passado e até hoje motiva muita discussão entre acadêmicos e profissionais.
Leia na InTEGRA

 

Bellacosa Mainframe fala sobre o legado Dijkstra : Structured Programming

🧠 Structured Programming (Dijkstra) — A Revolução Silenciosa que Salvou o Software

☕ Um Café no Bellacosa Mainframe

Nos primórdios da programação, escrever código era mais parecido com montar uma gambiarra elétrica do que com engenharia. Fios cruzados, saltos imprevisíveis e um único erro podia derrubar tudo. Foi nesse caos que surgiu uma ideia simples — e revolucionária:

💡 Programas deveriam ser estruturados, previsíveis e compreensíveis.

O nome por trás dessa virada?

👉 Edsger W. Dijkstra — um dos maiores gênios da computação.

---

🏛️ Antes da Revolução: O Velho Oeste do Código

Nos anos 50 e início dos 60:

• Programas eram gigantescos blocos lineares

• Cheios de saltos incondicionais

• Manutenção era um pesadelo

• Bugs eram quase impossíveis de rastrear

O principal culpado? 😈

👉 O famigerado GOTO

Um comando que dizia:

“Pare o que está fazendo e vá executar ali no meio do programa.”

Resultado: o famoso spaghetti code 🍝

---

💣 A Carta que Mudou Tudo

Em 1968, Dijkstra publicou uma carta histórica:

👉 “Go To Statement Considered Harmful”

Essa publicação virou um terremoto intelectual na área.

Ele não estava apenas criticando um comando — estava propondo uma nova forma de pensar software.

---

🧱 O Conceito Central: Programas Devem Ter Estrutura

Structured Programming defende que todo programa pode ser construído usando apenas três estruturas de controle:

1️⃣ Sequência

Executar instruções na ordem.

A
B
C

---

2️⃣ Seleção (Decisão)

IF condição
   A
ELSE
   B
END-IF

---

3️⃣ Iteração (Repetição)

WHILE condição
   A
END-WHILE

---

💡 Só isso. Sem saltos caóticos.

---

🏗️ O Impacto no Mainframe

Folha de Codificacao COBOL

Terminal 3270

Programa COBOL

Structured Programming influenciou diretamente:

• COBOL moderno (COBOL-74 em diante)

• Pascal (projetado para ensino estruturado)

• C

• Ada

• praticamente todas as linguagens posteriores

No COBOL, surgiram práticas como:

• PERFORM estruturado

• END-IF, END-PERFORM

• eliminação de GO TO sempre que possível

💬 Nos ambientes corporativos, isso foi decisivo para sistemas críticos sobreviverem décadas.

---

☕ Comentário Bellacosa Mainframe

Se você já abriu um programa legado cheio de:

GO TO ERRO-999
GO TO SAIDA
GO TO VOLTA-LOOP
GO TO TRATA-ABEND

Você sabe exatamente por que Dijkstra virou uma lenda 😅

Structured Programming não é frescura acadêmica.

👉 É o que permite um sistema bancário rodar 40 anos sem colapsar.

---

🕵️ Curiosidades e Bastidores

🧩 1) Dijkstra odiava computadores “bagunçados”

Ele acreditava que programação deveria ser uma disciplina matemática rigorosa.

Chegou a dizer que:

“Testar pode mostrar a presença de bugs, nunca sua ausência.”

---

✍️ 2) Ele escrevia à mão

Sim — muitos de seus algoritmos eram desenvolvidos no papel antes de qualquer implementação.

---

🧮 3) Também criou o algoritmo de caminho mínimo

👉 O famoso Algoritmo de Dijkstra, base de roteamento e GPS.

---

🧨 4) Nem todo mundo gostou da crítica ao GOTO

Programadores da época reagiram com:

• indignação

• sarcasmo

• artigos contra

• debates acalorados

Hoje parece óbvio. Na época, foi uma guerra cultural.

---

🐣 Easter Egg Mainframe

Mesmo em sistemas altamente estruturados…

👉 GO TO nunca morreu completamente.

Em COBOL legado, ele aparece como:

• fuga de erro

• tratamento de exceções improvisado

• controle de fluxo antigo

• patches históricos

É o equivalente ao:

“Não encoste nisso que está funcionando.”

---

🤫 Fofoquice Histórica

Dijkstra não gostava de popularização excessiva da programação.

Ele acreditava que:

👉 nem todos deveriam programar
👉 programação é atividade intelectual profunda
👉 más práticas se espalham rápido demais

Hoje, com milhões de devs no mundo… imagine o que ele diria 😄

---

🚀 Por que isso ainda importa HOJE?

Structured Programming é a base de:

• Clean Code

• Arquitetura de Software

• Boas práticas corporativas

• Programação orientada a objetos

• Sistemas críticos

• Segurança e confiabilidade

Sem essa revolução, software moderno seria inviável.

---

✅ Conclusão

Structured Programming não é apenas um capítulo da história.

👉 É o alicerce invisível de praticamente todo software sério já escrito.

No mundo mainframe, especialmente, ela foi a diferença entre:

💀 sistemas incontroláveis
e
🏦 infraestruturas que sustentam economias inteiras

🔥 PERFORM no COBOL: você manda ou ele manda em você?

 

Bellacosa Mainframe apresenta o comando Perform em COBOL

🔥 PERFORM no COBOL: você manda ou ele manda em você?

(Um café no Bellacosa Mainframe, para padawans e cavaleiros Jedi do z/OS)

Você já deu o spoiler certo: PERFORM é o maestro do COBOL.
Quem domina PERFORM escreve código legível, previsível, auditável e aceito em produção.
Quem não domina… acaba criando um GO TO disfarçado com terno e gravata 😅

Vamos organizar, aprofundar e elevar o nível do que você trouxe — com exemplos reais, pegadinhas, DB2, CICS e dicas de campo.

---

COBOL e o Perform

🧠 Origem e filosofia do PERFORM

Nos anos 70, COBOL sofreu com o “spaghetti code” (muito GO TO).
O PERFORM surgiu como a resposta estruturada, permitindo:

• Modularidade

• Fluxo previsível

• Testabilidade

• Facilidade de manutenção (sim, o auditor agradece)

👉 Regra de ouro mainframe:

“Se dá pra fazer com PERFORM, NÃO use GO TO.”

---

Comando Perform e suas variações em COBOL

1️⃣ PERFORM Simples — chamada limpa e direta

📌 O que faz

Executa um parágrafo uma única vez.

PERFORM 0100-CALCULA-IMPOSTO

🧪 Exemplo real

0100-CALCULA-IMPOSTO.
    COMPUTE WS-IMPOSTO = WS-VALOR * 0.15.
0100-EXIT.
    EXIT.

💡 Dica Bellacosa

• Sempre crie o -EXIT

• Facilita debug, tracing e manutenção futura

---

2️⃣ PERFORM VARYING — o FOR do COBOL

📌 O que faz

Loop com contador explícito.

PERFORM VARYING WS-CONT FROM 1 BY 1
 UNTIL WS-CONT > 10
    PERFORM 0300-PROCESSA-REGISTRO
END-PERFORM

🧪 Exemplo com tabela interna

PERFORM VARYING IDX FROM 1 BY 1
 UNTIL IDX > WS-QTDE
    MOVE WS-TABELA(IDX) TO WS-REG
    PERFORM 0400-VALIDA-DADO
END-PERFORM

⚠️ Pegadinha clássica

❌ Alterar WS-CONT dentro do parágrafo executado
✔️ Deixe o controle só no PERFORM

---

3️⃣ PERFORM UNTIL — o rei da leitura de arquivos

📌 O que faz

Repete até a condição ser verdadeira
(atenção: condição é avaliada antes)

PERFORM UNTIL WS-FIM = 'SIM'
    READ ARQ-ENTRADA
        AT END MOVE 'SIM' TO WS-FIM
        NOT AT END
            PERFORM 0500-PROCESSA-REG
    END-READ
END-PERFORM

🧠 Padrão mainframe clássico

• Batch

• VSAM

• Sequential files

• DB2 cursors (já já)

---

4️⃣ PERFORM TIMES — simples, direto e elegante

📌 O que faz

Executa um bloco N vezes, sem contador explícito.

PERFORM 12 TIMES
    ADD 1 TO WS-TOTAL
END-PERFORM

📌 Quando usar

• Simulações

• Inicializações

• Processos fixos

❌ Quando NÃO usar

• Quando você precisa do índice (use VARYING)

---

5️⃣ PERFORM THRU — tradição mainframe raiz 🧓💾

📌 O que faz

Executa uma sequência contínua de parágrafos

PERFORM 1000-INICIALIZA
   THRU 1099-INICIALIZA-EXIT

🧪 Estrutura clássica

1000-INICIALIZA.
    OPEN INPUT ARQ-ENTRADA
    PERFORM 1100-CARREGA-PARAMETROS.

1099-INICIALIZA-EXIT.
    EXIT.

⚠️ Regra sagrada

Nunca coloque código fora da sequência THRU

Senão…
🔥 comportamento imprevisível
🔥 bugs fantasma
🔥 chamado em produção às 3h da manhã

---

🟦 PERFORM + DB2 (exemplo real)

Cursor com PERFORM UNTIL

PERFORM UNTIL SQLCODE NOT = 0
    EXEC SQL
        FETCH C1 INTO :WS-COL1, :WS-COL2
    END-EXEC

    IF SQLCODE = 0
        PERFORM 2000-PROCESSA-LINHA
    END-IF
END-PERFORM

👉 Padrão de ouro DB2 COBOL

---

🟩 PERFORM + CICS

PERFORM 3000-VALIDA-MAP
PERFORM 3100-PROCESSA-NEGOCIO
PERFORM 3200-ENVIA-RESPOSTA

✔ Modular
✔ Legível
✔ Fácil de testar

---

🧨 Erros comuns em produção

Erro	Impacto
PERFORM THRU mal delimitado	Execução inesperada
Alterar contador no parágrafo	Loop infinito
Falta de EXIT	Debug caótico
GO TO misturado com PERFORM	Código ilegível

---

🧙 Curiosidades & Easter Eggs

🥚 Em COBOL antigo, PERFORM THRU era o padrão absoluto
🥚 Auditores AMAM código com PERFORM bem estruturado
🥚 Muitos shops ainda proíbem GO TO por norma interna
🥚 PERFORM é um dos motivos do COBOL sobreviver tão bem até hoje

---

🎓 Regra final para padawans

Se você entende PERFORM, você entende o fluxo do COBOL.
Se entende o fluxo, domina Batch, DB2 e CICS.

 

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.