IBM zOS Basics

1.936 visualizações

Publicada em

Conceitos básicos de Mainframe zOS com base no redbook SG24-6366-02

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.936
No SlideShare
0
A partir de incorporações
0
Número de incorporações
10
Ações
Compartilhamentos
0
Downloads
69
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • z/OS é um sistema Operacional desenvolvido para um servidor corporativo integrado.
    Incorpora em um único produto: servidor de comunicação, serviços, suporte ao sistema Sysplex, POO, (DCE) Distributed Computer Environment, ambiente computacional distribuído, e interface de aplicação aberta.
    Especialmente adequado para integrar hoje ambientes heterogêneos e de múltiplos
    fornecedores.
    Embora seu nome seja z/OS, incorpora o sistema operacional base MVS e continua
    sendo construído sobre os pontes fortes clássicos do MVS: Confiabilidade, características de disponibilidade continua, e segurança. Isso fornece um sistema escalável com suporte a grande volume de transações com grandes números de usuários com alto desempenho, um avançado sistema e gerenciamento de rede, segurança, e disponibilidade 24/7.
    Juntos, IBM System z e z/OS oferecem recursos projetados para reduzir a complexidade de TI e aumentar a flexibilidade do negocio reduzindo custos.
  • Serviços de gestão de programas que lhe permitem criar, carregar, modificar, listar, ler e copiar programas executáveis.
    Fornece soluções para as seguintes áreas principais:
    Data management: Conjunto de funções para gerenciamento de dados;
    Softcopy publications services: Melhora a produtividade na instalação e gerenciamento de sistemas.
    Security services: Conjunto de produtos e funcionalidades usados para segurança.
    System management services: Controle robusto e automação em gerenciamento de sistemas.
    Network communication services: suporte de rede
    Applications enablement services: infra-estrutura sólida na qual você pode construir aplicações, estender aplicações existentes e executar OLTP e processos batch.
    z/OS UNIX System Services: contém os serviços de aplicações e do sistema UNIX
    Distributed computing services: Conjunto de características e funções como servidor de arquivos, habilitação de algoritmos de data encryption standard (DES) e commercial data masking facility (CDMF), serviços de arquivos distribuídos (DFS) SMB
    e-Business services: HTTP Server, serviço web para aplicações de e-business críticas.
    Print services: Serviços de impressão.
    OS/390.
    Havia dez versões do OS/390, com um novo lançamento enviados a cada seis meses.
    z/OS (número do programa 5694-A01), a próxima geração do sistema operacional System
    z, permite-lhe gerir a volatilidade da carga de trabalho de e-business. Oferece as mais
    altas qualidades de serviço para transações empresariais e de dados, e se estende essas
    qualidades para novas aplicações utilizando as mais recentes tecnologias de software.
    Um dos destaques do z/OS é o 64-bit z/Architecture implementada pelo z/OS e
    processadores IBM System z, o que elimina gargalos associados à falta de memória
    endereçável.
    O suporte de armazenamento de 64-bit real (central) elimina o armazenamento
    expandido, ajuda a eliminar paginação, e pode permitir você a consolidar seus sistemas
    atuais em menos partições lógicas (LPARs) ou a uma única imagem nativa.
  • Software and hardware evolution
    Com a introdução dos servidores paralelos S/390 em 1994, o mainframe foi revivido. A CMOS oferece poder de computação de mainframe a um custo menor. As zSeries CMOS podem se conectar com outros zSeries e S/390 CMOS ou até mesmo a tradicional ES/9000 para formar um Sysplex Paralelo. Essa transformação de hardware de mainframe, juntamente com os requisitos de negócio para TI, são as forças motrizes por trás das mudanças no sistema operacional. E em 2001, o sistema z/OS foi apresentado como o sistema operacional do servidor zSeries.

    z/Architecture
    z/Architecture é o próximo passo na evolução do System/360 ao System/370, System/370 (370-XA), Architecture/370 (ESA/370) e Enterprise Systems Architecture/390 (ESA/390). Inclui todas as instalações do ESA/390 exceto para asynchronous-pageout, asynchronous-data-mover, program-call-fast e instalações vetoriais. Também proporciona extensões significativas, como se segue:
    • Registos gerais de 64 bits e registradores de controle.
    • Um modo de endereçamento de 64 bits, além dos modos de endereçamento de 24 bits e de 31 bits do ESA/390, que são transportados a z/Architecture.
    Ambos os endereços de operando e endereços de instrução podem ser endereços de 64 bits. A program-status word (PSW) é expandida para 16 bytes para conter o endereço de instrução maior. A PSW contém também um bit recém-atribuído que especifica o modo de endereçamento de 64 bits.
    • Até três níveis adicionais de tabelas dynamic-address-translation (DAT), região de tabelas chamadas, para traduzir os endereços virtuais de 64 bits.
    Um espaço de endereço virtual pode ser especificado por uma segment-table, como no ESA/390, ou por uma region-table, e qualquer um destes tipos de designação é chamado um address-space-control element (ASCE). Uma ASCE pode alternativamente ser um real-space que faz com que os endereços virtuais sejam tratados simplesmente como endereços reais sem o uso de tabelas DAT.
    • 8 K-byte para conter PSWs novos e antigos maiores e register save areas.
    • Muitas das novas instruções, muitas das quais operam em inteiros binários de 64 bits.
  • z/OS operating systems and hardware
    z/OS V1R12 pode ser executado em qualquer Servidor IBM System z (z196, z10 ™ CE, z10 BC, z9 EC, z9 BC, e z990).
    z/OS and workloads
    A melhor plataforma para a integração de processamento de transações baseado na web, e-business, e aplicações empresariais e servidores de banco de dados é z/OS no zSeries, a principal plataforma para cargas de trabalho em escala empresarial.
  • Hardware requirements
    A base do sistema operacional z/OS é executada em um processador e reside no armazenamento do processador durante a execução.
    O hardware é composto pelos processadores e outros dispositivos, como um direct access storage device (DASD), fita e consoles. Tape e DASD são usados para funções do sistema e por programas de usuários que executam em um ambiente z/OS. Quando você pede um z/OS, você o recebe em cartuchos de fita. Quando você instalar o sistema a partir da fita, o código do sistema é, então, armazenado em volumes de DASD. Depois o sistema é personalizado e preparado para a operação, consoles são necessários para
    iniciar e operar o sistema z/OS. Unidades de controle ligam o processador a outra fita, DASD, e os consoles. Os principais conceitos são:
    • Software: O sistema operacional z/OS consiste em módulos de carga e é muitas vezes chamado código executável. Estes módulos de carga são colocados em volumes DASD em bibliotecas durante um processo de instalação do sistema.
    • Hardware: Consiste de todos os dispositivos, controladores e processadores que compõem um complexo z/OS.
    • Dispositivos: Fita, DASD, e os consoles. “Existem mais.”
    • Armazenamento: Armazenamento Central, muitas vezes chamado de armazenamento real ou principal, onde o z/OS executa. Além disso, todos os programas de usuário partilham o armazenamento do processador com o sistema operacional
  • Basic mode and LPAR mode
    O hardware pode ser utilizada em dois modos:
    Modo LPAR: Modo Logicamente Particionado (LPAR - Logically partitioned) é um processador central (CP) modo Power-on Reset que permite o uso do recurso do processador / System Manager (PR / SM ™) e permite a um operador alocar recursos de hardware do PC (incluindo o processador central, a memória principal, e os caminhos de canal), entre várias partições lógicas (LPs). O z/OS é executado em cada LPAR na máquina com todos os recursos do servidor (CPs, armazenamento e canais).
    Modo básico: Este é um modo de processador central, que não usa particionamento lógico, com o CP executando uma cópia do z/OS.
    Quando um servidor está no modo básico, todos os recursos do servidor (Cps, armazenamento e canais) são disponíveis a um sistema operacional. Todos os Cps físicos são utilizados no modo dedicado para o sistema. Qualquer recurso CP em excesso é desperdiçado, porque nenhum outro sistema tem acesso a ela.
    Ainda existem situações em que os servidores são executados em modo básico (por exemplo, se o z/OS precisa utilizar toda a capacidade do servidor). No entanto, por causa da enorme capacidade dos servidores modernos, isso está se tornando menos comum.
  • O sistema z/OS é constituído por elementos de base que fornecem funções operacionais essenciais, além dos serviços prestados pelas funções do BCP como suporte de comunicação, acesso on-line, host graphics, e visualização on-line de publicações.
    Elementos básicos podem ser ativados e desativados dinamicamente, porque o cliente pode optar por usar um produto do fornecedor em vez de produtos IBM.
    O z/OS consiste de uma coleção de funções que são chamados elementos de base e elementos opcionais. Os elementos opcionais (características) são integrados ou não integrados. Estas opcionais características, tanto integradas e não integradas, são também testadas como parte da integração do sistema inteiro.
  • Além dos elementos básicos, o z/OS tem recursos opcionais que estão intimamente relacionados com as características de base. Os recursos opcionais estão ordenáveis com z/OS e fornecem funções adicionais do sistema operacional.
    São Unpriced, enviados para você apenas se você encomendá-los, ou Priced, sempre enviados.
  • A espinha dorsal do z/OS é o MVS base control program (BCP), com JES2 ou JES3 como um subsistema de entrada de trabalho principal. Estes fornecem os serviços essenciais que fazem do z/OS o sistema escolhido quando você precisa para processar suas cargas de trabalho de forma confiável, de forma segura, com integridade de dados completa e sem interrupção.
  • Computer security
    Devido ao aumento de pessoas que usam computador e de conhecimentos de informática em geral, a necessidade de segurança de dados assumiu um novo patamar de importância.

    RACF component
    É um componente do z/OS Security Server, e ele trabalha em conjunto com as características existentes do z/OS para proporcionar maior segurança de dados para uma
    instalação.

    RACF security protection
    Utiliza um ID de usuário localizado em um perfil de usuário no banco de dados RACF e uma senha ou frase criptografada para realizar a identificação e verificação do usuário.

    RACF authorization checks
    Autoriza não só que recursos o usuário pode acessar, mas também de que forma o usuário pode acessá-los, tais como, somente leitura, ou para atualizar e ler.
  • DFSMS component
    DFSMS é um ambiente operacional que ajuda a automatizar e centralizar o gerenciamento de armazenamento com base nas políticas na sua instalação definida em disponibilidade, desempenho, espaço e segurança.
    O coração de DFSMS é o Storage Management Subsystem (SMS).
    DFSMS é uma família de produtos, cada uma com funções específicas. Os produtos e funções são os seguintes:
    • DFSMSdfp: Data Facility Product (dfp)
    • DFSMSdss: Data Set Services (dss)
    • DFSMShsm: Hierarchical Storage Manager (hsm)
    • DFSMSrmm: Removable Media Manager (rmm)
    • DFSMStvs: Transactional VSAM Services (tvs)

    Network File System (NFS)
    É um sistema de arquivo distribuído, que permite aos usuários acessar arquivos UNIX e diretórios que estão localizados em computadores remotos como se fossem locais.
  • DFSMS and XRC
    Fornece funções de fazer cópias de dados de produção para o propósito de continuidade de negócios. Fornece uma capacidade de cópia remota a distância estendida Extended Remote Copy (XRC).
    Extended Remote Copy (XRC)
    Fornece cópia remota assíncrona (espelho) de dados críticos em longas distâncias para um segundo local remoto com um impacto mínimo.
    Peer-to-Peer Remote Copy (PPRC)
    É uma solução de hardware para recuperação de desastre rápida e precisa, e uma solução para carga de trabalho e migração DASD.
  • Communications Server
    z/OS Communications Server fornece um conjunto de protocolos de comunicação que suportam funções de conectividade peer-to-peer para ambas as redes locais e redes de área ampla, incluindo a rede de área ampla de maioria popular, a Internet.
    TCP/IP
    Transmission Control Protocol/Internet Protocol (TCP/IP) é um conjunto de protocolos e aplicações que permitem a realização de certas funções do computador de uma maneira semelhante independente dos tipos de computadores ou as redes a serem utilizadas.
    Computer network
    É um grupo de nós de computador eletronicamente ligados por um meio de comunicação.
  • System Modification Program Extended (SMP/E)
    É uma ferramenta de software projetado para gerenciar a instalação de produtos de software em seu sistema z/OS, e para acompanhar as modificações aplicadas a esses Produtos.
    Em um z/OS , um módulo de carregamento representa a unidade básica de código executável. Os módulos de carregamento são criados pela combinação de um ou mais módulos de objetos e o processamento com um utilitário de edição de link. Edição de Link de módulos é um processo que resolve referências externas e endereços . Funções em um sistema, portanto , são um ou mais módulos de objetos que foram combinados e o link editado.
    PTFs
    Quando um problema com um elemento de software é descoberto, a IBM fornece aos seus clientes com uma correção testada para corrigir esse problema. Esta correção vem na forma de uma program temporary fix (PTF).
    CSI data sets
    Contem todas as informações que o SMP/E precisa controlar a distribuição e bibliotecas alvo. As entradas CSI contem o nome do elemento, o tipo, a história, a forma como o elemento foi introduzido no sistema, e um ponteiro para o elemento de distribuição e bibliotecas alvo. Em adição à distribuição e zonas-alvo, o SMP/E CSI também contém uma região global.
    Installing service
    Serviço corretivo instalado nas bibliotecas alvo.
  • Time Sharing Option/Extended (TSO/E)
    É um elemento básico do sistema operacional z/OS que permite aos usuários trabalhar de forma interativa com o sistema.
    TSO/E environments
    • Line Mode TSO/E: Isso envolve o uso de comandos TSO/E digitados em um terminal, uma linha de uma vez.
    • ISPF/PDF: O Interactive System Productivity Facility (ISPF) o os seus Program Development Facility (ISPF/PDF) trabalham em conjunto com TSO/E para fornecer painéis com os quais os usuários podem interagir.
    • Information Center facility: Um conjunto de painéis que permitem exibir serviços como e-mail e nomes de diretórios, realizar análise de dados e preparar documentos, tais como relatórios, gráficos e tabelas.
    CLIST language
    É uma linguagem de programação de alto nível que permite que os programadores emitem listas de comandos TSO/E e extratos JCL em combinação com lógica, aritmética e funções de manipulação de string fornecida pela linguagem.
    REXX EXECs
    É uma linguagem de programação que é extremamente versátil. Aspectos como estrutura comum de programação, legibilidade e formato livre torná-a uma linguagem útil para iniciantes e usuários em geral.
    TSO/E commands and programs
    Linguagens de programação comuns usados sob TSO/E incluem assembler, COBOL, Fortran, Pascal, PL / I, REXX e CLIST. REXX e CLIST (Lista de comandos) são linguagens de programação de interpretação de alto nível que lhe permitem combinar comandos TSO/E com as declarações de linguagem.
    Os seguintes comandos podem ser usados para compilar ou montar declarações fonte escritos em várias línguas:
    • ASM command
    • COBOL command
    • FORT command
    • PLI command
  • z/OS UNIX System Services (z/OS UNIX)
    Começando com OS/390 V2R4, z/OS UNIX System Services foi mesclado com o BCP e agora faz parte do BCP FMID.
    ISPF shell
    É uma interface de painel que você pode usar em vez de comandos TSO/E ou comandos shell para executar determinadas tarefas.
    HFS and zFS
    Em sistemas operacionais atuais z/OS, tanto o HFS e ZFS PFSS pode ser usado para acessar os dados do sistema de arquivos. z/OS UNIX kernel
    O espaço de endereçamento do kernel contém o suporte MVS para serviços UNIX z/OS.
    ISHELL or OMVS shell
    Usuários interativos de z/OS UNIX tem uma escolha entre o uso de uma interface UNIXlike (o shell), uma interface de TSO (comandos TSO) e uma interface ISPF (diálogo ISPF CUA).
    z/OS UNIX dbx debugger
    É uma ferramenta interativa para depuração de programas em linguagem C que usam z/OS UNIX.
  • Shell and utilities
    • Comando TSO/E para entrar no ambiente shell
    • Ambiente shell para o desenvolvimento e execução de aplicativos
    • Utilitários para administrar e desenvolver em um ambiente UNIX z/OS UNIX interactions with z/OS
    • C/C++ Compiler, para compilar programas
    • Language Environment , para executar o shell e utilitários
    • Data Facility Storage Management Subsystem para acessar HFS / arquivos ZFS
    • z/OS Security Server
    • Resource Measurement Facility (RMF)
    • System Display and Search Facility (SDSF)
    • Time Sharing Option Extensions (TSO/E)
    • Serviços TCP/IP
    • ISPF, para usar as caixas de diálogo para OEDIT ou ISPF / PDF para o shell ISPF
    • BookManager READ, para usar o OHELP recurso de ajuda on-line
  • z/OS UNIX physical file systems
    É um pacote como módulos de carregamento de um ou mais MVS.
    PFS interface
    É um conjunto de protocolos e interfaces de chamadas entre LFS e os PFSS que estão instalados no z/OS UNIX.
    Existem dois tipos de PFSS, aqueles que gerenciam arquivos e aqueles que gerenciam soquetes, como:
    • File management PFSs, como HFS e ZFS, lidam com objetos que têm path names e que geralmente seguem a semântica de arquivos POSIX.
    • Socket PFSs lidam com objetos que são criados pelo socket () e accept () e funções que seguem semântica soquete.
    HFS-to-zFS migration
    Como a IBM anunciou a estabilização da HFS PFS, a migração de sistemas de arquivos HFS (ambos montados e desmontados) para sistemas de arquivos ZFS deve ocorrer ao longo do tempo.
    Advantages of zFS
    Como HFS, o ZFS é um sistema de arquivos UNIX. Ele contém os arquivos e diretórios que podem ser acessados com as APIs disponíveis para HFS. Em geral, a visualização do aplicativo do ZFS é o mesmo ponto de vista de aplicação HFS. Depois que um sistema de arquivos ZFS é montado, é quase indistinguível de qualquer outra HFS montada.
  • System Management Facility (SMF)
    Grava no conjunto de dados SYS1.MANxx, informações de sistema de dados e relacionadas ao trabalho que a sua instalação pode usar em:
    • Billing de usuários
    • Reporting de confiabilidade
    • Analise de configuração
    • Agendamento de jobs
    • Resumo do volume de atividade de acesso direto
    • Avaliação de atividade do conjunto de dados
    • Perfil de uso dos recursos do sistema
    • Manutenção e auditoria de segurança do sistema
    SMF data collection
    A coleta de dados é executada por várias rotinas específicas espalhados por todo z/OS e outros produtos. Esta coleção é feita em registros relacionados ao sistema ou relacionada ao trabalho.
    Installation SMF routines
    Uma instalação pode fornecer suas próprias rotinas, como parte do SMF. Estas rotinas receberão controle seja em um determinado ponto em que um job se move através do sistema, ou quando um evento específico ocorre.
  • Resource Measurement Facility (RMF)
    RMF reúne dados de desempenho usando três monitores:
    • Coleta de dados de curto prazo com o Monitor III
    • Monitoramento instantâneo com o Monitor II
    • Dados a longo prazo coletados com o Monitor I
    SMF records
    Os dados são coletados por um tempo do ciclo específico, e os registros de dados consolidados são escritos (geralmente como registos SMF) a um intervalo de tempo específico. O valor padrão para a coleta de dados é de um segundo e para os dados de gravação é de 30 minutos.
    RMF Monitor I, II and III
    Monitor I coleta dados a longo prazo sobre a carga de trabalho do sistema e utilização de recursos, e abrange todos os componentes de hardware e software de seu sistema: processador, dispositivos de armazenamento e utilização e atividades de I/O, juntamente com o consumo de recursos, atividade e desempenho dos grupos de espaços de endereçamento.
    Monitor II simplesmente tem snapshots de certos domínios-chave do z/OS.
    Monitor III utiliza o conceito de Análise de Contenção (espaço de endereço, address space, usado e estados de atraso) para a recolha de dados. Um espaço de endereço é um conjunto de endereços virtuais que um programa pode consultar. No z/OS, cada conjunto de programas logicamente relacionados compartilham o mesmo espaço de endereço que contenha até endereços de 2G.
  • Workload management
    Antes da introdução do Workload Manager (WLM), a única maneira de informar o z/OS sobre seu objetivo de negócio (como o tempo de resposta da transação) foi traduzir a partir de objetivos de alto nível sobre qual transação precisa ser feita em termos extremamente técnicos que o sistema pode compreender
    WLM goal mode
    Quando em goal mode a operação do sistema, o WLM fornece menores, mais simples, e mais externas consistências do sistema que refletem metas para as operações expressas em termos comumente usados em objetivos de negócios, e recursos de correspondência WLM (definindo prioridades em filas de recursos) para atingir essas metas com monitoramento constante e adaptação do sistema.
    Subsystems using WLM
    MVS workload management oferece uma solução para o gerenciamento de distribuição de carga de trabalho, balanceamento de carga de trabalho e distribuição de recursos para as cargas de trabalho concorrentes. MVS workload management é a cooperação conjunta de vários subsistemas (CICS, IMS/ESA®, JES, APPC, TSO/E, z/OS UNIX System Services, DDF, DB2®, SOM, LSFM, e Internet Connection Server) com o componente MVS workload management (WLM).
    WLM service policy
    Workload management fornece uma nova externa gestão de desempenho MVS em uma política de serviço que reflete os objetivos para o trabalho, expressos em termos comumente usados em acordos de nível de serviço (SLAs).
  • Infoprint Server overview
    É um aplicativo UNIX que utiliza z/OS UNIX System Services. Esta característica é a base de uma total solução de servidor de impressão para o ambiente de z/OS em uma rede TCP / IP.
    Print Interface: É o componente do Infoprint Server que processa solicitações de impressão recebidas de clientes remotos e usuários locais.
    IP PrintWay: É o componente do Infoprint Server que transmite conjunto de dados de saída a partir do spool JES2 ou JES3 para impressoras de rede, ou para outros sistemas host em sua rede TCP / IP.
    NetSpool: Intercepta impressões de dados a partir de aplicações VTAM, tais como CICS e IMS; transforma os fluxos de dados para dados de linha EBCDIC, PCL, PDF ou outros formatos que a impressora de destino aceita, e escreve o conjunto de dados de saída para o spool JES.
    Infoprint Central: É um sistema de gerenciamento de impressão baseado na web, principalmente para os operadores de help desk. No entanto, outros usuários autorizados ou remetentes de trabalho também podem usá-lo.
    Com Infoprint Central, você pode:
    • Trabalhar com as tarefas de impressão
    • Trabalhar com impressoras
    • Trabalhar com unidades lógicas NetSpool (LUs)
    • Visualizar definições da impressora
    • Verificar o estado do sistema
  • z/OSMF
    É uma nova função de gerenciamento do sistema central para z/OS e é projetado para fornecer as melhores ferramentas para o gerenciamento de sistemas e system programmers ajudando-o a ser mais produtivo.
    Oferece uma estrutura para o gerenciamento de vários aspectos dos sistemas z/OS através de uma intuitiva interface de usuário do navegador da Web 2.0 e as novas tecnologias facilitadoras no z/OS.
    Related system components
    Estruturalmente, z/OSMF é um conjunto de aplicações web hospedadas em seu sistema z/OS. Dependendo da tarefa de gestão do sistema para ser executada, as interfaces z/OSMF com outros componentes z/OS oferecem uma interface simplificada para a realização de tarefas.
    z/OSMF é fornecido com os seguintes programas:
    Dojo: Dojo visa resolver vários problemas históricos de longa data com DHTML que impediram a adoção em massa de desenvolvimento de aplicações web dinâmica. Dojo permite que você crie facilmente capacidades dinâmica em páginas da web e qualquer outro ambiente que suporta JavaScript. Use os componentes que o Dojo fornece para fazer sites mais úteis, ágeis e funcionais.
    WebSphere: IBM WebSphere Application Server OEM Edition para z/OS é um produto que fornece o ambiente de tempo de execução para a gestão do sistema de aplicações.
    Quando em funcionamento, z/OSMF utiliza os serviços prestados pelos seguintes componentes z/OS:
    - CIM: O servidor Common Information Model (CIM) roda em um sistema host z/OS; este componente fornece dados z/OS e capacidade administrativa.
    - CEA: Common Event Adapter (CEA) é um componente que permite aos fornecedores CIM identificar, receber e processar eventos z/OS selecionados.
    - System REXX: O componente System REXX fornece uma infra-estrutura através da qual REXX executáveis podem ser executados fora dos ambientes normais TSO/E ou em lote, utilizando uma interface de programação simples.
    Incident Log task: Utiliza os serviços prestados pelos seguintes componentes z/OS:
    • CIM • CEA • System REXX (SYSREXX)
  • IBM Health Checker for z/OS
    O objetivo do IBM Health Checker para z/OS é identificar potenciais problemas antes que eles afetem a sua disponibilidade, ou, em casos mais graves, causar interrupções. Ele verifica as configurações e definições atuais ativas para um sistema z/OS e sysplex e compara os valores com os sugeridos pela IBM ou definidas por você. Produz uma saída na forma de mensagens detalhadas para que você saiba de ambos os potenciais problemas e ações sugeridas para tomar.
    Health Checker for z/OS processing
    1. Verifica os valores fornecidos pelos componentes.
    Cada verificação inclui um conjunto de valores pré-definidos, como por exemplo:
    - Intervalo, ou quantas vezes a verificação será executada
    - Gravidade da verificação, o que influencia como a saída de verificação é emitida
    - Encaminhamento e códigos de descrição para a verificação
    2. Verifica a saída.
    Uma verificação de problemas a sua saída como WTOs e outras mensagens, que você pode ver usando o SDSF, o utilitário HZSPRINT, ou um fluxo de log que recolhe o histórico da saída de controle. Se a verificação encontra um desvio de melhores práticas ou um problema em potencial, ela emite uma mensagem OMC conhecida como uma exceção, como mencionado anteriormente.
    3. Resolver exceções de verificação
    Quando você receber uma exceção, resolva usando as informações na mensagem de exceção de verificação ou por valores de verificação primordiais, de modo que você não receba as mesmas exceções mais e mais. Você pode usar qualquer SDSF ou o membro parmlib HZSPRMxx, ou o IBM Health Checker para z/OS MODIFY (F hzsproc) para gerenciar verificações.
    4. Se você resolver uma exceção alterando uma configuração de produto ou de controle do sistema, é uma boa política executar novamente as verificações relacionados a esta ação, para garantir que o problema identificado foi resolvido.
  • É um novo nível de versão a cada ano. Portanto, você pode esperar para receber uma função em novos níveis de cada lançamento. Cada novo nível é testado exaustivamente, e a qualidade do sistema operacional é melhorada.
  • Um data set é uma coleção de dados relacionados logicamente, que pode ser um código de programa, uma biblioteca de macros, ou um arquivo de registros de dados usados por um programa em processamento. Os registros de dados (também chamados de registros lógicos) são a unidade básica de informação usada por um programa em processamento. Ao colocar seus dados em volumes de data sets organizados, você pode salvar e processar os dados de forma eficiente. Você também pode imprimir o conteúdo de um data set, ou exibir o conteúdo em um terminal.
    Você pode armazenar dados em secondary storage devices, tais como:
    Um direct access storage device (DASD)
    Uma magnetic tape volume
    Há muitos tipos diferentes de data sets no z/OS, e métodos diferentes para acessá-los. Discutiremos três tipos de data sets: sequenciais, particionados, e VSAM data sets.
    Em um dats set sequencial, os registros são itens de dados que são armazenados consecutivamente. Para recuperar o décimo item no data set, por exemplo, o sistema deve primeiro passar os últimos nove itens. Os itens de dados que devem ser todos utilizados em sequência, como a lista em ordem alfabética dos nomes em uma lista de sala de aula, são melhores armazenados em um data set sequencial.
    Um data set particionado ou PDS consiste em um diretório e membros. O diretório contém o endereço de cada membro e, portanto, torna possível para os programas ou o sistema operacional acessar cada membro diretamente. Cada membro, no entanto, consiste de registros armazenados em sequência.
    Data sets particionados são frequentemente chamados de libraries. Os programas são armazenados como membros de data sets particionados. Geralmente, o sistema operacional carrega os membros de um PDS sequencialmente no storage, mas pode acessar membros diretamente quando se seleciona um programa para execução.
    Em um Virtual Storage Access Method (VSAM) key sequenced data set (KSDS), os registros são itens de dados que são armazenados com informações de controle (chaves) para que o sistema possa recuperar um item sem ter de procurar todos os itens anteriores no conjunto de dados. Conjuntos de dados VSAM KSDS são ideais para itens de dados que são usados ​​com frequência e em uma ordem imprevisível.
  • z/OS suporta diversos dispositivos para armazenamento de dados. Discos ou fitas são mais frequentemente usados para armazenar data sets em uma base de longo prazo. Os drives de disco são conhecidos como direct access storage devices (DASDs), porque, apesar de alguns data sets sobre eles poderem ser armazenados sequencialmente, esses dispositivos podem lidar com acesso direto. As unidades de fita são conhecidas como dispositivos de acesso sequencial, porque os data sets em fita devem ser acessadas sequencialmente
    O termo DASD aplica-se aos discos ou equivalentes simuladores de discos. Todos os tipos de data sets podem ser armazenados em DASD (apenas os data sets sequenciais podem ser armazenado numa fita magnética). Você usa volumes DASD para armazenamento de dados e programas executáveis, incluindo o próprio sistema operacional e para o armazenamento de trabalho temporário. Você pode usar um volume DASD para muitos data sets diferentes, e realocar ou reutilizar o espaço no volume.
    Para permitir que o sistema localize rapidamente um data set específico, z/OS inclui um data set conhecido como o master catalog que permite o acesso a qualquer um dos data sets no sistema do computador ou outros catálogos de data sets. z/OS requer que o master catalog resida em um DASD que sempre está montado em uma unidade que está on-line ao sistema.
  • Um método de acesso define a técnica que é utilizada para armazenar e recuperar dados. Métodos de acesso têm as suas próprias estruturas de data set para organizar os dados, programas fornecidos pelo sistema (ou macros) para definir data sets e programas utilitários para processar data sets.
    Métodos de acesso são identificados principalmente pela organização do data set. Usuários z/OS, por exemplo, usam o basic sequential access method (BSAM) ou queued sequential access method (QSAM) com data sets sequenciais.
    Há momentos em que um método de acesso identificado com uma organização podem ser usados para processar um data set organizado de uma maneira diferente. Por exemplo, um data set sequencial (data set em formato não estendido) criado usando BSAM pode ser processado pelo basic direct access method (BDAM), e vice-versa. Outro exemplo são os arquivos UNIX, que você pode processar usando BSAM, QSAM, basic partitioned access method (BPAM), ou virtual storage access method (VSAM).
    Este texto não descreve todos os métodos de acesso disponíveis no z/OS. Métodos de acesso comumente usados incluem o seguinte:
    QSAM Queued Sequential Access Method (fortemente usado)
    BSAM Basic Sequential Access Method (para casos especiais)
    BDAM Basic Direct Access Method (se tornando obsoleto )
    BPAM Basic Partitioned Access Method (para libraries)
    VSAM Virtual Storage Access Method (utilizado para aplicativos mais complexos)
  • Volumes DASD são utilizados para armazenar dados e programas executáveis (incluindo o próprio sistema operacional), e para o armazenamento temporário de trabalho. Pode ser utilizado por vários data sets diferentes, e o espaço nele pode ser realocado e reutilizado. Em um volume, o nome de um data set deve ser exclusivo. Um data set pode ser localizado por tipo de dispositivo, volume serial number e o nome do data set. Diferente da árvore de arquivos em um sistema UNIX. A estrutura de arquivos z/OS básica não é hierárquica. Data sets z/OS não têm equivalência a um path name.
    Embora os volumes DASD diferem em aparência física, capacidade e velocidade, eles são semelhantes na gravação de dados, verificação de dados, formato de dados e programação. A superfície de gravação de cada volume é dividido em várias concêntricas tracks. O número de tracks e a sua capacidade variam com o dispositivo. Cada dispositivo tem um mecanismo de acesso que contém cabeças de leitura/gravação para transferir dados.
    As características de disco e de data sets de hardware e software de mainframe diferem consideravelmente de UNIX e de PC, e leva a sua própria terminologia especializada. Termos utilizados para descrever vários aspectos do gerenciamento de armazenamento no z/OS:
    Direct Access Storage Device (DASD) é outro nome para um disk drive.
    Um disk drive também é conhecido como um disk volume, um disk pack, ou um Head Disk Assembly (HDA). Usamos o termo volume neste texto, exceto quando se discute as características físicas dos dispositivos.
    Um disk drive contém cilindros.
    Cilindros contém tracks.
    Tracks contém data records e estão em formato Count Key Data (CKD).
    Data blocks são as unidades de gravação em disco.
    O sistema operacional usa grupos de labels para identificar volumes DASD e os data sets que contêm. Programas de aplicação do cliente geralmente não usam esses labels diretamente. Volumes DASD devem usar labels padrão. Labels padrão incluem um label de volume, um label de data set para cada data set e label de usuário opcionais. Um label de volume, armazenado na trilha 0 do cilindro 0, identifica cada volume DASD.
    O system programmers z/OS ou administrador de armazenamento utiliza o programa utilitário ICKDSF para inicializar cada volume DASD antes de ser usado no sistema. ICKDSF gera o rótulo de volume e constrói a tabela de volume de conteúdo (VTOC), uma estrutura que contém os rótulos de data sets. O system programmer também podem usar ICKDSF para escanear um volume para garantir que ele seja utilizável e reformatar todas as tracks.
  • Para usar um data set, você primeiro deve alocá-lo (estabelecer um link para ele), em seguida, acessar os dados usando macros para o método de acesso que você escolheu.
    A atribuição de um data set significa uma ou ambas das duas coisas:
    Criar espaço para um novo data set em um disco.
    Estabelecer um link lógico entre um job step e qualquer data set.
    Outras formas de alocar um data set incluem os seguintes métodos.:
    Access method services
    Você pode alocar data sets através de um programa de serviços multifuncionais chamado access method services. Access method services incluem os comandos mais usados para trabalhar com data sets, tais como ALLOCATE, ALTER, DELETE, e PRINT.
    ALLOCATE
    Você pode usar o comando TSO ALLOCATE para criar data sets. O comando atualmente o guia através dos valores de alocação que você deve especificar.
    ISPF menus
    Você pode usar um conjunto de menus TSO chamado Interactive System Productivity Facility. Um menu guia o usuário através da atribuição de um data set.
    Using JCL
    Você pode usar um conjunto de comandos chamado job control language para alocar data sets.
  • Quando você alocar um novo data set, você deve dar ao data set um nome exclusivo. Um nome de data set pode ser um name segment, ou uma série de name segments unidos. Cada name segment representa um nível de qualificação. Por exemplo, o nome do data set VERA.LUZ.DATA é composto por três name segments. O primeiro nome da esquerda é chamado de high-level qualifier (HLQ), e o sobrenome do lado direito é o lowest-level qualifier (LLQ). Segments ou qualifiers são limitados a oito caracteres, o primeiro dos quais deve ser alfabético (A a Z) ou especial (#, @ ou $). Os restantes sete caracteres são ou alfabéticos, ou numéricos (0 - 9),ou especial, ou um hífen (-). Name segments são separados por um ponto (.). Incluindo todos os name segments e pontos, o comprimento do nome do data set não deve exceder 44 caracteres. Assim, um máximo de 22 name segments pode fazer um nome de data set.
    Por exemplo, os seguintes nomes não são nomes de data sets válidos:
    Um nome com um qualificador com mais de oito caracteres (HLQ.ABCDEFGHI.XYZ).
    Um nome que contém dois pontos sucessivos (HLQ.. ABC).
    Um nome que termina com um ponto (HLQ.ABC.).
    Um nome com um qualifier que não começa com caracter alfabético ou especial (HLQ.123.XYZ).
    O HLQ para data sets de um usuário normalmente é controlado pelo sistema de segurança. Há uma série de convenções para o restante do nome. Estas são convenções, não regras, mas são amplamente utilizados. Elas incluem os seguintes itens:
    As letras LIB em algum lugar do nome indicam que o data set é uma biblioteca. As letras PDS são uma alternativa menos utilizadas por esta convenção.
    As letras CNTL, JCL, ou JOB em algum lugar do nome tipicamente indica que o data set contém JCL
    As letras LOAD, LOADLIB ou LINKLIB no nome indicam que o data set contém arquivos executáveis. (A biblioteca com modules z / OS executáveis deve ser dedicado exclusivamente aos modules executáveis.)
    As letras PROC, RPC, ou PROCLIB indica uma biblioteca de procedimentos JCL.
    Várias combinações são usadas para indicar um código-fonte para uma linguagem específica, por exemplo COBOL, Assembler, Fortran, PL / I, JAVA, C ou C + +.
    Uma porção de um nome de data set pode indicar um projeto específico, tais como PAYROLL.
    Usar muitos qualifiers é considerado má prática. Por exemplo, P390A.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S é um nome data set válido (maiúsculas, não excede 44 bytes, sem caracteres especiais), mas não é muito significativo. Uma boa prática é um nome de data set conter três ou quatro qualifiers.
    Mais uma vez, os períodos contam para o limite de 44 caracteres.
  • Data sets z/OS tradicionais são record oriented. No uso normal, não existem arquivos byte stream, como são encontrados em sistemas PC e UNIX. (z/OS UNIX tem arquivos byte stream, e as funções byte stream existem em outras áreas especializadas. Estes não são considerados data sets tradicionais.)
    No z/OS, não há caracteres new line (NL) ou carriage return e line feed (CR + LF) para indicar o final de um registro. Registros são ou tamanho fixo ou variável em um determinado data set. Ao editar um data set com ISPF, por exemplo, cada linha é um registro. Data sets z/OS tradicionais têm um dos cinco formatos de registros, como segue:
    F (Fixed): Um bloco físico no disco é um registro lógico e todos os blocos/registros são do mesmo tamanho. Raramente utilizado.
    FB (Fixed Blocked): Vários registros lógicos são combinados em um bloco físico. Isto pode proporcionar a utilização eficiente do espaço e operação. Comumente usado para registros de tamanho fixo.
    V (Variable): Tem um registro lógico como um bloco físico. Um registro lógico de tamanho variável consiste em uma record descriptor word (RDW), seguido pelos dados. A record descriptor word é um campo de 4 bytes que descreve o registro. Os dois primeiros bytes contêm o tamanho do registro lógico (incluindo 4 bytes RDW). O tamanho pode ser de 4 a 32.760 bytes. Todos os bits do terceiro e quarto bytes devem ser 0, porque os outros valores são utilizados para registros estendidos. Raramente utilizado.
    VB (Variable Blocked): Coloca vários registros lógicos de tamanho variável (cada um com um RDW) em um bloco físico. O software tem de colocar um adicional Block Descriptor Word (BDW) no início do bloco, que contém o tamanho total do bloco.
    U (Undefined): Consiste de tamanho variável de registros físicos/blocos com nenhuma estrutura pré-definida. Embora este formato pode parecer atraente para muitas aplicações incomuns, normalmente é usado apenas para os módulos executáveis.
  • Devemos salientar a diferença entre um bloco e um registro. Um bloco é o que está escrito no disco, enquanto um registro é uma entidade lógica. A terminologia aqui é generalizada em toda a literatura z/OS. Os termos-chave são:
    Block Size (BLKSIZE) é o tamanho do bloco físico escrito no disco para registros F e FB. Para registros V, VB, e U, é o tamanho máximo do bloco físico que pode ser usado para o data set.
    Logical Record Size (LRECL) é o tamanho lógico do registro (F ou FB) ou o tamanho máximo lógico do registro permitido (V ou VB) para o data set. Registros de formato U não têm LRECL.
    Record Format (RECFM) é F, FB, V, VB, ou U, como descrito acima.
    Esses termos são conhecidos como características data control block (DCB), nomeado para o control block onde podem ser definidos em um programa em linguagem assembly. O usuário é muitas vezes quem especifica esses parâmetros ao criar um novo data set. O tipo e o tamanho de um data set são definidos pelo seu record format (RECFM) e logical record length (LRECL). Data sets de tamanho fixo têm uma RECFM de F, FB, de FBS, e assim por diante. Data sets de tamanho variável tem um RECFM de V, VB, VBS, e assim por diante.
    Um data set com RECFM = FB e LRECL = 25 é um data set de tamanho fixo (FB) com um tamanho de registro de 25 bytes (o B é para blocked). Para um data set FB, o LRECL diz o tamanho de cada registro no data set; todos os registros são do mesmo tamanho. O primeiro byte de dados de um registro FB está na posição 1. Um registro em um data set FB estabelecido com LRECL = 25 pode ter esta aparência:
    Positions 1-3: Country Code = 'USA' - Positions 4-5: State Code = 'CA'
    Positions 6-25: City = 'San Jose' padded with 12 blanks on the right
    Um data set com RECFM = VB e LRECL = 25 é um data set de tamanho variável (VB) com um tamanho máximo de registro de 25 bytes. Em um data set VB, os registros podem ter diferentes tamanhos. Os primeiros quatro bytes de cada registro conterá o RDW, e os dois primeiros bytes do RDW contém o tamanho desse registro (em binário). O primeiro byte de dados de um registro VB está na posição 5, depois do RDW 4 bytes nas posições 1-4. Um registro em um data set VB estabelecido com LRECL = 25 pode ter esta aparência:
    Positions 1-2: Length in RDW = hex 0011 = decimal 17
    Positions 3-4: Zeros in RDW = hex 0000 = decimal 0
    Positions 5-7: Country Code = 'USA'
    Positions 8-9: State Code = 'CA'
    Positions 10-17: City = 'San Jose'
  • Há muitos tipos diferentes de data sets em z/OS, e métodos diferentes para gerenciá-los. Discutiremos três tipos: Sequential; Partitioned; VSAM
    Estes são usados para armazenamento em disco; podemos citar os tape data sets brevemente também.
    What is a sequential data set
    A estrutura de dados simples em um sistema z/OS é um data set sequencial. Ele consiste em um ou mais registros que estão armazenados na ordem física e processados em sequência. Novos registros são acrescentados ao final do data set. Um exemplo de um data set sequencial pode ser um data set de saída para uma impressora ou um arquivo de log.
    Um usuário z/OS define data sets sequenciais através do job control language (JCL) com uma organização de data set PS (DSORG = PS), que significa physical sequential. Em outras palavras, os registros no data set são organizados fisicamente um após o outro.
    Abrangemos aqui principalmente os data sets de disco, mas os aplicativos de mainframe também podem usar data sets de fita para muitas finalidades. Tapes armazenam data sets sequenciais. Unidades de fita de mainframe tem registros de tamanho variável (blocos). O tamanho máximo do bloco de métodos de programação de rotina é de 65 KB. Programação especializada pode produzir blocos mais longos. Há um certo número de produtos de unidades de fita, com características diferentes.
    What is a partitioned data set
    Um data set particionado (PDS) adiciona uma camada de organização para a estrutura simples de data sets sequenciais. Um PDS é uma coleção de data sets sequenciais, chamados de members. Cada membro é como um data set sequencial e tem um nome simples, que pode ser de até oito caracteres.
    Um PDS contém também um diretório. O diretório contém uma entrada para cada membro no PDS com uma referência (ou ponteiro) para o membro. Nomes dos membros estão listados em ordem alfabética no diretório, mas os próprios membros podem aparecer em qualquer ordem na biblioteca. O diretório permite que o sistema recupere um determinado membro do data set.
    Um data set particionado é comumente referido como uma library. No z/OS, bibliotecas são usadas para armazenar códigos de programas, controle de parametros de sistema e aplicativos, JCL, e módulos executáveis. Existem alguns data sets do sistema que não são bibliotecas.
    Um PDS perde espaço quando um membro é atualizado ou adicionado. Como resultado, os usuários do z/OS regularmente necessitam comprimir um PDS para recuperar o espaço perdido.
    Um usuário z/OS define um PDS através de JCL com uma organização data set PO (DSORG = PO), que representa partitioned organization.
  • What is a partitioned data set extended
    Um partitioned data set extended (PDSE) consiste em um diretório e zero ou mais membros, assim como um PDS. Ele pode ser criado com JCL, TSO / E, e ISPF, assim como um PDS, e pode ser processado com os mesmos métodos de acesso. Data sets PDSE são armazenadas somente no DASD, e não em fita.
    O diretório pode expandir automaticamente, conforme necessário, até o limite de endereçamento de 522.236 membros. Ele também tem um índice, que oferece uma busca rápida por nomes de membros. Espaço dos membros excluídos ou movidos são automaticamente reutilizados para novos membros, para que você não tenha que comprimir um PDSE para remover espaço desperdiçado. Cada membro de um PDSE pode ter até 15.728.639 registros. Um PDSE pode ter um máximo de 123 extensões, mas não pode se estender além de um volume. Quando um diretório de um PDSE está em uso, ele é mantido no armazenamento do processador para o acesso rápido.
    Data sets PDSE podem ser usados em lugar de quase todos os data sets PDS que são utilizados para armazenar dados. Mas o formato PDSE não pretende ser um substituto PDS. Quando um PDSE é usado para armazenar load modules, armazena-os em estruturas chamadas de program objects.
  • Virtual Storage Access Method (VSAM) aplica-se tanto a um tipo de data set e o método de acesso utilizado para gerenciar vários tipos de dados do usuário. Como um método de acesso, VSAM oferece funções muito mais complexas do que outros métodos de acesso ao disco. VSAM mantém registros de disco em um formato exclusivo que não é compreensível por outros métodos de acesso. VSAM é usado principalmente para aplicações. Arquivos VSAM não podem rotineiramente ser exibidos ou editados com ISPF. Data sets VSAM são descritos resumidamente como se segue:
    Key Sequence Data Set (KSDS): Uso mais comum. Cada registro tem um ou mais campos-chave e um registro pode ser recuperado (ou inserido) pelo valor da chave. Isto fornece acesso aleatório aos dados. Os registros são de tamanho variável.
    Entry Sequence Data Set (ESDS): Mantém registros em ordem sequencial. Os registros podem ser acessados sequencialmente. Ele é usado pelo IMS, DB2, e z/OS UNIX.
    Relative Record Data Set (RRDS): Permite a recuperação de registros por número: registro 1, registro 2, e assim por diante. Isso fornece acesso aleatório e supõe que o programa de aplicação tem uma maneira de obter os números de registros desejados.
    Linear Data Set (LDS): Isto é, em efeito, um data set byte-stream e é a única forma de um data set byte-stream definido em arquivos tradicionais z/OS (ao contrário de arquivos z/OS UNIX). Um número de funções do sistema z/OS usa o formato fortemente, mas raramente é usada por programas de aplicação.
    Existem vários métodos adicionais de acesso aos dados em VSAM que não estão listadas aqui. A maioria das aplicações utilizam VSAM para dados com chave. VSAM funciona com uma área de dados lógica conhecida como um control interval (CI). O tamanho padrão CI é de 4 KB, mas pode ser de até 32 KB. A CI contém registros de dados, o espaço não utilizado, record descriptor fields (RDFs), e um campo de descritor de CI. Vários CIs são colocados em uma control area (CA). Um data set VSAM consiste em áreas de controle e índice de registros. Uma das formas de índice de registro é o sequence set, que é o índice de nível mais baixo apontando para um intervalo de controle. Dados VSAM são sempre de comprimento variável e os registros são bloqueados automaticamente em intervalos de controle. Os atributos RECFM (F, FB, V, VB, e U) não se aplicam a VSAM, nem o atributo BLKSIZE. Você pode usar o utilitário Access Method Services (AMS) para definir e eliminar estruturas VSAM, como arquivos e índices. Há muitos detalhes do processamento VSAM que não estão incluídos nesta breve descrição. Mais o processamento é feito de forma transparente pelo VSAM, o programa de aplicação meramente recupera, atualiza, exclui ou adiciona registros com base em valores de chave.
  • z/OS usa um catálogo e um volume table of contents (VTOC) em cada DASD para gerenciar o armazenamento e colocação de data sets. Também torna possível agrupar data sets com base em relacionados dados históricos.
    What is a volume table of contents
    z/OS requer um formato particular para discos. Registro 1, na 1º faixa do 1º cilindro fornece o rótulo para o disco. Ele contém o 6-character volume serial number (volser) e um ponteiro para o volume table of contents (VTOC), o qual pode estar localizado em qualquer lugar no disco. O VTOC lista os data sets que residem em seu volume, com informações sobre a localização e o tamanho de cada data set, e outros atributos data set. O ICKDSF é usado para criar o rótulo e VTOC. Quando um volume de disco é inicializado com ICKDSF, o proprietário pode especificar a localização e o tamanho do VTOC. O tamanho pode ser bastante variável, indo de algumas faixas até, talvez, 100 faixas, dependendo da utilização prevista para o volume. Mais data sets sobre o volume de disco necessitam de mais espaço no VTOC. O VTOC também tem entradas para todo o espaço livre no volume. Alocar espaço para um data set faz com que as rotinas do sistema examine os registros de espaço livre, atualize eles, e crie uma nova entrada VTOC. Os data sets são sempre um número inteiro de faixas (ou cilindros) e começam no início de uma faixa (ou cilindro). Você também pode criar um VTOC com um índice. O índice VTOC é na verdade um data set com o nome SYS1.VTOCIX.volser, que tem entradas dispostas em ordem alfabética pelo nome do data set com ponteiros para as entradas VTOC. Ele também tem bitmaps do espaço livre no volume. Um índice VTOC permite ao usuário encontrar o data set muito mais rápido.
    What is a catalog
    Um catálogo descreve um atributo de data set e indica os volumes em que um data set está localizado. Quando um data set é catalogado, ele pode ser referido apenas pelo nome. Os data sets podem ser catalogados, descatalogados ou recatalogados. Todos os data sets DASD gerenciados pelo sistema são catalogados automaticamente em um catálogo. Catalogação em fita magnética não é necessária, mas pode simplificar jobs dos usuários. No z/OS, o master catalog e user catalogs armazenam as localizações dos data sets. Para encontrar um data set, o z/OS deve saber três informações: Data set name, Volume name e Unit (o volume device type, como um disco 3390 ou fita 3590). Você pode especificar todos os três valores em painéis ISPF ou em JCL. No entanto, o unit device type e o volume muitas vezes não são relevantes. Um system catalog é usado para armazenar e recuperar a localização UNIT e VOLUME de um data set. Basicamente, um catálogo pode fornecer o tipo de dispositivo de unidade e nome do volume para qualquer data set catalogado. Um system catalog fornece um olhar simples acima da função. Com esta facilidade, o usuário só precisa fornecer um nome de data set.
  • Using an alternate master catalog
    Então, o que acontece se uma instalação perde seu master catalog, ou o master catalog de alguma forma torna-se corrompido? Tal ocorrência seria um problema sério e requerem ações de recuperação rápidas.
    Para evitar essa situação, a maioria dos system programmers definem um backup para o master catalog. O programador do sistema especifica este master catalog alternativo durante a inicialização do sistema. Neste caso, o programador do sistema deve manter o alternativo em um volume separado daquele master catalog (para proteger contra uma situação em que o volume se torne indisponível).
    What is a generation data group
    No z/OS, é possível catalogar atualizações sucessivas ou gerações de dados relacionados. Eles são chamados de generation data groups (GDGs). Cada data set em um GDG é chamado de generation ou generation data set (GDS). Um generation data group (GDG) é uma coleção de data sets não-VSAM historicamente relacionados que são organizados em ordem cronológica, ou seja, cada data set é historicamente relacionado com os outros membros do grupo. Dentro de um GDG, as gerações podem ter semelhantes ou não atributos DCB e organizações data set. Se os atributos e organizações de todas as generations em um grupo são idênticos, as generations podem ser recuperados em conjunto como um único data set. Há vantagens para agrupar data sets relacionados. Por exemplo:
    Todos os data sets no grupo podem ser referidos por um nome comum.
    O sistema operacional é capaz de manter as generations em ordem cronológica.
    Generations desatualizadas ou obsoletas podem ser excluídas automaticamente pelo sistema operacional.
    Generation data sets tem ordenado sequencialmente absolute e relative names que representam sua idade. Rotinas de gerenciamento de catálogo do sistema operacional usam o absolute generation name. Data sets mais antigos têm números absolutos menores. O nome relativo é um inteiro usado para referir os mais recentes (0), o próximo mais recente (-1), e assim por diante, generation.
    Por exemplo, o data set de nome LAB.PAYROLL (0) refere-se o mais recente data set do grupo, LAB.PAYROLL (-1) refere-se ao segundo data set mais recente, e assim por diante. O número relativo também pode ser utilizado para catalogar uma nova generation (+1). Um generation data group (GDG) de base é alocado em um catálogo antes que os generation data sets são catalogados. Cada GDG é representado por uma entrada de base GDG.
    Para os novos data sets não gerenciados pelo sistema, se você não especificar um volume e o data set não é aberto, o sistema não cataloga o data set. Novos data sets gerenciados pelo sistema são sempre catalogados quando alocados, com o volume atribuído a partir de um grupo de armazenamento.
  • Pense em um sistema de arquivos UNIX como um recipiente que contém parte de toda a árvore de diretórios do UNIX. Ao contrário de uma biblioteca tradicional z/OS, um sistema de arquivos UNIX é hierárquico e orientado a byte. Para localizar um arquivo em um sistema de arquivos UNIX, você procura um ou mais diretórios. Não existe o conceito de um catálogo z/OS que aponta diretamente para um arquivo. z/OS UNIX System Services (z/OS UNIX) permite que os usuários do z/OS criem sistemas de arquivos UNIX e árvores de diretório do sistema de arquivos no z/OS, para acessar os arquivos do UNIX no z/OS e outros sistemas. No z/OS, um sistema de arquivos UNIX é montado sobre um diretório vazio pelo programador do sistema (ou um usuário com autoridade de montagem).
    Você pode usar os seguintes tipos de sistema de arquivos com z/OS UNIX:
    System z File System (zFS), que é um sistema de arquivo que armazena arquivos em data sets VSAM lineares .
    Hierarchical file system (HFS), um sistema de arquivos montável, que está a ser eliminado pelo zFS.
    z/OS Network File System (z/OS NFS), que permite que um sistema z/OS acesse um sistema de arquivos remoto UNIX (z/OS ou não-z/OS) sobre TCP/IP, como se fosse parte do local da árvore de diretórios z/OS.
    Temporary file system (TFS), que é um temporário, sistema de arquivo em memória física que suporta os sistemas de arquivos montáveis em storage.
    Tal como acontece com outros sistemas de arquivos UNIX, um path name identifica um arquivo e consiste em nomes de diretório e um nome de arquivo. Um nome de arquivo totalmente qualificado, que consiste no nome de cada diretório no caminho para um arquivo mais o próprio nome do arquivo, pode ser de até 1.023 bytes de tamanho. O path name é construído de nomes de diretórios individuais e um nome de arquivo separado pelo caractere forward-slash, por exemplo: /dir1/dir2/dir3/MyFile
    Como UNIX, z/OS UNIX é case-sensitive para nomes de arquivos e diretórios. Os arquivos em um sistema de arquivos hierárquico são arquivos sequenciais, e são acessados como fluxos de bytes. Um conceito de registro não existe com esses arquivos exceto a estrutura definida por um aplicativo.
    O data set zFS que contém o sistema de arquivos UNIX é um tipo de data set z/OS (um data set VSAM linear). zFS data sets e data sets z/OS podem residir no mesmo volume DASD. z/OS fornece comandos para a gestão de utilização de espaço zFS. A integração do sistema de arquivos zFS com serviços de gerenciamento do sistema de arquivos z/OS existentes fornece capacidades de gerenciamento automatizado do sistema de arquivos que podem não estar disponíveis em outras plataformas UNIX. Essa integração permite que os proprietários de arquivos gastem menos tempo em tarefas como backup e restauração de sistemas de arquivos inteiros.
  • TSO/E
    Em geral, o TSO/E faz com que seja mais fácil para as pessoas com todos os níveis de experiência interagir com o sistema z/OS.
    Se tornou a interface com o usuário principal para o sistema operacional z/OS.
    Fornece serviços de programação que você pode utilizar no sistema ou programas Aplicativos.
    TSO/E users
    Oferece vantagens para uma ampla gama de usuários de computador, incluindo system programmers, de aplicativos, administradores de centro de informações, usuários do centro de informações, administradores do TSO/E, e outros que acessam aplicativos que são executados em TSO/E.
  • Destaques do TSO/E são descritos nesta seção.
  • O SMP/E é uma ferramenta projetada para gerenciar a instalação de produtos de software em seu sistema z/OS e para acompanhar as alterações desses produtos. Geralmente, é de responsabilidade do system programmer garantir que todos os produtos de software e suas modificações estejam corretamente instalados no sistema. O system programmer também tem que garantir que todos os produtos são instalados no nível adequado para todos os elementos do sistema poderem trabalhar em conjunto. Em primeiro, pode não ser muito difícil, mas a complexidade de configuração de software aumenta, assim como a tarefa de monitoramento de todos os elementos do sistema. Para melhor entender isso, vamos dar uma olhada no seu sistema z/OS e ver como o SMP/E pode ajudar a manter a ele.
  • O sistema z/OS pode parecer ser um grande bloco de código que movimenta sua CPU. Na verdade, o z/OS é um sistema complexo com diversos blocos menores de codigo. Cada um desses blocos menores de código executam uma função específica no sistema .
    Por exemplo , algumas das funções que podem aparecer em um sistema z/OS incluem:
    Base Control Program (BCP)
    C/C++ IBM® Open Class® Library
    z/OS Communications Server
    Cryptographic Services
    DFSMSdfp
    DFSORT
    Distributed File Service
    Hardware Configuration Definition (HCD)
    High Level Assembler (HLASM)
    IBM HTTP Server
    Infoprint Server
    ISPF
    JES2 or JES3
    z/OS Language Environment®
    Network File System
    Open Systems Adapter/Support Facility (OSA/SF)
    Resource Measurement Facility (RMF™)
    System Display and Search Facility (SDSF)
    SMP/E
    Time Sharing Option/Extensions (TSO/E)
    z/OS UNIX System Services (z/OS UNIX)
  • Cada função do sistema é composta por um ou mais load modules. Em um ambiente z/OS, um load module representa a unidade básica legível por máquina, código executável. Os load modules são criados pela combinação de um ou mais object modules e processados com um utilitário link-edit. A link-edição de modules é um processo que resolve referências externas e endereços. As funções em seu sistema, portanto, são um ou mais object modules que foram combinados e link-editados.
    Na maioria das vezes, object modules são enviados a você como parte de um produto. Neste exemplo, o object module MOD1 foi enviado como parte do produto. Outras vezes, pode ser necessário montar o source code enviado a você por empacotadores do produto para criar o object module. Você pode modificar o source code e montá-lo para produzir um object module. No exemplo, SRCMOD2 é o source code que você monta para criar o object module MOD2. Quando montada, você link-edita o object module MOD2 com MOD1 para formar o load module LMOD1.
    Além dos object modules e source code, a maioria dos produtos distribui muitas partes adicionais, como macros, painéis de ajuda, elementos de diálogo e outros membros da biblioteca do z/OS. Estes modules, macros e outros tipos de dados e código são os blocos básicos de construção de seu sistema. Todos estes blocos de construção são chamados de elements.
  • Com o tempo, você pode precisar alterar alguns dos elementos de seu sistema. Estas alterações podem ser necessárias para melhorar a capacidade de utilização ou a confiabilidade de um produto. Você pode querer adicionar novas funções ao seu sistema, atualizar alguns dos elementos do seu sistema, ou modificar alguns elementos por várias razões. Em todos os casos, você está fazendo modificações no sistema. No SMP/E, nos referimos a essas modificações no sistema como SYSMODs.
    Um SYSMOD é o pacote atual contendo informações SMP/E necessárias para instalar e monitorar modificações no sistema. SYSMODs são compostos de duas partes:
    Modification control statements (MCS), designados por ++ nos dois primeiros caracteres, diz ao SMP/E:
    -Quais elementos estão sendo atualizados ou substituídos
    -Como o SYSMOD se refere ao software produto e outros SYSMODs
    -Outras informações de instalação especificas
    Modification text, que é os object modules, macros e outros elementos fornecidos pelo SYSMOD
    Há quatro categorias diferentes de SYSMODs, cada uma apoiando uma tarefa que você pode querer executar:
    Function SYSMODs: Introduz os elementos para um produto.
    PTF (program temporary fix) SYSMODs: Impedir ou corrigir problemas com um elemento , ou introduzir um novo elemento(s).
    APAR (authorized program analysis reports) SYSMODs: Corrigir problemas com um elemento.
    USERMOD (user modifications) SYSMODs: Customizar um elemento.
  • Para monitorar e controlar os elementos com sucesso, todos os elementos e suas modificações e atualizações devem ser claramente identificados para o SMP/E. O SMP/E confia nos modification identifiers para alcançar este objetivo. Existem três modification identifiers associados a cada elemento:
    Function modification identifiers (FMIDs): Identifica a function SYSMOD que introduz o elemento no sistema.
    Replacement modification identifiers (RMIDs): Identifica a última SYSMOD (usualmente a PTF SYSMOD) para substituir o elemento.
    Update modification identifiers (UMIDs): Identifica as SYSMODs que atualizaram um elemento desde a última vez que foi substituído.
    O SMP/E usa esses modification identifiers para rastrear todas as SYSMODs instaladas em seu sistema. Isto assegura que eles sejam instalados na sequência correta. Agora que percebemos a necessidade de monitoramento do elemento e conhecemos os tipos de monitoramentos do SMP/E, vamos ver como o SMP/E realiza sua função de monitoramento.
  • No ambiente SMP/E, existem dois tipos distintos de estantes. Elas são referidas como as distribution libraries e as target libraries.
    Da mesma forma que as estantes da biblioteca pública seguraram os livros da biblioteca, as distribution e target libraries mantêm os elementos do sistema.
    Distribution libraries: Contém todos os elementos, tais como modules e macros, que são usados como entrada para a execução de seu sistema. Um uso muito importante das distribution libraries é para backup. No caso de um erro sério ocorrer com um elemento do sistema de produção, o elemento pode ser substituído por um nível estável encontrado nas distribution libraries.
    Target libraries: Contém todo o código executável necessário para executar o sistema.
  • Como você se refere a analogia da biblioteca pública, você pode ver que há um pedaço importante que ainda não consideramos. Na biblioteca pública, há um catálogo de cartões para ajudar você a encontrar o livro ou informação que você está procurando. O SMP/E proporciona o mesmo tipo de mecanismo de controle, na forma do consolidated software inventory (CSI).
    Os CSI data sets contém todas as informações que o SMP/E precisa para controlar as bibliotecas distribution e target. Como o catálogo contém um cartão para cada livro na biblioteca, o CSI contém uma entrada para cada elemento em suas bibliotecas. As entradas CSI contém o nome do elemento, o tipo, a história, a forma como o elemento foi introduzido no sistema, e um ponteiro para o elemento na biblioteca distribution e target. O CSI não contém o elemento em si, mas sim uma descrição do elemento que representa.
    Os cartões no catálogo da biblioteca pública estão organizados em ordem alfabética pelo sobrenome do autor, e pelo tema e título do livro. No CSI, as entradas para os elementos das bibliotecas são agrupados de acordo com seu status de instalação. As entradas que representam elementos encontrados nas bibliotecas distribution estão contidas na distribution zone. E as que representam elementos encontrados nas bibliotecas target estão contidas na target zone. Ambas as zonas têm a mesma finalidade, como as gavetas do catálogo de cartão da biblioteca pública.
    Adicionalmente, o SMP/E CSI também contém uma global zone. A global zone contém:
    Entradas necessárias para identificar e descrever cada target e distribution zone do SMP/E
    Informações sobre SMP/E processing options
    Informações de status para todos SYSMODs SMP/E que começaram a processar dados
    Dado de exceção para SYSMODs que requerem tratamento especial ou que estão em erro
    No SMP/E, quando falamos de dados de exceção, estamos geralmente referindo-se a HOLDDATA. HOLDDATA muitas vezes é fornecida por um produto para indicar uma SYSMOD especificada que deve ser mantida desde a instalação. Razões para a conservação de um SYSMOD podem ser:
    A PTF contém erro e não deve ser instalada até que o erro seja corrigido (ERROR HOLD).
    Certas ações do sistema podem ser necessárias antes da instalação SYSMOD (SYSTEM HOLD).
    O usuário pode querer executar algumas ações antes de instalar o SYSMOD (USER HOLD).
  • Agora que você está familiarizado com o SMP/E e com o que ele pode fazer, você provavelmente está se perguntando o que você precisa saber para começar a usar o SMP/E. Vamos dar uma olhada nos comandos de processamento básicos que você precisa saber para usar SMP/E.
    Antes de processar comandos SMP/E, você deve primeiro definir a zona na qual você deseja que o SMP/E trabalhe (global, target ou distribution). Você pode fazer isso usando o comando SET. O comando SET identifica a zona e, por conseguinte, as bibliotecas, em que os comandos subsequentes SMP/E irão atuar.
    O comando SET também pode ser usado para solicitar um determinado conjunto de opções de processamento predefinidas.
    Para o SMP/E instalar um SYSMOD, o SYSMOD deve ser "recebido" em data sets que podem ser utilizados pelo SMP/E. O comando SMP/E RECEIVE executa a tarefa de copiar o SYSMOD do meio de distribuição a partir do qual ele foi enviado para o data set utilizado pelo SMP/E.
    Uma vez que um SYSMOD foi recebido, você quer "aplicar" o SYSMOD às bibliotecas target apropriadas. O comando SMP/E APPLY invoca vários utilitários de sistema para instalar elementos do SYSMOD nas bibliotecas target.
    Se tiver problemas após a aplicação de um SYSMOD, você pode querer "restaurar" os seus elementos em erro a um nível anterior e estável. O comando SMP/E RESTORE substitui um elemento falho com uma cópia das distribution libraries.
    Depois de ter realizado um SYSMOD RECEIVE e APPLY, você quer "aceitar" os elementos para as distribution libraries para backup. No entanto, isso só deve ser feito depois que você estiver satisfeito com o desempenho e estabilidade dos elementos da SYSMOD. Depois de um ACCEPT de SYSMOD, você não pode dar RESTORE do seu elemento a um nível anterior. O SMP/E ACCEPT atualiza as distribution libraries e assim elas estão disponíveis para backup de quaisquer SYSMODs futuras.
  • O SMP/E CSI e outros data sets primários contêm uma grande quantidade de informações que podem ser úteis ao instalar novos elementos ou funções, preparar modificações do usuário, ou problemas de depuração. Você pode exibir essas informações, bem como informações sobre os modules, macros e outros elementos, de várias maneiras diferentes.
    Query dialogs exibe informações específicas que você solicita através de diálogos interativos com SMP/E.
    LIST command gera uma lista de informações sobre o sistema.
    REPORT commands verifica, compara e gera informações sobre o conteúdo de zonas no seu sistema.
    SMP/E CSI application programming interface pode ser usado para escrever programas de aplicação para consultar o conteúdo dos CSI data sets do seu sistema.
  • Processor storage overview
    Logicamente, um sistema é constituído da main storage e um ou mais central processing units (CPs). O sistema administra o uso de armazenamento do processador e direciona o movimento de páginas virtual storage entre slots auxiliary storage e frames reais em blocos de 4096 bytes. Isso faz todo o virtual storage endereçável em cada address space que aparecem como main storage. Apenas as virtual pages necessárias para a execução do programa são mantidas na main storage. O restante residem no auxiliary storage. O sistema emprega o gerenciador auxiliary storage para executar o I/O de paginação real necessária para transferir páginas para dentro e para fora da main storage. O sistema também fornece alocação e gerenciamento do DASD para espaço de paginação no auxiliary storage.
    O sistema designa os frames reais mediante solicitação dos conjuntos de frames disponíveis, por forma a associação de endereços virtuais com endereços da main storage. Os frames são recuperados quando liberados por um usuário, quando um usuário é trocado, ou quando necessário para completar o conjunto disponível. Enquanto uma página virtual ocupa um frame real, a página é considerada paginável a não ser que seja fixada pela opção FIX da macro PGSER, uma macro PGFIX ou PGFIXA, ou obtidas a partir de um subconjunto fixo. O sistema também aloca regiões virtuais igual a reais (V =
    R) mediante pedido por esses programas que não podem tolerar relocação dinâmica. Tal região é atribuída de forma contígua a partir de uma área pré-definida da main storage e que não é paginada.
    A tecnologia da main storage possui as seguintes características:
    • O processador é diretamente acessível (para programas e dados)
    • Ele é volátil, rápido, e caro, quando comparados com armazenamento magnético (DASD, fita).
  • O intervalo de endereços virtuais que o sistema operacional atribui a um usuário ou separadamente executa o programa é chamado de um address space. Essa é a área contígua de endereços virtuais disponíveis para a execução de instruções e o armazenamento de dados. O intervalo de endereços virtuais em um address space inicia em zero e pode estender ao maior endereço permitido pela arquitetura do sistema operacional.
    System/370 foi a primeira arquitetura IBM a utilizar conceitos de virtual storage e de address space. O address space é um conjunto de endereços virtuais contíguos disponíveis para as instruções do programa e seus dados. O intervalo de endereços virtuais disponíveis em um programa começa em 0 e pode ir para o maior endereço permitido pela arquitetura do sistema operacional. O tamanho do address space é decidido pelo comprimento dos campos que mantém tais endereços. Como ele mapeia todos os endereços disponíveis, um address space inclui o código e os dados do sistema, e o código do usuário e dados. Assim, nem todos os endereços mapeados estão disponíveis para o código do usuário e dados. A arquitetura S/370 utiliza 24 bits para endereçamento. Portanto, o maior endereço acessível no MVS/370 foi de 16 megabytes, que também foi o tamanho do address space.
    Com o MVS/XA, a arquitetura XA aumentou para 31 bits para endereçamento e o tamanho do address space passou de 16 MB para 2 GB, que é 128 vezes maior. O endereço de 16 MB tornou-se o ponto de divisão entre as duas arquiteturas e a que se refere é comumente chamada de linha.
    Para compatibilidade, os programas sendo executados no MVS/370 devem ser executados no MVS/XA, e os novos programas devem ser capazes de explorar as novas tecnologias. Portanto, o bit de ordem superior do endereço (4 bytes) não é utilizado para endereçamento, mas em vez disso para indicar ao hardware quantos bits são usados para resolver um endereço: 31 bits (bit 32 on) ou de 24 bits (bit 32 off).
    No entanto, o uso de vários address spaces virtuais no z/OS fornece benefícios especiais. Endereçamento virtual permite um intervalo de endereçamento que é maior do que os recursos da main storage do sistema. O uso de vários address spaces virtuais fornece essa capacidade de endereçamento virtual para cada job no sistema ao atribuir a cada job seu próprio address space virtual separado. O número potencialmente grande de address spaces fornece ao sistema uma grande capacidade de endereçamento virtual.
    Com o z/OS, a z/Architecture extendeu a 64 bits e o tamanho do address space passou de 2 GB para 16 Exabytes, o que é 8 gigabytes vezes maior. Conforme mencionado, a área acima de 2 GB é chamado de the bar. Os endereços acima da barra são utilizados para dados apenas.
  • MVS/XA introduziu o conceito de addressing mode (AMODE). AMODE é um atributo de programa para indicar qual modo de endereçamento de hardware deve estar ativo para resolver um endereço; ou seja, quantos muitos bits devem ser utilizados para resolver e lidar com os endereços.
    AMODE=64: Indica que o programa pode enviar até 16 - Exa de endereços virtuais (apenas na z/Architecture).
    O conceito de residence mode (RMODE) é utilizado para indicar onde um programa deve ser colocado no virtual storage (by z/OS program management) quando o sistema o carrega a partir do DASD, como explicado aqui:
    RMODE=24: Indica que o module deverá residir abaixo dos 16 MB de linha de virtual storage. Entre as razões para RMODE24 é que o programa é AMODE24, o programa tem os blocos de controle que deve residir abaixo da linha.
    RMODE=ANY: Indica que o module pode residir em qualquer lugar no virtual storage, mas preferencialmente acima dos 16 MB de linha de virtual storage. Por isso, um RMODE é também chamado de RMODE 31. Observe que no z/OS não há RMODE=64, porque o virtual storage acima de 2 G não é adequado para os programas, apenas os dados.
    AMODE é um atributo de programa que pode ser especificado (ou padronizado) para cada CSECT, load module, e o alias do load module. AMODE indica o modo de endereçamento que deverá estar em vigor quando o programa é inserido. AMODE pode ter um dos seguintes valores:
    AMODE 24 - O programa foi projetado para receber o controle no modo de endereçamento de 24 - bit.
    AMODE 31 - O programa foi projetado para receber o controle no modo de endereçamento de 31 - bit.
    AMODE ANY - O programa foi projetado para receber o controle em um modo de endereçamento de 24 - bit ou 31 - bit.
    Em tempo de execução, há apenas três combinações AMODE/RMODE válidas:
    1.AMODE 24, RMODE 24, que é o padrão
    2.AMODE 31, RMODE 24
    3.AMODE 31, RMODE ANY
    As macros ATTACH, ATTACHX, LINK, LINKX, XCTL, e XCTLX da o controle do module invocado no AMODE especificado anteriormente. No entanto, a especificação de um AMODE particular, não garante que um module que obtém o controle por outros meios receberá controle em AMODE. Por exemplo, um module de AMODE 24 pode emitir um BALR para um module AMODE 31, RMODE 24. O module AMODE 31 terá controle no modo de endereçamento de 24 - bit.
  • Em um sistema z/OS, o armazenamento é gerenciado pelos seguintes componentes do z/OS:
    • Virtual Storage Manager
    • Real Storage Manager
    • Auxiliary Storage Manager
    O virtual storage é gerenciado pelo Virtual Storage Manager (VSM). A função principal da VSM é controlar o uso de endereços de virtual storage pelos programas. Cada instalação pode utilizar os parâmetros de virtual storage (no data set SYS1.PARMLIB) para especificar como determinadas áreas de virtual storage devem ser alocadas para os programas. Esses parâmetros têm um impacto sobre o uso da main storage e no desempenho geral do sistema.
    VSM acompanha o mapa de virtual storage para cada address space. Ao fazê-lo, ele vê um address space como uma coleção de 256 subconjuntos, que são áreas de virtual storage relacionados logicamente identificado por números 0 a 255. Sendo relacionados logicamente significa que as áreas de armazenamento tem características de compartilhamento do subconjunto, tais como:
    • Chave de proteção de armazenamento
    • Se eles buscam protegidos, pagináveis, ou swap
    • Onde elas devem residir no virtual storage (acima ou abaixo de 16 megabytes)
    • Se eles podem ser compartilhados por mais de uma tarefa
    Real Storage Manager (RSM) acompanha o conteúdo da main storage. Ele gerencia as atividades de paginação, tais como a page-in, page-out, page stealing, e ajuda na troca de um address space de entrada ou de saída. RSM também executa a fixação da página, que está marcando páginas como indisponíveis para roubar.
    Auxiliary Storage Manager
    O Auxiliary Storage Manager (ASM) controla a utilização de paginas de data sets e a operação de I/O de paginação implícito. Como um system programmer, você é responsável pelo tamanho e o desempenho da pagina de data sets. O ASM utiliza data sets de página do sistema para manter o controle dos slots de auxiliary storage. Especificamente:
    • Slots para as páginas de virtual storage que não estão em frames da main storage
    • Slots para as páginas que não ocupam os frames mas, como o conteúdo do frame não foram alterados, os slots serão ainda válidos.
    Quando uma página de entrada ou página de saída é necessário, o ASM funciona com o RSM para localizar os frames da main storage e os slots de auxiliary storage.
  • z/OS address spaces
    Quando você inicializa o z/OS, master scheduler initialization routines inicializa serviços de sistema, tais como o log do sistema e tarefas de comunicação, e inicia o master scheduler address space (*MASTER*). Cada address space tem criado um número associado a ele, conhecido como address space id (ASID). Porque o master scheduler é o primeiro espaço de endereçamento criado no sistema, torna-se um address space number one (ASID=1).
    Outro sistema de address spaces são então iniciados durante o processo de inicialização do z/OS.
    Em seguida, o subsystem de address spaces são iniciados. O master scheduler inicia o job entry subsystem (JES2 ou JES3). JES é o job entry subsystem primário. Em seguida, outros subsystems definidos são iniciados. Todos os subsystems são definidos em SYS1.PARMLIB, membro IEFSSNxx. Esses subsystems são secondary subsystems.
    System component address spaces
    Além de áreas de inicialização do sistema, MVS estabelece system component address spaces, estabelece um address space para o master scheduler (o master scheduler address space) e outros address spaces do sistema para vários subsystems e componentes do sistema.
  • Memory hierarchy
    A hierarquia de memória mostra as diferentes camadas de memória ao longo de um processo computacional. Quanto maior for a camada de memória, então é mais rápida, mais cara, e é menor. As camadas superiores são acessadas diretamente pelo processador.
    O problema é como distribuir os dados e programas em toda a memória, no que diz respeito à sua importância para o negócio e sua frequência de uso. Há várias considerações a ter em mente:
    • Quais são os dados (e programas) precisam migrar para uma camada inferior quando a camada ocupada está cheia ou quase cheia? Neste caso, existem dois algoritmos que podem ser utilizados:
    – Um algoritmo least recently used (LRU) mantém os dados mais referenciados ou programas no armazenamento. Isso pressupõe, para o processamento comercial que, se os dados ou código foi referenciado no passado, ele provavelmente vai ser referenciado no futuro, também. LRU é boa para o acesso aleatório, tal como num ambiente online.
    – Um algoritmo sequencial é usado para acesso sequencial. Depois que os dados são acessados em uma camada alta (como a main storage), ele pode ser rebaixado para o cache DASD porque não há chances para uma nova visita.
    • O que fazer com os dados que foram atualizados em uma camada volátil? Neste caso, há também dois algoritmos que podem ser utilizados:
    – Store-in, em que a atualização dos dados é mantido na camada volátil (main storage, por exemplo), sem ser copiados para a camada inferior não-volátil (cache DASD, por exemplo). Este algoritmo favorece o desempenho, mas exige um log para manter integridade de gravação. Exemplos de store-in incluem o cache L2 e o DB2 buffer pool no virtual storage (main storage).
    – Store-through, onde os dados atualizados é imediatamente (síncrono) copiados para a camada inferior volátil (geralmente exigindo uma operação de I/O para o cache DASD). Este algoritmo favorece a integridade de gravação, mas não ajuda no desempenho. Exemplos de store-through incluem o cache L1 e o VSAM buffer pool no virtual storage (main storage).
    • Como problemas de integridade podem ser resolvidos quando as camadas inferiores são partilhadas entre cópias diferentes de sistemas z/OS? Esta partilha de dados melhora a disponibilidade contínua (24/7), mas um Coupling Facility é necessário.
  • Role of a system programmer
    A função do system programmer é instalar, customizar e manter o sistema operacional. O Sistema Operacional z/OS é executado em várias configurações de hardware. Um system programmer deve definir os recursos de configuração de E/S de hardware que devem estar disponíveis para o sistema operacional z/OS. O hardware usado pode ser da IBM ou de outro fabricante. Como um system programmer z/OS, você deve estar ciente do seguinte:
    • Conceitos de armazenamento
    • Conceitos de armazenamento virtual e address spaces
    • Configurações de dispositivos I/O
    • Configurações do Processador
    • Definições de Console
    • System libraries em que o software é colocado
    • System data sets e seus posicionamentos
    • Parâmetros de customização que são utilizados para definir a configuração z/OS
    • Execução da tarefa de análise de desempenho por meio do uso de monitores de desempenho como o RMF
  • System operations
    Introdução e gerenciamento de novas cargas no sistema, tais como tarefas em lote e processamento de transações on-line, podem envolver também os system programmers individuais que estão sendo designados para suportar os diversos tipos de cargas que executam no complexo.
    Os system programmers devem ser hábeis para a depuração de problemas com o software do sistema. Esses problemas geralmente são capturadas em uma cópia do conteúdo da memória do computador chamado de dump, que o sistema produz em resposta a uma falha de produto de software, tarefa do usuário ou transação. Utilizando o dump e as ferramentas de depuração especializadas, o system programmer pode determinar quais os componentes falharam. Quando o erro ocorre em um produto de software, o system programmer trabalha diretamente com o fornecedor de software para relatar o problema e esperar por uma correção potencial para a instalação.
  • z/OS system programmer management overview
    Como um system programmer z/OS, você precisa estar envolvido na customização de itens. Esses itens são explicados aqui.
    Address spaces: Quando o Sistema Operacional z/OS é iniciado, z/OS estabelece os espaços de endereço componentes do sistema.
    Paging: Os conjuntos de dados de página contêm as partes paginadas para fora dos espaços de endereço, a área de serviço comum (CSA), PLPA, e os dados gravados em conjuntos de dados de E/S virtual (VIO).
    Dispatching work: O planejamento de espaços de endereço como unidades despacháveis para execução em um CP no sistema z/OS é feita pelo componente dispatcher do z/OS.
    Job flow: z/OS utiliza um subsistema de entrada de tarefa (JES) para receber tarefas (também chamado de batch, que é um tipo não-interativo de transação) no sistema operacional, para planejar o processamento pelo z/OS, e para controlar seu processamento de saída.
    z/OS storage: O system programmer deve estar ciente de todas as considerações de armazenamento durante a instalação e a customização de um ambiente de sistema operacional z/OS.
    System data sets: Cada instalação deve incorporar os conjuntos de dados do sistema necessários para o sistema para alocação de espaço para eles em dispositivos de acesso direto (DASD) durante a instalação do sistema.
    Operator communication: A operação de um sistema z/OS envolve o seguinte:
    – Console de operações
    – Mensagens (produzido pelo z/OS) de processamento e comandos (produzido por um operador) de processamento que constitui a base da interação do operador com o z/OS e a base de automação do z/OS.
    – Gerenciamento de hardware e de software
    Security: Um sistema de segurança (como RACF) deve ser instalado em seu sistema operacional por um system programmer para manter os recursos necessários para cumprir os objetivos de segurança.
    Availability: Os produtos de software dão suporte aos system programmers e operadores na gestão dos seus sistemas com influência na complexidade de seu trabalho e a sua capacidade de manter a disponibilidade do sistema em um alto nível.
    Integrity: Em um sistema operacional é dito ter a integridade do sistema quando ele é projetado, implementado e mantido para se proteger contra o acesso não autorizado, e não de forma na medida em que os controles de segurança especificados para esse sistema não podem ser comprometidos.
  • The system programmer and z/OS operations
    Um system programmer tem que planejar as operações das seguintes áreas:
    • Workload Manager
    Workload Manager (WLM) fornece uma solução para gerenciar a distribuição de carga, o equilíbrio de carga, e distribuição dos recursos para cargas de concorrentes.
    • System performance
    O ajuste inicial consiste em selecionar os parâmetros apropriados para vários componentes do sistema e subsistemas. Quando os requisitos do sistema aumentam e ele se torna necessário para a mudança de prioridades ou adquirir recursos adicionais, como um processador maior, mais memória, ou mais terminais, os objectivos do WLM podem ter que serem ajustados para refletir as condições alteradas.
    • I/O device configuration
    Como um system programmer, você deve definir uma configuração de E/S para o sistema operacional (software) e o subsistema de canal (hardware). O componente de Hardware Configuration Definition (HCD) do z/OS consolida o hardware e o software da configuração de processos de E/S em uma interface com o usuário final interativa única.
    • Console operations
    A operação de um sistema z/OS envolve o seguinte:
    – Console de operações, ou como os operadores interagem com o z/OS para monitorar ou controlar o hardware e o software
    – Mensagens e comandos de processamento que forma a base de interação do operador com o z/OS e a base de automação do z/OS
    A operação do z/OS envolve gerenciamento de hardware como processadores e dispositivos periféricos (incluindo os consoles que os operadores fazem o seu trabalho) e de software, como o sistema de controle operacional z/OS, o subsistema de entrada de jobs, subsistemas como o NetView que podem controlar as operações automatizadas, e de todos os aplicativos que são executados no z/OS.
    Como as mensagens são também a base de operações automatizadas, entender o processamento de mensagens em um sistema z/OS podem ajudá-lo a planejar a automação do z/OS.
  • IBM zOS Basics

    1. 1. Z/OS BASICS Anderson David de Souza 14 November 2013 1.0
    2. 2. 2 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    3. 3. 3 Arquitetura do z/OS (Hardware e software) Sistema Operacional z/OS –Servidor de comunicação –Serviços de dados e arquivos –Suporte ao sistema Parallel Sysplex –POO – Distributed Computer Environment (DCE) –Interface de aplicação aberta z/OS possui base MVS –Confiabilidade –Disponibilidade continua –Segurança –Suporte a grande volume de transações –Suporte a grandes números de usuários –Avançado sistema e gerenciamento de rede –Disponibilidade 24/7
    4. 4. 4 Arquitetura do z/OS (Hardware e software) z/OS services –Data management –Softcopy publications services –Security services –System management services –Network communication services –Applications enablement services –z/OS UNIX System Services –Distributed computing services –e-Business services –Print services z/OS functional enhancements –z/OS Versão 1Release 1 substituto do OS/390 –Destaque à 64-bit z/Architecture •Elimina o armazenamento expandido •Ajuda a eliminar paginação •Sistemas atuais em menos LPARs ou a uma única imagem nativa
    5. 5. 5 Arquitetura do z/OS (Hardware e software) Software and hardware evolution –Base no CMOS - Complementary Metal Oxide Semiconductor • Menores em tamanho e maior em capacidade • Desempenho a um custo mais baixo –S/390 paralelos em 1994 • Mainframe revivido •zSeries CMOS e S/390 CMOS ou ES/9000 formam um Sysplex Paralelo –z/OS do servidor zSeries em 2001 z/Architecture –Registros gerais de 64 bits e registradores de controle –Endereçamento de 64 bits, além dos modos de 24 e de 31 bits do ESA/390 –Até três níveis adicionais de tabelas dynamic-address-translation (DAT) –8 K-byte para PSWs maiores e register save areas –Muitas das novas instruções, muitas das quais operam em inteiros binários de 64 bits
    6. 6. 6 Arquitetura do z/OS (Hardware e software) IBM server and operating system evolution
    7. 7. 7 Arquitetura do z/OS (Hardware e software) z/OS operating systems and hardware –z/OS V1R12 executa em qualquer Servidor IBM System z z/OS and workloads –z/OS no zSeries
    8. 8. 8 Arquitetura do z/OS (Hardware e software) Hardware requirements –Base do z/OS •Executada em um processador •Reside no armazenamento do processador –Software •Load modules z/OS –Hardware •Dispositivos •Controladores •Processadores –Dispositivos •Tape •DASD •Consoles –Armazenamento
    9. 9. 9 Arquitetura do z/OS (Hardware e software) Basic mode and LPAR mode –Modo LPAR •CP em Power-on Reset –Modo básico •CP com um z/OS
    10. 10. 10 Arquitetura do z/OS (Hardware e software) z/OS base elements
    11. 11. 11 Arquitetura do z/OS (Hardware e software) z/OS optional features – Unpriced – Priced
    12. 12. 12 Arquitetura do z/OS (Hardware e software) Base control program functions – BCP, backbone do z/OS –Serviços essenciais ao SO •BCP e JES –BCP requer: •Um produto de segurança (RACF) •DFSMSdfp •Communications Server •SMP/E •TSO/E •z/OS UNIX System Services (z/OS UNIX) kernel –Componentes BCP importantes •System Management Facilities (SMF) •Resource Management Facility (RMF) •Workload Manager (WLM) –Recursos opcionais interessantes •Infoprint Server
    13. 13. 13 Arquitetura do z/OS (Hardware e software) Computer security –Segurança RACF component (z/OS Security Server) –Controle flexível ao acesso a recursos protegidos –Proteção dos recursos de instalação –Informação de outros produtos –Controle centralizado ou descentralizado de perfis –Interface do painel ISPF –Transparência aos usuários –Saída para rotinas de instalação RACF security protection –ID de usuário –Senha ou frase criptografada RACF authorization checks –Autorização de recursos
    14. 14. 14 Arquitetura do z/OS (Hardware e software) Data Facility Storage Management Subsystem (DFSMS) component – Ajuda a automatizar e centralizar o gerenciamento de armazenamento –Storage Management Subsystem (SMS) –DFSMS •Data Facility Product (dfp) •Data Set Services (dss) •Hierarchical Storage Manager (hsm) •Removable Media Manager (rmm) •Transactional VSAM Services (tvs) Network File System (NFS) –Sistema de arquivo distribuído • Acessar arquivos UNIX • Acessar diretórios remotos
    15. 15. 15 Arquitetura do z/OS (Hardware e software) DFSMS and XRC –Cópias de dados Extended Remote Copy (XRC) –Cópia remota de dados críticos Peer-to-Peer Remote Copy (PPRC) –Solução de hardware para recuperação de desastre –Solução Workload e migração DASD
    16. 16. 16 Arquitetura do z/OS (Hardware e software) z/OS Communications Server –Protocolos de comunicação •Conectividade peer-to-peer TCP/IP –Protocolos e aplicações Computer network
    17. 17. 17 Arquitetura do z/OS (Hardware e software) System Modification Program Extended (SMP/E) –Gerenciar a instalação de Softwares –Acompanhar as modificações PTFs –Correção de software CSI data sets –Nome do elemento –Tipo –História –Forma de introdução no sistema –Ponteiro Installing service –Serviço corretivo à target
    18. 18. 18 Arquitetura do z/OS (Hardware e software) Time Sharing Option/Extended (TSO/E) –Interatividade com o z/OS TSO/E environments –Line Mode TSO/E –ISPF/PDF –Information Center facility CLIST language –TSO/E e JCL com programação REXX EXECs –Versatilidade TSO/E commands and programs –Assembler, COBOL –Fortran, Pascal –PL/I, REXX e CLIST
    19. 19. 19 Arquitetura do z/OS (Hardware e software) z/OS UNIX System Services –OS/390 V2R4 ... BCP FMID ISPF shell (interface de painel) HFS and zFS –Acessar dados do sistema de arquivos z/OS UNIX kernel –Suporte para serviços UNIX z/OS ISHELL or OMVS shell –Escolha entre interface z/OS UNIX dbx debugger –Depuração de programas em C Shell and utilities –Comando TSO/E para entrar no ambiente shell –Desenvolvimento e execução de aplicativos –Utilitários para administrar e desenvolver em um ambiente UNIX
    20. 20. 20 Arquitetura do z/OS (Hardware e software) z/OS UNIX interactions with z/OS –C/C++ Compiler –Language Environment –Data Facility Storage Management Subsystem –z/OS Security Server –Resource Measurement Facility (RMF) –System Display and Search Facility (SDSF) –Time Sharing Option Extensions (TSO/E) –Serviços TCP/IP –ISPF –BookManager READ
    21. 21. 21 Arquitetura do z/OS (Hardware e software) z/OS UNIX physical file systems –Pacote com módulos de carregamento MVS PFS interface –Protocolos e chamadas entre LFS e PFSS –PFSS •Gerência de arquivos •Gerência de soquetes HFS-to-zFS migration –Estabilização HFS PFS Advantages of zFS –Melhor desempenho –Arquitetura subjacente suporta funções adicionais –Recuperação de falha aprimorada
    22. 22. 22 Arquitetura do z/OS (Hardware e software) System Management Facility (SMF) –Billing de usuários –Reporting de confiabilidade –Analise de configuração –Agendamento de jobs –Resumo de atividade do direct access volume –Avaliação de atividade do conjunto de dados –Perfil de uso dos recursos do sistema –Manutenção e auditoria de segurança do sistema SMF data collection –Sistema ou Job Installation SMF routines – Rotinas como parte do SMF • Recebe controle
    23. 23. 23 Arquitetura do z/OS (Hardware e software) Resource Measurement Facility (RMF) –Dados de desempenho (Monitores) •Dados de curto prazo (III) •Monitoramento instantâneo (II) •Dados a longo prazo (I) SMF records – Ciclo específico (1s) –Tempo especifico p/ dados consolidados (30min) RMF Monitor I, II and III –Monitor I •Workload •Utilização de recursos •Abrange hardware e software –Monitor II •Snapshots de z/OS key fields –Monitor III •Análise de Contenção (adress space utilizado e delay states)
    24. 24. 24 Arquitetura do z/OS (Hardware e software) Workload management –Objetivo de negócio WLM goal mode –Simples consistências do sistema Subsystems using WLM – Soluções workload • Gerenciamento de distribuição • Balanceamento • Distribuição de recursos –Cooperação conjunta de subsistemas • CICS, IMS/ESA®, JES, APPC • TSO/E, z/OS UNIX System Services • DDF, DB2®, SOM, LSFM, e Internet Connection Server WLM service policy –Gestão de desempenho MVS • SLAs
    25. 25. 25 Arquitetura do z/OS (Hardware e software) Infoprint Server overview – Aplicativo UNIX –Servidor de impressão em TCP/IP –Print Interface •Processa solicitações de impressão –IP PrintWay •Output data sets do JES2/JES3 –NetSpool •Intercepta impressões de dados VTAM •Transforma os fluxos de dados •Escreve o output data set ao spool JES –Infoprint Central •Sistema de gerenciamento de impressão
    26. 26. 26 Arquitetura do z/OS (Hardware e software) z/OSMF –Gerenciamento de sistemas z/OS –system programmers Related system components – Conjunto de aplicações web –Dojo • Visa resolver problemas históricos com DHTML •Crie sites úteis, ágeis e funcionais. –WebSphere utiliza: •Common Information Model (CIM) •Common Event Adapter (CEA) •System REXX –Incident Log task utiliza: • CÏM, CEA, System REXX
    27. 27. 27 Arquitetura do z/OS (Hardware e software) IBM Health Checker for z/OS –Identificar potenciais problemas –Compara as configurações (Atuais ou IBM) –Produz mensagens detalhadas Health Checker for z/OS processing –Verifica os valores dos componentes –Verifica a saída •Exceção OMC –Resolver exceções –Garantir resolução
    28. 28. 28 Arquitetura do z/OS (Hardware e software) z/OS release cycle
    29. 29. 29 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    30. 30. 30 Arquitetura de arquivos (sequencial, particionado e VSAM)  O que é um data set? – Uma coleção de dados relacionados logicamente, que pode ser um código de programa, uma biblioteca de macros ou um arquivo de registros de dados usados por um programa em processamento  Tipos de data sets – Data set sequencial Os registros são itens de dados que são armazenados consecutivamente – Data set particionado ou PDS Consiste em um diretório e membros – Virtual Storage Access Method (VSAM) key sequenced data set (KSDS) Os registros são itens de dados que são armazenados com informações de controle (chaves) para que o sistema possa recuperar um item sem ter de procurar todos os itens anteriores no conjunto de dados
    31. 31. 31 Arquitetura de arquivos (sequencial, particionado e VSAM)  Onde são armazenados data sets? – Secondary storage devices • Direct access storage device (DASD) • Magnetic tape volume
    32. 32. 32 Arquitetura de arquivos (sequencial, particionado e VSAM)  O que são access methods? – Define a técnica que é utilizada p/ armazenar e recuperar dados – Têm as suas próprias estruturas data set para organizar os dados, programas fornecidos pelo sistema para definir data sets e programas utilitários para processar data sets – São identificados principalmente pela organização do data set – Um data set sequencial criado usando BSAM pode ser processado pelo BDAM – Métodos de acesso comumente usados • QSAM Queued Sequential Access Method (fortemente usado) • BSAM Basic Sequential Access Method (para casos especiais) • BDAM Basic Direct Access Method (se tornando obsoleto ) • BPAM Basic Partitioned Access Method (para libraries) • VSAM Virtual Storage Access Method (utilizado para aplicativos mais complexos)
    33. 33. 33 Arquitetura de arquivos (sequencial, particionado e VSAM)  Como são utilizados DASD volumes – Pode ser utilizado por vários data sets e o espaço pode ser realocado e reutilizado – Em um volume, o nome de um data set deve ser exclusivo – Um data set pode ser localizado por tipo de dispositivo, volser e nome do data set – Embora diferem em aparência física, capacidade e velocidade, eles são semelhantes na gravação de dados, verificação de dados, formato de dados e programação – Terminologia DASD para usuários UNIX e PC • Direct Access Storage Device (DASD) é outro nome para um disk drive (disk volume, disk pack, ou Head Disk Assembly (HDA)) • Um disk drive contém cilindros • Cilindros contém tracks • Tracks contém data records e estão em formato Count Key Data (CKD) • Data blocks são as unidades de gravação em disco – O que são DASD labels • O SO usa grupos de labels para identificar volumes DASD e os data sets que contêm. Um label de volume, armazenado na trilha 0 do cilindro 0, identifica cada volume DASD
    34. 34. 34 Arquitetura de arquivos (sequencial, particionado e VSAM)  Alocando um data set – Para usar um data set, você primeiro deve alocá-lo, em seguida, acessar os dados usando macros para o método de acesso que você escolheu – A atribuição de um data set significa • Criar espaço para um novo data set em um disco • Estabelecer um link lógico entre um job step e qualquer data set – Outras formas de alocar um data set incluem • Access method services Programa de serviços multifuncionais, incluem os comandos mais usados para trabalhar com data sets, tais como ALLOCATE, ALTER, DELETE, e PRINT • ALLOCATE Comando TSO ALLOCATE para criar data sets • ISPF menus Interactive System Productivity Facility, guia o usuário através da atribuição de um data set • Using JCL Job control language para alocar data sets
    35. 35. 35 Arquitetura de arquivos (sequencial, particionado e VSAM)  Como são nomeados data sets – Pode ser um name segment, ou uma série de name segments – Segments ou qualifiers são limitados a 8 caracteres, o primeiro dos quais deve ser alfabético (A a Z) ou especial (#, @ ou $), os restantes 7 caracteres são ou alfabéticos, ou numéricos (0 – 9), ou especial, ou um hífen (-) – Name segments são separados por ponto (.) – Incluindo todos os name segments e pontos, o comprimento do nome do data set não deve exceder 44 caracteres, então 22 name segments pode fazer um nome de data set
    36. 36. 36 Arquitetura de arquivos (sequencial, particionado e VSAM)  Data set record formats – Data sets z/OS tradicionais são diferentes de arquivos em sistemas PC e UNIX – No z/OS, não há caracteres new line (NL) ou carriage return e line feed (CR + LF) para indicar o final de um registro – Data sets z/OS tradicionais têm um dos cinco formatos de registros • F (Fixed), FB (Fixed Blocked), V (Variable), VB (Variable Blocked), U (Undefined) – Um bloco é o que está escrito no disco, enquanto um registro é uma entidade lógica • Block Size (BLKSIZE) Tamanho do bloco físico escrito no disco para registros F e FB. Para V, VB, e U, é o tamanho máximo do bloco físico usado para o data set • Logical Record Size (LRECL) Tamanho lógico do registro (F ou FB) ou o tamanho máximo lógico do registro permitido (V ou VB) para o data set. (U) não têm LRECL • Record Format (RECFM) F, FB, V, VB, ou U, como descrito acima – Esses termos são conhecidos como características data control block (DCB), nomeado para o control block onde podem ser definidos em um programa em linguagem assembly
    37. 37. 37 Arquitetura de arquivos (sequencial, particionado e VSAM)  Data set record formats
    38. 38. 38 Arquitetura de arquivos (sequencial, particionado e VSAM)  Tipos de data sets – Sequential, Partitioned, VSAM – O que é um sequential data set • A estrutura de dados simples em um sistema z/OS é um data set sequencial. Consiste em um ou mais registros que estão armazenados na ordem física e processados em sequência. Novos registros são acrescentados ao final do data set • Job control language (JCL), organização de data set PS (DSORG = PS), que significa physical sequential • Tapes armazenam data sets sequenciais – O que é um partitioned data set • PDS é uma coleção de data sets sequenciais, chamados de members • Contém também um diretório que contém uma entrada para cada membro no PDS com uma referência (ou ponteiro) para o membro • Um data set particionado é comumente referido como uma library • Um PDS perde espaço quando um membro é atualizado ou adicionado. Usuários do z/OS regularmente necessitam comprimir um PDS para recuperar o espaço perdido • JCL, organização data set PO (DSORG = PO), que representa partitioned organization.
    39. 39. 39 Arquitetura de arquivos (sequencial, particionado e VSAM)  Tipos de data sets – O que é um partitioned data set extended • Partitioned data set extended (PDSE) consiste em um diretório e zero ou mais membros, assim como um PDS. Data sets PDSE são armazenadas somente no DASD, e não em fita. • O diretório pode expandir automaticamente, conforme necessário, até o limite de endereçamento de 522.236 membros. Também tem um índice, que oferece uma busca rápida por nomes de membros. Espaço dos membros excluídos ou movidos são automaticamente reutilizados para novos membros. Cada membro de um PDSE pode ter até 15.728.639 registros. Um PDSE pode ter um máximo de 123 extensões, mas não pode se estender além de um volume. Quando um diretório de um PDSE está em uso, ele é mantido no armazenamento do processador para o acesso rápido. • Data sets PDSE podem ser usados em lugar de quase todos os data sets PDS que são utilizados para armazenar dados. Mas o formato PDSE não pretende ser um substituto PDS. Quando um PDSE é usado para armazenar load modules, armazena-os em estruturas chamadas de program objects.
    40. 40. 40 Arquitetura de arquivos (sequencial, particionado e VSAM)  Tipos de data sets
    41. 41. 41 Arquitetura de arquivos (sequencial, particionado e VSAM)  O que é Virtual Storage Access Method – VSAM aplica-se tanto a um tipo de data set e o método de acesso. Oferece funções muito mais complexas do que outros métodos de acesso ao disco. Mantém registros de disco em um formato exclusivo, não compreensível por outros métodos de acesso. Usado mais para aplicações. Não podem rotineiramente ser exibidos/editados com ISPF • Key Sequence Data Set (KSDS): Cada registro tem um ou mais campos-chave e um registro pode ser recuperado (ou inserido) pelo valor da chave • Entry Sequence Data Set (ESDS): Registros em ordem sequencial, podem ser acessados sequencialmente. Usado por IMS, DB2, e z/OS UNIX • Relative Record Data Set (RRDS): Permite a recuperação de registros por número: registro 1, registro 2, e assim por diante • Linear Data Set (LDS): Isto é, em efeito, um data set byte-stream e é a única forma de um data set byte-stream definido em arquivos tradicionais z/OS (ao contrário de arquivos z/OS UNIX) – Funciona com uma área de dados lógica conhecida como um control interval (CI). Vários CIs são colocados em uma control area (CA). Um data set VSAM consiste em áreas de controle e índice de registros. Dados VSAM são sempre de comprimento variável e os registros são bloqueados automaticamente em intervalos de controle
    42. 42. 42 Arquitetura de arquivos (sequencial, particionado e VSAM)  Catalogs e volume table of contents – O que é um volume table of contents • Registro 1, na 1º faixa do 1º cilindro, fornece o rótulo para o disco, contém o 6- character volume serial number (volser) e um ponteiro para o volume table of contents (VTOC). O VTOC lista os data sets que residem em seu volume. O ICKDSF é usado para criar o rótulo e VTOC. O VTOC também tem entradas para todo o espaço livre no volume. Você também pode criar um VTOC com um índice. O índice VTOC é um data set com o nome SYS1.VTOCIX.volser, que tem entradas dispostas em ordem alfabética pelo nome do data set com ponteiros para as entradas VTOC. Ele também tem bitmaps do espaço livre no volume. – O que é um catalog • Um catálogo descreve um atributo de data set e indica os volumes em que um data set está localizado. Os data sets podem ser catalogados, descatalogados ou recatalogados. No z/OS, o master catalog e user catalogs armazenam as localizações dos data sets. Para encontrar um data set, o z/OS deve saber três informações: Data set name, Volume name e Unit. Um system catalog é usado para armazenar e recuperar a localização UNIT e VOLUME de um data set. Com esta facilidade, o usuário só precisa fornecer um nome de data set.
    43. 43. 43 Arquitetura de arquivos (sequencial, particionado e VSAM)  Catalogs e volume table of contents – No z/OS, é possível catalogar atualizações sucessivas ou gerações de dados relacionados, chamados generation data groups (GDGs). Cada data set em um GDG é chamado generation/generation data set (GDS). GDG é uma coleção de data sets não- VSAM historicamente relacionados organizados em ordem cronológica. Dentro de um GDG, as gerações podem ter semelhantes ou não atributos DCB e organizações data set. Se os atributos e organizações de todas as generations em um grupo são idênticos, as generations podem ser recuperados em conjunto como um único data set • Todos os data sets no grupo podem ser referidos por um nome comum • O sistema operacional é capaz de manter as generations em ordem cronológica • Generations desatualizadas/obsoletas podem ser excluídas automaticamente no SO – Generation data sets tem ordenado sequencialmente absolute e relative names. Data sets mais antigos têm números absolutos menores. O nome relativo é um inteiro usado para referir os mais recentes (0), o próximo mais recente (-1), e assim por diante – Um generation data group (GDG) de base é alocado em um catálogo antes que os generation data sets são catalogados. Cada GDG é representado por uma entrada de base GDG
    44. 44. 44 Arquitetura de arquivos (sequencial, particionado e VSAM)  z/OS UNIX file systems – Ao contrário de uma biblioteca tradicional z/OS, um sistema de arquivos UNIX é hierárquico e orientado a byte. Para localizar um arquivo em um sistema de arquivos UNIX, você procura um ou mais diretórios. Não existe o conceito de um catálogo z/OS que aponta diretamente para um arquivo. z/OS UNIX System Services (z/OS UNIX) permite que os usuários do z/OS criem sistemas de arquivos UNIX e árvores de diretório do sistema de arquivos no z/OS, para acessar os arquivos do UNIX no z/OS e outros sistemas – Você pode usar os seguintes tipos de sistema de arquivos com z/OS UNIX: • System z File System (zFS), que é um sistema de arquivo que armazena arquivos em data sets VSAM lineares • Hierarchical file system (HFS), um sistema de arquivos montável, que está sendo eliminado pelo zFS • z/OS Network File System (z/OS NFS), que permite que um sistema z/OS acesse um sistema de arquivos remoto UNIX (z/OS ou não-z/OS) sobre TCP/IP, como se fosse parte do local da árvore de diretórios z/OS • Temporary file system (TFS), que é um temporário, sistema de arquivo em memória física que suporta os sistemas de arquivos montáveis em storage
    45. 45. 45 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    46. 46. 46 Alocação de arquivos utilizando TSO (Sequencial e particionado) TSO/E –Interação com o z/OS –Interface –Serviços de programação TSO/E users –Vantagens para usuários
    47. 47. 47 Alocação de arquivos utilizando TSO (Sequencial e particionado) TSO/E highlights –Session Manager –Commands –Online help –Console –Support for z/OS UNIX –CLIST –REXX –Data and notice handling –Security
    48. 48. 48 Alocação de arquivos utilizando TSO (Sequencial e particionado)  Exemplo 1 – Alocar um novo data set sequencial com espaço alocado • New data set name: USER.EX1.DATA • Number of tracks: 2 • Logical record length: 80 • DCB block size: 8000 • Record format: fixed block  ALLOC DA(EX1.DATA) + DSORG(PS) SPACE(2,0) TRACKS + LRECL(80) BLKSIZE(8000) RECFM(F,B) NEW
    49. 49. 49 Alocação de arquivos utilizando TSO (Sequencial e particionado)  Exemplo 2 – Alocar um novo data set particionado com espaço alocado • New data set name: USER.EX2.DATA • Block length: 200 bytes • Logical record length: 100 • DCB block size: 200 • Number of directory blocks: 2 • Record format: fixed block  ALLOC DA(EX2.DATA) + DSORG(PO) BLOCK(200) SPACE(10,10) + LRECL(100) BLKSIZE(200) + DIR(2) RECFM(F,B) NEW
    50. 50. 50 Alocação de arquivos utilizando TSO (Sequencial e particionado)  Exemplo 3 – Alocar um novo data set sequencial com predefinição • New data set name: DATA3.EX3.DATA • Block length: 800 bytes • Logical record length: 80 • Record format: fixed block  ALLOC DA('DATA3.EX3.DATA') + BLOCK(800) LRECL(80) DSORG(PS) + RECFM(F,B) NEW
    51. 51. 51 Alocação de arquivos utilizando TSO (Sequencial e particionado)  Exemplo 4 – Alocar um novo data set sequencial usando um attribute • The name that you want to give the new data set: USER.EX4.DATA • The number of tracks expected to be used: 10 • DCB operands are in an attribute list named: ATRLST1  ATTRIB ATRLST1 + DSORG(PS) LRECL(80) BLKSIZE(3200)  ALLOC DA(EX4.DATA) NEW + SPACE(10,2) TRACKS USING(ATRLST1)
    52. 52. 52 Alocação de arquivos utilizando TSO (Sequencial e particionado)  Exemplo 5 – Alocar um novo data set particionado com espaço alocado • New data set name: USER.EX5.DATA • Block length: 1000 bytes • DCB attributes taken from attribute list: ATRLST2  ATTRIB ATRLST2 + DSORG(PO) LRECL(100) BLKSIZE(200)  ALLOC DA(EX5.DATA) + USING(ATRLST3) BLOCK(1000) + SPACE(10,10) NEW
    53. 53. 53 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    54. 54. 54
    55. 55. 55 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    56. 56. 56 Conceitos de instalação no z/OS (SMP/E) System Modification Program Extended (SMP/E) –Gerenciar a instalação de produtos de software –E acompanhar as modificações
    57. 57. 57 Conceitos de instalação no z/OS (SMP/E) Entendendo o sistema –O z/OS pode parecer ser um grande bloco de código que movimenta sua CPU, na verdade, o z/OS é um sistema complexo com diversos blocos menores de código, cada um desses blocos menores de código executam uma função específica no sistema z/OS
    58. 58. 58 Conceitos de instalação no z/OS (SMP/E)  Entendendo o sistema – Cada função do sistema é composta por um ou mais load modules • Unidade básica legível por máquina, código executável
    59. 59. 59 Conceitos de instalação no z/OS (SMP/E)  Alterando os elementos do sistema – Modificações no sistema (SYSMODs) • Modification control statements (MCS), ++ Quais elementos estão sendo atualizados/substituídos Como o SYSMOD se refere ao software e outros SYSMODs Outras informações de instalação especificas • Modification text Object modules, macros, e outros elementos – Categorias SYSMODs • Function SYSMODs • PTF (program temporary fix) SYSMODs • APAR (authorized program analysis reports) SYSMODs • USERMOD (user modifications) SYSMODs
    60. 60. 60 Conceitos de instalação no z/OS (SMP/E)  Mantendo o controle dos elementos do sistema – Acompanhamento e controle de requisitos • Function modification identifiers (FMIDs) Identifica a function SYSMOD que introduz o elemento no sistema • Replacement modification identifiers (RMIDs) Identifica a última SYSMOD (usualmente a PTF SYSMOD) para substituir o elemento • Update modification identifiers (UMIDs) Identifica as SYSMODs que atualizaram um elemento desde a última vez que ele foi substituído
    61. 61. 61 Conceitos de instalação no z/OS (SMP/E)  Distribution and target libraries
    62. 62. 62 Conceitos de instalação no z/OS (SMP/E)  Consolidated software inventory (CSI) – Zonas SMP/E • Distribution zone • Target zone • Global zone – Global zone • Entradas necessárias para identificar e descrever cada target e distribution zone • Informações sobre SMP/E processing options • Informações de status para todos SYSMODs SMP/E iniciados • Dados de exceção (geralmente HOLDDATA) para SYSMODs que requerem tratamento especial ou que estão em erro – HOLDDATA, uma SYSMOD especifica mantida desde a instalação • A PTF contém erro e não deve ser instalada antes da correção (ERROR HOLD) • Ações do sistema podem ser necessárias antes da instalação (SYSTEM HOLD) • O usuário pode querer executar ações antes de instalar o SYSMOD (USER HOLD)
    63. 63. 63 Conceitos de instalação no z/OS (SMP/E)  Definindo a zona que você deseja trabalhar – Comando SET  Recebendo o SYSMOD em SMP/E data sets – Comando RECEIVE  Aplicando o SYSMOD às target libraries – Comando APPLY  Restaurando as target libraries a um nível anterior – Comando RESTORE  Aceitando o SYSMOD e atualizando as distribution libraries – Comando ACCEPT
    64. 64. 64 Conceitos de instalação no z/OS (SMP/E)  Exibindo dados SMP/E – Query dialogs • Informações específicas que você solicita em diálogos interativos SMP/E – LIST command • Gera uma lista de informações sobre o sistema – REPORT commands • Verifica, compara e gera informações do conteúdo das zonas no sistema – SMP/E CSI application programming interface • Pode ser usado para escrever programas de aplicação para consultar o conteúdo dos CSI data sets do seu sistema
    65. 65. 65 Conceitos de instalação no z/OS (SMP/E)  Fluxo do processamento SMP/E SYSMOD
    66. 66. 66 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    67. 67. 67 Conceitos de memória z/OS  Processor storage overview – Main storage e um ou mais central processing units (Cps) – Tecnologia da main storage • Processador diretamente acessível • Ela é volátil, rápida, e cara, comparados com armazenamento magnético
    68. 68. 68 Conceitos de memória z/OS  Adress space – Intervalo de endereços virtuais que o SO atribui a um usuário ou separadamente executa o programa é chamado de um address space. Área contígua de endereços virtuais disponíveis à execução de instruções e o armazenamento de dados  Previous IBM architectures – System/370, 1ª arquitetura IBM a utilizar conceitos de virtual storage e address space • S/370 utiliza 24 bits para endereçamento. Portanto, o maior endereço acessível no MVS/370 foi de 16 MB, que também foi o tamanho do address space – MVS/XA, a arquitetura XA aumentou para 31 bits para endereçamento e o tamanho do address space passou de 16 MB (line) para 2 GB (128x) – Bit de ordem superior do endereço: 31 bits (bit 32 on) ou de 24 bits (bit 32 off)  z/OS z/Architecture – Com o z/OS, a z/Architecture extendeu a 64 bits e o tamanho do address space passou de 2 GB (the bar) para 16 EB (8 GBx)
    69. 69. 69 Conceitos de memória z/OS  Address space concept
    70. 70. 70 Conceitos de memória z/OS  Addressing mode – AMODE – AMODE é um atributo de programa para indicar qual modo de endereçamento que deve estar ativo quando um programa é inserido • AMODE=24: O programa pode enviar até 16 M de endereços virtuais (24 bits) • AMODE=31: O programa pode enviar até 2 G de endereços virtuais (31 bits) • AMODE=ANY: O programa foi projetado ao modo de endereçamento 24 bit ou 31 bit • AMODE=64: O programa pode enviar até 16 E de endereços virtuais (z/Architecture)  Residency mode – RMODE – Utilizado para indicar onde um programa deve ser colocado no virtual storage (by z/OS program management) quando o sistema o carrega a partir do DASD • RMODE=24: O module deverá residir abaixo dos 16 MB da linha do virtual storage. Entre as razões para RMODE24 é que o programa é AMODE24 • RMODE=ANY: O module pode residir em qualquer lugar no virtual storage, mas preferencialmente acima dos 16 MB da linha do virtual storage. Por isso, um RMODE é também chamado de RMODE 31. Observe, no z/OS não há RMODE=64, o virtual storage acima de 2 G não é adequado para programas, apenas dados
    71. 71. 71 Conceitos de memória z/OS  Addressing mode and residence mode
    72. 72. 72 Conceitos de memória z/OS  Storage managers – O armazenamento é gerenciado pelos seguintes componentes z/OS • Virtual Storage Manager • Real Storage Manager • Auxiliary Storage Manager
    73. 73. 73 Conceitos de memória z/OS  z/OS address spaces – Master scheduler initialization routines inicializa serviços de sistema – Address space id (ASID)  System component address spaces – Além de áreas de inicialização do sistema, o MVS estabelece system component address spaces, address space para o master scheduler address space e outros address spaces do sistema para vários subsystems e componentes do sistema
    74. 74. 74 Conceitos de memória z/OS  Memory hierarchy
    75. 75. 75 Agenda Arquitetura do z/OS (Hardware e software) Arquitetura de arquivos (sequencial, particionado e VSAM) Alocação de arquivos utilizando TSO (Sequencial e particionado) Alocação de arquivo VSAM KSDS (Com a lista do catálogo) Conceitos de instalação no z/OS (SMP/E) Conceitos de memória z/OS Quais são as principais responsabilidades do z/OS System Programmer
    76. 76. 76 Quais são as principais responsabilidades do z/OS System Programmer  Role of a system programmer – Instalar, customizar e manter o sistema operacional • Conceitos de armazenamento • Conceitos de armazenamento virtual e address spaces • Configurações de dispositivos I/O • Configurações do Processador • Definições de Console • System libraries em que o software é colocado • System data sets e seus posicionamentos • Parâmetros de customização para definir a configuração z/OS • Execução da tarefa de análise de desempenho (RMF)
    77. 77. 77 Quais são as principais responsabilidades do z/OS System Programmer  System operations – Introdução e gerenciamento de novas cargas no sistema, tais como tarefas em lote e processamento de transações on-line, podem envolver também os system programmers – System programmers devem ser hábeis para a depuração de problemas com o software do sistema. Esses problemas geralmente são capturados em uma cópia do conteúdo da memória do computador (dump), que o sistema produz em resposta a uma falha de produto de software, tarefa do usuário ou transação
    78. 78. 78 Quais são as principais responsabilidades do z/OS System Programmer  z/OS system programmer management overview
    79. 79. 79 Quais são as principais responsabilidades do z/OS System Programmer  The system programmer and z/OS operations – Um system programmer tem que planejar as operações das seguintes áreas: • Workload Manager • System performance • I/O device configuration • Console operations

    ×