 |
| Bellacosa Mainframe e o design patterns no ibm mainframe e cobol |
☕ Um Café no Bellacosa Mainframe
Design Patterns no COBOL e no IBM Z
Como um Padawan COBOL pode escrever software que sobrevive décadas
"Um bom programa resolve um problema. Um excelente programa continua resolvendo o mesmo problema durante trinta anos, passando por centenas de desenvolvedores sem virar um monstro impossível de manter."
Existe uma grande ironia no mundo da programação.
Muitos desenvolvedores COBOL acreditam que Design Patterns nasceram junto com Java, C++ ou C#. Outros pensam que são conceitos exclusivos da programação orientada a objetos.
Na realidade...
o Mainframe já utilizava diversos padrões de projeto muito antes do livro "Design Patterns: Elements of Reusable Object-Oriented Software" (Gang of Four - 1994).
A diferença é que ninguém chamava isso de Pattern.
Chamavam de:
Standard Program
Skeleton
Modelo Corporativo
Framework Interno
Programa Base
Convenção da Empresa
Quando Christopher Alexander criou o conceito de Pattern Language para arquitetura civil nos anos 70, ele dizia que existiam soluções recorrentes para problemas recorrentes.
A Engenharia de Software simplesmente emprestou essa ideia.
E adivinhe...
Grandes bancos já faziam exatamente isso com COBOL desde os anos 70.
Hoje vamos descobrir como um Padawan pode utilizar esses conceitos para produzir software digno de um Mestre Jedi do IBM Z.
O que é um Pattern?
Imagine que você precisa construir cem casas.
Você não desenha uma planta completamente diferente para cada uma.
Você reutiliza soluções que funcionam.
Na programação acontece exatamente o mesmo.
Um Pattern é:
Uma solução reutilizável para um problema recorrente.
Não é código.
Não é framework.
Não é biblioteca.
É uma maneira inteligente de organizar o código.
Por que Patterns existem?
Porque desenvolvedores repetem erros.
Depois repetem soluções.
Depois percebem que algumas soluções sempre funcionam.
Então essas soluções recebem um nome.
Quando recebem um nome...
Podem ser ensinadas.
O primeiro Pattern que todo programador COBOL aprende (sem perceber)
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
MAIN.
PERFORM INICIALIZA
PERFORM PROCESSA
PERFORM FINALIZA
STOP RUN.
Você já viu isso milhares de vezes.
Isso possui nome.
Template Method Pattern
Existe um fluxo fixo.
Cada etapa executa uma responsabilidade.
É um Pattern.
Pattern 1 — Template Method
Origem:
Gang of Four.
No COBOL ele existe há décadas.
Estrutura:
MAIN
↓
INICIALIZA
↓
VALIDA
↓
PROCESSA
↓
GRAVA
↓
FINALIZA
Cada rotina possui apenas uma responsabilidade.
Exemplo ruim
MAIN.
READ
VALIDA
CALCULA
GRAVA
IMPRIME
LOG
TRATA ERRO
ATUALIZA DB2
CONSOME MQ
GERA XML
ENVIA EMAIL
TERMINA
800 linhas.
Ninguém entende.
Agora veja:
MAIN.
PERFORM READ-DADOS
PERFORM VALIDAR
PERFORM CALCULAR
PERFORM GRAVAR
PERFORM FINALIZAR
Agora qualquer pessoa entende.
Benefícios
Código limpo.
Fluxo legível.
Debug simples.
Mais fácil de testar.
Mais fácil de manter.
Pattern 2 — Guard Clause
Muito usado atualmente.
Também chamado de Early Exit.
Em COBOL:
Ao invés de criar IF dentro de IF dentro de IF...
Faça validações logo no início.
Ruim
IF CLIENTE-ATIVO
IF LIMITE > 0
IF SENHA-OK
PROCESSA
END-IF
END-IF
END-IF
Melhor
IF NOT CLIENTE-ATIVO
GO TO FINALIZA
END-IF
IF LIMITE <= ZERO
GO TO FINALIZA
END-IF
IF NOT SENHA-OK
GO TO FINALIZA
END-IF
PERFORM PROCESSA
Muito mais simples.
Pattern 3 — Dispatcher Pattern
Muito usado em CICS.
Imagine:
MENU
1 Clientes
2 Contas
3 Extrato
4 PIX
Ao invés de escrever centenas de IF...
Use um Dispatcher.
EVALUATE OPCAO
WHEN 1
PERFORM CLIENTES
WHEN 2
PERFORM CONTAS
WHEN 3
PERFORM EXTRATO
WHEN OTHER
PERFORM ERRO
END-EVALUATE
Esse Pattern aparece em:
CICS
Batch
APIs
Menus
Serviços REST
Pattern 4 — Factory
Parece moderno.
Mas existe em COBOL.
Imagine:
Arquivo pode ser:
VSAM
DB2
IMS
MQ
Você não quer que o programa saiba qual utilizar.
Então cria uma rotina.
OBTER-DADOS
↓
VSAM
ou
DB2
ou
IMS
Quem chama:
PERFORM OBTER-DADOS
Não importa de onde veio.
Isso é abstração.
Pattern 5 — Strategy
Muito usado em bancos.
Imagine cálculo de juros.
Existem dezenas.
Pessoa Física.
Pessoa Jurídica.
Consignado.
Agrícola.
Imobiliário.
Ao invés de centenas de IF...
Cada estratégia fica separada.
CALCULO PF
CALCULO PJ
CALCULO RURAL
CALCULO PREMIUM
Depois:
EVALUATE TIPO
WHEN PF
PERFORM CALCULO-PF
WHEN PJ
PERFORM CALCULO-PJ
END-EVALUATE
Cada regra evolui sozinha.
Pattern 6 — Chain of Responsibility
Muito utilizado em validações.
Exemplo:
Receber pagamento.
Primeiro:
Validar CPF.
↓
Validar Conta.
↓
Saldo.
↓
Limite.
↓
Fraude.
↓
Autorizar.
Cada etapa apenas verifica uma responsabilidade.
Se falhar...
Para tudo.
É exatamente como uma esteira.
Pattern 7 — Facade
Imagine um sistema extremamente complexo.
Para gerar um boleto você precisa:
DB2
↓
MQ
↓
CICS
↓
VSAM
↓
Logs
↓
SMF
↓
Impressão
O usuário não quer saber disso.
Então existe uma fachada.
PERFORM GERAR-BOLETO
Internamente:
GERA
↓
DB2
↓
VSAM
↓
MQ
↓
LOG
↓
PDF
A fachada esconde toda complexidade.
Pattern 8 — Singleton
Muito famoso.
No Mainframe aparece em:
Tabela de parâmetros.
Configuração.
Área comum.
TS Queue.
Control Blocks.
Existe apenas uma instância.
Todos utilizam.
Pattern 9 — Repository
Hoje famoso em Java.
No COBOL:
Camada de acesso ao banco.
Ao invés de:
EXEC SQL
SELECT...
END-EXEC
Espalhado por cem programas.
Criamos:
CLIENTE-REPOSITORY
↓
CONSULTA
↓
ATUALIZA
↓
DELETE
↓
INSERT
Os programas apenas chamam.
Muito mais organizado.
Pattern 10 — Service Layer
Muito utilizado atualmente.
Exemplo.
Tela chama:
CONSULTAR CLIENTE
A camada Service decide:
Consultar DB2.
Consultar VSAM.
Consultar Cache.
Consultar API.
Quem chamou não sabe.
Nem precisa saber.
Pattern 11 — Adapter
Muito importante na Modernização.
Imagine.
Sistema antigo retorna:
PIC X(30)
Nova API quer JSON.
Adapter converte.
COBOL
↓
Adapter
↓
REST JSON
É exatamente o trabalho do z/OS Connect.
Pattern 12 — Builder
Imagine montar uma mensagem MQ.
Existem dezenas de campos.
Ao invés de fazer tudo junto...
Criamos uma rotina.
INICIA
↓
CLIENTE
↓
CONTA
↓
SALDO
↓
HEADER
↓
FINALIZA
Depois envia.
Muito mais organizado.
Pattern 13 — Observer
Muito comum hoje.
Eventos.
Exemplo.
Conta alterada.
Vários sistemas precisam saber.
Conta
↓
Evento
↓
Auditoria
↓
CRM
↓
Fraude
↓
Analytics
No Mainframe isso acontece usando:
MQ
Kafka
CDC
Eventos CICS
Pattern 14 — Retry Pattern
Rede falhou.
API indisponível.
MQ ocupado.
Ao invés de abortar imediatamente:
Tenta
↓
Falhou
↓
Espera
↓
Tenta novamente
↓
Falhou
↓
Espera
↓
Última tentativa
Muito usado em integrações.
Pattern 15 — Circuit Breaker
Extremamente moderno.
Imagine.
API está fora.
Sem Circuit Breaker:
100 mil chamadas.
Todas falham.
Com Circuit Breaker:
Após determinado número de erros...
Ele para de chamar.
Protege o sistema.
Muito usado em microsserviços.
Hoje também aplicado em IBM Z.
Pattern 16 — Bulk Processing
O Batch inteiro utiliza esse conceito.
Ao invés de:
Abre
↓
Lê
↓
Fecha
↓
Abre
↓
Lê
↓
Fecha
Processa milhares de registros em sequência.
Economiza I/O.
Pattern 17 — Retry Queue
Muito usado em MQ.
Mensagem falhou.
Não descarta.
Envia para outra fila.
Depois tenta novamente.
Pattern 18 — Checkpoint Restart
Um dos maiores Patterns do Mainframe.
Imagine:
Batch de oito horas.
Faltam cinco minutos.
Acabou energia.
Sem Checkpoint:
Começa do zero.
Com Checkpoint:
Continua do último ponto.
É um dos grandes diferenciais do IBM Z.
Pattern 19 — Producer / Consumer
Quem produz dados.
Quem consome dados.
COBOL
↓
MQ
↓
Java
↓
API
↓
Analytics
Todos independentes.
Pattern 20 — Pipeline
Muito utilizado em processamento Batch.
Entrada
↓
Validação
↓
Transformação
↓
Enriquecimento
↓
Saída
Cada programa faz apenas uma etapa.
É mais simples.
Mais rápido.
Mais reutilizável.
Patterns invisíveis do próprio z/OS
O interessante é que o próprio IBM Z foi construído usando Patterns.
CICS Transaction Routing.
Workload Manager.
JES2.
VTAM.
RACF Exit.
SMF Exit.
DFSORT.
Todos utilizam padrões arquiteturais extremamente sofisticados.
A origem dos Patterns modernos
Muito antes da Engenharia de Software falar sobre Design Patterns, Christopher Alexander, arquiteto, observava que cidades bem planejadas repetiam soluções eficientes para problemas semelhantes. Sua ideia de uma "linguagem de padrões" inspirou pesquisadores da computação. Em 1994, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides — conhecidos como Gang of Four (GoF) — consolidaram 23 padrões clássicos para software orientado a objetos.
Enquanto isso, no universo IBM Mainframe, equipes de bancos, seguradoras e governos já aplicavam conceitos equivalentes, ainda que com outros nomes. Um programa "modelo", uma rotina padronizada de tratamento de erros ou um módulo único de acesso ao DB2 eram, na prática, padrões de projeto antes mesmo da terminologia se popularizar.
Como identificar um Pattern no seu programa?
Faça estas perguntas:
Este problema aparece frequentemente?
Já resolvi isso antes?
Outros programas fazem igual?
Posso reutilizar essa solução?
O código ficará mais simples para outro desenvolvedor entender?
Se a resposta for "sim" para várias delas, provavelmente existe um Pattern adequado.
Patterns e qualidade de software
Um bom Pattern não existe para deixar o código "bonito". Ele existe para aumentar a qualidade do software.
Entre os principais ganhos estão:
Legibilidade: novos desenvolvedores entendem o fluxo rapidamente.
Manutenibilidade: alterações ficam concentradas em pontos específicos.
Reutilização: menos código duplicado significa menos defeitos.
Testabilidade: módulos menores são mais fáceis de validar.
Escalabilidade: novas funcionalidades podem ser adicionadas sem grandes reescritas.
Confiabilidade: sistemas críticos tornam-se mais previsíveis.
Em ambientes corporativos, onde aplicações COBOL permanecem em produção por décadas, esses benefícios representam economia de milhares de horas de manutenção.
Curiosidades
Algumas curiosidades surpreendem quem está começando:
O comando PERFORM incentiva naturalmente a modularização, muito antes das linguagens modernas popularizarem métodos e funções.
O COPYBOOK pode ser visto como uma forma primitiva de reutilização estrutural.
O EXEC CICS LINK lembra uma chamada para um serviço.
O EXEC SQL separa regras de negócio do acesso aos dados, aproximando-se do Repository Pattern.
Frameworks internos criados por grandes bancos nos anos 1980 já padronizavam logs, tratamento de erros, auditoria e segurança, antecipando conceitos que hoje aparecem em arquiteturas modernas.
Dicas para um Padawan COBOL
Se você está iniciando sua jornada no IBM Z, adote alguns hábitos desde cedo:
Nunca escreva um parágrafo com centenas de linhas. Divida em pequenas responsabilidades.
Evite duplicar lógica de negócio. Se duas rotinas fazem a mesma coisa, considere criar um módulo reutilizável.
Prefira nomes claros para seções e parágrafos. Eles documentam o fluxo naturalmente.
Centralize acesso a banco, VSAM e APIs sempre que possível.
Trate erros de forma consistente em todos os programas.
Pense na próxima pessoa que fará manutenção — talvez seja você daqui a cinco anos.
O impacto na carreira
Dominar Design Patterns diferencia um programador que apenas escreve código de um profissional capaz de projetar soluções.
Durante entrevistas técnicas, é comum que arquitetos e líderes valorizem candidatos que demonstrem organização, modularidade e preocupação com manutenção. Esses profissionais costumam evoluir para funções como Desenvolvedor Sênior, Líder Técnico, Arquiteto de Soluções ou Especialista IBM Z.
Além disso, ao aprender Patterns você desenvolve uma habilidade valiosa: enxergar problemas de forma abstrata. Essa capacidade facilita a transição entre COBOL, Java, Python, C#, Go ou qualquer outra linguagem, pois os conceitos permanecem os mesmos.
O Holocron Final
O jovem Padawan costuma acreditar que programar significa apenas fazer o sistema funcionar.
O Cavaleiro Jedi já entende que fazer funcionar é apenas o começo.
O Mestre sabe que um software corporativo precisa sobreviver a mudanças de regras, novas integrações, fusões de empresas, atualizações de hardware e décadas de manutenção. Ele escreve código pensando não apenas na execução de hoje, mas na equipe que dará continuidade ao projeto amanhã.
Os Design Patterns representam justamente essa evolução. Eles condensam décadas de experiência acumulada por engenheiros de software, arquitetos e desenvolvedores que descobriram, muitas vezes após cometer inúmeros erros, quais soluções resistem ao teste do tempo. No universo IBM Z, esses princípios estão presentes em praticamente todos os grandes sistemas corporativos, mesmo quando não recebem esse nome.
Para um programador COBOL Padawan, estudar Patterns é muito mais do que decorar termos como Factory, Strategy ou Facade. É aprender a organizar o pensamento, reduzir complexidade, produzir código mais limpo, facilitar testes, diminuir defeitos e tornar a manutenção previsível. É construir programas que outras pessoas consigam compreender, evoluir e confiar.
No Bellacosa Mainframe, acreditamos que o verdadeiro poder do IBM Z não está apenas na velocidade dos processadores ou na robustez do hardware. Está nas pessoas que escrevem software de qualidade. E esse caminho começa com pequenos hábitos: modularizar, reutilizar, documentar bem e escolher padrões adequados para problemas recorrentes.
Quando você domina esses conceitos, deixa de ser apenas um codificador. Torna-se um engenheiro de software capaz de construir sistemas que, assim como o próprio Mainframe, continuam relevantes, confiáveis e elegantes por muitas décadas. Esse é o verdadeiro passo para sair da condição de Padawan e iniciar sua jornada rumo à Maestria no universo COBOL e IBM Z.
