☕ 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 BASED. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta BASED. Mostrar todas as mensagens

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, 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.


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...