Módulo 2 Mainframe

Tabela de Conteúdo

1. Apresentação
2. Formas de Representação – 1 de 4
3. Formas de Representação – 2 de 4
4. Formas de Representação – 3 de 4
5. Formas de Representação – 4 de 4
6. Binário e Hexadecimal – 1 de 4
7. Binário e Hexadecimal – 2 de 4
8. Binário e Hexadecimal – 3 de 4
9. Binário e Hexadecimal – 4 de 4
10. Crescimento da Informação
11. Bytes e Words: Tamanhos
12. Padrões EBCDIC e ASCII
13. Formatos Numéricos
14. Conceitos: Hardware e Software
15. Particionamento Físico e Lógico
16. Particionamento Físico (em desuso)
17. Processamento n - way
18. Particionamento Lógico
19. CEC e CPC: Fundamentais
20. Memória: tipos e usos
21. CPU, Registradores e PSW
22. SubSistema de Canal: entrada/saída de dados
23. Visão Geral de um Sistema Computacional
24. Power On Reset e Initial Microcode Loading
25. Initial Program Loading = “boot”
26. Address Spaces e Espaços de Dados
27. Mecanismo de Memória Virtual
28. Arquivos de Paginação e Swapping
29. Mecanismo de Interrupções
30. Dispatcher: Execução de Tarefas
31. Métodos de Acesso e Blocagem
32. Métodos de Acesso: Organização Seqüencial
33. Métodos de Acesso: Organização Direta
34. Métodos de Acesso: Organização Particionada
35. Métodos de Acesso: Arquivos VSAM
36. SRM (System Resources Manager)
37. WLM (WorkLoad Manager)
38. SMF (System Management Facility)
39. RMF (Resource Measurement Facility)
40. O Mundo UNIX no Mainframe
41. O Ambiente do Usuário
42. O File System do UNIX
43. MVS, OS/390 e z/OS
44. VM e z/VM
45. O que é um MONTADOR (Assembler)
46. O que é um COMPILADOR
47. O que é um INTERPRETADOR
48. Visão Geral dos Módulos: FONTE, OBJETO e de CARGA
49. Arquivos e Atualização
50. Objetos
51. Estruturação do REXX
52. Funções do JOB Entry Subsystem
53. Inicialização do JES2 (JES2PARM)
54. RJE: Remote JOB Entry
55. NJE: Network JOB Entry
56. Diferenças para o JES3
57. SDSF System Display and Search Facility
58. Processamento Batch: Local e Remoto (RJE/NJE)
59. Processamento Interativo: TSO/E
60. Processamento Interativo: ROSCOE
61. Processamento de Transações: CICS ou IMS
62. Placas/Canais OSA
63. DCE Distributed Computing Environment
64. Célula DCE
65. Serviços de Computação Distribuída
66. Segurança no Sistema Central
67. Segurança no Ambiente DCE
68. Interoperabilidade RACF / DCE
69. Segurança na Computação em Rede
70. Leitura Módulo 2 - finalizada
Apresentação
Neste módulo veremos alguns conceitos de Hardware, Software,
Sistemas Operacionais, Aplicativos, Batch, Online e Sistemas Distribuídos.

Bom estudo!

Formas de Representação – 1 de 4

O significado de uma maçã não é alterado pelo fato dela ser conhecida por vários nomes diferentes, em
diferentes línguas, são apenas nomes e letras diferentes, para a mesma coisa.
Assim também, uma quantidade, um valor, não é alterado pelo fato de ser representado em diversas
Bases de numeração, que explicam o significado dos dígitos no número.

Formas de Representação – 2 de 4

Vamos agora entender como a Informação é Representada dentro do computador.

Lembremos que George Boole definiu a Álgebra booleana, que usa a numeração binária, e
que esta foi implementada nos Computadores, devido às características da eletricidade.

Temos então as seguintes definições:

Bit - É a menor unidade de informação possível e só possui dois valores: 0 ou 1

Byte - É a convenção do número de bits que o compõe: 8 bits perfazem um byte (na França, chama-se
OCTETO)

Estes 8 bits representam 256 possibilidades: de 0 a 255, equivalentes ao número binário que contém.
Formas de Representação – 3 de 4

Mostramos acima o que queremos dizer quando anotamos o número 206 na base decimal e o seu
equivalente nas bases binária (‘11001110’) e hexadecimal (‘CE’).
A título de curiosidade, mostramos como este número seria representado, caso usássemos os algarismos
Romanos!
São usadas nos Mainframes as Bases: Binária (2), Hexadecimal (16, para Ponto Flutuante) e Decimal (10,
para Compactado).

Formas de Representação – 4 de 4

Distinguimos os seguintes termos:

Dado, que é apenas um número,

Informação, que é um número associado a uma unidade e
Conhecimento, que é o conjunto de leis que explicam como a informação pode ou deve ser utilizada.

Binário e Hexadecimal – 1 de 4

Como vimos, a Base 2 utiliza apenas dois valores possíveis:

Zero e Um, que podem representar a presença/existência ou não de um dado atributo.
Binário e Hexadecimal – 2 de 4
A Eletricidade permite obter maior Velocidade trabalhando em Binário, um dos motivos é que são
necessárias apenas as duas “tabuadas” abaixo, com as quais se consegue operações:

• Adição e subtração (ver “tabuada” da adição abaixo e complemento de 2, a seguir)

• Multiplicação e divisão, por adições e subtrações sucessivas

Para cálculos mais complexos, implementam-se algoritmos em Rotinas de:

• Exponenciação, Trigonométricas, Inversos, Algoritmos para Multiplicação, Divisão, Raiz

Quadrada.

Binário e Hexadecimal – 3 de 4
Números Negativos são expressos como Complemento de 2. Abaixo mostramos como obter o
Complemento de 2 de um número:

1. Inverte-se todos os seus bits;

2. Soma-se um ao bit de mais baixa ordem.
Subtrações são obtidas somando-se o complemento do subtraendo.

O bit de mais alta ordem é o sinal:

• 0 significa número positivo
• 1 significa número negativo
Binário e Hexadecimal – 4 de 4
A Base 16 (Hexadecimal) é apenas uma simplificação na maneira de se
expressar os números em binário, combinando quatro bits de cada vez e
convertendo pelo uso de uma tabela, tal como mostrado nesta página.
Determinadas situações, principalmente quando alguma convenção do
Sistema Operacional é contrariada, caracterizam o fim anormal
(Abnormal end) da tarefa em andamento e o conteúdo da memória é
descarregado (Dump) em hexadecimal em um arquivo, para posterior
listagem em papel ou análise com a ferramenta IPCS, para se descobrir a
causa do erro.

Crescimento da Informação
Esta ilustração apresenta a evolução dos múltiplos (prefixos) usados para quantificar a informação, já
que estas quantidades crescem num ritmo acelerado.

Na definição da Arquitetura do Sistema /360, o barramento de Endereços foi definido com 24 fios,
significando a possibilidade da CPU e Canais acessarem 2 elevado a 24 ou seja, 16 Megabytes de
Memória.

A próxima Arquitetura, chamada /370-XA (de eXtended Architecture), foi definida com 31 fios,
permitindo acessar 128 vezes mais dados, ou 2 Gb.

A última Arquitetura definida, chamada Arquitetura z (de Zero Down Time), com 64 fios, permite 8
bilhões de vezes a anterior, ou 16 exaBytes.
• As primeiras máquinas da Arquitetura z podiam ter até 64 Gb de Memória Central.
• Os novos equipamentos T-Rex z990 podem atingir 256 Gb de Memória Central, ou seja, um
quarto de Terabyte de Memória!
Bytes e Words: Tamanhos

O Byte é a menor unidade endereçável de memória, e o tamanho ou capacidade desta é medido pela
quantidade de Bytes que possui.

O expoente da base 2, representa o número de fios que deve ter o barramento de Endereços para que CPU
e Canais possam acessar cada byte da Memória.
Houve uma época em que a Memória era medida em quantidade de “Palavras” e cada fabricante definia
quantos Bytes tinha a Palavra da sua máquina. Embora menos usada atualmente (programadores
Assembler usam com freqüência) mas, para irmo-nos habituando com a nomenclatura, observemos os
nomes dados às associações de bytes contíguos no Mainframe, conforme a ilustração apresentada.

Prefixos gregos e extensões:

Kilo / Mega / Giga / Tera / Peta / Exa / Zeta / Yotta
mili / micro / nano / pico / femto / atto / zepto / yocto
Padrões EBCDIC e ASCII

Padrões EBCDIC e ASCII

Para que as informações pudessem ser trocadas entre máquinas diferentes, foram desenvolvidos Padrões
de representação de caracteres binários:
• ASCII: adotado no PC e microcomputadores em geral
• EBCDIC: adotado pela IBM para os Mainframes

É necessária esta Conversão entre os padrões, quando se deseja trocar informação.

Classificação dos Conteúdos possíveis de um byte:

• Dígitos (Números) de 0 a 9
• Letras: MAIÚSCULAS e minúsculas de A até Z
• Pontuação, caracteres nacionais (@, #, $)
• Caracteres especiais como + * (
• Caracteres de controle como NUL, CR, DS
Formatos Numéricos
No Mainframe, são usados 7 Formatos Numéricos:

3 formatos Binários (números inteiros):

Ponto Fixo: com e sem sinal e Lógico (sempre sem sinal).

3 formatos em Ponto Flutuante (HFP, formato Hexadecimal):

Curto, longo, estendido (4, 8 e 16 bytes cada).

1 formato em Decimal compactado de comprimento variável (1 a 31 dígitos)

Basicamente são usadas 4 Representações:

Binário, Hexadecimal, Decimal, Caracteres

Por sugestão do IEEE, foram adotados novos formatos em Ponto Flutuante Binário (BFP)
A Arquitetura z acrescentou formatos de 64 bits e novas instruções para manipulá-los.
Não julgamos necessário neste momento.
Conceitos: Hardware e Software
Algumas definições que vamos precisar:
• Hardware é a parte material do computador, aquela que se
pode tocar, são as “ferragens”.

• Software é a parte não material (posso tocar a mídia que

contém um programa mas NÃO as Instruções que o
compõem), que estrutura o que deve ser feito pelo
Hardware.

• Firmware é uma área “nebulosa”, que possui características

de ambos: É programada (em Assembler e C) como se
fosse um Software mas funciona intrinsecamente ligada ao
Hardware (micro-instruções na Control Storage, dentro do chip da PU).

• Arquitetura é o conjunto de regras que definem quais as funções que um dado Hardware deve ter,
as instruções que deve executar, que resultados produzir e define também as interfaces, ou como o
Software irá pedir/conseguir resultados mais os mecanismos de Controle (Interrupções,
Sinalizações, etc) que caberão ao Sistema Operacional tratar.

• Design é a Tecnologia com a qual uma dada Arquitetura foi implementada. Assim sendo, posso
implementar uma mesma Arquitetura segundo diferentes Técnicas, resultando em máquinas
diferentes que realizam as mesmas funções. Com transístores Bipolares ou CMOS, com ou sem
Caches, com ou sem Pipelines, com mais ou menos Memória Associativa (CAM = Contents
Addressable Memory, as TLBs e ALBs), etc.

Particionamento Físico e Lógico

Inicialmente, uma máquina Física era totalmente absorvida pelo Sistema Operacional (ou Programa
“Stand Alone”) que a estivesse usando.

• A possibilidade de se ter mais de uma CPU, na mesma máquina e compartilhando a mesma

Memória Central é chamada “Tightly Coupled”.
• Quando várias CPUs, localizadas em máquinas diferentes, se comunicam entre si (normalmente
através de um dispositivo chamado CTC=Channel to Channel Adapter), dizemos que se chama
“Loosely Coupled”.
Então, surgiram máquinas que podiam ser “divididas” em duas, e apenas duas, máquinas Lógicas, em
cada uma das quais se podia colocar um Sistema Operacional diferente e que funcionavam
independentemente do outro. Esta “divisão” não era exatamente “no meio”: o Usuário decidia quanto de
Memória, Processadores e Canais cada máquina Lógica iria possuir, dentro de certos limites
(granularidade).

Para eliminar a restrição de 2 máquinas lógicas por máquina física, foi criado o conceito de
Particionamento Lógico, onde uma mesma máquina Física poderia conter 7, depois 10, depois 15 e hoje
até 30 (já está prevista a possibilidade de termos 60) máquinas Lógicas diferentes e independentes. Aqui
também, é o usuário quem decide quanto de cada recurso (Processadores, Memória e Canais) cada
máquina Lógica vai ter.

Particionamento Físico (em desuso)

Foi graças à duplicação de componentes (Hardware) que se tornou possível:

Um “Box” ser dividido em 2 Sistemas independentes

Permitindo a existência de 2 Ambientes distintos e independentes
Processador / Memória / Canais não eram compartilhados
Carga baixa em um “side” significava desperdício de recursos
As novas máquinas CMOS não têm mais este Modo
Ver adiante o Sistema Operacional VM (Virtual Machine), considerado uma forma “lógica” de
particionar, devido à simulação por Software: mais “assist”, capacidades adicionais do Micro-Código,
como a instrução SIE (Start Interpretive Execution), que “despacha” uma máquina Virtual

Processamento n - way

Graças aos avanços da Tecnologia, foi conseguido:

Mais de um Processador por “Box”: CEC / CPC
Podem ser compartilhados ou não (dedicados à LPAR)
Tem as vantagens do Tightly Coupled
Sem as desvantagens do particionamento Físico

Esta é a modalidade “vigente” e presente nos Mainframes atuais.

Particionamento Lógico

Graças às técnicas de Micro Código ou Micro Programação, em contraposição às de “Hardwiring”,

temos:
PR/SM: Processor Resources / System Management, que suporta o LIC;
LIC: Licensed Internal Code (exemplo: CFCC, LPAR Scheduler)
LPAR Scheduler (é o micro código (LIC) que coordena as LPARs)
LPAR: Logical Partition, cada uma das divisões lógicas da máquina física
Flexibilidade de alocação / distribuição dinâmica de recursos:

Processadores (podem ser compartilhados em pedaços de tempo, “slices”)

Memórias (não podem ser compartilhadas mas podem ser remanejadas)
Canais (podem ser compartilhados se houver MIF=Multiple Image Facility)

CEC e CPC: Fundamentais

O nome dado ao Computador, ou à sua caixa (“box”) física, é:

CEC - Central Electronic Complex (usado na literatura Técnica) ou CPC - Central Processor Complex
(usado nas Consoles HMC e SE) e contém:

Processadores
Memórias e
CSS (Channel Sub System ou Sub Sistema de Canais).
Além destes três componentes principais, listamos outros elementos de Tecnologia:
PR/SM e LIC: Micro códigos permitiam dois modos de funcionar
Basic e LPAR modes (este último é o único disponível nas máquinas atuais)
É possível a Reconfiguração dinâmica (sem parar) de CPUs, Memórias e Periféricos
O controle do Hardware é feito pelos lap-tops, chamados SE (Support Element), ou pela HMC (Hardware
Management Console).
Mais elementos de Tecnologia: CMOS, Fonte, Bateria, Placa OSA (detalhada adiante)

Imagens são os nomes dados às cópias dos Sistemas Operacionais, que podem ser:

MVS, OS/390, z/OS, VM, z/VM, TPS, DOS-VSE, LINUX

O objetivo último é disponibilizar ao Usuário a parte “lógica” ilustrada acima.

Memória: tipos e usos

Vamos agora nos deter nos três principais componentes do CEC/CPC:
Memória é o local onde ficam instruções e dados, e de onde a CPU os vai retirar.
Nos Cursos Presenciais detalharemos os esquemas de Endereçamento e suas exceções, esquemas de
Proteção, padrão de Referência e de Alteração (Reference e Change bits).
Toda Memória é dividida em “pedaços” de 4Kb, que têm os seguintes nomes:
Se estiverem na Memória Central (Real), são chamados de Frames
Se na Expandida (Real), E-Frames (não existe mais este tipo na Arquitetura z)
Se na Auxiliar (Arquivos chamados Page data sets), Slots
Se na Virtual (Conceitual), Pages
Os Processador e o SubSistema de Canais, apenas têm acesso à Memória Central (Real).
O Sistema Operacional administra as Memórias físicas de tal maneira que seja transparente para o
usuário, que só deve se preocupar com a Memória Virtual (a única que um Programa pode “enxergar”;
vamos detalhar estes Conceitos no Curso Presencial).

Para que a CPU possa fazer a “tradução” dos endereços de Memória Virtual para Real, é usado um
dispositivo de Hardware chamado DAT=Dynamic Address Translation e Tabelas dispostas na Memória
Central, chamadas de Segment e Page Tables, das quais falaremos bastante nos Cursos Presenciais.

CPU, Registradores e PSW

Cada CPU tem a capacidade de realizar cálculos graças à: ALU: Unidade Aritmética e Lógica (o único
componente “ativo”) e Registradores, dos quais existem 16 de cada tipo:
De uso Geral
Controle (apenas usados pelo Sistema Operacional)
Acesso (usados pela técnica AASF, um conceito muito avançado, não relevante neste momento.
Ponto Flutuante (IBM: HFP + IEEE: BFP)

A PSW ou palavra de estado do Programa, é composta de duas partes:

Máscaras e indicações de estado (o que o Programa pode ou não pode fazer!)
Endereço da próxima Instrução (NSI=Next Sequential Instruction)

Outros registradores existentes em cada CPU: Prefix, Clock Comparator, CPU Timer.
Para determinadas Instruções, o resultado obtido pela ALU é mantido em um conjunto de 4 bits chamados
“Flags” da ALU, para indicar, após cada tipo de Instrução:

Aritméticas: se o resultado é zero, menor ou maior que zero ou houve “overflow”

Comparação: operandos iguais, primeiro ou segundo operando menor que o outro
Testes de Bits: se todos os bits testados são Zero, Um ou estão “misturados” (zeros e uns).
SubSistema de Canal: entrada/saída de dados

O SubSistema de Canal possui os seguintes conceitos, que ampliaremos mais tarde:

IOP ou SAP, são Processadores que conferem a capacidade de processamento aos Canais

Channel Paths, são os caminhos (fibra óptica) e fornecem a capacidade de conexão

Curiosidade: Alguns tipos de Canais existentes: BY, BL, CTC, CNC, OSA, FC, FCV, etc.

Unidades de Controle oferecem economia de escala e tomam “conta” de vários dispositivos periféricos,
como: Discos, Fitas, Terminais, Linhas de Teleprocessamento, etc.

Sub canais (ou UCW) representam os periféricos, isto é, cada Periférico tem uma porção de Memória
(numa área especial chamada HSA = Hardware System Area) associada a ele.Sub canais trabalham
assincronamente e em paralelo aos Processadores, comunicando-se com eles via Interrupções e
permitindo recuperações de erro.

Uma operação de I/O (Entrada e Saída) é conseguida pela execução de instruções de um Programa de
Canal, chamadas CCW Channel Command Word, instruindo o que ler/gravar.

Canais ESCON são compostos de fibra óptica. Estas têm vantagens na transmissão serial (luz) comparado
com a paralela (que usava eletricidade, portanto sujeita a interferências).

EMIF é uma facilidade que permite o compartilhamento de CNC, CTC, CFS e OSA.

FICON é a última “geração” de canais de fibra óptica e têm a maior vazão: 200 MB/s.

Visão Geral de um Sistema Computacional

Reunindo os Conceitos destas três partes importantes e resumindo, um Computador é fisicamente

composto de:
Processadores
Memórias
SubSistema de Canais e caminhos de canal (Channel Paths)
Unidades de Controle
Periféricos, Redes
O Sistema Operacional provê os Serviços básicos para a execução de um trabalho (JOB) e as
salvaguardas necessárias para evitar que situações de erro comprometam o funcionamento de outras
partes do Sistema, controlando assim todo o Computador.

Produtos e Ferramentas completam a funcionalidade de um Sistema Operacional, viabilizando os

Ambientes de Produção e Desenvolvimento, como Gerenciadores de Bases de Dados e de Transações.
Sistemas Aplicativos são aqueles desenvolvidos pelos Analistas e Programadores do CPD, através de
Programas Batch e Transações, que podem ser:
Online, ligados diretamente ao Computador mas sem atualizar arquivos, ou
Realtime, diretamente ligados e atualizando os arquivos instantaneamente.

Power On Reset e Initial Microcode Loading

A inicialização do Hardware começa pelo processo de POR (Power On Reset), embutido no qual se dá o
IML (Initial Microcode Loading), preparando-o fisicamente para as funções lógicas que o usuário
configurou via HCD (Hardware Configuration Definition).
A ferramenta HCD é invocada num Terminal, via ferramenta TSO/E e cria dois arquivos:

IODF (Input Output Definition File), que contém as configurações de I/O para os Sistemas Operacionais
(UCB = Unit Control Block), transferidas para a área COMMON no processo de IPL (visto a seguir).
IOCDS = Input Output Configuration Data Set através de um utilitário de IOCP Input Output
Configuration Program, contendo informações como as UCW = Unit Control Word e CUCW = Control
Unit Control Word, que serão transferidas para a HSA = Hardware System Area, na Memória Central
durante o POR/IML.
O processo de POR/IML é controlado pelo SE = Support Element, um dos lap-tops presentes no
Mainframe, podendo ser iniciado de sua console ou de uma HMC = Hardware Management Console.
Apenas após a carga dos Micro-Programas é que o Hardware poderá operar. Antes deste instante, o
Hardware nem consegue “enxergar” os Periféricos existentes (não há UCW!).

Initial Program Loading = “boot”

A partir do POR/IML, poderão ser usadas Consoles “normais” MCS (Multiple Console Support), para
fazer a inicialização do Software via NIP (Nucleus Initialization Program) e para a comunicação com as
imagens de Sistemas Operacionais que forem carregadas pelo IPL (Initial Program Loading, o equivalente
ao “boot” do Micro).
O conteúdo dos 8 bytes do LOADPARM será explicado mais tarde. Entre outras funções, ele serve para
determinar qual carregar, dentre vários Sistemas Operacionais que possa ter.

Os Sistemas Operacionais de Mainframes ficam alojados, basicamente, em quatro arquivos, segundo as

suas características de uso ou funções:

SYS1.NUCLEUS - Kernel do Sistema Operacional, residente todo tempo na Memória

SYS1.LPALIB - Rotinas “transientes” do SO, só vêm para a Memória se necessário
SYS1.LINKLIB - Rotinas colocadas à disposição dos Usuários (Utilitários, etc.)
SYS1.SVCLIB - Rotinas de recuperação de erros, raramente necessárias.

Que módulos serão carregados, em que ordem e onde, depende de parâmetros que o pessoal de Suporte
especificou no arquivo SYS1.PARMLIB. Quais arquivos do Sistema Operacional que serão usados, estão
definidos no arquivo Catálogo Mestre (MasterCat).
Apenas um detalhe, para agilizar o carregamento das rotinas “transientes”, elas são “preparadas” e
colocadas num outro arquivo chamado PLPA Page Data Set.
Address Spaces e Espaços de Dados

Vamos ver mais conceitos, envolvendo a Memória Virtual:

Chamamos Address Space ao conjunto de endereços que um Programa pode gerar. É sinônimo de
Memória Virtual. Têm a seguinte distribuição, ou “mapeamento”:

Área Comum: Contém rotinas e dados/tabelas do Sistema Operacional, está mapeada em torno da linha
dos 16 Mbytes, tendo uma parte “acima” e outra “abaixo” desta linha.

Área Privada: Contém rotinas e dados do Usuário e são duas: a área acima da linha dos 16 Mbytes é
chamada Área Privada Estendida.

Devido ao endereçamento em 31 bits, os Address Spaces do OS/390 chegam a 2 Gbytes.

Devido ao endereçamento em 64 bits, os Address Spaces do z/OS atingem 16 ExaBytes, 8 bilhões de
vezes maior.
Data Spaces e Hyperspaces são sempre vinculados a um Address Space; contêm apenas dados, utilizados
por instruções que executam no Address Space proprietário.
Data Spaces: permitem o acesso byte a byte
Hyperspaces: acesso apenas em blocos de 4 Kbytes

Mecanismo de Memória Virtual

Memória Central: acessível byte a byte, por instruções de programa.
Memória Expandida: acessível em blocos de 4 Kbytes, apenas pelo Sistema Operacional. Quem
precisava, pedia a ele.
Memória Expandida era um elemento intermediário entre a memória Central e a Auxiliar, para operações
de Paginação e Swapping, usada preferencialmente, em relação aos Arquivos de Paginação e Swapping
em Memória Auxiliar; era arquiteturalmente mais extensa que a Memória Central, ou seja, não limitada a
2 GB.
Page (Página): célula de 4 Kbytes mapeada na Memória Virtual através das Tabelas de Segmento e
Página.
Frame: célula de 4 Kbytes localizada na Memória Real (Central + Expandida); quando localizada na
Memória Expandida, também era chamada de E-Frame.
Slot: célula de 4 Kbytes localizada num Arquivo de Paginação ou Swapping, na Memória Auxiliar.
A localização física de uma Página Virtual na Memória Central é determinada pelo hardware DAT
(Dynamic Address Translation), com base em tabelas mantidas pelo Sistema Operacional.

Arquivos de Paginação e Swapping

Para resolver os problemas de escassez de Memória Central, o Sistema Operacional lança mão dos
seguintes processos:
Page Out: para liberar Frames na Memória Central
Page In: para resolver Page-Faults, trazendo-as da Memória Auxiliar
Swap Out: para reduzir a carga do Sistema ou quando um Address Space está em WAIT, ou seja, não
pode receber CPU
Swap In: para aumentar a carga do Sistema ou quando um Address Space fica de novo READY, ou seja,
pronto para receber CPU

Arquivos de Paginação obrigatórios:

PLPA e COMMON (contém SLOTS do Sistema Operacional)
Pelo menos um LOCAL (contém SLOTS dos Usuários)
Arquivos de Swapping eram opcionais no OS/390, agora não são mais usados. Se não fossem definidos, o
Sistema usava os arquivos de paginação Local, como faz atualmente.

Mecanismo de Interrupções
Vejamos agora como atua o Componente do Sistema Operacional que administra as Tarefas a executar.
Para isso, notemos que há seis tipos de interrupções, cuja compreensão somente será necessária nos
Cursos Presenciais, e que são:
PSW Restart
External
SuperVisor Call
Program Check
Machine Check
Input/Output.

Quando ocorre qualquer interrupção num processador, um Tratador de Interrupção, específico para cada
um dos 6 tipos, recebe o controle, salva o “status” do que estava sendo executado e analisa a interrupção
para determinar as suas causas.

Passa o controle, então, para uma Rotina Específica, conforme a causa da interrupção (I/O, Program
Check, External, etc.).

Quando esta Rotina termina, passa o controle para o Dispatcher, que determina qual Task vai executar
naquele processador: ou a que foi interrompida, ou outra, que estava aguardando sua vez.

Dispatcher: Execução de Tarefas

O Dispatcher recebe o controle ao fim de cada interrupção e quando rotinas do Sistema Operacional
acabaram de executar.
O Dispatcher “despacha” quem vai executar depois dele, na mesma CPU. Uma outra maneira de se
interpretar este fato é supor que, se está sendo executado o código do Dispatcher é porque esta CPU que o
executa está procurando o que ela deve fazer em seguida.

Ele sempre despacha quem estiver no topo da Fila, onde se encontram todas as Tasks que querem ganhar
CPU para executar as instruções dos Programas que representam.
Há Tasks que não estão nesta Fila, porque estão aguardando algum evento que ainda não aconteceu, como
a leitura dos dados necessários, por exemplo. Diz-se que estas

Tasks estão em WAIT. Quando o Sistema Operacional tiver completado o evento pelo qual esperam, elas
são tiradas deste estado (Wait) e ficam “prontas” (Ready) para receber CPU, na Fila do Dispatcher.
A Fila do Dispatcher contém as Tasks a executar em cada Address Space e é organizada pelo SRM
(System Resources Manager), em ordem decrescente de prioridade de execução dos Address Spaces.
Métodos de Acesso e Blocagem
Descreveremos a seguir, nos próximos parágrafos, os principais tipos de Arquivos, disponíveis nos
Mainframes.
Chamamos de Método de Acesso o conjunto de Rotinas do Sistema Operacional que se incumbem de
tratar os Arquivos.

Ao contrário dos Arquivos da Plataforma Baixa, que não têm estrutura, ou seja, começam no primeiro
byte e terminam no último, os Arquivos do Mainframe têm uma estrutura.

São compostos fisicamente de “pedaços” chamados Blocos, que podem ter o mesmo tamanho (Fixos) ou
não (Variáveis). Cada Bloco, por sua vez, pode conter apenas um “pedaço” chamado Registro Lógico, ou
vários (diz-se que o arquivo é Blocado). Quando um Programa Aplicativo solicita uma leitura ou
gravação, é de um Registro Lógico, cabendo ao Método de Acesso fazer a Blocagem e a De-Blocagem,
além da Leitura ou Gravação.

O tamanho de um Arquivo (área de dados) inicial é determinado na criação do arquivo e pode haver uma
especificação de alocação secundária para até 15 extensões.

Métodos de Acesso: Organização Seqüencial

Método de Acesso Seqüencial: SAM (Sequential Access Method)

Os Blocos são gravados fisicamente por ordem de chegada (FIFO – First In First Out), daí o nome
Seqüenciais.
Adições podem ser feitas no final do arquivo (área gravada)
Alterações "in loco" podem ser feitas, sem alterar o tamanho
Deleções somente lógicas (não são possíveis fisicamente)
Exemplo típico: arquivos em Fita Magnética.
Métodos de Acesso: Organização Direta

Método de Acesso Direto: DAM (Direct Access Method)

Cada Registro tem uma chave de identificação, não há Blocagem.

Um algoritmo (“hashing”) converte essa chave numa localização física dentro do arquivo
Registros são gravados fisicamente conforme essa localização
Podem ocorrer sinônimos – O método usado deve resolver esse problema
Adições podem ser feitas e serão “encaixadas” segundo sua chave
Alterações podem ser feitas; A liberdade depende do método empregado
Deleções físicas podem ser feitas, eliminando assim o Registro
Apenas podem ser gravados em Disco Magnético, único dispositivo que permite o acesso a qualquer
localização física. Apesar desta habilidade, em um Disco também podem ser gravados Arquivos
Seqüenciais.

Métodos de Acesso: Organização Particionada

Método de Acesso Particionado: PAM Partitioned Access Method.

Arquivos particionados são também chamados PDS (Partitioned Data Sets) ou Bibliotecas (Libraries).
São compostos de uma parte inicial chamada Diretório, os dados propriamente ditos, chamados Membros
e um espaço livre ao final. O tamanho do Diretório é determinado no momento da criação do arquivo e
não pode ser expandido (outro tipo de Arquivo, chamado PDS-E, o permite).

Entradas no diretório, classificadas pelo nome do membro, apontam a localização física de seu início, na
área de dados
Membros são gravados seqüencialmente na área de dados, contígua ao diretório
Adições: novos membros são gravados a partir de onde começa o espaço livre, ampliando a área de dados
e reduzindo a área livre
Alterações: nova versão de um membro é gravada como uma adição, mas o espaço ocupado pela versão
anterior fica inacessível
Deleções: um membro pode ser deletado, mas o espaço ocupado por ele fica inacessível até ser
recuperado com um Utilitário.

Métodos de Acesso: Arquivos VSAM

Método de Acesso VSAM (Virtual Storage Access Method):
CI (Control Interval) é a entidade equivalente a um bloco físico, que o VSAM utiliza para transferir dados
entre memória e disco.

Tipos de arquivos VSAM:

ESDS - equivalente a um arquivo seqüencial

KSDS - cada registro tem uma chave de identificação (key); possui um índice para permitir acesso
direto por key; é equivalente a um tipo de arquivo direto
RRDS – cada registro tem um número de identificação que corresponde à sua posição no arquivo
LDS – o significado dos dados gravados nos CI destes arquivos depende do programa que os criou, o
VSAM não reconhece nenhuma estrutura neles

SRM (System Resources Manager)

O SRM (System Resources Manager) gerencia os recursos do Sistema (Processador, Memória e E/S),
distribuindo-os aos diversos Address Spaces em execução, a cada instante.
Por parâmetros do SRM, a instalação define o consumo esperado de recursos para cada tipo de serviço;
baseado nestes parâmetros e no consumo de recursos real (medido) de cada Address Space, o SRM
distribui recursos aos diversos Address Spaces, de modo que cada um receba sua quota.
O SRM procura balancear dois objetivos: atender a requisitos de desempenho para cada tipo de serviço, e
manter recursos ocupados ao máximo, para procurar obter uma produtividade máxima.
Para atingir esses objetivos, o SRM utiliza diversas técnicas; uma delas é o Swapping; outra é impedir a
criação de novos Address Spaces.
O SRM controla recursos exclusivamente no âmbito de um só Sistema, não foi objetivo do Projetista
explorar as várias imagens do Sysplex.
A linguagem de parâmetros do SRM era muito pouco amistosa..., e foi substituída pelo WLM, que
veremos a seguir.

WLM (WorkLoad Manager)

Para reduzir o impacto de algumas das limitações do SRM, o WLM (WorkLoad Manager) foi concebido
inicialmente para funcionar como uma interface com o SRM, objetivando balancear as cargas, a partir de
1.994.

Por meio de amistosos diálogos ISPF (IWMARIN0), podem ser feitas especificações quanto à definição
dos vários tipos de serviço, e ao desempenho que se espera que cada um venha a apresentar quando em
execução. O WLM se encarrega de prover a devida conversão dessas especificações para os parâmetros
internos que o SRM entende.

O WLM foi projetado para trabalhar em ambientes Sysplex, de modo que existe interação entre os WLM
que rodam em cada Imagem do Sysplex (“Bucket Broadcast”).
Este componente do z/OS é muito importante porque ele automatiza o balanceamento e a distribuição das
cargas entre as várias imagens do SysPlex a cada 10 segundos, tarefa esta difícil de ser executada por
seres humanos.

SMF (System Management Facility)

Para informar aos Usuários o que está acontecendo no Sistema, entra em cena o SMF (System
Management Facility), um componente que tem Address Space próprio.

Ele recebe informação dos demais componentes, quando certos eventos ocorrem, por exemplo: fim de um
serviço, término da leitura ou gravação de um arquivo, etc.
O SMF grava essa informação, formatada em registros de tipo específico para cada evento, nos seus
arquivos com nome genérico SYS1.MANx.
Esses arquivos são periodicamente acumulados em fita, pelo programa Utilitário IFASMFDP.
Quando um período se encerra (por exemplo, um mês, uma semana), programas de consolidação são
executados para gerar relatórios a partir dos registros acumulados neste período.

Esses relatórios constituem a ferramenta de contabilização do uso dos recursos da instalação: podem
informar a quantidade de recursos consumida por cada usuário, departamento, Aplicação, quantas vezes
foi executado cada Programa, quantos términos foram anormais, que tipos de erros são mais freqüentes,
etc.

RMF (Resource Measurement Facility)

O RMF é um dispositivo opcional. É um monitor de desempenho, uma janela para se visualizar
instantaneamente a utilização dos recursos do Sistema.
Este tipo de programa monitora, sob controle do usuário, áreas específicas do Sistema, visando a coleta de
dados relativos à utilização de recursos, permitindo deduzir qual é a performance.
O resultado dessa monitoração pode ser obtido em relatórios impressos, pode ser exibido em relatórios
formatados numa tela para o usuário, ou pode ser armazenado em arquivos em disco, permitindo análises
posteriores sobre períodos bem mais extensos.

O RMF pode coletar dados no nível de um Address Space, de um Sistema ou de um Sysplex inteiro,
fornecendo informação desde qualquer imagem de um Sysplex.
O Postprocessor permite obter relatórios mais abrangentes, colhidos sobre dados históricos relativos a um
período mais longo.
Com o Spreadsheet Converter, dados do RMF podem ser downloaded para uma estação de trabalho, para
serem processados por softwares de planilha eletrônica.
O Spreadsheet Reporter é uma interface baseada em Windows, na estação de trabalho, para analisar dados
do RMF com Lotus 1-2-3 ou Excel

O Mundo UNIX no Mainframe

Permitindo ao Mainframe executar Processos do mundo UNIX, o UNIX System Services (OS/390 e
z/OS) é o componente que suporta todos os padrões vigentes para Sistemas abertos (Posix, XPG,
XPG4.2) e, em 1.995, foi certificado como um Sistema X/Open UNIX 95. Possui dois elementos
principais:

Kernel:
Funções de Supervisor do UNIX, suporte a serviços de Sistema; a maioria das funções no BCP (Sistema
Operacional).
Funções de suporte ao file system hierárquico do UNIX; funções no DFSMSdfp
Application Services:
Shell & Utilities - fornece a interface padrão de comandos, familiar aos usuários UNIX
Debugger - fornece comandos que permitem a depuração interativa de um programa escrito em C; é
familiar a muitos usuários UNIX

Há dois Address Spaces de Sistema: OMVS e BPXOINIT

Cada usuário executa o Shell & Utilities em um Address Space próprio
Processos adicionais são rodados em Address Spaces adicionais
A produção de programas, naturalmente, é feita nas linguagens C e C++, mas os respectivos compiladores
não fazem parte dos Serviços UNIX, e sim dos Serviços de Habilitação de Aplicações do Mainframe

O Ambiente do Usuário
O ambiente Shell é criado em um Address Space, onde cada usuário trabalha, usando uma interface de
comandos que inclui:

Comandos - diretivas para serviços específicos

Utilitários - programas prontos que executam funções comuns
Programas - para executar serviços particulares
Scripts - arquivos texto contendo listas de comandos

Ferramentas de Desenvolvimento - para auxiliar o programador de Aplicações na elaboração de

programas
Debugger - para ajudar a depurar programass em C/C++
Shell & Utilities é um interpretador de comandos; alguns executam no Address Space onde roda a Shell,
outros disparam a execução de processos adicionais em Address Spaces externos.

O File System do UNIX

O Sistema de Arquivamento - File System - do UNIX é orientado para byte; é um Sistema de
arquivamento hierárquico (Hierarchical File System) onde cada arquivo é nomeado por um "pathname",

por exemplo:
/usr/prog/anne/file1

O comando MOUNT permite conectar um file system de usuário a um "mount point", um diretório vazio
em outro file system.
A implementação de um Hierarchical File System é feita, sob o OS/390, ocupando espaço em disco,
num arquivo do tipo HFS.
Um arquivo HFS, que contém um file system, é um arquivo do OS/390 gerenciado pelo SMS, cujo
conteúdo o OS/390 ignora; quem interpreta e reconhece seu conteúdo é o UNIX System Services.

MVS, OS/390 e z/OS

A evolução começou com os Sistemas Operacionais que suportavam arquiteturas de 24 bits (MVT);
depois, vieram os Sistemas Operacionais que suportavam 31 bits (MVS).

O OS/390 trouxe a idéia de um Sistema Servidor: era formado por uma coleção de produtos, agrupados
em torno de funções Servidoras definidas. No primeiro OS/390 V1.1, a missão de Sistema Operacional
básico foi entregue ao MVS/ESA V5.2.2, em seu estado da arte na época; produtos específicos lhe foram
agregados, formando um “pacote” Servidor para a arquitetura S/390.

O OS/390 evoluiu para o z/OS, suportando uma arquitetura de 64 bits; é a situação em que nos
encontramos. O último OS/390 é o 2.10 (release de transição), que suporta dois níveis de arquitetura, a de
31 bits e a de 64 bits, junto com o z/OS 1.1, mas somente no nível da memória Central; o tamanho limite
da memória Virtual (Address Spaces e outros espaços adicionais) ainda é limitado a 2 Gbytes (devido aos
31 bits).
Somente a partir do z/OS 1.2 a memória Virtual se estende até o limite de 64 bits da nova arquitetura z.

VM e z/VM

O propósito da Figura é ilustrar apenas algumas das possibilidades existentes. Como sabemos, uma
máquina física pode ser dividida em até 30 lógicas; aqui aparecem desenhadas apenas 5 LPARs, e em
cada uma delas pode-se colocar qualquer Sistema Operacional.
Na primeira, exemplificamos que pode estar um DOS/VSE ou o TPS (específico para Cias. Aéreas);
Na segunda, o microcódigo da Coupling Facility;
Na terceira um LINUX nativo;
Na quarta um z/OS ou OS/390 ou MVS (o último “release” saiu em 1.995!).
Na quinta e última, mostramos as possibilidades do VM ou z/VM.
Como o VM (ou z/VM) administra Sistemas Operacionais, podemos ter em baixo dele, isto é, dentro da
mesma LPAR, outros VM ou z/VM em até 5 níveis, em baixo dos quais podem estar alguns z/OS, por
exemplo! Ao lado do VM de segundo nível, podemos ter outros z/OS dando suporte ao Unix System
Server, e rodando processos Unix!
Ao lado deles, podemos definir centenas de LINUX independentes (são máquinas Virtuais), cada qual
rodando os seus Aplicativos!
Via parâmetros, o pessoal de Suporte pode dizer quanto de Memória, CPU e Canais cada LPAR receberá,
podendo compartilhar Processadores e Canais (Memória não), e pode pedir ao Micro-Código para
balancear estas cargas (IRD).

O que é um MONTADOR (Assembler)

Vamos agora definir alguns conceitos que envolvem Aplicativos, Compiladores e Linguagens de
Programação:
Dicionário AURÉLIO:

MONTAR vt 3: aprontar, armar para funcionar

MONTAGEM sf 2: Operação de reunir peças dum dispositivo, mecanismo, etc., de modo que funcione ou
preencha o seu fim.

MONTADOR: Monta as instruções, uma a uma, estando bem próximo da máquina física, daí ser
chamado de Linguagem de Baixo Nível. Em compensação, normalmente é o mais rápido das três opções.

MACRO: uma Macro pode gerar várias Instruções.

O que é um COMPILADOR
COMPILADOR: Cria o código necessário para cumprir o propósito da instrução da Linguagem de Alto
Nível.

Cada instrução, em COBOL por exemplo, gera “n” instruções de máquina, o que torna o código maior e
geralmente, mais lento do que o equivalente em Assembler

O que é um INTERPRETADOR

INTERPRETADOR: Chama as rotinas convenientes, já prontas, para realizar o que o Usuário deseja.
Normalmente é o mais lento dos três, porque a mesma instrução, se estiver em um “loop”, será
interpretada cada vez que for necessária.

Sua grande vantagem é que o código é executado assim que terminada a Edição, não havendo a etapa de
LinkEdição (ou Binder)

que é obrigatória para os dois anteriores.

Mais adiante, falaremos da Linguagem REXX, que possui Interpretador e Compilador, o Usuário decide
qual usar.
Visão Geral dos Módulos: FONTE, OBJETO e de CARGA

A figura apresenta as relações entre os diversos módulos:

FONTE: tal como foi escrito pelo programador;

OBJETO: já traduzido para instruções em linguagem de máquina, mas ainda não pode ser executado.
DE CARGA: com endereçamento e módulos reunidos e estruturados, prontos para a execução.

Arquivos e Atualização
Input, Process, Output é uma Abordagem Sistêmica dos processos.

Ao se resolver um Problema, normalmente um Programa que faz parte de uma Aplicação, lê (Input)
Arquivos de Detalhe com as Transações ocorridas (Compra, Venda, Saque, etc., com o número da Conta
do Cliente, ou nome, ou número da peça no Estoque, etc.), processa, isto é, consiste os dados para
conferir se a transação é legítima e, se for, grava (Output) a Base de Dados, que conterá a nova posição
atualizada dos Negócios, eventualmente produzindo Relatórios onde ficam registradas as mudanças
ocorridas, datas, etc.

É muito comum que os Arquivos gravados sejam lidos no próximo Ciclo de atualizações (que pode ser
diário, mensal, etc.). Alguns arquivos precisam estar Classificados (SORT), segundo algum campo Chave,
outros Intercalados (MERGE).
Objetos
Apenas para relembrar as características de Objetos:
Data Abstraction:
Só o Objeto conhece a Estrutura dos Dados
Outros Objetos só conhecem os Serviços
Inheritance:
Herda Estrutura e Processos da Classe/Super
Polymorphism:
Mesma mensagem, resultados diferentes
As instruções que processam os Dados chamam-se Métodos e os Dados que serão processados pelas
Instruções chamam-se Atributos, em cada Instância.

A Figura mostra que, no Mainframe, o Utilitário Linkage Editor apenas processa Programas comuns,
guardando-os em PDSs comuns. Apenas o Utilitário Binder consegue tratar, tanto Programas comuns
quanto Objetos mas estes têm que ser armazenados em arquivos do tipo PDS-E (a evolução dos arquivos
PDS, justamente com estrutura adequada para abrigar Objetos).

Estruturação do REXX
Aqui veremos uma pequeníssima amostra da Linguagem REXX. Uma Exec REXX (ou, um Programa na
Linguagem REXX) é sempre formada por um programa principal e pode englobar rotinas adicionais do
usuário, como funções e subrotinas.

Tanto o programa principal, como funções e subrotinas, são formados por codificação que se enquadra em
duas categorias:

Fornecida pelo REXX - inclui as instruções básicas da linguagem e funções embutidas, ou funções REXX
Fornecida pelo TSO/E - inclui as funções de manuseio do Data Stack e funções do TSO/E REXX
Nos manuais sobre REXX, as instruções e funções são geralmente abordadas em capítulos diferentes,
conforme a divisão acima.
Existem ainda códigos criados por Programadores de Sistemas ou de Aplicações, formado por funções e
subrotinas escritos em outras linguagens que não REXX (Assembler, por exemplo).
A Linguagem REXX é muito conhecida e utilizada por Profissionais de Mainframes, sendo fácil de se
usar e permitindo desenvolver rapidamente as mais variadas soluções, às vezes Aplicações inteiras.

Funções do JOB Entry Subsystem

Vamos agora examinar um pouco o SubSistema JES2. Criado especificamente para fazer o “spooling”
dos dados de entrada (SYSIN) bem como dos dados de saída (SYSOUT), acelerando desta maneira a
execução do job step e provendo flexibilidade para recuperação e envio dos resultados (localmente ou via
RJE e/ou NJE), o JES oferece meios de se obter informação e influir na execução da carga de trabalho,
seja individualmente ou por ação em grupos enfileirados de Jobs, tanto na entrada quanto na saída. Para
isto, vale-se de dois arquivos localizados no(s) SPOOL Volume(s) e no(s) CHECKPOINT(s). No
Processamento Batch, o JCL de um Job pode ser passado para o JES2 a partir de 3 fontes:
Submetido interativamente por usuário de TSO/E
Comando START na console do Operador
LOGON de usuário de TSO/E

As 6 fases de processamento de um Job serão detalhadas no Presencial. Em resumo:

O JES2 recebe o JCL do Job, registra o Job na Fila de Jobs, obtendo um número e grava o JCL junto com
eventuais arquivos de Sysin no SPOOL; o JCL é, então, verificado quanto a erros (Converter /
Interpreter).
A execução sempre ocorre fora do JES2, no Address Space de um Initiator Batch.
Após a execução, são agrupados os arquivos de Sysout do Job que tenham as mesmas características
(classe, formulário, destino, etc.).
A transcrição desses arquivos de Sysout para impressoras encerra o processamento, e o Job pode, então,
ser totalmente eliminado do Sistema.

Inicialização do JES2 (JES2PARM)

Vamos mostrar rapidamente, como o JES é inicializado. Através do Comando START do JES2
(normalmente automatizado na inicialização do z/OS) é invocada a “Procedure” correspondente, trazendo
para a memória os principais módulos que farão a inicialização dos arquivos segundo os parâmetros
especificados pelo pessoal de Suporte nos membros adequados da biblioteca SYS1.PARMLIB.
Com as especificações do membro JES2PARM e a modalidade de inicialização (COLD, WARM ou
HOT), o JES pode preparar seus arquivos para o início ou retomada dos trabalhos, após eventual
interrupção, adquirindo controle sobre os periféricos definidos para tal (leitoras, impressoras, linhas).

RJE: Remote JOB Entry

Na modalidade de Entrada Remota de Jobs, uma estação de trabalho remota tem os seus periféricos
conectados a uma Unidade de Controle de Comunicação (UCC) que, por sua vez, liga-se através de
canais de comunicação à unidade de Controle do CPD, usando o Address Space do VTAM como
“interface” para as funções RJE do JES.
Dessa maneira, é conseguida a cooperação entre os dois locais (às vezes usa-se Produtos como o T-BARR
para efetuar o controle) com o processamento e arquivos centralizados no CPD.

NJE: Network JOB Entry

Na modalidade de Entrada de Jobs através da Rede o processo é similar, apenas contando as duas pontas
do processo com Mainframes executando z/OS com JES e VTAM, ou MVS, ou OS/390, ou VM ou
DOS/VSE.
Com o comando de JES $G, pode-se observar e influenciar um serviço à distância, em outro nó da rede.
Os Comandos $M e $N permitem enviar comandos a outros membros de MAS (Multi Access Spool) e
nós de rede, respectivamente.
Diferenças para o JES3
Há duas características dignas de nota que diferenciam hoje os SubSistemas JES2 e JES3.

À esquerda na Figura acima, está representado um compartilhamento de SPOOL com imagens diferentes
de JES2 (que têm que estar no mesmo nível ou “release”). Todos os membros participam do processo
executando todas as suas funções.
À direita está representado o JES3 onde apenas uma das imagens é GLOBAL, sendo a única a receber
“input” e produzir “output”, além de administrar toda distribuição da carga aos LOCALs. Para isso, a
GLOBAL tem que fazer a etapa de Conversão.

SDSF System Display and Search Facility

O SDSF é um dispositivo opcional. É uma ferramenta para monitorar, gerenciar e controlar o Sistema;
roda como um diálogo ISPF, num Address Space de usuário TSO/E.
Oferece uma maneira fácil e eficiente de:

Controlar Jobs - colocar em Hold, liberar, cancelar e purgar;

monitorar Jobs ainda rodando e examinar sua saída, sem imprimi-la

Controlar recursos - impressoras, linhas e INITiators
Examinar o System Log de um Sistema e o Operations Log de um Sysplex.

Processamento Batch: Local e Remoto (RJE/NJE)

Jobs podem ser submetidos a partir de estações de trabalho remotas, onde tradicionalmente se usavam
terminais de RJE (Remote Job Entry).
Hoje em dia, nestas estações rodam-se programas que emulam os velhos terminais de RJE, como o T-
BARR, da BARR Systems.

Jobs também podem ser submetidos a partir de outros processadores centrais numa rede; estes
processadores podem estar rodando z/OS, OS/390, MVS, VM ou VSE, e esta possibilidade se chama NJE
(Network Job Entry).
O recurso RJE/NJE tem que ter sido ativado na definição do JES2 e, para ter acesso à Rede, é preciso
ativar o Address Space do VTAM, o Método de Acesso de comunicações do Sistema.

Processamento Interativo: TSO/E

No passado, usuários utilizavam terminais 3270 para se conectar ao Sistema central; com a proliferação
das estações de trabalho, os terminais 3270 foram sendo substituídos por equipamento tipo PC-
compatível, rodando programas emuladores de 3270.
Alguns programas de emulação de 3270 comumente usados são PComm (Personal Communications) da
IBM, o EXTRA da Attachmate Corporation, e o RUMBA da Wall Data Incorporation.

Quando o usuário faz um LOGON de TSO/E na Rede, este comando é recebido pelo VTAM (Virtual
Telecommunications Access Method). O VTAM interage com o Address Space TSO, para processar o
Logon do usuário e criar um Address Space para o usuário, com o nome do seu User-id de TSO/E.
Estabelecida a comunicação direta entre o VTAM e o Address Space do usuário, este pode entrar
comandos, interpretados e executados em seu próprio Address Space, para editar arquivos, submeter jobs,
examinar sysouts, executar programas, etc... Quando o usuário faz Logoff, o seu Address Space é
eliminado

Processamento Interativo: ROSCOE

O processamento interativo de um usuário, como vimos, gira em torno de editar arquivos, submeter jobs,
examinar sysouts e executar programas específicos.
Em muitos ambientes de desenvolvimento e produção, usa-se como ferramenta para o usuário o
ROSCOE, da CA – Computer Associates, um produto que consiste de um misto de painéis e comandos.
Estruturalmente diferente do TSO/E (que é componente do Sistema),o ROSCOE roda num único Address
Space do tipo STC (ativado por um comando START a partir da Console do Sistema), dentro do qual é
realizado o processamento de todos os Usuários.

Processamento de Transações: CICS ou IMS

Observe que este é o primeiro exemplo, em que quem dispara a transação é um Cliente qualquer,
solicitando um Extrato, e não um funcionário do CPD.
Nos casos em que diversos usuários efetuam processamento de transações, todos estarão conectados a
uma só Aplicação: o programa gerenciador de transações. Então, além do VTAM para dar acesso à Rede,
deverá estar ativo também o Address Space desse programa gerenciador de transações.
Dependendo da sua estrutura interna e parâmetros, o programa gerenciador de transações pode ocupar um
único Address Space, ou ter funções distribuídas em mais de um Address Space.

A figura mostra uma configuração com o CICS/TS (Customer Information Control System - Transaction
Server) ou com o IMS/TM (Information Management System - Transaction Manager), usando mais de
um Address Space para processar suas transações, que podem atingir 36 milhões por dia!
Se o processamento da transação acessa um bancos de dados, o correspondente gerenciador de banco de
dados (DBMS – Data Base Management System) deverá ser acionado e, tipicamente, estará ocupando
seu(s) próprio(s) Address Space(s). A figura mostra alguns possíveis gerenciadores de bancos de dados,
como o DB2 e o IMS/DB da IBM e o Adabas da Software AG; mas são usados, também, o Oracle da
Oracle Corporation, e o IDMS da CA – Computer Associates.

Placas/Canais OSA

Entendamos agora como o Mainframe pode se conectar diretamente à Rede. Empresas possuíam Redes
Locais e gostariam de ligá-las aos Mainframes sem incorrer no custo de Media Access Control e portas
das controladoras 3172; foram criadas então as Placas Open Systems Adapter com os propósitos de:
Conectar redes locais diretamente ao Mainframe, sem controladora externa;
Atuar como Servidor de Rede Novell Netware (OSA tipo 1, já descontinuada).

Como as Placas se encaixam em soquetes existentes dentro do CEC, são de fácil conexão e representam
menor custo do que as opções tradicionais. Sua configuração é feita através do Address Space OSA/SF ou
de uma estação de trabalho com OS/2.

A Placa OSA1 (descontinuada) permitia emular Servidor, fazer “offload” do código do TCP/IP,
suportar LANRES e Cache do Network File System.
A Placa OSA2 permite fazer “Passthru” de SNA/APPN e TCP/IP, possibilitando a conexão em
Assinchronous Transfer Mode, além de FDDI, Token Ring e Ethernet (Fast e Gigabit).

DCE Distributed Computing Environment

A arquitetura DCE foi desenvolvida pela OSF (Open Software Foundation) em conjunto com diversos
fabricantes, e adotada no OS/390 e z/OS.
Uma Aplicação pode ser projetada em duas partes: uma parte Cliente, que solicita serviços, e uma parte
Servidora, que os provê. Em cada máquina que participa de uma rede DCE deve rodar um código básico
DCE, que faz a interface das Aplicações DCE com Serviços DCE e com o software de rede.
Isto permite que uma Aplicação Servidora seja localizada, independente da máquina em que está
executando, e acessada de forma transparente para a Aplicação Cliente. O efeito final é que a Aplicação
Cliente e a Aplicação Servidora parecem estar em comunicação direta.

Célula DCE

Uma Célula DCE é uma entidade administrativa que agrega diversas máquinas, todas rodando o código
básico DCE, chamado RPC (Remote Procedure Call). Uma célula DCE deve agregar todos os Servidores
dos serviços básicos da arquitetura:

Servidor de Diretório - para localização de Aplicações Servidoras

Servidor de Segurança - para autenticação de Aplicações e auxílio

na autorização de acesso a recursos

Servidor de Tempo - para sincronizar os clocks das várias máquinas numa rede DCE

Células podem estar conectadas a outras células por meio de máquinas participantes da célula, que
assumam o papel de roteadores. O componente DCE Base Services é um elemento básico; fornece os
serviços para desenvolver e rodar Aplicações Cliente/Servidor, incluindo código RPC e o serviços de
Diretório, Segurança e Tempo.

Serviços de Computação Distribuída

Esta Figura permite avaliar como tudo se integra através do DCE. Mainframes, Servidores e Micros, estão
totalmente integrados através das Redes WAN e LAN, permitindo que máquinas de qualquer fabricante
comuniquem-se com Softwares de qualquer provedor, cujo detalhamento faremos no último módulo de
Soluções deste Curso.
Para o Mainframe, nos Sistemas Operacionais z/OS, temos:

Serviços de Computação Distribuída (Elementos Básicos)

DCE Base Services - OSF DCE nível 1.1
DFS (Distributed File Service) - OSF DCE nível 1.2.2

NFS (Network File System)

Serviços de Computação Distribuída (Dispositivos Opcionais)
InfoPrint Server for OS/390 (inclui OS/390 Print Interface, Windows 95/NT Client, IP PrintWay,
NetSpool)

Segurança no Sistema Central

O componente RACF (Resource Access and Control Facility) está contido no Servidor de Segurança,
que é dispositivo opcional.
A missão do RACF é a segurança no âmbito do Sistema Central; tem Banco de Dados próprio, com
informação para desempenhar as seguintes funções principais:
Identificação do Usuário – para permitir (ou não) acesso do usuário ao Sistema
Controle do Acesso – para permitir (ou não) acesso a recursos protegidos do Sistema, como arquivos,
programas, transações, volumes e terminais
Registrar e Relatar – para rastrear, registrar e relatar tentativas de acesso indevido
Como veremos a seguir, por ser componente do OS/390 e do z/OS, o RACF tem interoperabilidade com
outros componentes.
Outro software de segurança usado no mercado é o TopSecret, da CA - Computer Associates.

Segurança no Ambiente DCE

O componente DCE Security Server está contido no Servidor de Segurança, que é dispositivo opcional.
DCE Security Server acessa um Banco de Dados de Registro DCE, onde o Administrador de Segurança
registra todos os "principals", como são chamados os Usuários e Aplicações da Rede DCE.
Quando um usuário faz Login ou uma Aplicação é ativada, ambos se apresentam ao Servidor de
Segurança, e este efetua um processo de autenticação.

A Aplicação, em seguida, se dirige novamente ao Servidor de Segurança para requisitar um certificado de

privilégios, com o qual se dirigirá a uma dada Aplicação Servidora.
O Servidor de Segurança fornece um bilhete criptografado, que tem validade por um determinado tempo,
e, com este bilhete, a Aplicação Cliente se dirige à Aplicação Servidora.
A Aplicação Servidora decriptografa o bilhete, identifica o Cliente requisitante, e autoriza (ou não) o
acesso aos recursos solicitados.
Interoperabilidade RACF / DCE
RACF e DCE Security Server são integrados, pois são componentes do z/OS e do OS/390.
A interoperabilidade entre o RACF e o DCE é necessária, pois é preciso haver uma correspondência entre
User-ids de RACF e principals de DCE, uma vez que um não substitui o outro.
Vejamos dois cenários possíveis:
Um usuário faz Login na Rede DCE e requisita uma Aplicação Servidora que roda sob o z/OS – é preciso
um User-id RACF, para controlar o acesso a recursos.
Um Usuário faz Logon no TSO/E, é autenticado pelo RACF, e requisita uma Aplicação Servidora na
Rede DCE – é preciso um principal DCE, para ser autenticado antes do acesso à rede e a recursos DCE.
A interoperabilidade entre RACF e DCE permite Sign-On único.

Segurança na Computação em Rede

Por último e ainda na área de Segurança, vejamos o Componente Firewall Technologies, que está
contido no Servidor de Segurança, que é dispositivo opcional. Lembre-se de que Segurança é um dos
pontos fortes do Mainframe.
Firewall (parede corta-fogo) é uma barreira entre uma rede privada interna, considerada segura, e uma
outra rede, externa e não segura, ou a Internet.

Sua finalidade é prevenir comunicação não autorizada para dentro ou para fora da rede interna segura.
Quando usado, está no “host” que oferece o ponto de contato único entre a rede interna e a rede externa.
Diversas técnicas, como filtros de endereços e pacotes, Servidores especiais e outras, podem ser usadas
no “host” que abriga o Firewall, para implementar a proteção desejada e constituem a essência do
componente Firewall Technologies.

Leitura Módulo 2 - finalizada

Neste segundo Módulo você pôde conhecer mais profundamente os Mainframes, sua arquitetura interna,
mecanismos de armazenamento e processamento da informação, dentre outros aspectos.

Esse conjunto de informações permitirá a você, quando unido aos conteúdos dos demais Módulos,
compor uma visão abrangente acerca das soluções que podem ser desenvolvidas utilizando-se as
diferentes tecnologias de computação. Esta visão será posteriormente utilizada como a base para a etapa
presencial deste curso.

Para ter acesso ao conteúdo do Módulo 3, realize sua Avaliação, acessível a partir da página inicial do
presente Módulo.