✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Padawan COBOL. Mostrar todas as mensagens

terça-feira, 31 de março de 2026

☕ O Holocron do IBM Bob Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z

Bellacosa Mainframe e uma trilha para aprender o IBM BOB

☕ O Holocron do IBM Bob

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

O mundo mudou.

Enquanto passamos décadas aprendendo os segredos do DISP, do DFSORT, do CICS, do Db2, do VSAM e dos utilitários mais obscuros do z/OS, uma nova geração de desenvolvedores começou a conversar com máquinas em linguagem natural e pedir que elas escrevessem código, documentação, testes e até arquiteturas inteiras.

A primeira reação de muitos profissionais experientes costuma ser previsível:

"Isso é modinha."

"IA não entende COBOL."

"Nunca vai substituir um analista de produção."

"Nem sabe o que é um S322."

Talvez.

Mas talvez estejamos olhando para a ferramenta errada.

Porque IBM Bob não nasceu para substituir um especialista IBM Z.

Ele nasceu para trabalhar ao lado dele.

E isso muda completamente a história.

O que é o IBM Bob?

Imagine um aprendiz extremamente dedicado.

Ele nunca dorme.

Não reclama.

Lê milhares de páginas de documentação em segundos.

Conhece APIs.

Conhece padrões modernos.

Entende agentes.

Consegue construir ferramentas.

Escreve testes.

Produz documentação.

Sugere modernizações.

Ajuda a criar MCP Servers.

Conversa com o watsonx.

Integra-se ao Orchestrate.

Pode inclusive auxiliar equipes inteiras durante o ciclo de desenvolvimento.

Esse aprendiz atende pelo nome de IBM Bob.

Bob pode ser visto como um companheiro de desenvolvimento baseado em IA, desenhado para apoiar atividades do ciclo de vida de software e construção de agentes corporativos.

Mas existe um detalhe importante.

Bob não conhece seu ambiente.

Ele não conhece sua instalação.

Ele não conhece suas convenções.

Ele não sabe onde estão seus copybooks.

Ele não entende por que aquele JOB roda somente às quartas-feiras às 02h37 da manhã.

Você sabe.

E é exatamente por isso que você continua sendo importante.

O Erro que Muitos Padawans Cometem

Muitos profissionais COBOL observam ferramentas de IA e concluem:

"Isso é para programadores Python."

Não.

Na verdade, talvez sejamos justamente os profissionais mais preparados para utilizá-las.

Quem trabalhou em Mainframe desenvolveu habilidades raras:

Pensamento sistêmico.

Modelagem de negócios.

Análise de impacto.

Governança.

Segurança.

Auditoria.

Confiabilidade.

Capacidade de compreender aplicações escritas há quarenta anos.

E IA gosta de contexto.

IA gosta de conhecimento estruturado.

IA gosta de especialistas.

Ela precisa de mestres para guiá-la.

O futuro não pertence ao desenvolvedor que apenas escreve código.

Pertence ao profissional capaz de ensinar máquinas a compreender sistemas complexos.

A Trilha do Padawan IBM Bob

Resolvi montar uma trilha de oito semanas.

Nada impossível.

Nada acadêmico.

Nada de cursos infinitos de vinte horas falando sobre redes neurais.

Apenas uma jornada prática.

Semana 1 — Entender o Ecossistema IBM AI

Objetivo:

Compreender o que existe ao redor de Bob.

Estude:

watsonx.ai
Granite
watsonx.data
watsonx.governance
AI Agents
MCP

Faça cursos gratuitos no IBM SkillsBuild.

Não tenha pressa.

Seu objetivo não é virar cientista de dados.

Seu objetivo é aprender a conversar com uma nova geração de ferramentas.

Semana 2 — Aprender Agentes

Descubra que um agente não é apenas um chatbot.

Ele pode:

Planejar.

Executar.

Consultar APIs.

Tomar decisões.

Utilizar memória.

Usar ferramentas externas.

Exercício:

Imagine um agente chamado:

COBOL Guru

Pergunte:

Explique este JCL.

Procure copybooks.

Liste dependências.

Estime complexidade.

Perceba algo interessante.

Você já sabe fazer isso.

A diferença é que agora poderá ensinar uma IA a ajudá-lo.

Semana 3 — Conhecer Bob

Leia a documentação.

Entenda seus casos de uso.

Observe demonstrações.

Experimente prompts.

Pergunte:

Analise este programa COBOL.

Gere documentação.

Escreva testes.

Sugira APIs.

Crie OpenAPI.

Identifique código morto.

Comece pequeno.

Um programa.

Depois dez.

Depois cem.

Semana 4 — Watsonx Orchestrate

Aqui a mágica começa.

Bob deixa de ser apenas um assistente.

Passa a participar de fluxos empresariais.

Skill.

Ferramenta.

Agente.

Processo.

Orquestração.

E então você percebe algo curioso.

É quase como desenhar uma aplicação CICS moderna.

Só que utilizando IA.

Semana 5 — Descobrir MCP

MCP talvez seja uma das tecnologias mais interessantes surgidas recentemente.

Em vez de pedir que uma IA adivinhe informações, você oferece ferramentas para que ela consulte dados reais.

Imagine um MCP chamado:

BellacosaMainframeServer

Com funções:

analyze_jcl()

find_copybook()

search_db2()

locate_cics_program()

find_dead_code()

estimate_batch_window()

De repente Bob deixa de ser um chatbot.

Ele se torna um analista júnior extremamente produtivo.

Semana 6 — Hands-on

Construa.

Erre.

Experimente.

Quebre.

Reconstrua.

Peça:

Bob, documente esta aplicação.

Depois:

Gere casos de teste.

Depois:

Crie APIs REST.

Depois:

Produza Markdown.

Depois:

Gere Swagger.

Pouco a pouco você perceberá que Bob não elimina conhecimento COBOL.

Ele amplia seu alcance.

Semana 7 — Mainframe Modernization

Pegue um sistema real.

COBOL.

JCL.

Db2.

VSAM.

CICS.

E pergunte:

O que pode ser modernizado?

O que pode virar API?

O que está obsoleto?

O que nunca é utilizado?

Você ficará surpreso.

Bob pode sugerir caminhos.

Mas somente um profissional experiente saberá decidir quais realmente fazem sentido.

Semana 8 — O Projeto Final

Construa algo seu.

Um sonho.

Um laboratório.

Um produto.

Um experimento.

Sugiro:

Bellacosa Bob for Mainframe

Capaz de:

Receber COBOL.

Analisar JCL.

Documentar aplicações.

Gerar testes.

Produzir OpenAPI.

Encontrar dependências.

Responder perguntas.

Criar artigos.

Explicar abends.

Mapear datasets.

Imagine um novo colega dizendo:

Bom dia.

Detectei cinco programas sem testes.

Há três copybooks duplicados.

Posso gerar documentação.

Deseja continuar?

Quem recusaria ajuda?

O Conselho de um Mestre para os Padawans COBOL

Durante anos ouvimos previsões sobre a morte do Mainframe.

Elas vieram.

E foram embora.

O IBM Z continua processando transações, cartões, seguros, governos, bolsas de valores e sistemas críticos do planeta.

Agora surge uma nova onda.

IA.

Agentes.

MCP.

Orquestração.

Granite.

Bob.

E novamente alguns profissionais ficarão olhando de longe.

Esperando passar.

Outros decidirão estudar.

Experimentar.

Errar.

Construir.

Compartilhar.

E descobrirão que a IA não veio para apagar décadas de experiência.

Veio para amplificar aquilo que os especialistas IBM Z sempre tiveram de mais valioso:

Conhecimento.

Contexto.

Disciplina.

Arquitetura.

Curiosidade.

Portanto, jovem Padawan COBOL, coloque mais café na caneca.

Abra o SkillsBuild.

Explore o Bob.

Construa seu primeiro agente.

Crie seu primeiro MCP.

Converse com o futuro.

E lembre-se:

A Força pode estar nos prompts, mas a verdadeira sabedoria continua residindo em quem conhece o significado de um DISP=(MOD,CATLG,DELETE), de um Abend U4038 e da responsabilidade de manter funcionando sistemas que movimentam bilhões de registros todos os dias.

Que os Holocrons do IBM Z estejam com você.

domingo, 22 de março de 2026

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

Bellacosa Mainframe estuda o IBM BOB

☕ O Holocron do IBM Bob

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

"O medo de perder conhecimento leva ao caos. O caos leva à reescrita em Java. A reescrita em Java leva ao sofrimento."
— Mestre Sysprog Yoda, Sala de Operações do JES2, aproximadamente 03:17 da manhã.

Existe um momento na jornada de todo Padawan COBOL...

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

A aplicação que ele acabou de receber para manutenção possui mais de trinta anos.

Não existe documentação.

O analista funcional aposentou-se em 2014.

O arquiteto virou diretor.

O programador original mora em alguma praia do Nordeste e provavelmente desligou seu pager em 1998.

Os diagramas UML nunca existiram.

Os requisitos estão enterrados em milhares de linhas de COBOL, dezenas de PROCs catalogadas, JCLs obscuros, COPYBOOKS compartilhados por cinquenta programas diferentes, packages DB2 esquecidos, mapas BMS, tabelas VSAM, MQs espalhadas pela infraestrutura e algum código assembler que ninguém ousa tocar.

Você abre o primeiro programa.

São apenas 18 mil linhas.

Respira aliviado.

Até descobrir que ele faz PERFORM em outros vinte programas.

E então surge a pergunta inevitável.

"Será que existe alguma IA capaz de entender tudo isso?"

Talvez.

E talvez ela tenha um nome curioso.

IBM Bob.

Hoje vamos abrir mais um Holocron do Bellacosa Mainframe e conversar sobre aquilo que talvez seja uma das iniciativas mais interessantes da IBM para os próximos anos.

O que é o IBM Bob?

IBM Bob é apresentado como um assistente inteligente para desenvolvimento de software baseado em Inteligência Artificial.

Mas chamá-lo apenas de um gerador de código é diminuir bastante sua ambição.

Na prática, Bob parece querer ocupar um espaço muito maior.

Ele deseja ser:

Desenvolvedor auxiliar;
Revisor de código;
Especialista em documentação;
Tutor técnico;
Ferramenta de onboarding;
Auditor de segurança;
Agente de produtividade;
Companheiro corporativo de engenharia.

Talvez a melhor definição seja:

IBM Bob é uma tentativa da IBM de construir um "engenheiro de software virtual" especializado em ambientes empresariais.

IBM já tentou isso antes

A ideia não é nova.

IBM possui uma longa tradição em criar ferramentas para aumentar a produtividade.

Década	Ferramenta
1960	FORTRAN Compiler
1970	ISPF
1980	CSP
1990	VisualAge
2000	Rational Rose
2010	Bluemix
2020	Watson
2025	watsonx
2026	IBM Bob

Existe uma espécie de evolução natural.

Antigamente tínhamos compiladores.

Depois IDEs.

Posteriormente ALM.

Mais tarde plataformas cloud.

Agora temos companheiros cognitivos.

Bob pode ser visto como uma mistura de:

GitHub Copilot
Rational Assistant
Watsonx
ChatGPT
Knowledge Assistant

Tudo isso embalado para empresas.

O problema que IBM está tentando resolver

Existe uma crise silenciosa acontecendo.

E ela não é tecnológica.

Ela é humana.

Estamos perdendo especialistas.

Todos os dias.

Pessoas que conhecem:

CICS

IMS

PL/I

COBOL

Natural

IDMS

JCL

Netview

SA z/OS

RACF

DB2

GDPS

SMP/E

RMF

SMF

SAF

VTAM

estão se aposentando.

E conhecimento não documentado possui meia vida curta.

Quando o especialista sai, o sistema continua.

Mas o entendimento desaparece.

Bob parece ser uma tentativa de capturar parte dessa inteligência institucional.

O maior erro do artigo original

O artigo que motivou esta discussão é bastante interessante.

Mas possui uma lacuna gigantesca.

Praticamente ignora o Mainframe.

E justamente aí está talvez a maior oportunidade do IBM Bob.

IBM possui bilhões de linhas COBOL instaladas.

Bilhões.

Sistemas que movimentam:

Cartões.

PIX.

Seguros.

Bolsas.

Impostos.

Benefícios sociais.

Compensação bancária.

Passagens aéreas.

Energia elétrica.

Telecomunicações.

Saúde.

Previdência.

Esses sistemas não vão desaparecer.

Eles precisam ser compreendidos.

E compreendê-los custa caro.

Muito caro.

Imagine conversar com um sistema legado

Imagine abrir um chat.

Perguntar:

Explique PROGCBL1.

Bob responde.

Sistema responsável pela liquidação diária.

Arquivos utilizados:

CLIENTES.KSDS

MOVTO.PS

Dependências:

DB2

CICS

Programas chamados:

CBL100

CBL200

CBL991

Pontos críticos:

Falta tratamento SQLCODE +100.

Possível deadlock.

Campo SALDO alterado em três locais.

Pronto.

Dias de investigação reduzidos para minutos.

O Holocron dos COPYBOOKS Perdidos

Todo Padawan COBOL conhece esse momento.

Você encontra:

COPY CLI0001

COPY BAN0007

COPY FIS9999

COPY SEG1234

Pergunta:

"Onde estão?"

Ninguém sabe.

Bob poderia consultar:

Git

Endevor

Changeman

Panvalet

Librarian

PDS

PDSE

e responder.

COPY SEG1234

Localização:

CORP.COBOL.COPYLIB

Última alteração:

15/03/2024

Responsável:

Equipe Seguros

Campos utilizados:

CPF

SALDO

RISCO

TIPO_APOLICE

Você acabou de economizar duas horas.

O poder do entendimento semântico

Talvez a maior revolução seja essa.

Não escrever código.

Entender sistemas.

Pergunta:

Quem atualiza SALDO_DISPONIVEL?

Resposta:

PROG010

PROG200

TRN991

JOBNIGHT

Impacto:

17 programas.

Possíveis efeitos colaterais:

Extrato.

PIX.

TED.

Internet Banking.

Isso é engenharia reversa inteligente.

Bob poderia ser o arqueólogo corporativo

Hoje fazemos arqueologia manual.

ISPF.

3.14.

3.4.

SUPERC.

FILEAID.

SPUFI.

SDSF.

JES2.

TSO.

Bob poderia atuar como um arqueólogo digital.

Encontrando relações invisíveis.

O sonho do Sysprog

Imagine perguntar.

Explique este JCL.

Resposta:

Job diário.

Executa às 23h.

Consome 4 CPUs.

Lê VSAM.

Executa DFSORT.

Atualiza DB2.

Publica mensagem MQ.

Gera SMF.

Último ABEND:

S806.

Ocorrências:

Ou então.

Por que ocorreu este ABEND?

S0C7

Campo NUMERO-CONTA possui dados inválidos.

Registro 145783.

Programa:

COBLIQ01

Parágrafo:

3000-PROCESSA

Isso seria quase magia.

Mas magia suficientemente avançada é indistinguível da tecnologia.

O problema dos LLMs

Nem tudo são flores.

Existe um problema sério.

LLMs alucinam.

E sistemas corporativos não aceitam alucinações.

Bob não pode inventar.

Não pode responder.

"Talvez."

Em bancos.

Talvez custa milhões.

Portanto provavelmente Bob utilizará RAG.

Retrieval Augmented Generation.

Consultando:

Catálogos.

DB2 Catalog.

Git.

Endevor.

SMF.

SDSF.

WLM.

RMF.

Copybooks.

Documentação interna.

Tickets Jira.

Confluence.

Runbooks.

Segurança

Este é provavelmente o aspecto mais importante.

Um banco não pode enviar CPF para um LLM público.

Nem dados médicos.

Nem cartões.

Nem chaves PIX.

Bob precisa viver próximo dos dados.

Talvez em:

LinuxONE.

OpenShift.

Cloud privada.

IBM Z.

Com recursos de:

LGPD.

PCI DSS.

SOX.

Mascaramento.

Auditoria.

Guardrails.

Zero Trust.

O verdadeiro diferencial

Acredito que Bob cometeria um erro enorme tentando competir diretamente com Copilot.

Copilot escreve código.

Bob deveria compreender empresas.

Ele deveria ser especialista em:

CICS.

IMS.

MQ.

COBOL.

JCL.

DB2.

VSAM.

RACF.

SA z/OS.

Netview.

GDPS.

WLM.

DFSMS.

SMP/E.

Prompt:

Crie API REST para este COBOL.

Resposta:

OpenAPI.

JSON.

COBOL parser.

z/OS Connect.

Swagger.

JCL Deploy.

Tudo documentado.

O Holocron Vivo da Empresa

Talvez seja essa a visão mais bonita.

Bob não substituirá desenvolvedores.

Ele preservará memória.

Será um Holocron corporativo.

Um aprendiz conversa.

Pergunta.

Aprende.

Entende.

Documenta.

Compartilha.

E a empresa deixa de depender exclusivamente da memória de poucas pessoas.

O futuro pertence aos desenvolvedores que sabem conversar com IA

Muitos têm medo.

"IA vai substituir programadores."

Talvez substitua quem apenas copia código.

Mas dificilmente substituirá quem entende negócio.

Quem entende processamento batch.

Quem entende compensação bancária.

Quem conhece JES2.

Quem domina CICS.

Quem compreende RACF.

Quem sabe porque um catálogo ICF ficou inconsistente às três da manhã.

Esses profissionais continuarão valiosos.

Talvez ainda mais.

Porque agora terão um novo aliado.

Um companheiro.

Um assistente.

Um aprendiz digital.

Um pequeno droide azul corporativo.

Um Bob.

Considerações Finais

Existe uma frase muito conhecida na comunidade de tecnologia:

"Todo sistema legado é apenas um sistema que continua pagando as contas."

IBM conhece essa realidade melhor do que ninguém.

E talvez o IBM Bob seja uma das primeiras tentativas realmente sérias de transformar cinquenta anos de conhecimento corporativo em algo conversável, pesquisável e ensinável.

Se conseguir compreender verdadeiramente COBOL, JCL, CICS, IMS, DB2, VSAM e os inúmeros segredos escondidos nos data centers do planeta, Bob poderá se tornar muito mais do que um assistente de programação.

Ele poderá tornar-se o primeiro grande Holocron do Mainframe Moderno.

E para nós, Padawans COBOL, isso significa algo extraordinário.

Pela primeira vez em décadas, talvez seja possível sentar diante de um sistema com quarenta anos de idade, tomar uma caneca de café, fazer uma pergunta simples e ouvir uma resposta compreensível.

E convenhamos...

Isso parece muito mais próximo da Força do que da simples Inteligência Artificial.

domingo, 2 de fevereiro de 2025

🥋 Laboratório COBOL para Padawans Do Zero ao Primeiro Jedi do Batch

Bellacosa Mainframe apresenta laboratorio inicial para padawan cobol

🥋 Laboratório COBOL para Padawans

Do Zero ao Primeiro Jedi do Batch

Este laboratório foi criado para alguém que nunca programou em COBOL. Os exercícios são progressivos e apresentam conceitos, sintaxe, boas práticas, armadilhas comuns e soluções comentadas.

Objetivo:

Aprender sintaxe COBOL
Escrever programas simples
Compreender variáveis
Utilizar DISPLAY
Aprender IF, PERFORM, EVALUATE
Trabalhar com tabelas OCCURS
Evitar erros comuns
Pensar como um desenvolvedor Mainframe

Laboratório 1 – Seu primeiro programa

Objetivo

Entender estrutura COBOL.

IDENTIFICATION DIVISION.
PROGRAM-ID. LAB001.

PROCEDURE DIVISION.

    DISPLAY 'OLA PADAWAN'.

    STOP RUN.

O que aprendemos

DIVISION
PROGRAM-ID
DISPLAY
STOP RUN

Armadilhas

Esquecer:

STOP RUN.

faz o programa terminar de maneira inadequada.

Laboratório 2 – Variáveis

Objetivo

Criar variáveis.

WORKING-STORAGE SECTION.

01 WS-NOME PIC X(20).
01 WS-IDADE PIC 99.

Programa


MOVE 'VAGNER' TO WS-NOME.
MOVE 52 TO WS-IDADE.


DISPLAY WS-NOME.
DISPLAY WS-IDADE.

Boas práticas

Prefixo WS

WS-NOME
WS-SALARIO
WS-TOTAL

Evite

NOME
X1
ABC

Laboratório 3 – MOVE

Objetivo

Copiar dados.

MOVE 100 TO WS-VALOR.
MOVE WS-VALOR TO WS-TOTAL.

Erro comum

Mover texto para campo numérico

Errado

MOVE 'ABC' TO WS-IDADE.

Laboratório 4 – ACCEPT

Ler teclado.


DISPLAY 'DIGITE SEU NOME'.

ACCEPT WS-NOME.



DISPLAY WS-NOME.

Laboratório 5 – Soma

Objetivo

Calcular.


01 A PIC 999.
01 B PIC 999.
01 C PIC 9999.



ADD A B GIVING C.



DISPLAY C.

Alternativa

COMPUTE C=A+B.

Laboratório 6 – Subtração


SUBTRACT A FROM B.


DISPLAY B.

Laboratório 7 – Multiplicação


MULTIPLY A BY B.


DISPLAY B.

Laboratório 8 – Divisão


DIVIDE A INTO B.


DISPLAY B.

Melhor

DIVIDE A INTO B GIVING C.

Laboratório 9 – IF

Objetivo

Decisão.



IF WS-IDADE >=18

   DISPLAY 'MAIOR'

ELSE

   DISPLAY 'MENOR'

END-IF.

Boa prática

Sempre

END-IF

Laboratório 10 – IF aninhado



IF IDADE >60

   DISPLAY 'IDOSO'

ELSE

   IF IDADE >=18

      DISPLAY 'ADULTO'

   ELSE

      DISPLAY 'MENOR'

   END-IF

END-IF.

Laboratório 11 – EVALUATE

Mais elegante.


EVALUATE NOTA

WHEN 10
 DISPLAY 'EXCELENTE'

WHEN 8
 DISPLAY 'OTIMO'

WHEN OTHER
 DISPLAY 'ESTUDAR'

END-EVALUATE.

É o SWITCH do COBOL.

Laboratório 12 – PERFORM

Criando parágrafos.


PERFORM MOSTRAR.



MOSTRAR.

DISPLAY 'OLA'.

Boa prática

Dividir lógica.

Não fazer:

500 linhas seguidas.

Laboratório 13 – PERFORM TIMES



PERFORM 5 TIMES

 DISPLAY 'COBOL'

END-PERFORM.

Laboratório 14 – PERFORM UNTIL



MOVE 1 TO I.



PERFORM UNTIL I >5


DISPLAY I


ADD 1 TO I


END-PERFORM.

Resultado

Laboratório 15 – Tabelas OCCURS


01 WS-NUMEROS.

   05 WS-NUM OCCURS 5 TIMES PIC 999.

Preenchendo



MOVE 10 TO WS-NUM(1).

MOVE 20 TO WS-NUM(2).

MOVE 30 TO WS-NUM(3).

Laboratório 16 – Percorrer tabela


01 I PIC 9.


PERFORM VARYING I FROM 1 BY 1 UNTIL I >5


DISPLAY WS-NUM(I)


END-PERFORM.

Muito usado em produção.

Laboratório 17 – Strings


STRING

'NOME='

WS-NOME


DELIMITED BY SPACE


INTO WS-SAIDA.



DISPLAY WS-SAIDA.

Laboratório 18 – INSPECT

Contar letras.



INSPECT WS-TEXTO

TALLYING WS-QTD

FOR ALL 'A'.

Laboratório 19 – Inicialização


INITIALIZE REGISTRO.

Substitui:


MOVE SPACES TO REGISTRO.

MOVE ZEROS TO REGISTRO.

Laboratório 20 – Mini Projeto Final

Cadastro simples

1-Incluir

2-Consultar

3-Sair

Variáveis


01 OPCAO PIC 9.

01 NOME PIC X(30).

01 IDADE PIC 99.

Fluxo



PERFORM UNTIL OPCAO=3


DISPLAY MENU


ACCEPT OPCAO


EVALUATE OPCAO


WHEN 1

PERFORM INCLUIR


WHEN 2

PERFORM CONSULTAR


WHEN 3

DISPLAY 'ATE LOGO'


WHEN OTHER

DISPLAY 'INVALIDO'


END-EVALUATE


END-PERFORM.

📚 Erros Mais Comuns do Padawan COBOL

Erro	Problema
Esquecer ponto final	Compilação falha
Não usar END-IF	Código confuso
Índice fora do OCCURS	ABEND
Mover texto para PIC 9	Dados inválidos
Divisão por zero	S0CB
Variável não inicializada	Resultado imprevisível
Não usar GIVING	Sobrescreve dados
PERFORM infinito	Loop sem fim
Nomes genéricos	Manutenção difícil
Misturar lógica em um único parágrafo	Código espaguete

🎓 Checklist do Padawan COBOL

Ao concluir os 20 laboratórios, o aluno deverá saber:

✅ Criar programas COBOL
✅ Declarar variáveis
✅ Usar PIC X e PIC 9
✅ Fazer cálculos
✅ Receber dados com ACCEPT
✅ Exibir informações com DISPLAY
✅ Trabalhar com IF e EVALUATE
✅ Criar laços com PERFORM
✅ Utilizar OCCURS
✅ Manipular strings
✅ Inicializar estruturas
✅ Identificar erros comuns
✅ Desenvolver pequenos programas estruturados
✅ Aplicar boas práticas de nomenclatura e modularização

Este conjunto de laboratórios fornece uma base sólida para avançar posteriormente para arquivos sequenciais, VSAM, JCL, DB2, CICS e desenvolvimento COBOL empresarial em IBM z/OS.

Apresentação do Laboratório COBOL para Padawans

Este laboratório foi concebido para desenvolvedores iniciantes que desejam aprender COBOL de maneira prática, gradual e estruturada. O principal objetivo é fornecer uma base sólida sobre a linguagem, permitindo que o estudante compreenda sua sintaxe, suas instruções fundamentais e as boas práticas utilizadas em ambientes corporativos, especialmente no ecossistema IBM Z.

A didática adotada é baseada em pequenos desafios progressivos, nos quais cada exercício apresenta um conceito novo, seguido por uma solução comentada, observações sobre armadilhas comuns e recomendações de codificação. Essa abordagem reduz a curva de aprendizado, incentiva a experimentação e ajuda o aluno a desenvolver confiança ao escrever seus primeiros programas.

COBOL é uma linguagem predominantemente associada ao paradigma de programação estruturada e procedural. Seu modelo enfatiza a decomposição do problema em etapas sequenciais, a modularização por meio de parágrafos e seções, além do uso de estruturas de decisão e repetição claramente definidas. Essa característica torna a linguagem particularmente adequada para o processamento de regras de negócio, cálculos financeiros e sistemas transacionais de grande porte.

Realizar este laboratório permite ao estudante adquirir fundamentos essenciais antes de avançar para tópicos mais complexos, como manipulação de arquivos, JCL, VSAM, DB2, CICS e modernização de aplicações. Mais do que aprender comandos, o participante desenvolve uma mentalidade disciplinada de desenvolvimento, manutenção e qualidade de software, altamente valorizada no mercado de tecnologia corporativa.

sábado, 24 de junho de 2023

IEBPTPCH: Como um Padawan COBOL Pode Enxergar os Segredos dos Data Sets do IBM Z Sem Invocar IDCAMS, ISPF ou Magia Negra

Bellacosa Mainframe e o iebptpch para analise de copybooks

☕ O Holocron do IEBPTPCH

Como um Padawan COBOL Pode Enxergar os Segredos dos Data Sets do IBM Z Sem Invocar IDCAMS, ISPF ou Magia Negra

"O Mainframe nunca escondeu seus segredos. Apenas esperava que alguém tivesse paciência suficiente para imprimir seus antigos holocrons."
— Bellacosa Mainframe

Introdução – O dia em que o Padawan encontrou um artefato esquecido

Todo programador COBOL passa por algumas iniciações obrigatórias.

Primeiro aprende a editar no ISPF.

Depois descobre o SDSF.

Em seguida entende que JCL não é exatamente uma linguagem, mas uma espécie de contrato legal escrito por advogados intergalácticos.

E então chega um dia estranho.

Seu Tech Lead aparece.

Pergunta:

— Bellacosa Jr., consegue verificar o conteúdo do copybook ACCOUNT-COMMON sem abrir o ISPF?

Você responde:

— Posso fazer um Browse...

Ele sorri.

— Não.

— Quero um spool.

— Quero evidência.

— Quero auditoria.

— Quero algo que funcione igual em 1985, 2005 e 2026.

Nesse momento surge um pequeno utilitário.

Pequeno.

Discreto.

Quase esquecido.

Chamado IEBPTPCH.

E ele provavelmente estava instalado no seu sistema antes mesmo de você nascer.

Afinal, o que é o IEBPTPCH?

IEBPTPCH é um dos utilitários clássicos do z/OS.

Seu nome vem de uma época em que desenvolvedores utilizavam cartões perfurados.

IBM Extended Basic Punch Utility

O nome ficou.

Os cartões morreram.

Mas o utilitário continua vivo.

Sua missão é extremamente simples:

Visualizar dados sem alterá-los.

Ele funciona como um scanner arqueológico.

Abre.

Lê.

Imprime.

Exporta.

Documenta.

Mas não modifica.

É quase um modo READ ONLY elevado ao estado zen.

Por que ele ainda existe?

Porque empresas grandes amam evidências.

Bancos.

Seguradoras.

Governo.

Bolsa de Valores.

Data Centers.

Auditores não gostam de ouvir:

"Confia em mim."

Eles gostam de receber:

PDF

Spool

Relatórios

Listagens

Evidências históricas

IEBPTPCH nasceu para isso.

O grande poder do utilitário

Ele consegue trabalhar com:

Dataset sequencial

Biblioteca particionada

PDS

PDSE

Vários datasets concatenados

ARQ1

ARQ2

ARQ3

Tudo junto.

Membros específicos

COPYBOOKS

COBOL

JCL

PROC

Anatomia do Job

Passo 1

EXEC

//STEP01 EXEC PGM=IEBPTPCH

Nada de parâmetros.

Nada complicado.

Passo 2

SYSUT1

Entrada.

É o Holocron.

Dataset origem.

//SYSUT1 DD DSN=BANK.COPYLIB,
// DISP=SHR

Passo 3

SYSUT2

Destino.

Geralmente spool.

//SYSUT2 DD SYSOUT=*

Pode ser arquivo também.

Passo 4

SYSPRINT

Mensagens.

Diagnóstico.

//SYSPRINT DD SYSOUT=*

Passo 5

SYSIN

Comandos.

//SYSIN DD *
PRINT TYPORG=PO
/*

Fim.

Literalmente.

Acabou.

O utilitário já está funcionando.

Entendendo o TYPORG

Esse parâmetro derruba muitos padawans.

TYPORG=PO

Partitioned Organization

PDS

PDSE

Exemplo:

PRINT TYPORG=PO

TYPORG=PS

Sequential

Arquivo sequencial.

Exemplo:

PRINT TYPORG=PS

Laboratório 1 — Imprimindo um programa COBOL

Suponha:

BELLA.COBOL.SOURCE

Possui:

PGMCLIENT

Nosso objetivo:

Visualizar.

Imprimir.

Documentar.

Sem editar.

JCL

//PRINT01 EXEC PGM=IEBPTPCH

//SYSUT1 DD DSN=BELLA.COBOL.SOURCE,
/// DISP=SHR

//SYSUT2 DD SYSOUT=*

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

PRINT MEMBER=PGMCLIENT,
      TYPORG=PO

/*

Resultado:

IDENTIFICATION DIVISION.

PROGRAM-ID. PGMCLIENT.

DATA DIVISION.

WORKING-STORAGE SECTION.

Tudo vai para spool.

Pode virar PDF.

Enviar email.

Arquivar.

Git.

Wiki.

Confluence.

RAG.

LLM.

Laboratório 2 — Copybook perdido

Situação real.

Padawan recebe erro:

IGYDS1089-E

Copybook não encontrado.

Ele suspeita.

Existe um copybook chamado:

CLIENTE

Mas não sabe.

Executa:

PRINT MEMBER=CLIENTE,
      TYPORG=PO

Descobre:

05 CPF PIC 9(11).

05 NOME PIC X(50).

Mistério resolvido.

Laboratório 3 — Dataset Sequencial

Arquivo:

BANK.CLIENT.FILE

Conteúdo:

000001JOSE
000002MARIA
000003ANA

JCL:

PRINT TYPORG=PS

Saída:

000001JOSE

000002MARIA

000003ANA

Simples.

Elegante.

Funciona desde o System/370.

Laboratório 4 — Concatenando datasets

Algo muito utilizado.

Exemplo:

//SYSUT1 DD DSN=FILE01,
// DISP=SHR

// DD DSN=FILE02,
// DISP=SHR

// DD DSN=FILE03,
// DISP=SHR

IEBPTPCH processa tudo.

Como se fosse um único arquivo.

Excelente para auditorias.

Easter Egg Nº 1

Pouca gente sabe.

O nome PUNCH não desapareceu.

Existe ainda.

PUNCH TYPORG=PO

Originalmente produzia cartões perfurados.

Hoje gera saída textual.

É um pequeno fóssil tecnológico preservado dentro do z/OS.

Easter Egg Nº 2

Em vários bancos brasileiros o IEBPTPCH ainda é usado por equipes SOX.

Motivo?

Auditores adoram spool.

Spool possui:

Timestamp

Classe

Owner

Jobname

Número do Job

Histórico

É praticamente uma cadeia de custódia digital.

Easter Egg Nº 3

Muitos pipelines modernos de IA podem usar IEBPTPCH.

Arquitetura:

PDS

↓

IEBPTPCH

↓

TXT

↓

Chunking

↓

Embedding

↓

Vector DB

↓

RAG

↓

Agente COBOL

Sim.

Um utilitário criado na década de 1960 pode alimentar agentes de IA em 2026.

Existe certa poesia nisso.

Comparação com outros utilitários

Utilitário	Faz o quê
IEBPTPCH	Visualiza
IEBGENER	Copia
IEBCOPY	Manipula PDS
IDCAMS	VSAM
DFSORT	Ordena
ISPF Browse	Visualiza
SDSF	Consulta spool

Dicas de veterano Bellacosa Mainframe

Dica 1

Nunca faça EDIT apenas para olhar.

Use Browse.

Ou IEBPTPCH.

Dica 2

Quer documentação automática?

IEBPTPCH.

Spool.

PDF.

Git.

IA.

Dica 3

Quer descobrir rapidamente o que existe numa biblioteca antiga?

IEBPTPCH.

Dica 4

Em ambientes regulados, produzir evidência vale ouro.

IEBPTPCH é praticamente um gerador oficial de evidências.

O que um Padawan COBOL deve aprender com isso?

O erro comum dos iniciantes é imaginar que dominar Mainframe significa conhecer apenas COBOL, DB2 e CICS.

Não.

O verdadeiro Jedi do IBM Z entende que o ecossistema é formado por centenas de pequenos holocrons tecnológicos acumulados ao longo de mais de sessenta anos de engenharia.

IEBPTPCH é um deles.

Ele não possui interface web.

Não oferece API REST.

Não conversa diretamente com ChatGPT.

Não tem dashboard em React.

Mas continua fazendo algo extraordinariamente importante:

Permitir observar, compreender e preservar conhecimento corporativo armazenado em datasets do z/OS de forma simples, segura e praticamente imutável.

E talvez seja exatamente isso que diferencia um simples programador COBOL de um Mestre Bellacosa Mainframe: entender que, antes de modernizar sistemas, conectar APIs ou alimentar agentes de IA, é preciso primeiro abrir os antigos holocrons do datacenter e aprender a escutar o que eles ainda têm a ensinar.

sábado, 17 de junho de 2023

IBM Z Resiliency Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

Bellacosa Mainframe expande as ideias em IBM Z Resiliency

☕ Um Café no Bellacosa Mainframe

O Holocron da IBM Z Resiliency

Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

"O melhor programa COBOL não é apenas aquele que produz o resultado correto. É aquele que continua produzindo o resultado correto mesmo quando discos falham, servidores reiniciam, links caem, operadores cometem erros e o datacenter enfrenta uma crise."

Introdução

Quando um desenvolvedor COBOL começa sua jornada no IBM Z, normalmente sua preocupação é bastante simples:

aprender PROCEDURE DIVISION;
entender WORKING-STORAGE;
fazer READ e WRITE em arquivos VSAM;
acessar Db2;
executar um programa via JCL;
tratar um SQLCODE.

Tudo isso é importante.

Mas existe uma realidade muito maior que normalmente só é descoberta anos depois.

Seu programa não vive sozinho.

Ele faz parte de um enorme ecossistema composto por:

IBM Z Hardware
z/OS
JES2
WLM
CICS
IMS
Db2
MQ
RACF
GDPS
Parallel Sysplex
Storage
Redes
Operação
Monitoramento
Backup
Disaster Recovery

Todo esse conjunto possui um único objetivo:

Nunca deixar o negócio parar.

É justamente isso que a IBM chama de Resiliency.

O maior equívoco do desenvolvedor iniciante

O Padawan COBOL costuma pensar:

"Meu programa compilou."

Depois:

"Funcionou no teste."

Depois:

"Funcionou em produção."

Fim da história.

Na realidade...

A história apenas começou.

Porque a pergunta correta nunca é:

"O programa funciona?"

A pergunta correta é:

"Ele continua funcionando quando alguma coisa dá errado?"

Essa mudança de mentalidade separa um programador júnior de um engenheiro de software para ambientes críticos.

O mundo perfeito não existe

Imagine um banco.

Às 10 horas da manhã.

Existem:

8 milhões de clientes conectados.
milhares de caixas eletrônicos.
PIX.
cartões.
internet banking.
aplicativos móveis.
APIs REST.
Open Finance.

Nesse momento:

uma CPU apresenta defeito.

O que acontece?

Se você respondeu:

"O banco para."

Você ainda está pensando como quem programa um computador doméstico.

No IBM Z, o esperado é que ninguém perceba.

Esse é o verdadeiro significado da palavra Resiliency.

Resiliência não significa nunca falhar

Essa é outra confusão muito comum.

Nenhum computador é perfeito.

Discos quebram.

Memórias apresentam defeitos.

Cabos rompem.

Fontes queimam.

Operadores erram comandos.

Aplicações possuem bugs.

Até meteoros poderiam destruir um datacenter.

Resiliência significa:

Aceitar que falhas acontecerão e projetar o sistema para continuar operando apesar delas.

O conceito mais importante

A IBM define resiliência como:

Capacidade de fornecer os serviços necessários diante da adversidade sem impacto significativo.

Perceba um detalhe.

Ela não fala em hardware.

Ela não fala em COBOL.

Ela fala em:

Serviço.

O cliente quer sacar dinheiro.

Ele não quer saber quantas CPUs existem.

O iceberg invisível

Quando você executa:

EXEC SQL
SELECT SALDO
END-EXEC

Você enxerga apenas uma linha.

Por trás dela existem dezenas de componentes trabalhando juntos.

Seu programa depende de:

compilador COBOL;
runtime;
Db2;
buffer pools;
storage;
cache;
canais FICON;
discos;
processadores;
WLM;
z/OS;
JES;
rede;
segurança RACF.

A resiliência protege toda essa cadeia.

O verdadeiro custo de um downtime

Muitos iniciantes imaginam:

"Se o sistema parar por cinco minutos não faz diferença."

Na prática, cinco minutos podem significar:

milhões de transações não realizadas;
PIX rejeitados;
compras canceladas;
multas;
perda de reputação;
ações caindo na bolsa.

O Redbook mostra que o custo de uma interrupção vai muito além da infraestrutura. Há perdas diretas de receita, custos fixos durante a parada e impactos intangíveis, como perda de confiança dos clientes e danos à marca.

O famoso RAS

Quase todo Sysprog conhece esta sigla.

Reliability

Confiabilidade.

Quanto menor a chance de quebrar.

Availability

Disponibilidade.

Mesmo quebrando,

continua funcionando.

Serviceability

Facilidade para manutenção.

Trocar peças.

Atualizar firmware.

Fazer manutenção.

Sem parar o ambiente.

O COBOL participa da Resiliência?

Sim.

Muito mais do que parece.

Um programa COBOL mal escrito pode derrubar um ambiente inteiro.

Por exemplo:

LOOP infinito.
COMMIT inexistente.
Deadlock.
Consumo exagerado de CPU.
SQL sem índice.
Arquivos bloqueados.
Storage leak.
Falta de tratamento de exceção.

Resiliência também é responsabilidade do desenvolvedor.

O que um Padawan precisa aprender

Primeira fase.

Programar.

Segunda fase.

Programar corretamente.

Terceira fase.

Programar para recuperação.

Quarta fase.

Programar pensando na infraestrutura.

Quinta fase.

Programar pensando no negócio.

Essa evolução leva anos.

A importância do COMMIT

Imagine:

Você atualiza:

100.000 registros.

No registro 99.999 ocorre uma queda elétrica.

Sem COMMIT.

Tudo volta.

Com COMMIT periódico.

A perda é mínima.

O programa consegue reiniciar.

Esse pequeno detalhe pode economizar horas de processamento.

Checkpoints

Batchs gigantes normalmente possuem checkpoints.

Imagine um processamento de:

40 milhões de clientes.

No cliente 39 milhões ocorre uma falha.

Sem checkpoint.

Tudo recomeça.

Com checkpoint.

Continua do ponto salvo.

É resiliência aplicada ao desenvolvimento.

Idempotência

Uma palavra moderna.

Mas extremamente útil.

Se o mesmo programa executar novamente,

ele não deve:

duplicar pagamentos;

duplicar TED;

duplicar PIX;

duplicar lançamentos.

Grandes sistemas financeiros dependem disso.

Tratamento de exceções

Nunca escreva:

IF SQLCODE NOT = 0
    DISPLAY 'ERRO'
END-IF

Isso não resolve nada.

Um bom programa:

registra logs;
identifica contexto;
faz rollback quando necessário;
encerra de forma segura;
permite recuperação.

O papel do WLM

O Workload Manager decide quem recebe prioridade.

Imagine:

Folha de pagamento.
PIX.
Batch estatístico.

Quem deve receber CPU primeiro?

O WLM responde.

Seu programa faz parte dessa fila.

Parallel Sysplex

Talvez seja a tecnologia mais famosa do IBM Z.

Vários sistemas trabalham como se fossem um único computador.

Se um deles cair,

os demais continuam.

O usuário nem percebe.

Parece magia.

Na realidade,

é engenharia.

GDPS

Geographically Dispersed Parallel Sysplex.

Imagine:

São Paulo inteiro sem energia.

Outro datacenter assume.

Essa é a ideia.

Algumas empresas conseguem continuar operando mesmo após perder completamente um site.

Zero Data Loss

Um conceito impressionante.

Perder:

zero.

Nem um registro.

Nem um pagamento.

Nem um PIX.

Nem um centavo.

Nem um byte.

É um objetivo que depende de arquiteturas de replicação síncrona e soluções como GDPS e tecnologias de espelhamento de armazenamento.

Curiosidade

Muitos bancos realizam manutenção durante o horário comercial.

Você nem percebe.

Enquanto um sistema recebe manutenção,

outro assume.

Depois ocorre o inverso.

Esse processo chama-se:

Rolling Maintenance.

Easter Egg nº 1

O maior inimigo da disponibilidade nem sempre é o hardware.

É o operador.

Estudos da indústria mostram que erros humanos continuam entre as causas mais frequentes de indisponibilidade.

Por isso existem:

automação;
procedimentos;
scripts;
validações;
System Automation;
Runbooks.

Easter Egg nº 2

Os engenheiros IBM costumam perseguir um objetivo curioso.

Eliminar o que chamam de:

Single Point of Failure

Qualquer componente único que possa derrubar todo o ambiente.

Vale para:

CPU;
disco;
switch;
cabo;
storage;
operador;
documentação.

Até pessoas podem ser um "Single Point of Failure" quando apenas um especialista conhece um procedimento crítico.

Easter Egg nº 3

Um COBOL pode ser resiliente mesmo sendo escrito há 40 anos.

Se:

estiver bem estruturado;
tratar exceções;
possuir restart;
possuir checkpoints;
respeitar transações;

ele continua extremamente moderno.

O que estudar depois deste curso

Depois de entender Resiliency, o caminho natural é aprofundar-se na própria stack IBM Z.

Infraestrutura

IBM Z Hardware
CPC
LPAR
PR/SM
HMC

Sistema Operacional

z/OS
JES2
SDSF
WLM
SMF
RMF

Armazenamento

DFSMS
DFSMShsm
Copy Services
Metro Mirror
Global Mirror

Redes

VTAM
TCP/IP
DVIPA
Sysplex Distributor

Middleware

CICS
IMS
Db2
MQ

Alta Disponibilidade

Parallel Sysplex
Coupling Facility
Data Sharing
GDPS

Operação

IBM System Automation
OMEGAMON
IBM Z Operations Analytics

As habilidades modernas do desenvolvedor COBOL

O mercado mudou.

Hoje um desenvolvedor COBOL pode agregar muito mais valor quando conhece:

APIs REST com z/OS Connect;
JSON e XML;
Git;
GitHub;
DevOps;
CI/CD;
testes automatizados;
observabilidade;
OpenTelemetry;
containers para ferramentas de apoio;
Ansible;
Zowe;
VS Code;
automação operacional;
inteligência artificial aplicada ao desenvolvimento.

Os perigos de ignorar a resiliência

Quem pensa apenas em "fazer funcionar" costuma criar sistemas frágeis.

Os principais riscos são:

perda de dados;
duplicidade de transações;
indisponibilidade prolongada;
degradação de desempenho;
dificuldade de recuperação;
manutenção cara;
dependência de especialistas;
aumento do risco operacional.

Em ambientes financeiros, esses problemas podem gerar prejuízos milionários.

Como evoluir de Padawan para Mestre

Uma evolução sólida pode seguir esta trilha:

Nível 1 — Fundamentos

COBOL
JCL
VSAM
Db2
CICS

Nível 2 — Sistema

z/OS
SDSF
JES2
TSO/ISPF
WLM

Nível 3 — Arquitetura

Parallel Sysplex
Coupling Facility
Data Sharing
ARM
SFM

Nível 4 — Continuidade de Negócios

RAS
HA
DR
RTO
RPO
GDPS

Nível 5 — Modernização

APIs
z/OS Connect
DevOps
Observabilidade
IA
Automação

A maior lição do IBM Z Resiliency

Depois de estudar esse tema, muitos desenvolvedores descobrem que escrever código representa apenas uma pequena parte do trabalho. Um programa COBOL faz sentido somente quando está inserido em uma arquitetura capaz de sobreviver a falhas, manter dados íntegros e continuar entregando serviços ao negócio.

É por isso que os profissionais mais valorizados no ecossistema IBM Z não são apenas excelentes programadores. Eles entendem infraestrutura, operação, banco de dados, middleware, redes, automação e continuidade de negócios. Eles sabem que um COMMIT bem posicionado, um tratamento adequado de exceções ou um checkpoint inteligente podem ter tanto impacto quanto uma nova funcionalidade.

No fim da jornada, o verdadeiro Mestre do IBM Z não é aquele que escreve o código mais sofisticado. É aquele que projeta soluções que continuam funcionando quando o inesperado acontece. Essa é a essência da IBM Z Resiliency: construir sistemas preparados para enfrentar falhas sem interromper aquilo que realmente importa — o negócio de milhões de pessoas.

quinta-feira, 14 de julho de 2022

☕💥 Arrays em COBOL: O Poder Oculto do OCCURS, SSRANGE e a Guerra Contra a Invasão de Memória

Bellacosa Mainframe e as tabelas internas no COBOL occurs e arrays

☕💥 Arrays em COBOL: O Poder Oculto do OCCURS, SSRANGE e a Guerra Contra a Invasão de Memória

Ou como evitar transformar seu Address Space em um filme de terror para Sysprogs

Introdução

Existe um momento na vida de todo desenvolvedor COBOL júnior em que ele descobre duas verdades universais:

A primeira é que OCCURS parece simples até deixar de ser simples.

A segunda é que existe uma entidade maligna chamada:

SSRANGE

capaz de transformar uma manhã tranquila em uma reunião emergencial envolvendo desenvolvimento, suporte, infraestrutura, DBA, operador e um sysprog segurando uma caneca de café já fria.

E tudo isso por causa de um pequeno detalhe:

MOVE WS-NOME(9999)

quando a tabela possui apenas:

OCCURS 100 TIMES.

Bem-vindo ao fascinante mundo das tabelas COBOL.

Capítulo 1 – O que é OCCURS?

OCCURS é o mecanismo utilizado pelo COBOL para criar estruturas repetitivas.

Em linguagens modernas chamaríamos isso de:

Array
Vetor
Lista fixa
Matriz

Exemplo:

01 CLIENTES.

   05 CLIENTE OCCURS 10 TIMES.

      10 NOME PIC X(30).
      10 IDADE PIC 99.

Memória:

CLIENTE(1)
CLIENTE(2)
CLIENTE(3)
...
CLIENTE(10)

COBOL simplesmente reserva um bloco contínuo.

A origem histórica

Década de 60.

Memória era absurdamente cara.

IBM 1401

4 KB

IBM System/360

256 KB

370

1 MB

Não existia:

Java Collections
Python List
C++ Vector

Era necessário reservar memória antecipadamente.

Daí nasceu:

OCCURS

Curiosidade histórica

Os engenheiros da IBM chamavam essas estruturas de:

Table Handling

Muito antes da expressão Array Processing se popularizar.

Capítulo 2 — Como a memória é organizada

Exemplo:

01 TAB.

   05 ITEM OCCURS 5 TIMES.

      10 CODIGO PIC 9(5).

Cada item ocupa:

5 bytes

Total

25 bytes

Layout:

0000 ITEM(1)
0005 ITEM(2)
0010 ITEM(3)
0015 ITEM(4)
0020 ITEM(5)

Acesso:

MOVE ITEM(3) TO WS-X

COBOL faz:

Base + ((3-1)*5)

Capítulo 3 – O Terror do Out of Bounds

Tabela:

05 CLIENTE OCCURS 100 TIMES.

Código:

MOVE NOME(101)

Problema.

A posição não existe.

Antigamente

Compilador:

NOSSRANGE

Padrão.

Nenhuma verificação.

Resultado:

Leitura aleatória.

Sobrescrever memória.

Corrupção.

O verdadeiro vilão

Imagine:

01 TABELA.

05 DADOS OCCURS 100 TIMES.

05 FLAG-FINAL PIC X.

Erro:

MOVE "S" TO DADOS(101)

Na prática:

FLAG-FINAL = S

ou pior.

Modifica outra estrutura.

Isso é invasão de memória?

Sim.

Tecnicamente:

Buffer overflow

Memory overwrite

Storage corruption

Capítulo 4 — Address Space

No zOS cada Job possui.

Address Space.

Exemplo

JOB1234



Private Area


LSQA


SWA


Subpools


Heap


Stack

Seu programa COBOL vive ali.

Se escrever fora da tabela:

pode corromper:

Working Storage

Heap

LE Runtime

Control Blocks

Em casos extremos:

S0C4

S878

U4038

Capítulo 5 — SSRANGE

A melhor invenção desde o café expresso.

Compilação:

SSRANGE

CBL SSRANGE

Exemplo

MOVE WS-NOME(101)

Resultado:

Abend imediato.

Mensagem:

IGZxxxx

Subscript out of range

Excelente para:

Homologação

Teste

Produção?

Normalmente:

NOSSRANGE

Performance melhor.

Dica Bellacosa

Desenvolvimento

SSRANGE

Produção

NOSSRANGE

Capítulo 6 — Índices

Ruim:

77 WS-I PIC 999.

Melhor:

05 CLIENTE OCCURS 100 TIMES
   INDEXED BY IDX.

SET

SET IDX TO 1

SET IDX UP BY 1

SET IDX DOWN BY 1

Por que índice é melhor?

Subscript:

CLIENTE(I)

Cálculo toda vez.

Index

Endereço pronto.

Ponteiro interno.

Mais rápido.

Capítulo 7 – Navegação

Crescente

SET IDX TO 1


PERFORM UNTIL IDX > MAX

PROCESSA

SET IDX UP BY 1

END-PERFORM

Decrescente

SET IDX TO MAX


PERFORM UNTIL IDX = 0


PROCESSA


SET IDX DOWN BY 1


END-PERFORM

Muito usado em:

Compressão

Ordenação

Rollback

Capítulo 8 — SEARCH

Busca sequencial.

SEARCH CLIENTE


AT END


DISPLAY "NAO ACHOU"


WHEN ID = WS-ID


DISPLAY NOME

END-SEARCH

Complexidade

O(n)

100 mil registros.

50 mil leituras médias.

SEARCH ALL

Arma secreta.

Busca binária.

Tabela obrigatoriamente ordenada.

SEARCH ALL CLIENTE


WHEN ID(IDX)=WS-ID


DISPLAY "ACHOU"

END-SEARCH

Complexidade

O(log n)

1000000 itens.

Comparações:

~20

Magia matemática.

Capítulo 9 — OCCURS DEPENDING ON

Tabela variável.

05 QTDE PIC 9(4).


05 CLIENTE OCCURS 1 TO 1000 TIMES

DEPENDING ON QTDE.

Muito usado em:

Copybooks

APIs

Arquivos

Capítulo 10 — Bidimensional

Exemplo.

Agência x Dia

05 MOVIMENTO.

10 AG OCCURS 100.

15 DIA OCCURS 31.

20 TOTAL PIC 9(10).

Uso:

TOTAL(10,15)

Agência 10.

Dia 15.

Tridimensional

ANO

MES

DIA

VENDAS(2026,6,23)

N dimensões

Teoricamente ilimitado.

Exemplo.

Banco.

País

Estado

Agência

Conta

Produto

Dia

Capítulo 11 — Ordenação

Tabela ordenada.

ASCENDING KEY

Muito útil para:

SEARCH ALL

Caches

Lookup

Capítulo 12 – Quando usar tabela

Excelente:

Parâmetros

Cache

Código UF

Tabela IR

CEP

Conversões

Ruim:

Milhões registros.

Melhor:

DB2

VSAM

IMS

Capítulo 13 – Performance

O(n)

SEARCH ALL

O(log n)

Index

Muito rápido

Subscript

Mais lento

SSRANGE

Seguro

NOSSRANGE

Rápido

Easter Egg COBOL

Existe uma lenda entre veteranos de mainframe.

Diz-se que em algum datacenter esquecido dos anos 80 existe um programa COBOL compilado com:

NOSSRANGE
OPT(2)
FASTSRT
ARITH(EXTEND)

executando desde 1987.

Ninguém sabe exatamente o que ele faz.

Ninguém possui o código-fonte.

Ninguém ousa recompilar.

Mas toda madrugada, às 02h17, ele produz um relatório financeiro perfeito, movimenta bilhões de dólares e desaparece novamente nas profundezas do JES2.

Os sysprogs apenas observam o spool, tomam um gole de café e repetem o antigo mantra do reino z/OS:

"Se está funcionando há 39 anos, não toque."

Conclusão

OCCURS é muito mais do que um simples array.

É uma das construções mais antigas, elegantes e eficientes já criadas para processamento em lote de grande volume.

Dominar:

OCCURS
INDEXED BY
SET
SEARCH
SEARCH ALL
SSRANGE
OCCURS DEPENDING ON
Tabelas multidimensionais
Navegação UP e DOWN
Layout de memória
Address Space do z/OS

é um dos marcos que separam o Padawan COBOL do Cavaleiro do Batch Jedi Council.

Porque no universo do Mainframe existe uma verdade absoluta:

"DB2 pode falhar, CICS pode reciclar, VSAM pode corromper, mas um OCCURS acessado fora dos limites sempre encontrará uma maneira criativa de arruinar o dia de alguém."

domingo, 15 de março de 2020

☕💥 Fluxogramas no Mundo Mainframe

Bellacosa Mainframe e o fluxograma no mundo mainframe

☕💥 Fluxogramas no Mundo Mainframe

Ou como um Padawan COBOL descobre que antes do `IF WS-SALDO > ZERO`, existia um desenhinho que salvava projetos milionários

"Um programa COBOL sem fluxograma é como um JCL sem JOB CARD. Talvez execute. Talvez funcione. Mas ninguém vai entender daqui seis meses."
— Mestre Bellacosa Mainframe

Introdução

Uma das maiores diferenças entre um desenvolvedor COBOL júnior de hoje e um analista de sistemas da década de 1970, 1980 ou 1990 não está na linguagem.

Não está no z/OS.

Não está no DB2.

Não está no CICS.

Está na forma de pensar software.

Hoje aprendemos:

Fazer código
Testar
Commitar
Fazer Pull Request

Antigamente aprendíamos:

Analisar
Modelar
Desenhar
Revisar
Aprovar
Codificar

E neste mundo existia um personagem muito poderoso.

O Fluxograma.

O nascimento dos fluxogramas

A ideia é muito antiga.

Vem dos trabalhos de engenharia industrial.

Frank Gilbreth

Henry Gantt

Por volta de 1921 começaram a desenhar processos industriais.

Exemplo:

Receber matéria-prima

↓

Produzir

↓

Inspecionar

↓

Embalar

↓

Enviar

Décadas depois os computadores apareceram.

E alguém percebeu:

"Programas são processos."

Logo...

Processos industriais

viraram

Processos computacionais.

O modelo Waterfall

Se você trabalha em Mainframe bancário provavelmente ainda verá isso.

Waterfall.

As fases clássicas:

Requisitos

↓

Análise

↓

Fluxogramas

↓

Especificação Técnica

↓

Codificação

↓

Teste

↓

Implantação

Documentos clássicos do Waterfall

Documento Funcional

O que o sistema faz.

Exemplo:

Pagamento de boleto

Regra:

Se vencido

cobrar multa

Se pago em dia

valor normal

Documento Técnico

Como será implementado.

Exemplo:

Programa:

PAGBOL01

Tabela:

TB_BOLETO

Transação:

PB01

Copybooks

CPBOLETO

Fluxograma

É a ponte entre os dois.

Negócio

↓

Fluxograma

↓

COBOL

Bellacosa Mainframe e os simbolos de fluxograma

O que é um Fluxograma?

É uma representação gráfica de um algoritmo.

Ao invés de escrever:

IF SALDO > ZERO
   DISPLAY "OK"
ELSE
   DISPLAY "NEGADO"
END-IF

Desenhamos.

        ◇
SALDO > 0 ?
   /    \
 SIM    NÃO
 ↓       ↓
OK    NEGADO

Nosso cérebro entende imagens mais rapidamente.

Por isso funcionam.

Símbolos principais

Oval

Significado:

Início

Fim

Exemplo

 _______
(START )
 -------

 _______
( END  )
 -------

Retângulo

Processamento.

Fazer algo.

Exemplo:

Calcular juros

Atualizar cadastro

Mover campos

Exemplo COBOL

COMPUTE JUROS =
SALDO * 0.05

Fluxograma

□ Calcular juros

Losango

Decisão.

Pergunta.

Tem duas saídas.

SIM

NÃO

Exemplo

Cliente VIP?

COBOL

IF CLIENTE-VIP='S'

Paralelogramo

Entrada e saída.

DISPLAY

RECEIVE

SEND

Batch

Ler arquivo

Online

Receber PFKEY

Seta

Fluxo.

Indica sequência.

Sem seta.

Existe caos.

Com seta.

Existe entendimento.

Círculo

Conector.

Liga páginas.

Muito usado em especificações gigantes.

Página 1

↓

○A

Página 10

○A

continuação

Bellacosa Mainframe e um fluxograma cobol batch

Fluxograma de Batch COBOL

Imagine:

Pagar folha salarial.

Desenho

START

↓

Abrir arquivo

↓

Ler funcionário

↓

Fim Arquivo?

◇

Sim

Gerar relatório

END

Não

Calcular salário

Gravar saída

Ler próximo

COBOL

OPEN INPUT FUNCIONARIO

PERFORM UNTIL EOF='S'

 READ FUNCIONARIO

   AT END
      MOVE 'S' TO EOF

   NOT AT END

      PERFORM CALCULA

      WRITE REG-SAIDA

 END-READ

END-PERFORM

Bellacosa Mainframe exemplo de fluxograma cobol vsam

Fluxograma para VSAM

Abrir KSDS

↓

READ

↓

FOUND?

SIM

UPDATE

REWRITE

NÃO

WRITE

END

Bellacosa Mainframe exemplo de fluxograma online cics

Fluxograma Online CICS

Exemplo.

Consulta saldo.

START

Receber tela

↓

ENTER?

SIM

↓

Validar conta

↓

Conta existe?

◇

SIM

Ler DB2

Enviar tela

NÃO

Mensagem erro

END

COBOL

EXEC CICS RECEIVE MAP


EXEC SQL

SELECT SALDO

INTO :WS-SALDO

FROM CONTA


END-EXEC


EXEC CICS SEND MAP


END-EXEC

Bellacosa Mainframe exemplo de fluxograma db2

Fluxograma com DB2

Exemplo.

Transferência bancária.

START

Receber origem

Receber destino

Valor válido?

◇

SIM

BEGIN UNIT OF WORK

SELECT

UPDATE

COMMIT

NÃO

ROLLBACK

END

Fluxograma das tabelas DB2

Tabela

CLIENTE

Tabela

CONTA

Tabela

MOVIMENTO

Fluxo

CLIENTE

↓

CONTA

↓

MOVIMENTO

Exemplo SQL

SELECT
C.NOME,
M.VALOR

FROM CLIENTE C

JOIN CONTA CT

ON...

JOIN MOVIMENTO M

Fluxograma ajuda a enxergar joins.

Workflow

Muitos confundem.

Fluxograma

não é

Workflow

Mas workflow pode usar fluxograma.

Exemplo

Solicitação crédito

Cliente

↓

Análise

↓

Aprovação gerente

↓

Compliance

↓

Liberação

Hoje isso está em:

IBM BPM

Camunda

ServiceNow

Power Automate

Fluxos de diálogo

Muito usado em CICS.

Tela login

↓

Senha válida?

◇

Sim

Não

Mensagem erro

Chatbots fazem isso.

ChatGPT faz isso.

URA faz isso.

PIX faz isso.

Boas práticas

1 Não cruzar linhas

Errado

Linhas embaralhadas.

Causa dor psicológica.

2 Usar nomes claros

Errado

Processo 1

Correto

Calcular IOF

3 Uma decisão por vez

Evita confusão.

4 Modularizar

Subfluxos.

Exemplo

Pagamento

↓

Calcular imposto

↓

Fluxograma separado

Curiosidades

Easter Egg 1

COBOL nasceu em 1959.

Fluxogramas já eram padrão.

Easter Egg 2

Muitos programadores COBOL dos anos 80 codificavam olhando apenas para fluxogramas.

Nem tinham acesso ao usuário.

Easter Egg 3

Ferramentas CASE prometiam gerar COBOL automaticamente.

Excelerator

ADW

CoolGen

IEF

Pacbase

A ideia era:

Desenhar

Gerar programa

Compilar

Easter Egg 4

IBM usou fluxogramas extensivamente na documentação do OS/360.

Centenas de páginas.

Easter Egg 5

DFSORT pode ser representado perfeitamente por fluxograma.

INPUT

↓

SORT

↓

SUM

↓

OUTREC

↓

OUTPUT

Por que ainda usamos em Mainframe?

Porque sistemas bancários possuem:

Centenas de regras

Milhares de IFs

Milhões de contas

Um código COBOL pode ter:

30000 linhas

500 parágrafos

200 IFs

Ler isso é cansativo.

Ver um desenho leva segundos.

O Fluxograma como ferramenta de sobrevivência do Padawan COBOL

Imagine receber:

Programa:

FINA0345

38 mil linhas.

Criado em 1994.

Sem documentação.

Sem analista.

Sem usuário.

Sem autor.

Você abre.

Encontra:

PERFORM P1120

PERFORM P1130

PERFORM P1140

PERFORM P1150

O que fazem?

Ninguém sabe.

Mas após desenhar:

START

↓

Validar Cliente

↓

Consultar DB2

↓

Calcular Limite

↓

Atualizar Histórico

↓

Gerar Extrato

↓

END

Tudo fica claro.

É por isso que arquitetos, analistas de sistemas, especialistas em CICS, DB2, IMS, MQ, BPM e até equipes DevOps continuam utilizando fluxogramas.

Eles não substituem COBOL.

Não substituem UML.

Não substituem documentação funcional.

Mas fazem algo extremamente valioso: transformam milhares de linhas de código em uma história visual que qualquer pessoa consegue seguir.

E, no universo Bellacosa Mainframe, talvez esta seja a melhor definição possível:

Fluxograma é o mapa da dungeon. COBOL é a espada. DB2 é o tesouro. CICS é o portal de entrada. E o programador júnior que aprende a desenhar processos deixa de ser apenas um codificador e começa a pensar como um verdadeiro Analista de Sistemas do Reino IBM Z. ☕🚀

terça-feira, 25 de fevereiro de 2020

☕💥 Os 10 Padrões Secretos de Arrays em COBOL Mainframe

Bellacosa Mainframe e 10 padroes secretos de arrays

☕💥 Os 10 Padrões Secretos de Arrays em COBOL Mainframe

Ou como descobrir que você já usava algoritmos de entrevistas do LeetCode muito antes deles virarem moda

Introdução

Existe uma curiosidade engraçada no mundo da programação.

Um desenvolvedor Java estuda LeetCode.

Um desenvolvedor Python assiste vídeos sobre algoritmos.

Um engenheiro C++ compra livros de Competitive Programming.

Enquanto isso...

Um programador COBOL de banco com vinte anos de experiência está processando 300 milhões de registros no Batch Noturno utilizando exatamente os mesmos algoritmos...

Mas chama tudo de:

"andar na tabela"

"fazer acumulado"

"pesquisa binária"

"comparar dois índices"

"janela de análise"

E provavelmente faz isso tomando café às 3 da manhã olhando um SDSF.

A verdade é que muitos dos algoritmos mais famosos ensinados atualmente em universidades e plataformas de entrevistas já existem no universo COBOL há décadas.

OCCURS.

INDEXED BY.

SEARCH.

SEARCH ALL.

SET UP.

SET DOWN.

ASCENDING KEY.

Tabelas auxiliares.

Acumuladores.

Áreas de trabalho.

Tudo isso forma um verdadeiro arsenal de algoritmos.

E hoje vamos conhecer os 10 padrões clássicos de Arrays, explicados para um Padawan COBOL.

Padrão 1 — Two Pointers

Os Dois Jedi da Tabela

É provavelmente o algoritmo mais antigo do mundo corporativo.

A ideia é simples.

Utilizamos dois ponteiros.

Um na esquerda.

Outro na direita.

Ou ambos andando em velocidades diferentes.

Exemplo

Verificar se uma tabela é simétrica.

01 TAB.

   05 ITEM OCCURS 100 TIMES
      INDEXED BY IDX1 IDX2.

77 MAX PIC 999 VALUE 100.



SET IDX1 TO 1
SET IDX2 TO MAX



PERFORM UNTIL IDX1 >= IDX2


   IF ITEM(IDX1) NOT = ITEM(IDX2)

      DISPLAY 'NAO SIMETRICO'

   END-IF


   SET IDX1 UP BY 1
   SET IDX2 DOWN BY 1


END-PERFORM

Onde aparece?

Remover duplicidade

Palíndromo

Conciliação bancária

Arquivos ordenados

Merge VSAM

Join Batch

Complexidade

O(n)

Padrão 2 — Sliding Window

A Janela Deslizante

Esse algoritmo parece sofisticado.

Mas todo programador financeiro já utilizou.

Exemplo

Últimos 30 dias.

Tabela

Janela

Primeira

10 20 15

Soma

Move.

20 15 40

Move.

15 40 50

105

COBOL


ADD ENTRADA(I)
TO SOMA


SUBTRACT ENTRADA(I-3)

FROM SOMA

Muito usado em:

Detecção fraude

PIX

Cartão crédito

Médias móveis

SMF

Complexidade

O(n)

Padrão 3 — Prefix Sum

O Acumulador Supremo

Padawan.

Você provavelmente já usou.

Só não sabia o nome.

Exemplo.

Tabela.

5 3 2 4 1

Prefix.

Consultar.

Posição.

2 até 5.

15 - 5

COBOL

ADD VALOR(I)

TO ACUM(I-1)

GIVING ACUM(I)

Utilização.

Analytics

RMF

SMF

Cobrança

Padrão 4 — Kadane

O Santo Graal das Séries

Maior sequência positiva.

Exemplo.

Resultado.

COBOL

IF SOMA < ZERO

MOVE ZERO TO SOMA

END-IF

Aplicações.

Lucro máximo

Oscilações

Bolsa

PIX

Cartões

Complexidade.

O(n)

Padrão 5 — Merge Intervals

Fundindo Períodos

Muito usado.

Principalmente bancos.

Exemplo.

Cliente bloqueado.

01-05

03-10

12-20

Resultado.

01-10

12-20

COBOL

Comparar.

Datas.

Mesclar.

Usado.

Seguros

Férias

Janelas batch

Padrão 6 — Cyclic Sort

A Ordem Cósmica

Pouco conhecido.

Mas genial.

Exemplo.

3 1 2

Cada número.

Vai para posição.

Correta.

Resultado.

1 2 3

Muito útil.

Detectar.

Ausentes.

Duplicados.

Padrão 7 — Hashing

O Cache Jedi

Python

Dict

Java

HashMap

COBOL

Tabela OCCURS

Exemplo.

Estados.

SP


RJ


MG

Pesquisar.

Instantaneamente.

Alternativa.

SEARCH ALL

Exemplo.

Tabela IR.

Códigos.

CEP.

Produtos.

Padrão 8 — Binary Search

SEARCH ALL

A arma secreta do COBOL.

Tabela ordenada.

SEARCH ALL CLIENTE

Complexidade.

O(log n)

1000000 registros.

Comparações.

Magia matemática.

Muito superior.

SEARCH.

500 mil leituras.

SEARCH ALL.

Padrão 9 — Monotonic Stack

O Mestre Esquecido

Pouco usado.

Mas poderoso.

Encontrar.

Próximo maior.

Próximo menor.

Exemplo.

Temperaturas.

Pergunta.

Quando esquenta?

Em COBOL.

Pode ser implementado.

Com tabela OCCURS.

Muito usado.

Forecast.

Analytics.

IA.

Padrão 10 — Two Heaps

O Conselho Jedi

Min Heap.

Max Heap.

Encontrar.

Top 10.

Maior.

Menor.

Mediana.

Em COBOL.

Mais raro.

Mas possível.

Exemplo.

Ranking clientes.

SEARCH versus SEARCH ALL

Padawan.

Essa é importante.

Linear.

O(n)

SEARCH ALL

O(log n)

1000000 registros.

SEARCH.

500000 leituras.

SEARCH ALL.

INDEX versus Subscript

Subscript.

CLIENTE(I)

Índice.

INDEXED BY IDX

Mais rápido.

Menos cálculos.

Melhor cache.

SSRANGE

O Guardião das Tabelas

Sempre.

DEV.

TESTE.

QA.

Nunca acessar.

CLIENTE(1001)

Se existem.

SSRANGE salva vidas.

Quando usar DB2

Tabela enorme.

Não use OCCURS.

Quando usar OCCURS

Lookup.

UF.

IR.

CEP.

Parâmetros.

Cache.

Arquitetura Moderna

Hoje.

Programadores resolvem LeetCode.

Veteranos Mainframe.

Já faziam isso.

Em 1982.

Usando.

COBOL

VSAM

JCL

DFSORT

ICETOOL

DB2

Curiosidade Histórica

Década de 70.

IBM chamava isso.

Table Processing

Década de 80.

Performance Tuning.

Década de 90.

Binary Search.

Virou padrão.

Grandes bancos.

Década de 2000.

Java descobriu.

Collections.

Década de 2020.

LeetCode descobriu.

Década de 2030.

IA vai descobrir.

Que um programador COBOL aposentado em Campinas ou Itatiba já utilizava Prefix Sum desde 1989.

Easter Egg Bellacosa

Existe uma antiga profecia dos Sysprogs.

Ela diz:

"Chegará um dia em que um desenvolvedor júnior perguntará ao arquiteto qual algoritmo usar."

O arquiteto responderá:

Use Sliding Window.

O desenvolvedor pesquisará durante três horas.

Assistirá quatro vídeos.

Lerá cinco artigos.

Abrirá o ChatGPT.

Fará benchmarking.

Criará um POC.

E finalmente implementará.

Enquanto isso, um programador COBOL veterano sentado ao lado apenas dirá:

Ah...

Você queria uma média móvel.

Faço isso desde 1993.

Está no PROGFINC.

Linha 287.

Não mexe.

Funciona.

E agora pega um café.

Porque no Reino do Mainframe, muitas vezes os algoritmos mais modernos apenas receberam nomes mais bonitos para técnicas que os Cavaleiros COBOL já dominavam há décadas.

quarta-feira, 8 de janeiro de 2020

☕💥 Algoritmos no Mainframe: Da Matemática de Al-Khwarizmi ao COBOL no z/OS

Bellacosa Mainframe apresenta algoritmos na programação

☕💥 Algoritmos no Mainframe: Da Matemática de Al-Khwarizmi ao COBOL no z/OS

Ou como um programador COBOL Padawan descobre que, antes de existir código, existia lógica

"Um bom algoritmo faz um bom programa. Um excelente algoritmo faz o programador parecer um mago. Um algoritmo ruim faz o operador do turno da madrugada querer abrir um chamado para exorcismo."

— Bellacosa Mainframe

Introdução

Existe uma frase que gosto de repetir aos meus alunos padawans:

"COBOL não é difícil. Difícil é pensar."

E isso pode soar estranho.

Muitos acreditam que programar significa decorar comandos, aprender sintaxe, conhecer verbos COBOL ou dominar JCL.

Não.

Programar é, essencialmente, aprender a pensar de forma estruturada.

E isso possui um nome.

Algoritmo.

Antes do COBOL.

Antes do Assembler.

Antes do FORTRAN.

Antes do System/360.

Antes do z16.

Antes do ChatGPT.

Já existiam algoritmos.

E a história deles é simplesmente fantástica.

O nascimento dos algoritmos

A palavra algoritmo deriva do nome do matemático persa:

Muhammad ibn Musa al-Khwarizmi

(cerca de 780–850 d.C.)

Ele escreveu um tratado chamado:

"Kitab al-Jabr wa-l-Muqabala"

Livro que deu origem à palavra:

Algebra

E seu nome latinizado tornou-se:

Algorismus

Posteriormente:

Algorithm

Ou seja...

Cada vez que fazemos:

ADD A TO B GIVING TOTAL

estamos usando ideias desenvolvidas há mais de mil anos.

Algoritmos antes dos computadores

Curiosamente, algoritmos são muito mais antigos que computadores.

Exemplos:

Receitas culinárias

Procedimentos militares

Construção de pirâmides

Cálculos astronômicos

Navegação marítima

Tributação romana

Tudo era algoritmo.

Apenas não era chamado assim.

O primeiro algoritmo famoso

O algoritmo de Euclides.

300 a.C.

Encontrar o MDC.

Exemplo:

MDC(48,18)

Passo 1

48 mod 18 = 12

Passo 2

18 mod 12 = 6

Passo 3

12 mod 6 =0

Resposta

Dois mil anos depois...

Continuamos utilizando a mesma lógica.

A chegada dos computadores

Década de 1940.

ENIAC

UNIVAC

EDSAC

LEO I

IBM 650

IBM 7070

A grande dificuldade não era processador.

Era ensinar uma máquina a pensar.

E pensar significava:

Transformar problemas em algoritmos.

O nascimento do mainframe

1952

IBM 701

1954

IBM 704

1964

System/360

Um dos projetos mais revolucionários da história.

Pela primeira vez:

Uma arquitetura única.

Diversos equipamentos.

Compatibilidade.

E o software começava a ganhar importância.

O problema dos programas gigantes

Década de 50.

Empresas começavam a automatizar:

Folha de pagamento

Seguros

Bancos

Governo

Previdência

Surgiu um problema.

Como ensinar milhares de pessoas a desenvolver sistemas?

Resposta:

Criando linguagens de alto nível.

COBOL nasce em 1959

CODASYL.

Grace Hopper.

Departamento de Defesa Americano.

Objetivo:

Criar uma linguagem próxima do inglês.

Exemplo:

READ CLIENTE

IF SALDO > 1000

   PERFORM LIBERA-CREDITO

END-IF

Mas existe um detalhe importante.

COBOL não pensa.

Quem pensa é o desenvolvedor.

COBOL apenas executa.

O algoritmo continua sendo o verdadeiro cérebro.

O algoritmo escondido dentro do COBOL

Muitos iniciantes acreditam:

"Aprendi COBOL."

Não.

Aprendeu comandos.

Programar é construir algoritmos.

Exemplo.

Problema:

Calcular média.

Padawan inexperiente:

ADD A TO B
ADD C TO TOTAL
DIVIDE 3 INTO TOTAL

Padawan treinado:

Entrada

3 notas

Processamento

Somar

Dividir

Saída

Média

Ele pensa primeiro.

Codifica depois.

Características de um algoritmo

Entrada

Pode possuir dados.

Exemplo:

Arquivo VSAM

DB2

GDG

SYSIN

Saída

Relatório

Arquivo

Mensagem

Tela CICS

API JSON

Finitude

Todo algoritmo precisa terminar.

Exemplo ruim:

PERFORM FOREVER

Exemplo bom:

PERFORM UNTIL EOF='S'

Clareza

Evitar ambiguidades.

Ruim:

"Processar cliente"

Bom:

Ler registro

Validar CPF

Consultar saldo

Atualizar DB2

Gravar auditoria

Algoritmos nos Batchs Mainframe

Imagine.

Banco processando PIX.

2 bilhões de registros.

A lógica continua igual.

Entrada

SORTIN

Processamento

JOINKEYS

ICETOOL

COBOL

Saída

SORTOUT

Relatórios

DB2

O algoritmo do fechamento bancário

Leitura

Validação

Consolidação

Apuração

Tributação

Geração de extrato

Backup

Auditoria

Tudo algoritmo.

Algoritmos no CICS

O novato vê:

EXEC CICS RECEIVE

EXEC CICS SEND

EXEC CICS LINK

Mas por trás existe:

Receber dados

Validar

Consultar

Persistir

Retornar

Fluxo decisório.

Algoritmos no Natural

Mesmo conceito.

MAP

READ

FIND

END-FIND

ESCAPE TOP

DECIDE ON

São apenas ferramentas.

O raciocínio continua sendo algoritmo.

Pseudocódigo

Excelente ferramenta para padawans.

Exemplo.

Transferência bancária.



Inicio


Ler conta origem


Ler conta destino


Ler valor


Saldo suficiente ?


SIM


Debitar


Creditar


Gerar log


Nao


Retornar erro



Fim

Só depois escrevemos COBOL.

Fluxogramas

Muito utilizados nos anos 70.

Analistas desenhavam:

Retângulos

Losangos

Setas

Pastas físicas.

Canetas.

Régua.

Pranchetas.

Sim.

Mainframe já existia antes do Visio.

Algoritmos de busca

Busca sequencial.

Busca binária.

Hash.

Índices VSAM.

DB2 Index.

B-tree.

LSM Trees.

Todos são algoritmos.

Algoritmos de ordenação

Mainframe ama ordenação.

DFSORT.

SYNCSORT.

ICETOOL.

Métodos famosos:

Bubble Sort

Merge Sort

QuickSort

HeapSort

No universo IBM, o Merge Sort praticamente reina.

Complexidade computacional

Nem todo algoritmo é igual.

O(1)

Constante

O(log n)

Busca binária

O(n)

Linear

O(n²)

Bubble

O(2ⁿ)

Exponencial

O dia em que um COBOL virou um monstro

Já vi programa COBOL com:

70 mil linhas.

350 PERFORM.

1200 IF.

85 GO TO.

Documentação inexistente.

Autor aposentado em 1998.

Chamado aberto em produção.

Ninguém sabe mexer.

Por quê?

Ausência de algoritmo.

Código cresceu.

Pensamento não.

Design de algoritmos

Força Bruta

Dividir e conquistar

Backtracking

Greedy

Programação dinâmica

Mesmo em bancos.

Mesmo em seguradoras.

Mesmo em governo.

Algoritmos modernos no IBM Z

Hoje temos:

z16

z17

LinuxONE

OpenShift

zCX

API Connect

z/OS Connect

Kafka

Python

Java

Node.js

Machine Learning

Mas adivinhe.

O algoritmo continua sendo rei.

Inteligência Artificial também vive de algoritmos

Redes neurais.

Transformers.

LLMs.

Árvores.

Regressão.

Clustering.

Tudo algoritmo.

A IA não substituiu algoritmos.

Ela apenas os sofisticou.

O maior erro dos novos programadores

Querer aprender linguagem.

Antes de aprender lógica.

É equivalente a comprar um sabre de luz sem saber usar a Força.

Conselhos para um Padawan COBOL

Primeiro pense.

Depois desenhe.

Depois escreva.

Depois teste.

Depois otimize.

Nunca faça o inverso.

Pergunte sempre:

Quais entradas?

Qual processamento?

Qual saída?

Existem exceções?

Qual volume?

Como recuperar falhas?

Como auditar?

Como escalar?

O algoritmo invisível que move o mundo

Quando um cliente faz PIX.

Existe algoritmo.

Quando um avião decola.

Existe algoritmo.

Quando uma seguradora calcula prêmio.

Existe algoritmo.

Quando um cartão aprova compra.

Existe algoritmo.

Quando o INSS paga benefícios.

Existe algoritmo.

Quando um CICS responde em menos de um segundo.

Existe algoritmo.

E quando um velho programa COBOL criado em 1987 continua funcionando perfeitamente em um IBM Z moderno...

Existe um bom algoritmo escondido ali.

Considerações finais

Muitos dizem que COBOL é uma linguagem antiga.

Discordo.

COBOL é apenas um meio de expressão.

A verdadeira tecnologia imortal chama-se algoritmo.

Ela nasceu com matemáticos árabes, sobreviveu aos impérios, atravessou a Revolução Industrial, alimentou os primeiros computadores, ajudou a criar o System/360, sustentou bancos por décadas, acompanhou a internet, chegou ao z/OS, conversa hoje com APIs REST e provavelmente continuará existindo quando estivermos programando computadores quânticos.

Portanto, jovem Padawan, lembre-se:

Você não é pago para escrever DISPLAY, MOVE, ADD ou EXEC CICS.

Você é pago para transformar problemas caóticos em sequências ordenadas de decisões capazes de gerar valor para empresas, governos e pessoas.

E esse poder, desde Al-Khwarizmi até o IBM z17, continua tendo exatamente o mesmo nome:

Algoritmo.

☕🚀 E como diria um velho mestre do Bellacosa Mainframe:

"Código envelhece. Linguagens mudam. Frameworks desaparecem. Mas um algoritmo elegante continua sendo reconhecido por qualquer programador, em qualquer época, em qualquer plataforma."

Translate

terça-feira, 31 de março de 2026