Mostrar mensagens com a etiqueta perform. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta perform. Mostrar todas as mensagens

domingo, 13 de setembro de 2015

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

 

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

https://i.ebayimg.com/images/g/UP4AAOSwjTlnBJCl/s-l1200.png
Folha de Codificacao COBOL
https://www.leapwork.com/hs-fs/hubfs/Blog%20Images/MicrosoftTeams-image.png?height=329&name=MicrosoftTeams-image.png&width=329
Terminal 3270
https://attachment.tapatalk-cdn.com/2988/202003/14238_34a44305c61df33e1c21eb07e30ba66d.png
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

sábado, 10 de julho de 2010

🔥 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

ErroImpacto
PERFORM THRU mal delimitadoExecução inesperada
Alterar contador no parágrafoLoop infinito
Falta de EXITDebug caótico
GO TO misturado com PERFORMCó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.