☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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

sexta-feira, 12 de junho de 2026

☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?


Bellacosa Mainframe e tenta entender a razao do Cobol nao existir fora do Mainframe

☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?

Quando alguém fala em COBOL, a maioria das pessoas imediatamente imagina um enorme IBM Z, salas refrigeradas, bancos, seguradoras e sistemas que movimentam bilhões de dólares por dia.

Mas existe uma curiosidade que poucos conhecem:

O COBOL nunca foi exclusivo do Mainframe.

Durante décadas existiram versões para:

  • MS-DOS

  • Windows

  • Linux

  • Unix

  • AIX

  • HP-UX

  • Solaris

  • AS/400

  • VMS

  • até mesmo Raspberry Pi atualmente

Empresas como Micro Focus, Fujitsu, RM/COBOL, Acucobol, GNUCobol e outras investiram milhões tentando popularizar o COBOL fora do universo IBM.

Mesmo assim, quando ouvimos a palavra COBOL em 2026, quase todo mundo associa imediatamente ao Mainframe.

A pergunta é inevitável:

Por que isso aconteceu?

Por que Java virou universal?

Por que C conquistou sistemas operacionais?

Por que Python dominou a automação?

E por que COBOL permaneceu praticamente "preso" ao Mainframe?

A resposta envolve tecnologia, mercado, marketing, história, cultura corporativa e até psicologia.

Pegue seu café.

Hoje vamos mergulhar em uma das maiores curiosidades da história da computação.


O MAIOR MITO SOBRE COBOL

Existe uma crença popular:

"COBOL só funciona em Mainframe."

Isso nunca foi verdade.

Desde os anos 70 já existiam compiladores COBOL para minicomputadores.

Nos anos 80 surgiram versões para:

  • DOS

  • Unix

  • VAX/VMS

Nos anos 90:

  • Windows

  • OS/2

  • Linux

Nos anos 2000:

  • .NET

  • JVM

  • Web Services

Tecnicamente falando, o COBOL poderia ter seguido praticamente qualquer caminho.

Mas não seguiu.


O PROBLEMA NUNCA FOI A LINGUAGEM

Essa é a primeira coisa que surpreende muita gente.

O COBOL não fracassou fora do Mainframe porque era ruim.

Na verdade ele possuía diversas vantagens.

Extremamente legível

Exemplo:

IF SALDO-CONTA IS GREATER THAN LIMITE-CREDITO
   DISPLAY "LIMITE EXCEDIDO"
END-IF

Até alguém sem conhecimento profundo consegue entender.


Excelente para regras de negócio

Bancos adoram COBOL porque ele descreve regras empresariais com clareza.

Por exemplo:

COMPUTE JUROS =
    VALOR * TAXA / 100

Não existe mistério.


Forte manipulação de registros

Antes dos bancos relacionais se popularizarem, isso era ouro.


Precisão decimal

Enquanto várias linguagens sofriam com arredondamentos, COBOL nasceu para dinheiro.

E dinheiro não aceita erro.


O VERDADEIRO PROBLEMA: O COBOL NASCEU PARA NEGÓCIOS

A palavra COBOL significa:

Common Business Oriented Language

Observe:

Não é:

  • Common Game Language

  • Common Scientific Language

  • Common Internet Language

É:

Business.

Negócios.

Empresas.

Contabilidade.

Folha de pagamento.

Seguros.

Finanças.

Faturamento.

Desde o nascimento, ele tinha um propósito extremamente específico.


ENQUANTO ISSO, O MUNDO MUDOU

Na década de 1960 isso era perfeito.

Mas nas décadas seguintes surgiram novos mercados.


Computação científica

FORTRAN dominou.


Sistemas operacionais

C dominou.


Inteligência Artificial

LISP dominou inicialmente.


Aplicações gráficas

C++


Internet

Java

PHP

Perl

JavaScript


Ciência de Dados

Python

R


O mundo começou a exigir coisas que nunca foram prioridade para o COBOL.


O COBOL NÃO FOI FEITO PARA SER "COOL"

Aqui existe um fator psicológico interessantíssimo.

Pense nos heróis da programação:

  • Linus Torvalds → C

  • Guido van Rossum → Python

  • Bjarne Stroustrup → C++

  • James Gosling → Java

Agora pense em COBOL.

A maioria das pessoas nem sabe quem foi Grace Hopper.

Grace Hopper ajudou a criar conceitos fundamentais que levariam ao COBOL.

Mas a linguagem nunca foi vendida como algo revolucionário.

Ela foi vendida como algo:

  • estável

  • corporativo

  • burocrático

E isso afasta jovens desenvolvedores.


O EFEITO "BANCO"

Imagine dois anúncios.

Linguagem A

"Crie jogos incríveis!"

Linguagem B

"Automatize cálculos atuariais."

Qual parece mais divertida?

Foi exatamente isso que aconteceu.

COBOL ficou associado a:

  • bancos

  • seguradoras

  • governos

  • sistemas legados

Enquanto outras linguagens ficaram associadas à inovação.


O ERRO DE MARKETING MAIS CARO DA HISTÓRIA

Durante os anos 80 e 90, universidades começaram a ensinar:

  • C

  • Pascal

  • C++

  • Java

COBOL desapareceu dos cursos.

A consequência foi devastadora.

Menos estudantes.

Menos projetos.

Menos comunidade.

Menos livros.

Menos ferramentas.

Menos conteúdo.

Menos adoção.

Criou-se um círculo vicioso.


O PROBLEMA DAS FERRAMENTAS

Vamos ser honestos.

Nos anos 90 era muito mais divertido programar Visual Basic do que COBOL.

Visual Basic tinha:

  • botões

  • janelas

  • eventos

Você arrastava componentes.

Tudo aparecia na tela.

COBOL continuava focado em:

OPEN INPUT CLIENTES
READ CLIENTES

O apelo visual era praticamente zero.


O MUNDO APAIXONOU-SE POR INTERFACES GRÁFICAS

Quando o Windows explodiu, surgiu uma nova geração de desenvolvedores.

Eles queriam construir:

  • telas

  • jogos

  • multimídia

COBOL não era o candidato natural.


O MAINFRAME PROTEGEU O COBOL

Aqui está a maior ironia.

O Mainframe foi simultaneamente:

  • a maior força do COBOL

  • e sua maior prisão

Sem Mainframe talvez COBOL tivesse desaparecido.

Mas graças ao Mainframe ele sobreviveu.

Por outro lado, o sucesso no Mainframe reduziu o incentivo para conquistar outros mercados.

Os bancos já estavam satisfeitos.

Por que mudar?


O FATOR ECONÔMICO

Imagine um banco.

Você possui:

  • 50 milhões de linhas COBOL

  • 40 anos de história

  • bilhões movimentados diariamente

Qual decisão é mais segura?

Opção A

Migrar tudo.

Opção B

Continuar usando COBOL.

A resposta é óbvia.


O EFEITO "SE ESTÁ FUNCIONANDO, NÃO MEXA"

Poucas linguagens tiveram a sorte de trabalhar em ambientes tão conservadores.

Um sistema bancário precisa:

  • estabilidade

  • previsibilidade

  • auditoria

Não precisa ser moderno.

Precisa funcionar.

E COBOL funciona.

Muito bem.


A CHEGADA DA INTERNET

Nos anos 90 surgiu a Web.

Foi uma nova corrida do ouro.

Linguagens correram para conquistar esse território.

  • Java

  • PHP

  • Perl

  • ASP

COBOL chegou depois.

Muito depois.

Quando chegou, o mercado já tinha donos.


O PROBLEMA DA COMUNIDADE

Uma linguagem vive ou morre pela comunidade.

Python possui:

  • milhões de usuários

  • milhares de bibliotecas

  • eventos globais

Java possui ecossistema gigantesco.

COBOL sempre teve uma comunidade menor.

Extremamente qualificada.

Mas menor.


O FATOR OPEN SOURCE

Outro golpe importante.

O movimento Open Source impulsionou:

  • Linux

  • Python

  • PHP

  • Perl

COBOL permaneceu muito ligado ao mundo corporativo.

Licenças caras.

Compiladores pagos.

Ferramentas empresariais.

Isso limitou sua expansão.


MAS EXISTE COBOL OPEN SOURCE

Hoje existe o fantástico:

GNUCobol

GnuCOBOL Official Project

Ele compila COBOL para C e roda em:

  • Linux

  • Windows

  • macOS

Mostrando que o COBOL continua vivo fora do Mainframe.


O COBOL É LENTO?

Outro mito.

Na verdade, muitas implementações COBOL são extremamente rápidas.

Especialmente em processamento transacional.

O problema nunca foi desempenho.


O COBOL É ANTIGO DEMAIS?

Também não.

Veja a ironia.

Hoje temos:

  • APIs REST

  • JSON

  • XML

  • Kafka

  • Containers

  • Docker

E o COBOL já conversa com tudo isso.

Inclusive o usuário Bellacosa Mainframe frequentemente explora integrações modernas entre COBOL, JSON, CICS Web Services e z/OS Connect.

O problema não é tecnológico.

É percepção de mercado.


O PARADOXO DO SUCESSO

O COBOL sofreu do mesmo problema que o DB2 Mainframe.

Ele ficou tão bom no que fazia que nunca precisou mudar radicalmente.

Enquanto outras linguagens lutavam para sobreviver, o COBOL já tinha conquistado o setor financeiro.


O QUE ACONTECERIA SE O COBOL FOSSE CRIADO HOJE?

Imagine uma linguagem com:

  • sintaxe legível

  • precisão decimal nativa

  • foco em regras de negócio

  • forte tipagem

  • excelente auditoria

Provavelmente seria vendida como:

  • FinTech Language

  • Banking Language

  • Enterprise Language

E talvez fosse considerada revolucionária.


O COBOL PERDEU A GUERRA?

Não.

Na verdade, ele venceu uma guerra diferente.

Enquanto milhares de linguagens nasceram e morreram, COBOL continua executando sistemas críticos após mais de seis décadas.

Poucas tecnologias na história conseguiram isso.


A VERDADE QUE POUCOS ADMITEM

Quando um programador Python cria um sistema hoje, ninguém sabe se ele existirá daqui a 30 anos.

Quando um programador COBOL cria um sistema bancário, existe uma boa chance de alguém ainda estar executando aquele código décadas depois.

Isso muda completamente a forma de projetar software.


A GRANDE LIÇÃO PARA OS PADAWANS

A pergunta correta não é:

"Por que COBOL ficou nichado no Mainframe?"

A pergunta correta é:

"Por que o Mainframe continuou sendo o melhor lugar para executar aquilo que o COBOL foi criado para fazer?"

Porque o COBOL nasceu para resolver problemas empresariais gigantescos.

E o Mainframe continua sendo a plataforma mais eficiente para executar esses processos com:

  • confiabilidade

  • segurança

  • disponibilidade

  • escalabilidade

  • integridade transacional

O COBOL não ficou preso ao Mainframe.

Na realidade, ele encontrou seu habitat natural.

As versões para DOS, Windows e Linux sempre existiram, continuam existindo e funcionam muito bem.

Mas fora do Mainframe ele precisava competir com centenas de linguagens.

Dentro do Mainframe ele se tornou rei.

E existe uma enorme diferença entre participar de uma competição e dominar um reino.

Mais de 65 anos depois de seu nascimento, o COBOL continua processando salários, aposentadorias, seguros, cartões de crédito, transferências bancárias e operações financeiras que sustentam boa parte da economia mundial.

Poucas linguagens podem dizer isso.

E talvez esse seja o maior paradoxo da computação:

O COBOL não conquistou todas as plataformas porque nunca precisou.

Ele já estava ocupado movendo o mundo. ☕🚀



sábado, 5 de abril de 2025

☕💥 Buffer Overflow, Memory Overwrite e Storage Corruption no z/OS

 

Bellacosa Mainframe e os perigos na gestão de memoria no mainframe

☕💥 Buffer Overflow, Memory Overwrite e Storage Corruption no z/OS

Ou como um simples MOVE pode transformar um datacenter multimilionário em uma sessão espírita conduzida por um Sysprog com café frio

 


Introdução

Existe uma frase antiga entre veteranos de Mainframe:

"Computadores não cometem erros. Eles apenas obedecem ordens idiotas em velocidades absurdamente altas."

E poucas coisas representam melhor isso do que três monstros ancestrais da programação:

  • Buffer Overflow

  • Memory Overwrite

  • Storage Corruption

O curioso é que muitos desenvolvedores COBOL juniores acreditam que isso é um problema de C, C++, Linux ou Windows.

Na verdade...

Mainframe conhece esses monstros desde que Elvis Presley ainda estava gravando discos.

A diferença é que o z/OS aprendeu a sobreviver a eles.

Hoje vamos entender como esses problemas surgem em:

  • COBOL

  • JCL

  • REXX

  • CICS

  • DB2

  • IMS

  • VSAM

  • Batch

  • JES2

  • SDSF

  • Language Environment

e principalmente...

como impedir que uma simples variável PIC X(10) provoque um incidente digno de abertura de War Room.


Capítulo 1

O que é Buffer Overflow?

Definição simples.

Você reservou espaço para 10.

Escreveu 100.

Fim.

Exemplo.

COBOL

01 WS-NOME.

   05 WS-TEXTO PIC X(10).



MOVE "BELLACOSA-MAINFRAME" TO WS-TEXTO

Teoricamente:

0123456789
BELLACOSA

Sobrou:

MAINFRAME

Para onde foi?

Depende.

Pode ir para:

Flag

Outra variável

LE Runtime

Heap

Stack


Linguagem C


char nome[10];

strcpy(nome,"BellacosaMainframe");

Mesmo problema.

COBOL apenas costuma esconder melhor.


Capítulo 2

Memory Overwrite

Buffer Overflow produz.

Memory Overwrite.

É o efeito colateral.


Exemplo

01 WS-AREA.

05 TABELA OCCURS 100.

10 COD PIC X.


05 FLAG PIC X.

Erro.

MOVE 'S'
TO TABELA(101)

Resultado.

FLAG = S


Pior.

Pode alterar:

SQLCA

DFHEIBLK

TGT

Save Area


Storage Corruption

É o estágio terminal.

Já não sabemos mais o que foi alterado.

O programa continua rodando.

Mas agora virou um zumbi.


O pesadelo

Job roda.

Termina RC=0000.

DB2 recebe dados errados.

VSAM inconsistente.

Extrato bancário incorreto.

E ninguém percebe.


Capítulo 3

Como o z/OS protege memória

1964

System/360

Quase nenhuma proteção.


Anos 70

Storage Keys

PSW


Anos 80

MVS/XA

Address Space


Anos 90

ESA

Cross Memory


Anos 2000

zOS

64 bits

LE

Heap protegido


Hoje

z16

z17

Guard Pages

Hardware assistido

Storage protection


O conceito de Address Space

Cada Job.

Cada TSO.

Cada CICS.

Possui seu universo.


Imagine apartamentos.

Apartamento 101.

COBOL.

Apartamento 102.

DB2.

Apartamento 103.

JES2.

Overflow.

Quebrou parede.

Invadiu apartamento vizinho.

Sysprog chora.


Capítulo 4

Batch

Batch é perigoso.

Porque roda horas.


Exemplo

5 milhões registros.

Erro.

Registro 3.456.789.

Corrupção.


Abends comuns

S0C4

Protection Exception


S0C7

Dados inválidos


S0C1

Opcode ilegal


S878

Storage


S80A

Memória insuficiente


U4038

LE detectou problema


Caso histórico

Década 90.

Seguradora.

Tabela OCCURS 500.

Nova regra.

700 elementos.

Programa não recompilado.

Sobrescreveu área.

Job fechou mensal.

Milhares apólices erradas.

Descoberta.

3 semanas depois.


Capítulo 5

CICS

No online.

Muito pior.


CICS compartilha recursos.

Tasking.

Threads.


Erro.

Pode derrubar milhares usuários.


DFHEIBLK corrompido.

Retorno errado.


Pseudo-conversacional.

COMMAREA.

Overflow.


Exemplo

DFHCOMMAREA PIC X(32767)

Recebe.

40 mil.

Boom.


Abends famosos

AEI9

ASRA

AEYD

APCT

AICA


AICA

Loop infinito.

CPU consumida.


ASRA

Equivalente S0C4.


Capítulo 6

DB2

DB2 é robusto.

Mas aplicativo não.


SQLDA.

SQLCA.

Host Variables.


Exemplo

PIC X(10)

Coluna VARCHAR(100)


Truncation.


SQLCODE

-302

-311

-305


Melhor prática.

Verificar.

SQLCODE.

Sempre.


Capítulo 7

IMS

IMS é uma máquina do tempo.

Ainda vivo.


PCB errado.

SSA inválida.

Pode gerar.

U0777


Overflow.

Área I/O.


Segmento corrompido.


Capítulo 8

VSAM

KSDS.

RRDS.

ESDS.


Erro clássico.

READ NEXT.

EOF ignorado.


Subscript inválido.


Storage corruption.


IDCAMS detecta.

VERIFY

EXAMINE


Capítulo 9

REXX

Parece inocente.

Não é.


Stem.

CLIENTE.0=100

DO I=1 TO 1000

SAY CLIENTE.I

END

Dados inexistentes.


RC inesperado.


Storage não costuma corromper.

Mas lógica.

Sim.


Capítulo 10

JES2

JES2 protege spool.


Mas programa pode gerar.

100 milhões linhas.

SYSOUT gigante.


JES2 sofre.


HASP...

mensagens.


Spool cheio.


Job cancelado.


Capítulo 11

SDSF

Melhor amigo.


ST

Status


DA

Address Spaces


LOG

Mensagens


ENC

Enclave


Examine.

MEMORY.

CPU.

Abends.


Capítulo 12

LE

Language Environment.

Herói desconhecido.


SSRANGE

CHECK

HEAPCHK

RPTSTG

TRAP

TERMTHDACT


Exemplo

PARM='TRAP(ON)'

Captura.

Stack.

Dump.


Capítulo 13

Ferramentas modernas

Fault Analyzer

Abend Aid

IBM Debug

IPDF

CEEDUMP


SMF

30

110

120


RMF


OMEGAMON


Z APM


Capítulo 14

Como programar seguro

Sempre

SSRANGE


Validar índices.

IF IDX <= MAX

Nunca confiar input.


CHECK LENGTH


SQLCODE


RESP

CICS


FILE STATUS


ON SIZE ERROR


INITIALIZE


INSPECT


TESTAR.

TESTAR.

TESTAR.


Capítulo 15

Detectando antes do caos

Pipeline ideal.

DEV

SSRANGE

QA

HEAPCHK

HML

TRAP

PRD

NOSSRANGE

SMF

OMEGAMON


Alarmes.

CPU.

Storage.

Abends.

Spool.

Response Time.


Easter Egg Bellacosa

Existe uma lenda em alguns datacenters.

Conta-se que um programa COBOL compilado em 1984 executava perfeitamente.

Até que um desenvolvedor júnior resolveu "modernizar".

Adicionou:

OCCURS 2000 TIMES

Compilou.

Promoveu.

Sexta-feira.

17h45.

Produção.

Fim de mês.

Folha salarial.

Executou.

RC=0000.

Tudo aparentemente perfeito.

Na segunda-feira descobriram que 12 mil funcionários haviam recebido exatamente:

R$ 0,01

O programa não havia abendado.

Não havia S0C4.

Não havia dump.

Apenas um discreto byte sobrescrito em uma área esquecida do Working Storage.

Dizem que o Sysprog responsável ainda hoje aparece pelos corredores do CPD segurando uma caneca de café e repetindo para novos desenvolvedores:

"Tem gente que teme IA substituir programadores. Eu temo programadores que compilam NOSSRANGE em homologação."


Conclusão

Os grandes incidentes em Mainframe raramente começam com uma pane espetacular.

Eles começam com pequenas negligências:

  • Um índice não validado;

  • Um OCCURS mal dimensionado;

  • Um SQLCODE ignorado;

  • Um COMMAREA maior que o esperado;

  • Um READ VSAM sem FILE STATUS;

  • Um JCL sem limites de espaço;

  • Um REXX assumindo que tudo sempre existe.

O z/OS evoluiu durante mais de 60 anos justamente para impedir que esses erros se transformem em catástrofes.

Mas a última linha de defesa continua sendo a mesma desde 1959:

O desenvolvedor que entende memória, respeita limites e trata cada MOVE como se estivesse carregando plutônio digital.

sexta-feira, 14 de março de 2025

Passwords vs Passphrases no RACF: O Escudo Jedi do Sysprog Padawan na Era do IBM z17

 

Bellacosa Mainframe apresenta passwords e passphrases no racf zos

Passwords vs Passphrases no RACF: O Escudo Jedi do Sysprog Padawan na Era do IBM z17

Quando oito caracteres já não conseguem proteger uma galáxia inteira

Por Vagner Bellacosa – Bellacosa Mainframe

"O medo leva ao improviso. O improviso leva ao post-it. O post-it leva ao incidente de segurança."

Introdução – O Jovem Padawan e a Porta do Datacenter

Todo Sysprog Padawan passa por um momento peculiar em sua jornada.

Ele aprende sobre JES2.

Descobre o SDSF.

Sobrevive ao primeiro ABEND.

Começa a entender o funcionamento do RACF.

Admira a elegância dos perfis FACILITY.

Tem pesadelos ocasionais com UACC(READ).

E, inevitavelmente, faz uma pergunta aparentemente inocente:

Mestre Bellacosa, por que ainda existem senhas de oito caracteres em um computador capaz de processar bilhões de transações por dia?

A pergunta é excelente.

E a resposta nos leva para uma viagem que começa na década de 1970 e termina nos sofisticados ambientes Zero Trust do IBM z17.

Este artigo não pretende apenas explicar a diferença entre Passwords e Passphrases no RACF.

Pretende mostrar como a evolução das credenciais acompanha a própria evolução do IBM Z.

Porque segurança em mainframe nunca foi apenas uma questão técnica.

Ela é uma filosofia operacional.

Uma disciplina.

E, em muitos aspectos, uma forma de arte.


O IBM Z nunca foi um computador comum

Muitas pessoas enxergam o mainframe apenas como um computador grande.

O Sysprog sabe que isso está longe da verdade.

O IBM Z é um ecossistema.

Ele é projetado para atender requisitos que poucas plataformas conseguem oferecer simultaneamente.

Disponibilidade próxima de 100%.

Escalabilidade extrema.

Auditoria detalhada.

Criptografia integrada.

Virtualização massiva.

Processamento transacional absurdo.

Em muitos bancos brasileiros, um único complexo IBM Z é responsável por:

PIX;

TED;

DOC;

Cartões;

Previdência;

Empréstimos;

Internet Banking;

Aplicativos móveis;

Open Finance.

Uma falha de autenticação em um ambiente desses não representa apenas um problema técnico.

Representa potencialmente milhões de reais em perdas.

Representa vazamento de informações.

Representa riscos regulatórios.

Representa danos reputacionais.

Por isso RACF existe.


RACF: O Mestre Guardião da Ordem Jedi

RACF significa:

Resource Access Control Facility.

Ele não é apenas um produto.

Ele é praticamente o sistema imunológico do z/OS.

RACF controla:

Usuários;

Grupos;

Datasets;

CICS;

DB2;

TSO;

UNIX System Services;

MQ;

JES;

Operações especiais.

Quando um usuário digita:

LOGON VAGNER

RACF faz inúmeras verificações.

Quem é você?

Você realmente é você?

Sua senha expirou?

Está revogada?

Tentou errar várias vezes?

Está autorizado ao dataset?

É quase como um Jedi verificando um visitante tentando entrar no Templo de Coruscant.


O legado das senhas de oito caracteres

Um jovem profissional pode achar estranho.

Como assim apenas oito caracteres?

A explicação está na história.

RACF surgiu em uma época muito diferente.

Década de 70.

Redes fechadas.

Terminais 3270.

Linhas SNA.

Poucos usuários externos.

Ataques pela Internet?

Praticamente inexistentes.

Botnets?

Não.

GPUs especializadas?

Não.

Malwares ladrões de credenciais?

Não.

Naquele contexto:

ABCD1234

Era aceitável.

Não porque fosse forte.

Mas porque o modelo de ameaças era outro.


O universo mudou

Hoje o cenário é completamente diferente.

Temos:

Credential stuffing.

Ataques automatizados.

Malwares infostealers.

Phishing.

Engenharia social.

Ataques offline.

Data breaches.

Dark web.

Inteligência artificial.

Sistemas expostos por APIs.

Open Banking.

Open Finance.

Cloud híbrida.

VPNs comprometidas.

O atacante atual possui recursos que um hacker dos anos 80 jamais sonharia possuir.


Entropia: o combustível da Força

Um dos conceitos mais importantes em segurança é a entropia.

Podemos simplificar:

Quanto mais possibilidades existem, maior a entropia.

Quanto maior a entropia, mais difícil é descobrir a credencial.

Imagine um cofre.

Primeiro cofre.

100 combinações.

Segundo cofre.

10 bilhões de combinações.

Qual deles você escolheria?

A resposta é óbvia.


O limite matemático das Passwords

Uma senha de oito caracteres possui restrições.

Mesmo utilizando:

Maiúsculas

Minúsculas

Números

Caracteres especiais

Existe um teto.

Por exemplo.

66 opções possíveis.

Elevadas à oitava potência.

66⁸

Aproximadamente.

360 trilhões.

Parece muito.

Mas não é.

Não para hardware especializado.


O grande inimigo chama-se previsibilidade

Padawans adoram criar senhas criativas.

Infelizmente os atacantes também adoram.

Exemplos clássicos:

IBM2026

Cobol65

Mainframe1

Banco123

Bellacosa2026

Parece forte.

Mas é previsível.

Ferramentas modernas usam regras.

Substituições.

Palavras comuns.

Datas.

Nomes próprios.

Centenas de milhões de combinações inteligentes.

Em poucos minutos.


A ascensão das Passphrases

IBM percebeu essa limitação.

E RACF evoluiu.

Surgiu o conceito de Passphrase.

Inicialmente:

14 caracteres mínimos.

Posteriormente.

9 até 100 caracteres.

Uma enorme evolução.


Regras do RACF para Passphrases

O RACF não permite qualquer frase.

Existem salvaguardas.

Não conter o userid.

Possuir duas letras.

Possuir dois caracteres especiais.

Não repetir três caracteres iguais.

Exemplo:

Errado.

VAGNER2026

Errado.

AAAAAAAAAAAA

Errado.

Bellacosa!!!

Correto.

MeuCafeNoMainframe@2026

O crescimento exponencial da segurança

Aqui está o ponto mais fascinante.

Adicionar caracteres produz crescimento exponencial.

Não linear.

Imagine.

8 caracteres.

66⁸

14 caracteres.

66¹⁴

A diferença é quase incompreensível.

É como comparar.

Um copo de água.

Com o Oceano Pacífico.


O ataque de força bruta

Suponhamos.

Um laboratório possui capacidade de testar.

100 bilhões de combinações por segundo.

Uma senha simples.

Pode ser quebrada rapidamente.

Uma passphrase longa.

Poderia levar bilhões de anos.

Na prática.

É impossível.


O paradoxo do ser humano

Até aqui tudo parece resolvido.

Use passphrases.

Fim do artigo.

Não.

Existe um detalhe.

O usuário.

O elo mais imprevisível.


Cenário 1

Senha impossível.

Q7#Xt29L@P

Usuário esquece.

Anota.

Cola no monitor.

Segurança destruída.


Cenário 2

Mesma senha em vinte sistemas.

Vazamento único.

Comprometimento múltiplo.


Cenário 3

Passphrase amigável.

EuTomoCafeNoBellacosa@TodaManha2026

Grande.

Memorável.

Complexa.

Excelente.


O ensinamento do XKCD

Existe uma famosa tirinha.

Ela revolucionou a discussão sobre senhas.

Mostra algo interessante.

Senha.

Tr0ub4dor&3

Difícil lembrar.

Passphrase.

correct horse battery staple

Muito maior.

Muito mais fácil.

Muito mais segura.

A indústria inteira começou a reconsiderar suas práticas.


O NIST mudou de ideia

Antigamente.

As organizações exigiam.

Trocar senha mensalmente.

Símbolos obrigatórios.

Perguntas secretas.

Regras absurdas.

Exemplos.

SenhaJan2026
SenhaFev2026
SenhaMar2026

O usuário apenas incrementava o mês.

Nada realmente melhorava.

Hoje.

O NIST recomenda.

Passphrases longas.

Bloqueio contra senhas vazadas.

MFA.

FIDO2.

Autenticação forte.


O IBM z17 e a era Passwordless

O IBM z17 representa outra etapa evolutiva.

O objetivo não é apenas fortalecer senhas.

É eliminar senhas.

Tecnologias disponíveis.

Certificados.

Smartcards.

PIV.

Kerberos.

RACF MFA.

Passkeys.

Tokens.

Biometria.


MFA: Dois sabres de luz são melhores que um

Autenticação multifator funciona porque exige mais de um elemento.

Algo que você sabe.

Passphrase.

Algo que possui.

Token.

Algo que é.

Biometria.

Um atacante pode roubar uma senha.

Pode até enganar um usuário.

Mas roubar múltiplos fatores simultaneamente é muito mais difícil.


IDs Técnicos também merecem atenção

Muitos ambientes possuem.

USRBATCH.

DB2ADM.

CICSSTC.

MQMGR.

FTPUSER.

Estas contas frequentemente permanecem anos sem revisão.

Grande erro.

Devemos utilizar.

Rotação automática.

Vault corporativo.

Segredos temporários.

Auditoria constante.


O Sysprog Padawan em 2026

O Padawan moderno não pode ser apenas especialista em JCL.

Ele precisa entender.

Zero Trust.

Identidade.

Criptografia.

OAuth.

JWT.

OpenID.

PKI.

MFA.

Threat Hunting.

SIEM.

Compliance.

Porque o papel do Sysprog mudou.

Ele deixou de ser apenas um operador do sistema.

Tornou-se um arquiteto de confiança digital.


A recomendação do Mestre Bellacosa

Se eu estivesse formando uma academia para Sysprogs Padawans em 2026, minhas recomendações seriam:

Usuário comum.

Passphrase com vinte caracteres.

Desenvolvedor.

Passphrase mais MFA.

Administrador RACF.

MFA obrigatório.

IDs privilegiados.

Certificados digitais.

APIs.

OAuth2.

Serviços automatizados.

Segredos rotacionados.

Parceiros externos.

Autenticação federada.


Considerações finais – A verdadeira lição do RACF

No final das contas, a discussão sobre Passwords versus Passphrases não trata apenas de matemática.

Também não trata apenas de criptografia.

Ela fala sobre pessoas.

Sobre hábitos.

Sobre comportamento.

Sobre cultura organizacional.

Sobre engenharia de confiança.

O RACF continua sendo um dos sistemas de controle de acesso mais sofisticados já construídos.

Mas nem mesmo um IBM z17 equipado com processadores criptográficos dedicados consegue proteger uma organização cujo administrador utiliza uma senha anotada em um caderno escondido sob o teclado.

A verdadeira segurança surge quando tecnologia, processos e pessoas trabalham em harmonia.

E talvez esta seja a maior lição para todo Sysprog Padawan.

Aprender comandos é importante.

Dominar SETROPTS é valioso.

Entender SURROGAT, FACILITY e OPERCMDS é fundamental.

Mas compreender que segurança é uma disciplina viva, que evolui constantemente diante de novas ameaças, é o que realmente separa um aprendiz de um Mestre da Ordem Mainframe.

E lembre-se sempre:

No IBM Z, a Força não está apenas no processador. Ela também está na credencial que impede o lado sombrio de assumir o controle da galáxia corporativa.

 

terça-feira, 9 de julho de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Padawan Avançado - Parte IV

 

Bellacosa Mainframe e os ponteiros de memoria em cobol Parte IV

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 4 – O Padawan Avançado

COBOL, Metal C, APIs, Buffers Compartilhados, JSON, MQ e as Técnicas Jedi de Alto Desempenho no IBM Z

Por Bellacosa Mainframe


"O Padawan aprende MOVE. O Cavaleiro aprende BASED. O Mestre aprende que um ponteiro pode conectar universos inteiros."

Mestre Bellacosa Sysprog Jedi


Introdução

Chegamos ao último módulo do Holocron dos Ponteiros COBOL.

Nas partes anteriores aprendemos:

Parte 1

  • USAGE POINTER

  • ADDRESS OF

  • SET

  • AMODE

  • Heap

  • Stack

Parte 2

  • BASED

  • ALLOCATE

  • FREE

  • CEEGTST

  • Estruturas dinâmicas

Parte 3

  • SOC4

  • Memory Leak

  • Overlay

  • CEEDUMP

  • IPCS

  • Fault Analyzer

O jovem Padawan então pergunta:

Mestre...

Eu entendi os ponteiros.

Mas onde eles realmente são usados?

O mestre aponta para um gigantesco IBM z17.

E responde.

Em praticamente todos os lugares importantes.


O grande segredo

Poucos desenvolvedores percebem.

Mas produtos IBM utilizam ponteiros intensivamente.

Exemplos.

CICS

DB2

MQ

LE

z/OS

TCP/IP

JES2

JES3

RACF

SMF

VSAM

IMS

Todos.


O COBOL moderno

COBOL não vive sozinho.

Ele conversa.

Com:

C

Metal C

Assembler

Java

MQ

JSON

REST

Sockets


E o idioma dessa conversa é.

Ponteiros.


COBOL e C

Talvez seja o casamento mais comum.


C

Produz buffer.


COBOL

Consome.


Arquitetura.

C


↓

malloc()


↓

PTR



↓

COBOL


BASED

Exemplo conceitual

Programa C.

malloc(1024);

Retorna.

Endereço.


COBOL.

01 WS-PTR POINTER.

Recebe.


Associa.

SET ADDRESS OF BUFFER

TO WS-PTR

Pronto.


COBOL agora enxerga.

Memória criada em C.


Metal C

Mais interessante.


Executa próximo do hardware.


Pode usar.

64 bits.

Storage Keys.


Compartilhar.

Buffers.


Muito utilizado.

Middleware.


Shared Memory

Outro uso avançado.


Vários programas.

Mesmo buffer.


Visualmente.

Programa A


↓

Shared Buffer


↑


Programa B

Sem cópia.


Muito rápido.


MQ

Excelente exemplo.


MQGET

MQPUT


Mensagem.


Buffer.


COBOL.

Ponteiro.


Estrutura BASED.


Visualmente.

MQ


↓

Buffer


↓

PTR


↓

BASED

Processamento.

Zero cópia.


JSON

Muito utilizado hoje.


Imagine.

{
"name":"Bellacosa",

"idade":52
}

Parser.

Cria árvore.


Cada nó.

Possui ponteiros.


Pai.

Filho.

Irmão.


Exemplo.

JSON ROOT


↓


name


↓


idade

XML

Mesma ideia.


DOM.


Tree.


Ponteiros ligam.

Nós.


APIs

z/OS Connect.


Buffers.


Payload.


Parser.


Muito comum.


Sockets

TCP/IP.


Recebe.

4096 bytes.


Ponteiro.


COBOL lê.


Mais eficiente.


Cache

Outro caso.


Tabela gigante.


Ponteiro.

Evita copiar.


Exemplo.

100 MB.


Mover.

Custa.


Apontar.

8 bytes.


Quase instantâneo.


Tabelas in-memory

Excelente.


DB local.


Lookup rápido.


Hash.


B-tree.


Implementável.


Estruturas avançadas

Lista Duplamente Encadeada

NODE


PREV


NEXT

Árvore AVL


Balanceada.


Ponteiros.


B-tree

Muito utilizada.

Banco dados.


Grafo

Exemplo.

A


/ \


B  C


\ /


D

Tudo possível.


Comparação com outras linguagens

LinguagemPonteiros
COBOLSim
CSim
C++Sim
RustControlado
JavaReferências
GoSim
PythonOculto

Curiosidade

Java.

Esconde.


COBOL.

Mostra.


C.

Expõe totalmente.


Rust.

Protege.


Quando usar?

Bellacosa recomenda.


Excelente.

Buffers

MQ

JSON

XML

APIs

Cache

LE

Middleware

Parsers

Estruturas dinâmicas


Quando evitar?

Cadastro.


Folha pagamento.


VSAM simples.


DB2 comum.


Relatórios.


Performance

Muito alta.


Sem MOVE.


Sem COPY.


Sem serialização.


Muito usada.

Em produtos IBM.


Segurança

Ainda importante.


Ponteiro errado.

Continua.

SOC4.


Heap inválido.


Overlay.


Corrompe.


Documentação

Obrigatória.


Desenhe.

Diagramas.


Exemplo.

PTR1


↓

NODE1


↓

NODE2


↓

NODE3

Ajuda manutenção.


Bellacosa Best Practices

Regra 1

Inicialize.

Sempre.

SET PTR TO NULL

Regra 2

Documente.


Regra 3

Libere.


Regra 4

Nunca reutilize.

Após FREE.


Regra 5

BASED bem definido.


Regra 6

Evite engenharia excessiva.


O Teste do Mestre

Pergunta ao Padawan.

Você precisa.

Criar.

Lista encadeada?


Não?


Use OCCURS.


Sim?


Use ponteiros.


Curiosidades Finais

A maioria dos desenvolvedores COBOL jamais precisará escrever uma árvore AVL.

Ou um parser XML próprio.

Ou um cache compartilhado.

Ou uma estrutura dinâmica baseada em CEEGTST.

Mas os profissionais que sabem fazer isso normalmente pertencem a grupos bastante especializados:

  • Sysprogs

  • Middleware Engineers

  • Desenvolvedores CICS

  • Equipes MQ

  • Produtos IBM

  • Desenvolvedores de Frameworks

  • Especialistas em LE

  • Equipes de Modernização IBM Z


O Conselho Final do Mestre Bellacosa

Os ponteiros em COBOL são quase como cristais Kyber escondidos em uma antiga câmara do templo IBM Z.

Durante décadas, muitos desenvolvedores passaram por eles sem percebê-los.

Outros ouviram histórias assustadoras sobre SOC4, overlays e memory leaks e decidiram nunca tocá-los.

E alguns poucos escolheram estudá-los profundamente.

Esses poucos descobriram algo fascinante.

Ponteiros não servem apenas para criar problemas.

Eles são a base invisível que sustenta grande parte das tecnologias modernas do ecossistema IBM Z.

São eles que permitem compartilhar buffers entre linguagens.

São eles que fazem parsers navegarem por documentos JSON gigantescos.

São eles que ajudam produtos IBM a movimentar milhões de mensagens MQ por segundo.

São eles que transformam estruturas estáticas em sistemas vivos, capazes de crescer, adaptar-se e responder dinamicamente às necessidades do negócio.

Mas existe uma última lição.

Talvez a mais importante.

Um ponteiro não possui moral.

Ele não distingue sabedoria de imprudência.

Ele apenas aponta.

E cabe ao desenvolvedor decidir se está usando esse poder para construir um elegante mecanismo de alto desempenho ou para abrir um portal direto para um CEEDUMP de 500 páginas às três horas da manhã de um fechamento bancário.


Fim do Holocron Bellacosa Mainframe

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM ZParte 1 a Parte 4 concluídas.


terça-feira, 7 de maio de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas - Parte II

 

Brellacosa Mainframe e os ponteiros de memoria do Cobol parte II

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas

Quando o Padawan Descobre que Pode Construir Estruturas que Não Existem Até Serem Invocadas

Por Bellacosa Mainframe


"Um registro em WORKING-STORAGE nasce junto com o programa. Um registro BASED espera pacientemente até que alguém lhe conceda um endereço. É quase como invocar um sabre de luz que ainda não possui cristal."

Mestre Sysprog Bellacosa


Introdução

Na Parte 1 aprendemos sobre:

  • USAGE POINTER

  • ADDRESS OF

  • SET

  • Stack

  • Heap

  • AMODE 24/31/64

  • Ponteiros inválidos

  • Dangling pointers

Agora vamos atravessar uma das fronteiras mais desconhecidas do COBOL moderno.

Chegou o momento do Padawan descobrir algo surpreendente.

No COBOL, podemos criar estruturas que não ocupam memória alguma até receberem um endereço válido.

Sim.

Existe praticamente uma espécie de objeto fantasma.

Uma descrição.

Uma planta arquitetônica.

Um molde.

Sem existência física.

Até alguém dizer:

SET ADDRESS OF ALGUMA-COISA

ou

ALLOCATE

E então...

A estrutura ganha vida.


O que é BASED?

BASED é provavelmente uma das palavras menos utilizadas no COBOL corporativo.

Exemplo:

01 WS-CLIENTE BASED.

O compilador entende:

"Existe uma estrutura chamada WS-CLIENTE."

Mas também entende:

"Não reserve memória para ela."


Diferença entre WS tradicional

Working Storage

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.

Ao carregar o programa.

Memória:

1000 WS-NOME

1030 WS-IDADE

Sempre existe.


BASED

01 WS-CLIENTE BASED.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.

Memória:

Nada.

Zero.

Inexistente.


Como BASED funciona?

Pense em um apartamento na planta.

Temos:

Sala

Cozinha

Banheiro

Quarto

Tudo desenhado.

Mas ainda não foi construído.


BASED é exatamente isso.


O papel do ponteiro

Precisamos de alguém para dizer:

Mestre...

O apartamento agora fica naquele endereço.


Exemplo

01 PTR-CLIENTE.

USAGE POINTER.

Associando

SET ADDRESS OF WS-CLIENTE

TO PTR-CLIENTE

Pronto.

WS-CLIENTE agora existe.


Primeiro exemplo completo

Passo 1

Definir ponteiro

01 PTR-CLI POINTER.

Passo 2

Criar estrutura BASED

01 REG-CLIENTE BASED.

   05 CLI-ID.
      PIC 9(5).

   05 CLI-NOME.
      PIC X(30).

   05 CLI-SALDO.
      PIC S9(7)V99.

Passo 3

Criar memória real

01 WS-AREA.

   PIC X(40).

Passo 4

Associar

SET PTR-CLI

TO ADDRESS OF WS-AREA

Passo 5

Ativar

SET ADDRESS OF REG-CLIENTE

TO PTR-CLI

Passo 6

Usar

MOVE 1000

TO CLI-ID


MOVE 'BELLACOSA'

TO CLI-NOME

Resultado.

Funciona.

Mesmo sendo BASED.


O que aconteceu?

Antes

REG-CLIENTE


inexistente

Depois

PTR-CLI


↓

70001000




REG-CLIENTE


usa memória 70001000

ALLOCATE

Agora começa a magia.

Não queremos usar WS.

Queremos memória nova.

Dinâmica.


Exemplo

ALLOCATE REG-CLIENTE

Compilador solicita memória.

Heap.


Visualmente

Antes

HEAP


vazio

Depois

HEAP


7000000


REG-CLIENTE

FREE

Toda magia tem preço.

Precisamos liberar.


Exemplo

FREE REG-CLIENTE

Se esquecer.

Memory leak.


CEEGTST

Muito utilizado.

LE Runtime.


Significa.

Get Storage.


Exemplo conceitual

CALL 'CEEGTST'

LE devolve.

Endereço.


Ponteiro recebe.


Mais sofisticado.

Mais profissional.


CEEFRET

Libera memória.


Equivalente.

malloc()


free()

No mundo C.


Comparação

COBOLC
ALLOCATEmalloc
FREEfree
CEEGTSTmalloc avançado
CEEFRETfree

Criando lista encadeada

Agora o lado Jedi aparece.


Estrutura

01 NODE BASED.


05 DADO.
PIC 9(5).


05 NEXT POINTER.

Visualmente

NODE


DADO


NEXT

Primeiro nó

100


PTR=2000

Segundo

200


PTR=3000

Terceiro

300


NULL

Ligando nós

SET NEXT

TO PTR-NODE2

Pronto.

Lista encadeada.


Navegando

Começamos.

HEAD

Enquanto

PTR <> NULL

Exibe.

Avança.


Exemplo

DISPLAY DADO


SET PTR

TO NEXT

Filas

Também possível.

FIFO.


Cliente 1

Cliente 2

Cliente 3


Pilhas

LIFO.


Push

Pop

Peek


Tudo em COBOL.


Árvores

Mais interessante.


          50


      20      80


   10   30

Estrutura

LEFT POINTER


RIGHT POINTER

Muito elegante.


Tabelas dinâmicas

Outra vantagem.


OCCURS tradicional.

1000 TIMES

Sempre ocupa.


Dinâmica.

Somente o necessário.


XML

Parser.


Nós.

Filhos.

Pai.


Ponteiros ajudam muito.


JSON

Excelente caso.


Objeto.

Array.

Subobjeto.


Estrutura árvore.


Performance

Muito boa.


Sem copiar dados.


Apenas endereço.


Mover.

8 bytes.


Mover.

1 MB.

Muito pior.


Heap

Mais lenta.

Que Working Storage.


Mas muito flexível.


Cuidados

Nunca esquecer FREE


Não usar memória liberada


Inicializar ponteiros

SET PTR TO NULL

Verificar retorno


Documentar


Curiosidade

Pouquíssimos desenvolvedores COBOL já implementaram uma lista encadeada real em produção.

Mas praticamente todos os produtos IBM utilizam estruturas semelhantes internamente.

CICS.

MQ.

DB2.

LE.

z/OS.

Todos.


O Conselho do Mestre Bellacosa

BASED é provavelmente a funcionalidade que mais aproxima COBOL do universo das linguagens de sistemas.

Ela permite abandonar parcialmente o modelo tradicional de registros fixos e entrar em um mundo onde estruturas podem nascer, crescer, conectar-se umas às outras e desaparecer dinamicamente.

Mas o jovem Padawan deve compreender uma verdade fundamental.

Quando utilizamos BASED, ALLOCATE, CEEGTST e ponteiros encadeados, deixamos o confortável universo dos datasets catalogados, dos OCCURS previsíveis e dos registros estáticos.

Passamos a caminhar pelos corredores escuros do Heap do Language Environment.

E nesses corredores existem criaturas perigosas chamadas:

  • Memory Leak

  • Dangling Pointer

  • Heap Corruption

  • S0C4

  • Storage Overlay

  • Abend U4038

O verdadeiro Mestre COBOL não teme essas criaturas.

Ele simplesmente sabe exatamente onde elas vivem.


Continua na Parte 3

O Lado Sombrio dos Ponteiros: SOC4, Memory Leaks, Dumps, IPCS, Fault Analyzer e os Monstros Escondidos no Heap do IBM Z.


segunda-feira, 15 de abril de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Despertar da Força dos Ponteiros - Parte I

 

Bellacosa Mainframe e os ponteiros de memoria no COBOL Parte I

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 1 – O Despertar da Força dos Ponteiros

Quando o Padawan Descobre que um Endereço Pode Ser Mais Poderoso que os Dados

Por Bellacosa Mainframe


"O dado é importante. Mas conhecer onde ele vive na memória é conhecer a própria Força."

Mestre Sysprog Bellacosa


Introdução

Existe um momento na jornada de todo desenvolvedor COBOL em que ele acredita já ter visto praticamente tudo.

Aprendeu arquivos.

Aprendeu VSAM.

Aprendeu DB2.

Aprendeu CICS.

Aprendeu tabelas OCCURS.

Aprendeu REDEFINES.

Aprendeu recursão.

Aprendeu programas aninhados.

Aprendeu até THREADSAFE.

Então um dia aparece um código semelhante a este:

01 PTR-CLIENTE      USAGE POINTER.

SET PTR-CLIENTE TO ADDRESS OF WS-CLIENTE.

O jovem Padawan olha para aquilo e pergunta:

Mestre…

COBOL tem ponteiros?

O mestre sorri.

Toma um gole de café.

E responde:

Sim.

E são provavelmente uma das funcionalidades menos conhecidas, mais poderosas e potencialmente mais perigosas disponíveis no IBM Enterprise COBOL.


O grande mito

Existe um mito muito comum.

"COBOL não trabalha com endereços."

Errado.

COBOL trabalha.

Sempre trabalhou.

Só que de forma extremamente controlada.

Enquanto linguagens como C permitem brincar livremente com memória:

int *p;

COBOL diz:

Jovem Padawan...

Se você vai manipular memória...

Faça isso com respeito.


O que é um ponteiro?

Um ponteiro não é um dado.

Ele não contém um nome.

Ele não contém um CPF.

Ele não contém uma data.

Ele contém:

O endereço onde algo está.

Imagine.

Apartamento:

Rua Jedi 500

Apartamento 1001

O apartamento é o dado.

O endereço é o ponteiro.


Exemplo.

Cliente

Nome

Bellacosa

Está armazenado em:

7FFF012345678

O ponteiro guarda:

7FFF012345678

Nada mais.


Por que isso existe?

Porque às vezes queremos acessar memória dinamicamente.

Criar estruturas.

Buffers.

Caches.

Árvores.

Filas.

Listas.

Comunicar com C.

Trabalhar com APIs.

Manipular XML.

Shared Memory.

LE Runtime.


COBOL sempre teve ponteiros?

Não.

COBOL 60

Não.

COBOL 68

Não.

COBOL 74

Não.


A situação começou a mudar com:

COBOL 85


Mais tarde.

IBM Enterprise COBOL.

Introduziu:

USAGE POINTER

ADDRESS OF

BASED

ALLOCATE

FREE


Atualmente.

Enterprise COBOL

4

5

6

6.3

6.4

6.5

Suportam totalmente.


O que é USAGE POINTER?

É o tipo especial que armazena um endereço.

Exemplo.

01 WS-PTR.

   USAGE POINTER.

ou

01 WS-PTR POINTER.

Não faça:

PIC X(08)

Errado.


Não faça:

PIC 9(18)

Errado.


O compilador conhece o formato.

Você não precisa.


ADDRESS OF

Talvez seja a instrução mais importante.

Exemplo.

Temos.

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).

Pegando endereço.

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Pronto.

Agora.

WS-PTR aponta.

Para WS-CLIENTE.


Visualmente

Antes.

WS-PTR


NULL

Depois.

WS-PTR


0000007FFF123450

Como funciona na memória

Imagine.

Working Storage

ENDEREÇO


1000


WS-NOME


Bellacosa



1030


WS-IDADE


52



1035


WS-PTR

Executamos.

SET PTR

TO ADDRESS OF WS-NOME

Resultado.

PTR


1000

O ponteiro virou.

Uma espécie de GPS.


O que é SET?

SET é o comando utilizado.

Para manipular ponteiros.

Exemplo.

SET PTR

TO ADDRESS OF WS-DADOS

Outro.

SET PTR TO NULL

Muito importante.

Sempre inicializar.


Boa prática.

SET PTR TO NULL

No início.


Primeiro exemplo completo

Passo 1

Criar estrutura

WORKING-STORAGE SECTION.


01 WS-CLIENTE.

   05 WS-NOME.

      PIC X(30).



01 WS-PTR

USAGE POINTER.

Passo 2

Preencher

MOVE 'BELLACOSA'

TO WS-NOME

Passo 3

Capturar endereço

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Passo 4

Display

DISPLAY 'PONTEIRO OK'

Fim.


O que o compilador faz?

Compilador cria.

Variável especial.

Compatível com arquitetura.

31 bits.

64 bits.


Padawan pergunta.

Mestre...

Então é um hexadecimal?

Resposta.

Sim.

Normalmente.


Exemplo.

0000000012345678

IBM Z e endereçamento

Aqui começa a magia.

IBM Z possui longa história.


AMODE 24

Década 70.

Memória.

16 MB.


AMODE 31

1983

2 GB


AMODE 64

zSeries

Exabytes teóricos.


COBOL acompanha.


Working Storage

Ponteiros podem apontar para:

Working Storage


Local Storage


Heap


Dynamically allocated


LE Areas


Buffers


Stack

Existe outra área.

Stack.

Exemplo.

Função chamada.

STACK



Frame A


Frame B


Frame C

Cada frame.

Possui.

Variáveis.

Retorno.

Contexto.


Ponteiros podem apontar.

Para stack.

Sim.


Mas aqui mora perigo.


O lado sombrio

Imagine.

Procedimento.

Termina.

Stack destruída.


Ponteiro ainda existe.


Aponta.

Para memória inválida.


Chamamos isso.

Dangling Pointer.


Exemplo.

PTR


12345

Memória já morreu.


Resultado.

SOC4.


Heap

Heap é diferente.

Sobrevive.

Mais tempo.


Usado em.

ALLOCATE.

CEEGTST.

GETMAIN.


Mais seguro.


Curiosidade

Muitos programas COBOL bancários.

Nunca usam ponteiros.


Por quê?

Não precisam.


COBOL nasceu.

Para registros.

Arquivos.

Campos fixos.


Ponteiros vieram.

Muito depois.


Vantagens

Extremamente rápidas.

Não copia dados.


Exemplo.

Mover.

1 MB.

Custa.

CPU.


Mover ponteiro.

8 bytes.

Instantâneo.


Onde usar?

Excelente para.

XML

JSON

Árvores

Cache

Filas

MQ

Buffers

APIs

Sockets

C

Metal C


Onde NÃO usar?

Cadastro clientes.

Folha pagamento.

Relatórios.

VSAM simples.

Batch convencional.


Performance

Muito boa.

Quase zero overhead.


Mas.

Erro custa caro.


Um MOVE errado.

Perde registro.


Ponteiro errado.

Pode derrubar programa.


SOC4.


Segurança

Ponteiros são ferramenta poderosa.

Mas perigosos.


Podem causar.

Corrupção memória.

Exposição dados.

Abends.

Memory leaks.


Padawan deve lembrar.

Ponteiro não sabe.

Se memória ainda existe.

Ele apenas acredita.


Curiosidades Bellacosa

Pouquíssimos desenvolvedores COBOL escrevem código com ponteiros diariamente.

Mas os profissionais que trabalham com:

  • Language Environment

  • XML parsers

  • CEEGTST

  • Metal C

  • DB2 internals

  • Middleware

  • MQ exits

  • CICS User Exits

  • z/OS Connect

  • Parsers de alta performance

frequentemente encontram USAGE POINTER, ADDRESS OF, BASED e estruturas dinâmicas escondidas em programas aparentemente inocentes.


O Conselho do Mestre Bellacosa

Imagine que os dados COBOL são sabres de luz.

Você pode segurá-los diretamente.

Pode copiá-los.

Pode movê-los.

Pode validá-los.

Mas um ponteiro é diferente.

Um ponteiro é um mapa para encontrar o sabre.

Ele não contém energia.

Ele não contém plasma.

Ele apenas diz:

"Vá até aquele lugar da memória e você encontrará aquilo que procura."

E essa é justamente a beleza e o perigo dos ponteiros em COBOL.

Eles permitem que o Padawan transcenda a programação tradicional baseada em registros fixos e passe a manipular a própria estrutura da memória do IBM Z.

Mas também ensinam uma das maiores lições do universo mainframe:

O dado pode estar protegido por RACF.

O dataset pode estar catalogado.

O programa pode ser RENT e THREADSAFE.

Mas um ponteiro errado continua tendo o poder de levar até mesmo um Mestre Sysprog ao temido S0C4.

Continua na Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas: Construindo Listas Encadeadas no IBM Z.


terça-feira, 26 de março de 2024

COBOL Multithread no Mainframe: O Lado Quântico da Força no IBM Z

Bellacosa Mainframe e o cobol multithread

COBOL Multithread no Mainframe: O Lado Quântico da Força no IBM Z

Quando o Padawan Descobre que um Programa COBOL Pode Executar Várias Trilhas de Execução Simultaneamente

Por Bellacosa Mainframe

"Seu pai conhecia uma técnica chamada multithreading. Era um poderoso aliado do lado luminoso da CPU, antes que o excesso de serialização o consumisse."

Mestre Sysprog Bellacosa


A Pergunta que Todo Padawan COBOL Faz

Após aprender:

  • CALL

  • Nested Programs

  • Recursividade

  • LE

  • RENT

  • THREADSAFE

surge uma dúvida inevitável.

Mestre...

Um programa COBOL pode criar Threads?

A resposta curta é:

Sim.

Mas...

Não da forma que Java, C++ ou Python fazem.

E aqui começa uma das partes mais interessantes da arquitetura IBM Z.


O mito do COBOL Monothread

Durante décadas, COBOL foi praticamente sinônimo de:

Uma tarefa

↓

Um programa

↓

Um fluxo

↓

Fim

Exemplo:

OPEN

PERFORM

READ

UPDATE

WRITE

CLOSE

STOP RUN

Linear.

Sequencial.

Determinístico.


Era suficiente.

Bancos.

Seguros.

Governo.

Folha pagamento.


Mas IBM Z mudou

Hoje temos:

LPARs

SMT

zIIP

SRB

TCB

OpenMP

POSIX

USS

Java

C++

Metal C

E COBOL começou a participar desse universo.


A resposta correta

Pergunta:

COBOL possui

CREATE THREAD

Não.

Não possui.


Pergunta:

COBOL pode executar multithread?

Sim.

Através do ambiente.


Onde isso é possível?

Basicamente.

USS

Unix System Services


LE

Language Environment


POSIX

pthread


CICS THREADSAFE


Java Integration

JNI


Metal C


Quando surgiu?

LE apareceu.

Década 90.

Posix Threads.

zOS UNIX.

Enterprise COBOL V3.

V4.

V5.

V6.


COBOL 6.5

convive perfeitamente.


O conceito

COBOL não cria.

COBOL participa.


Exemplo.

C cria.

COBOL executa.


Arquitetura

Programa Mestre


↓

pthread_create()


↓

Thread A


↓

COBOL


THREAD-CPF




Thread B


↓

COBOL


THREAD-END




Thread C


↓

COBOL


THREAD-PIX

Como funciona na memória

Cada thread possui:

PCB

TCB

Stack

Registers

PSW

LE Context


Exemplo

Thread 1

Stack

64 KB


Thread 2

64 KB


Thread 3

64 KB


Visualmente

MEMÓRIA



THREAD 1


STACK



THREAD 2


STACK



THREAD 3


STACK




HEAP



SHARED

O ponteiro de execução

Aqui está a magia.

Cada thread possui.

Instruction Pointer

PSW

Program Counter


Exemplo

Thread 1

EXECUTANDO


Linha 500

Thread 2

Linha 200

Thread 3

Linha 950

Todos simultaneamente.


CPU troca.

Dispatch.

Redispatch.


O Scheduler

zOS decide.

Não COBOL.


WLM.

Gerencia.

Prioridade.

Classe.

Importância.


Exemplo real

Sistema anti-fraude.


Thread 1

CPF


Thread 2

PIX


Thread 3

Cartão


Thread 4

IA


Programa pai espera.


Como esperar

Join.


Exemplo conceitual

THREAD CREATE


THREAD CREATE


THREAD CREATE



WAIT

COBOL recebe resultado.


Exemplo com C

Programa C

pthread_create();

Chama COBOL

THREADCPF

COBOL

PROGRAM-ID. THREADCPF.

Executa.


Retorna.


Pode fazer COBOL puro?

Praticamente não.


Enterprise COBOL

não possui.

START THREAD

Não existe.


Alternativa elegante

Múltiplas subtarefas

Batch.


Exemplo.

JOB

STEP1


STEP2


STEP3

Executando em paralelo.


JES2.


Muito usado.


Outra alternativa

CICS

THREADSAFE


Exemplo

Programa

THREADSAFE


Múltiplas tasks.


CICS gerencia.


THREADSAFE

Extremamente importante.


Programa comum

QR TCB


THREADSAFE

L8

T8


Múltiplas CPUs.


Maior throughput.


Cuidados

Working Storage

Perigoso.


Thread 1

WS=100


Thread 2

WS=500


Corrupção.


Melhor

LOCAL STORAGE


Exemplo

LOCAL-STORAGE SECTION.

Cada thread

sua cópia.


Reentrância

Obrigatório.


Programa

RENT


ou

REENTRANT

Sem isso.

Desastre.


Locks

Às vezes necessários.


Variável compartilhada.


Thread 1

incrementa


Thread 2

incrementa


Resultado errado.


Exemplo

100

esperado


Recebe

98


Race condition.


Segurança

Ataques possíveis.


Deadlock.


Starvation.


Race.


Stack exhaustion.


DoS.


Exemplo

Thread A

espera B


B espera C


C espera A

Fim.


Parado.


Performance

Depende.


CPU bound

Excelente.


I/O bound

Média.


DB2

Depende.


VSAM

Depende.


Locking.


zIIP

Grande vantagem.


LE

Java

XML

podem usar.


Economia MIPS.


Curiosidade

Maioria dos programas COBOL bancários.

Ainda.

Monothread.


Porque.

São rápidos.

Determinísticos.

Confiáveis.


Exemplo Arquitetura Moderna

MASTER


│


├── Thread CPF


├── Thread PIX


├── Thread AML


├── Thread IA


└── Thread LOG

Master acompanha.


Tabela.

THREAD-ID


STATUS


RC

Exemplo

001


RUNNING


002


ENDED


003


WAIT

Master coleta.


Merge.


Retorna.


Pode valer a pena?

Sim.

Análise fraude.

OCR.

JSON.

IA.

APIs.

Criptografia.

Scoring.


Não.

Leitura sequencial.

Sort.

Folha pagamento.

Batch tradicional.


O conselho do Mestre Bellacosa

Multithreading em COBOL no IBM Z é quase como pilotar um caça estelar experimental escondido em um hangar do datacenter. O motor existe, a tecnologia é impressionante, mas ela não foi colocada diretamente no painel de instrumentos do programador COBOL.

O COBOL clássico continua sendo uma linguagem essencialmente sequencial. Entretanto, quando combinado com Language Environment, POSIX Threads, USS, CICS THREADSAFE, Java ou Metal C, ele passa a habitar um universo onde dezenas de trilhas de execução podem coexistir dentro do mesmo endereço de memória, cada uma com seu próprio stack, contexto LE, PSW e ponteiro de instrução.

O verdadeiro Padawan precisa entender uma lição importante:

O programa COBOL não é o Mestre dos Threads.

Ele é um guerreiro altamente especializado convocado para executar missões dentro de um ecossistema que o IBM Z já domina há décadas.

E talvez essa seja a maior beleza do mainframe moderno: ele consegue executar milhões de transações por segundo, milhares de tarefas concorrentes e dezenas de linguagens diferentes, enquanto um antigo programa COBOL escrito há trinta anos continua processando registros tranquilamente, como um velho Mestre Jedi que já viu muitas gerações de processadores nascerem e desaparecerem na galáxia IBM Z.


segunda-feira, 22 de janeiro de 2024

COBOL Recursivo: Quando o Padawan Descobre que um Programa Pode Invocar a Si Mesmo

 

Bellacosa Mainframe apresenta um programa cobol recursivo

COBOL Recursivo: Quando o Padawan Descobre que um Programa Pode Invocar a Si Mesmo

O Poder Proibido do CALL Infinito na Galáxia IBM Z

Por Bellacosa Mainframe

"O medo leva ao ABEND. O ABEND leva ao dump. O dump leva ao sofrimento."

— Mestre Sysprog Yoda/390

Durante muitos anos, programadores COBOL cresceram acreditando em uma verdade absoluta:

"Programa COBOL não faz recursão."

Era praticamente um dogma do templo Jedi dos mainframes.

E, honestamente?

Durante décadas isso foi quase verdade.

A maioria dos sistemas bancários, seguradoras, governo e processamento batch nunca precisou de algoritmos recursivos.

Mas então surgiram:

  • XML

  • JSON

  • árvores hierárquicas

  • parsers

  • estruturas dinâmicas

  • APIs modernas

  • integração com Java

  • serviços z/OS Connect

E um dia o jovem Padawan perguntou:

"Mestre Bellacosa...

Posso fazer um programa COBOL chamar ele mesmo?"

A resposta é:

Sim.

Mas como todo poder da Força, existe um preço.


O que é Recursividade?

Recursão significa:

Um procedimento invoca ele próprio.

Exemplo clássico:

Calcular fatorial.

5! = 5 × 4 × 3 × 2 × 1

Matematicamente:

Fatorial(n)

se n=1 retorna 1

senão

n * Fatorial(n-1)

Exemplo:

F(5)

5 × F(4)

5 × 4 × F(3)

5 × 4 × 3 × F(2)

5 × 4 × 3 × 2 × F(1)

120

É uma técnica extremamente elegante.


COBOL Sempre Teve Recursão?

Não.

Historicamente COBOL nasceu em 1959.

E sua filosofia era:

Processamento comercial.

Arquivos.

Registros.

Batch.

Volumes enormes.

Não havia necessidade prática.

Durante décadas COBOL assumia:

Programa residente

Uma única Working Storage

Compartilhada

Exemplo:

WORKING-STORAGE SECTION.

01 CONTADOR PIC 9(5).

Só existe uma instância.

Todo mundo usa a mesma.

Problema:

Programa chama ele mesmo.

Segunda chamada sobrescreve variáveis.

Primeira execução quebra.

Caos.


Quando Surgiu?

IBM Enterprise COBOL começou suportar adequadamente recursão através da opção:

RECURSIVE

ou

RENT

Dependendo da geração do compilador.

Hoje encontramos suporte em:

Enterprise COBOL 4

Enterprise COBOL 5

Enterprise COBOL 6.x

COBOL 6.3

COBOL 6.4

COBOL 6.5

Totalmente suportado.

Inclusive no IBM z17.


Como Declarar um Programa Recursivo

No cabeçalho:

IDENTIFICATION DIVISION.
PROGRAM-ID. FATORIAL RECURSIVE.

ou

PROGRAM-ID. FATORIAL.

RECURSIVE.

Depende do compilador.


Exemplo Completo

Passo 1

Definir LINKAGE

LINKAGE SECTION.


01 LK-NUMERO.
   PIC 9(4).

01 LK-RESULTADO.
   PIC 9(10).

Passo 2

Procedure Division

PROCEDURE DIVISION USING
          LK-NUMERO
          LK-RESULTADO.

Passo 3

Caso base

IF LK-NUMERO <= 1

   MOVE 1 TO LK-RESULTADO

ELSE

...

Passo 4

Criar variável local

LOCAL-STORAGE SECTION.


01 WS-TEMP.
   PIC 9(10).

01 WS-N.
   PIC 9(4).

Local Storage é fundamental.

Já veremos por quê.


Passo 5

Preparar próxima chamada

COMPUTE WS-N = LK-NUMERO -1

Passo 6

Invocar a si mesmo

CALL 'FATORIAL'

USING

WS-N
WS-TEMP

Passo 7

Calcular

COMPUTE LK-RESULTADO =
        LK-NUMERO * WS-TEMP

Fim.


Programa Completo

IDENTIFICATION DIVISION.
PROGRAM-ID. FATORIAL RECURSIVE.

DATA DIVISION.


LOCAL-STORAGE SECTION.


01 WS-N.
   PIC 9(4).

01 WS-TEMP.
   PIC 9(10).


LINKAGE SECTION.


01 LK-NUMERO.
   PIC 9(4).

01 LK-RESULTADO.
   PIC 9(10).


PROCEDURE DIVISION USING
        LK-NUMERO
        LK-RESULTADO.


IF LK-NUMERO <= 1

   MOVE 1 TO LK-RESULTADO

ELSE

   COMPUTE WS-N =
           LK-NUMERO -1


   CALL 'FATORIAL'

   USING

      WS-N
      WS-TEMP


   COMPUTE LK-RESULTADO =
           LK-NUMERO * WS-TEMP

END-IF.


GOBACK.

O que Acontece na Memória?

Aqui mora a magia.

Imagine:

FATORIAL(5)

Stack:

Frame 1
n=5

Chama:

Frame 2
n=4

Depois:

Frame 3
n=3

Depois:

Frame 4
n=2

Depois:

Frame 5
n=1

Retorno:

Frame 5 → 1

Frame 4 → 2

Frame 3 → 6

Frame 2 →24

Frame 1 →120


Visualmente

STACK



F(5)

F(4)

F(3)

F(2)

F(1)

Depois:

POP


F(1)


F(2)


F(3)


F(4)


F(5)

O Papel da LOCAL-STORAGE

Muitos Padawans cometem um erro fatal.

Usar:

WORKING-STORAGE

Exemplo:

01 WS-N.

Errado.

Por quê?

Porque Working Storage é única.

Compartilhada.

Exemplo:

Primeira chamada

WS-N=5

Segunda

WS-N=4

Terceira

WS-N=3

Sobrescreve.

Tudo quebra.


LOCAL-STORAGE

Cria uma cópia nova.

Para cada chamada.

Exemplo:

Frame 1

WS-N=5

Frame 2

WS-N=4

Frame 3

WS-N=3

Independentes.


Como o Compilador Faz Isso?

Ele cria activation records.

Também chamados:

Stack frames

Contém:

Variáveis locais

Endereço retorno

Parâmetros

Estado execução

Exatamente igual:

C

C++

Java

Pascal


CALL Estático

Mais eficiente.

CALL 'FATORIAL'

Resolvido no linkedit.

Menos overhead.


CALL Dinâmico

MOVE 'FATORIAL'

TO WS-PGM


CALL WS-PGM

Mais flexível.

Menos rápido.


Existe Limite?

Sim.

STACK.

Região LE.

Memory limits.

Exemplo:

F(1000000)

Boom.

SOC1

SOC4

S878

S80A

Dependendo ambiente.


Como Evitar?

Caso base.

Sempre.

Sempre.

Sempre.

Exemplo ruim:

CALL FATORIAL


CALL FATORIAL


CALL FATORIAL

Nunca termina.


Cuidados Importantes

1 Não usar Working Storage

Errado.


2 Ter condição parada

Obrigatório.


3 Validar entrada

Exemplo:

IF NUMERO < 0

Fatorial negativo?

Não faz sentido.


4 Cuidado com profundidade

100 níveis

Ok.

500

Talvez.

10000

Perigoso.


5 Testar LE Runtime

HEAP

STACK

ALL31

Importante.


Performance

Aqui muitos ficam decepcionados.

Recursão é elegante.

Mas nem sempre rápida.

Cada chamada cria:

Frame

Parâmetros

Contexto

Retorno

Overhead.


Loop tradicional:

PERFORM


UNTIL

Quase sempre vence.


Exemplo

Fatorial iterativo.

MOVE 1 TO WS-TOTAL


PERFORM VARYING I


FROM 1


BY 1


UNTIL I > N


MULTIPLY I


BY WS-TOTAL


END-PERFORM

Muito eficiente.


Quando Vale a Pena?

Árvores.

XML.

JSON.

DOM.

Grafos.

Estruturas hierárquicas.

Menus.

Organogramas.

Filesystem.

Dependências.


Exemplo XML

empresa


 departamento


   funcionario


 departamento


   funcionario

Percorrer árvore.

Recursão fica linda.


Segurança

Sim.

Existe aspecto de segurança.

Ataque:

Stack exhaustion.

Negação de serviço.

DoS.

Programa recebe:

99999999

Explode stack.


Proteção:

IF NIVEL > 1000

DISPLAY "ERRO"

STOP RUN

Debug

Debug recursivo é divertido.

E assustador.

Ferramentas:

IBM Debug Tool

Fault Analyzer

Abend Aid

Mostram:

Call Stack

Frame atual

Parâmetros

Muito útil.


Curiosidades

Poucos sistemas bancários usam recursão pesada.

COBOL nasceu para processamento sequencial.

Por isso muitos programadores veteranos passam décadas sem escrever uma única rotina recursiva.


Outra curiosidade:

COBOL OO suporta métodos recursivos naturalmente.

INVOKE SELF

Também funciona.


Recursão de Cauda (Tail Recursion)

Alguns compiladores modernos fazem otimizações.

Mas COBOL IBM geralmente não realiza Tail Call Optimization de forma agressiva como linguagens funcionais.

Logo:

RETURN F(N-1)

Ainda pode consumir stack.

Não confie nisso.


Padrão Recomendado pelo Mestre Bellacosa

Para o jovem Padawan COBOL, eu costumo ensinar uma regra bastante prática:

Use recursão apenas quando ela deixar a solução mais clara do que um PERFORM VARYING.

Se a lógica for:

  • Fatorial

  • Somatório

  • Contador

Prefira iteração.

Se a lógica envolver:

  • Árvores

  • XML

  • JSON aninhado

  • Catálogos IMS

  • Dependências complexas

  • Estruturas organizacionais

  • Menus multiníveis

Então a recursividade torna-se uma excelente aliada.


Exemplo pratico de recursividade

Veja uma algoritmo em arvore B (B-Tree) search

https://eljefemidnightlunch.blogspot.com/2023/10/cobol-recursivo-sem-misterios.html


Considerações Finais

A recursão em COBOL é quase como encontrar um antigo holocron escondido nos corredores de um datacenter IBM Z.

Muitos veteranos nunca precisaram utilizá-la. Outros a evitam por receio de consumir stack, degradar performance ou provocar abends difíceis de diagnosticar.

No entanto, compreender programas recursivos amplia significativamente o repertório técnico de um desenvolvedor COBOL moderno. Em um mundo onde o mainframe conversa diariamente com APIs REST, processa documentos JSON complexos, integra-se com microsserviços e participa de arquiteturas híbridas, dominar recursividade deixa de ser apenas curiosidade acadêmica e passa a ser uma habilidade estratégica.

O verdadeiro Padawan não utiliza recursão para demonstrar inteligência. Ele a utiliza porque compreende profundamente o problema, conhece os limites da memória, respeita a pilha de execução do Language Environment, escolhe LOCAL-STORAGE sabiamente e sabe exatamente quando um simples PERFORM VARYING é a solução mais elegante.

E essa talvez seja a maior lição do COBOL recursivo:

Nem todo poder disponível deve ser usado. Mas todo poder disponível deve ser compreendido.

No templo Bellacosa Mainframe, conhecer a recursividade significa possuir mais uma ferramenta no cinto utilitário do Sysprog Jedi, pronta para ser acionada quando a missão exigir atravessar estruturas tão profundas quanto os corredores infinitos de uma galáxia IBM Z em plena era do z17.


quarta-feira, 24 de maio de 2023

☕Os Holocrons Esquecidos do Tratamento de Erros no IBM Z - EXCEPTION/ERROR Procedures em COBOL:

 

Bellacosa Mainframe e o tratamento de erro em cobol

☕ EXCEPTION/ERROR Procedures em COBOL: Os Holocrons Esquecidos do Tratamento de Erros no IBM Z

Quando o Padawan Descobre que Tratar Erros é Muito Mais Importante do que Apenas Verificar FILE STATUS

Por muitos anos, grande parte dos desenvolvedores COBOL aprendeu que tratar erros significava simplesmente verificar um FILE STATUS, utilizar um AT END, um INVALID KEY ou, em situações mais modernas, um ON EXCEPTION.

E, para muitos sistemas, isso realmente é suficiente.

Mas o IBM Z esconde mecanismos muito mais sofisticados.

Pouco conhecidos.

Pouco documentados.

E frequentemente esquecidos pelas novas gerações de desenvolvedores.

O Enterprise COBOL possui recursos capazes de interceptar falhas automaticamente, centralizar tratamentos, construir frameworks corporativos de recuperação, conversar com o Language Environment, produzir observabilidade moderna e até integrar eventos de erro com plataformas como MQ, OpenTelemetry, Splunk, Elastic e Grafana.

Foi justamente para explorar esse lado quase arqueológico do COBOL que nasceu a série:

📚 EXCEPTION/ERROR Procedures em COBOL

Os Holocrons Esquecidos do Tratamento de Erros no IBM Z

Uma jornada em quatro capítulos, destinada aos jovens Padawans, arquitetos IBM Z, desenvolvedores seniores e curiosos que desejam compreender como os grandes ambientes corporativos realmente lidam com falhas.


📖 Capítulo 1

O Despertar das DECLARATIVES

Quando o Padawan Descobre que COBOL Possui Seu Próprio Mecanismo Jedi de Tratamento de Erros

Neste primeiro holocron, exploramos um dos recursos mais antigos e menos utilizados do COBOL.

Você aprenderá:

  • O que são DECLARATIVES

  • USE AFTER ERROR PROCEDURE

  • História desde ANSI-74 e ANSI-85

  • Como o runtime COBOL transfere o controle para rotinas especiais

  • Comparação entre FILE STATUS e DECLARATIVES

  • Fluxo interno de execução

  • Estruturas de memória

  • Primeiro programa passo a passo

  • Dicas, cuidados e boas práticas Bellacosa

🔗 https://eljefemidnightlunch.blogspot.com/2023/01/exceptionerror-procedures-em-cobol-os.html


📖 Capítulo 2

O Padawan Aprende a Domar os Abends do Dataset

VSAM, FILE STATUS 35/39/92/93, Retry, Logging e Frameworks Corporativos de Recuperação

Todo desenvolvedor IBM Z já encontrou um misterioso FILE STATUS 35 às duas da manhã.

Neste capítulo estudamos:

  • FILE STATUS detalhado

  • Erros 35, 39, 90, 92 e 93

  • VSAM KSDS, ESDS e RRDS

  • Retry inteligente

  • Logging corporativo

  • Estratégias de recuperação

  • Auditoria

  • Framework Bellacosa de tratamento de falhas

  • Observabilidade para ambientes batch

🔗 https://eljefemidnightlunch.blogspot.com/2023/02/os-holocrons-esquecidos-do-tratamento.html


📖 Capítulo 3

O Lado Sombrio das Exceções

LE, CICS HANDLE CONDITION, ON EXCEPTION, CEEHDLR, Dumps, Fault Analyzer, IPCS e os Monstros do S0C4

Chegamos ao território dos Sysprogs Jedi.

Aqui exploramos:

  • Language Environment (LE)

  • Condition Handling

  • CEEHDLR

  • CEESGL

  • HANDLE CONDITION

  • HANDLE ABEND

  • SOC4

  • SOC7

  • S0CB

  • CEEDUMP

  • Fault Analyzer

  • IPCS

  • Como o runtime trata exceções

  • Estruturas de memória

  • Segurança

  • Performance

Se você sempre quis entender o que acontece quando um programa decide produzir um dump de centenas de páginas, este é o capítulo ideal.

🔗 https://eljefemidnightlunch.blogspot.com/2023/03/os-holocrons-esquecidos-do-tratamento.html


📖 Capítulo 4

O Mestre Bellacosa

Frameworks Corporativos de Tratamento de Erros, MQ Dead Letter Queue, APIs JSON, OpenTelemetry, Splunk e a Arte Jedi de Transformar Falhas em Conhecimento

O último holocron leva o tratamento de erros para um novo patamar.

Abordamos:

  • Logger corporativo

  • Correlation ID

  • MQ Dead Letter Queue

  • APIs JSON

  • OpenTelemetry

  • Splunk

  • Elastic/OpenSearch

  • Grafana

  • SRE

  • Observabilidade

  • Compliance

  • LGPD

  • IA aplicada à análise de falhas

  • Framework Bellacosa para Engenharia de Confiabilidade

O objetivo deixa de ser apenas tratar erros.

Passa a ser transformar erros em métricas, conhecimento e melhoria contínua.

🔗 https://eljefemidnightlunch.blogspot.com/2023/04/os-holocrons-esquecidos-do-tratamento.html


☕ O Conselho Final do Mestre Bellacosa

O jovem Padawan aprende rapidamente a testar:

IF WS-FS NOT = '00'

O Cavaleiro domina DECLARATIVES, HANDLE CONDITION e Fault Analyzer.

Mas o Mestre Bellacosa compreende algo ainda mais importante.

Erros nunca desaparecerão.

Datasets continuarão desaparecendo.

Locks continuarão acontecendo.

JSON continuará chegando corrompido.

Ponteiros continuarão apontando para lugares proibidos.

E algum programa inevitavelmente produzirá um SOC4 em plena sexta-feira às 23h58.

O diferencial não está em escrever sistemas que nunca falham.

Está em construir sistemas capazes de observar, compreender, registrar, correlacionar, aprender e evoluir a partir das falhas.

Porque, no fim das contas, talvez a maior lição destes Holocrons seja bastante simples:

Um bom programa COBOL processa milhões de registros.

Um grande programa COBOL continua elegante, auditável e resiliente mesmo quando a galáxia inteira dos datasets decide entrar em caos.

Boa leitura, jovem Padawan. Que o FILE STATUS seja sempre 00, e que seus CEEDUMPs sejam curtos, raros e perfeitamente documentados. ☕🚀💙🖥️

Atenção aos errros em Cobol


☕ Não se esqueça Padawan COBOL

Um Padawan COBOL não erra menos porque memorizou toda a sintaxe da linguagem. Ele erra menos porque desenvolveu disciplina técnica. A primeira regra é simples: nunca confie apenas na memória. Consulte manuais, padrões internos e documentação IBM sempre que houver dúvida.

Escreva programas pequenos, modulares e legíveis. Utilize copybooks padronizados, nomenclatura consistente e comentários que expliquem decisões de negócio, não o óbvio. Sempre valide retornos de chamadas, FILE STATUS, SQLCODE, RESP/RESP2, RCs e condições excepcionais. Trate erros como parte natural do projeto, não como um detalhe para o fim do desenvolvimento.

Pratique testes unitários utilizando zUnit, automatize builds com DBB (Dependency Based Build), integre pipelines Git, Jenkins, GitHub Actions ou Azure DevOps, e utilize análise estática de código sempre que possível. Aproveite recursos modernos do Enterprise COBOL, como JSON PARSE, JSON GENERATE, LOCAL-STORAGE, DECLARATIVES, compilação com opções de diagnóstico aprimoradas e ferramentas como Fault Analyzer, Debug Tool e Application Delivery Foundation for z/OS.

Revisão de pares, programação a quatro mãos ajudam sempre a ter um codigo melhor e evitar erros de simpatia, nao tente inventar a roda, use o que existe e é homologado na sua instalação, consulte o enxoval para saber as regras e diretrizes do seu projeto.

Aprenda a ler dumps, estudar SMF, compreender o Language Environment e observar métricas de desempenho. Revise código de colegas e aceite revisões no seu próprio código. A humildade técnica é uma das maiores virtudes de um Mestre.

O jovem Padawan escreve programas que funcionam. O Mestre Bellacosa escreve programas que continuam funcionando quando a galáxia inteira resolve apresentar FILE STATUS diferente de 00. ☕🚀💙🖥️


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...