🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀 O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

 

Bellacosa Mainframe apresenta a gestão de tarefas no z/os

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀

O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

Você digita um JCL, dá submit e pensa:
👉 “beleza, agora é só esperar o output”

Errado.

No z/OS, seu job entra em um ecossistema competitivo, onde:

• CPU é disputada
• memória é compartilhada
• prioridades são negociadas
• o sistema decide tudo

Se você quer sair do nível “usuário de mainframe” e virar engenheiro de sistema, esse é o mapa mental que muda o jogo 👊🔥

---

🧠 1. O COMEÇO — SUBMIT NÃO É EXECUÇÃO

Quando você faz submit:

//JOB ...

👉 seu job NÃO executa.

---

🔹 O que acontece de verdade

• JES recebe
• vai pro spool
• ganha um número
• entra numa fila
• espera um initiator

---

🔥 Tradução Bellacosa

“Submit é só entrar na fila do sistema.”

---

💡 Exemplo real

Você tem 100 jobs na fila…

👉 seu job pode esperar minutos ou horas

---

⚙️ 2. JOB → TASK (A TRANSFORMAÇÃO INVISÍVEL)

O z/OS não trabalha com “jobs”.

👉 Ele trabalha com:

TASKS (TCBs)

---

🔹 Como funciona

JOB → STEPS → TASKS (TCB)

Cada step vira uma unidade executável.

---

🧨 Curiosidade

Um job pode gerar várias tasks simultâneas.

---

⚡ 3. DISPATCHER — O “DEUS DO CPU”

Esse é o cara mais importante do sistema.

---

🔹 Função

Decidir:

“Quem roda AGORA?”

---

🔥 Como ele faz isso

• varre a fila (WUQ)
• pega TCB ou SRB
• escolhe o de maior prioridade
• carrega contexto
• entrega CPU

---

💡 Insight poderoso

O dispatcher troca tarefas milhares de vezes por segundo

---

🧠 Tradução

CPU nunca fica “presa” a um programa

---

🧩 4. TCB vs SRB — A BRIGA INTERNA

🔹 TCB

• usado por aplicações (COBOL 👀)
• pode ser interrompido

---

🔹 SRB

• usado pelo sistema
• maior prioridade
• execução mais rápida

---

🔥 Tradução Bellacosa

SRB é o “VIP do sistema”
TCB é o trabalhador comum 😄

---

🧠 5. ENCLAVES — O NÍVEL CORPORATIVO

Aqui o sistema evolui de técnico → negócio.

---

🔹 O que é?

Um conjunto de tarefas:

👉 espalhadas em vários address spaces
👉 tratadas como uma unidade

---

🔥 Exemplo real

App Web → WAS → CICS → DB2

👉 tudo isso vira um enclave

---

💡 Insight

O z/OS não gerencia código… gerencia transações de negócio

---

🖥️ 6. PR/SM — O MESTRE DO HARDWARE

Antes do z/OS, existe:

👉 PR/SM (hypervisor)

---

🔹 Ele faz:

• divide hardware em LPARs
• entrega CPU virtual
• controla recursos

---

🔥 Relação

Hardware → PR/SM → z/OS → Task

---

🧨 Curiosidade

Seu z/OS pode não saber qual CPU física está usando 😳

---

⚡ 7. CPU MANAGEMENT — ONDE PERFORMANCE NASCE

🔹 Conceitos:

• HyperDispatch
• afinidade CPU/memória
• otimização de cache

---

💡 Insight

Rodar perto do dado = menos latência

---

🔥 Tradução Bellacosa

Não é só rodar… é rodar no lugar certo

---

👥 8. ADDRESS SPACES — O UNIVERSO ISOLADO

Cada coisa roda em seu próprio espaço:

• Batch
• TSO
• Started Task

---

🔥 Dentro deles:

• TCBs
• subtasks
• memória isolada

---

💡 Exemplo

Um batch:

Initiator → cria address space → cria TCB → executa

---

🔗 9. DYNAMIC LINKAGE — COMO OS PROGRAMAS SE CONECTAM

🔹 Comandos principais:

• LINK
• LOAD
• ATTACH
• XCTL

---

🔥 O que fazem?

• chamam programas
• carregam módulos
• transferem controle

---

💡 Ordem de busca:

1. memória (LPA)
2. JOBLIB/STEPLIB
3. LINKLIST

---

🧨 Easter Egg

Se está na LPA… é MUITO mais rápido

---

🧠 10. WLM — O VERDADEIRO CHEFE

🔥 Workload Manager

Define:

• prioridade
• objetivos
• distribuição de CPU

---

💡 Exemplo real

Tipo de workload	Prioridade
pagamento online	alta
batch relatório	baixa

---

🔥 Tradução Bellacosa

O sistema não atende quem pede… atende quem importa

---

🔒 11. SERIALIZATION — EVITANDO O CAOS

🔹 Problema:

2 jobs querem o mesmo recurso

---

🔹 Solução:

• ENQ / DEQ
• GRS

---

💡 Exemplo

Dois jobs acessando dataset:

👉 um espera

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Seu job pode nunca rodar

Se prioridade for baixa

---

🔥 2. CPU pode trocar de task milhares de vezes

Você nem percebe

---

💀 3. SRB pode interromper seu programa

Sem você saber

---

🧠 4. Um único negócio pode rodar em vários address spaces

(enclave)

---

⚙️ PASSO A PASSO REAL (SIMPLIFICADO)

Submit Job
 ↓
JES spool
 ↓
Fila de execução
 ↓
Initiator pega job
 ↓
Cria Address Space
 ↓
Cria TCB
 ↓
Dispatcher escolhe
 ↓
CPU executa
 ↓
WLM ajusta prioridade
 ↓
Output no spool

---

🎯 RESUMO FINAL

✔ Job vira task

✔ Task disputa CPU

✔ Dispatcher decide

✔ WLM prioriza

✔ PR/SM gerencia hardware

✔ Enclave agrupa negócio

---

💥 FRASE FINAL

“Você não executa um job no mainframe…
você entra numa competição onde o z/OS decide se você merece rodar.”

 

 

Bellacosa Mainframe o que é address space

Um Café no Bellacosa Mainframe

2,167 subscribers

O que é Address Space?

Bellacosa Mainframe

4,424 followers

July 25, 2025

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?

Um Address Space é um ambiente isolado de execução fornecido 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 um job COBOL batch, ou inicia um programa via CICS, o sistema cria um address space para:

• 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 COBOL online.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, como abend 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á existia dé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 da IBM , ler os manuais e participar da comunidade para evoluir sempre.

Espero ter ajudado e contem comigo para mais artigos, participe de nossa comunidade.

Ajude-nos a evoluir sempre.

Obrigado.

 

Bellacosa Mainframe e as tabelas internas no COBOL occurs e arrays

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

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

---

Introdução

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

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

A segunda é que existe uma entidade maligna chamada:

SSRANGE

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

E tudo isso por causa de um pequeno detalhe:

MOVE WS-NOME(9999)

quando a tabela possui apenas:

OCCURS 100 TIMES.

Bem-vindo ao fascinante mundo das tabelas COBOL.

---

Capítulo 1 – O que é OCCURS?

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

Em linguagens modernas chamaríamos isso de:

• Array

• Vetor

• Lista fixa

• Matriz

Exemplo:

01 CLIENTES.

   05 CLIENTE OCCURS 10 TIMES.

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

Memória:

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

COBOL simplesmente reserva um bloco contínuo.

---

A origem histórica

Década de 60.

Memória era absurdamente cara.

IBM 1401

4 KB

IBM System/360

256 KB

370

1 MB

Não existia:

• Java Collections

• Python List

• C++ Vector

Era necessário reservar memória antecipadamente.

Daí nasceu:

OCCURS

---

Curiosidade histórica

Os engenheiros da IBM chamavam essas estruturas de:

Table Handling

Muito antes da expressão Array Processing se popularizar.

---

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

Exemplo:

01 TAB.

   05 ITEM OCCURS 5 TIMES.

      10 CODIGO PIC 9(5).

Cada item ocupa:

5 bytes

Total

25 bytes

Layout:

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

Acesso:

MOVE ITEM(3) TO WS-X

COBOL faz:

Base + ((3-1)*5)

---

Capítulo 3 – O Terror do Out of Bounds

Tabela:

05 CLIENTE OCCURS 100 TIMES.

Código:

MOVE NOME(101)

Problema.

A posição não existe.

---

Antigamente

Compilador:

NOSSRANGE

Padrão.

Nenhuma verificação.

Resultado:

Leitura aleatória.

Sobrescrever memória.

Corrupção.

---

O verdadeiro vilão

Imagine:

01 TABELA.

05 DADOS OCCURS 100 TIMES.

05 FLAG-FINAL PIC X.

Erro:

MOVE "S" TO DADOS(101)

Na prática:

FLAG-FINAL = S

ou pior.

Modifica outra estrutura.

---

Isso é invasão de memória?

Sim.

Tecnicamente:

Buffer overflow

Memory overwrite

Storage corruption

---

Capítulo 4 — Address Space

No zOS cada Job possui.

Address Space.

Exemplo

JOB1234



Private Area


LSQA


SWA


Subpools


Heap


Stack

Seu programa COBOL vive ali.

---

Se escrever fora da tabela:

pode corromper:

Working Storage

Heap

LE Runtime

Control Blocks

---

Em casos extremos:

S0C4

S878

U4038

---

Capítulo 5 — SSRANGE

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

Compilação:

SSRANGE

ou

CBL SSRANGE

---

Exemplo

MOVE WS-NOME(101)

Resultado:

Abend imediato.

Mensagem:

IGZxxxx

Subscript out of range

---

Excelente para:

Homologação

Teste

QA

---

Produção?

Normalmente:

NOSSRANGE

Performance melhor.

---

Dica Bellacosa

Desenvolvimento

SSRANGE

Produção

NOSSRANGE

---

Capítulo 6 — Índices

Ruim:

77 WS-I PIC 999.

Melhor:

05 CLIENTE OCCURS 100 TIMES
   INDEXED BY IDX.

---

SET

SET IDX TO 1

---

Próximo

SET IDX UP BY 1

---

Anterior

SET IDX DOWN BY 1

---

Por que índice é melhor?

Subscript:

CLIENTE(I)

Cálculo toda vez.

---

Index

Endereço pronto.

Ponteiro interno.

Mais rápido.

---

Capítulo 7 – Navegação

Crescente

SET IDX TO 1


PERFORM UNTIL IDX > MAX

PROCESSA

SET IDX UP BY 1

END-PERFORM

---

Decrescente

SET IDX TO MAX


PERFORM UNTIL IDX = 0


PROCESSA


SET IDX DOWN BY 1


END-PERFORM

---

Muito usado em:

Compressão

Ordenação

Rollback

---

Capítulo 8 — SEARCH

Busca sequencial.

SEARCH CLIENTE


AT END


DISPLAY "NAO ACHOU"


WHEN ID = WS-ID


DISPLAY NOME

END-SEARCH

---

Complexidade

O(n)

---

100 mil registros.

50 mil leituras médias.

---

SEARCH ALL

Arma secreta.

Busca binária.

---

Tabela obrigatoriamente ordenada.

SEARCH ALL CLIENTE


WHEN ID(IDX)=WS-ID


DISPLAY "ACHOU"

END-SEARCH

---

Complexidade

O(log n)

---

1000000 itens.

Comparações:

~20

---

Magia matemática.

---

Capítulo 9 — OCCURS DEPENDING ON

Tabela variável.

05 QTDE PIC 9(4).


05 CLIENTE OCCURS 1 TO 1000 TIMES

DEPENDING ON QTDE.

---

Muito usado em:

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 e o conceito de address space

O que é Address Space?

Se existe um conceito que todo estudante de Mainframe precisa compreender logo no início, esse conceito é o Address Space.

Ele é uma das bases do funcionamento do z/OS e explica como milhares de programas conseguem executar ao mesmo tempo no IBM Z sem interferirem uns nos outros.

Embora o nome pareça complicado, a ideia é bastante simples.

---

Definição simples

Um Address Space (Espaço de Endereçamento) é uma área de memória virtual exclusiva onde um programa, um subsistema ou um serviço do z/OS é executado.

Cada Address Space possui:

• sua própria memória;

• seus próprios programas;

• suas próprias variáveis;

• seus próprios controles;

• sua própria proteção.

Em outras palavras:

Cada programa executa em um "ambiente privado", sem acessar diretamente a memória dos outros programas.

---

Uma analogia simples

Imagine um grande prédio comercial.

Cada empresa possui um escritório próprio.

Dentro do escritório existem:

• computadores;

• documentos;

• funcionários;

• armários.

Os funcionários de uma empresa não entram livremente nas salas das outras.

No z/OS acontece exatamente isso.

Cada programa trabalha dentro do seu próprio escritório, chamado Address Space.

---

O que significa Address Space?

Em português:

Espaço de Endereçamento.

É o conjunto de endereços de memória que um programa pode utilizar durante sua execução.

---

Por que ele existe?

Imagine que dois programas estejam executando ao mesmo tempo.

Programa A:

Calcula salários

Programa B:

Processa PIX

Se ambos utilizassem a mesma memória física sem controle, um poderia sobrescrever os dados do outro.

O resultado seria:

• corrupção de memória;

• perda de dados;

• travamentos;

• ABENDs.

O Address Space evita esse problema.

---

Como funciona?

Imagine três programas.

COBOL

CICS

DB2

Cada um recebe seu próprio espaço.

+------------------+
| Address Space A  |
| Programa COBOL   |
+------------------+

+------------------+
| Address Space B  |
| CICS             |
+------------------+

+------------------+
| Address Space C  |
| DB2              |
+------------------+

Cada ambiente é isolado.

---

Memória Virtual

Os Address Spaces utilizam memória virtual.

Isso significa que o programa acredita possuir um enorme espaço de memória.

Na realidade, o z/OS faz o gerenciamento automaticamente.

---

Isolamento

Uma das maiores vantagens é a proteção.

Programa A

↓

não consegue alterar

↓

Programa B

Isso aumenta muito a segurança.

---

Quantos Address Spaces existem?

Depende do ambiente.

Um grande banco pode possuir milhares deles simultaneamente.

Exemplo:

• JES2;

• CICS;

• DB2;

• IMS;

• MQ;

• TCP/IP;

• aplicações COBOL;

• utilitários;

• Started Tasks.

Cada componente normalmente executa em seu próprio Address Space.

---

O que existe dentro de um Address Space?

Normalmente encontramos:

• programa executável;

• memória de trabalho;

• pilhas (Stacks);

• buffers;

• tabelas;

• bibliotecas carregadas;

• áreas de controle.

Tudo isso pertence apenas àquele Address Space.

---

Quem cria o Address Space?

O próprio z/OS.

Sempre que um JOB ou uma Started Task inicia, o sistema operacional cria automaticamente um novo espaço de endereçamento.

---

JOB Batch

Quando um JOB COBOL começa:

JES2

↓

Inicia JOB

↓

z/OS cria Address Space

↓

Programa executa

↓

JOB termina

↓

Address Space é removido

---

Started Tasks

Serviços permanentes normalmente possuem Address Spaces próprios.

Exemplos:

• JES2;

• VTAM;

• TCP/IP;

• DB2;

• CICS;

• RACF;

• OMVS.

Esses espaços permanecem ativos durante muito tempo.

---

Address Space e CICS

Normalmente existe um Address Space para cada região CICS.

Dentro dele podem existir milhares de transações simultâneas.

As transações compartilham recursos internos do CICS, mas continuam protegidas pelo gerenciamento da região.

---

Address Space e DB2

O Db2 utiliza diversos Address Spaces.

Exemplo:

MSTR

DBM1

IRLM

DIST

Cada um possui funções específicas.

---

Como o z/OS protege a memória?

O hardware do IBM Z trabalha em conjunto com o sistema operacional.

Se um programa tentar acessar memória que não lhe pertence:

resultado:

Protection Exception

Ou outro tipo de ABEND.

Essa proteção é um dos pilares da confiabilidade do mainframe.

---

Benefícios

Segurança

Programas não interferem entre si.

---

Estabilidade

Um erro em uma aplicação normalmente não afeta as demais.

---

Escalabilidade

Milhares de programas podem executar simultaneamente.

---

Organização

Cada aplicação possui seu próprio ambiente de execução.

---

Quem trabalha com Address Spaces?

Diversos profissionais lidam com esse conceito:

• Programadores COBOL;

• Desenvolvedores PL/I;

• Administradores CICS;

• DBAs;

• Sysprogs;

• Operadores Mainframe;

• Especialistas em Performance.

---

Curiosidades incríveis

1. O z/OS pode manter milhares de Address Spaces ativos

Grandes ambientes executam milhares de aplicações simultaneamente sem comprometer a estabilidade.

---

2. Cada região CICS normalmente possui seu próprio Address Space

Isso facilita o isolamento entre ambientes de produção, homologação e testes.

---

3. O Db2 utiliza vários Address Spaces

Cada um desempenha uma função específica, como gerenciamento, processamento de banco de dados, bloqueios e conexões distribuídas.

---

4. O conceito existe desde os primeiros sistemas de memória virtual da IBM

Ele evoluiu ao longo das décadas e continua sendo um dos principais motivos da alta confiabilidade do IBM Z.

---

Erros comuns de iniciantes

"Address Space é apenas memória RAM"

Não.

Ele representa um espaço de memória virtual, administrado pelo z/OS e mapeado para a memória física conforme necessário.

---

"Todos os programas compartilham a mesma memória"

Não.

Cada aplicação executa em seu próprio Address Space, garantindo isolamento e proteção.

---

"Quando um programa termina, o Address Space continua existindo"

Nem sempre.

Nos jobs batch, o Address Space normalmente é encerrado quando o processamento termina.

Já serviços permanentes, como CICS e Db2, permanecem ativos enquanto o subsistema estiver em execução.

---

Quando aprender Address Space?

Esse conceito deve ser estudado logo após compreender:

• z/OS;

• memória virtual;

• Storage;

• processamento Batch;

• Started Tasks.

Ele servirá de base para entender CICS, Db2, IMS, desempenho, gerenciamento de memória e arquitetura do IBM Z.

---

Conclusão

O Address Space é um dos conceitos mais importantes do z/OS. Ele fornece um ambiente de memória virtual isolado para cada programa, job ou subsistema, permitindo que milhares de aplicações executem simultaneamente com segurança, estabilidade e alto desempenho.

Sem os Address Spaces, o IBM Mainframe não conseguiria oferecer o nível de confiabilidade, disponibilidade e escalabilidade que faz dele a plataforma escolhida por bancos, seguradoras, governos e grandes empresas em todo o mundo.