✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Salve jovem padawan, prosseguindo em nossa jornada de descobrimento e compartilhamento de conhecimento, hoje escreverei sobre um tema dificil, tentarei ser claro e ajudar com exemplos fáceis de entender.
Em minhas aulas percebo que os alunos ficam confusos por ser um tema muito abstrato, porém de máxima importância para um desenvolvedor Mainframe, a questão da memória, lembrando que um Z17 tem 16 exabytes de endereço de memória disponível.
Ao codificar, devemos dominar o espaço, ser econômicos em seu uso e dar o máximo de performance para um programa, por isso entender o conceito ajudará bastante.
✅ O que é Address Space?
UmAddress Spaceé umambiente isolado de execuçãofornecido pelo z/OS para que um job, um programa ou uma tarefa rode com sua própria memória e recursos protegidos. Pense nele como um "container" de memória virtual onde o seu programa COBOL roda. Esse cointainer será alocado no DATA DIVISION do Cobol e o programa ao ser enviado para o processamento na CPU, reservará esse espaço para usar durante todo o processo.
🧠 Por que isso é importante para COBOL?
Quando você submete umjob COBOL batch, ou inicia um programa viaCICS, o sistema cria umaddress spacepara:
Carregar os programas COBOL compilados (load modules).
Alocar memória para as variáveis.
Abrir arquivos (datasets, VSAM, etc.).
Comunicar com o CICS, DB2 ou IMS.
Controlar segurança, permissões e acesso via RACF.
Garantir que um job não interfira em outro (isolamento de execução).
Esse espaço estará isolado de outras aplicações e protegido contra interferências durante todo o processamento dos dados, porém devemos criá-lo com cuidado. Afinal muitas outras aplicações criarão os delas, esse espaço tende a ser continuo e para seu uso mais racional, o endereçamento renumera em tempo de execução para 1 até o ultimo byte reservado.
📌 Tipos de Address Space comuns no ambiente z/OS:
Bellacosa Mainframe e os tipos de address space em mainframe
Tipo de EspaçoDescriçãoJob Address SpaceCriado quando um JCL é submetido. Executa seu programa COBOL.TSO Address SpaceQuando um usuário entra via TSO (ISPF), um espaço é criado.CICS RegionCICS cria um espaço para executar programas COBOLonline.STC(Started Task)Tasks como SDSF, VTAM ou WebSphere são address spaces.
🛠️ Dica prática para COBOListas
Se você estiver enfrentando erros de memória, comoabend S0C4, S0C1, S80A, saiba que o problema pode estar relacionado à forma como o seu programa está usando (ou ultrapassando) os limites do Address Space.
Sempre recomendo o uso dos Bug traps do COBOL, nunca deixe de validar returns codes, sql codes e validar os valores resultantes. Evitando abends descontralados em tempo de execução.
💡 Curiosidade Bellacosa Mainframe:
Cada address space tem sua própriaárea de memória protegida, mas todos compartilham o mesmo sistema de I/O, JES e catálogo. O z/OS garante que um job de um programador "distraído" não corrompa o ambiente do colega — um isolamento que já existiadécadas antes dos containers Docker!
💡 Conclusão
Esse artigo teve como objetivo fornecer os primeiros passos para o futuro Mainframer, mas para obter maiores conhecimentos recomendo visitar o site daIBM, ler os manuais e participar da comunidade para evoluir sempre.
Espero ter ajudado e contem comigo para mais artigos, participe de nossa comunidade.
Bellacosa Mainframe e as tabelas internas no COBOL occurs e arrays
☕💥 Arrays em COBOL: O Poder Oculto do OCCURS, SSRANGE e a Guerra Contra a Invasão de Memória
Ou como evitar transformar seu Address Space em um filme de terror para Sysprogs
Introdução
Existe um momento na vida de todo desenvolvedor COBOL júnior em que ele descobre duas verdades universais:
A primeira é que OCCURS parece simples até deixar de ser simples.
A segunda é que existe uma entidade maligna chamada:
SSRANGE
capaz de transformar uma manhã tranquila em uma reunião emergencial envolvendo desenvolvimento, suporte, infraestrutura, DBA, operador e um sysprog segurando uma caneca de café já fria.
E tudo isso por causa de um pequeno detalhe:
MOVE WS-NOME(9999)
quando a tabela possui apenas:
OCCURS 100 TIMES.
Bem-vindo ao fascinante mundo das tabelas COBOL.
Capítulo 1 – O que é OCCURS?
OCCURS é o mecanismo utilizado pelo COBOL para criar estruturas repetitivas.
SET IDX TO 1
PERFORM UNTIL IDX > MAX
PROCESSA
SET IDX UP BY 1
END-PERFORM
Decrescente
SET IDX TO MAX
PERFORM UNTIL IDX = 0
PROCESSA
SET IDX DOWN BY 1
END-PERFORM
Muito usado em:
Compressão
Ordenação
Rollback
Capítulo 8 — SEARCH
Busca sequencial.
SEARCH CLIENTE
AT END
DISPLAY "NAO ACHOU"
WHEN ID = WS-ID
DISPLAY NOME
END-SEARCH
Complexidade
O(n)
100 mil registros.
50 mil leituras médias.
SEARCH ALL
Arma secreta.
Busca binária.
Tabela obrigatoriamente ordenada.
SEARCH ALL CLIENTE
WHEN ID(IDX)=WS-ID
DISPLAY "ACHOU"
END-SEARCH
Complexidade
O(log n)
1000000 itens.
Comparações:
~20
Magia matemática.
Capítulo 9 — OCCURS DEPENDING ON
Tabela variável.
05 QTDE PIC 9(4).
05 CLIENTE OCCURS 1 TO 1000 TIMES
DEPENDING ON QTDE.
Muito usado em:
MQ
Copybooks
APIs
Arquivos
Capítulo 10 — Bidimensional
Exemplo.
Agência x Dia
05 MOVIMENTO.
10 AG OCCURS 100.
15 DIA OCCURS 31.
20 TOTAL PIC 9(10).
Uso:
TOTAL(10,15)
Agência 10.
Dia 15.
Tridimensional
ANO
MES
DIA
VENDAS(2026,6,23)
N dimensões
Teoricamente ilimitado.
Exemplo.
Banco.
País
Estado
Agência
Conta
Produto
Dia
Capítulo 11 — Ordenação
Tabela ordenada.
ASCENDING KEY
Muito útil para:
SEARCH ALL
Caches
Lookup
Capítulo 12 – Quando usar tabela
Excelente:
Parâmetros
Cache
Código UF
Tabela IR
CEP
Conversões
Ruim:
Milhões registros.
Melhor:
DB2
VSAM
IMS
Capítulo 13 – Performance
SEARCH
O(n)
SEARCH ALL
O(log n)
Index
Muito rápido
Subscript
Mais lento
SSRANGE
Seguro
NOSSRANGE
Rápido
Easter Egg COBOL
Existe uma lenda entre veteranos de mainframe.
Diz-se que em algum datacenter esquecido dos anos 80 existe um programa COBOL compilado com:
NOSSRANGE
OPT(2)
FASTSRT
ARITH(EXTEND)
executando desde 1987.
Ninguém sabe exatamente o que ele faz.
Ninguém possui o código-fonte.
Ninguém ousa recompilar.
Mas toda madrugada, às 02h17, ele produz um relatório financeiro perfeito, movimenta bilhões de dólares e desaparece novamente nas profundezas do JES2.
Os sysprogs apenas observam o spool, tomam um gole de café e repetem o antigo mantra do reino z/OS:
"Se está funcionando há 39 anos, não toque."
Conclusão
OCCURS é muito mais do que um simples array.
É uma das construções mais antigas, elegantes e eficientes já criadas para processamento em lote de grande volume.
Dominar:
OCCURS
INDEXED BY
SET
SEARCH
SEARCH ALL
SSRANGE
OCCURS DEPENDING ON
Tabelas multidimensionais
Navegação UP e DOWN
Layout de memória
Address Space do z/OS
é um dos marcos que separam o Padawan COBOL do Cavaleiro do Batch Jedi Council.
Porque no universo do Mainframe existe uma verdade absoluta:
"DB2 pode falhar, CICS pode reciclar, VSAM pode corromper, mas um OCCURS acessado fora dos limites sempre encontrará uma maneira criativa de arruinar o dia de alguém."
Bellacosa Mainframe apresenta o ibm mainframe parte vi
☕ Um Café no Bellacosa Mainframe
Capítulo VI — O Grande Maestro Invisível
O Supervisor do z/OS: Quem Realmente Comanda a Nave?
TERCEIRA REGRA DAS GRANDES CIVILIZAÇÕES
Se você entrar na ponte de comando de uma gigantesca nave espacial e encontrar todos gritando ao mesmo tempo...
...corra.
Porque alguém perdeu o controle.
Agora imagine uma nave com:
cinco milhões de passageiros;
centenas de milhares de robôs;
milhares de laboratórios;
dezenas de hangares;
milhões de mensagens por segundo.
Mesmo assim...
Tudo funciona em perfeita ordem.
Quem organiza tudo isso?
Um personagem quase invisível.
Ele nunca aparece nas propagandas.
Nunca recebe prêmios.
Nunca é lembrado quando tudo funciona.
Mas basta ele falhar...
...e toda a galáxia entra em pânico.
Seu nome é:
Supervisor.
Bem-vindo ao cérebro do z/OS.
O Mito do Sistema Operacional
Quando um Padawan COBOL ouve falar em sistema operacional, normalmente imagina algo parecido com Windows.
Uma área de trabalho.
Ícones.
Mouse.
Papel de parede.
Lixeira.
O z/OS sorri discretamente.
Porque ele nunca foi criado para ser bonito.
Foi criado para manter bancos funcionando às três horas da manhã.
Enquanto você dorme.
Imagine uma Cidade Planetária
Esqueça computadores.
Imagine uma cidade que nunca dorme.
Ela possui:
hospitais;
aeroportos;
metrôs;
usinas;
polícia;
bombeiros;
telecomunicações;
bancos;
universidades.
Milhões de pessoas vivem ali.
Todas querem atenção.
Ao mesmo tempo.
Se não existir alguém coordenando tudo...
o caos será inevitável.
Esse coordenador é o Supervisor.
O Maestro Invisível
Imagine uma orquestra com:
200 mil músicos.
Cada um toca um instrumento diferente.
Violinos.
Pianos.
Metais.
Percussão.
Corais.
Agora imagine que ninguém pode parar.
Nunca.
Quem garante que todos toquem em perfeita sincronia?
O maestro.
O Supervisor do z/OS exerce exatamente esse papel.
Segundo Wilhelm G. Spruth, o Supervisor controla os recursos fundamentais do sistema, administra interrupções, coordena a execução dos programas e fornece os serviços básicos necessários para todo o restante do sistema operacional funcionar.
O Primeiro Ser a Despertar
Quando um IBM Z inicia...
quem acorda primeiro?
Não é o COBOL.
Nem o Db2.
Nem o CICS.
Nem o TSO.
O primeiro a despertar é o núcleo do sistema.
Chamado tradicionalmente de:
Nucleus.
Imagine o reator principal da nave.
Sem ele...
nada acontece.
O Nucleus — O Reator Central
O Nucleus contém os componentes absolutamente essenciais.
Ali vivem rotinas responsáveis por:
gerenciamento de memória;
tratamento de interrupções;
escalonamento;
proteção;
comunicação com hardware;
serviços básicos.
É o coração pulsante do z/OS.
Por isso ele permanece residente em memória durante toda a execução do sistema.
O Grande Mapa da Cidade
Agora imagine uma cidade gigantesca.
Você precisa saber exatamente onde está:
cada prédio.
cada rua.
cada ponte.
cada estação.
No z/OS esse mapa chama-se:
Memória Virtual.
Mas cuidado.
Ela não é apenas um monte de bytes.
Ela é cuidadosamente organizada.
Os Bairros da Galáxia
A memória do z/OS parece uma cidade cuidadosamente planejada.
Existem bairros com funções específicas.
Entre eles:
CSA.
SQA.
LPA.
PLPA.
FLPA.
MLPA.
Cada um possui regras próprias.
Cada um recebe moradores específicos.
Misturar tudo seria como construir um aeroporto dentro de uma biblioteca.
CSA — A Praça Central
CSA significa:
Common Service Area.
Imagine uma enorme praça pública.
Todos podem passar por ela.
Diversos componentes compartilham informações ali.
Mas exatamente por ser compartilhada...
ela precisa ser extremamente protegida.
SQA — A Área Militar
Agora imagine um setor altamente restrito.
Não entram turistas.
Nem curiosos.
Apenas oficiais autorizados.
Esse setor chama-se:
System Queue Area.
Ali ficam estruturas críticas utilizadas pelo próprio sistema operacional.
Qualquer corrupção nessa região pode comprometer toda a nave.
LPA — A Biblioteca Universal
Imagine uma biblioteca gigantesca.
Milhares de pessoas consultam o mesmo livro.
Seria absurdo imprimir uma cópia para cada uma.
No z/OS surgiu uma ideia brilhante.
Carregar apenas uma única cópia.
Todos compartilham.
Essa biblioteca recebe o nome de:
Link Pack Area.
Ela contém módulos amplamente utilizados por diversas aplicações.
Economia de memória.
Maior desempenho.
Mais estabilidade.
Address Spaces — Pequenos Universos Paralelos
Chegamos a um dos conceitos mais fascinantes do Mainframe.
Imagine um gigantesco prédio.
Cada apartamento representa um universo independente.
Os moradores podem decorar como quiserem.
Mover móveis.
Trocar cortinas.
Pintar paredes.
Mas nunca atravessam magicamente para o apartamento vizinho.
Cada apartamento é um:
Address Space.
Segundo Spruth, o z/OS utiliza Address Spaces independentes para isolar aplicações e proteger o sistema, permitindo que milhares de ambientes coexistam simultaneamente.
Por Que Isso É Importante?
Imagine um programa COBOL contendo um erro grave.
Em muitos sistemas antigos...
ele poderia comprometer todo o computador.
No z/OS...
normalmente ele derruba apenas seu próprio universo.
Os vizinhos continuam vivendo normalmente.
Essa é uma enorme diferença filosófica.
Tarefas Dentro das Tarefas
Agora imagine uma universidade.
Cada faculdade possui dezenas de cursos.
Cada curso possui centenas de alunos.
No z/OS ocorre algo semelhante.
Dentro de um Address Space existem:
Tasks.
Subtasks.
TCBs.
SRBs.
É uma organização hierárquica extremamente eficiente.
Dispatcher — O Controlador de Tráfego
Imagine um aeroporto.
Dezenas de aviões querem pousar.
Centenas desejam decolar.
Quem decide?
A torre.
No z/OS ela chama-se:
Dispatcher.
Sua missão é extremamente simples.
Escolher:
quem executa.
quando executa.
quanto tempo executa.
Depois passa a vez ao próximo.
Spruth descreve o Dispatcher como o responsável por distribuir o tempo de CPU entre as diferentes unidades de trabalho do sistema.
Scheduler — O Mestre das Filas
Agora imagine um restaurante gigantesco.
Milhares de pedidos chegam.
Quem organiza a cozinha?
O Scheduler.
No z/OS ele coordena prioridades.
Urgências.
Dependências.
Recursos.
Nada acontece por acaso.
Interrupções — O Telefone Vermelho
Imagine que durante uma missão alguém aperta um botão de emergência.
O comandante interrompe imediatamente a conversa.
Primeiro resolve a emergência.
Depois continua.
As interrupções funcionam exatamente assim.
Elas avisam ao Supervisor que algum evento importante ocorreu.
Disco terminou.
Rede respondeu.
Timer expirou.
Erro aconteceu.
O Supervisor reorganiza tudo em microssegundos.
Problemas Também Entram na Fila
Curiosamente...
até os problemas seguem regras.
Quando ocorre um erro:
o Supervisor registra.
analisa.
protege o restante do sistema.
gera informações para diagnóstico.
Nada acontece de forma aleatória.
Até o caos é organizado.
O Sistema Nunca Para de Observar
Enquanto aplicações trabalham...
o Supervisor acompanha continuamente:
uso de CPU.
uso de memória.
I/O.
esperas.
prioridades.
contenção.
É como um comandante observando milhares de painéis simultaneamente.
O Tempo Compartilhado
Um iniciante costuma perguntar:
"Como milhares de programas executam ao mesmo tempo?"
A resposta curta é:
eles não executam exatamente ao mesmo tempo.
O Supervisor alterna entre eles tão rapidamente que nosso cérebro percebe continuidade.
É como assistir a um filme.
Na verdade...
você está vendo dezenas de fotografias por segundo.
Quando Tudo Parece Simultâneo
Imagine um mágico lançando:
vinte bolas.
Nenhuma cai.
O segredo?
Ele sabe exatamente quando mover cada mão.
O Dispatcher faz algo parecido.
Troca rapidamente de contexto entre milhares de tarefas.
Resultado?
Todos acreditam possuir a CPU inteira.
O Supervisor Nunca Dorme
Mesmo durante períodos aparentemente tranquilos...
ele continua trabalhando.
Verificando timers.
Tratando interrupções.
Liberando memória.
Gerenciando filas.
Coordenando recursos.
Ele é o único tripulante que jamais abandona a ponte de comando.
O Que Mudou Desde 2010?
Desde que Spruth escreveu seu relatório, o Supervisor do z/OS evoluiu significativamente.
Hoje convivemos com:
processadores multicore muito maiores;
integração profunda com virtualização PR/SM;
Workload Manager extremamente sofisticado;
suporte ampliado para Java, Linux e containers;
automação inteligente;
observabilidade em tempo real;
integração com APIs REST;
inteligência artificial auxiliando diagnósticos.
Mas sua missão continua exatamente igual:
garantir ordem em meio ao caos.
A Filosofia dos Grandes Comandantes
Existe uma lição escondida aqui.
O Supervisor nunca tenta fazer tudo.
Ele coordena.
Distribui.
Organiza.
Confia em especialistas.
Essa talvez seja uma das maiores lições da engenharia.
E também da liderança.
Um bom comandante não pilota todas as naves.
Ele garante que cada especialista faça o melhor trabalho possível.
Curiosidades do Diário de Bordo
🧠 O Supervisor do z/OS permanece ativo durante toda a vida do sistema operacional, coordenando praticamente todos os recursos importantes.
🌌 Address Spaces representam ambientes isolados que permitem enorme estabilidade e proteção entre aplicações.
📚 A Link Pack Area (LPA) evita desperdício de memória compartilhando módulos comuns entre milhares de programas.
🚀 Dispatcher e Scheduler trabalham continuamente para manter equilíbrio entre desempenho, prioridades e utilização eficiente dos recursos.
Diário de Bordo do Padawan COBOL
Antes de deixar a ponte de comando da nave, registre estas coordenadas no seu Holocron Técnico:
✅ Um sistema operacional corporativo é muito mais do que um carregador de programas; ele é o grande coordenador de toda a infraestrutura.
✅ O Supervisor do z/OS atua como um maestro invisível, organizando milhares de atividades simultaneamente sem perder o controle.
✅ O isolamento por Address Spaces é um dos pilares da estabilidade do Mainframe, permitindo que aplicações coexistam com segurança.
✅ Grandes sistemas não sobrevivem porque possuem processadores rápidos. Eles sobrevivem porque existe inteligência coordenando cada microssegundo de sua operação.
Missão Seguinte
No próximo capítulo, embarcaremos em um dos setores mais movimentados de toda a galáxia IBM Z: o JES (Job Entry Subsystem).
Descobriremos por que um simples JCL é, na verdade, um plano de voo interestelar; como milhares de jobs entram em filas sem se atropelar; e por que o JES funciona como a gigantesca torre de controle responsável por sincronizar toda a produção batch do planeta.
Prepare seu cartão perfurado imaginário, revise seu JCL e mantenha sua toalha — e seu café — sempre por perto. Afinal, nossa próxima escala será o coração da produção em lote do universo mainframe.
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
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
