Rational Developer para System z

IBM Rational Developer for System z Versão 9.0.1

Guia de Referência de Configuração do Host


S517-9857-06
Nota

Antes de usar estas informações, certifique-se de ler as informações gerais em Avisos sobre a Documentação para o IBM Rational Developer for System z.

Sexta edição (dezembro de 2013)

Esta edição se aplica ao IBM Rational Developer for System z Versão 9.0.1 (programa número 5724-T07) e a todas as liberações e modificações subsequentes, até que seja indicado de outra forma em novas edições.

Solicite as publicações pelo telefone ou fax. O IBM Software Manufacturing Solutions recebe os pedidos de publicações entre 8h30 e 19h, horário padrão na costa leste dos Estados Unidos. O número de telefone é (800) 879-2755. O número de fax é (800) 445-9269. O fax deve ser enviado para: Publications, 3rd floor.

Você também pode solicitar as publicações por meio de um representante IBM ou da filial da IBM que atende em sua região. As publicações não são guardadas no endereço a seguir.

A IBM agradece pelo seu comentário. Você pode enviar os comentários por correio ao seguinte endereço:

IBM Brasil - Centro de Traduções
Rodovia SP 101 Km 09
Rodovia SP 101 Km 09
CEP 13185-900
Hortolândia, SP

É possível enviar um fax com os seus comentários para: 1-800-227-5088 (Estados Unidos e Canadá)

Ao enviar informações à IBM, você concede à IBM o direito não-exclusivo de utilizar ou distribuir as informações da forma que julgar apropriada, sem incorrer em qualquer obrigação para com o Cliente.

Nota para Usuários do Governo dos Estados Unidos - Uso, duplicação ou divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.

Copyright International Business Machines Corporation 2000, 2013.

Conteúdo

Figuras
Tabelas
Sobre este Documento
Quem Deve Usar este Documento
Resumo das Mudanças
Descrição do Conteúdo do Documento
Entendendo o Developer for System z
Considerações de segurança
Considerações de TCP/IP
Considerações WLM
Considerações de Ajuste
Considerações sobre Desempenho
Considerações de Push-to-client
considerações CICSTS
Considerações da Saída de Usuário
Customizando o Ambiente TSO
Executando várias instâncias
Resolução de problemas de configuração
Configurando o SSL e a Autenticação X.509
Configurando o TCP/IP
Guia de Referência de Configuração do Host do IBM Rational Developer for System z
Capítulo 1. Entendendo o Developer for System z
Visão geral do componente
RSE como um aplicativo Java
donos das tarefas
Fluxo de conexão
Depurador Integrado
CARMA
Arquivos de Configuração CARMA
CRASTART
Envio em Lote
Proprietário de Bloco de Conjunto de Dados
Liberando um Bloqueio
Estrutura de diretório do z/OS UNIX
Atualizar Privilégios para Administradores que Não São de Sistema
Comandos de Segurança Úteis
Comandos Úteis do z/OS UNIX
Configuração de Amostra
Capítulo 2. Considerações de segurança
Métodos de autenticação
ID do Usuário e Senha
ID do Usuário e Senha Única
Certificado X.509
Autenticação do JES Job Monitor
Autenticação do Debug Manager
Segurança de conexão
Limitar Comunicação Externa a Portas Especificadas
Criptografia de Comunicação Usando SSL ou TLS
Verificação de Port Of Entry
Usando os PassTickets
Criação de Log de Auditoria
Controle de Auditoria
Processamento de Auditoria
Dados de Auditoria
Segurança do JES
Ações nas Tarefas - Limitações de Destino
Ações nas Tarefas - Limitações de Execução
Acesso aos Arquivos de Spool
Comunicação Criptografada de SSL/TLS
Comunicação Criptografada pelo Depurador Integrado
Autenticação de cliente usando certificados X.509
Validação da Autoridade de Certificação (CA)
(Opcional) Consulte uma Certificate Revocation List (CRL)
Autenticação por Software de Segurança
Autenticação por Daemon do RSE
Verificação de Port Of Entry (POE)
Alterando Funções de Cliente
OFF.REMOTECOPY.MVS
Grupos de Desenvolvedores de Push-to-client
Segurança de Depuração
segurança do CICSTS
repositório do CRD
transações do CICS
comunicação criptografada por SSL
Informações Variadas
Lixeira GATE
ACEE Gerenciado
Segurança de SCLM
arquivos de configuração do Developer for System z
JES Job Monitor - FEJJCNFG
RSE - rsed.envvars
RSE - ssl.properties
RSE - pushtoclient.properties
Definições de segurança
Requisitos e Lista de Verificação
Ativar Configurações de Segurança e Classes
Definir um segmento OMVS para usuários do Developer for System z
Definir as Tarefas Iniciadas do Developer for System z
Definir RSE como um servidor z/OS UNIX seguro
Definir as Bibliotecas Controladas por Programa do MVS para RSE
Definir Suporte de PassTicket para RSE
Definir a Proteção do Aplicativo para RSE
Definir a Segurança de Comando JES
Definir Perfis de Conjuntos de Dados
Definir os Arquivos Controlados por Programa do z/OS UNIX para RSE
Verifique as Configurações de Segurança
Capítulo 3. Considerações de TCP/IP
Portas TCP/IP
Comunicação Externa
Comunicação interna
Reserva de Porta TCP/IP
portas do CARMA e TCP/IP
Considerações de LDAP
Substituindo o Comportamento TCP/IP Padrão
ACK Atrasado
Multipilhas (CINET)
O CARMA e a Afinidade de Pilha
crastart*.conf
CRASUB*
Distributed Dynamic VIPA
Restringindo a Seleção de Portas
Configuração de Amostra
Sistema SYS1 - Perfil TCP/IP
Sistema SYS2 - Perfil TCP/IP
Capítulo 4. Considerações WLM
Classificação de Carga de Trabalho
Regras de Classificação
Configurando Objetivos
Considerações para Seleção de Objetivos
STC
OMVS
JES
ASCH
CICS
Capítulo 5. Considerações de Ajuste
Uso de Recursos
Visão Geral (Overview)
Contagem do espaço de endereço
Contagem de processos
Contagem de encadeamentos
Uso temporário de recursos
Uso de Armazenamento
Limite de Tamanho de Heap Java
Limite de Tamanho do Espaço de Endereço
Diretrizes de Estimativa de Tamanho
Análise do Uso de Armazenamento de Amostra
Uso do espaço do sistema de arquivos z/OS UNIX
Definições de Recursos Principais
/etc/rdz/rsed.envvars
SYS1.PARMLIB(BPXPRMxx)
Várias definições de recurso
Placa EXEC na JCL do Servidor
FEK.#CUST.PARMLIB(FEJJCNFG)
SYS1.PARMLIB(IEASYSxx)
SYS1.PARMLIB(IVTPRMxx)
SYS1.PARMLIB(ASCHPMxx)
Monitoramento
Monitoramento de RSE
Monitorando o z/OS UNIX
Monitoramento da Rede
Monitorando Sistemas de Arquivos z/OS UNIX
Configuração de Amostra
Contagem do Conjunto de Encadeamento
Determinar Limites Mínimos
Definindo Limites
Uso de Recurso de Monitor
Capítulo 6. Considerações sobre Desempenho
Usar Sistemas de Arquivos zFS
Evite o Uso de STEPLIB
Aprimorar o acesso às bibliotecas do sistema
Bibliotecas de Tempo de Execução Language Environment (LE)
Desenvolvimento de Aplicativos
Aprimorando o desempenho da verificação de segurança
Gerenciamento de carga de trabalho
Tamanho de heap Java fixo
Opção Java -Xquickstart
Compartilhamento de Classe entre JVMs
Ativar Compartilhamento de Classes
Limites de Tamanho de Cache
Segurança do Cache
SYS1.PARMLIB(BPXPRMxx)
Espaço em disco
Utilitários de Gerenciamento de Cache
Capítulo 7. Considerações de Push-to-client
Introdução
Sistema Primário
Metadados Push-to-client
Local de Metadados
Segurança de Metadados
Uso de Espaço de Metadados
Controle de Configuração do Cliente
Controle de Versão do Cliente
Diversos Grupos de Desenvolvedores
Ativação
Concatenações de Grupo
Ligação da Área de Trabalho
Local de Metadados do Grupo
Etapas de Configuração
Seleção de Grupo Baseada em LDAP
Esquema LDAP
Seleção do Servidor LDAP
Local do Servidor LDAP
Configuração de Amostra
Incluindo Backend push-to-client no LDAP
Configuração de Grupo LDAP Inicial
Incluir Desenvolvedores em Grupos LDAP
pushtoclient.properties
rsed.envvars
/var/rdz/pushtoclient/*install
Seleção de Grupo Baseada em SAF
Configuração de Amostra
Definição de Segurança
pushtoclient.properties
rsed.envvars
/var/rdz/pushtoclient/*install
Período de Carência para Rejeitar Mudanças
Projetos baseados no host
Capítulo 8. considerações CICSTS
RESTful versus Serviços da Web
Regiões de Conexão Primária versus Não-primária
Log de Instalação de Recurso do CICS
segurança do Application Deployment Manager
segurança do repositório CRD
Segurança de Pipeline
Segurança da Transação
comunicação criptografada por SSL
Segurança do Recurso
Administrative Utility
Notas de Migração do Utilitário Administrativo
Mensagens do Administrative Utility
Depuração de Transação do CICS
Capítulo 9. Considerações da Saída de Usuário
Características da Saída de Usuário
Ativação da Saída de Usuário
Gravando uma Rotina de Saída do Usuário
Mensagens do console
Executando com um ID do Usuário da Variável
Shell Script do z/OS UNIX
REXX exec do z/OS UNIX
Pontos de Saída Disponíveis
audit.action
logon.action
Capítulo 10. Customizando o Ambiente TSO
O Serviço TSO Commands
Métodos de Acesso
Usando o Método de Acesso do TSO/ISPF Client Gateway
ISPF.conf
Usar Perfis do ISPF Existentes
Usando um exec de alocação
Usar Diversos Execs de Alocação
Diversos Arquivos ISPF.conf com Diversas Configurações do Developer for System z
Capítulo 11. Executando várias instâncias
Configuração idêntica em um sysplex
Arquivos de Configuração Diferentes de Níveis de Software Idênticos
Sincronização Automatizada
Todas as Outras Situações
Capítulo 12. Resolução de problemas de configuração
Análise de Log e Configuração Usando FEKLOGS
Arquivos de Log
criação de logs do JES Job Monitor
Criação de Log de Daemon RSE e de Conjunto de Encadeamento
criação de logs do usuário do RSE
criação de log do SCLM Developer Toolkit
Criação de logs do CARMA
Criação de Log IVP fekfivpc
Criação de log de teste IVP do fekfivpi
Criação de Log de Teste IVP do fekfivps
Criação de Log da Revisão de Código
Criação de Log da Cobertura de Código
Arquivos de dump
Dumps do MVS
Dumps de Java
Locais de Dump do z/OS UNIX
Rastreio
rastreio do JES Job Monitor
rastreio RSE
rastreio CARMA
Rastreio de feedback de erro
Bits de permissão do z/OS UNIX
atributo do sistema de arquivos SETUID
Autorização de controle de programa
Autorização APF
Sticky Bit
Portas TCP/IP reservadas
Tamanho do espaço de endereço
Requisitos da JCL de Inicialização
Limitações Definidas em SYS1.PARMLIB(BPXPRMxx)
Limitações Armazenadas no Perfil de Segurança
Limitações Impostas por Saídas do Sistema
Limitações para Endereçamento de 64 Bits
Informações Variadas
Encerramento Anormal por Falta de Espaço B37 de Feedback de Erro
Limites do sistema
Conexão recusada
OutOfMemoryError
Emulador de Conexão do Host
Capítulo 13. Configurando o SSL e a Autenticação X.509
Decida Usar o SSL ou TLS Como o Método de Criptografia
Decidir Onde Armazenar Chaves Privadas e Certificados
Criar um Conjunto de Chaves com o RACF
(Opcional) Usando um Certificado Assinado
Clonar a Configuração RSE Existente
Atualizar rsed.envvars para Ativar a Coexistência
Atualizar ssl.properties para Ativar SSL
Ativar SSL Criando um Novo Daemon RSE
Testar a Conexão
(Opcional) Incluir Suporte de Autenticação de Cliente X.509
(Opcional) Criar um Banco de Dados de Chaves com gskkyman
(Opcional) Criar um Keystore com keytool
Capítulo 14. Configurando o TCP/IP
Dependência do nome do host
Compreendendo os Resolvedores
Compreendendo as Ordens de Procura das Informações de Configuração
Ordens de Procura Usadas no Ambiente do z/OS UNIX
Arquivos de Base da Configuração do Resolvedor
Tabelas de Conversão
Tabelas do Host Local
Aplicando Estas Informações de Configuração ao Developer for System z
O Endereço do Host Não É Resolvido Corretamente
Bibliografia
Publicações Referenciadas
Publicações Informativas
Glossário
Avisos sobre a Documentação para o IBM Rational Developer for System z
Licença de Copyright
Reconhecimentos de Marca Registrada
Índice

Figuras

  1. Visão geral do componente
  2. RSE como um aplicativo Java
  3. donos das tarefas
  4. Fluxo de conexão
  5. Depurador Integrado
  6. Fluxo do CARMA
  7. Fluxo de Determinação de Enfileiramento de Conjunto de Dados
  8. Estrutura de diretório do z/OS UNIX
  9. Política AT-TLS para Debug Manager
  10. Portas TCP/IP
  11. update.sh - Suportar Configuração de DDVIPA com um Firewall
  12. Amostra do Distributed Dynamic VIPA
  13. classificação WLM
  14. Número máximo de espaços de endereço
  15. Número de espaços de endereços por cliente
  16. Número máximo de processos
  17. Número de processos para STCRSE
  18. Número de processos por cliente
  19. Número máximo de encadeamentos do conjunto de encadeamento do RSE
  20. Número máximo de encadeamentos do JES Job Monitor
  21. Uso de recursos com 5 logons
  22. Uso de recursos com 5 logons (continuação)
  23. Uso de recursos ao editar um membro PDS
  24. Uso do espaço do sistema de arquivos z/OS UNIX
  25. Uso do recurso de configuração de amostra
  26. Definição de esquema LDAP de amostra
  27. ADNJSPAU - Administrative utility do CICSTS
  28. ADNJSPAU - Utilitário Administrativo CICSTS (Parte 2 de 3)
  29. ADNJSPAU - Utilitário Administrativo CICSTS (Parte 3 de 3)
  30. RSEDSSL - Tarefa do usuário do daemon RSE para SSL
  31. Diálogo Importar Certificado do Host
  32. Diálogo Preferências - SSL

Tabelas

  1. Comandos do Console do JES Job Monitor
  2. Matriz de Permissão do Comando LIMIT_COMMANDS
  3. Perfis JESSPOOL Estendidos
  4. Matriz de Autoridade do Console LIMIT_CONSOLE
  5. Matriz de permissão de navegação LIMIT_VIEW
  6. Mecanismos de armazenamento de certificado SSL
  7. Informações de SAF para Alterar Funções de Cliente
  8. Informações do SAF de Push-to-client
  9. Informações de SAF para Funções de Depuração
  10. Variáveis de configuração de segurança
  11. Comandos do Operador do JES2 Job Monitor
  12. Comandos do Operador do JES3 Job Monitor
  13. Subsistemas de Ponto de Entrada do WLM
  14. qualificadores de trabalho WLM
  15. cargas de trabalho WLM
  16. cargas de trabalho WLM STC
  17. Cargas de trabalho WLM OMVS
  18. Carga de trabalhos WLM JES
  19. Cargas de trabalho WLM ASCH
  20. Cargas de trabalho WLM - CICS
  21. Uso de recursos comuns
  22. Uso de recursos obrigatórios específicos do usuário
  23. Uso de recursos específicos do usuário
  24. Contagem do espaço de endereço
  25. Limites de espaço de endereço
  26. Contagem de processos
  27. Limites do processo
  28. Contagem de encadeamentos
  29. Limites de encadeamento
  30. Configurações de Referência para Uso de Armazenamento
  31. Diretivas de saída do log
  32. Diretivas de saída temporárias
  33. Matriz de suporte ao grupo push-to-client para *.enabled
  34. Matriz de suporte ao grupo push-to-client para reject.*.updates
  35. Concatenações de Grupo Push-to-client
  36. Informações do LDAP de Push-to-client
  37. Informações do SAF de Push-to-client
  38. Variáveis de JAVA_DUMP_TDUMP_PATTERN
  39. Mecanismos de armazenamento de certificado SSL
  40. Definições locais disponíveis para o resolvedor
  41. Publicações Referenciadas
  42. Web Sites Referidos
  43. Publicações Informativas

Sobre este Documento

Este documento oferece informações de segundo plano para várias tarefas de configuração do próprio IBM® Rational Developer for System z e outros componentes e produtos do z/OS (como WLM e CICS).

De agora em diante, os seguintes nomes serão usados neste manual:

Este documento faz parte de um conjunto de documentos que descrevem a configuração do host do Developer for System z. Cada um desses documentos tem um público alvo específico. Você não precisa ler todos os documentos para concluir a configuração do Developer for System z.

As informações neste documento aplicam-se a todos os pacotes do IBM Rational Developer for System z Versão 9.0.

Quem Deve Usar este Documento

Este documento é destinado a programadores de sistema que configuram e ajustam o IBM Rational Developer for System z Versão 9.0.1.

Enquanto as etapas de configuração reais são descritas em outra publicação, esta publicação lista em detalhes vários assuntos relacionados, como ajuste, configuração de segurança, entre outros. Para usar este documento, você deve estar familiarizado com os sistemas host z/OS UNIX System Services e MVS.

Resumo das Mudanças

Esta seção resume as mudanças no IBM Rational Developer for System z Versão 9.0 Referência de Configuração do Host, S517-9857-06 (atualizado em dezembro de 2013).

Mudanças técnicas e adições ao texto e ilustrações são indicadas por uma linha vertical à esquerda da mudança.

Novas informações:

Este documento contém informações anteriormente apresentadas no IBM Rational Developer for System z Versão 9.0 Referência de Configuração do Host, SC14-7290-04.

Novas informações:

Este documento contém informações apresentadas anteriormente no IBM Rational Developer for System z Versão 8.5.1: Referência de Configuração de Host, S517-9857-03.

Novas informações:

Este documento contém informações anteriormente presentes na Referência de Configuração de Host do IBM Rational Developer for System z Versão 8.5, S517-9857-02.

Novas informações:

Este documento contém informações apresentadas anteriormente no IBM Rational Developer for System z Versão 8.0.3: Referência de Configuração de Host, S517-9857-01.

Novas informações:

Este documento contém informações apresentadas anteriormente no IBM Rational Developer for System z Versão 8.0.1 Referência de Configuração de Host , S517-9857-00.

Novas informações:

Informações removidas:

Descrição do Conteúdo do Documento

Esta seção resume as informações apresentadas neste documento.

Entendendo o Developer for System z

O host do Developer for System z consiste em vários componentes que interagem para oferecer acesso ao cliente para os serviços e dados do host. Entender o design desses componentes pode ajudá-lo a tomar as decisões corretas de configuração.

Considerações de segurança

O Developer for System z fornece acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. A validação dos pedidos de conexão, o fornecimento de comunicação segura entre o host e a estação de trabalho, e a atividade de autorização e auditoria são aspectos importantes da configuração do produto.

Considerações de TCP/IP

O Developer for System z usa TCP/IP para fornecer acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. Ele também usa TCP/IP para comunicação entre vários componentes e outros produtos.

Considerações WLM

Ao contrário dos aplicativos tradicionais do z/OS, o Developer for System z não é um aplicativo monolítico que pode ser identificado facilmente para Workload Manager (WLM). O Developer for System z consiste de vários componentes que interagem para fornecer ao cliente acesso para os serviços e dados do host. Alguns destes serviços estão ativos em diferentes espaços de endereço, resultando em diferentes classificações de WLM.

Considerações de Ajuste

O RSE (Explorador de Sistema Remoto) é o núcleo do Developer for System z. Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon age como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamentos processam as cargas de trabalho do cliente.

Isso torna o RSE um alvo principal para o ajuste da configuração do Developer for System z. Entretanto, a manutenção de centenas de usuários, cada um usando 17 ou mais encadeamentos, uma determinada quantidade de armazenamento e possivelmente um ou mais espaços de endereço exige configuração adequada do Developer for System z e do z/OS.

Considerações sobre Desempenho

O z/OS é um sistema operacional altamente customizável, e (algumas vezes pequenas) alterações no sistema podem ter um grande impacto sobre o desempenho geral. Este capítulo destaca algumas das alterações que podem ser feitas para melhorar o desempenho do Developer for System z.

Considerações de Push-to-client

Push-to-client, ou controle de cliente baseado em host, suporta gerenciamento central dos seguintes itens:

considerações CICSTS

Este capítulo contém informações úteis para um administrador do CICS Transaction Server.

Considerações da Saída de Usuário

Esse capítulo o ajuda a aprimorar o Developer for System z ao gravar as rotinas de saída.

Customizando o Ambiente TSO

Este capítulo ajuda você a imitar um procedimento de logon do TSO incluindo instruções DD e conjuntos de dados no ambiente do TSO no Developer for System z.

Executando várias instâncias

Há situações em que você deseja várias instâncias do Developer for System z ativas no mesmo sistema, por exemplo, durante o teste de um upgrade. Entretanto, alguns recursos, como portas TCP/IP, não podem ser compartilhadas, portanto os padrões nem sempre são aplicáveis. Use as informações neste capítulo para planejar a coexistência de diferentes instâncias do Developer for System z; depois é possível usar este guia de configurações para customizá-las.

Resolução de problemas de configuração

Este capítulo é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar durante a configuração do seu Developer for System z, e possui as seções a seguir:

Configurando o SSL e a Autenticação X.509

Este apêndice é fornecido para ajudar você com alguns dos problemas comuns que você pode encontrar ao configurar Secure Socket Layer (SSL) ou durante a verificação ou modificação de uma configuração existente. Este apêndice também fornece uma configuração de amostra para dar suporte aos usuários se autenticando com um certificado X.509.

Configurando o TCP/IP

Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o TCP/IP ou durante a verificação ou a modificação de uma configuração existente.

Guia de Referência de Configuração do Host do IBM Rational Developer for System z

Capítulo 1. Entendendo o Developer for System z

O host do Developer for System z consiste em diversos componentes que interagem para dar ao cliente acesso aos dados e serviços do host. Entender o design desses componentes pode ajudá-lo a tomar as decisões corretas de configuração.

Os seguintes tópicos são abordados neste capítulo:

Visão geral do componente

Figura 1. Visão geral do componente
Visão Geral do Componente

Figura 1 mostra uma visão geral do layout do Developer for System z em seu sistema host.

A descrição no parágrafo e a lista mostram a função central designada ao RSE. Com algumas exceções, toda a comunicação do cliente passa pelo RSE. Isso é permitido para uma configuração fácil da rede relacionada à segurança, uma vez que apenas um conjunto limitado de portas é usado para a comunicação entre o cliente e o host.

Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon age como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamentos processam as cargas de trabalho do cliente. Com base nos valores definidos no arquivo de configuração rsed.envvars e na quantidade real de conexões do cliente, vários espaços de endereço do conjunto de encadeamento podem ser iniciados pelo daemon.

RSE como um aplicativo Java

Figura 2. RSE como um aplicativo Java
RSE como um aplicativo Java

A Figura 2 mostra uma visualização básica do uso de recursos (processos e armazenamento) pelo RSE.

O RSE é um aplicativo Java™, que significa que ele está ativo no ambiente z/OS UNIX. Isso é permitido para facilitar o porting em diferentes plataformas host e comunicação direta com o cliente do Developer for System z, que é também um aplicativo Java (baseado na estrutura do Eclipse). Portanto, o conhecimento básico de como z/OS UNIX e Java funcionam é muito útil quando você tenta compreender o Developer for System z.

No z/OS UNIX, um programa é executada em um processo, que é identificado por um PID (ID do Processo). Cada programa é ativado em seu próprio processo, portanto invocar outro programa criará um novo processo. O processo que iniciou um processo é referenciado com um PPID (PID Pai), o novo processo é chamado de processo-filho. O processo-filho pode ser executado no mesmo espaço de endereço ou pode ser gerado (criado) em um novo espaço de endereço. Um novo processo que é executado no mesmo espaço de endereço pode ser comparado a executar um comando em TSO, enquanto aquele gerado em um novo espaço de endereço é semelhante a enviar uma tarefa em lote.

Observe que um processo pode ser único ou multiencadeado. Em um aplicativo multiencadeado (como o RSE), os diferentes encadeamentos competem por recursos do sistema como se eles fossem espaços de endereço separados (com menos gasto adicional).

Mapeando essas informações de processo para a amostra RSE na Figura 2, obtivemos o seguinte fluxo:

  1. Quando a tarefa RSED for iniciada, ela executa BPXBATSL, que invoca z/OS UNIX e cria um ambiente de shell - PID 50331904.
  2. Neste processo, o shell script rsed.sh é executado, que executa em um processo separado (/bin/sh) - PID 67109114.
  3. O shell script configura as variáveis de ambiente definidas em rsed.envvars e executa o Java com os parâmetros necessários para iniciar o daemon RSE - PID 50331949.
  4. O daemon RSE fará spawn off do novo shell em um processo-filho (RSED8) - PID 307.
  5. Neste shell, as variáveis de ambiente definidas em rsed.envvars são configuradas e o Java é executado com os parâmetros necessários para iniciar o conjunto de encadeamento do RSE - PID 308.

O RSE é capaz de executar em modo de endereçamento de 31 bits ou 64 bits, resultando em diferentes limites de armazenamento. No modo de 31 bits, o armazenamento disponível está limitado a 2 GB, enquanto que no modo de 64 bits, não há limite, a menos que especificado no SYS1.PARMLIB.

Aplicativos Java, como o RSE, não alocam armazenamento diretamente, mas usam serviços de gerenciamento de memória Java. Esses serviços, como alocação de armazenamento, liberação de armazenamento e coleta de lixo, funcionam dentro dos limites do heap Java. Os tamanhos mínimo e máximo do heap é definido (implicitamente ou explicitamente) durante a inicialização de Java. Ao executar em modo de 64 bits, o Java tentará alocar o heap acima de 2 GB de barramento, liberando espaço abaixo do barramento.

Isso significa que a obtenção da maioria do tamanho de espaço de endereço disponível é um ato de equilíbrio da definição de um tamanho grande de heap, enquanto deixa espaço suficiente para o z/OS armazenar uma quantidade variável de blocos de controle do sistema (dependendo do número de encadeamentos ativos).

donos das tarefas

Figura 3. donos das tarefas
Donos das Tarefas

Figura 3 mostra uma visão geral básica do proprietário das credenciais de segurança usadas para várias tarefas do Developer for System z.

A propriedade de uma tarefa pode ser dividida em duas seções. As tarefas iniciadas são propriedades do ID do usuário que é designado para a tarefa iniciada em seu software de segurança. Todos as outras tarefas, com os conjuntos de encadeamentos (RSEDx) como exceção, são propriedades do ID de usuário cliente.

Figura 3 mostra as tarefas iniciadas do Developer for System z (JMON e RSED) e tarefas iniciadas de amostra e serviços do sistema com os quais Developer for System z se comunica. O Application Deployment Manager (ADM) fica ativo dentro de uma região CICS. A tag USS REXEC representa o serviço do z/OS UNIX REXEC (ou SSH).

O daemon RSE (RSED) cria um ou mais espaços de endereço do conjunto de encadeamentos (RSEDx) para processar os pedidos dos clientes. Cada conjunto de encadeamentos RSE suporta múltiplos clientes e é propriedade do mesmo usuário como um daemon RSE. Cada cliente possui seus próprios encadeamentos dentro de um conjunto de encadeamentos, e estes encadeamentos são propriedades do ID de usuário cliente.

Dependendo das ações concluídas pelo cliente, um ou mais espaços de endereço adicionais podem ser iniciados, todos propriedades do ID de usuário cliente, para executar uma ação solicitada. Esses espaços de endereço podem ser uma tarefa em lote MVS, uma transação APPC ou um processo-filho z/OS UNIX. Observe que um processo-filho z/OS UNIX está ativo em um inicializador z/OS UNIX (BPXAS) e o processo-filho aparece com uma tarefa iniciada no JES.

A criação destes espaços de endereços é mais frequentemente acionada por um encadeamento do usuário em um conjunto de encadeamentos, diretamente ou usando serviços do sistema como ISPF. Mas o espaço de endereço também poderia ser criado por um terceiro. Por exemplo, o Gerenciador de Arquivos iniciará um novo espaço de endereço para cada conjunto de dados (ou membro) que ele tenha que processar em nome do Developer for System z. z/OS UNIX REXEC ou SSH são envolvidos ao iniciar as construções no z/OS UNIX.

Os espaços de endereços do usuário terminam com a conclusão da tarefa ou quando um cronômetro de inatividade vence. As tarefas iniciadas permanecem ativas. Os espaços de endereços listados em Figura 3 permanecem no sistema tempo suficiente para serem visíveis. No entanto, é recomendável estar ciente que, devido à maneira com que o z/OS UNIX é projetado, há também vários espaços de endereço temporários de curta duração.

Fluxo de conexão

Figura 4. Fluxo de conexão
Fluxo de Conexão

Figura 4 mostra uma visão geral esquemática de como o cliente conecta-se ao host usando Developer for System z. Ele também explica brevemente como os PassTickets são usados.

  1. O cliente efetua logon no daemon (porta 4035).
  2. O daemon RSE autentica o cliente usando as credenciais apresentadas pelo cliente.
  3. O daemon RSE seleciona um conjunto de encadeamento existente ou inicia um novo se todos estiverem cheios.
  4. O daemon RSE passa o ID do usuário cliente para o conjunto de encadeamento.
  5. O conjunto de encadeamento cria um encadeamento do servidor RSE específico do cliente, usando o ID do usuário cliente e um PassTicket para autenticação.
  6. O encadeamento do servidor cliente se conecta a uma porta para comunicação futura com o cliente.
  7. O encadeamento do servidor cliente retorna o número da porta à qual o cliente deve se conectar.
  8. O cliente desconecta do daemon RSE e se conecta ao número da porta fornecido.
  9. O encadeamento do servidor cliente inicia outros encadeamentos específicos do usuário (extratores), sempre usando o ID do usuário cliente e um PassTicket para autenticação. Esses encadeamentos fornecem os serviços específicos do usuário necessários pelo cliente.

A descrição anterior mostra o design orientado a encadeamento do RSE. Em vez de iniciar um espaço de endereço por usuário, vários usuários são atendidos por um espaço de endereço de um único conjunto de encadeamento. No conjunto de encadeamentos, cada extrator (um serviço específico do usuário) fica ativo em seu próprio encadeamento com o contexto de segurança do usuário designado a ele, garantindo uma configuração segura. Esse design acomoda um grande número de usuários com uso de recursos limitado, mas não significa que cada cliente usará vários encadeamentos (17 ou mais, dependendo das tarefas executadas).

Do ponto de vista da rede, o Developer para System z atua de forma semelhante ao FTP no modo passivo. O cliente se conecta a um ponto focal (daemon RSE) e, em seguida, elimina a conexão e reconecta ao número de porta fornecido pelo ponto focal. A seguinte lógica controla a seleção da porta que é usada na segunda conexão:

  1. Se o cliente especificou um número de porta diferente de zero na guia de propriedades de subsistema, então o servidor RSE usará essa porta para a conexão. Se essa porta não estiver disponível, a conexão falhará.
  2. Se _RSE_PORTRANGE for especificado em rsed.envvars, então o servidor RSE se conectará a uma porta desse intervalo. Se nenhuma porta estiver disponível, a conexão falhará. O servidor RSE não precisa da porta exclusivamente pela duração da conexão do cliente. Ela só é necessária no momento da expansão entre (servidor) a ligação e (cliente) a conexão que nenhum outro servidor RSE pode se conectar à porta. Isso significa que a maioria das conexões estará usando a primeira porta no intervalo, com o restante do intervalo sendo um buffer no caso de diversos logons simultâneos.
  3. Se nenhuma limitação for configurada, o servidor RSE se conectará à porta 0. O resultado é que o TCP/IP escolhe o número da porta.

O uso de PassTickets para todos os serviços z/OS que requerem a autenticação permite que o Developer for System z chame esses serviços à vontade, sem armazenar a senha ou constantemente solicitá-la ao usuário. O uso de PassTickets para todos os serviços z/OS permite também métodos de autenticação alternativos durante o logon, como senhas únicas e certificados X.509.

Depurador Integrado

Figura 5. Depurador Integrado
Depurador integrado

O Depurador Integrado é usado para depurar vários aplicativos. A figura 5 mostra uma visão geral esquemática de como um cliente do Developer for System z pode depurar um aplicativo.

  1. O cliente se conecta ao host, usando o logon do host do Developer for System z normal.
  2. Como parte do logon, um extrator de depuração registrará o usuário com o gerenciador de depuração, o qual está ativo na tarefa iniciada de DBGMGR.
  3. Quando um aplicativo for iniciado com um indicador de que ele deve ser depurado, o ambiente de linguagem (LE) chamará a análise de depuração.
  4. A análise de depuração se registrará no gerenciador de depuração.
  5. Usando o extrator de depuração, o gerenciador de depuração notificará o cliente do Developer for System z do usuário que receberá esta sessão de depuração. Se o usuário não estiver registrado neste momento, a sessão de depuração ficará inativa, esperando o usuário se registrar no gerenciador de depuração.
  6. O mecanismo de depuração dentro do cliente contata o gerenciador de depuração, o qual por sua vez transmitirá os dados entre o mecanismo de depuração e a análise de depuração.

CARMA

Figura 6. Fluxo do CARMA
Fluxo do CARMA

O CARMA (Common Access Repository Manager) é usado para acessar um host baseado em Software Configuration Manager (SCM), por exemplo, o CA Endevor® SCM. A Figura 6 mostra uma visão geral esquemática de como um cliente Developer for System z pode acessar qualquer Software Configuration Manager (SCM) baseado em host suportado.

  1. O cliente tem um plug-in Common Access Repository Manager (CARMA).
  2. O plug-in CARMA se comunica com o extrator CARMA, ativo como um encadeamento específico do usuário no conjunto de encadeamentos RSE (RSEDx). Esta comunicação é feita por meio da conexão RSE existente.
  3. Quando o cliente solicitar acesso a um SCM, o extrator CARMA se conectará a uma porta TCP/IP e iniciará um servidor CARMA específico do usuário, com o número da porta como argumento de inicialização. O servidor CARMA então se conectará a esta porta e usará este caminho para se comunicar com o cliente. Note que o host baseado em SCMs espera espaços de endereço de usuário único para acessar os seus serviços, que requer que o CARMA inicie um servidor CARMA por usuário. Não é possível criar um único servidor que suporte diversos usuários.
  4. O servidor CARMA carregará o Repository Access Manager (RAM) que suporta o SCM solicitado.
  5. O RAM lida com os detalhes técnicos de interação com o SCM específico e apresenta uma interface comum para o cliente.

Arquivos de Configuração CARMA

O Developer for System z suporta vários métodos para iniciar um servidor CARMA. Cada método tem vantagens e desvantagens. O Developer for System z também fornece vários Repository Access Managers (RAMs), os quais podem ser divididos em dois grupos, RAMs de produção e RAMs de amostra. Várias combinações de RAMs e métodos de inicialização do servidor estão disponíveis como uma configuração pré-configurada.

Todos os métodos de inicialização do servidor compartilham um arquivo de configuração comum, CRASRV.properties, o qual (junto com outras coisas) especifica qual método de inicialização será usado.

CRASTART

O método "CRASTART" inicia o servidor CARMA como uma subtarefa dentro do RSE. Ele fornece uma configuração bastante flexível utilizando um arquivo de configuração separado, que define alocações de conjuntos de dados, e chamadas de programas necessárias para iniciar um servidor CARMA. Esse método fornece o melhor desempenho e utiliza o mínimo de recursos, mas requer que o módulo CRASTART esteja localizado no LPA.

O RSE chama o módulo de carregamento CRASTART, o qual usa as definições em crastart*.conf para criar um ambiente válido para executar comandos ISPF e TSO em lote. O Developer for System z usa este ambiente para executar o servidor CARMA, CRASERV. O Developer for System z fornece vários arquivos crastart*.conf, cada um deles pré-configurado para um RAM específico.

Envio em Lote

O método "envio em lote" inicia o servidor CARMA enviando uma tarefa. Esse é o método padrão utilizado nos arquivos de configuração de amostra fornecidos. O benefício desse método é que os logs do CARMA são facilmente acessados na saída de tarefas. Ele também permite o uso de JCL de servidor customizado para cada desenvolvedor, que é mantido pelo próprio desenvolvedor. Entretanto, esse método utiliza um iniciador de JES por desenvolvedor que iniciar um servidor CARMA.

O RSE chama o CLIST CRASUB*, o qual por sua vez envia um JCL embutido para criar um ambiente válido para executar os comandos ISPF e TSO em lote. O Developer for System z usa este ambiente para executar o servidor CARMA, CRASERV. O Developer for System z fornece vários membros CRASUB*, cada um deles pré-configurado para um RAM específico.

Proprietário de Bloco de Conjunto de Dados

Figura 7. Fluxo de Determinação de Enfileiramento de Conjunto de Dados
Fluxo de daemon de bloqueio

Figura 7 mostra uma visão geral esquemática de como o daemon RSE determina qual cliente Developer for System z possui um bloqueio de conjunto de dados.

  1. RSE daemon (RSED) cria um conjunto de encadeamentos (RSEDx). Para confirmar a conclusão da inicialização, o conjunto de encadeamentos relata seu Address Space Identifier (ASID) novamente ao daemon RSE, que armazena-o no bloco de controle criado para rastrear este conjunto de encadeamento.
  2. O cliente efetua logon, que cria um encadeamento do servidor RSE específico do usuário (USER) dentro de um conjunto de encadeamento (RSEDx). Cada encadeamento tem um identificador exclusivo de Task Control Block (TCB).
  3. O cliente abre um conjunto de dados na edição, que instrui o servidor RSE a obter um bloqueio restrito (enfileiramento) no conjunto de dados.
  4. O sistema registra o ASID, TCB e o nome da tarefa (RSEDx) do solicitante como parte do processo de enfileiramento. Essas informações são armazenadas nas filas GRS (Global Resource Serialization).
  5. Um operador consulta o daemon RSE para o status do bloqueio do conjunto de dados.
  6. O daemon RSE varre as filas GRS para saber se o conjunto de dados está bloqueado e recupera o ASID, TCB e o nome da tarefa do proprietário do bloqueio.
  7. O ASID recuperado é comparado com o ASID dos conjuntos de encadeamentos diferentes.
  8. O daemon RSE solicita que o conjunto de encadeamentos que possui o ASID determine qual usuário possui o TCB.
  9. O ID do usuário do cliente relacionado é retornado ao solicitante quando uma correspondência for encontrada. Caso contrário, o nome da tarefa recuperado de GRS é retornado.

Com a configuração do servidor único do Developer for System z, em que diversos usuários são designados a um único espaço de endereço de encadeamento, o z/OS perdeu a capacidade de rastrear quem possui um bloqueio em um conjunto de dados ou membro com o comando do operador DISPLAY GRS,RES=(*,dataset*). Os comandos do sistema param no nível de espaço de endereço, que é o conjunto de encadeamento.

Para abordar este problema, o Developer for System z fornece o comando do operador MODIFY rsed APPL=DISPLAY OWNER,DATASET=dataset, conforme descrito em "Comandos de operador" em Guia de Configuração do Host (S517-9094). O comando do operador pode resolver todos os conjuntos de dados e bloqueios de membro feitos por usuários RSE, bem como bloqueios feitos por outros produtos, como ISPF.

Liberando um Bloqueio

Sob circunstâncias normais, um conjunto de dados ou um membro fica bloqueado quando o cliente o abrir no modo de edição, e liberado quando o cliente fechar a sessão de edição.

Determinadas condições de erro podem evitar que esse mecanismo funcione como designado. Nesse caso, o usuário que mantém o bloqueio pode ser cancelado usando o comando do operador modify cancel do RSE, como descrito em "Comandos do operador" no Guia de Configuração do Host (SC23-7658). Os bloqueios do conjunto de dados ativo que pertencem a esse usuário são liberados durante o processo.

Estrutura de diretório do z/OS UNIX

Figura 8. Estrutura de diretório do z/OS UNIX
Estrutura de diretório do z/OS Unix

Figura 8 mostra uma visão geral dos diretórios do z/OS UNIX usados pelo Developer for System z. A lista a seguir descreve cada diretório tocado pelo Developer for System z, como o local pode ser alterado e que mantém os dados dentro dele.

Atualizar Privilégios para Administradores que Não São de Sistema

Os dados em /var/rdz/pushtoclient/ são mantidos por não administradores de sistema, como gerentes de produto, que podem não ter muitos privilégios de atualização no z/OS UNIX. Portanto, é importante entender como o z/OS UNIX configura as permissões de acesso durante a criação de arquivos para assegurar que você tenha uma configuração viável e segura.

Os padrões do UNIX determinam que permissões podem ser configuradas para os três tipos de usuários: proprietário, de grupo e outros. Permissões de leitura, gravação e execução podem ser configuradas para cada tipo individualmente.

O z/OS UNIX configura os UID (user ID) e GID (group ID) para os seguintes valores quando um arquivo é criado:

Cada site pode configurar sua própria máscara padrão de permissões de acesso, mas uma máscara comum concede permissão de leitura e de gravação para o proprietário e permissão de leitura para grupos e outros.

Os dados no /var/rdz/pushtoclient/ são criados usando a máscara de permissões de acesso definida na diretiva file.permission do pushtoclient.properties. O valor padrão concede permissão de leitura e gravação para o proprietário e grupos e permissão de leitura para outros. Todos têm permissão de execução. As permissões de acesso final devem permitir acesso de leitura e execução a todos, e acesso de gravação aos administradores do cliente do Developer for System z que mantêm os dados.

Os dados em /var/rdz/pushtoclient/projects/ são criados sem usar nenhuma máscara de permissão de acesso específica. As permissões de acesso final devem conceder permissão de leitura para todos e permissão de gravação para os gerentes de projeto que mantêm os dados.

Comandos de Segurança Úteis

Para assegurar que um grupo de gerentes de projeto ou administradores de cliente do Developer for System z possam gerenciar os dados nesses diretórios, seu administrador de segurança pode ter de criar um grupo com um segmento OMVS válido para eles. Esse grupo é preferivelmente o grupo padrão dos IDs de usuário envolvidos. Consulte Security Server RACF Command Language Reference (SA22-7687) para obter mais informações sobre a seguinte amostra de comandos RACF:

ADDGROUP RDZPROJ OMVS(GID(1200))
CONNECT IBMUSER GROUP(RDZPROJ)
ALTUSER IBMUSER DFLTGRP(RDZPROJ)

Comandos Úteis do z/OS UNIX

Consulte a UNIX System Services Command Reference (SA22-7802) para obter mais informações sobre os seguintes comandos de amostra do z/OS UNIX:

Configuração de Amostra

No cenário a seguir, todos os gerentes de projeto de desenvolvimento, uma equipe de três, serão incumbidos de desempenhar tarefas de um administrador cliente do Developer for System z.

O administrador de segurança já designou para a equipe um grupo padrão (RDZPROJ) com um ID de grupo exclusivo (1200). Seus IDs de usuário não possuem privilégios especiais (como UID 0) no z/OS UNIX. O administrador de segurança não definiu o perfil FILE.GROUPOWNER.SETGID. Sendo assim, o z/OS UNIX usará o ID de grupo do diretório ao criar novos arquivos. O ID do usuário IBMUSER (com o UID 0 e o grupo padrão SYS1) foi usado pelo programador de sistemas para criar o diretório /var/rdz/pushtoclient.

  1. O programador de sistemas limita as permissões de gravação de /var/rdz/pushtoclient a proprietários e grupos:
    # chmod 775 /var/rdz/pushtoclient
    # ls -ld /var/rdz/pushtoclient
    drwxrwxr-x   2 IBMUSER  SYS1      
    /var/rdz/pushtoclient
    Nota: A tarefa FEKSETUP usada durante a configuração da customização já realizou esta etapa.
  2. O programador de sistemas torna RDZPROJ o grupo proprietário:
    # chgrp RDZPROJ /var/rdz/pushtoclient
    # ls -ld /var/rdz/pushtoclient
    drwxrwxr-x   2 IBMUSER  RDZPROJ   
    /var/rdz/pushtoclient

Isso conclui a configuração necessária para limitar as permissões de gravação de /var/rdz/pushtoclient ao programador de sistemas (IBMUSER) e aos gerentes de projeto (RDZPROJ).

Capítulo 2. Considerações de segurança

O Developer for System z fornece acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. A validação dos pedidos de conexão, o fornecimento de comunicação segura entre o host e a estação de trabalho, e a atividade de autorização e auditoria são aspectos importantes da configuração do produto.

Os mecanismos de segurança usados pelos servidores e serviços do Developer for System z dependem dos conjuntos de dados e sistemas de arquivos no qual ele reside sejam seguros. Isto indica que apenas administradores confiáveis de sistema podem ser capazes de atualizar as bibliotecas de programa e os arquivos de configuração.

Os seguintes tópicos são abordados neste capítulo:

Nota: O Explorador de Sistemas Remotos (RSE), que fornece os principais serviços, como conexão do cliente com o host, consiste em 2 entidades lógicas:
  • Daemon RSE, que gerencia a configuração da conexão e que é iniciado como uma tarefa iniciada ou uma tarefa de usuário de longa execução.
  • Servidor RSE, que manipula pedidos individuais do cliente e é iniciado como um encadeamento em um ou mais processos-filho pelo daemon RSE.

Consulte Capítulo 1. Entendendo o Developer for System z para saber sobre conceitos de design do Developer for System z básicos.

Métodos de autenticação

O Developer for System z suporta diversas formas de autenticar um ID do usuário fornecido por um cliente mediante a conexão.

Nota: Os dados de autenticação fornecidos pelo cliente só são usados uma vez, durante a configuração de conexão inicial. Depois que um ID do usuário é autenticado, o ID do usuário e os PassTickets autogerados são usados para todas as ações que requerem autenticação.

ID do Usuário e Senha

O cliente fornece um ID de usuário e uma senha correspondente na conexão. O ID de usuário e a senha são usados para autenticar o usuário com seu produto de segurança.

ID do Usuário e Senha Única

Com base em um token exclusivo, uma senha única pode ser gerada por um produto de terceiro. Senhas únicas melhoram a configuração da segurança já que o token exclusivo não pode ser copiado e usado sem o conhecimento do usuário e uma senha interceptada é inútil já que é válida somente uma vez.

O cliente fornece um ID de usuário e a senha única na conexão, que é usada para autenticar o ID do usuário com a saída de segurança fornecida por terceiro. Espera-se que essa saída de segurança ignore os PassTickets usados para satisfazer pedidos de autenticação durante o processamento normal. Os PassTickets devem ser processados por seu software de segurança.

Certificado X.509

Um terceiro pode fornecer um ou mais certificados X.509 que podem ser usados para autenticar um usuário. Quando armazenado em dispositivos seguros, os certificados X.509 combinam uma configuração segura com facilidade de uso para o usuário (nenhum ID do usuário ou senha necessário).

Ao conectar, o cliente fornece um certificado selecionado e, como opção, uma extensão selecionada, que é usada para autenticar o ID do usuário com seu produto de segurança.

Nota: Esse método de autenticação só é suportado pelo método de conexão do daemon RSE, e a comunicação SSL (Secure Socket Layer) deve estar ativada.

Autenticação do JES Job Monitor

A autenticação do cliente é realizada pelo daemon do RSE (ou REXEC/SSH) como parte do pedido de conexão do cliente. Depois de o usuário ser autenticado, os PassTickets gerados automaticamente são usados para todos os pedidos de autenticação futuros, incluindo o logon automático no JES Job Monitor.

Para que o JES Job Monitor valide o ID do usuário e o PassTicket apresentados pelo RSE, o JES Job Monitor deve ter permissão para avaliar o PassTicket. Isso implica no seguinte:

Nota: Clientes anteriores (versão 7.0 e mais antiga) comunicam-se diretamente com o JES Job Monitor. Para essas conexões, somente o método de autenticação de ID de usuário e senha é suportado.

Autenticação do Debug Manager

A autenticação do cliente é realizada pelo daemon do RSE (ou REXEC/SSH) como parte do pedido de conexão do cliente. Depois de o usuário ser autenticado, os PassTickets gerados automaticamente são usados para todas as solicitações de autenticação futuras, incluindo o logon automático no Debug Manager.

Para que o Debug Manager valide o ID do usuário e o PassTicket apresentados pelo RSE, o Debug Manager deve ter permissão para avaliar o PassTicket. Isso implica que o módulo de carregamento AQEZPCM, por padrão localizado na biblioteca de carregamento FEK.SFEKAUTH, deve ser autorizado pelo APF.

Segurança de conexão

Diferentes níveis de segurança de comunicação são suportados por RSE, o qual controla a comunicação entre o cliente e a maioria dos serviços do Developer for System z:

Alguns serviços Developer for System z opcionais usam um caminho de comunicação externo (cliente-host) separado:

O Developer for System z conta com produtos de terceiros, tal como o servidor TN3270, para fornecer alguns serviços. Consulte a documentação do produto relacionada para obter opções de segurança de conexão.

Limitar Comunicação Externa a Portas Especificadas

O programador de sistemas pode especificar as portas nas quais o servidor RSE pode se comunicar com o cliente. Por padrão, qualquer porta disponível é usada. Esse intervalo de portas não possui conexão com a porta do daemon RSE.

Para ajudar a compreender o uso da porta, segue uma breve descrição do processo de conexão do RSE:

  1. O cliente se conecta à porta do host 4035, daemon do RSE.
  2. O daemon do RSE cria um encadeamento do servidor RSE.
  3. O servidor RSE abre uma porta do host para o cliente se conectar. A seleção dessa porta pode ser configurada pelo usuário, no cliente na guia de propriedades do subsistema (isso não é recomendado) ou por meio da definição _RSE_PORTRANGE em rsed.envvars.
  4. O daemon RSE retorna o número da porta para o cliente.
  5. O cliente se conecta à porta do host.
Nota: O processo é semelhante para o método de conexão alternativo (opcional) usando REXEC/SSH, o qual é descrito em "(Opcional) Usando REXEC (ou SSH)" no Guia de Configuração do Host (SC23-7658).

Criptografia de Comunicação Usando SSL ou TLS

Todos os fluxos de dados do Developer for System z externos que passam pelo RSE podem ser criptografados usando Secure Socket Layer (SSL) ou Segurança da Camada de Transporte (TLS). O uso de comunicação criptografada é controlado pelas configurações no arquivo de configuração ssl.properties, conforme descrito em Comunicação Criptografada de SSL/TLS. A variável DSTORE_SSL_ALGORITHM na diretiva _RSE_JAVAOPTS de rsed.envvars permite escolher entre SSL e seu TLS sucessor como o método de criptografia, conforme documentado em "Definindo Parâmetros de Inicialização Java Extras com _RSE_JAVAOPTS" no Guia de Configuração de Host (SC23-7658).

O Depurador Integrado Engine no cliente se conecta ao gerenciador de depuração no host. O uso de SSL ou TLS é controlado por uma política Application Transparent TLS (AT-TLS).

O Emulador de Conexão do Host no cliente se conecta a um servidor TN3270 no host. O uso de SSL ou TLS é controlado por TN3270, conforme documentado no Guia de Configurações de IP do Servidor de Comunicação (SC31-8775).

Ações remotas (baseadas em host) em subprojetos do z/OS UNIX usam um servidor REXEC ou SSH no host. A comunicação SSH é sempre criptografada usando SSL.

O cliente Application Deployment Manager usa o Serviço da Web CICS TS ou a interface RESTful para chamar os serviços de host do Application Deployment Manager. O uso de SSL é controlado pelo CICS TS, conforme documentado no RACF Security Guide for CICS TS .

Verificação de Port Of Entry

O Developer for System z suporta a verificação de Port Of Entry (POE), que permite que o host acesse apenas os endereços TCP/IP confiáveis. O uso de POE é controlado pela definição de perfis específicos em seu software de segurança e a diretiva enable.port.of.entry em rsed.envvars, conforme descrito em Verificação de Port Of Entry (POE).

Observe que a ativação de POE afetará outros aplicativos TCPIP que suportam a verificação de POE, como o INETD.

Usando os PassTickets

Após o logon, os PassTickets são usados para estabelecer segurança de encadeamento no servidor RSE. Esse recurso não pode ser desativado. Os PassTickets são senhas geradas pelo sistema com um lifespan de aproximadamente 10 minutos. Os PassTickets gerados baseiam-se no algoritmo de criptografia DES, no ID do usuário, no ID do aplicativo, em um registro de data e hora e em uma chave secreta. Essa chave secreta é um número de 64 bits (16 caracteres hexadecimais) que deve ser definido para seu software de segurança. Para segurança adicional, o software de segurança do z/OS trata os PassTickets por padrão como senhas de uso único.

Para ajudá-lo a compreender o uso de PassTicket, a seguir há uma breve descrição do processo de segurança do RSE:

  1. O cliente se conecta à porta do host 4035, daemon do RSE.
  2. O daemon RSE autentica o cliente usando as credenciais apresentadas pelo cliente.
  3. O daemon RSE cria um ID de cliente exclusivo e um encadeamento do servidor RSE.
  4. O servidor RSE gera um PassTicket e cria um ambiente de segurança para o cliente, utilizando o PassTicket como senha.
  5. O cliente se conecta à porta do host retornada pelo daemon RSE.
  6. O servidor RSE valida o cliente utilizando o ID do cliente.
  7. O servidor RSE utiliza um PassTicket recém-gerado como senha para todas as ações futuras que requerem uma senha.
Nota: Um mecanismo similar é usado para configurar conexões seguras com o Debug Manager.

A senha real do cliente não é mais necessária após a autenticação inicial, pois os produtos de segurança compatíveis com SAF podem avaliar as senhas PassTickets e comuns. O servidor RSE gera e utiliza um PassTicket cada vez que uma senha é solicitada, resultando em uma senha válida (temporária) para o cliente.

O uso de PassTickets permite que o RSE configure um ambiente de segurança específico do usuário à vontade, sem a necessidade de armazenar todos os IDs de usuário e senhas em uma tabela, o que poderia ser comprometido. Ele também permite métodos de autenticação de cliente que não usam senhas reutilizáveis, como certificados X.509.

Os perfis de segurança nas classesAPPL e PTKTDATA são necessários para que se possa usar os PassTickets. Esses perfis são específicos do aplicativo e, portanto, não afetam a configuração atual do sistema.

Os PassTickets sendo específicos do aplicativo implicam em o RSE e o JES Job Monitor usarem o mesmo ID de aplicativo (APPLID). Por padrão, ambos os servidores usam FEKAPPL como APPLID, mas isso pode ser alterado pela diretiva APPLID em rsed.envvars para o RSE e em FEJJCNFG para o JES Job Monitor.

Não é recomendável usar OMVSAPPL como ID do aplicativo porque ele abrirá a chave secreta para a maioria dos aplicativos do z/OS UNIX. Também não é recomendável usar o ID do aplicativo padrão MVS, que é MVS seguido pelo ID do sistema SMF, porque isto abrirá uma chave secreta para a maioria dos aplicativos MVS (incluindo as tarefa em lote do usuário).

A menor unidade de um registro de data e hora de PassTicket é de 1 segundo. Isso significa que todos os PassTickets gerados em um único segundo pelo mesmo aplicativo para o mesmo ID de usuário serão idênticos. Isso, combinado com o PassTickets de manipulação de software de segurança z/OS, causa um problema para o Developer for System z durante o logon, pois diversos PassTickets serão necessários em um segundo. Portanto, o Developer for System z requer a configuração de um sinalizador nas definições do PassTicket que permitem que os PassTickets gerados sejam reutilizados.

Atenção: O pedido de conexão do cliente falhará se os PassTickets não estiverem configurados corretamente.

Criação de Log de Auditoria

O Developer for System z suporta a criação de log de auditoria das ações que são gerenciadas pelo daemon RSE. Os logs de auditoria são armazenados como arquivos de texto no diretório de log do daemon, utilizando o formato CSV (Comma Separated Value).

Controle de Auditoria

Várias opções no rsed.envvars influenciam a função de auditoria, como documentado em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).

O comando do operador modify switch pode ser usado para alternar manualmente para um novo arquivo de log de auditoria, conforme documentado em "Comandos do operador" no Guia de Configuração do Host (SC23-7658).

Uma mensagem de aviso é enviada para o console quando o sistema de arquivos que contém os arquivos de log de auditoria estiver em execução com pouco espaço livre. Essa mensagem do console (FEK103E) é repetida regularmente até que o problema de pouco espaço seja resolvido. Consulte "Mensagens do console" no Guia de Configuração do Host (SC23-7658) para obter uma lista de mensagens do console geradas pelo RSE.

Processamento de Auditoria

Um novo arquivo de log de auditoria é iniciado após um momento predeterminado ou quando o comando do operador modify switch é emitido. O arquivo de log antigo é salvo como audit.log.yyyymmdd.hhmmss, em que yyyymmdd.hhmmss é a data/registro de data e hora no qual o log foi fechado. A data/registro de data e hora do sistema designados ao arquivo indicam a criação do arquivo de log. A combinação das duas datas mostra o período de tempo abrangido por esse arquivo de log de auditoria.

As diretivas audit.action* em rsed.envvars permitem que você especifique uma saída de usuário (shell script do z/OS UNIX, z/OS UNIX REXX ou programa do z/OS UNIX) que será chamada pelo RSE quando um log de auditoria for fechado. Essa saída de usuário pode então processar os dados contidos no log de auditoria.

Os arquivos de log de auditoria terão a máscara de bit de permissão (-rw-r-----), se não for alterada pela diretiva audit.log.mode em rsed.envvars. Isso significa que o proprietário (UID do z/OS UNIX do daemon RSE) tem acesso de leitura e gravação, enquanto o grupo do proprietário (padrão) tem acesso de leitura. Todas as outras tentativas de acesso serão negadas, a menos que isso seja feito por um superusuário (UID 0) ou alguém com permissão suficiente para o perfil SUPERUSER.FILESYS na classe de segurança UNIXPRIV.

Dados de Auditoria

As seguintes ações são registradas:

Cada ação registrada é armazenada (com uma data/registro de data e hora) utilizando o formato Comma Separated Value (CSV), que pode ser lido por uma ferramenta de automação ou de análise de dados. Por exemplo:

yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name[,returncode]
  [,additional_information]]

Estatísticas de conjunto de dados e de membro também são registradas quando o arquivo é aberto. Elas são anexadas à linha que documenta a conclusão da ação READ e os campos são delimitados com %n. Por exemplo:

yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name,returncode,create%nmodify%n...

Os seguintes atributos são registrados, na ordem listada:

Segurança do JES

O Developer for System z permite acesso do cliente ao spool do JES através do JES Job Monitor. O servidor fornece limitações de acesso básico, que podem ser estendidas com os recursos de proteção padrão do arquivo de spool de seu produto de segurança. As ações do operador (Suspender, Liberar, Cancelar e Limpar) nos arquivos de spool são feitas através do console EMCS, para o qual é necessário configurar permissões condicionais.

Ações nas Tarefas - Limitações de Destino

O JES Job Monitor não fornece aos usuários do Developer for System z acesso total de operador ao spool do JES. Apenas os comandos Suspender, Liberar, Cancelar e Limpar estão disponíveis e, por padrão, somente para arquivos em spool que pertencem ao usuário. Os comandos são emitidos selecionando a opção apropriada na estrutura de menus do cliente (sem prompt de comandos). O escopo dos comandos pode ser ampliado, utilizando perfis de segurança para definir para quais tarefas os comandos estão disponíveis.

Semelhante ao caractere de ação SDSF SJ, o JES Job Monitor também suporta o comando Mostrar JCL para recuperar a JCL que criou a saída de tarefa selecionada e o mostra em uma janela de editor. O JES Job Monitor recupera a JCL do JES, tornando-o uma função útil para situações em que o membro JCL original não é facilmente localizado.

Tabela 1. Comandos do Console do JES Job Monitor
Ações JES2 JES3
Suspender $Hx(jobid)

with x = {J, S or T}

*F,J=jobid,H
Liberar $Ax(jobid)

with x = {J, S or T}

*F,J=jobid,R
Cancelar $Cx(jobid)

with x = {J, S or T}

*F,J=jobid,C
Limpar $Cx(jobid),P

with x = {J, S or T}

*F,J=jobid,C
Mostrar JCL não-aplicável não-aplicável

Os comandos JES disponíveis listados na Tabela 1 são limitados por padrão às tarefas que pertencem ao usuário. Isto pode ser alterado com a diretiva LIMIT_COMMANDS, conforme documentado em "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658).

Tabela 2. Matriz de Permissão do Comando LIMIT_COMMANDS
Proprietário da tarefa
LIMIT_COMMANDS Usuário Outros
USERID (padrão) Permitido Não permitido
LIMITED Permitido Permitido somente se for permitido explicitamente por perfis de segurança
NOLIMIT Permitido Permitido se for permitido pelos perfis de segurança ou quando a classe JESSPOOL não estiver ativa

O JES utiliza a classe JESSPOOL para proteger os conjuntos de dados SYSIN/SYSOUT. Semelhante a SDSF, o JES Job Monitor estende o uso da classe JESSPOOL para proteger os recursos de tarefas também.

Se LIMIT_COMMANDS não for USERID, o JES Job Monitor consultará se há permissão para o perfil relacionado na classe JESSPOOL, conforme mostrado na tabela a seguir.

Tabela 3. Perfis JESSPOOL Estendidos
Comando Perfil JESSPOOL Acesso Necessário
Suspender nodeid.userid.jobname.jobid ALTER
Liberar nodeid.userid.jobname.jobid ALTER
Cancelar nodeid.userid.jobname.jobid ALTER
Limpar nodeid.userid.jobname.jobid ALTER
Mostrar JCL nodeid.userid.jobname.jobid.JCL READ

Use as seguintes substituições na tabela anterior:

nodeid O ID do nó NJE do subsistema JES de destino
userid ID do usuário local do proprietário da tarefa
jobname Nome da tarefa
jobid ID da tarefa do JES

Se a classe JESSPOOL não estiver ativa, existe um comportamento diferente para o valor LIMITED e NOLIMIT de LIMIT_COMMANDS, conforme descrito no "Tabela de matriz de permissão do comando LIMIT_COMMANDS" em "FEJJCNFG, arquivo de Configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658). O comportamento é idêntico quando JESSPOOL está ativo, já que a classe, por padrão, nega a permissão se um perfil não estiver definido.

Ações nas Tarefas - Limitações de Execução

A segunda fase da segurança de comando em spool do JES, depois de especificar os destinos permitidos, inclui as permissões necessárias para realmente executar o comando do operador. Essa autorização de execução é aplicada pelas verificações de segurança do z/OS e do JES.

Observe que Mostrar JCL não é um comando do operador, como os outros comandos JES Job Monitor (Suspender, Liberar, Cancelar e Limpar), de modo que as limitações na próxima lista não se aplicam porque não há nenhuma verificação de segurança adicional.

O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário através de um console MCS (EMCS) estendido, cujo nome é controlado com o diretiva CONSOLE_NAME, conforme documentado em "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658).

O JES Job Monitor permite que você defina quanta autoridade é concedida ao console EMCS com a diretiva LIMIT_CONSOLE, conforme o documento no "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (S517-9094).

Tabela 4. Matriz de Autoridade do Console LIMIT_CONSOLE
LIMIT_CONSOLE Perfil ativo na classe OPERCMDS Não há perfil ativo na classe OPERCMDS
LIMITED (padrão) Permitido, se houver permissão do perfil de segurança Não permitido
NOLIMIT Permitido, se houver permissão do perfil de segurança Permitido

Essa configuração permite que o administrador de segurança defina permissões granulares de execução de comandos usando as classes OPERCMDS e CONSOLE.

Supondo que a identidade do servidor JES Job Monitor, criando um console JMON a partir de uma sessão do TSO, seja impedida por seu software de segurança. Embora o console possa ser criado, o ponto de entrada é diferente (JES Job Monitor versus TSO). Os comandos JES emitidos a partir desse console falharão na verificação de segurança se a segurança estiver configurada conforme documentado nesta publicação e o usuário não tiver autoridade para comandos JES por outros meios.

Observe que o JES Job Monitor não poderá criar o console quando um comando tiver que ser executado se o nome do console já estiver sendo usado. Para evitar isso, o programador de sistema pode configurar a diretiva GEN_CONSOLE_NAME=ON no arquivo de configuração do JES Job Monitor ou o administrador de segurança pode definir perfis de segurança para que os usuários do TSO parem de criar um console. Os comandos de amostra do RACF a seguir impedem que qualquer indivíduo (exceto aqueles permitidos) crie um console TSO ou SDSF:

Nota: Sem autorização para esses comandos do operador, os usuários ainda poderão enviar tarefas e ler a saída da tarefa por meio do JES Job Monitor, se tiverem autoridade suficiente para possíveis perfis que protejam esses recursos (como aqueles das classes JESINPUT, JESJOBS e JESSPOOL).

Consulte o Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre proteção de comandos do operador.

Acesso aos Arquivos de Spool

O JES Job Monitor permite acesso de procura a todos os arquivos em spool, por padrão. Isso pode ser alterado com a diretiva LIMIT_VIEW, conforme documentado em "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658).

Tabela 5. Matriz de permissão de navegação LIMIT_VIEW
Proprietário da tarefa
LIMIT_VIEW Usuário Outros
USERID Permitido Não permitido
NOLIMIT (padrão) Permitido Permitido se for permitido pelos perfis de segurança ou quando a classe JESSPOOL não estiver ativa

Para limitar os usuários às suas próprias tarefas no spool JES, defina a instrução "LIMIT_VIEW=USERID" no arquivo de configuração do JES Job Monitor, FEJJCNFG. Se os usuários precisarem de acesso a um intervalo maior de tarefas, mas não todas, use os recursos de proteção de arquivo de spool padrão do seu produto de segurança, como a classe JESSPOOL.

Ao definir a proteção adicional, lembre-se que o JES Job Monitor utiliza a SAPI (SYSOUT Application Program Interface) para acessar o spool. Isto significa que o usuário precisa de, pelo menos, acesso UPDATE aos arquivos de spool, mesmo para a funcionalidade de procura. Esse requisito não se aplicará se você executar o z/OS 1.7 (z/OS 1.8 para JES3) ou superior. Aqui, a permissão READ é suficiente para a funcionalidade de procura.

Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre a proteção do arquivo em spool do JES.

Comunicação Criptografada de SSL/TLS

A comunicação externa (cliente-host) usando RSE pode ser criptografada usando SSL (Secure Socket Layer) ou Transport Layer Security (TLS). Esse recurso é desativado por padrão e é controlado pelas configurações no ssl.properties. Consulte "(Opcional) ssl.properties, criptografia RSE SSL" no Guia de Configuração do Host (SC23-7658).

O daemon RSE e o servidor RSE suportam diferentes mecanismos para armazenar certificados devido a diferenças de arquitetura entre eles. Isso implica que as definições e os certificados SSL são necessários para o daemon RSE e para o servidor RSE. Um certificado compartilhado poderá ser usado se o daemon RSE e o servidor RSE usarem o mesmo método de gerenciamento de certificado.

Tabela 6. Mecanismos de armazenamento de certificado SSL
Armazenamento de certificado Criado e gerenciado por Daemon RSE Servidor RSE
conjunto de chaves produto de segurança compatível com SAF suportados suportados
banco de dados de chaves gskkyman do z/OS UNIX suportados /
keystore keytool do Java / suportados
Nota: Conjuntos de chaves compatíveis com SAF é o método preferido para gerenciar certificados.

Os conjuntos de chaves compatíveis com SAF podem armazenar a chave privada do certificado no banco de dados de segurança ou usando ICSF (Integrated Cryptographic Service Facility), a interface para o hardware de criptografia do System z.

ICSF é recomendado para o armazenamento de chaves privadas associadas a certificados digitais, porque é uma solução mais segura do que o gerenciamento de chaves privadas não-ICSF. O ICSF garante que as chaves privadas sejam criptografadas na chave mestra do ICSF e que o acesso a elas seja controlado por recursos gerais das classes de segurança CSFKEYS e CSFSERV. Além disso, o desempenho operacional é aprimorado, pois o ICSF utiliza o Coprocessador Criptográfico de hardware. Consulte o Cryptographic Services ICSF Administrator's Guide (SA22-7521) para obter mais detalhes sobre o ICSF e sobre como controlar quem pode usar chaves e serviços criptográficos.

O daemon RSE utiliza funções SSL do Sistema para gerenciar as comunicações criptografadas por SSL. Isso implica que SYS1.SIEALNKE deve ser controlado pelo programa pelo software de segurança e estar disponível para o RSE por meio de LINKLIST ou da diretiva STEPLIB em rsed.envvars.

O ID do usuário do RSE (stcrse nos comandos de amostra a seguir) precisa de autorização para acessar esse conjunto de chaves e os certificados relacionados quando os conjuntos de chaves compatíveis com SAF são usados para o daemon RSE ou o servidor RSE.

A variável DSTORE_SSL_ALGORITHM na diretiva _RSE_JAVAOPTS de rsed.envvars permite escolher entre SSL e seu TLS sucessor como método de criptografia, conforme documentado em "Definindo Parâmetros de Inicialização Java Extras com _RSE_JAVAOPTS" no Guia de Configuração de Host (SC23-7658).

Consulte Capítulo 13. Configurando o SSL e a Autenticação X.509 para obter mais detalhes sobre como ativar o SSL para Developer for System z.

Comunicação Criptografada pelo Depurador Integrado

A comunicação externa (cliente-host) com o Debug Manager opcional também pode ser criptografada usando SSL ou TLS. Para fazer a criptografia dessa maneira, crie uma política AT-TLS para a porta usada pelo Debug Manager para comunicação externa, por padrão 5335. Uma política de amostra é fornecida em Figura 9. Consulte Communications Server IP Configuration Guide (SC31-8775) para obter detalhes sobre a configuração AT-TLS (Application Transparent TLS).

Figura 9. Política AT-TLS para Debug Manager
TTLSRule                      RDz_Debug_Manager
{
 LocalPortRange           5335
 Direction                Inbound
 TTLSGroupActionRef       grp_Production
 TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction         RDz_Debug_Manager
{
 HandshakeRole Server
 TTLSKeyRingParms
 {
  Keyring dbgmgr.racf     # Keyring must be owned by the Debug Manager
 }
}
TTLSGroupAction               grp_Production
{
 TTLSEnabled              On
 Trace                    2
}

Autenticação de cliente usando certificados X.509

O daemon RSE suporta que os próprios usuários se autentiquem com um certificado X.509. Usar a comunicação criptografada SSL é um pré-requisito para essa função, uma vez que é uma extensão para a autenticação de host com um certificado usado no SSL.

O daemon RSE inicia o processo de autenticação de cliente pela validação do certificado de cliente. Alguns aspectos chave que são verificados são as datas de validade do certificado e a fidelidade da Autoridade de Certificação (CA) usada para assinar o certificado. Opcionalmente, também é possível consultar uma Lista de Revogação de Certificado (CRL) (terceiros).

Depois que o daemon RSE valida o certificado, ele é processado para autenticação. O certificado é transmitido a seu produto de segurança para autenticação, a menos que a diretiva rsed.envvars enable.certificate.mapping esteja configurada como false, quando o daemon RSE fará a autenticação.

Se bem-sucedido, o processo de autenticação determinará o ID do usuário a ser usado para esta sessão, que é, então, testado pelo daemon do RSE para assegurar que seja útil no sistema host onde o daemon do RSE está em execução.

A última verificação (que é feita para cada mecanismo de autenticação, não apenas certificados X.509) verifica se o ID do usuário tem permissão para usar o Developer for System z.

Se você estiver familiarizado com as classificações de segurança do SSL usadas por TCP/IP, a combinação dessas etapas de validação corresponderão às especificações de "Autenticação de Cliente Nível 3" (a mais alta disponível).

Validação da Autoridade de Certificação (CA)

Parte do processo de validação do certificado inclui verificar se o certificado foi assinado por uma Autoridade de Certificação (CA) de confiança. Para fazer isso, o daemon do RSE deve ter acesso a um certificado que identifique a CA.

Ao usar o banco de dados de chaves gskkyman para sua conexão SSL, o certificado da CA deve ser incluído no banco de dados de chaves.

Ao usar um conjunto de chaves SAF (que é o método aconselhado), você deve incluir o certificado da CA em seu banco de dados de segurança como o certificado CERTAUTH com o atributo TRUST ou HIGHTRUST, conforme mostrado neste comando RACF de amostra:

Observe que a maioria dos produtos de segurança já tem os certificados para as CAs reconhecidas disponíveis em seu banco de dados com um status NOTRUST. Use os comandos RACF de amostra a seguir para listar os certificados de CA existentes e marcar um como confiável com base no rótulo designado a ele.

Nota: O status HIGHTRUST será necessário se você depender do RACF para autenticar o usuário com base na extensão HostIdMappings do certificado. Consulte o Autenticação por Software de Segurança para obter informações adicionais.

Quando o certificado da CA for incluído em seu banco de dados de segurança, ele deverá ser conectado ao conjunto de chaves RSE, conforme mostrado neste comando RACF de amostra:

Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter informações adicionais sobre o comando RACDCERT.

Atenção: Se você depender do daemon RSE em vez de seu software de segurança para autenticar um usuário, deverá tomar cuidado para não confundir as CAs com os status TRUST e HIGHTRUST no conjunto de chaves SAF ou no banco de dados de chaves gskkyman. O daemon do RSE não é capaz de diferenciar entre os dois, portanto, os certificados assinados por uma CA com status TRUST será válido para propósitos de autenticação de ID do usuário.

(Opcional) Consulte uma Certificate Revocation List (CRL)

Se desejado, é possível instruir o daemon do RSE para verificar uma ou mais Certificate Revocation Lists (CRL) para incluir segurança extra para o processo de validação. Isso é feito incluindo variáveis de ambiente relacionadas à CRL em rsed.envvars.

Consulte Cryptographic Services System Secure Sockets Layer Programming (SC24-5901) para obter informações adicionais sobre essas e outras variáveis de ambiente usadas pelo z/OS System SSL.

Nota: Tome cuidado ao especificar outras variáveis de ambiente do z/OS System SSL (GSK_*) em rsed.envvars, pois elas podem alterar a maneira como o daemon RSE trata as conexões SSL e a autenticação de certificado.

Autenticação por Software de Segurança

O RACF executa várias verificações para autenticar um certificado e retornar o ID do usuário associado. Observe que outros produtos de segurança podem fazer isso de forma diferente. Consulte a documentação de seu produto de segurança para obter informações adicionais sobre a função initACEE usada para realizar a autenticação (modo de consulta).

  1. O RACF verifica se o certificado está definido na classe DIGTCERT. Se estiver, o RACF retornará o ID do usuário que estava associado a este certificado quando ele foi incluído no banco de dados RACF.

    Os certificados são definidos como RACF usando o comando RACDCERT, como no seguinte exemplo:

    RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
  2. Se o certificado não estiver definido, o RACF verificará para ver se há um filtro de nome de certificado correspondente definido nas classes DIGTNMAP ou DIGTCRIT. Se esse for o caso, retorna o ID do usuário associado ao filtro de correspondência mais específico.
    Nota: Aconselha-se não usar filtros de nomes para certificados usados pelo Developer for System z, pois esses filtros mapeiam todos os certificados para um único ID de usuário. O resultado é que todos os usuários do Developer for System z efetuarão logon com o mesmo ID do usuário.
  3. Se não houver nenhum filtro de nome correspondente, o RACF localizará a extensão de certificado HostIdMappings e extrairá o par de ID de usuário e nome do host integrado. Se localizado e validado, o RACF retornará o ID do usuário definido na extensão HostIdMappings.

    O par ID do usuário e nome do host é válido se todas estas condições forem verdadeiras:

    A definição da extensão HostIdMappings na sintaxe ASN.1 é:

    id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1}
    HostIdMappings::= SET OF HostIdMapping
    HostIdMapping::= SEQUENCE{
       hostName        IMPLICIT[1] IA5String,
       subjectId         IMPLICIT[2] IA5String,
       proofOfIdPossession IdProof OPTIONAL
     }
     IdProof::= SEQUENCE{
       secret        OCTET STRING,
       encryptionAlgorithm OBJECT IDENTIFIER
     }

    Nota: Uma extensão HostIdMappings não é honrada se o ID do usuário de destino tiver sido criado após o início do período de validade para o certificado contendo a extensão HostIdMappings. Portanto, se você estiver criando IDs de usuários especificamente para certificados com extensões HostIdMappings, certifique-se de que você tenha criado os IDs de usuários antes de os pedidos de certificados serem enviados.

    Consulte Security Server RACF Security Administrator’s Guide (SA22-7683) para obter mais informações sobre certificados X.509, como são gerenciados pelo RACF e como definir filtros de nome de certificado. Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter informações adicionais sobre o comando RACDCERT.

Autenticação por Daemon do RSE

Developer for System z podem fazer autenticação de certificado X.509 básica sem contar com seu produto de segurança. A autenticação realizada pelo daemon do RSE requer que um ID do usuário e nome do host sejam definidos em uma extensão de certificado e está ativa somente se a diretiva enable.certificate.mapping em rsed.envvars estiver configurada para FALSE.

Essa função deverá ser usada se o seu produto de segurança não suportar autenticação de um usuário com base em um certificado X.509 ou se o seu certificado for causar falha no(s) teste(s) feito(s) por seu produto de segurança (por exemplo, o certificado possui um identificador falho para a extensão HostIdMappings e não há nenhum filtro ou definição em DIGTCERT).

O cliente consultará o usuário pelo identificador da extensão (OID) a ser usado, que é, por padrão, o OID de HostIdMappings, {1 3 18 0 2 18 1}.

O daemon do RSE extrairá o ID do usuário e o nome do host do mesmo usando o formato da extensão HostIdMappings. Esse formato está descrito em Autenticação por Software de Segurança.

O par ID do usuário e nome do host é válido se todas estas condições forem verdadeiras:

Atenção: Depende do administrador de segurança assegurar que todas as CAs conhecidas do daemon RSE sejam altamente confiáveis, já que o daemon RSE não pode verificar se aquele que assinou o certificado de cliente é altamente confiável ou apenas confiável. Consulte Validação da Autoridade de Certificação (CA) para obter informações adicionais sobre certificados de CA acessíveis.

Verificação de Port Of Entry (POE)

O Developer for System z suporta a verificação de Port Of Entry (POE), que permite que o host acesse apenas os endereços TCP/IP confiáveis. Esse recurso fica desativado por padrão e requer a definição do perfil de segurança BPX.POE, conforme mostrado nos seguintes comandos RACF de amostra:

Nota:
  • O RSE deve ser configurado para usar o POE removendo-se o comentário da opção "enable.port.of.entry=true" em rsed.envvars, conforme documentado em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
  • O ID de usuário do RSE STCRSE requer o UID(0) quando esse perfil não está definido e a verificação de POE está ativada em rsed.envvars.
  • A definição de BPX.POE afetará outros aplicativos TC/PIP que suportam a verificação de POE, como INETD.
  • As zonas de segurança (perfis EZB.NETACCESS.**, que são os intervalos de endereços IP) devem ser configuradas na classe SERVAUTH para utilizar toda a força da verificação de POE.

Consulte o Communications Server IP Configuration Guide (SC31-8775) para obter informações adicionais sobre o controle de acesso à rede usando a verificação de POE.

Alterando Funções de Cliente

Clientes do Developer for System z versão 8.5.1 e mais recente podem verificar a autorização de acesso aos perfis de segurança do SAF, e baseado no resultado, ativar ou desativar a função relacionada para o usuário.

Developer for System z verifica permissões de acesso aos perfis listados em Tabela 7 para determinar quais opções devem ser ativadas ou desativadas para o usuário.

Tabela 7. Informações de SAF para Alterar Funções de Cliente
Perfil FACILITY Compri
mento fixo
Acesso Necessário Resultado
FEK.USR.OFF.REMOTECOPY.MVS.sysname 27 READ O cliente desativa funções de copiar e relacionadas para conjuntos de dados do MVS

Nota: O Developer for System z presume que um usuário não tenha autorização de acesso quando o software de segurança indica que ele não pode determinar se um usuário tem ou não autorização de acesso a um perfil. Um exemplo disso é quando o perfil não está definido.

O valor sysname corresponde ao nome do sistema de destino.

A coluna "Comprimento fixo" documenta o comprimento da parte fixa do perfil de segurança relacionado.

Por padrão, o Developer for System z espera os perfis FEK.* estarem na classe de segurança FACILITY. Observe que os perfis na classe FACILITY estão limitados a 39 caracteres. Se a soma do comprimento da parte do perfil fixo (FEK.USR.<key>) e o comprimento da parte do perfil específica do site (sysname) exceder este número, é possível posicionar os perfis em outra classe e instrui o Developer for System z a usar esta classe no lugar. Para fazer isso, remova o comentário da linha _RSE_FEK_SAF_CLASS em rsed.envvars e forneça o nome de classe desejado.

As seguintes definições de segurança de amostra permitem a ação REMOTECOPY.MVS para todos os usuários no CDFMVS08, exceto aqueles no grupo RESTRICT:

RDEFINE FACILITY (FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT CONTROL')
PERMIT FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08 CLASS(FACILITY) -
  ID(RESTRICT) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

OFF.REMOTECOPY.MVS

Quando os usuários tiverem acesso de LEITURA ao perfil FEK.USR.OFF.REMOTECOPY.MVS.sysname, então seus clientes do Developer for System z versão 8.5.1 e mais recente desativarão as ações arrastar, copiar, salvar como e trabalhar offline para os conjuntos de dados MVS. O resultado é que os usuários podem acessar os conjuntos de dados nesse sistema, mas os usuários não podem criar uma cópia local de um conjunto de dados em sua estação de trabalho. Isso ajuda a evitar a exposição de informações confidenciais se a estação de trabalho local for perdida ou roubada.

Grupos de Desenvolvedores de Push-to-client

Os clientes do Developer for System z versão 8.0.1 e superior podem extrair arquivos de configuração de cliente e informações de upgrade do host quando se conectam, assegurando que todos os clientes tenham configurações comuns e estejam atualizados.

Desde a versão 8.0.3, o administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar as necessidades de diferentes grupos de desenvolvedores. Isso permite que os usuários recebam uma configuração customizada, com base em critérios como associação de um grupo LDAP ou permissão para um perfil de segurança.

Ao usar as definições do banco de dados de segurança como mecanismo de seleção (o valor SAF é especificado para diretivas em pushtoclient.properties), o Developer for System z verifica as permissões de acesso aos perfis listados na Tabela 8 para determinar a quais grupos de desenvolvedores o usuário pertence, e se um usuário tem permissão para rejeitar atualizações.

Tabela 8. Informações do SAF de Push-to-client
Perfil FACILITY Compri
mento fixo
Acesso Neces
sário
Resultado
FEK.PTC.CONFIG.ENABLED.
  sysname.devgroup
23 READ O cliente aceita atualizações de configuração para o grupo especificado
FEK.PTC.PRODUCT.
  ENABLED.sysname.devgroup
24 READ O cliente aceita atualizações de produto para o grupo especificado
FEK.PTC.REJECT.CONFIG.
  UPDATES.sysname
30 READ O usuário pode rejeitar atualizações de configuração
FEK.PTC.REJECT.PRODUCT.
  UPDATES.sysname
31 READ O usuário pode rejeitar atualizações de produto
Nota: O Developer for System z presume que um usuário não tenha autorização de acesso quando o software de segurança indica que ele não pode determinar se um usuário tem ou não autorização de acesso a um perfil. Um exemplo disso é quando o perfil não está definido.

O valor devgroup corresponde ao nome do grupo designado a um grupo específico de desenvolvedores. Observe que o nome do grupo é visível nos clientes do Developer for System z.

O valor sysname corresponde ao nome do sistema de destino.

A coluna "Comprimento fixo" documenta o comprimento da parte fixa do perfil de segurança relacionado.

Por padrão, o Developer for System z espera os perfis FEK.* estarem na classe de segurança FACILITY. Observe que os perfis na classe FACILITY estão limitados a 39 caracteres. Se a soma do comprimento da parte de perfil fixo (FEK.PTC.<key>) e o comprimento da parte de perfil específico do site (sysname ou sysname.devgroup)exceder esse número, você poderá colocar os perfis em outra classe e instruir o Developer for System z a usar essa classe no lugar. Para fazer isso, remova o comentário da linha _RSE_FEK_SAF_CLASS em rsed.envvars e forneça o nome de classe desejado.

Observe que o administrador de cliente deve estar na lista de acesso dos perfis FEK.PTC.*.ENABLED.* para definir e gerenciar os metadados de push-to-client relacionados. Isso significa que os perfis devem ser definidos com (pelo menos) o administrador de cliente na lista de acesso para que o push-to-client com suporte de grupo possa ser implementado.

Consulte "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094) para obter mais informações sobre como ativar o suporte a diversos grupos. Consulte Capítulo 7. Considerações de Push-to-client para obter mais informações sobre conceitos e implementação de push-to-client.

Segurança de Depuração

O Depurador Integrado opcional é capaz de depurar transações CICS carregadas na memória de leitura. Quando usado para depurar uma transação no estado de problema (não autorizado), o Depurador Integrado validará se o usuário que possui a sessão de depuração tem permissão para fazer isso.

O Developer for System z verifica o acesso aos perfis listados em Tabela 9 para determinar quais permissões de depuração foram concedidas.

Tabela 9. Informações de SAF para Funções de Depuração
Perfil FACILITY Acesso Necessário Resultado
AQE.AUTHDEBUG.WRITEBUFFER UPDATE O usuário está apto a depurar transações CICS somente leitura

Nota: O Developer for System z presume que um usuário não tenha autorização de acesso quando o software de segurança indica que ele não pode determinar se um usuário tem ou não autorização de acesso a um perfil. Um exemplo disso é quando o perfil não está definido.

As definições de segurança de amostra a seguir permitem a ação AUTHDEBUG.WRITEBUFFER para todos os usuários no grupo RDZDEBUG:

RDEFINE FACILITY (AQE.AUTHDEBUG.WRITEBUFFER) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - DEBUG CICS READ-ONLY')
PERMIT AQE.AUTHDEBUG.WRITEBUFFER CLASS(FACILITY) -
  ID(RDZDEBUG) ACCESS(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH

segurança do CICSTS

O Depurador Integrado opcional é capaz de depurar transações CICS. Consulte Depuração de Transação do CICS para obter mais detalhes.

O Developer for System z permite, através do Application Deployment Manager, que administradores do CICS controlem quais definições de recurso do CICS podem ser editadas pelo desenvolvedor, seus valores-padrão e a exibição de uma definição de recurso do CICS por meio de um servidor CICS Resource Definition (CRD). Consulte Capítulo 8. considerações CICSTS para obter informações adicionais sobre as definições de segurança necessárias do CICS TS.

repositório do CRD

O conjunto de dados de VSAM do repositório do servidor CRD contém todas as definições de recurso padrão e deve, portanto, ser protegido contra atualizações, mas os desenvolvedores devem ter permissão para ler os valores armazenados aqui.

transações do CICS

O Developer for System z fornece várias transações que são usadas pelo servidor CRD durante a definição e a consulta de recursos do CICS. Quando a transação é conectada, a verificação de segurança de recurso do CICS, se ativada, garante que o ID do usuário esteja autorizado para executar o ID de transação.

comunicação criptografada por SSL

O cliente Application Deployment Manager usa os Serviços da Web do CICS TS ou a interface RESTful para chamar o servidor CRD. O uso de SSL para essa comunicação é controlado pela definição TCPIPSERVICE do CICS TS, conforme documentado no RACF Security Guide for CICS TS .

Informações Variadas

Lixeira GATE

A primeira vez que um espaço de endereço instrui o RACF a acessar uma classe de recurso que não é RACLISTed (armazenada na memória), como a classe DATASET, o RACF recuperará e armazenará todos os perfis genéricos no espaço de endereço do usuário, em uma lista conhecida como GATE (Generic Anchor Table Entry). Até o z/OS 1.12, RACF mantém quatro âncoras genéricas para cada espaço de endereço e quatro para cada MVS TCB que tem seu próprio ACEE. Quando todos os quatro forem usados, RACF substituirá o menos recentemente mencionado quando um novo entrar.

Se seus usuários acessam frequentemente mais de quatro qualificadores de alto nível de conjunto de dados, os conjuntos de encadeamentos RSE (que atendem a diversos usuários usando encadeamentos com ACEEs específicos ao usuário) poderão passar pela lixeira GATE pois RACF tem de rotear novas entradas por meio dos slots de âncora disponíveis.

Em z/OS 1.12, RACF introduziu a opção GENERICANCHOR do comando SET, que permite aumentar o tamanho da tabela. Isso pode ser configurado em todo o sistema para cada nome de tarefa.

ACEE Gerenciado

O Developer for System z usa os serviços kernel do z/OS UNIX, como pthread_security_np() e __passwd(), que usam o serviço de segurança InitACEE, resultando em blocos de controle de segurança "ACEE gerenciado". Um ACEE (Elemento de Ambiente do Acessador) gerenciado é armazenado em cache pelo produto de segurança, e o produto de segurança ignorará determinadas mudanças (como mudanças de senha fora do Developer for System z) até que o cache atinja o tempo limite. (O esgotamento do tempo limite pode levar vários minutos.)

Atualize o cache do ACEE gerenciado após as mudanças de segurança para garantir que os novos dados sejam usados pelo Developer for System z.

Segurança de SCLM

O serviço SCLM Developer Toolkit oferece funcionalidade de segurança opcional para as funções Construir, Promover e Implementar.

Se a segurança for ativada para uma função pelo administrador de SCLM, as chamadas SAF serão feitas para verificar a autoridade para executar a função protegida com o ID do usuário do responsável pela chamada ou do substituto.

Consulte SCLM Developer Toolkit Administrator’s Guide (SC23-9801), para obter informações adicionais sobre as definições de segurança SCLM necessárias.

arquivos de configuração do Developer for System z

Há vários arquivos de configuração do Developer for System z cujas diretivas impactam a segurança e a configuração de auditoria. Com base nas informações deste capítulo, o administrador de segurança e o programador de sistemas podem decidir quais devem ser as configurações para as diretivas a seguir.

JES Job Monitor - FEJJCNFG

Nota: Detalhes sobre essas e outras diretivas FEJJCNFG estão disponíveis em "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658).

RSE - rsed.envvars

Nota: Detalhes sobre essas e outras diretivas rsed.envvars estão disponíveis em "rsed.envvars, arquivo de configuração RSE" no Guia de Configuração do Host (SC23-7658).

RSE - ssl.properties

Nota: Detalhes sobre essas e outras diretivas ssl.properties estão disponíveis em "(Opcional) ssl.properties, criptografia RSE SSL" no Guia de Configuração do Host (SC23-7658).

RSE - pushtoclient.properties

Nota: Detalhe sobre essas e outras diretivas pushtoclient.properties estão disponíveis em "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094).

Definições de segurança

Customize e envie o membro de amostra FEKRACF, que tem comandos RACF e z/OS UNIX de amostra para criar as definições de segurança básicas para o Developer for System z.

FEKRACF está localizado em FEK.#CUST.JCL, a menos que tenha especificado um local quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de Customização" no Guia de Configuração do Host do IBM Rational Developer for System z para obter mais detalhes.

Consulte RACF Command Language Reference (SA22-7687), para obter mais informações sobre comandos RACF.

Nota:
  • Para esses sites que usam CA ACF2TM for z/OS, consulte a página de produto no site de suporte CA (https://support.ca.com) e verifique o Developer for System z Knowledge Document, TEC492389 relacionado. Este Knowledge Document tem detalhes sobre os comandos de segurança necessários para configurar adequadamente o Developer for System z.
  • Para esses sites que usam CA Top Secret® for z/OS, consulte a página de produto no site de suporte de CA (https://support.ca.com) e verifique o Developer for System z Knowledge Document, TEC492091 relacionado. Este Knowledge Document tem detalhes sobre os comandos de segurança necessários para configurar adequadamente o Developer for System z.

As seções a seguir descrevem as etapas necessárias, configuração opcional e possíveis alternativas.

Requisitos e Lista de Verificação

Para concluir a configuração de segurança, o administrador de segurança deve conhecer os valores que estão listados em Tabela 10. Esses valores foram definidos durante as etapas anteriores da instalação e da customização do Developer for System z.

Tabela 10. Variáveis de configuração de segurança
Descrição
  • Valor-padrão
  • Onde encontrar a resposta
Valor
Developer for System z qualificador de alto nível do produto
  • FEK
  • Instalação SMP/E
Developer for System z qualificador de alto nível de customização
  • FEK.#CUST
  • FEK.SFEKSAMP(FEKSETUP), conforme descrito em "Configuração de Customização" no Guia de Configuração do Host do IBM Rational Developer for System z.
dNome da Tarefa Iniciada pelo Depurador Integrado
  • DBGMGR
  • FEK.#CUST.PROCLIB(DBGMGR), conforme descrito em "Mudanças em PROCLIB" no Guia de Configuração de Host do IBM Rational Developer for System z
Nome da tarefa iniciada do JES Job Monitor
  • JMON
  • FEK.#CUST.PROCLIB(JMON), conforme descrito em "Mudanças de PROCLIB" no Guia de Configuração do Host do IBM Rational Developer for System z
Nome da tarefa iniciada do daemon RSE
  • RSED
  • FEK.#CUST.PROCLIB(RSED), conforme descrito em "Mudanças de PROCLIB" no Guia de Configuração do Host do IBM Rational Developer for System z.
ID do aplicativo
  • FEKAPPL
  • /etc/rdz/rsed.envvars, conforme descrito em "Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host do IBM Rational Developer for System z

A lista a seguir é uma visão geral das ações que são necessárias para concluir a configuração de segurança básica do Developer for System z. Conforme documentado nas seções a seguir, métodos diferentes podem ser usados para preencher esses requisitos, dependendo do nível de segurança necessário. Para obter informações sobre a configuração de segurança dos serviços opcionais do Developer for System z, consulte as seções anteriores.

Ativar Configurações de Segurança e Classes

Developer for System z usa uma variedade de mecanismos de segurança para assegurar um ambiente de sistema host seguro e controlado para o cliente. Para fazer isto, várias classes e configurações de segurança devem estar ativas, conforme mostrado com os seguintes comandos RACF de amostra:

Definir um segmento OMVS para usuários do Developer for System z

Um segmento OMVS do RACF ou equivalente que especifica um ID do usuário z/OS UNIX (UID) não zero válido, diretório inicial e comando shell deve ser definido para cada usuário do Developer for System z. Seu grupo padrão também requer um segmento OMVS com um ID de grupo.

Ao usar o Depurador Integrado, o ID do usuário sob o qual o aplicativo sendo depurado está ativo e seu grupo padrão também requer um segmento RACF OMVS válido ou equivalente.

Nos comandos de amostra do RACF a seguir, substitua os marcadores #userid, #user-identifier, #group-name e #group-identifier por valores reais:

Definir as Tarefas Iniciadas do Developer for System z

Os comandos RACF de amostra a seguir criam as tarefas iniciadas de DBGMGR, JMON e RSED, com IDs do usuário protegidos ( STCDBGM, STCJMON e STCRSE) e o grupo STCGROUP designado a elas. Substitua os marcadores #group-id e #user-id-* pelos IDs de OMVS válidos.

Nota:
  • Assegure-se de que os IDs de usuário das tarefas iniciadas sejam protegidos especificando-se a palavra-chave NOPASSWORD.
  • Assegure-se de que o servidor RSE tenha um uid OMVS exclusivo devido aos privilégios relacionados ao z/OS UNIX concedidos a esse uid.
  • O daemon RSE exige um tamanho de espaço de endereço grande (2GB) para operação adequada. Configure este valor na variável ASSIZEMAX do segmento OMVS para o ID do usuário STCRSE. Configurar esse valor assegura que o daemon RSE obtenha o tamanho da região necessário, independentemente de mudanças para MAXASSIZE em SYS1.PARMLIB(BPXPRMxx).
  • O RSE exige também um grande número de encadeamentos para operação adequada. Você pode definir o limite na variável THREADSMAX do segmento OMVS do ID do usuário STCRSE. Configurar o limite assegura que o RSE obtenha o limite de encadeamento necessário, independentemente de mudanças para MAXTHREADS ou MAXTHREADTASKS em SYS1.PARMLIB(BPXPRMxx). Para determinar o valor correto para o limite de encadeamento, consulte "Considerações de ajuste" no Referência de Configuração do Host (S517-9857).
  • O ID do usuário STCJMON é outro bom candidato para configurar THREADSMAX no segmento OMVS, pois o JES Job Monitor usa um encadeamento por conexão do cliente.
  • A tarefa iniciada pelo Depurador Integrado (DBGMGR) é usada apenas pelo recurso do Depurador Integrado opcional.

Considere tornar o ID do usuário STCRSE restrito. Usuários com o atributo RESTRICTED não podem acessar recurso protegidos (MVS) que não estão especificamente autorizados a acessar.

ALTUSER STCRSE RESTRICTED

Para assegurar que os usuários restritos não obtenham acesso a recursos do sistema de arquivos z/OS UNIX por meio de "outras" permissões de bits, defina o perfil RESTRICTED.FILESYS.ACCESS na classe UNIXPRIV com UACC(NONE). Para obter mais informações sobre restringir IDs de usuário, consulte Security Server RACF Security Administrator's Guide (SA22-7683).

Atenção: Se usar IDs de usuário restritos, inclua explicitamente o acesso a um recursos usando os comandos de TSO PERMIT ou z/OS UNIX setfacl. Os recursos incluem esses recursos em que a documentação do Developer for System z usa UACC, como o perfil ** na classe PROGRAM ou em que conta com convenções comuns do z/OS UNIX, como qualquer pessoa tendo permissão de leitura e execução para bibliotecas Java. Teste o acesso antes de ativá-lo em um sistema de produção.

Definir RSE como um servidor z/OS UNIX seguro

RSE requer acesso UPDATE ao perfil BPX.SERVER para criar ou excluir o ambiente de segurança para o encadeamento do cliente. Se esse perfil não estiver definido, UID(0) será necessário para o RSE. Essa etapa é necessária para que os clientes possam se conectar.

O Depurador Integrado requer acesso UPDATE ao perfil BPX.SERVER para criar ou excluir o ambiente de segurança para o encadeamento de depuração. Se este perfil não estiver definido, o UID(0) será necessário para o ID do usuário da tarefa iniciada de STCDBM. Esta permissão é necessária apenas quando o recurso Depurador Integrado opcional é usado.

Atenção: Definir o perfil BPX.SERVER torna o z/OS UNIX um comutador completo da segurança de nível UNIX para a segurança de nível z/OS UNIX, que é mais segura. Esse comutador pode afetar outros aplicativos e operações z/OS UNIX. Teste a segurança antes de ativá-la em um sistema de produção. Para obter mais informações sobre os diferentes níveis de segurança, consulte UNIX System Services Planning (GA22-7800).

Definir as Bibliotecas Controladas por Programa do MVS para RSE

Servidores com autoridade para BPX.SERVER devem executar em um ambiente limpo e controlado por programa. Este requisito implica que todos os programas chamados pelo RSE também devem ser controlados por programa. Para as bibliotecas de carregamento do MVS, o controle de programa é gerenciado pelo seu software de segurança. Essa etapa é necessária para que os clientes possam se conectar.

O RSE usa o tempo de execução do sistema (SYS1.LINKLIB), Language Environment’ (CEE.SCEERUN*) e a biblioteca de carregamento do ISPF’ TSO/ISPF Client Gateway (ISP.SISPLOAD).

Nota: Não utilize o perfil ** se já tiver um perfil * na classe PROGRAM. O perfil obscurece e complica o caminho da procura usado por seu software de segurança. Nesse caso, você deve mesclar as definições * existentes com a ** nova. Use o perfil **, conforme documentado em Security Server RACF Security Administrator's Guide (SA22-7683).

As bibliotecas de pré-requisito adicionais a seguir devem ser tornadas controladas por programa para suportar o uso de serviços opcionais. Esta lista não inclui conjuntos de dados que são específicos para um produto com o qual o Developer for System z interage, tal como o IBM File Manager.

Nota: As bibliotecas que são projetadas para colocação de LPA também requerem autorizações de controle de programa se forem acessadas por meio de LINKLIST ou STEPLIB. Esta publicação documenta o uso das seguintes bibliotecas LPA:
  • ISPF, para TSO/ISPF Client Gateway
    • ISP.SISPLPA
  • Biblioteca de tempo de execução REXX, para SCLM Developer Toolkit
    • REXX.*.SEAGLPA
  • Developer for System z, para CARMA
    • FEK.SFEKLPA

Definir Suporte de PassTicket para RSE

A senha do cliente ou outro meio de identificação, como o certificado X.509 é usada somente para verificar a identidade mediante a conexão. Depois disso, os PassTickets são usados para manter a segurança do encadeamento. Essa etapa é necessária para que os clientes possam se conectar.

Os PassTickets são senhas geradas pelo sistema com um tempo de vida de aproximadamente 10 minutos. Os PassTickets gerados são baseados em uma chave secreta. Esta chave é um número de 64 bits (16 caracteres hexadecimais). Nos comandos de amostra RACF a seguir, substitua o marcador key16 por uma sequência hexadecimal de 16 caracteres fornecida pelo usuário que tenha os caracteres de 0 a 9 e A a F.

O RSE suporta o uso de um ID do aplicativo que não FEKAPPL. Remova o comentário e customize a opção "APPLID=FEKAPPL" em rsed.envvars para ativar isso, conforme documentado em "Defining extra Java startup parameters with _RSE_JAVAOPTS" no IBM Rational Developer for System z Host Configuration Guide. As definições de classe PTKTDATA devem corresponder ao ID do aplicativo real usado pelo RSE.

Não é recomendável usar OMVSAPPL como ID do aplicativo porque ele abrirá a chave secreta para a maioria dos aplicativos do z/OS UNIX. Também não é recomendável usar o ID do aplicativo padrão MVS, que é seguido do MVS pelo ID SMF do sistema, pois isso abrirá a chave secreta para a maioria dos aplicativos MVS, incluindo tarefas em lote do usuário.

Nota:
  • Se a classe PTKTDATA já estiver definida, verifique se ela está definida como uma classe genérica antes de criar os perfis listados acima. O suporte para caracteres genéricos da classe PTKTDATA é novo desde o z/OS release 1.7, com a introdução de uma interface Java para PassTickets.
  • Substitua o curinga (*) da definição IRRPTAUTH.FEKAPPL.* por uma máscara de ID do usuário válida para limitar os IDs do usuário para os quais o RSE pode gerar um PassTicket.
  • Dependendo das configurações do RACF, o usuário que define um perfil também poderá estar na lista de acesso do perfil. Remova esta permissão para os perfis PTKTDATA.
  • O JES Job Monitor e o RSE devem ter o mesmo ID de aplicativo para permitir que o JES Job Monitor avalie os PassTickets apresentados pelo RSE. Para o JES Job Monitor, o ID do aplicativo é definido no arquivo de configuração FEJJCNFG com a diretiva APPLID.
  • Se o sistema tiver um produto criptográfico instalado e disponível, você poderá criptografar a chave de aplicativo de conexão protegida para proteção adicional. Para isso, use a palavra-chave KEYENCRYPTED em vez de KEYMASKED. Para obter mais informações, consulte Security Server RACF Security Administrator's Guide (SA22-7683).
Atenção: O pedido de conexão do cliente falhará se os PassTickets não estiverem configurados corretamente.

Definir a Proteção do Aplicativo para RSE

Durante o logon do cliente, o daemon RSE verifica se um usuário tem permissão para usar o aplicativo.

Nota:
  • Conforme descrito em mais detalhes em Definir Suporte de PassTicket para RSE, o RSE suporta o uso de um ID do aplicativo que não FEKAPPL. A definição de classe do APPL deve corresponder ao ID do aplicativo real usado pelo RSE.
  • A solicitação de conexão do cliente é bem-sucedida se o ID do aplicativo não estiver definido na classe APPL.
  • A solicitação de conexão do cliente falhará somente se o ID do aplicativo estiver definido e o usuário não tiver acesso de LEITURA ao perfil.

Definir a Segurança de Comando JES

O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário por meio de um console MCS estendido (EMCS), cujo nome é controlado com a diretiva CONSOLE_NAME, conforme documentado em "FEJJCNFG, Arquivo de Configuração do JES Job Monitor" no Guia de Configuração do Host do IBM Rational Developer for System z.

A amostra a seguir de comandos RACF dá aos usuários do Developer for System z a acesso condicional a um conjunto limitado de comandos JES, que são Manter, Liberar, Cancelar e Limpar. Os usuários só terão permissão de execução se emitirem os comandos por meio do JES Job Monitor. Substitua o marcador #console pelo nome real do console.

Nota:
  • O uso do console é permitido se nenhum perfil MVS.MCSOPER.#console for definido.
  • A classe CONSOLE deverá estar ativa para que WHEN(CONSOLE(JMON)) funcione, mas não há registro de entrada real de perfil na classe CONSOLE para consoles EMCS.
  • Não substitua JMON pelo nome real do console na cláusula WHEN(CONSOLE(JMON)). A palavra-chave JMON representa o aplicativo de ponto de entrada, não o nome do console.

Atenção: Definir os comandos JES com o acesso universal NONE no software de segurança pode afetar outros aplicativos e operações. Teste a segurança antes de ativá-la em um sistema de produção.

A Tabela 11 e a Tabela 12 mostram os comandos do operador emitidos para JES2 e JES3 e os perfis de segurança distintos que podem ser usados para protegê-los.

Tabela 11. Comandos do Operador do JES2 Job Monitor
Ações Comando Perfil OPERCMDS Acesso Necessário
Suspen
der
$Hx(jobid)

with x = {J, S or T}

jesname.MODIFYHOLD.BAT
jesname.MODIFYHOLD.STC
jesname.MODIFYHOLD.TSU
UPDATE
Liberar $Ax(jobid)

with x = {J, S or T}

jesname.MODIFYRELEASE.BAT
jesname.MODIFYRELEASE.STC
jesname.MODIFYRELEASE.TSU
UPDATE
Cancelar $Cx(jobid)

with x = {J, S or T}

jesname.CANCEL.BAT
jesname.CANCEL.STC
jesname.CANCEL.TSU
UPDATE
Limpar $Cx(jobid),P

with x = {J, S or T}

jesname.CANCEL.BAT
jesname.CANCEL.STC
jesname.CANCEL.TSU
UPDATE
Tabela 12. Comandos do Operador do JES3 Job Monitor
Ações Comando Perfil OPERCMDS Acesso Necessário
Suspen
der
*F,J=jobid,H
jesname.MODIFY.JOB
UPDATE
Liberar *F,J=jobid,R
jesname.MODIFY.JOB
UPDATE
Cancelar *F,J=jobid,C
jesname.MODIFY.JOB
UPDATE
Limpar *F,J=jobid,C
jesname.MODIFY.JOB
UPDATE
Nota:
  • Os comandos de operador JES Manter, Liberar, Cancelar e Limpar e o comando Mostrar JCL podem ser executados somente em arquivos de spool de propriedade do ID do usuário do cliente, a menos que LIMIT_COMMANDS= com valor LIMITED ou NOLIMIT esteja especificado no arquivo de configuração do JES Job Monitor. Para obter informações adicionais, consulte "Ações com relação a tarefas - limitações de destino" no Referência de Configuração do Host (S517-9857).
  • Os usuários podem procurar qualquer arquivo em spool, a menos que LIMIT_VIEW=USERID esteja definido no arquivo de configuração do JES Job Monitor. Para obter mais informações, consulte "Acesso a arquivos de spool" em Referência de Configuração do Host (S517-9857).
  • Mesmo se os usuários não estiverem autorizados para estes comandos do operador, eles ainda poderão enviar tarefas e ler saída de tarefa por meio do JES Job Monitor se tiverem autoridade suficiente a possíveis perfis que protegem esses recursos, como aqueles em classes JESINPUT, JESJOBS e JESSPOOL.

Supondo que a identidade do servidor JES Job Monitor, criando um console JMON a partir de uma sessão do TSO, seja impedida por seu software de segurança. Mesmo que o console possa ser criado, o ponto de entrada é diferente; por exemplo, JES Job Monitor versus TSO. Os comandos JES emitidos deste console falharão na verificação de segurança se sua segurança estiver configurada conforme documentado nesta publicação e o usuário não tiver autoridade aos comandos JES por outros meios.

Definir Perfis de Conjuntos de Dados

O acesso READ para usuários e ALTER para programadores de sistema é suficiente para a maioria dos conjuntos de dados do Developer for System z. Substitua o marcador #sysprog por IDs de usuário válidos ou nomes de grupos do RACF. Além disso, solicite ao programador de sistema que instalou e configurou o produto, os nomes de conjunto de dados corretos. FEK é o qualificador de alto nível padrão usado durante a instalação e FEK.#CUST é o qualificador de alto nível padrão para conjuntos de dados criados durante o processo de customização.

Nota:
  • Proteja FEK.SFEKAUTH contra atualizações, pois este conjunto de dados é autorizado pelo APF. O mesmo ocorre para FEK.SFEKLOAD e FEK.SFEKLPA que, nesse caso, esses conjuntos de dados são controlados pelo programa.
  • Os comandos de amostra nesta publicação e na tarefa FEKRACF supõem que a Enhanced Generic Naming (EGN) esteja ativa. Quando o EGN estiver ativo, o qualificador ** poderá ser usado para representar qualquer número de qualificadores na classe DATASET. Substitua ** por * se a EGN não estiver ativa em seu sistema. Para obter mais informações sobre EGN, consulte Security Server RACF Security Administrator's Guide (SA22-7683).

Alguns dos componentes opcionais do Developer for System z exigem perfis adicionais do conjunto de dados de segurança. Substitua os marcadores #sysprog, #ram-developer e #cicsadmin por um ID de usuário válido ou nomes de grupos RACF:

Use os comandos de amostra do RACF a seguir para obter uma configuração mais segura onde o acesso READ também é controlado.

Ao controlar o acesso READ para conjuntos de dados do sistema, você deve fornecer aos servidores Developer for System z e usuários a permissão READ para os seguintes conjuntos de dados:

Nota: Ao usar a Biblioteca Alternativa para o pacote do produto REXX, o nome da biblioteca padrão de tempo de execução do REXX será REXX.*.SEAGALT ao invés de REXX.*.SEAGLPA, conforme usado na amostra acima.

Definir os Arquivos Controlados por Programa do z/OS UNIX para RSE

Servidores com autoridade para BPX.SERVER devem executar em um ambiente limpo e controlado por programa. Este requisito implica que todos os programas chamados pelo RSE também devem ser controlados por programa. Para arquivos z/OS UNIX, o controle de programa é gerenciado pelo comando extattr. Para executar esse comando, você precisa de acesso READ para o BPX.FILEATTR.PROGCTL na classe FACILITY ou ser UID(0).

O servidor RSE usa a biblioteca compartilhada Java do RACF (/usr/lib/libIRRRacf*.so).

Nota:
  • Desde o z/OS 1.9, /usr/lib/libIRRRacf*.so é instalado no modo controle de programa durante a instalação do SMP/E RACF.
  • Desde o z/OS 1.10, /usr/lib/libIRRRacf*.so é parte do SAF, que é fornecido com z/OS base, portanto, está disponível também para clientes não RACF.
  • A configuração pode ser diferente se você utilizar um produto de segurança diferente do RACF. Para obter mais informações, consulte a documentação do produto de segurança.
  • A instalação de SMP/E do Developer for System z configura o bit de controle de programa para programas RSE internos.
  • Utilize o comando ls -Eog z/OS UNIX para exibir o status atual do bit de controle do programa. O arquivo é controlado por programa se a letra p for exibida na segunda sequência.
    $ ls -Eog /usr/lib/libIRRRacf*.so
    -rwxr-xr-x  aps-  2     69632 Oct  5  2007 /usr/lib/libIRRRacf.so
    -rwxr-xr-x  aps-  2     69632 Oct  5  2007 /usr/lib/libIRRRacf64.so                                 

Verifique as Configurações de Segurança

Use os seguintes comandos de amostra para exibir os resultados de suas customizações relacionadas à segurança.

Opcionalmente, perfis que direcionam o comportamento do Developer for System z para um usuário específico podem existir. Esses perfis correspondem o filtro FEK.** e são localizados por padrão na classe FACILITY. Consulte a diretiva _RSE_FEK_SAF_CLASS em rsed.envvars. É possível usar o comando SEARCH para listar os nomes de perfil. Use o comando RLIST para mostrar os detalhes para um perfil.

Capítulo 3. Considerações de TCP/IP

O Developer for System z usa TCP/IP para fornecer acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. Ele também usa TCP/IP para comunicação entre vários componentes e outros produtos.

Observe que a maioria das funções do Developer for System z são baseadas em z/OS UNIX e, assim, o TCP/IP usará a ordem de procura do z/OS UNIX para localizar seus arquivos de configuração. Consulte Capítulo 14. Configurando o TCP/IP para obter informações adicionais.

Os seguintes tópicos são abordados neste capítulo:

Portas TCP/IP

Figura 10. Portas TCP/IP
Portas TCP/IP

Figura 10 mostra as portas TCP/IP que podem ser usadas pelo Developer for System z. As setas mostram qual parte não liga (lado de ponta da seta) e qual se conecta.

Comunicação Externa

Defina as seguintes portas para seu firewall protegendo o host do z/OS, uma vez que são usadas para a comunicação de cliente-host (utilizando o protocolo tcp):

Nota: Normalmente, o cliente especifica qual endereço TCP/IP é usado para se conectar ao host. No entanto, para assegurar que as sessões de depuração se comuniquem com o host correto, o gerenciador de depuração indica ao cliente qual endereço TCP/IP deve ser usado.

Comunicação interna

Vários serviços do host Developer for System z são executados em encadeamentos ou espaços de endereço separados e utilizam soquetes TCP/IP como mecanismo de comunicação. Todos esses serviços usam o RSE para comunicação com o cliente, tornando seu fluxo de dados confinado apenas ao host. Para alguns serviços, será usada qualquer porta disponível, para outros, o programador de sistema poderá escolher a porta ou o intervalo de portas que será usado:

Reserva de Porta TCP/IP

Se usar a instrução PORT ou PORTRANGE em PROFILE.TCPIP para reservar as portas usadas pelo Developer for System z, observe que muitas ligações são feitas por encadeamentos ativos em um conjunto de encadeamentos RSE. O nome da tarefa do conjunto de encadeamentos do RSE é RSEDx, em que RSED é o nome da tarefa iniciada do RSE e x é um número aleatório de um dígito; assim, curingas são obrigatórios na definição.

PORT      4035     TCP RSED  ; Developer para System z - RSE daemon
PORT      6715     TCP JMON  ; Developer para System z - JES job monitor
PORT      5335     TCP DBGMGR ; Developer for System z - Integrated
 debugger
PORT      5336     TCP DBGMGR ; Developer for System z - Integrated
 debugger
PORTRange 8108 11  TCP RSED* ; Developer para System z - _RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer para System z - CARMA

portas do CARMA e TCP/IP

O CARMA (Common Access Repository Manager) é usado para acessar um host baseado em Software Configuration Manager (SCM), por exemplo, o CA Endevor® SCM. Na maioria dos casos, como no daemon RSE, um servidor se conecta a uma porta e atende a pedidos de conexão. O CARMA, no entanto, usa uma abordagem diferente, uma vez que o servidor CARMA não está ativo ainda quando o cliente inicia o pedido de conexão.

Quando o cliente envia uma solicitação de conexão, o minerador CARMA, que está ativo como um encadeamento de usuários em um conjunto de encadeamentos RSE, solicitará uma porta efêmera ou localizará uma porta livre no intervalo especificado no arquivo de configuração CRASRV.properties e ligará a ele. O extrator inicia então o servidor CARMA e transmite o número da porta, para que o servidor saiba a que porta se conectar. Quando o servidor estiver conectado, o cliente poderá enviar solicitações ao servidor e receber os resultados.

A partir de uma perspectiva TCP/IP, o RSE (por meio do minerador CARMA) é o servidor que liga a porta e o servidor CARMA é o cliente que se conecta a ela.

Se usar a instrução PORT ou PORTRANGE em PROFILE.TCPIP para reservar o intervalo de porta usado pelo CARMA, observe que o minerador CARMA está ativo em um conjunto de encadeamentos RSE. O nome da tarefa do conjunto de encadeamentos do RSE é RSEDx, em que RSED é o nome da tarefa iniciada RSE e x é um número aleatório de um dígito, assim são necessários caracteres curinga na definição.

PORTRange 5227 100 RSED*          ; Developer para System z - CARMA

Considerações de LDAP

O servidor RSE pode ser configurado para consultar um ou mais servidores LDAP para vários serviços do Developer for System z:

Observe que medidas de segurança de TCP/IP, como firewalls, podem fazer com que o servidor RSE (baseado em host) pare de entrar em contato com o servidor LDAP. Use as informações a seguir para assegurar que o servidor LDAP possa ser atingido:

Substituindo o Comportamento TCP/IP Padrão

ACK Atrasado

O ACK atrasado atrasa o reconhecimento (ACK) do recebimento de um pacote TCP em até 200 ms. Esse atraso aumenta a chance de que o ACK possa ser enviado com a resposta ao pacote recebido, reduzindo o tráfego de rede. Entretanto, se o remetente ficar aguardando o ACK antes de enviar um novo pacote (por exemplo, devido à implementação do algoritmo de Nagle) e não houver resposta ao pacote que acabou de ser enviado (por exemplo, porque ele faz parte de uma transferência de arquivo), a comunicação é atrasada desnecessariamente.

O Developer for System z permite que você desative a função de ACK atrasado. No host, isso é feito com a diretiva DSTORE_TCP_NO_DELAY em rsed.envvars, conforme documentado no Guia de Configuração do Host (S517-9094).

Multipilhas (CINET)

O z/OS Communication Server permite que você tenha diversas pilhas TCP/IP simultaneamente ativas em um único sistema. Isso é chamado configuração CINET.

Se Developer for System z não estiver ativo na pilha padrão, as funções selecionadas do Developer for System z podem falhar. A afinidade de pilha é um modo seguro para resolver isso. Ela instrui o Developer for System z a usar apenas determinada pilha TCP/IP (em vez de cada pilha TCP/IP disponível, que é o padrão para tarefas iniciadas).

A afinidade de pilha é configurada para as tarefas iniciadas de RSED removendo o comentário e customizando a diretiva _BPXK_SETIBMOPT_TRANSPORT no arquivo de configuração rsed.envvars. . Consulte a seção relacionada no "Capítulo 2 Customização Básica" do Guia de Configuração do Host (SC23-7658) para obter mais detalhes sobre como customizar este arquivo de configuração.

O CARMA e a Afinidade de Pilha

O CARMA (Common Access Repository Manager) é usado para acessar um host baseado em Software Configuration Manager (SCM), por exemplo, o CA Endevor® SCM. Para fazer isso, o CARMA inicia um servidor específico do usuário, que necessita de configuração adicional para impor a afinidade de pilha.

Semelhante às tarefas iniciadas do Developer for System z, a afinidade de pilha de um servidor CARMA é configurada com a variável _BPXK_SETIBMOPT_TRANSPORT, que deve ser passada para o LE (Language Environment). Isso pode ser feito ajustando o comando de inicialização no arquivo de configuração crastart*.conf ou CRASUB*.

Nota:
  • O nome exato do arquivo de configuração que contém o comando de inicialização depende das várias opções feitas pelo programador de sistemas que configurou o CARMA. Consulte o "Capítulo 3. (Opcional) Common Access Repository Manager (CARMA)" no Guia de Configuração do Host(S517-9094) para obter mais informações sobre isso.
  • _BPXK_SETIBMOPT_TRANSPORT especifica o nome da pilha TCP/IP a ser usada, como definido na instrução TCPIPJOBNAME no TCPIP.DATA relacionado.
  • Codificar uma instrução SYSTCPD DD não configura a afinidade de pilha solicitada.
  • Por padrão, o CARMA não usa as pilhas de TCP/IP normais. O CARMA usa o endereço de loopback para comunicação entre o minerador CARMA e o servidor CARMA. Isso melhora a segurança (apenas os processos locais possuem acesso ao endereço de loopback) e pode evitar a necessidade de incluir afinidade de pilha na comunicação do CARMA.

crastart*.conf

Substitua esta parte:

... PARM(&CRAPRM1. &CRAPRM2.)

por esta (em que TCPIP representa a pilha TCP/IP desejada):

... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
Nota: CRASTART não suporta continuações de linha, mas não há nenhum limite quanto ao comprimento de linha aceito.

CRASUB*

Substitua esta parte:

... PARM(&PORT &TIMEOUT)

por esta (em que TCPIP representa a pilha TCP/IP desejada):

... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
Nota: O envio da tarefa limita o comprimento de linha em 80 caracteres. É possível quebrar uma linha mais longa em um espaço em branco ( ) e usar um sinal de mais (+) no final da primeira linha para concatenar as 2 linhas.

Distributed Dynamic VIPA

O DVIPA (Dynamic Virtual IP Addressing) distribuído permite que você execute simultaneamente configurações Developer for System z idênticas em diferentes sistemas em seu sysplex e faça com que o TCP/IP, opcionalmente com a ajuda de WLM, distribua as conexões do cliente entre esses sistemas.

Há várias maneiras de se configurar um DVIPA distribuído, mas o Developer for System z impõe algumas restrições nessas opções.

Existem também algumas restrições no Developer for System z ao usar DVIPA distribuído:

JES Job Monitor, CARMA e outros servidores do Developer for System z somente interagem com o RSE local e, portanto, não requerem uma configuração DVIPA.

O Depurador Integrado interage com o RSE local e, portanto, não requer uma configuração de DVIPA. Para assegurar que as sessões de depuração se comuniquem com o host correto, o gerenciador de depuração informa ao cliente qual endereço TCP/IP deve ser usado e, dessa forma, não requer uma configuração de DVIPA.

Os DVIPAs distribuídos são definidos pelas palavras-chave VIPADEFine e VIPABackup do bloco VIPADynamic em seu perfil TCP/IP. A palavra-chave VIPADISTribute inclui as definições necessárias do Sysplex Distributor. O DVIPA distribuído requer que todas as pilhas participantes estejam de acordo com o sysplex, o que é feito por meio das palavras-chave SYSPLEXRouting e DYNAMICXCF do bloco IPCONFIG em seu perfil TCP/IP. Consulte Communications Server: IP Configuration Reference (SC31-8776) para obter detalhes adicionais sobre essas diretivas.

Consulte MVS Setting Up a Sysplex (SA22-7625) e Communication Server: SNA Network Implementation Guide (SC31-8777) para obter mais informações sobre a configuração da estrutura EZBEPORTS em seu recurso de acoplamento.

Restringindo a Seleção de Portas

O uso de SYSPLEXPORTS implica em que o TCP/IP irá selecionar uma porta efêmera para a conexão secundária. Uma porta efêmera é qualquer porta que esteja livre e não reservada de nenhuma forma. O uso de uma porta efêmera conflita com a melhor prática de firewall de limitar as portas que estão abertas para comunicação, porque não se sabe qual porta será usada.

É possível contornar esse problema forçando o Developer for System z a usar portas conhecidas para a conexão secundária definindo um _RSE_PORTRANGE exclusivo por sistema e assegurando que os intervalos de portas usados sejam reservados para uso do Developer for System z em todos os sistemas. Observe que essa solução requer o APAR de TCP/IP PM63379.

Para assegurar que o TCP/IP irá rotear a conexão secundária para o sistema correto, o Developer for System z deve usar um intervalo de portas exclusivo em cada sistema. Isso implica em que não é possível usar uma configuração idêntica compartilhada para os sistemas, pois _RSE_PORTRANGE em rsed.envvars deve ser exclusivo. Consulte Arquivos de Configuração Diferentes de Níveis de Software Idênticos em Capítulo 11. Executando várias instâncias para obter informações sobre como configurar diversos servidores com diferentes arquivos de configuração usando o mesmo código. Você deve usar uma cópia principal de rsed.envvars e um script para ajustar e copiar em uma configuração específica ao sistema para assegurar que o arquivo permaneça idêntico em diferentes sistemas.

  1. Configure Developer for System z em SYS1 como se fosse uma configuração de um único sistema, mas assegure-se de que /usr/lpp/rdz e /etc/rdz estejam localizados em um sistema de arquivos compartilhado. Todas as partes baseadas em MVS também devem ser compartilhas com SYS2.
  2. Use /etc/rdz/rsed.envvars como a cópia principal e inclua uma referência para /etc/rdz no final do arquivo, de modo que as cópias específicas dos sistemas possam apanhar os arquivos de configuração restantes.
    $ oedit /etc/rdz/rsed.envvars
       -> add the following at the END: 
         # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
         CFG_BASE=/etc/rdz
         CLASSPATH=.:$CFG_BASE:$CLASSPATH
         # --
  3. Crie /etc/rdz/update.sh, um shell script que irá copiar o rsed.envvars principal e ajustar _RSE_PORTRANGE
    $ oedit /etc/rdz/update.sh
    $ chmod 755 /etc/rdz/update.sh
    Figura 11. update.sh - Suportar Configuração de DDVIPA com um Firewall
    #! /bin/sh
    # Materiais Licenciados - Propriedade da IBM
    # 5724-T07 Copyright IBM Corp. 2012
    # clone rsed.envvars e configure PORTRANGE para uso com RDz & DDVIPA
    
    file=rsed.envvars            #; echo file $file
    sys=${1:-$(sysvar SYSNAME)}  #; echo sys $sys
    dir=$(dirname $0)            #; echo dir $dir
    # se sysname tiver um caractere especial, preceda-o com \ (ex. SYS\$1)
    case "$sys" in               # #### CUSTOMIZE ESTA SEÇÃO ####
      "SYS1") range=8108-8118;;
      "SYS2") range=8119-8129;;
    esac                         #; echo range $range
    echo "configurando o intervalo de portas $range para $sys usando $dir/$file"
    
    if test ! $range ; then
      echo ERROR: nenhum intervalo de portas definido para $sys ; exit 12 ; fi
    if test ! -e $dir/$file ; then
      echo ERROR: o arquivo $dir/$file não existe ; exit 12 ; fi
    if test ! -d $dir/$sys ; then
      echo ERROR: o diretório $dir/$sys não existe ; exit 12 ; fi
    
    mv $dir/$sys/$file $dir/$sys/prev.$file 2>/dev/null
    sed="/_RSE_PORTRANGE/s/.*/_RSE_PORTRANGE=$range/"
    sed "$sed" $dir/$file > $dir/$sys/$file
    
    if test ! -s $dir/$sys/$file ; then
      echo ERRO ao criar $dir/$sys/$file, restaurando o backup
      mv $dir/$sys/prev.$file $dir/$sys/$file ; exit 8 ; fi   
  4. Crie os diretórios /etc/rdz/SYS1 e /etc/rdz/SYS2 e execute /etc/rdz/update.sh para preencher os diretórios.
    $ mkdir /etc/rdz/SYS1 /etc/rdz/SYS2
    $ /etc/rdz/update.sh SYS1
    configurando o intervalo de portas 8108-8118 para SYS1 usando 
       /etc/rdz/rsed.envvars
    $ /etc/rdz/update.sh SYS2
    configurando o intervalo de portas 8119-8129 para SYS2 usando 
       /etc/rdz/rsed.envvars
  5. Assegure-se de que a tarefa iniciada RSED aponte para /etc/rdz/&SYSNAME.
    //     CNFG='/etc/rdz/&SYSNAME.'

Em seguida, você deve assegurar-se de que os intervalos de portas definidos sejam reservados para o Developer for System z em todos os sistemas no sysplex para garantir que o número da porta permaneça exclusivo dentro do sysplex. Use a instrução PORT ou PORTRANGE em PROFILE.TCPIP para reservar todos os intervalos em todos os sistemas. O nome da tarefa do conjunto de encadeamentos do RSE é RSEDx, em que RSED é o nome da tarefa iniciada do RSE e x é um número aleatório de um dígito; assim, curingas são obrigatórios na definição.

PORTRange 8108 22 RSED*          ; 8108-8129 - Developer para System z
                                 ; - conexão secundária

Conforme documentado em Fluxo de conexão, o intervalo de portas em _RSE_PORTRANGE pode ser pequeno. O servidor RSE não precisa da porta exclusivamente pela duração da conexão do cliente. Ela só é necessária no momento da expansão entre (servidor) a ligação e (cliente) a conexão que nenhum outro servidor RSE pode se conectar à porta. Isso significa que a maioria das conexões estará usando a primeira porta no intervalo, com o restante do intervalo sendo um buffer no caso de diversos logons simultâneos.

Configuração de Amostra

Na configuração de amostra a seguir existem dois sistemas z/OS, SYS1 e SYS2, que fazem parte de um sysplex. O System SYS1 é definido como o sistema que normalmente hospeda o Sysplex Distributor para o DVIPA distribuído Developer for System z.

Depois de definir o DVIPA distribuído, o Developer for System z pode ser iniciado nos sistemas para permitir as conexões do cliente do balanceamento de carga em todos os sistemas. O JES Job Monitor apenas interage com o RSE local e, portanto, não requer uma configuração DVIPA. Os clientes se conectarão à porta 4035 no endereço IP 10.10.10.1.

Figura 12. Amostra do Distributed Dynamic VIPA
Amostra do VIPA Dinâmico Distribuído

Sistema SYS1 - Perfil TCP/IP

IPCONFIG
  SYSPLEXRouting
; SYSPLEXROUTING é necessário, pois esta pilha precisa da comunicação sysplex
  DYNAMICXCF 9.9.9.1   255.255.255.0   1
; DYNAMICXCF define o dispositivo/link com o endereço home 9.9.9.1 conforme necessário
  IGNORERedirect

VIPADYNAMIC
  VIPADEFINE 255.255.255.0   10.10.10.1 
; VIPADEFINE define 10.10.10.1 como DVIPA principal no SYS1 para RDz
  VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE torna 10.10.10.1 um DVIPA distribuído, deve corresponder ao SYS2
    SYSPLEXPORTS                   ; RDz prereq
    DISTMETHOD BASEWLM             ; BASEWLM or ROUNDROBIN
    10.10.10.1                     ; endereço DVIPA usado por clientes RDz
    PORT 4035                      ; porta usada por clientes RDz 
    DESTIP 9.9.9.1   9.9.9.2       ; RDz ativo em SYS1 e SYS2
ENDVIPADYNAMIC

Sistema SYS2 - Perfil TCP/IP

IPCONFIG
  SYSPLEXRouting
; SYSPLEXROUTING é necessário, pois esta pilha precisa da comunicação sysplex
  DYNAMICXCF 9.9.9.2   255.255.255.0   1
; DYNAMICXCF define o dispositivo/link com o endereço home 9.9.9.2 conforme necessário
  IGNORERedirect

VIPADYNAMIC
  VIPABACKUP 255.255.255.0   10.10.10.1 
; VIPABACKUP define 10.10.10.1 como um DVIPA de backp em SYS2 para RDz
  VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE torna 10.10.10.1 um DVIPA distribuído, deve corresponder a SYS1
    SYSPLEXPORTS                   ; RDz prereq
    DISTMETHOD BASEWLM             ; BASEWLM or ROUNDROBIN
    10.10.10.1                     ; endereço DVIPA usado por clientes RDz
    PORT 4035                      ; porta usada por clientes RDz 
    DESTIP 9.9.9.1   9.9.9.2       ; RDz ativo em SYS1 e SYS2
ENDVIPADYNAMIC

Capítulo 4. Considerações WLM

Ao contrário dos aplicativos tradicionais do z/OS, o Developer for System z não é um aplicativo monolítico que pode ser identificado facilmente para Workload Manager (WLM). O Developer for System z consiste de vários componentes que interagem para fornecer ao cliente acesso para os serviços e dados do host. Como descrito em Capítulo 1. Entendendo o Developer for System z, alguns destes serviços estão ativos em espaços de endereços diferentes, resultando em classificações WLM diferentes.

Os seguintes tópicos são abordados neste capítulo:

Classificação de Carga de Trabalho

Figura 13. classificação WLM
Classificação WLM

O Figura 13 mostra uma visão geral básica dos subsistemas por meio dos quais as cargas de trabalho do Developer for System z são apresentadas ao WLM.

O Application Deployment Manager (ADM) está ativo dentro de uma região CICS e, portanto, seguirá as regras de classificação do CICS no WLM.

RSE daemon (RSED) e JES Job Monitor (JMON) são tarefas iniciadas do Developer for System z (ou tarefas em lote de longa execução), cada um com espaço de endereço individual.

Como documentado em RSE como um aplicativo Java, o daemon RSE gera um processo-filho para cada servidor de conjunto de encadeamentos RSE (que suporta um número variável de clientes). Cada conjunto de encadeamentos está ativo em um espaço de endereço separado (usando um iniciador z/OS UNIX, BPXAS). Porque estes são processos gerados, eles são classificados usando as regras de classificação WLM OMVS, e não as regras de classificação de tarefa iniciada.

Os clientes que estão ativos em um conjunto de encadeamentos podem criar uma infinidade de outros espaços de endereços, dependendo das ações realizadas pelos usuários. Dependendo da configuração de Developer for System z algumas cargas de trabalho, como o serviço TSO Commands (TSO cmd) ou CARMA, podem executar em subsistemas diferentes.

Os espaços de endereços listados em Figura 13 permanecem no sistema o tempo suficiente para serem visíveis, mas você deve estar ciente que devido à maneira como o z/OS UNIX é projetado, há também vários espaços de endereços temporários de curta duração. Estes espaços de endereços temporários estão ativos nos subsistemas OMVS.

Note que enquanto os conjuntos de encadeamento RSE usam o mesmo ID do usuário e um nome de tarefa similar como o daemon RSE, todos os espaços de endereços iniciados por um conjunto de encadeamento são de propriedade do ID do usuário do cliente solicitando a ação. O ID de usuário cliente também é usado como (parte de) o nome da tarefa para todos os espaços de endereço baseados em OMVS iniciados pelo conjunto de encadeamentos.

Mais espaços de endereços são criados por outros serviços que o Developer for System z usa, como o File Manager (FMNCAS) ou o z/OS UNIX REXEC (construção USS).

Regras de Classificação

O WLM usa regras de classificações para mapear o trabalho entrando no sistema para uma classe de serviço. Esta classificação é baseada nos qualificadores de trabalho. O primeiro qualificador (obrigatório) é um tipo de subsistema que recebe o pedido de trabalho. O Tabela 13 lista os tipos de subsistema que podem receber cargas de trabalho Developer for System z.

Tabela 13. Subsistemas de Ponto de Entrada do WLM
Tipos de subsistemas Descrição do trabalho
ASCH Os pedidos de trabalho incluem todos os programas de transação APPC planejados pelo planejador de transação da IBM-supplied APPC/MVS, ASCH.
CICS Os pedidos de trabalho incluem todas as transações processadas pelo CICS.
JES Os pedidos de trabalho incluem todos os trabalhos que o JES2 ou JES3 iniciam.
OMVS Os pedidos de trabalho incluem o trabalho processado nos espaços de endereços filhos bifurcados no z/OS UNIX System Services.
STC Os pedidos de trabalho incluem todo o trabalho iniciado pelos comandos START e MOUNT. O STC também inclui os espaços de endereços do componente do sistema.

A Tabela 14 lista qualificadores adicionais que podem ser usados para designar uma carga de trabalho a uma classe de serviço específica. Consulte MVS Planejamento: Gerenciamento de Carga de Trabalho (SA22-7602) para obter detalhes adicionais sobre os qualificadores de trabalho listados.

Tabela 14. qualificadores de trabalho WLM
ASCH CICS JES OMVS STC
AI Dados da Conta x x x x
LU Nome LU (*) x
PF Perform (*) x x
PRI Prioridade x
SE Nome de Ambiente de Planejamento x
SSC Nome de Coleta de Subsistema x
SI Instância de Subsistema (*) x x
SPM Parâmetro de Subsistema x
PX Nome Sysplex x x x x x
SY Nome do Sistema (*) x x x
TC Transação/Classe de Trabalho (*) x x
TN Transação/Nome do Trabalho (*) x x x x x
UI ID do usuário (*) x x x x x
Nota: Para os qualificadores marcados com (*), é possível especificar os grupos de classificação ao incluir um G na abreviação do tipo. Por exemplo, um grupo de nome de transação seria TNG.

Configurando Objetivos

Como documentado em Classificação de Carga de Trabalho, o Developer for System z cria tipos diferentes de cargas de trabalho no seu sistema. Estas diferentes tarefas comunicam-se entre si, o que implica que o tempo decorrido real tornar-se importante para evitar problemas de tempo limite para as conexões entre as tarefas. Como resultado, Developer for System z é recomendável que as tarefas sejam colocadas em classes de serviço de alto desempenho ou em classes de serviço de desempenho moderado com uma alta prioridade.

Uma revisão, e possivelmente uma atualização, dos seus objetivos WLM atuais é, por essa razão, aconselhado. Isto é especialmente verdadeiro para empresas tradicionais MVS novas no que diz respeito às cargas de trabalho OMVS de tempo crítico.

Nota:
  • As informações sobre os objetivos nesta seção são deliberadamente mantidas em um nível descritivo porque os objetivos de desempenho reais são muito específicos do site.
  • Para ajudar no entendimento do impacto de uma tarefa específica no seu sistema, termos como recursos substanciais, moderados e mínimos são usados. Todos eles são relativos ao uso total de recurso Developer for System z, ele mesmo, mas não de todo o sistema.

O Tabela 15 lista os espaços de endereços que são usados pelo Developer for System z. O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.

Tabela 15. cargas de trabalho WLM
Descrição Nome da tarefa Carga de trabalho
JES Job Monitor JMON STC
Daemon RSE RSED STC
Conjunto de encadeamento do RSE RSEDx OMVS
ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) <userid>x OMVS
Serviço do TSO Commands (APPC) FEKFRSRV ASCH
CARMA (batch) CRA<port> JES
CARMA (crastart) <userid>x OMVS
CARMA (ISPF Client Gateway) <userid> e <userid>x OMVS
Build MVS (tarefa em lote) * JES
Build z/OS UNIX (comandos do shell) <userid>x OMVS
Shell do z/OS UNIX <userid> OMVS
Tarefa do File Manager <userid>x OMVS
Gerenciador de Implementação de Aplicativo CICSTS CICS

Considerações para Seleção de Objetivos

As seguintes considerações gerais do WLM podem ajudar a definir apropriadamente as definições de objetivos corretas para Developer for System z:

Quando usar os objetivos de tempo de resposta:

Quando usar objetivos de velocidade:

STC

Todas as tarefas iniciadas do Developer for System z, daemons RSE e JES Job Monitor, estão atendendo solicitações de cliente em tempo real.

Tabela 16. cargas de trabalho WLM STC
Descrição Nome da tarefa Carga de trabalho
JES Job Monitor JMON STC
Daemon RSE RSED STC

OMVS

As cargas de trabalho OMVS podem ser divididas em dois grupos, conjuntos de encadeamentos RSE e todo o resto. Isto porque todas as cargas de trabalho, exceto os conjuntos de encadeamentos RSE, usam o ID de usuário cliente como base para o nome do espaço de endereço. (O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.

Tabela 17. Cargas de trabalho WLM OMVS
Descrição Nome da tarefa Carga de trabalho
Conjunto de encadeamento do RSE RSEDx OMVS
ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) <userid>x OMVS
CARMA (crastart) <userid>x OMVS
CARMA (ISPF Client Gateway) <userid> e <userid>x OMVS
Build z/OS UNIX (comandos do shell) <userid>x OMVS
Shell do z/OS UNIX <userid> OMVS
Tarefa do File Manager <userid>x OMVS

Todas as cargas de trabalho restantes terminarão na mesma classe de serviço devido a uma convenção de nomenclatura do espaço de endereço comum. É recomendável especificar um objetivo de período múltiplo para esta classe de serviço. Os primeiros períodos deveriam ser de objetivos de tempo de resposta percentil e de alto desempenho, enquanto que o último período deveria possuir um objetivo de velocidade de desempenho moderado. Algumas cargas de trabalho, como a ISPF Client Gateway, relatarão transações individuais para o WLM, enquanto outras não.

JES

Os processos em lote do JES gerenciado são usados de várias maneiras pelo Developer for System z. O uso mais comum é para construções MVS, onde uma tarefa é submetida e monitorada para determinar quando ela termina. Mas o Developer for System z também poderia iniciar um servidor CARMA em lote e comunicar-se com ele usando TCP/IP.

Tabela 18. Carga de trabalhos WLM JES
Descrição Nome da tarefa Carga de trabalho
CARMA (batch) CRA<port> JES
Build MVS (tarefa em lote) * JES

ASCH

Nas versões atuais do Developer for System z, o ISPF Client Gateway é usado para executar comandos TSO e ISPF não interativos. Devido a razões históricas, o Developer for System z também suporta executar estes comandos por meio de uma transação APPC. Você deve observar que o método APPC é reprovado.

Tabela 19. Cargas de trabalho WLM ASCH
Descrição Nome da tarefa Carga de trabalho
Serviço do TSO Commands (APPC) FEKFRSRV ASCH

CICS

O Application Deployment Manager é um servidor Developer for System z opcional que está ativo dentro de uma região do CICS Transaction Server.

Tabela 20. Cargas de trabalho WLM - CICS
Descrição Nome da tarefa Carga de trabalho
Gerenciador de Implementação de Aplicativo CICSTS CICS

O WLM suporta vários tipos de gerenciamento que você pode usar para CICS:

Capítulo 5. Considerações de Ajuste

Conforme explicado em Capítulo 1. Entendendo o Developer for System z, o RSE (Explorador de Sistema Remoto) é o núcleo do Developer for System z. Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon age como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamentos processam as cargas de trabalho do cliente.

Isso torna o RSE um alvo principal para o ajuste da configuração do Developer for System z. Entretanto, manter centenas de usuários, cada um usando 17 ou mais encadeamentos, uma certa quantia de armazenamento, e possivelmente 1 ou mais espaços de endereços requer uma configuração adequada de ambos Developer for System z e z/OS.

Os seguintes tópicos são abordados neste capítulo:

Uso de Recursos

Use as informações nesta seção para estimar o uso normal e máximo de recursos pelo Developer for System z, para que possa planejar sua configuração do sistema de acordo.

Ao usar os números e as fórmula apresentados nesta seção para definir os valores dos limites do sistema, lembre-se de que você está trabalhando com estimativas bastante precisas. Deixe margem suficiente ao configurar os limites do sistema para permitir o uso de recursos por tarefas temporárias e outras tarefas, ou por usuários que se conectam várias vezes ao host simultaneamente. (Por exemplo, por meio de RSE e de TN3270).

Nota:
  • As informações são limitadas ao escopo para serviços acessados por meio do RSE que são fornecidas pelo próprio Developer for System z. Por exemplo, o uso de recurso do TN3270 não é documentado (não acessado por meio do RSE), nem o uso de recursos dos programas chamados durante construções remotas (baseadas em host) dos projetos MVS ou z/OS UNIX (não fornecido pelo Developer for System z).
  • Incluir extensões de terceiros no Developer for System z pode aumentar os contadores de uso de recurso.
  • Todos os serviços têm tarefas de "manutenção" de curta duração, que usam recursos durante sua execução, e que podem ser executados em sequência ou em paralelo entre si. Os recursos usados por essas tarefas não são documentados.
  • Onde for útil, o uso de recursos específicos do usuário de software obrigatório, como o ISPF Client Gateway, é documentado.
  • Os números apresentados aqui podem ser alterados sem notificação prévia.

Visão Geral (Overview)

As tabelas a seguir dão uma visão geral do número de espaços de endereços, processos e encadeamentos usados pelo Developer for System z. Mais detalhes sobre os números apresentados aqui podem ser localizados nas seções de texto:

Tabela 21 dá uma visão geral dos principais recursos usados pelas tarefas iniciadas do Developer for System z. Esses recursos são alocados apenas uma vez. Eles são compartilhados entre clientes do Developer for System z.

Tabela 21. Uso de recursos comuns
Tarefa iniciada Espaços de endereço Processos Encadeamentos
JMON 1 1 3
RSED 1 3 11
RSEDx 1 + 1 (a) 1 + 2 1 + 10

Nota: (a) Existe pelo menos um espaço de endereço autorizado pelo APF e pelo menos 1 espaço de endereço do conjunto de encadeamento do RSE ativo. Consulte Contagem do espaço de endereço para determinar o número real de espaços de endereços do conjunto de encadeamento do RSE.

A Tabela 22 fornece uma visão geral dos recursos principais usados pelo software obrigatório. Esses recursos são alocados para cada cliente do Developer for System z que chama a função relacionada.

Tabela 22. Uso de recursos obrigatórios específicos do usuário
Software obrigatório Espaços de endereço Processos Encadeamentos
ISPF Client Gateway 1 2 4
APPC 1 1 2

Tabela 23 dá uma visão geral dos principais recursos por cada cliente do Developer for System z ao executar a função especificada. Valores não-numéricos, como ISPF, são uma referência ao valor correspondente na Tabela 22.

Tabela 23. Uso de recursos específicos do usuário
Ação do usuário

Espaços de endereço
ID do
usuário
Processos
ID do
usuário
                Encadeamentos

ID do usuário   RSEDx     JMON
Logon - - - 17 1
Cronômetro para tempo limite inativo - - - 1 -
Procurar - - - 1 -
Expandir PDS(E) ISPF ISPF ISPF - -
Abrir conjunto de dados ISPF ISPF ISPF 1 -
Comando TSO ISPF ISPF ISPF - -
Shell do z/OS UNIX 1 1 1 6 -
Build MVS 1 - - - -
Build z/OS UNIX 3 3 3 - -
CARMA (batch) 1 1 2 1 -
CARMA (crastart) 1 1 2 4 -
CARMA (ispf) 4 4 7 5 -
SCLMDT ISPF ISPF ISPF - -

Nota: O ISPF pode ser substituído pelo APPC, exceto para o SCLM Developer Toolkit.

Contagem do espaço de endereço

Tabela 24 lista os espaços de endereços que são usados pelo Developer for System z, em que "u" na coluna "Count" indica que a quantia deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função. O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.

Tabela 24. Contagem do espaço de endereço
Contador Descrição Nome da tarefa Comparti
lhado
Termina após
1 JES Job Monitor JMON Sim Nunca
1 Daemon RSE RSED Sim Nunca
1 RSE APF autorizado RSEDx Sim Nunca
(a) Conjunto de encadeamento do RSE RSEDx Sim Nunca
lu ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) <userid>x Não 15 minutos ou no logoff do usuário
lu Serviço do TSO Commands (APPC) FEKFRSRV Não 60 minutos ou efetuar logoff do usuário
lu CARMA (batch) CRA<port> Não 7 minutos ou no logoff do usuário
lu CARMA (crastart) <userid>x Não 7 minutos ou no logoff do usuário
4u CARMA (ispf, descontinuado) (1)<userid> ou (3)<userid>x Não 7 minutos ou no logoff do usuário
(b) Uso simultâneo do ISPF Client Gateway por 1 usuário <userid>x Não Conclusão da tarefa
1u Build MVS (tarefa em lote) * Não Conclusão da tarefa
3u Build z/OS UNIX (comandos do shell) <userid>x Não Conclusão da tarefa
1u Shell do z/OS UNIX <userid> Não Logoff do usuário

Nota:
  • (a) Existe pelo menos um espaço de endereço do conjunto de encadeamento do RSE ativo. O número real depende de:
    • A diretiva minimum.threadpool.process em rsed.envvars. O valor-padrão é 1.
    • O número de usuários que podem ser atendidos por um conjunto de encadeamento. As configurações padrão são planejadas para 30 usuários por conjunto de encadeamentos.
    Nota: Se a diretiva single.logon estiver ativa, haverá pelo menos 2 conjuntos de encadeamento iniciados, mesmo que minimum.threadpool.process esteja configurado como 1. A configuração padrão para single.logon em rsed.envvars está ativa.
  • (b) Developer for System z tem diversos encadeamentos ativos por usuário. No caso de o espaço de endereço do ISPF Client Gateway não tiver terminado de atender aos pedido de um encadeamento quando outro encadeamento enviar um pedido, o ISPF inicializará um novo Client Gateway para processar o novo pedido. Esse espaço de endereço termina após a conclusão da tarefa.
  • O SCLMDT exige um espaço de endereço do ISPF Client Gateway. O SCLMDT compartilha o espaço de endereço com o serviço do TSO Commands.
  • A maioria das ações relacionadas ao conjunto de dados do MVS usa o serviço do TSO Commands, que pode estar ativo no ISPF Client Gateway ou em uma transação do APPC, respectivamente.

Use a fórmula em Figura 14 para estimar o número máximo de espaços de endereços usados pelo Developer for System z.

Figura 14. Número máximo de espaços de endereço
Número máximo de espaços de endereço

Em que,

Use a fórmula em Figura 15 para estimar o número máximo de espaços de endereços usados por um cliente Developer for System z (não contando os espaços de endereços temporários não documentados).

Figura 15. Número de espaços de endereços por cliente
Número de espaços de endereço por cliente

Em que,

As definições na Tabela 25 podem limitar o número real de espaços de endereço.

Tabela 25. Limites de espaço de endereço
Local Limite Recursos afetados
rsed.envvars maximum.threadpool.process Limita o número de conjuntos de encadeamento do RSE
IEASYMxx MAXUSER Limita o número de espaços de endereço
ASCHPMxx MAX Limita o número de iniciadores APPC para o serviço TSO Commands (APPC)

Contagem de processos

Tabela 26 lista o número de processos por espaço de endereço que é usado pelo Developer for System z. "u" na coluna "Address Spaces" indica que a quantia deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função.

Tabela 26. Contagem de processos
Processos Espaços de endereço Descrição ID do usuário
1 1 JES Job Monitor STCJMON
3 1 Daemon RSE STCRSE
1 1 Autorizado pelo APF RSE STCRSE
2 (a) Conjunto de encadeamento do RSE STCRSE
2 (b) ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) <userid>
1 1u Serviço do TSO Commands (APPC) <userid>
1 1u CARMA (batch) <userid>
1 1u CARMA (crastart) <userid>
1 1u CARMA (ispf, descontinuado) <userid>
1 3u Build z/OS UNIX (comandos do shell) <userid>
1 1u Shell do z/OS UNIX <userid>
(5) (u) SCLM Developer Toolkit <userid>

Nota:
  • (a) Existe pelo menos 1 espaço de endereço do conjunto de encadeamento do RSE ativo. Consulte Contagem do espaço de endereço para determinar o número real de espaços de endereços do conjunto de encadeamento do RSE.
  • O daemon RSE e todos os conjuntos de encadeamento do RSE usam o mesmo ID de usuário.
  • (b) Em situações normais e ao usar as opções de configuração padrão, existe 1 ISPF Client Gateway ativo por usuário. O número real pode variar, conforme descrito em Contagem do espaço de endereço.
  • O SCLMDT exige um espaço de endereço do ISPF Client Gateway. O SCLMDT compartilha o espaço de endereço com o serviço do TSO Commands.
  • (u) Os processos SCLMDT são executados no espaço de endereço do ISPF Client Gateway e, portanto, não possuem um valor para a contagem do espaço de endereço.
  • Os processos SCLMDT são temporários e terminam na conclusão da tarefa, mas vários processos podem estar ativos simultaneamente para um único usuário. A Tabela 26 lista o número máximo de processos SCLMDT simultâneos.
  • A maioria das ações relacionadas ao conjunto de dados do MVS usa o serviço do TSO Commands, que pode estar ativo no ISPF Client Gateway ou em uma transação do APPC, respectivamente.
  • Um build z/OS UNIX usa três processos no total, cada um executando em seu próprio espaço de endereço.
  • Todos os processos listados permanecem ativos até que o espaço de endereço relacionado termine, a menos que indicado de outra forma.

Use a fórmula em Figura 16 para estimar o número máximo de processos usados pelo Developer for System z.

Figura 16. Número máximo de processos
Número máximo de processos

Em que,

Use a fórmula em Figura 17 para estimar o número máximo de processos usados pelo STCRSE, o RSED iniciou o ID do usuário da tarefa (não contando os processos temporários não documentados).

Figura 17. Número de processos para STCRSE
Número de processos para STCRSE

Em que,

Use a fórmula em Figura 18 para estimar o número máximo de processos usados por um cliente Developer for System z (não contando os processos temporários não documentados).

Figura 18. Número de processos por cliente
Número de processos por cliente

Em que,

As definições na Tabela 27 podem limitar o número real de processos.

Tabela 27. Limites do processo
Local Limite Recursos afetados
BPXPRMxx MAXPROCSYS Limita o número total de processos
BPXPRMxx MAXPROCUSER Limita o número de processos por UID do z/OS UNIX

Nota:

Contagem de encadeamentos

Tabela 28 lista o número de encadeamentos usados pelas funções selecionadas do Developer for System z. "u" nas colunas "Encadeamentos" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função. A contagem de encadeamento é listada por processo, à medida que os limites são definidos neste nível.

Tabela 28. Contagem de encadeamentos
              Encadeamentos
ID do usuário Descrição
RSEDx Ativado Autoinicialização
- 3 + 1u - STCJMON JES Job Monitor
- 15 2 STCRSE Daemon RSE
- 1 - STCRSE RSE APF autorizado
10 (a) + 17u - 1 (a) STCRSE Conjunto de encadeamento do RSE
- 4u (b) 1u (b) <userid> ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT)
- 2u - <userid> Serviço do TSO Commands (APPC)
1u 2u - STCRSE e <userid> CARMA (batch)
4u 2u - STCRSE e <userid> CARMA (crastart)
5u 4u 3u STCRSE e <userid> CARMA (ispf, descontinuado)
- 1u (c) 2u <userid> Build z/OS UNIX (comandos do shell)
6u 1u - STCRSE e <userid> Shell do z/OS UNIX
1 (d) - - STCRSE Fazer Download
1 (e) - - STCRSE Procurar
- (5) - <userid> SCLM Developer Toolkit
1u - - STCRSE Cronômetro para tempo limite inativo

Nota:
  • (a) Existe pelo menos 1 espaço de endereço do conjunto de encadeamento do RSE ativo. Consulte Contagem do espaço de endereço para determinar o número real de espaços de endereços do conjunto de encadeamento do RSE.
  • (b) Em situações normais e ao usar as opções de configuração padrão, existe 1 ISPF Client Gateway ativo por usuário. O número real pode variar, conforme descrito em Contagem do espaço de endereço.
  • O SCLMDT exige um espaço de endereço do ISPF Client Gateway. O SCLMDT compartilha o espaço de endereço com o serviço do TSO Commands.
  • Dependendo da ação selecionada, o SCLMDT pode usar vários processos de encadeamento único que terminam na conclusão da tarefa. A Tabela 28 lista o número máximo de encadeamentos SCLMDT simultâneos.
  • A maioria das ações relacionadas ao conjunto de dados do MVS usa o serviço do TSO Commands, que pode estar ativo no ISPF Client Gateway ou em uma transação do APPC, respectivamente.
  • (c) Um build z/OS UNIX invoca utilitários de build diferentes, que podem ser multiencadeados. A Tabela 28 lista o número mínimo de encadeamentos de build z/OS UNIX simultâneos.
  • (d) Cada download de dados de host usará um encadeamento separado. Este encadeamento será encerrado quando os dados forem transferidos ao cliente.
  • (e) Cada procura remota usará um encadeamento separado. Este encadeamento será encerrado quando os resultados forem transferidos ao cliente.
  • Todos os encadeamentos listados permanecem ativos até que o processo relacionado termine, a menos que indicado de outra forma.
  • A contagem normal de encadeamentos para o código autorizado pelo APF RSE é 1. Entretanto, durante a inicialização, há 13 ou mais encadeamentos ativos simultâneos temporariamente.

Use a fórmula em Figura 19 para estimar o número máximo de encadeamentos usados por um conjunto de encadeamentos RSE. Use a fórmula da Figura 20 para avaliar o número máximo de encadeamentos usados pelo JES Job Monitor.

Figura 19. Número máximo de encadeamentos do conjunto de encadeamento do RSE
Número máximo de encadeamentos do conjunto de encadeamentos RSE

Figura 20. Número máximo de encadeamentos do JES Job Monitor
Número máximo de encadeamentos do JES Job Monitor

Em que,

As definições na Tabela 29 podem limitar o número real de encadeamentos em um processo, o que é da maior importância para os conjuntos de encadeamentos do RSE.

Tabela 29. Limites de encadeamento
Local Limite Recursos afetados
BPXPRMxx MAXTHREADS Limita o número de encadeamentos em um processo.
BPXPRMxx MAXTHREADTASKS Limita o número de tarefas MVS em um processo.
BPXPRMxx MAXASSIZE Limita o tamanho de espaço de endereço e, portanto, o armazenamento disponível para blocos de controle relacionados a encadeamento.
rsed.envvars Xmx Define o tamanho máximo do heap Java. Este armazenamento é reservado e, portanto, não está mais disponível para blocos de controle relacionados a encadeamento.
rsed.envvars maximum.clients Limita o número de clientes (e, portanto, seus encadeamentos) em um conjunto de encadeamento do RSE.
rsed.envvars maximum.threads Limita o número de encadeamentos de cliente em um conjunto de encadeamentos RSE.
FEJJCNFG MAX_THREADS Limita o número de encadeamentos no JES Job Monitor.

Nota:
  • O valor para maximum.threads em rsed.envvars deve ser inferior ao valor para MAXTHREADS e MAXTHREADTASKS em BPXPRMxx.
  • O comando operador DISPLAY PROCESS,CPU, que mostra os encadeamentos ativos em um conjunto de encadeamentos, está limitado a mostrar apenas os primeiros 4.000 encadeamentos.

Uso temporário de recursos

O uso de recurso documentado nas seções anteriores é permanente para o tempo de vida do Developer for System z ou semipermanente para certas tarefas específicas do usuário.

Entretanto, o Developer for System z usará temporariamente os recursos adicionais para tarefas de manutenção e atender às solicitações a seguir:

Uso de Armazenamento

RSE é um aplicativo Java, que implica que o planejamento de uso de armazenamento (memória) para Developer for System z deve levar dois limites de alocação de armazenamento em consideração, tamanho de heap Java e tamanho de Espaço de Endereço.

Limite de Tamanho de Heap Java

Java oferece vários serviços para facilitar os esforços de codificação para aplicativos Java. Um desses serviços é o gerenciamento de armazenamento.

O gerenciamento de armazenamento Java aloca grandes blocos de armazenamento e os usa para pedidos de armazenamento pelo aplicativo. Esse armazenamento gerenciado por Java é chamado de heap Java. A coleta de lixo periódica (desfragmentação) reclama o espaço não utilizado no heap e reduz o seu tamanho. Note que, para salvar ciclos de CPU, a coleta de lixo tende a aguardar até que o armazenamento ocupado seja realmente necessário, deixando, assim, o armazenamento que não é mais usado alocado (e se tornando paginado) por um período maior de tempo do que o absolutamente necessário.

O tamanho de heap máximo Java é definido em rsed.envvars com a diretiva Xmx. Se esta diretiva não for especificada, o Java usará um tamanho padrão de 512 MB. Você deve especificar um valor de 256 MB ou mais alto. Ao executar em modo de 64 bits, o Java tentará alocar o heap acima de 2 GB de barramento, liberando espaço abaixo do barramento.

Cada conjunto de armazenamento do RSE (que atende às ações do cliente) é um aplicativo Java separado e, portanto, tem um heap Java pessoal. Observe que todos os conjuntos de encadeamento usam o mesmo arquivo de configuração rsed.envvars e, portanto, têm o mesmo limite de tamanho de heap Java.

O uso do conjunto de encadeamento do heap Java depende muito das ações executadas pelos clientes conectados. O monitoramento regular do uso de heap é necessário para definir o limite de tamanho de heap ideal. Use o comando do operador modificar processo de exibição para monitorar o uso de heap Java por conjuntos de encadeamento do RSE.

Limite de Tamanho do Espaço de Endereço

Todos os aplicativos z/OS, incluindo aplicativos Java, estão ative dentro de um espaço de endereço, e estão, portanto, ligados pelas limitações de tamanho do espaço de endereço.

O tamanho do espaço de endereço desejado é especificado durante a inicialização, por exemplo, com o parâmetro REGION em JCL. Entretanto, as configurações do sistema podem limitar o tamanho do espaço de endereço real. Consulte Tamanho do espaço de endereço para saber mais sobre esses limites.

Os conjuntos de encadeamento do RSE herdam os limites de tamanho do espaço de endereço do daemon RSE. O tamanho do espaço de endereço deve ser suficiente para abrigar o heap Java, o próprio Java, as áreas de armazenamento comuns e todos os blocos de controle que o sistema cria para suportar a atividade do conjunto de encadeamento, como um TCB (Bloco de Controle de Tarefa) por encadeamento. Observe que algum desse uso de armazenamento está abaixo da linha de 16 MB. Ao executar em modo de 64 bits, o Java tentará alocar o heap acima de 2 GB de barramento, liberando espaço abaixo do barramento.

Você deve monitorar o tamanho do espaço de endereço real antes de alterar quaisquer configurações que o influenciem, como alterar o tamanho do heap Java ou a quantidade de usuários suportada por um único conjunto de encadeamento. Use o software de monitoramento regular do sistema para controlar o uso de armazenamento real pelo Developer for system z. Se você não tiver uma ferramenta de monitoramento dedicada, então informações básicas podem ser reunidas com ferramentas como a visualização SDSF DA ou TASID (uma ferramenta de informações do sistema como elas estão armazenadas no banco de dados disponível por meio da página da Web "Support and downloads" do ISPF).

Diretrizes de Estimativa de Tamanho

Conforme mencionado antes, o uso de armazenamento real pelo Developer para System z é altamente influenciado pela atividade do usuário. Algumas ações usam uma quantidade fixa de armazenamento (por exemplo, logon), enquanto outras são variáveis (por exemplo, listando conjuntos de dados com um qualificador de alto nível especificado).

Observe que o RSE exibe o heap Java atual e o limite de tamanho de espaço de endereço durante a inicialização na mensagem do console FEK004I.

Use um dos seguintes cenários se o monitoramento mostrar que o tamanho de heap Java atual é insuficiente para a carga de trabalho real:

Como referência, oTabela 30 mostra valores usados por clientes reais do Developer for System z para configurações de chave rsed.envvars que têm impacto no uso de armazenamento.

Tabela 30. Configurações de Referência para Uso de Armazenamento
xmx (heap java máximo) maximum.clients Tipo de desenvolvimento primário
512M 30 PL/I
512M 10 COBOL
384M 12 COBOL
800M (64 bits) 20 Não especificado

Análise do Uso de Armazenamento de Amostra

As exibições nas figuras a seguir mostram alguns números de uso de recurso de amostra para uma configuração padrão do Developer for System z com essas modificações.

Figura 21. Uso de recursos com 5 logons
Tamanho Máx Heap=10 MB e privado AS Tamanho=1,959 MB

inicialização

 BPXM023I (STCRSE)
 ID do Processo(268     ) Uso de Memória(7%) Clientes(0)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,01      2740           72
 RSED              4,47     32,8 M        15910
 RSED8             1,15     27,4 M        12612

logon 1

 BPXM023I (STCRSE)
 ID do Processo(268     ) Uso de Memória(13%) Clientes(1)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,01      2864           81
 RSED              4,55     32,8 M        15980
 RSED8             3,72     55,9 M        24128

logon 2

 BPXM023I (STCRSE)
 ID do Processo(268     ) Uso de Memória(23%) Clientes(2)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
--------   -----------    -------  ----------
 JMON              0,02      2944           86
 RSED              4,58     32,9 M        16027
 RSED8             4,20     57,8 M        25205

logon 3

 BPXM023I (STCRSE)
 ID do Processo(268     ) Uso de Memória(37%) Clientes(3)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,02      3020           91
 RSED              4,60     32,9 M        16076
 RSED8             4,51     59,6 M        26327

logon 4

 BPXM023I (STCRSE)
 ID do Processo(268     ) Uso de Memória(41%) Clientes(4)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,02      3108           96
 RSED              4,61     32,9 M        16125
 RSED8             4,77     62,3 M        27404
Figura 22. Uso de recursos com 5 logons (continuação)
logon 5

 BPXM023I (STCRSE)
 ID do Processo(268     ) Uso de Memória(41%) Clientes(4)
 ID do Processo(33554706) Uso de Memória(13%) Clientes(1)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,03      3184          101
 RSED              4,64     32,9 M        16229
 RSED8             4,78     62,4 M        27413
 RSED9             4,60     56,6 M        24065

A Figura 21 e a Figura 22 mostram um cenário em que 5 clientes efetuam logon em um daemon RSE com um heap Java de 10 MB.

Figura 23. Uso de recursos ao editar um membro PDS
Tamanho Máx Heap=10 MB e privado AS Tamanho=1,959 MB

inicialização

 BPXM023I (STCRSE)
 ID do Processo(212     ) Uso de Memória(7%) Clientes(0)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,01      2736           71
 RSED              4,35     32,9 M        15117
 RSED8             1,43     27,4 M        12609

logon

 BPXM023I (STCRSE)
 ID do Processo(212     ) Uso de Memória(13%) Clientes(1)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,01      2864           80
 RSED              4,48     33,0 M        15187
 RSED8             3,53     53,9 M        24125

expandir árvore MVS grande (195 conjuntos de dados)
 BPXM023I (STCRSE)
 ID do Processo(212     ) Uso de Memória(13%) Clientes(1)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              0,01      2864           80
 RSED              4,58     33,1 M        16094
 RSED8             4,28     56,1 M        24740

expandir PDS pequeno (21 membros)
 BPXM023I (STCRSE)
 ID do Processo(212     ) Uso de Memória(13%) Clientes(1)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 IBMUSER2          0,22      2644          870
 JMON              0,01      2864           80
 RSED              4,61     33,1 M        16108
 RSED8             4,40     56,2 M        24937

abrir membro de tamanho médio (86 linhas)

 BPXM023I (STCRSE)
 ID do Processo(212     ) Uso de Memória(13%) Clientes(1)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 IBMUSER2          0,22      2644          870
 JMON              0,01      2864           80
 RSED              4,61     33,1 M        16108
 RSED8             8,12     62,7 M        27044

A Figura 23 mostra um cenário em que 1 cliente efetua logon em um daemon RSE com um heap Java de 10 MB e edita um membro PDS.

Uso do espaço do sistema de arquivos z/OS UNIX

A maioria dos dados relacionados ao Developer for System z que não estão gravados em uma instrução DD terminam em um arquivo z/OS UNIX. O programador de sistema tem controle sobre os dados que são gravados e para onde eles vão. Entretanto, não há controle sobre a quantidade de dados gravada.

Os dados podem ser agrupados nas seguintes categorias:

Conforme documentado em Capítulo 12. Resolução de problemas de configuração, o Developer for System z grava os logs de host relacionados a RSE nos seguintes diretórios z/OS UNIX:

Por padrão, apenas as mensagens de erro e de aviso são gravadas nos logs. Portanto, se tudo correr conforme o planejado, esses diretórios devem manter apenas os arquivos vazios ou quase vazios(sem contar os logs de auditoria).

Você pode ativar a criação de log de mensagens informativas, preferivelmente na direção do centro de suporte IBM, o que aumenta perceptivelmente o tamanho dos arquivos de log.

Figura 24. Uso do espaço do sistema de arquivos z/OS UNIX
inicialização

$ ls -l /var/rdz/logs
total 144
-rw-rw-rw-   1 STCRSE   STCGRP     33642 Jul 10 12:10 rsedaemon.log
-rw-rw-rw-   1 STCRSE   STCGRP      1442 Jul 10 12:10 rseserver.log

logon

$ ls -l /var/rdz/logs
total 144
drwxrwxrwx   3 IBMUSER  SYS1        8192 Jul 10 12:11 IBMUSER
-rw-rw-rw-   1 STCRSE   STCGRP     36655 Jul 10 12:11 rsedaemon.log
-rw-rw-rw-   1 STCRSE   STCGRP      1893 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 160
-rw-rw-rw-   1 IBMUSER  SYS1        3459 Jul 10 12:11 ffs.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 ffsget.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 ffsput.log
-rw-rw-rw-   1 IBMUSER  SYS1         303 Jul 10 12:11 lock.log
-rw-rw-rw-   1 IBMUSER  SYS1         126 Jul 10 12:11 rmt_classloader_cache.jar
-rw-rw-rw-   1 IBMUSER  SYS1        7266 Jul 10 12:11 rsecomm.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 stderr.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 stdout.log

logoff
$ ls -l /var/rdz/logs
total 80
drwxrwxrwx   3 IBMUSER  SYS1        8192 Jul 10 12:11 IBMUSER
-rw-rw-rw-   1 STCRSE   STCGRP     36655 Jul 10 12:11 rsedaemon.log
-rw-rw-rw-   1 STCRSE   STCGRP      2208 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 296
-rw-rw-rw-   1 IBMUSER  SYS1        6393 Jul 10 12:11 ffs.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 ffsget.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 ffsput.log
-rw-rw-rw-   1 IBMUSER  SYS1         609 Jul 10 12:11 lock.log
-rw-rw-rw-   1 IBMUSER  SYS1         126 Jul 10 12:11 rmt_classloader_cache.jar
-rw-rw-rw-   1 IBMUSER  SYS1       45157 Jul 10 12:11 rsecomm.log
-rw-rw-rw-   1 IBMUSER  SYS1           0 Jul 10 12:11 stderr.log
-rw-rw-rw-   1 IBMUSER  SYS1         176 Jul 10 12:11 stdout.log

parar

$ ls -l /var/rdz/logs
total 80
drwxrwxrwx   3 IBMUSER  SYS1        8192 Jul 10 12:11 IBMUSER
-rw-rw-rw-   1 STCRSE   STCGRP     36655 Jul 10 12:11 rsedaemon.log
-rw-rw-rw-   1 STCRSE   STCGRP      2490 Jul 10 12:12 rseserver.log

A Figura 24 mostra o uso mínimo do espaço do sistema de arquivos z/OS UNIX ao usar o nível de depuração 2 (mensagens informativas).

Exceto para logs de auditoria, os arquivos de log são sobrescritos em cada reinício (para a tarefa iniciada do RSE) ou logon (de um cliente), mantendo o tamanho total em verificação. A diretiva keep.last.log em rsed.envvars altera isso ligeiramente, uma vez que ela pode instruir o RSE a manter uma cópia dos logs anteriores. As cópias mais antigas são sempre removidas.

Uma mensagem de aviso é enviada ao console quando o sistema de arquivos que contém os arquivos de log de auditoria estiver em execução com pouco espaço livre e a auditoria estiver ativa. Essa mensagem do console (FEK103E) é repetida regularmente até que o problema de pouco espaço seja resolvido. Consulte "Mensagens do console" no Guia de Configuração do Host (SC23-7658) para obter uma lista de mensagens do console geradas pelo RSE.

As definições na Tabela 31 controlam os dados que são gravados nos diretórios de log e onde os diretórios estão localizados.

Tabela 31. Diretivas de saída do log
Local Diretriz Funções
resecomm.properties debug_level Definir o nível de detalhes do log padrão.
rsed.envvars keep.last.log Manter uma cópia dos logs anteriores antes da inicialização/logon.
rsed.envvars enable.audit.log Manter um rastreio de auditoria de ações do cliente.
rsed.envvars enable.standard.log Gravar os fluxos stdout e stderr do conjunto (ou conjuntos) de encadeamento em um arquivo de log.
rsed.envvars DSTORE_TRACING_ON Ativar a criação de log de ações do DataStore.
rsed.envvars DSTORE_MEMLOGGING_ON Ativar a criação de log do uso de memória do DataStore.
Comando do operador modify rsecommlog <level> Altera dinamicamente o nível de detalhes do log de rsecomm.log
Comando do operador modify rsedaemonlog <level> Altera dinamicamente o nível de detalhes do log de rsedaemon.log
Comando do operador modify rseserverlog <level> Altera dinamicamente o nível de detalhe do log de rseserver.log
Comando do operador modificar rsestandardlog {on|off} Altera dinamicamente a atualização de std*.*.log
rsed.envvars daemon.log Caminho inicial para a tarefa iniciada do RSE e os logs de auditoria.
rsed.envvars user.log Caminho inicial para logs do usuário.
rsed.envvars CGI_ISPWORK Caminho inicial dos logs do ISPF Client Gateway
rsed.envvars TMPDIR Diretório de logs do IVP
rsed.envvars _CEE_DMPTARG Diretório de dumps Java

Developer for System z, junto com o software de requisito, como o ISPF Client Gateway, também grava dados temporários no /tmp e /var/rdz/WORKAREA. A quantidade de dados gravada aqui como resultado de ações do usuário é imprevisível, portanto você deve ter um amplo espaço livre nos sistemas de arquivos que mantêm esses diretórios.

O Developer for System z sempre tenta limpar estes arquivos temporários, mas a limpeza manual, conforme documentado em "(Opcional) Limpeza de WORKAREA e /tmp" em Guia de Configuração do Host (SC23-7658), pode ser executada virtualmente a qualquer momento.

As definições na Tabela 32 controlam onde os diretórios de dados temporários estão localizados.

Tabela 32. Diretivas de saída temporárias
Local Diretriz Funções
rsed.envvars CGI_ISPWORK Caminho inicial dos dados temporários.
rsed.envvars TMPDIR Diretório dos dados temporários.

Definições de Recursos Principais

/etc/rdz/rsed.envvars

As variáveis de ambiente definidas em rsed.envvars são usadas por RSE, Java e z/OS UNIX. O arquivo de amostra que vem com o Developer for System z é destinado a instalações de pequeno e médio porte que não exigem os componentes opcionais do Developer for System z. "rsed.envvars, arquivo de configuração RSE" no Guia de Configuração do Host (SC23-7658) descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis necessitam de atenção especial:

_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx512m"
Defina o tamanho de heap inicial (Xms) e máximo (Xmx). Os padrões são 128M e 512M, respectivamente. Altere para aplicar os valores de tamanho de heap desejados. Se esta diretiva for removida, os valores padrão de Java serão usados, que são 4M e 512M respectivamente.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=30"
Quantidade máxima de clientes atendidos por um conjunto de encadeamentos. O padrão é 30. Remova o comentário e customize para limitar o número de clientes por conjunto de encadeamentos. Observe que outros limites podem impedir que o RSE atinja esse limite.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threads=520"
Valor máximo dos encadeamentos ativos em um conjunto de encadeamentos para permitir clientes novos. O padrão é 520. Remova o comentário e customize para limitar o número de clientes por conjunto de encadeamentos baseado no número de encadeamentos em uso. Note que cada conexão do cliente usa diversos encadeamentos (17 ou mais) e que outros limites podem evitar que o RSE atinja esse limite.
Nota: Esse valor deve ser inferior ao configurado para MAXTHREADS e MAXTHREADTASKS, em SYS1.PARMLIB(BPXPRMxx).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dminimum.threadpool.process=1"
O número mínimo de conjuntos de encadeamentos ativos. O padrão é 1. Remova o comentário e customize para iniciar pelo menos o número listado de processos do conjunto de encadeamentos. Os processos do conjunto de encadeamentos são usados para balanceamento de carga dos encadeamentos do servidor RSE. Mais novos processos serão iniciados quando forem necessários. Iniciar os novos processos diretamente ajuda a evitar atrasos na conexão, mas usa mais recursos durante os tempos inativos.
Nota: Se a diretiva single.logon estiver ativa, haverá, pelo menos, 2 conjuntos de encadeamentos iniciados, mesmo se minimum.threadpool.process estiver definido como 1. A configuração padrão para single.logon no rsed.envvars é ativo.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threadpool.process=100"
O número máximo de conjuntos de encadeamentos ativos. O padrão é 100. Remova o comentário e customize para limitar o número de processos do conjunto de encadeamentos. Os processos do conjunto de encadeamentos são usados para balanceamento de carga dos encadeamentos do servidor RSE e a limitação deles limitará a quantidade de conexões do cliente ativas.

SYS1.PARMLIB(BPXPRMxx)

O RSE é um aplicativo Java, que significa que ele está ativo no ambiente z/OS UNIX. Isso promove o BPXPRMxx a se tornar um membro parmlib crucial, uma vez que ele contém os parâmetros que controlam o ambiente e os sistemas de arquivos do z/OS UNIX. O BPXPRMxx é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer for System z:

MAXPROCSYS(nnnnn)
Especifica o número máximo de processos que o sistema permite.

Intervalo de Valor: nnnnn é um valor decimal de 5 a 32767.
Padrão: 900
MAXPROCUSER(nnnnn)
Especifica o número máximo de processos que um único ID de usuário do z/OS UNIX pode ter ativo simultaneamente, independentemente de como os processos foram criados.

Intervalo de Valor: nnnnn é um valor decimal de 3 a 32767.
Padrão: 25

Nota:
  • Todos os processos RSE usam o mesmo ID do usuário do z/OS UNIX (aquele do usuário que está designado ao daemon do RSE), pois todos os clientes são executados como encadeamentos dentro dos processos RSE.
  • Esse valor pode ser definido também com a variável PROCUSERMAX no segmento de perfil de segurança OMVS do usuário designado à tarefa iniciada do RSED.
MAXTHREADS(nnnnnn)
Especifica o número máximo de encadeamentos pthread_created, incluindo execução, enfileiramento e saída, exceto desconexão, que um único processo pode ter ativado simultaneamente. Especificar um valor de 0 impede que os aplicativos usem pthread_create.

Intervalo de Valor: nnnnnn é um valor decimal de 0 a 100000.
Padrão: 200

Nota:
  • Cada cliente usa pelo menos 17 encadeamentos dentro do processo do conjunto de encadeamentos do RSE e vários clientes são ativados dentro do processo.
  • Esse valor pode ser configurado também com a variável THREADSMAX no segmento do perfil de segurança OMVS do usuário designado à tarefa iniciada do RSED. Quando configurado, o valor THREADSMAX é usado para MAXTHREADS e MAXTHREADTASKS.
MAXTHREADTASKS(nnnnn)
Especifica o número máximo de tarefas MVS que um único processo pode ter ativado simultaneamente para encadeamentos pthread_created.

Intervalo de Valor: nnnnn é um valor decimal de 0 a 32768.
Padrão: 1000

Nota:
  • Cada encadeamento ativo possui uma tarefa MVS (TCB, Bloco de Controle da Tarefa).
  • Cada tarefa MVS simultânea exige armazenamento adicional, algumas das quais devem ficar abaixo da linha de 16 MB.
  • Cada cliente usa pelo menos 17 encadeamentos dentro do processo do conjunto de encadeamentos do RSE e vários clientes são ativados dentro do processo.
  • Esse valor pode ser configurado também com a variável THREADSMAX no segmento do perfil de segurança OMVS do usuário designado à tarefa iniciada do RSED. Quando configurado, o valor THREADSMAX é usado para MAXTHREADS e MAXTHREADTASKS.
MAXUIDS(nnnnn)
Especifica o número máximo de IDs do usuário (UIDs) do z/OS UNIX que podem funcionar simultaneamente.

Intervalo de Valor: nnnnn é um valor decimal de 1 a 32767.
Padrão: 200
MAXASSIZE(nnnnn)
Especifica os valores de recursos RLIMIT_AS que serão estabelecidos como os valores iniciais para os novos processos. RLIMIT_AS indica o tamanho da região de espaço de endereço.

Intervalo de Valor: nnnnn é um valor decimal de 10485760 (10 Megabytes)
                     a 2147483647 (2 Gigabytes).
Padrão: 209715200 (200 Megabytes)

Nota:
  • Esse valor deve ser configurado como 2 G.
  • Esse valor pode ser configurado com a variável ASSIZEMAX no segmento de perfil de segurança OMVS do usuário designado à tarefa iniciada do RSED.
MAXFILEPROC(nnnnnn)
Especifica o número máximo de descritores para arquivos, soquetes, diretórios e quaisquer outros objetos do sistema de arquivos que um único processo pode ter ativado ou alocado simultaneamente.

Intervalo de Valor: nnnnnn é um valor decimal de 3 a 524287.
Padrão: 64000

Nota:
  • Um conjunto de encadeamentos possui todos os encadeamentos de clientes em um único processo.
  • Esse valor pode ser configurado também com a variável FILEPROCMAX no segmento do perfil de segurança OMVS do usuário designado à tarefa iniciada do RSED.
MAXMMAPAREA(nnnnn)
Especifica a quantidade máxima de espaço de armazenamento do espaço de dados (em páginas) que pode ser alocada para mapeamentos de memória de arquivos z/OS UNIX. O armazenamento não é alocado até que o mapeamento de memória esteja ativado.

Intervalo de Valor: nnnnn é um valor decimal de 1 a 16777216.
Padrão: 40960

Nota: Esse valor pode ser configurado também com a variável MMAPAREAMAX no segmento do perfil de segurança OMVS do usuário designado à tarefa iniciada do RSED.

Use o comando do operador SETOMVS ou SET OMVS para aumentar ou diminuir dinamicamente (até o próximo IPL) o valor de quaisquer variáveis BPXPRMxx anteriores. Para fazer uma alteração permanente, edite o membro BPXPRMxx que será usado para IPLs. Consulte MVS System Commands (SA22-7627) para obter informações adicionais sobre esses comandos do operador.

As definições a seguir são subparâmetros da instrução NETWORK.

MAXSOCKETS(nnnnnnnn)
Especifica o número máximo de soquetes suportados por esse sistema de arquivos para essa família de endereços. Esse é um parâmetro opcional.

Intervalo de Valor: nnnnnnnn é um valor decimal de 0 a 16777215.
Padrão: 100
INADDRANYCOUNT(nnnn)
Especifica o número de portas que o sistema reserva para uso com a PORT 0, as ligações INADDR_ANY, começando com o número de porta especificado no parâmetro INADDRANYPORT. Esse valor é necessário apenas para CINET (várias pilhas TCP/IP).

Intervalo de Valor: nnnn é um valor decimal de 1 a 4000.
Padrão: Se nenhum INADDRANYPORT ou INADDRANYCOUNT
             for especificado, o padrão para INADDRANYCOUNT será 1000.  
             Caso contrário, nenhuma porta será reservada (0).

Várias definições de recurso

Placa EXEC na JCL do Servidor

As definições a seguir são recomendadas a serem incluídas na placa EXEC no JCL dos servidores Developer for System z.

REGION=0M
REGION=0M é recomendado para o daemon RSE e as tarefas iniciadas do JES Job Monitor, RSED e JMON, respectivamente. Fazendo isso, o tamanho do espaço de endereço fica limitado apenas pelo armazenamento privado disponível, ou pelas saídas do sistema IEFUSI ou IEALIMIT. Observe que é altamente recomendado pela IBM que essas saídas não sejam usadas para espaços de endereços z/OS UNIX, como o daemon RSE.
TIME=NOLIMIT
TIME=NOLIMIT é recomendado a ser usado para todos os servidores Developer for System z. Isso porque o tempo de CPU de todos os clientes Developer for System z acumula nos espaços de endereço do servidor.

FEK.#CUST.PARMLIB(FEJJCNFG)

As variáveis de ambiente definidas em FEJJCNFG são usadas pelo JES Job Monitor. O arquivo de amostra fornecido com o Developer for System z destina-se a instalações de porte médio e pequeno. "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658) descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis necessitam de atenção especial:

MAX_THREADS
Número máximo de usuários que podem utilizar um Monitor de Tarefas do JES por vez. O padrão é 200. O valor máximo é 2147483647. Aumentar este número pode exigir o aumento do tamanho do espaço de endereços do JES Job Monitor.

SYS1.PARMLIB(IEASYSxx)

IEASYSxx mantém parâmetros do sistema e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As diretivas a seguir são conhecidas por impactar o Developer for System z:

MAXUSER=nnnnn
Esse parâmetro especifica um valor que, na maioria das condições, o sistema usa para limitar o número de tarefas e as tarefas iniciadas que podem ser executadas simultaneamente durante um IPL específico.

Intervalo de Valor: nnnnn é um valor decimal de 0-32767. Note que os
           valores especificados para os parâmetros do sistema
           MAXUSER, RSVSTRT e RSVNONR não pode exceder 32767.
Valor-padrão: 255

SYS1.PARMLIB(IVTPRMxx)

IVTPRMxx configura parâmetros para o Communication Storage Manager (CSM), e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer for System z:

FIXED MAX(maxfix)
Define a quantidade máxima de armazenamento dedicada a buffers fixos do CSM.

Intervalo de Valor:  maxfix é um valor de 1024K a 2048M.
Padrão: 100M
ECSA MAX(maxecsa)
Define a quantidade máxima de armazenamento dedicada a buffers do ECSA CSM.

Intervalo de Valor:  maxecsa é um valor de 1024K a 2048M.
Padrão: 100M

SYS1.PARMLIB(ASCHPMxx)

Um membro parmlib ASCHPMxx contém informações de planejamento para o planejador de transação ASCH e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As diretivas a seguir são conhecidas por impactar o Developer for System z:

MAX(nnnnn)
Um parâmetro opcional da definição CLASSADD que especifica o número máximo de iniciadores de transações APPC que são permitidos em uma determinada classe de iniciadores de transações. Depois que esse limite for atingido, nenhum novo espaço de endereço será criado e os pedidos recebidos serão enfileirados para aguardar até que os espaços de endereço do iniciador existentes se tornem disponíveis. O valor não deve exceder o número máximo de espaços de endereço permitido por sua instalação e você deve estar ciente dos produtos concorrentes no sistema que também exigirão espaços de endereço.

Intervalo de Valor:  nnnnn é um valor decimal de 1 a 64000.
Padrão: 1

Nota: Se você usar APPC para iniciar o serviço TSO Commands, então a classe de transações usada deve ter iniciadores de transações suficientes para permitir um iniciador para cada usuário concorrente do Developer for System z.

Monitoramento

Como as cargas de trabalho do usuário podem alterar a necessidade de recursos do sistema, o sistema deve ser monitorado regularmente para medir o uso de recursos de modo que o Rational Developer for System z e as configurações do sistema possam ser ajustadas em resposta aos requisitos do usuário. Os comandos a seguir podem ser usados para ajudar nesse processo de monitoramento.

Monitoramento de RSE

Os conjuntos de encadeamentos RSE são o ponto focal para a atividade do usuário no Developer for System z e, assim, exigem monitoramento para o uso ideal. O daemon RSE pode ser consultado sobre informações que não podem ser reunidas com as ferramentas de monitoramento comuns do sistema.

Monitorando o z/OS UNIX

A maioria dos limites z/OS UNIX que é do interesse do Developer for System z pode ser exibida usando comandos do operador. Alguns comandos mostram ainda o uso atual e a limite máximo de um limite específico. Consulte MVS System Commands (SA22-7627) para obter informações adicionais sobre esses comandos.

Monitoramento da Rede

Ao suportar um grande número de clientes se conectando ao host, não só o Developer for System z, mas também sua infraestrutura de rede deve poder manipular a carga de trabalho. O gerenciamento de redes é um assunto amplo e bem documentado que sai do escopo da documentação do Developer for System z. Portanto, apenas os seguintes ponteiros são fornecidos.

Monitorando Sistemas de Arquivos z/OS UNIX

Developer for System z usa sistemas de arquivo z/OS UNIX para armazenar vários tipos de dados, como arquivos de logs e temporários. Use o comando z/OS UNIX df para verificar quantos descritores de arquivo ainda estão disponíveis e quanto espaço livre foi deixado antes que a próxima extensão do conjunto de dados subjacente HFS ou zFS seja criada.

$ df
Mounted on    Filesystem         Avail/Total    Files      Status
/tmp          (OMVS.TMP)         1393432/1396800 4294967248 Available
/u/ibmuser    (OMVS.U.IBMUSER)   1248/1728      4294967281 Available
/usr/lpp/rdz  (OMVS.LPP.FEK)     3062/43200     4294967147 Available
/var          (OMVS.VAR)         27264/31680    4294967054 Available

Configuração de Amostra

A configuração de amostra a seguir mostra a configuração necessária para suportar estes requisitos:

Contagem do Conjunto de Encadeamento

Por padrão, o Developer for System z tenta incluir 30 usuários em um conjunto de encadeamento único. Entretanto, nossos requisitos indicam que o tempo limite de inatividade estará ativo. A Tabela 28 mostra que isso incluirá 1 encadeamento por cliente conectado. Esse encadeamento é um encadeamento de cronômetro e portanto ativo constantemente. Isso evitará que o RSE coloque 30 usuários em um único conjunto de encadeamentos, como 10+30*(17+1)=550, e maximum.threads é configurado para 520 por padrão.

Poderíamos aumentar maximum.threads, mas devido ao requisito ter uma média de 20 MB de heap Java por usuário, optamos por diminuir o maximum.clients para 25 (10+25*18 = 460). Isso nos mantém dentro do tamanho máximo padrão de heap Java de 512 MB (20*25 = 500).

Com 25 clientes por conjunto de encadeamentos e a necessidade de suportar 500 conexões, sabemos agora que precisaremos de 20 espaços de endereço de conjunto de encadeamentos.

Determinar Limites Mínimos

Usando as fórmulas mostradas anteriormente neste capítulo e os critérios mencionados no início desta seção, podemos determinar o uso do recurso que deve ser adaptado.

Definindo Limites

Agora que os números de uso de recursos são conhecidos, podemos customizar a limitação das diretivas com valores apropriados.

Uso de Recurso de Monitor

Após ativar os limites do sistema conforme documentado em Definindo Limites, podemos começar a monitorar o uso do recurso pelo Developer for System z para ver se o ajuste de algumas variáveis é necessário. O Figura 25 mostra o uso de recurso após 499 usuários terem efetuado logon. (O exemplo na figura apenas mostra a criação do logon. Nenhuma ação do usuário é indicada no exemplo).

Figura 25. Uso do recurso de configuração de amostra
F RSED,APPL=D P
BPXM023I (STCRSE)
 ProcessId(83886168) Memory Usage(17%) Clients(25) Order(1)
 ProcessId(91      ) Memory Usage(17%) Clients(25) Order(2)
 ProcessId(122     ) Memory Usage(17%) Clients(25) Order(3)
 ProcessId(16777348) Memory Usage(17%) Clients(25) Order(4)
 ProcessId(16777358) Memory Usage(17%) Clients(25) Order(5)
 ProcessId(16777368) Memory Usage(17%) Clients(25) Order(6)
 ProcessId(16777378) Memory Usage(17%) Clients(25) Order(7)
 ProcessId(16777388) Memory Usage(17%) Clients(25) Order(8)
 ProcessId(16777398) Memory Usage(17%) Clients(25) Order(9)
 ProcessId(33554622) Memory Usage(17%) Clients(25) Order(10)
 ProcessId(16777416) Memory Usage(17%) Clients(25) Order(11)
 ProcessId(16777426) Memory Usage(17%) Clients(25) Order(12)
 ProcessId(16777436) Memory Usage(9%) Clients(25) Order(13)
 ProcessId(16777446) Memory Usage(17%) Clients(25) Order(14)
 ProcessId(16777456) Memory Usage(17%) Clients(25) Order(15)
 ProcessId(16777466) Memory Usage(17%) Clients(25) Order(16)
 ProcessId(16777476) Memory Usage(17%) Clients(25) Order(17)
 ProcessId(16777487) Memory Usage(17%) Clients(25) Order(18)
 ProcessId(16777497) Memory Usage(17%) Clients(25) Order(19)
 ProcessId(16777507) Memory Usage(16%) Clients(24) Order(20)

F RSED,APPL=D P,D
BPXM023I (STCRSE)
 ProcessId(83886168) ASId(0022) JobName(RSED857 ) Order(1)
  PROCESS LIMITS:    CURRENT  HIGHWATER      LIMIT
   JAVA HEAP USAGE(%)     17         17        100
   CLIENTS                25         25         25
   MAXFILEPROC           365        366      64000
   MAXPROCUSER            44         44         80
   MAXTHREADS            310        311       1500
   MAXTHREADTASKS        311        311       1500

TASID
 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------  -----------  -------  ----------
 JMON             0.00     1780          73
 RSED             5.88    95.2M       41958
 RSED1            8.26   190.1M       58669
 RSED1            8.17   187.0M       58605
 RSED2            8.06   185.3M       58653
 RSED2            8.19   183.1M       60209
 RSED3            8.12   189.1M       58650
 RSED3            8.03   186.7M       58590
 RSED4            8.15   188.2M       58646
 RSED4            5.50   182.5M       58585
 RSED5            7.72   184.4M       58631
 RSED5            7.82   184.1M       58576
 RSED6            7.14   184.1M       58622
 RSED6            6.27   186.9M       58583
 RSED7            5.17   185.1M       58804
 RSED7            6.57   185.2M       58621
 RSED7            5.86   182.8M       58565
 RSED8            0.36     1560        2459
 RSED8            7.94   184.1M       58615
 RSED8            7.45   181.8M       58548
 RSED9            8.16   190.6M       58802
 RSED9            7.62   183.8M       58610
 RSED9            7.36   177.7M       57478

Capítulo 6. Considerações sobre Desempenho

O z/OS é um sistema operacional altamente customizável, e (algumas vezes pequenas) alterações no sistema podem ter um grande impacto sobre o desempenho geral. Este capítulo destaca algumas alterações que podem ser feitas para aprimorar o desempenho do Developer for System z.

Consulte MVS Initialization and Tuning Guide (SA22-7591) e UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre o ajuste do sistema.

Usar Sistemas de Arquivos zFS

O zFS (zSeries File System) e o HFS (Hierarchical File System) são sistemas de arquivo UNIX que podem ser usados em um ambiente z/OS UNIX. No entanto, o zFS fornece os seguintes recursos e benefícios:

Consulte UNIX System Services Planning (GA22-7800) para saber mais sobre zFS.

Evite o Uso de STEPLIB

Cada processo do z/OS UNIX que possui um STEPLIB que é propagado de pai para filho ou através de um exec consumirá cerca de 200 bytes de Extended Common Storage Area (ECSA). Se nenhuma variável de ambiente STEPLIB estiver definida, ou quando uma for definida como STEPLIB=CURRENT, o z/OS UNIX propagará todas as alocações TASKLIB, STEPLIB e JOBLIB atualmente ativas durante uma função fork(), spawn() ou exec().

O Developer for System z possui um padrão de arquivo de configuração STEPLIB=NONE codificado em rsed.envvars, conforme descrito em rsed.envvars. Pelas razões mencionadas anteriormente, não altere essa diretiva e coloque os conjuntos de dados de destino em LINKLIST ou LPA (Link Pack Area).

Aprimorar o acesso às bibliotecas do sistema

Determinadas bibliotecas do sistema e módulos de carregamento são intensamente usadas pelo z/OS UNIX e pelas atividades de desenvolvimento do aplicativo. O aprimoramento do acesso, como a inclusão na Área do Pacote de Links (LPA) pode aprimorar o desempenho do sistema. Consulte MVS Initialization and Tuning Reference (SA22-7592) para obter informações adicionais sobre a alteração de membros SYS1.PARMLIB descrito a seguir:

Bibliotecas de Tempo de Execução Language Environment (LE)

Quando programas C (incluindo o shell do z/OS UNIX) são executados, frequentemente usam rotinas da biblioteca de tempo de execução do LE (Language Environment). Em média, aproximadamente 4 MB da biblioteca de tempo de execução são carregados na memória para cada espaço de endereço executando um programa ativado para LE e copiados em cada fork.

CEE.SCEELPA

O conjunto de dados CEE.SCEELPA contém um subconjunto das rotinas de tempo de execução do LE, intensamente usadas pelo z/OS UNIX. Você deve incluir esse conjunto de dados em SYS1.PARMLIB(LPALSTxx) para ganho máximo de desempenho. Fazendo isso, os módulos são lidos do disco apenas uma vez e são armazenados em um local compartilhado.

Nota: Inclua a seguinte instrução em SYS1.PARMLIB(PROGxx), se você preferir incluir os módulos de carregamento na LPA dinâmica:
LPA ADD MASK(*) DSNAME(CEE.SCEELPA) 

Também é aconselhável colocar as bibliotecas de tempo de execução do LE CEE.SCEERUN e CEE.SCEERUN2 em LINKLIST, incluindo os conjuntos de dados em SYS1.PARMLIB(LNKLSTxx) ou SYS1.PARMLIB(PROGxx). Isso elimina o código extra STEPLIB do z/OS UNIX e há uma redução de entrada/saída devido ao gerenciamento pelo LLA e VLF, ou produtos semelhantes.

Nota: Inclua a biblioteca de classes C/C++ DLL CBC.SCLBDLL também em LINKLIST pelos mesmos motivos.

Se você decidir não colocar essas bibliotecas em LINKLIST, será necessário configurar a instrução STEPLIB apropriada no arquivo de configuração rsed.envvars, conforme descrito em rsed.envvars. Embora esse método sempre utilize armazenamento virtual adicional, pode aprimorar o desempenho definindo as bibliotecas de tempo de execução do LE para o LLA ou um produto semelhante. Isso reduz a E/S necessária para carregar os módulos.

Desenvolvimento de Aplicativos

Em sistemas em que o desenvolvimento de aplicativos é a principal atividade, o desempenho também pode ser beneficiado se você colocar o editor de ligação em um LPA dinâmico, incluindo as seguintes linhas em SYS1.PARMLIB(PROGxx):

LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN)
LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)

Para desenvolvimento do C/C++, você também pode incluir o conjunto de dados do compilador CBC.SCCNCMP em SYS1.PARMLIB(LPALSTxx).

As instruções anteriores são amostras de possíveis candidatos de LPA, mas as necessidades no seu site podem variar. Consulte Language Environment Customization (SA22-7564) para obter informações sobre a colocação de outros módulos de carregamento do LE na LPA dinâmica. Consulte UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre a colocação de módulos de carregamento do compilador C/C++ em um LPA dinâmico.

Aprimorando o desempenho da verificação de segurança

Para aprimorar o desempenho da verificação de segurança realizada para o z/OS UNIX, defina o perfil BPX.SAFFASTPATH na classe FACILITY do software de segurança. Isso reduz o código extra ao realizar verificações de segurança do z/OS UNIX para uma ampla variedade de operações, incluindo verificação de acesso ao arquivo, verificação de acesso ao IPC e verificação de propriedade do processo. Consulte UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre esse perfil.

Nota: Os usuários não precisam ter permissão para o perfil BPX.SAFFASTPATH.

Gerenciamento de carga de trabalho

Cada site possui necessidades específicas e é possível customizar o sistema operacional z/OS para aproveitar ao máximo os recursos disponíveis de acordo com essas necessidades. Com gerenciamento de carga de trabalho, você define suas metas de desempenho e designa uma importância de negócios a cada meta. Você define as metas para o trabalho em termos de negócios e o sistema decide quantos recursos, como CPU e armazenamento, devem ser fornecidos para o trabalho, de acordo com a meta.

O desempenho do Developer for System z pode ser equilibrado pela configuração das metas corretas para os processos. Algumas diretrizes gerais são listadas abaixo:

Consulte o MVS Planning Workload Management (SA22-7602) para obter mais informações sobre esse assunto.

Tamanho de heap Java fixo

Com um heap de tamanho fixo, nenhuma expansão ou contração de heap ocorre e isso pode ocasionar significantes ganhos de desempenho em algumas situações. No entanto, a utilização de um heap de tamanho fixo geralmente não é uma boa ideia, porque atrasa o início de uma coleta de lixo até que o heap esteja cheio, momento em que será uma tarefa principal. Também aumenta o risco de fragmentação, o que requer uma compactação de heap. Portanto, utilize heaps de tamanho fixo só depois de desempenhar teste adequado ou quando orientado pelo IBM Support Center. Consulte Java Diagnostics Guide (SC34-6650) para obter informações adicionais sobre tamanhos de heap e coleta de lixo.

O tamanho de heap inicial e máximo de um z/OS Java Virtual Machine (JVM) pode ser configurado com as opções da linha de comandos Java, -Xms (inicial) e -Xmx (máximo).

No Developer for System z, as opções de linha de comandos Java são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars, conforme descrito em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).

#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"

Opção Java -Xquickstart

Nota: -Xquickstart Java é útil apenas se você utilizar o método de inicialização alternativo REXEC/SSH para o servidor RSE. Este método está documentado em "(Opcional) Usando REXEC (ou SSH)" no Guia de Configuração do Host (SC23-7658).

A opção -Xquickstart pode ser usada para melhorar o tempo de inicialização de alguns aplicativos Java. -Xquickstart faz com que o compilador Just In Time (JIT) seja executado com um subconjunto de otimizações, ou seja, uma compilação rápida. Essa compilação rápida permite melhorar o tempo de inicialização.

A opção -Xquickstart é apropriada para aplicativos de execução mais curta, principalmente aqueles em que o tempo de execução não está concentrado em um número pequeno de métodos. -Xquickstart pode prejudicar o desempenho ser for usada em aplicativos de longa execução que contêm métodos ativos.

Para ativar a opção -Xquickstart para o servidor RSE, inclua a seguinte diretiva no final de rsed.envvars:

_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"

Compartilhamento de Classe entre JVMs

O IBM Java Virtual Machine (JVM) versão 5 e superior permite compartilhar classes de aplicativos e de autoinicialização entre JVMs armazenando-as em um cache em memória compartilhada. O compartilhamento de classes reduz o consumo total de memória virtual quando mais de uma JVM compartilha um cache. O compartilhamento de classes também reduz o tempo de inicialização de uma JVM após o cache ser criado.

O cache de classe compartilhada é independente de qualquer JVM ativa e persiste além do tempo de vida da JVM que criou o cache. Como o cache de classe compartilhada persiste além do tempo de vida de qualquer JVM, o cache é atualizado dinamicamente para refletir quaisquer modificações que possam ter sido feitas em JARs ou classes no sistema de arquivo.

A sobrecarga para criar e preencher um novo cache é mínima. O custo de tempo de inicialização da JVM para uma única JVM normalmente é entre 0 e 5% menor em comparação com um sistema que não utiliza compartilhamento de classe, dependendo de quantas classes são carregadas. O aprimoramento do tempo de inicialização da JVM com um cache preenchido normalmente é entre 10% e 40% mais rápido em comparação com um sistema que não utiliza compartilhamento de classe, dependendo do sistema operacional e do número de classes carregadas. Várias JVMs em execução simultaneamente mostram maiores benefícios no tempo de inicialização total.

Consulte o Java SDK and Runtime Environment User Guide para obter informações adicionais sobre o compartilhamento de classe.

Ativar Compartilhamento de Classes

Para ativar o compartilhamento de classes para o servidor RSE, inclua a seguinte diretiva no final de rsed.envvars. A primeira instrução define um cache denominado RSE com acesso em grupo e permite que o servidor RSE seja iniciado, mesmo se o compartilhamento de classes falhar. A segunda instrução é opcional e configura o tamanho do cache para 6 megabytes (o padrão do sistema é 16 MB). A terceira instrução inclui os parâmetros de compartilhamento de classes nas opções de inicialização Java.

_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal
#_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
_RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
Nota: Conforme mencionado em Segurança do Cache, todos os usuários que usam a classe compartilhada devem ter o mesmo ID do grupo (GID) primário. Isso significa que os usuários devem ter o mesmo grupo padrão definido no software de segurança, ou que os grupos padrão diferentes tenham o mesmo GID em seu segmento OMVS.

Limites de Tamanho de Cache

O tamanho máximo de cache compartilhado teórico é 2 GB. O tamanho de cache que você pode especificar é limitado pela quantidade de memória física e pelo espaço de troca disponíveis para o sistema. Como o espaço de endereço virtual de um processo é compartilhado entre o cache de classe compartilhada e o heap Java, o aumento do tamanho máximo do heap Java reduzirá o tamanho do cache da classe compartilhada que você pode criar.

Segurança do Cache

O acesso ao cache de classe compartilhada é limitado por permissões do sistema operacional e permissões de segurança Java.

Por padrão, os caches de classe são criados com a segurança no nível do usuário, portanto, apenas o usuário que criou o cache pode acessá-lo. No z/OS UNIX, há uma opção, groupAccess, que fornece acesso a todos os usuários no grupo primário do usuário que criou o cache. Entretanto, independentemente do nível de acesso usado, um cache poderá ser destruído apenas pelo usuário que o criou ou por um usuário root (UID 0).

Consulte o Java SDK and Runtime Environment User Guide para obter informações adicionais sobre as opções extras de segurança utilizando um Java SecurityManager.

SYS1.PARMLIB(BPXPRMxx)

Algumas das configurações de SYS1.PARMLIB(BPXPRMxx) afetam o desempenho das classes compartilhadas. O uso de configurações incorretas pode interromper o funcionamento de classes compartilhadas. Essas configurações também podem ter implicações no desempenho. Para obter informações adicionais sobre implicações no desempenho e sobre o uso desses parâmetros, consulte MVS Initialization and Tuning Reference (SA22-7592) e UNIX System Services Planning (GA22-7800). Os parâmetros BPXPRMxx mais significativos que afetam a operação de classes compartilhadas são os seguintes:

Espaço em disco

O cache de classe compartilhada requer espaço em disco para armazenar informações de identificação sobre os caches que existem no sistema. Essas informações são armazenadas em /tmp/javasharedresources. Se o diretório de informações de identificação for excluído, a JVM não poderá identificar as classes compartilhadas no sistema e deverá recriar o cache.

Utilitários de Gerenciamento de Cache

O comando da linha Java -Xshareclasses pode utilizar diversas opções, sendo alguns utilitários de gerenciamento do cache. Alguns deles são mostrados no exemplo a seguir ($ é o prompt do z/OS UNIX). Consulte o Java SDK and Runtime Environment User Guide para obter uma visão geral completa das opções de linha de comandos suportadas.

$ java -Xshareclasses:listAllCaches
Shared Cache            OS shmid        in use          Last detach time
RSE                     401412          0               Mon Jun 18 17:23:16 2007

Could not create the Java virtual machine.

$ java -Xshareclasses:name=RSE,printStats

Current statistics for cache "RSE":


base address       = 0x0F300058
end address        = 0x0F8FFFF8
allocation pointer = 0x0F4D2E28

cache size         = 6291368
free bytes         = 4355696
ROMClass bytes     = 1912272
Metadata bytes     = 23400
Metadata % used    = 1%

# ROMClasses       = 475
# Classpaths       = 4
# URLs             = 0
# Tokens           = 0
# Stale classes    = 0
% Stale classes    = 0%

Cache is 30% full

Could not create the Java virtual machine.

$ java -Xshareclasses:name=RSE,destroy
JVMSHRC010I Shared Cache "RSE" is destroyed
Could not create the Java virtual machine.
Nota:
  • Os utilitários de cache executam a operação necessária no cache especificado sem iniciar a JVM, por isso a mensagem "Could not create the Java virtual machine" é normal.
  • Um cache pode ser destruído apenas se todas as JVMs que o utilizam estiverem encerradas e o usuário que emite o comando tiver permissões suficientes.

Capítulo 7. Considerações de Push-to-client

Push-to-client, ou controle de cliente baseado em host, suporta gerenciamento central das seguintes coisas:

Os seguintes tópicos são abordados neste capítulo:

Introdução

Os clientes do Developer for System z versão 8.0.1 e superior podem extrair arquivos de configuração do cliente e informações de atualização do produto do host quando eles se conectam, assegurando que todos os clientes tenham configurações comuns e estejam atualizados.

Desde a versão 8.0.3, o administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar as necessidades de diferentes grupos de desenvolvedores. Isso permite que os usuários recebam uma configuração customizada, com base em critérios como associação de um grupo LDAP ou permissão para um perfil de segurança.

Os projetos do z/OS podem ser definidos individualmente por meio da perspectiva Projetos do z/OS no cliente, ou podem ser definidos centralmente no host e propagados para o cliente em uma base por usuário individual. Esses "projetos baseados em host" se parecem e funcionam exatamente como projetos definidos no cliente, exceto que sua estrutura, seus membros e suas propriedades não podem ser modificados pelo cliente e só podem ser acessados quando conectados ao host.

pushtoclient.properties informa ao cliente se essas funções estão ativadas e onde os dados relacionados são armazenados. Consulte "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094) para obter mais informações.

Normalmente, os sistemas z/OS, as estações de trabalho do desenvolvedor e os projetos de desenvolvimento são gerenciados por diferentes grupos de pessoas. O design push-to-client segue esse princípio e designa responsabilidades específicas a cada grupo:

Consulte o Centro de Informações do Developer for System z (http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp) para obter detalhes sobre como o administrador de cliente e o gerente de projeto de desenvolvimento podem executar as tarefas designadas a eles.

Ao ativar o suporte de configuração ou controle de versão para diversos grupos de desenvolvedor, uma equipe adicional será envolvida no gerenciamento de push-to-client. Qual é essa equipe depende da opção escolhida para identificar os grupos aos quais um desenvolvedor pertence:

Sistema Primário

O push-to-client é designado para armazenar dados específicos do sistema por sistema, enquanto mantém dados comuns (globais) em um único sistema (o sistema primário) para reduzir o esforço de gerenciamento. O sistema primário é identificado pela diretiva primary.system em pushtoclient.properties. O padrão é false.

Certifique-se de ter um, e apenas um, sistema definido como primário. Os administradores de cliente do Developer for System z não podem exportar dados de configuração globais, a menos que o sistema de destino seja um sistema primário. Os clientes do Developer for System z podem mostrar comportamento incorreto ao conectar-se a diversos sistemas primários com configurações fora de sincronização.

A regra somente um não se aplica quando diversos sistemas compartilham a configuração (/etc/rdz) e os metadados push-to-client (/var/rdz/pushtoclient) do Developer for System z. Como a configuração é compartilhada, todos os sistemas envolvidos são identificados como sistema primário. Mas, desde que todos os sistemas também compartilhem os metadados, essa duplicação não é um problema.

Metadados Push-to-client

Local de Metadados

A diretiva pushtoclient.folder em pushtoclient.properties identifica o diretório base no qual os metadados push-to-client são armazenados. O padrão é /var/rdz/pushtoclient.

O diretório base contém o arquivo de configuração push-to-client raiz, keymapping.xml. Todos os demais metadados estão em subdiretórios.

Em sua maioria, os subdiretórios são criados dinamicamente quando o administrador de cliente exporta a configuração da área de trabalho push-to-client. Esses subdiretórios agrupam os metadados por assunto, como mapeamentos e referências. Quanto mais componentes do cliente do Developer for System z se tornam elegíveis para serem gerenciados por push-to-client, mais subdiretórios são criados dinamicamente. Consulte o assistente de exportação no cliente do Developer for System z (Arquivo > Exportar... > Rational Developer for System z > Arquivos de Configuração) para saber o que é armazenado nesses subdiretórios.

Alguns subdiretórios são criados durante a customização do host inicial. Esses subdiretórios contêm dados que são mantidos manualmente pelo administrador de cliente ou pelo gerente de projeto de desenvolvimento.

Consulte "Configuração de Customização" no capítulo "Customização Básica" do Guia de Configuração do Host (S517-9094) para obter mais informações sobre como a criação desses subdiretórios.

Segurança de Metadados

Por padrão (consulte a diretiva file.permission em pushtoclient.properties), todos os arquivos e diretórios criados no diretório base recebem a máscara de bits de permissão 775 (rwxrwxr-x), que permite ao proprietário e ao grupo padrão do proprietário acesso de leitura e gravação à estrutura de diretório e aos arquivos contidos nela. Qualquer outra pessoa só tem acesso de leitura à estrutura de diretório e aos arquivos contidos nela.

É importante que o UID (ID do usuário) e o GID (ID do grupo) corretos do proprietário sejam configurados para esses diretórios antes de iniciar a configuração push-to-client.

Os seguintes comandos de amostra do RACF criam um novo grupo (RDZADMIN), designa a ele um GID exclusivo (2) e o torna o grupo padrão para o ID de usuário RDZADM1, que também recebe um UID exclusivo (6).

ADDGROUP RDZADMIN OWNER(IBMUSER) SUPGROUP(SYS1) -
  DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT ADMIN')
ALTGROUP RDZADMIN OMVS(GID(2))
CONNECT RDZADM1 GROUP(RDZADMIN) AUTH(USE)
ALTUSER RDZADM1 DFLTGRP(RDZADMIN) OMVS(UID(6))

O seguinte comando chown de amostra do z/OS UNIX altera o proprietário e o grupo de /var/rdz/pushtoclient e de tudo que ele contém para RDZADM1 e RDZADMIN, respectivamente. O comando deve ser executado por um superusuário (UID 0) para evitar problemas de permissão.

chown -R rdzadm1:rdzadmin /var/rdz/pushtoclient

O seguinte comando chmod de amostra do z/OS UNIX altera a máscara de bits de permissão de /var/rdz/pushtoclient e de tudo que ela contém para 775. Execute-o para assegurar-se de que toda adição manual ao diretório siga a lógica usada pelo Developer for System z. O comando deve ser executado por um superusuário (UID 0) para evitar problemas de permissão.

chmod -R 775 /var/rdz/pushtoclient

Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter mais informações sobre os comandos de amostra do RACF. Consulte o UNIX System Services Command Reference (SA22-7802) para obter mais informações sobre os comandos de amostra do z/OS UNIX. Consulte a seção Estrutura de diretório do z/OS UNIX para obter mais informações.

Uso de Espaço de Metadados

Os metadados push-to-client usam uma quantidade razoavelmente pequena de espaço em disco no z/OS UNIX, porque a grande massa dos metadados são arquivos XML codificados para UTF-8. Observe que o código do produto usado nos cenários de atualização de cliente podem ser armazenados em qualquer lugar da rede; não é necessário armazenar no z/OS UNIX, porque os metadados push-to-client relacionados (chamados arquivos de resposta) apontam o cliente para o local correto.

Controle de Configuração do Cliente

Quando um cliente do Developer for System z (versão 8.0.1 e superior) se conecta ao host, ele lê as definições em pushtoclient.properties. Se a diretiva config.enabled estiver ativada, o cliente comparará sua configuração atual com as definições nos metadados push-to-client. Se forem encontradas diferenças, o cliente iniciará um assistente que extrai os dados necessários e ativa a configuração conforme indicado pelo push-to-client.

A diretiva reject.config.updates em pushtoclient.properties controla se um usuário tem permissão para rejeitar as atualizações de configuração que o push-to-client está prestes a entregar.

Um cliente do Developer for System z (versão 8.0.1 e superior) tem um assistente, a ser usado pelo administrador de cliente, que pode exportar a configuração atual, que por sua vez é importada por todos os clientes do Developer for System z através do push-to-client. Observe que essa função está disponível em todos os clientes; por isso, você deve assegurar que apenas os administradores de cliente tenham permissão de gravação nos diretórios do z/OS UNIX que contêm metadados push-to-client (/var/rdz/pushtoclient).

A versão 8.0.3 ou superior é necessária ao cliente e ao host para ativar o suporte de grupo, conforme documentado em Diversos Grupos de Desenvolvedores.

Controle de Versão do Cliente

Quando um cliente do Developer for System z (versão 8.0.1 e superior) se conecta ao host, ele lê as definições em pushtoclient.properties. Se a diretiva product.enabled estiver ativada, o cliente comparará sua versão de produto atual com as definições nos metadados push-to-client. Se forem encontradas diferenças, o cliente iniciará um assistente que extrai os dados necessários e ativa a configuração conforme indicado pelo push-to-client.

A diretiva reject.product.updates em pushtoclient.properties controla se um usuário tem permissão para rejeitar atualizações de produto que o push-to-client está prestes a entregar.

A versão 8.0.3 ou superior é necessária ao cliente e ao host para ativar o suporte de grupo, conforme documentado em Diversos Grupos de Desenvolvedores.

Diversos Grupos de Desenvolvedores

Desde a versão 8.0.3, o administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar as necessidades de diferentes grupos de desenvolvedores. Isso permite que os usuários recebam uma configuração customizada, com base em critérios como associação de um grupo LDAP ou permissão para um perfil de segurança.

Ativação

O suporte para diversos grupos de desenvolvedores, cada um com seus próprios requisitos de configuração e atualização do cliente, é ativado ao designar o valor desejado às diretivas relacionadas (config.enabled e product.enabled) em pushtoclient.properties, conforme mostrado na Tabela 33.

Tabela 33. Matriz de suporte ao grupo push-to-client para *.enabled
Valor *.enabled Função ativada Diversos grupos suportados
False Não Não
True Sim Não
LDAP Sim Sim, com base na associação de grupos LDAP FEK.PTC.*.ENABLED.sysname.devgroup
SAF Sim Sim, com base na permissão para perfis de segurança FEK.PTC.*.ENABLED.sysname.devgroup

Observe que quando a função está ativada (isso inclui o valor TRUE), os desenvolvedores sempre fazem parte de um grupo padrão. Um desenvolvedor pode fazer parte de nenhum, um ou vários grupos adicionais.

A rejeição das atualizações também pode ser feita condicionalmente, conforme mostrado na Tabela 34.

Tabela 34. Matriz de suporte ao grupo push-to-client para reject.*.updates
Valor reject.*.updates Função ativada
False Não
True Sim
LDAP Depende da associação do grupo LDAP FEK.PTC.REJECT.*.UPDATES.sysname
SAF Depende da permissão para o perfil de segurança FEK.PTC.REJECT.*.UPDATES.sysname

Observe que as diretivas em pushtoclient.properties funcionam independentemente umas das outras. Você pode designar qualquer valor suportado a qualquer diretiva. Não há requisito para manter as configurações semelhantes.

Consulte Seleção de Grupo Baseada em LDAP e Seleção de Grupo Baseada em SAF para obter detalhes sobre a configuração necessária para a respectiva função. Consulte "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094) para obter mais informações sobre como ativar o suporte a diversos grupos.

Concatenações de Grupo

Quando a função *.enabled está ativada (isso inclui o valor TRUE) em pushtoclient.properties, os desenvolvedores sempre fazem parte de um grupo padrão para a função relacionada. Um desenvolvedor pode fazer parte de nenhum, um ou vários grupos adicionais.

Para limitar a complexidade de aplicar mudanças definidas em vários grupos, o Developer for System z limita as definições que serão usadas, como base em uma seleção feita pelo usuário.

Tabela 35. Concatenações de Grupo Push-to-client
Grupos adicionais Definições usadas
Nenhum Padrão
Um Padrão ou (padrão + grupo)
Diversos Padrão ou (padrão + 1 grupo)

O Developer for System z usa a seguinte lógica ao construir e aplicar o conjunto de mudanças:

  1. Aceita as atualizações, se houver, especificadas nas definições padrão.
  2. Aceita as atualizações especificadas na definição do grupo selecionado, se houver, alterando aquelas padrão, se já estiverem lá.
  3. Aplica as atualizações no cliente.
Nota: As atualizações podem consistir em ações de exclusão, inclusão e sobreposição.

Ligação da Área de Trabalho

Embora um desenvolvedor possa fazer parte de diversos grupos simultaneamente, a área de trabalho ativa do desenvolvedor não pode. A área de trabalho ativa deve estar ligada a um grupo específico (que pode ser o grupo padrão) para receber atualizações de configuração ou do produto. Uma vez feita a ligação, ela não pode ser desfeita. Uma nova área de trabalho deverá ser criada se uma nova ligação de grupo for necessária.

Quando uma área de trabalho que não tem ligação de grupo se conecta ao host, e config.enabled (ou product.enabled) indica que a função de push-to-client está ativa, o Developer for System z consulta todos os grupos para determinar a quais grupos o usuário pertence e solicita que o usuário selecione um grupo para a função relacionada. Nas conexões sucessivas, somente o grupo selecionado é consultado para ver se a associação ao grupo ainda é válida.

As diretivas reject.*.updates não funcionam com diversos grupos; por isso, a configuração deles é mais simples e não requer ligação da área de trabalho. Quando uma atualização está presente, o Developer for System z determina se o usuário tem permissão para rejeitar a atualização, e age apropriadamente.

Local de Metadados do Grupo

Conforme documentado em Local de Metadados, todos os metadados push-to-client são armazenados em uma estrutura de diretório na parte superior de /var/rdz/pushtoclient/ ao usar uma configuração sem o suporte de grupo. O mesmo layout de dados é mantido quando o suporte de grupo é ativado, mas com uma pequena diferença de interpretação, do diretório base, /var/rdz/pushtoclient/:

A customização do produto inicial cria o diretório grouping/ em /var/rdz/pushtoclient/. O administrador de cliente é responsável por incluir os diretórios <devgroup>/ em /var/rdz/pushtoclient/grouping/.

Observe que durante a customização inicial do produto, os diretórios projects/, install/ e install/responsefiles/ são criados em /var/rdz/pushtoclient/. O administrador do cliente deverá repetir essas ações make-directory em /var/rdz/pushtoclient/grouping/<devgroup>/ se houver necessidade de cenários de upgrade de produto de grupo específico ou projetos baseados em host de grupo específico.

A seguinte sequência de comandos de amostra do z/OS UNIX cria os subdiretórios com a máscara de bits de permissão correta. Os comandos devem ser executados pelo administrador de cliente para evitar problemas de propriedade.

saved_umask=$(umask)
umask 0000
cd /var/rdz/pushtoclient/grouping/
mkdir -m775 <devgroup>
cd <devgroup> 
mkdir -m775 install 
mkdir -m775 install/responsefiles 
mkdir -m775 projects 
umask $saved_umask

Consulte o UNIX System Services Command Reference (SA22-7802) para obter mais informações sobre os comandos de amostra do z/OS UNIX.

Etapas de Configuração

A configuração do suporte para diversos grupos de desenvolvedores requer uma coordenação entre o programador de sistema do z/OS, o administrador de cliente e o administrador que gerencia os critérios de seleção (o administrador de LDAP ou segurança). Na seguinte descrição do fluxo de trabalho, o administrador de segurança gerencia os critérios de seleção:

  1. O administrador de cliente solicita ao administrador de segurança as informações sobre configuração de agrupamento existente para desenvolvedores. A reutilização da configuração existente agiliza e simplifica a configuração de push-to-client.
  2. O administrador de cliente determina como ele deseja estruturar o suporte de diversos grupos e quem deve fazer parte desses grupos de push-to-client.
    Nota:
    • Há sempre uma configuração padrão definida e um cenário de atualização de produto padrão.
    • Os conjuntos de mudanças de push-to-client podem incluir ações de exclusão, inclusão e sobreposição.
    • Os conjuntos de mudanças de push-to-client podem ficar vazios.
    • Um desenvolvedor pode fazer parte de nenhum, um ou vários grupos de push-to-client.
    • O administrador de cliente deve ser membro de cada grupo de push-to-client.
  3. Os administradores de cliente e de segurança concordam quanto aos nomes de grupos push-to-client a serem usados.
  4. O administrador de cliente cria o diretório
    /var/rdz/pushtoclient/grouping/<devgroup>
    para cada grupo push-to-client.
    Nota: Os bits de permissão desse diretório devem ser 775 (drwxrwxr-x).
  5. O administrador de segurança faz a configuração inicial necessária para definir os perfis dos critérios de seleção push-to-client e inclui os grupos push-to-client nas listas de acesso.
    Nota:
    • As estruturas de critérios de seleção devem ser definidas com pelo menos o administrador de cliente na lista de acesso para que o administrador de cliente possa criar os metadados push-to-client relacionados.
    • Para a configuração inicial, apenas o administrador de cliente deve estar na lista de acesso de um grupo push-to-client. Isso para evitar que os clientes do Developer for System z recebam configurações que estejam em construção.
  6. O programador de sistema do z/OS ativa o suporte de diversos grupos ajustando pushtoclient.properties.
    Nota: As diretivas *.enabled devem estar ativadas para que o administrador de cliente possa criar os metadados push-to-client relacionados.
  7. O administrador de cliente cria as áreas de trabalho de cada grupo e as exporta para o host usando os respectivos nomes dos grupos. O administrador de cliente também cria os arquivos de resposta requeridos para criar cenários de atualização do produto específico do grupo.
  8. O administrador de segurança inclui os desenvolvedores nos grupos push-to-client, ativando o push-to-client para os desenvolvedores.

Seleção de Grupo Baseada em LDAP

Embora o protocolo LDAP seja o nome de um protocolo baseado em TCP/IP, ele é comumente usado para descrever um conjunto de serviços de diretório distribuídos. Como um banco de dados, um diretório é uma coleção estruturada de registros. O Developer for System z pode usar um servidor LDAP como um banco de dados hierárquico simples, no qual os grupos contêm um ou mais membros.

Ao usar definições no servidor LDAP como mecanismo de seleção (o valor LDAP é especificado para diretivas em pushtoclient.properties), o Developer for System z verifica a associação dos nomes de grupo listados na Tabela 36 para determinar a quais grupos de desenvolvedores o usuário pertence, e se um usuário tem permissão para rejeitar atualizações.

Tabela 36. Informações do LDAP de Push-to-client
Nome do grupo (cn=) Resultado
FEK.PTC.CONFIG.ENABLED.sysname.devgroup O cliente aceita atualizações de configuração para o grupo especificado
FEK.PTC.PRODUCT.ENABLED.sysname.devgroup O cliente aceita atualizações de produto para o grupo especificado
FEK.PTC.REJECT.CONFIG.UPDATES.sysname O usuário pode rejeitar atualizações de configuração
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname O usuário pode rejeitar atualizações de produto

O valor devgroup corresponde ao nome do grupo designado a um grupo específico de desenvolvedores. Observe que o nome do grupo é visível nos clientes do Developer for System z.

O valor sysname corresponde ao nome do sistema de destino.

Esquema LDAP

O esquema LDAP deve satisfazer às seguintes regras:

  1. Cada grupo push-to-client deve ser definido como grupo no esquema.
  2. Cada usuário deve ser definido como usuário no esquema.
  3. Uma entrada de grupo tem as referências para as entradas do usuário que pertencem a seu próprio grupo.

A Figura 26 é uma definição LDAP de amostra para um grupo e usuário, expressa em formato LDIF.

Nota: O Formato de Troca de Dados LDAP (LDIF) é um formato de texto padrão para representar objetos LDAP e atualizações LDAP. Os arquivos que contêm registros LDIF são usados para transferir dados entre servidores de diretório ou como entrada pelos atributos LDAP.
Figura 26. Definição de esquema LDAP de amostra
# Group Definition
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA,o=PTC,c=DeveloperForZ
objectClass: groupOfUniqueNames
objectClass: top
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA
description: Project A
uniqueMember: uid=mborn,ou=Users,dc=example,dc=com

# User Definition
dn: uid=mborn,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: top
cn: May Born
sn: Born
uid: mborn
facsimiletelephonenumber: +1 800 982 6883
givenname: May
mail: mborn@example.com
ou: Users 

Seleção do Servidor LDAP

Há uma ampla seleção de servidores LDAP comerciais e grátis disponíveis. Um exemplo é o IBM Tivoli Directory Server (http://www-01.ibm.com/software/tivoli/products/directory-server/). Há também um ampla seleção de ferramentas de linha de comandos e baseadas na GUI para gerenciar um servidor LDAP.

Conforme mencionado em Esquema LDAP, cada usuário deve ser definido para o servidor LDAP. Para reduzir o esforço de gerenciamento, é melhor colocar o esquema push-to-client em um servidor LDAP que já tenha acesso a todas as definições de usuário. Por exemplo, você pode usar o IBM Tivoli Directory Server ativo no z/OS usando um banco de dados SDBM (que é um wrapper para seu banco de dados de segurança).

Dependendo das políticas do site, o esquema push-to-client no servidor LDAP pode ser gerenciado pelo administrador de cliente. Esse acordo reduz as necessidades de colaboração, bem como possíveis atrasos e erros de comunicação.

Um argumento em favor do gerenciamento LDAP pelo administrador de cliente é que o esquema push-to-client não contém nada que seja confidencial ou esteja relacionado a segurança. Quando definições de usuário estão disponíveis ao servidor LDAP através de outros esquemas, os objetos LDAP do Developer for System z apenas determinam quais opções um desenvolvedor tem na seleção de um layout de área de trabalho e upgrades automáticos de produtos do cliente do Developer for System z.

Local do Servidor LDAP

Qualquer servidor de banco de dados que suporte o protocolo LDAP pode ser usado para hospedar o esquema push-to-client do Developer for System z. Portanto, o Developer for System z permite que você especifique as informações necessárias para conectar-se ao servidor LDAP. Também é possível especificar o sufixo que torna o banco de dados exclusivo no servidor LDAP.

rsed.envvars directive Padrão
_RSE_LDAP_SERVER Sistema de host local
_RSE_LDAP_PORT 389
_RSE_LDAP_PTC_GROUP_SUFFIX "O=PTC,C=DeveloperForZ"

Observe que medidas de segurança de TCP/IP, como firewalls, podem fazer com que o servidor RSE (baseado em host) pare de entrar em contato com o servidor LDAP. Para assegurar-se de que o servidor LDAP possa ser atingido, entre em contato com o administrador de TCP/IP com as seguintes informações:

Configuração de Amostra

Suponha que uma empresa tenha o Developer for System z ativo no sistema CDFMVS08. O IBM Tivoli Directory Server, também ativo no CDFMVS08, é usado como servidor LDAP. O servidor LDAP é configurado conforme descrito em Incluindo Backend push-to-client no LDAP.

Os seguintes usuários utilizam o Developer for System z:

Cada grupo de desenvolvedores requer arquivos de configuração de cliente específicos, e todos os desenvolvedores estão sujeitos ao mesmo controle de versão de cliente. Ao contrário dos administradores de cliente, os desenvolvedores não têm permissão para rejeitar nenhuma mudança que o push-to-client apresente.

Os administradores de cliente e de LDAP concordam em usar os nomes de grupo BANKING e INSURANCE para atualizações de configuração.

Incluindo Backend push-to-client no LDAP

Neste exemplo, são feitas atualizações no IBM Tivoli Directory Server no z/OS, atualmente usando apenas um banco de dados SDBM (wrapper de banco de dados de segurança), incluindo um banco de dados LDBM (arquivos do z/OS UNIX) para hospedar o esquema push-to-client.

  1. Inclua a seção backend do LDBM no arquivo de configuração LDAP.
    # filename ds.conf
    # restart GLDSRV started task to pick up changes
    
    # global section
    adminDN "cn=LDAP admin"
    adminPW password
    listen ldap://:389
    schemaPath /etc/ldap
    
    # SDBM back-end section (RACF)
    database SDBM GLDBSD31/GLDBSD64
    suffix "cn=RACF,o=IBM,c=US"
    
    # LDBM back-end section (z/OS UNIX files)
    database LDBM GLDBLD31/GLDBLD64 LDBM-RDZ
    suffix "o=PTC,c=DeveloperForZ"
    databaseDirectory /var/ldap/ldbm/rdz
  2. Pare e inicie a tarefa iniciada do LDAP, GRDSRV, para selecionar as mudanças na configuração.
  3. Crie o diretório /var/ldap/ldbm/rdz.
     mkdir -p /var/ldap/ldbm/rdz
  4. Atualize o esquema LDAP para incluir o backend do LDBM.
     ldapmodify -D "cn=LDAP admin" -w password -f 
     /usr/lpp/ldap/etc/schema.user.ldif
    
     ldapmodify -D "cn=LDAP admin" -w password -f 
     /usr/lpp/ldap/etc/schema.IBM.ldif
  5. Inclua a entrada raiz no backend do LDBM.
     ldapadd -D "cn=LDAP admin" -w password -f 
     /u/ibmuser/ptc_root.ldif
    em que /u/ibmuser/ptc_root.ldif contém o seguinte:
    dn: o=PTC,c=DeveloperForZ
    objectclass: top
    objectclass: organization
    o: PTC

Configuração de Grupo LDAP Inicial

Inclua os diferentes objetos de grupo LDAP no esquema e torne o administrador de cliente parte de cada um deles. A definição de usuário para o ID do usuário RDZADM1 é extraída do esquema RACF.

ldapadd -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_setup.ldif

em que /u/ibmuser/ptc_setup.ldif contém o seguinte:

#  banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US

#  insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US

#  reject configuration updates
dn: cn=FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US

#  reject product updates
dn: cn=FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US

Incluir Desenvolvedores em Grupos LDAP

Inclua os desenvolvedores nos objetos de grupos LDAP. As definições do usuário para IDs de usuário são obtidas do esquema RACF.

ldapmodify -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_add.ldif

em que /u/ibmuser/ptc_add.ldif retém o seguinte:

# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=BNK010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK014,profileType=user,cn=RACF,o=IBM,c=US

# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=INS010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS014,profileType=user,cn=RACF,o=IBM,c=US

pushtoclient.properties

# BANKING e INSURANCE têm necessidades de configuração diferentes
config.enabled=LDAP
# todos recebem atualizações do produto
product.enabled=TRUE
# somente RDZADMIN pode rejeitar atualizações de configuração
reject.config.updates=LDAP
# somente RDZADMIN pode rejeitar atualizações de produto
reject.product.updates=LDAP

rsed.envvars

Nenhuma atualização é necessária porque os padrões são usados:

/var/rdz/pushtoclient/*install

Ao exportar a configuração da área de trabalho para os grupos BANKING e INSURANCE, o assistente de exportação cria os diretórios /var/rdz/pushtoclient/grouping/<devgroup>/, bem como a estrutura de diretório por trás dele.

Como não há cenários de upgrade de produto individualizado, o administrador de cliente não precisa criar ou atualizar os subdiretórios install/ e install/responsefiles/ no /var/rdz/pushtoclient/grouping/<devgroup>.

O administrador de cliente deve criar os arquivos de resposta necessários para atualizações do produto no diretório de grupo padrão, /var/rdz/pushtoclient/install/responsefiles/.

Seleção de Grupo Baseada em SAF

SAF (Security Access Facility) é uma interface para acessar qualquer produto de segurança do z/OS. O Developer for System z pode usar essa interface para consultar o produto de segurança e recuperar informações relacionadas a push-to-client.

Ao usar as definições do banco de dados de segurança como mecanismo de seleção (o valor SAF é especificado para diretivas em pushtoclient.properties), o Developer for System z verifica as permissões de acesso aos perfis listados na Tabela 37 para determinar a quais grupos de desenvolvedores o usuário pertence, e se um usuário tem permissão para rejeitar atualizações.

Tabela 37. Informações do SAF de Push-to-client
Perfil FACILITY Compri
mento fixo
Acesso Neces
sário
Resultado
FEK.PTC.CONFIG.ENABLED.
  sysname.devgroup
23 READ O cliente aceita atualizações de configuração para o grupo especificado
FEK.PTC.PRODUCT.ENABLED.
  sysname.devgroup
24 READ O cliente aceita atualizações de produto para o grupo especificado
FEK.PTC.REJECT.CONFIG.
  UPDATES.sysname
30 READ O usuário pode rejeitar atualizações de configuração
FEK.PTC.REJECT.PRODUCT.
  UPDATES.sysname
31 READ O usuário pode rejeitar atualizações de produto
Nota: O Developer for System z presume que um usuário não tenha autorização de acesso quando o software de segurança indica que ele não pode determinar se um usuário tem ou não autorização de acesso a um perfil. Um exemplo disso é quando o perfil não está definido.

O valor devgroup corresponde ao nome do grupo designado a um grupo específico de desenvolvedores. Observe que o nome do grupo é visível nos clientes do Developer for System z.

O valor sysname corresponde ao nome do sistema de destino.

A coluna "Comprimento fixo" documenta o comprimento da parte fixa do perfil de segurança relacionado.

Por padrão, o Desenvolvedor para System z espera que os perfis FEK.* estejam na classe de segurança FACILITY. Observe que os perfis na classe FACILITY estão limitados a 39 caracteres. Se a soma do comprimento da parte de perfil fixo (FEK.PTC.<key>.) e o comprimento da parte de perfil específico do site (sysname ou sysname.devgroup) exceder esse número, você poderá colocar os perfis em outra classe e instruir o Developer for System z a usar essa classe no lugar. Para fazer isso, remova o comentário da linha _RSE_FEK_SAF_CLASS em rsed.envvars e forneça o nome de classe desejado.

Configuração de Amostra

Suponha que uma empresa tenha o Developer for System z ativo no sistema CDFMVS08. O banco de dados de segurança RACF é compartilhado entre diversos sistemas e os grupos a seguir são definidos no banco de dados de segurança:

Cada grupo de desenvolvedores requer arquivos de configuração de cliente específicos, e todos os desenvolvedores estão sujeitos ao mesmo controle de versão de cliente. Ao contrário dos administradores de cliente, os desenvolvedores não têm permissão para rejeitar nenhuma mudança que o push-to-client apresente. A regra de rejeição é válida para todos os sistemas, em preparação para expansão futura.

Os administradores de cliente e de segurança concordam em usar os nomes de grupo de push-to-client, BANKING e INSURANCE, para atualizações de configuração.

Definição de Segurança

# permitir que RDZADMIN e DEVBANK selecionem o grupo de push-to-client BANKING
RDEFINE FACILITY (FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING CLASS(FACILITY) -
  ID(RDZADMIN DEVBANK) ACCESS(READ)

# permitir que RDZADMIN e DEVINSUR selecione o grupo de push-to-client INSURANCE
RDEFINE FACILITY (FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE CLASS(FACILITY) -
  ID(RDZADMIN DEVINSUR) ACCESS(READ)

# RDZADMIN pode rejeitar atualizações de configuração em qualquer sistema
RDEFINE FACILITY (FEK.PTC.REJECT.CONFIG.UPDATES.*) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.* CLASS(FACILITY) -
  ID(RDZADMIN) ACCESS(READ)

# RDZADMIN pode rejeitar atualizações de produto em qualquer sistema
RDEFINE FACILITY (FEK.PTC.REJECT.PRODUCT.UPDATES.*) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.* CLASS(FACILITY) -
  ID(RDZADMIN) ACCESS(READ)

# ativar mudanças
SETROPTS RACLIST(FACILITY) REFRESH

pushtoclient.properties

# BANKING e INSURANCE têm necessidades de configuração diferentes
config.enabled=SAF
# todos recebem atualizações do produto
product.enabled=TRUE
# somente RDZADMIN pode rejeitar atualizações de configuração
reject.config.updates=SAF
# somente RDZADMIN pode rejeitar atualizações de produto
reject.product.updates=SAF

rsed.envvars

Nenhuma atualização é necessária porque os padrões são usados:

	_RSE_FEK_SAF_CLASS=FACILITY

/var/rdz/pushtoclient/*install

Ao exportar a configuração da área de trabalho para os grupos BANKING e INSURANCE, o assistente de exportação cria os diretórios /var/rdz/pushtoclient/grouping/<devgroup>/, bem como a estrutura de diretório por trás dele.

Como não há cenários de upgrade de produto individualizado, o administrador de cliente não precisa criar ou atualizar os subdiretórios install/ e install/responsefiles/ no /var/rdz/pushtoclient/grouping/<devgroup>/.

O administrador de cliente deve criar os arquivos de resposta necessários para atualizações do produto no diretório de grupo padrão, /var/rdz/pushtoclient/install/responsefiles/.

Período de Carência para Rejeitar Mudanças

Suponha que enquanto a configuração de amostra está ativa, um fix pack do Developer for System z com correções importantes se torne disponível, mas o cronograma de um projeto financeiro faz com que vários desenvolvedores estejam muito ocupados para alterar qualquer coisa em suas estações de trabalho imediatamente.

Para resolver o problema, o administrador de segurança pode conceder a todos os desenvolvedores DEVBANK um período de carência durante o qual eles podem optar por adiar (rejeitar) a atualização.

Configurar o período de carência é um processo muito simples:

# start of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.* CLASS(FACILITY) -
  ID(DEVBANK) ACCESS(READ)

# ativar mudanças
SETROPTS RACLIST(FACILITY) REFRESH

Ao final do período de carência, a autoridade adicional pode ser removida novamente:

# end of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.* CLASS(FACILITY) -
  ID(DEVBANK) DELETE

# ativar mudanças
SETROPTS RACLIST(FACILITY) REFRESH

Projetos baseados no host

Os projetos do z/OS podem ser definidos individualmente por meio da perspectiva Projetos do z/OS no cliente, ou podem ser definidos centralmente no host e propagados para o cliente em uma base por usuário individual. Esses "projetos baseados em host" se parecem e funcionam exatamente como os projetos definidos no cliente, exceto que sua estrutura, seus membros e suas propriedades não podem ser modificados pelo cliente e só podem ser acessados quando conectados ao host.

O diretório base para projetos baseados em host é definido (pelo administrador do cliente) em /var/rdz/pushtoclient/keymapping.xml, e é /var/rdz/pushtoclient/projects por padrão.

Para configurar projetos baseados em host, o gerente de projeto ou o desenvolvedor líder precisa definir os seguintes tipos de arquivos de configuração. Todos os arquivos são XML codificados para UTF-8.

Os projetos baseados em host também são elegíveis para participar da configuração de diversos grupos discutida em Diversos Grupos de Desenvolvedores. Essa elegibilidade significa que os projetos baseados em host podem ser definidos também em /var/rdz/pushtoclient/grouping/<devgroup>/projects/.

Quando uma área de trabalho está ligada a um grupo específico, e há definições de projeto para um usuário nesse grupo e no grupo padrão, o usuário recebe as definições do projeto dos grupos padrão e específico.

Capítulo 8. considerações CICSTS

Tradicionalmente, a função de definição de recursos para o CICS tem sido o domínio do administrador do CICS. Há uma resistência em permitir que o desenvolvedor de aplicativos defina recursos do CICS por vários motivos:

Developer for System z aborda esses problemas permitindo que os administradores do CICS controlem padrões de definição de recurso do CICS e controlem as propriedades de exibição de um parâmetro de definição de recurso do CICS por meio do servidor CICS Resource Definition (CRD), que é parte do Application Deployment Manager.

Por exemplo, o administrador do CICS pode fornecer certos parâmetros de definição de recurso do CICS que podem não ser atualizados pelo desenvolvedor de aplicativos. Outros parâmetros de definição de recurso do CICS podem ser atualizados, com ou sem os padrões fornecidos, ou o parâmetro de definição de recurso do CICS pode ser ocultado para evitar uma complexidade desnecessária.

Quando o desenvolvedor de aplicativos estiver satisfeito com as definições de recursos do CICS, elas poderão ser instaladas imediatamente no ambiente de teste do CICS em execução, ou poderão ser exportadas em um manifesto para edição e aprovação adicionais por um administrador do CICS. O administrador do CICS pode utilizar o administrative utility (utilitário em lote) ou a ferramenta Processamento de Manifesto para implementar as alterações de definição de recurso.

Nota: A ferramenta Processamento de Manifesto é um plug-in para o IBM CICS Explorer.

Consulte "(Opcional) Gerenciador de Implementação do Aplicativo" no Guia de Configuração do Host (SC23-7658) para obter mais informações sobre as tarefas necessárias para configurar o Application Deployment Manager em seu sistema host.

Customizar o Application Deployment Manager inclui os serviços a seguir no Developer for System z:

O servidor CICS Resource Definition (CRD) do Application Deployment Manager consiste no próprio servidor CRD, um repositório CRD, definições do recurso CICS associadas e, ao usar a interface de Serviço da Web, arquivos de ligação de Serviço da Web e um manipulador de mensagens do pipeline de amostra. O servidor CRD deve executar em uma Web Owning Region (WOR), que é mencionada na documentação do Developer for System z como a região de conexão primária do CICS.

Consulte o Centro de Informações do Developer for System z (http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp) para aprender mais sobre os serviços do Aplication Deployment Manager disponíveis na liberação atual do Developer for System z.

RESTful versus Serviços da Web

O CICS Transaction Server fornece na versão 4.1 e posterior suporte para uma interface HTTP projetada usando princípios do Representational State Transfer (RESTful). Essa interface RESTful é agora a interface CICSTS estratégica para uso por aplicativos clientes. A interface de Serviço da Web mais antiga foi estabilizada e os aprimoramentos serão apenas para a interface RESTful.

O Application Deployment Manager segue essa instrução de direção e exige o servidor RESTful CRD para todos os serviços que são novos no Developer for System versão 7.6 ou superior.

O RESTful e as interfaces de Serviço da Web podem ser ativados simultaneamente em uma única região CICS, se desejado. Nesse caso, haverá dois servidores CRD ativos na região. Os dois servidores compartilharão o mesmo repositório CRD. Observe que o CICS emitirá alguns avisos sobre definições duplicadas quando a segunda interface for definida para a região.

Regiões de Conexão Primária versus Não-primária

Um ambiente de teste do CICS pode consistir de várias regiões Multi-Region Option (MRO) conectadas. Com o tempo, foram utilizadas designações não oficiais para classificar essas regiões. As designações típicas são Terminal Owning Region (TOR), Web Owning Region (WOR), Application Owning Region (AOR) e Data Owning Region (DOR).

Uma Web Owning Region é usada para implementar suporte aos Serviços da Web do CICS e o servidor CICS Resource Definition (CRD) do Application Deployment Manager deve ser executado nessa região. Esta região é conhecida no Gerenciador de Implementação do Aplicativo como a região de conexão primária do CICS. O cliente do CRD implementa uma conexão de serviço da Web na região de conexão primária do CICS.

As regiões de conexão não-primárias do CICS são todas as outras regiões que o servidor CRD pode atender. Esse serviço inclui visualizar recursos utilizando IBM CICS Explorer e definir recursos utilizando o editor de definição de recurso do CICS.

Se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recurso do CICS da região de conexão primária do CICS, todas as outras regiões do CICS gerenciadas pelo BAS poderão ser atendidas pelo servidor CRD.

As regiões do CICS não gerenciadas pelo BAS requerem alterações adicionais para poderem ser atendidas pelo servidor CRD.

Log de Instalação de Recurso do CICS

As ações feitas pelo servidor CRD em relação aos recursos do CICS são registradas na fila do CICS CSDL TD, que normalmente aponta para a DD MSGUSR de sua região do CICS.

Se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recursos do CICS, a diretiva CICSPlex SM EYUPARM BASLOGMSG deverá ser configurada como (YES) para que o log seja criado.

segurança do Application Deployment Manager

segurança do repositório CRD

O conjunto de dados de VSAM do repositório do servidor CRD contém todas as definições de recurso padrão e deve, portanto, ser protegido contra atualizações, mas os desenvolvedores devem ter permissão para ler os valores armazenados aqui. Consulte Definir Perfis de Conjuntos de Dados para obter comandos RACF de amostra para proteger o repositório do CRD.

Segurança de Pipeline

Quando uma mensagem SOAP for recebida pelo CICS por meio da interface de Serviço da Web, ela será processada por um pipeline. Um pipeline é um conjunto de manipuladores de mensagens que são executados em sequência. O CICS lê o arquivo de configuração do pipeline para determinar quais manipuladores de mensagens devem ser chamados no pipeline. Um manipulador de mensagem é um programa no qual você pode executar processamento especial de pedidos e respostas de serviço da Web.

O Application Deployment Manager fornece um arquivo de configuração de pipeline de amostra que especifica a chamada de um manipulador de mensagens e um programa de processamento de cabeçalho SOAP.

O manipulador de mensagens do pipeline (ADNTMSGH) é usado para segurança através do processamento do ID do usuário e da senha no cabeçalho SOAP. ADNTMSGH é referido pelo arquivo de configuração de pipeline de amostra e, portanto, deve ser colocado na concatenação RPL do CICS.

Segurança da Transação

CPIH é o ID da transação padrão que um aplicativo chamado por um pipeline executará. Geralmente, o CPIH é configurado para um nível mínimo de autorização.

O Developer for System z fornece várias transações que são usadas pelo servidor CRD durante a definição e a consulta de recursos do CICS. Esses IDs de transação são configurados pelo servidor CRD, dependendo da operação solicitada. Consulte "(Opcional) Gerenciador de Implementação do Aplicativo" no Guia de Configuração do Host (SC23-7658) para obter mais informações sobre como customizar os IDs de transação.

Transação Descrição
ADMS Para solicitações da ferramenta Processamento de Manifesto para alterar recursos do CICS. Geralmente, isso é destinado aos administradores do CICS. Essa transação requer um alto nível de autorização.
ADMI Para pedidos que definam, instalem ou desinstalem recursos do CICS. Essa transação pode requerer um nível médio de autorização, dependendo das políticas do site.
ADMR Para todos os outros pedidos que recuperam as informações de ambiente e de recurso do CICS. Essa transação pode requerer um nível mínimo de autorização, dependendo das políticas do site.

Alguns ou todos esses pedidos de definição de recurso feitos pelas transações do servidor CRD devem ser protegidos. No mínimo, os comandos de atualização (parâmetros de atualização padrão do serviço da Web, parâmetros padrão do descritor e o nome de arquivo para ligação do nome do conjunto de dados) devem ser protegidos para impedir que todos, exceto os administradores do CICS, emitam esses comandos usados para configurar padrões de recurso global.

Quando a transação é conectada, a verificação de segurança de recurso do CICS, se ativada, garante que o ID do usuário esteja autorizado para executar o ID de transação.

A verificação de recursos é controlada pela opção RESSEC na transação que está executando o parâmetro de inicialização do sistema RESSEC e, para o servidor do CRD, o parâmetro de inicialização do sistema XPCT.

A verificação de recursos ocorre apenas se o parâmetro de inicialização do sistema XPCT tiver um valor diferente de NO e a opção RESSEC da definição TRANSACTION for YES ou o parâmetro de inicialização do sistema RESSEC for ALWAYS.

Os seguintes comandos RACF mostram como as transações do servidor CRD podem ser protegidas. Consulte o RACF Security Guide for CICSTS para obter informações adicionais sobre a definição da segurança do CICS.

comunicação criptografada por SSL

A criptografia SSL do fluxo de dados é suportada quando o cliente do Application Deployment Manager usa a interface dos Serviços da Web para invocar o servidor CRD. O uso de SSL para essa comunicação é controlado pela palavra-chave SSL(YES) na definição CICSTS TCPIPSERVICE, conforme documentado em RACF Security Guide para CICSTS.

Segurança do Recurso

O CICSTS fornece a capacidade de proteger os recursos e os comandos para manipulá-los. Algumas ações do Application Deployment Manager podem falhar se a segurança estiver ativada, mas não configurada completamente (por exemplo, concedendo permissões para manipular novos tipos de recursos).

Em caso de falha da função no Application Deployment Manager, examine o log do CICS para obter mensagens como a seguir e execute as ações corretivas, conforme documentado em RACF Security Guide para CICSTS.

DFHXS1111 %date %time %applid %tranid Security violation by user 
%userid at netname %portname for resource %resource in class 
%classname. SAF codes are (X'safresp',X'safreas'). ESM codes are 
(X'esmresp',X'esmreas').

Administrative Utility

O Developer for System z fornece o utilitário administrativo para permitir que administradores do CICS forneçam os valores-padrão para as definições de recurso do CICS. Esses padrões podem ser somente de leitura ou podem ser editados pelo desenvolvedor de aplicativos.

O administrative utility fornece as seguintes funções:

O administrative utility é chamado pela tarefa de amostra ADNJSPAU no conjunto de dados FEK.#CUST.JCL. O uso desse utilitário requer acesso UPDATE ao repositório do CRD.

ADNJSPAU está localizado em FEK.#CUST.JCL, a menos que o programador do sistema z/OS tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de customização" no Guia de Configuração do Host (SC23-7658) para obter mais detalhes.

Nota: O repositório CRD deve ser fechado no CICS antes de executar a tarefa ADNJSPAU. O repositório pode ser aberto novamente após a conclusão da tarefa. Por exemplo, após se conectar ao CICS, digite os seguintes comandos para fechar e abrir o arquivo, respectivamente:
  • CEMT S FILE(ADNREPF0) CLOSED
  • CEMT S FILE(ADNREPF0) OPEN

As instruções de controle de entrada são usadas para atualizar o repositório do CRD de um ambiente de teste do CICS, para o qual as regras gerais de sintaxe a seguir se aplicam:

As definições de amostra a seguir seguem a estrutura dos comandos DFHCSDUP, conforme definido no CICS Resource Definition Guide para CICSTS. A única diferença é a inserção das seguintes palavras-chave de permissão de exibição usadas para agrupar valores de atributo em três conjuntos de permissões:

UPDATE Os atributos que seguem essa palavra-chave serão atualizados por um desenvolvedor de aplicativos utilizando Developer for System z. Esse também é o padrão para atributos omitidos.
PROTECT Os atributos que seguem essa palavra-chave serão exibidos, mas estarão protegidos contra atualizações por um desenvolvedor de aplicativos utilizando Developer for System z.
HIDDEN Os atributos que seguem essa palavra-chave não serão exibidos e estarão protegidos contra atualizações por um desenvolvedor de aplicativos utilizando Developer for System z.

Consulte a seguinte amostra de código ADNJSPAU.

Figura 27. ADNJSPAU - Administrative utility do CICSTS
//ADNJSPAU JOB <JOB PARAMETERS>
//*
//ADNSPAU  EXEC PGM=ADNSPAU,REGION=1M
//STEPLIB  DD DISP=SHR,DSN=FEK.SFEKLOAD
//ADMREP   DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
*
* Parâmetros CICSPlex SM
*
DEFINE CPSMNAME(        )
*DEFINE STAGINGGROUPNAME(ADMSTAGE)
*
* Regra de exportação de manifesto
*
DEFINE MANIFESTEXPORTRULE(installOnly)
*
*   Padrões de definição de recurso do CICS
* Atributos omitidos são padronizados como UPDATE.
*
*   Atributos padrão DB2TRAN
*
DEFINE DB2TRAN()
       UPDATE  DESCRIPTION()
              ENTRY()
              TRANSID()
*
*   Atributos padrão DOCTEMPLATE
*
DEFINE DOCTEMPLATE()
       UPDATE  DESCRIPTION()
              TEMPLATENAME()
              FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM()
              DDNAME(DFHHTML) MEMBERNAME()
              HFSFILE()
              APPENDCRLF(YES) TYPE(EBCDIC)
*
*   Atributos padrão de arquivo
*
DEFINE FILE()
       UPDATE DESCRIPTION()
               RECORDSIZE() KEYLENGTH()
               RECORDFORMAT(V) ADD(NO)
               BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO)
               REMOTESYSTEM() REMOTENAME()
       PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1)
               STATUS(ENABLED) OPENTIME(FIRSTREF)
               DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1)
               TABLE(NO) MAXNUMRECS(NOLIMIT)
               READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS)
               UPDATEMODEL(LOCKING) LOAD(NO)
               JNLREAD(NONE) JOURNAL(NO)
               JNLSYNCREAD(NO) JNLUPDATE(NO)
               JNLADD(NONE) JNLSYNCWRITE(YES)
               RECOVERY(NONE) FWDRECOVLOG(NO)
               BACKUPTYPE(STATIC)
               PASSWORD() NSRGROUP()
               CFDTPOOL() TABLENAME()
Figura 28. ADNJSPAU - Utilitário Administrativo CICSTS (Parte 2 de 3)
*
* Atributos padrão Mapset
*
DEFINE MAPSET()
       UPDATE DESCRIPTION()
       PROTECT RESIDENT(NO) STATUS(ENABLED)
               USAGE(NORMAL) USELPACOPY(NO)
** Atributos padrão de tipo de processo
*
DEFINE PROCESSTYPE()
       UPDATE DESCRIPTION()
               FILE(BTS)
       PROTECT STATUS(ENABLED)
               AUDITLOG() AUDITLEVEL(OFF)
*
* Atributos padrão de programa
*
DEFINE PROGRAM()
       UPDATE DESCRIPTION()
               CEDF(YES) LANGUAGE(LE370)
               REMOTESYSTEM() REMOTENAME() TRANSID()
       PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT)
               DATALOCATION(ANY) DYNAMIC(NO)
               EXECKEY(USER) EXECUTIONSET(FULLAPI)
               RELOAD(NO) RESIDENT(NO)
               STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO)
       HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR)
*
* Atributos padrão TDQueue
*
DEFINE TDQUEUE()
       UPDATE DESCRIPTION()
               TYPE(INTRA)
* Parâmetros de partição extra
               DDNAME() DSNAME()
               REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1)
               RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED)
               BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR)
* Parâmetros de partição intra
               FACILITYID() TRANSID() TRIGERRLEVEL(1)
               USERID()
* Parâmetros indiretos
               INDIRECTNAME()
       PROTECT WAIT(YES) WAITACTION(REJECT)
* Parâmetros de partição extra
               DATABUFFERS(1)
               SYSOUTCLASS() ERROROPTION(IGNORE)
               OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT)
* Parâmetros de partição intra
               ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
Figura 29. ADNJSPAU - Utilitário Administrativo CICSTS (Parte 3 de 3)
*
* Atributos padrão de transação
*
DEFINE TRANSACTION()
       UPDATE DESCRIPTION()
               PROGRAM()
               TWASIZE(0)
               REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
       PROTECT PARTITIONSET() PROFILE(DFHCICST)
               DYNAMIC(NO) ROUTABLE(NO)
               ISOLATE(YES) STATUS(ENABLED)
               RUNAWAY(SYSTEM) STORAGECLEAR(NO)
               SHUTDOWN(DISABLED)
               TASKDATAKEY(USER) TASKDATALOC(ANY)
               BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
               DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
               DUMP(YES) TRACE(YES) CONFDATA(NO)
               OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
               ACTION(BACKOUT) INDOUBT(BACKOUT)
               RESSEC(NO) CMDSEC(NO)
               TRPROF()
               ALIAS() TASKREQ()
               XTRANID() TPNAME() XTPNAME()
*
* Atributos URDIMAP
*
DEFINE URIMAP()                        
       UPDATE  USAGE(CLIENT)           
               DESCRIPTION()           
               PATH(/required/path)    
               TCPIPSERVICE()          
               TRANSACTION()           
               PROGRAM()               
       PROTECT ANALYZER(NOANALYZER)    
               ATOMSERVICE()           
               CERTIFICATE()           
               CHARACTERSET()          
               CIPHERS()               
               CONVERTER()             
               HFSFILE()               
               HOST(host.mycompany.com)
               HOSTCODEPAGE()          
               LOCATION()              
               MEDIATYPE()             
               PIPELINE()              
               PORT(NO)                
               REDIRECTTYPE(NONE)      
               SCHEME(HTTP)            
               STATUS(ENABLED)         
               TEMPLATENAME()          
               USERID()                
               WEBSERVICE()            
*
* Nome de arquivo opcional para ligações de nome do conjunto de dados VSAM
*
*DEFINE DSBINDING() DSNAME()
/*

Notas de Migração do Utilitário Administrativo

Developer for System z versão 7.6.1 incluiu suporte URIMAP no Administrative utility. Para poder usar o suporte URIMAP, o conjunto de dados VSAM do repositório CRD deve estar alocado com um tamanho de registro máximo de 3000. Até a Developer for System z versão 7.6.1, as tarefas de alocação do repositório CRD da amostra usam um tamanho de registro máximo de 2000.

Siga estas etapas para ativar o suporte URIMAP se você estiver ’ usando um repositório CRD mais antigo:

  1. Crie um backup do seu repositório CRD existente, FEK.#CUST.ADNREPF0.
  2. Exclua o repositório CRD existente.
  3. Customize e submeta a tarefa FEK.SFEKSAMP(ADNVCRD) para alocar e inicializar um novo repositório CRD. Consulte a documentação no membro para obter instruções de customização.
  4. Customize e submeta a tarefa FEK.SFEKSAMP(ADNJSPAU) para usar o Administrative utility para preencher o repositório CRD novo.
Nota:
  • Migrar o repositório CRD existente não é necessário porque o administrative utility substitui os conteúdos completos do repositório CRD cada vez que ele é executado.
  • Não há problemas de compatibilidade de versão com o repositório CRD. Todo cliente suportado pelo Developer for System z e código de host trabalharão com tamanho de registro máximo. Mas o suporte URIMAP estará desativado se o tamanho de registro máximo não for 3000.

Mensagens do Administrative Utility

As mensagens a seguir são emitidas pelo Administrative utility para a SYSPRINT DD. As mensagens CRAZ1803E, CRAZ1891E, CRAZ1892E e CRAZ1893E contêm códigos de status de arquivo, retorno do VSAM, função do VSAM e feedback do VSAM. Os códigos de retorno, função e feedback do VSAM são documentados em DFSMS Macro Instructions for Data Sets (SC26-7408). Os códigos de status de arquivo são documentados em Enterprise COBOL for z/OS Language Reference (SC27-1408).

CRAZ1800I
concluído com êxito na linha <número da linha da última instrução de controle>

Explicação: O administrative utility do programador de sistema foi concluído com sucesso.

Resposta do usuário: Nenhuma.

CRAZ1801W
concluído com avisos na linha <número da linha da última instrução de controle>

Explicação: O administrative utility do programador de sistema foi concluído com um ou mais avisos localizados durante o processamento de instruções de controle.

Resposta do usuário: Verifique outras mensagens de aviso.

CRAZ1802E
encontrado um erro na linha < número da linha>

Explicação: O administrative utility do programador de sistema encontrou um erro grave.

Resposta do usuário: Verifique outras mensagens de aviso.

CRAZ1803E
Erro ao abrir repositório, status=<código de status do arquivo> RC=<código de retorno do VSAM> FC=<código de função do VSAM> FB=<código de feedback do VSAM>

Explicação: O administrative utility do programador de sistema encontrou um erro grave ao abrir o repositório do CRD.

Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.

CRAZ1804E
Registro de entrada não reconhecido na linha <número da linha>

Explicação: O administrative utility do programador de sistema encontrou uma instrução de controle de entrada desconhecida.

Resposta do usuário: Verifique se o comando DEFINE foi seguido por um espaço único e depois pela palavra-chave CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING, DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE ou TRANSACTION.

CRAZ1805E
Processando a palavra-chave <palavra-chave> na linha <número da linha>

Explicação: O administrative utility do programador de sistema está processando a instrução de controle de entrada da palavra-chave DEFINE.

Resposta do usuário: Nenhuma.

CRAZ1806E
Regra de exportação de manifesto inválida na linha <número da linha>

Explicação: O administrative utility do programador de sistema encontrou uma regra de exportação de manifesto inválida.

Resposta do usuário: Verifique se o valor da palavra-chave MANIFESTEXPORTRULE é "installOnly", "exportOnly" ou "both".

CRAZ1807E
Palavra-chave DSNAME ausente na linha <número da linha>

Explicação: O administrative utility do programador de sistema estava processando uma instrução de controle DEFINE DSBINDING que não possui a palavra-chave DSNAME.

Resposta do usuário: Verifique se a instrução de controle DEFINE DSBINDING contém a palavra-chave DSNAME.

CRAZ1808E
Valor inválido da palavra-chave <palavra-chave> na linha <número da linha>

Explicação: O administrative utility do programador de sistema estava processando uma instrução de controle DEFINE e encontrou um valor inválido para a palavra-chave nomeada.

Resposta do usuário: Verifique se o comprimento e o valor da palavra-chave nomeada estão corretos.

CRAZ1890W
Erro de sintaxe de palavra-chave na linha <número da linha>

Explicação: O administrative utility do programador de sistema estava processando uma instrução de controle DEFINE e encontrou um erro de sintaxe para a palavra-chave ou valor da palavra-chave.

Resposta do usuário: Verifique se o valor da palavra-chave está entre parênteses e imediatamente após a palavra-chave. A palavra-chave e o valor da palavra-chave devem estar contidos na mesma linha.

CRAZ1891W
Erro ao gravar chave duplicada do repositório, status=<código de status do arquivo> RC=<código de retorno do VSAM> FC=<código de função do VSAM> FB=<código de feedback do VSAM>

Explicação: O administrative utility do programador de sistema encontrou um erro de chave duplicada ao gravar no repositório CRD.

Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.

CRAZ1892W
Erro ao gravar repositório, status=<código de status do arquivo> RC=<código de retorno do VSAM> FC=<código de função do VSAM> FB=<código de feedback do VSAM>

Explicação: O administrative utility do programador de sistema encontrou um erro grave ao gravar no repositório CRD.

Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.

CRAZ1893W
Erro ao ler repositório, status=<código de status do arquivo> RC=<código de retorno do VSAM> FC=<código de função do VSAM> FB=<código de feedback do VSAM>

Explicação: O administrative utility do programador de sistema encontrou um erro grave ao ler o repositório do CRD.

Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.

Depuração de Transação do CICS

Para depurar transações do CICS, o Depurador Integrado requer as seguintes atualizações do CICS:

Para depurar transações do CICS carregadas na memória de leitura, o Depurador Integrado requer as seguintes atualizações do sistema:

Observe que somente um depurador baseado no ambiente de linguagem (LE) pode estar ativo em uma determinada região do CICS. Uma indicação clara de um depurador baseado em LE é que ele fornece um módulo de carregamento CEEEVDBG ou alias que deve estar disponível no aplicativo.

Capítulo 9. Considerações da Saída de Usuário

Esse capítulo o ajuda a aprimorar o Developer for System z ao gravar as rotinas de saída.

O Developer for System z fornece pontos de saída para selecionar os eventos do Developer for System z. Um ponto de saída é um ponto específico em um processamento de função no qual a função chama uma rotina de saída, se houver. É possível gravar uma rotina de saída para executar o processamento adicional.

Note que, ao contrário da maioria dos pontos de saída tradicionais, os pontos de saída do Developer for System z não permitem que você altere o comportamento da função. A rotina de saída, se houver, é chamada de forma assíncrona, após a função ser concluída. O processamento do Developer for System z não espera a rotina de saída terminar, nem verifica o status de conclusão.

Características da Saída de Usuário

Ativação da Saída de Usuário

As saídas de usuário são ativadas com as variáveis _RSE_JAVAOPTS <exit_point>.action no rsed.envvars, em que <exit_point> representa uma palavra-chave que identifica um ponto de saída específico, conforme documentado em Pontos de Saída Disponíveis.

 
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action=<user_exit>"

Por padrão, todos os pontos de saída ficam desativados. Remova o comentário e especifique o nome do caminho completo da rotina de saída do usuário para ativar o ponto de saída.

 
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action.id=<userid>"

Por padrão, o ID do usuário designado para o daemon RSE é usado para executar a rotina de saída fornecida. Remova o comentário e especifique um ID do usuário para usar o ID especificado para executar a saída de usuário. Não há necessidade de especificar uma senha porque o RSE gerará um PassTicket para ser usado como senha quando ele alternar para o ID do usuário especificado.

Gravando uma Rotina de Saída do Usuário

As rotinas de saída do usuário são chamadas como um comando shell z/OS UNIX com possivelmente um ou mais argumentos. Isso significa que a rotina de saída desenvolvida deve ser executável na linha de comandos do z/OS UNIX. As técnicas de codificação comuns incluem o shell script do z/OS UNIX e o REXX exec do z/OS UNIX, mas o código compilado como C/C++ também é possível.

Consulte o Guia do Usuário do UNIX System Services (SA22-7801) para saber mais sobre os shell scripts do z/OS UNIX. Consulte Usando REXX e z/OS UNIX System Services (SA22-7806) para saber mais sobre as extensões específicas do z/OS UNIX para a linguagem REXX.

A rotina de saída provavelmente será executada por um ID do usuário com permissões especiais (como o ID do usuário de tarefa iniciada do RSE, que é permitido para gerar os PassTickets). Portanto, é importante que você limite a autoridade de atualização para a rotina de saída para evitar abuso. Os limites de comandos de amostra a seguir do z/OS UNIX gravam a autoridade somente para o proprietário, embora todos possam ler e executar o script.

$ chmod 755 process_logon.sh
$ ls -l process_logon.sh 
-rwxr-xr-x   1 IBMUSER  SYS1        2228 Feb 28 23:44 process_logon.sh

As definições no rsed.envvars estão disponíveis para a rotina de saída do usuário como variáveis de ambiente.

O RSE chama a rotina de saída do usuário com uma sequência de argumentos única. A sequência de argumentos pode ser um valor único ou uma sequência única que retém diversas palavras-chave e valores delimitados em branco. Consulte Pontos de Saída Disponíveis para obter mais detalhes.

Mensagens do console

O Developer for System z usa o ID de mensagem do console FEK910I para exibir os dados relacionados às saídas de usuário.

A chamada da rotina de saída é marcada com a mensagem do console a seguir:

FEK910I <EXIT_POINT> EXIT: invoking <exit_point> processing exit 
  in thread <thread_id>

Todos os dados gravados no stdout (comando echo em um shell script, comando say em um REXX exec) serão enviados ao console:

FEK910I <EXIT_POINT> EXIT: <message>

A terminação da rotina de saída é marcada com a mensagem do console a seguir:

FEK910I <EXIT_POINT> EXIT: completed <exit_point> processing exit
 in thread <thread_id>

Executando com um ID do Usuário da Variável

O Developer for System z permite executar uma rotina de saída com o ID do usuário de tarefa iniciada ou com um ID do usuário especificado. Entretanto, talvez você queira executar algumas ações na rotina de saída usando outro ID do usuário, como o ID de usuário cliente na rotina de saída do logon. Isso pode ser realizado com o uso dos serviços padrão do z/OS UNIX, conforme mostrado nas amostras a seguir.

Shell Script do z/OS UNIX

Conforme documentado na Referência de Comando do UNIX System Services (SA22-7802), o z/OS UNIX oferece o comando su para usar os privilégios de um superusuário ou outro usuário. Há algumas coisas a serem lembradas ao usar o comando su.

#! /bin/sh
myID=ibmuser
echo a $(id)
echo 'echo b $(id)' | su -s $myID
echo "echo c \$(id)" | su -s $myID
cat /u/ibmuser/iefbr14
echo "submit /u/ibmuser/iefbr14" | su -s $myID

Essa saída de logon de amostra, executada pelo ID do usuário de tarefa iniciada, resultará nas mensagens de console a seguir:

+FEK910I LOGON EXIT: invoking logon processing exit in thread 411
+FEK910I LOGON EXIT: a uid=8(STCRSE) gid=1(STCGROUP)
+FEK910I LOGON EXIT: b uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: c uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: //IEFBR14  JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
+FEK910I LOGON EXIT: //IEFBR14  EXEC PGM=IEFBR14
$HASP100 IEFBR14  ON INTRDR                            FROM STC03919
IBMUSER
IRR010I  USERID IBMUSER  IS ASSIGNED TO THIS JOB.
+FEK910I LOGON EXIT: JOB JOB03926 submitted from path '/u/ibmuser/iefbr14'
ICH70001I IBMUSER  LAST ACCESS AT 00:46:13 ON MONDAY, MARCH 19, 2012
$HASP373 IEFBR14  STARTED - INIT 2    - CLASS A - SYS CD08
IEF403I IEFBR14 - STARTED - TIME=00.46.14
+FEK910I LOGON EXIT: completed logon processing exit in thread 411
    IEFBR14     IEFBR14     IEFBR14     0000
IEF404I IEFBR14 - ENDED - TIME=00.46.14
$HASP395 IEFBR14  ENDED
$HASP309 INIT 2    INACTIVE ******** C=BA

REXX exec do z/OS UNIX

Conforme documentado em Usando REXX e z/OS UNIX System Services (SA22-7806), o z/OS UNIX oferece o comando seteuid SYSCALL para configurar o UID efetivo do processo atual. Há algumas coisas a serem lembradas ao usar o comando seteuid.

/* rexx */
myID='ibmuser'
say userid()
address SYSCALL 'getpwnam' myID 'pw.'
say pw.1 pw.2 pw.3 pw.4 pw.5
address SYSCALL 'seteuid' pw.2  /* PW_UID = 2 */
say retval errno errnojr
say userid()

Essa saída de logon de amostra, executada pelo ID do usuário de tarefa iniciada, resultará nas mensagens de console a seguir:

+FEK910I LOGON EXIT: invoking logon processing exit in thread 515
+FEK910I LOGON EXIT: STCRSE
+FEK910I LOGON EXIT: IBMUSER  1 0 / /bin/sh
+FEK910I LOGON EXIT: 0 0 0
+FEK910I LOGON EXIT: IBMUSER
+FEK910I LOGON EXIT: completed logon processing exit in thread 515

Pontos de Saída Disponíveis

Os pontos de saída a seguir são fornecidos pelo Developer for System z:

audit.action

logon.action

Capítulo 10. Customizando o Ambiente TSO

Este capítulo é fornecido para auxiliar a imitar um procedimento de logon de TSO incluindo instruções DD e conjuntos d dados no ambiente do TSO em Developer for System z.

O Serviço TSO Commands

O serviço TSO Commands é o componente Developer for System z que executa comandos TSO e ISPF (em lote) e retorna o resultado para o cliente solicitante. Esses comandos podem ser solicitados implicitamente pelo produto ou explicitamente pelo usuário.

Os membros de amostra fornecidos com o Developer for System z criam um ambiente mínimo do TSO/ISPF. Se os desenvolvedores em sua loja precisarem de acesso a bibliotecas customizadas ou de terceiros, o programador de sistema z/OS deve incluir as instruções DD e as bibliotecas necessárias para o ambiente de serviço TSO Commands. Embora a implementação seja diferente no Developer for System z, a lógica por trás disso é idêntica ao procedimento de logon do TSO.

Nota: O serviço TSO Commands é uma ferramenta de linha de comandos não interativa, portanto, os comandos ou procedimentos que solicitam dados ou exibem painéis ISPF não funcionarão. Um emulador 3270, como o Host Connect Emulator que faz parte do cliente Developer for System z, será necessário para executá-los.

Métodos de Acesso

A partir da versão 7.1, o Developer for System z fornece uma opção para acessar o serviço TSO Commands.

Nota:
  • O serviço de Gateway do Cliente TSO/ISPF do ISPF substitui a função do SCLM Developer Toolkit usada na versão 7.1.
  • O uso de APPC por Developer for System z está marcado como reprovado. As informações relacionadas ao APPC foram removidas desta publicação. Para obter mais informações, consulte o White Paper Using APPC to provide TSO command services (SC14-7291), disponível na biblioteca do Developer for System z, http://www-01.ibm.com/support/docview.wss?uid=swg27038517.

Verifique o rsed.envvars para determinar qual método de acesso é usado para hosts da versão 7.1 e superior. Se os padrões tiverem sido usados durante o processo de configuração, rsed.envvars residirá em /etc/rdz/.

Usando o Método de Acesso do TSO/ISPF Client Gateway

ISPF.conf

O arquivo de configuração ISPF.conf (localizado por padrão em /etc/rdz/) define o ambiente do TSO/ISPF usado pelo Developer for System z. Existe apenas um arquivo de configuração ISPF.conf ativo, que é usado por todos os usuários do Developer for System z.

A seção principal do arquivo de configuração define os nomes DD e as concatenações relacionadas do conjunto de dados, como no seguinte exemplo:

sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
myDD=HLQ1.LLQ1,HLQ2.LLQ2

Usar Perfis do ISPF Existentes

Por padrão, o TSO/ISPF Client Gateway cria um perfil temporário do ISPF para o serviço TSO Commands. Entretanto, você pode instruir o TSO/ISPF Client Gateway z a utilizar uma cópia de um perfil existente do ISPF. A chave aqui é a instrução _RSE_ISPF_OPTS em rsed.envvars.

#_RSE_ISPF_OPTS="$_RSE_ISPF_OPTS&ISPPROF=&SYSUID..ISPPROF"

Remova o comentário da instrução (remova o sinal de sustenido (#) inicial) e forneça o nome completo do conjunto de dados do perfil existente do ISPF para utilizar esse recurso.

As seguintes variáveis podem ser usadas no nome do conjunto de dados:

Nota:
  • Se o nome do conjunto de dados transmitido em "ISPPROF" for inválido, um perfil de ISPF vazio temporário será usado.
  • O perfil do ISPF (temporário e copiado) é excluído no final da sessão. As alterações feitas no perfil não são mescladas com o perfil existente do ISPF.

Usando um exec de alocação

A instrução allocjob no ISPF.conf (que está assinalada como comentário por padrão) aponta um exec que pode ser usado para fornecer alocações adicionais do conjunto de dados por ID do usuário.

*allocjob = ISP.SISPSAMP(ISPZISP2)

Remova o comentário da instrução (remova o caractere de asterisco (*) inicial) e forneça a referência completa para o exec de alocação para utilizar esse recurso.

Nota: Como o exec é chamado antes do ISPF ser inicializado, você não pode utilizar VPUT e VGET. No entanto, você pode criar suas próprias implementações dessas funções utilizando um arquivo VSAM ou PDS(E).

Usar Diversos Execs de Alocação

Embora o ISPF.conf suporte apenas a chamada de um exec de alocação, não há limites para um exec chamar outro exec. E o ID do usuário do cliente que está sendo transmitido como parâmetro abre os execs de alocação personalizados. Você pode, por exemplo, verificar se o membro USERID’.EXEC(ALLOC)’ existe e executá-lo.

Uma variação elaborada para esse tema permite o uso de procedimentos de logon existentes do TSO, como a seguir:

Diversos Arquivos ISPF.conf com Diversas Configurações do Developer for System z

Se os cenários de exec de alocação descritos nas seções anteriores não puderem tratar de suas necessidades específicas, você poderá criar instâncias diferentes do servidor de comunicação RSE do Developer for System z, cada uma delas usando seu próprio arquivo ISPF.conf. A desvantagem principal do método descrito a seguir é que os usuários do Developer for System z devem conectar-se a servidores diferentes no mesmo host para obter o ambiente TSO desejado.

Nota: A criação de uma segunda instância do servidor RSE requer apenas a duplicação e atualização de arquivos de configuração, JCL de inicialização e definições de tarefa iniciada. Não é necessária uma nova instalação do produto e nenhum código é duplicado.
$ cd /etc/rdz
$ mkdir /etc/rdz/tso2
$ cp rsed.envvars /etc/rdz/tso2
$ cp ISPF.conf /etc/rdz/tso2
$ ls /etc/rdz/tso2
ISPF.conf              rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
      -> change: _RSE_RSED_PORT=4037
      -> change: CGI_ISPCONF=/etc/rdz/tso2
      -> change: -Ddaemon.log=/var/rdz/logs/tso2
      -> change: -Duser.log=/var/rdz/logs/tso2
      -> add at the END:
         # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
         CFG_BASE=/etc/rdz
         CLASSPATH=.:$CFG_BASE:$CLASSPATH
         # -- 
$ oedit /etc/rdz/tso2/ISPF.conf
      -> change: change as needed

Os comandos no exemplo anterior copiam os arquivos de configuração do Developer for System z que exigem alterações no diretório tso2 recém-criado. A variável CGI_ISPCONF em rsed.envvars deve ser atualizada para definir o novo diretório inicial ISPF.conf, e daemon.log e user.log devem ser atualizados para definir um novo local de log (que é criado automaticamente se não existir). A atualização _RSE_RSED_PORT assegura que o daemon do RSE existente e novo usarão números de porta exclusivos. A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para tso2. O arquivo ISPF.conf em si pode ser atualizado para atender às suas necessidades. Observe que a área de trabalho do ISPF (variável CGI_ISPWORK em rsed.envvars) pode ser compartilhada entre ambas as instâncias.

Agora resta apenas criar uma nova tarefa iniciada para o RSE que utiliza um novo número de porta e os novos arquivos de configuração /etc/rdz/tso2. Observe que se _RSE_RSED_PORT não for alterado em rsed.envvars, a nova tarefa iniciada deverá especificar uma nova porta como argumento de inicialização.

Consulte o Guia de Configuração de Host do IBM Rational Developer for System z (S517-9094) para obter mais informações sobre as ações mostradas anteriormente nesta seção.

Capítulo 11. Executando várias instâncias

Há situações em que você deseja várias instâncias do Developer for System z ativas no mesmo sistema, por exemplo, durante o teste de um upgrade. Entretanto, alguns recursos, como portas TCP/IP, não podem ser compartilhadas, portanto os padrões nem sempre são aplicáveis. Use as informações neste apêndice para planejar a coexistência de instâncias diferentes do Developer for System z, após as quais você pode utilizar este guia de configuração para customizá-las.

Embora seja possível compartilhar certas partes do Developer for System z entre duas (ou mais) instâncias, isso NÃO é recomendado, a menos que seus níveis de software sejam idênticos e as únicas alterações sejam nos membros de configuração. O Developer for System z deixa espaço de customização suficiente para criar várias instâncias que não se sobrepõem, e recomendamos a utilização destes recursos.

Nota:
  • FEK e /usr/lpp/rdz são o qualificador de alto nível e o caminho usados durante a instalação do produto. FEK.#CUST, /etc/rdz e /var/rdz são os locais padrão usados durante a customização do produto (consulte "Configuração de customização" no Guia de Configuração do Host (SC23-7658) para obter informações adicionais)..
  • Você deve instalar o Developer for System z em um sistema de arquivos privado (HFS ou zFS) para facilitar a implementação das partes do produto z/OS UNIX.
  • Se você não puder usar um sistema de arquivos privado, deverá usar uma ferramenta de arquivamento, como o comando z/OS UNIX tar para transportar os diretórios do z/OS UNIX de sistema para sistema. Isso para preservar os atributos (como controle de programas) para os arquivos e diretórios do Developer for System z.

    Consulte UNIX System Services Command Reference (SA22-7802) para obter informações adicionais sobre os seguintes comandos de amostra para arquivar e restaurar o diretório de instalação do Developer for System z.

    • Archive: cd /SYS1/usr/lpp/rdz; tar -cSf /u/userid/rdz.tar
    • Restore: cd /SYS2/usr/lpp/rdz; tar -xSf /u/userid/rdz.tar

Configuração idêntica em um sysplex

Os arquivos de configuração do Developer for System z (e código) podem ser compartilhados entre diferentes sistemas em um sysplex, com cada sistema executando sua própria cópia idêntica do Developer for System z, se algumas diretrizes forem obedecidas. Observe que estas informações destinam-se a instâncias do Developer for System z independentes. Regras adicionais para a configuração do TCP/IP são aplicadas usando o Distributed Dynamic VIPA para agrupar diversos servidores (cada qual em um sistema separado) em um servidor virtual, conforme documentado em Distributed Dynamic VIPA.

Arquivos de Configuração Diferentes de Níveis de Software Idênticos

Em algum conjunto limitado de circunstâncias, é possível compartilhar tudo, menos (algumas das) as partes customizáveis. Um exemplo é fornecer acesso não-SSL para uso no site e comunicação codificada por SSL para uso externo.

Atenção: A configuração compartilhada NÃO PODE ser usada com segurança para manutenção de teste, visualização técnica ou novo release.

Para configurar outra instância de uma instalação ativa do Developer for System z, refaça as etapas de customização das partes que são diferentes, usando conjuntos de dados, diretórios e portas diferentes para evitar sobreposição da configuração atual.

Na amostra de SSL mencionada anteriormente, a configuração do daemon RSE atual pode ser fechada e depois a configuração clonada pode ser atualizada. Em seguida, a JCL de inicialização do daemon RSE pode ser clonada e customizada com uma nova porta TCP/IP e o local dos arquivos de configuração atualizado. As customizações MVS (JES Job Monitor, entre outras) podem ser compartilhadas entre instâncias SSL e não-SSL. Isso resultaria nas seguintes ações:

$ cd /etc/rdz
$ mkdir /etc/rdz/ssl
$ cp rsed.envvars /etc/rdz/ssl
$ cp ssl.properties /etc/rdz/ssl
$ ls /etc/rdz/ssl/
rsed.envvars    ssl.properties
$ oedit /etc/rdz/ssl/rsed.envvars
      -> change: _RSE_RSED_PORT=4047
      -> change: -Ddaemon.log=/var/rdz/logs/ssl
      -> change: -Duser.log=/var/rdz/logs/ssl
      -> add at the END:
         # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
         CFG_BASE=/etc/rdz
         CLASSPATH=.:$CFG_BASE:$CLASSPATH
         # -- 
$ oedit /etc/rdz/ssl/ssl.properties
      -> change: change as needed

Os comandos no exemplo anterior copiam os arquivos de configuração do Developer for System z que requerem mudanças em um diretório recém-criado ssl. As variáveis daemon.log e user.log em rsed.envvars devem ser atualizadas para definir um novo local de log (o qual será criado automaticamente se ainda não existir). A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para ssl. O próprio arquivo ssl.properties pode ser atualizado para corresponder às suas necessidades.

Agora resta criar uma nova tarefa iniciada para o RSE que usa um novo número de porta e os novos arquivos de configuração /etc/rdz/ssl.

Consulte as seções relacionadas no Guia de Configuração do Host IBM Rational Developer for System z (S517-9094) para obter mais informações sobre as ações mostradas anteriormente nesta seção.

Sincronização Automatizada

Na amostra de SSL mencionada anteriormente, as mudanças entre o daemon RSE ativado por SSL e não SSL são mínimas, o que permite automatizar o processo de manter seus arquivos rsed.envvars sincronizados. Isso simplifica o lançamento de serviço porque apenas um arquivo rsed.envvars deve ser mantido.

O exemplo a seguir inclui um número da porta RSED nos nomes do diretório de log e atualiza o CLASSPATH para que os clones localizem o restante dos arquivos de configuração. Em seguida, o exemplo melhora a tarefa JCL iniciada do daemon RSE ativado por SSL para clonar o rsed.envvars do daemon RSE não SSL na inicialização, atualizando o número da porta no processo. Como o número da porta é integrado no nome do diretório de log, ele será automaticamente diferente entre os dois daemons.

  1. Prepare o rsed.envvars principal.
    $ oedit /etc/rdz/rsed.envvars
          -> change: -Ddaemon.log=/var/rdz/logs/$RSE_RSED_PORT
          -> change: -Duser.log=/var/rdz/logs/$RSE_RSED_PORT
          -> add at the END:
             # -- NEEDED BY CLONES TO FIND THE REMAINING CONFIGURATION FILES
             CFG_BASE=/etc/rdz
             CLASSPATH=.:$CFG_BASE:$CLASSPATH
             # -- 
  2. Prepare outros arquivos de configuração (que não são arquivos rsed.envvars) que diferem entre o principal (não SSL) e o clone (SSL).
    $ mkdir /etc/rdz/ssl
    $ cp /etc/rdz/ssl.properties /etc/rdz/etc/rdz/ssl
    $ oedit /etc/rdz/ssl/ssl.properties
          -> change: change as needed
  3. Crie uma tarefa iniciada RSED que clone o rsed.envvars de base e altere a porta do daemon RSE (4035 -> 4034).
    //*
    //* RSE DAEMON - SSL
    //*
    //RSED     PROC IVP=,                * 'IVP' to do an IVP test
    //            HOME='/usr/lpp/rdz',
    //            CNFG='/etc/rdz/ssl'
    //*
    //         SET SED='"/RSED_PORT/s/4035/4034/"'
    //         SET FILE='rsed.envvars'
    //*
    //* copy /etc/rdz/rsed.envvars to /etc/rdz/ssl/rsed.envvars
    //* and alter RSED_PORT
    //*
    //CLONE    EXEC PGM=BPXBATCH,REGION=0M,COND=(4,LT),
    //  PARM='SH cd &CNFG;sed &SED ../&FILE>&FILE' 
    //STDOUT   DD SYSOUT=* 
    //STDERR   DD SYSOUT=* 
    //* 
    //* start RSED with the newly created rsed.envvars 
    //* 
    //RSED     EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,COND=(4,LT), 
    //  PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG' 
    //STDOUT   DD SYSOUT=* 
    //STDERR   DD SYSOUT=* 
    //         PEND 
    //*

Todas as Outras Situações

Quando alterações de código estiverem envolvidas (manutenção, visualizações técnicas, novo release), ou suas alterações forem razoavelmente complexas, é aconselhável fazer outra instalação do Developer for System z. Esta seção descreve os possíveis pontos de conflito entre as diferentes instalações.

A lista a seguir é uma breve visão geral dos itens que devem ser ou são altamente aconselhados a serem diferentes entre as instâncias do Developer for System z:

Uma visão geral mais detalhada é listada a seguir:

Capítulo 12. Resolução de problemas de configuração

Este capítulo é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar durante a configuração do seu Developer for System z, e possui as seções a seguir:

A publicação Developer for System z Messages and Codes (SC14-7497) documenta mensagens e códigos de retorno gerados por componentes do Developer for System z. Developer for System z Answers to common host configuration and maintenance issues (SC14-7373) descreve vários cenários de problemas e sua resolução.

Mais informações estão disponíveis na seção Suporte do website do Developer for System z (http://www-03.ibm.com/software/products/us/en/developerforsystemz/), onde é possível localizar as Notas Técnicas que trazem as informações mais recentes de nossa equipe de suporte.

Na seção Biblioteca do website (http://www-01.ibm.com/support/docview.wss?uid=swg27038517), também é possível localizar a versão mais recente da documentação do Developer for System z, incluindo White Papers.

O Centro de Informações do Developer for System z (http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp) documenta o cliente do Developer for System z e como ele interage com o host (em uma perspectiva do cliente).

Informações sobre valor também podem ser localizadas na biblioteca do z/OS na Internet, disponível em http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.

Notifique-nos se pensar que o Developer for System z não tem uma certa função. Você pode abrir uma Solicitação para Aprimoramento (RFE) em

https://www.ibm.com/developerworks/support/rational/rfe/

Análise de Log e Configuração Usando FEKLOGS

Developer for System z fornece uma tarefa de amostra, FEKLOGS, que reúne todos os arquivos de log do z/OS UNIX bem como as informações de instalação e configuração do Developer for System z.

A tarefa de amostra FEKLOGS está localizada em FEK.#CUST.JCL, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de customização" no Guia de Configuração do Host (SC23-7658) para obter mais detalhes.

A customização de FEKLOGS é descrita dentro da JCL. A customização inclui a provisão de algumas variáveis principais.

Nota: Os clientes do SDSF podem usar o comando da linha XDC no SDSF para salvar a saída da tarefa em um conjunto de dados, o qual, por sua vez, pode ser fornecido para o centro de suporte IBM. Observe que o conjunto de dados de saída deve ser alocado como VB 2051 (o valor padrão no SDSF é VB 240) para evitar truncamento de registro.

Arquivos de Log

O Developer for System z cria arquivos de log que podem auxiliar você e o centro de suporte da IBM na identificação e solução de problemas. A lista a seguir é uma visão geral de arquivos de log que podem ser criados no sistema host do z/OS. Ao lado desses logs específicos do produto, assegure-se de marcar o SYSLOG de todas as mensagens relacionadas.

Os logs baseados no MVS podem ser localizados na instrução DD apropriada. Arquivos de log baseados no z/OS UNIX estão localizados nos seguintes diretórios:

Nota: Há comandos do operador disponíveis para controlar a quantidade de dados gravados em alguns dos arquivos de log mencionados. Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) para obter informações adicionais.

criação de logs do JES Job Monitor

Criação de Log de Daemon RSE e de Conjunto de Encadeamento

Nota:
  • serverlogs.count, stderr.*.log e stdout.*.log são criados apenas se a diretiva enable.standard.log em rsed.envvars estiver ativa ou se a função for dinamicamente ativada com o comando do operadormodify rsestandardlog on.
  • O * em stderr.*.log e em stdout.*.log significa 1 por padrão. Entretanto, pode existir vários conjuntos de encadeamento RSE e, nesse caso, o número é aumentado para cada novo conjunto de encadeamento RSE para garantir nomes de arquivos exclusivos.
  • Há comandos do operador disponíveis para controlar a quantidade de dados gravados em alguns dos arquivos de log mencionados. Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) para obter informações adicionais.
  • Os arquivos rse*.log também podem existir com uma extensão ".last", em vez de uma extensão ".log", se keep.last.log=true for especificado em rsed.envvars. Por padrão, os arquivos de log ".last" não são criados.
  • Os arquivos rse*.log terão um nome estendido se keep.all.logs=true for especificado em rsed.envvars. Por padrão, o nome estendido é usado. O nome a seguir é uma amostra do nome estendido, em que RSED representa o nome do espaço de endereço do daemon RSE e yyyymmddhhmmss é o registro de data e hora (ano, mês, dia, hora, minuto, segundo): rseserver.RSED#yyyymmddhhmmss.log

criação de logs do usuário do RSE

Nota:
  • O diretório .eclipse e os arquivos de log .dstore* começam com um ponto (.), o que os torna ocultos. Use o comando ls -lA do z/OS UNIX para listar arquivos e diretórios ocultos. Ao usar o cliente Developer for System z, selecione a página de preferências Janela > Preferências... > Sistemas Remotos > Arquivos e ative "Mostrar arquivos ocultos".
  • A criação dos arquivos de log .dstore* é controlada pelas opções de inicialização -DDSTORE_* Java, conforme descrito em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
  • Os arquivos de log .dstore* são criados em ASCII. Use o comando do z/OS UNIX, iconv -f ISO8859-1 -t IBM-1047 .dstore*, para exibi-los no EBCDIC (ao usar a página de códigos IBM-1047).
  • Diferente dos arquivos *.log, os arquivos de log do .dstore* não são removidos automaticamente na reconexão do cliente. A remoção desses arquivos é uma ação manual.
  • Há comandos do operador disponíveis para controlar a quantidade de dados gravados em alguns dos arquivos de log mencionados. Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) para obter informações adicionais.
  • Os arquivos ffs*.log, lock.log e rsecomm.log também podem existir com uma extensão ".last", em vez de uma extensão ".log", sekeep.last.log=true for especificado em rsed.envvars. Por padrão, os arquivos de log ".last" não são criados.
  • Os arquivos ffs*.log, lock.log e rsecomm.log terão um nome estendido se keep.all.logs=true for especificado em rsed.envvars. Por padrão, o nome estendido é usado. O nome a seguir é uma amostra de nome estendido, em que RSEDx representa o nome do espaço de endereço do conjunto de encadeamentos no qual o usuário está ativo e yyyymmddhhmmss é um registro de data e hora (ano, mês, dia, hora, minuto, segundo): ffs.RSEDx#yyyymmddhhmmss.log

criação de log do SCLM Developer Toolkit

Criação de logs do CARMA

Criação de Log IVP fekfivpc

Criação de log de teste IVP do fekfivpi

Criação de Log de Teste IVP do fekfivps

Criação de Log da Revisão de Código

Criação de Log da Cobertura de Código

Arquivos de dump

Quando um produto é finalizado de forma anormal, um dump de armazenamento é criado para auxiliar na determinação do problema. A disponibilidade e o local desses dumps dependem quase que totalmente das configurações específicas do site. Os dumps podem não ser criados, ou podem ser criados em locais diferentes daqueles mencionados nas seções a seguir.

Dumps do MVS

Quando um programa está em execução no MVS, verifique os arquivos de dump do sistema e verifique a JCL em busca das seguintes instruções DD (dependendo do produto):

Consulte o MVS JCL Reference (SA22-7597) e o Language Environment Debugging Guide (GA22-7560) para obter informações adicionais sobre essas instruções DD.

Dumps de Java

No z/OS UNIX, a maioria dos dumps do Developer for System z é controlada pela Java Virtual Machine (JVM).

A JVM cria um conjunto de agentes de dump por padrão, durante a inicialização (SYSTDUMP e JAVADUMP). Você pode sobrepor este conjunto de agentes de dump utilizando a variável de ambiente JAVA_DUMP_OPTS e sobrepor o conjunto pelo uso de -Xdump na linha de comandos. As opções da linha de comandos JVM são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars. Não altere nenhuma configuração de dump, a menos que tenha sido solicitado pelo IBM Support Center.

Nota: A opção -Xdump:what na linha de comandos pode ser usada para determinar quais agentes de dump existem na conclusão da inicialização.

Os tipos de dump que podem ser produzidos são os seguintes:

SYSTDUMP
Dump de transação Java. Um dump de armazenamento não-formatado gerado pelo z/OS.

O dump é gravado em um conjunto de dados MVS sequencial utilizando-se um nome padrão no formato %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S, ou conforme determinado pela configuração da variável de ambiente JAVA_DUMP_TDUMP_PATTERN.

Nota: JAVA_DUMP_TDUMP_PATTERN permite o uso de variáveis, que são convertidas em um valor real na hora em que o dump de transação é obtido.
Tabela 38. Variáveis de JAVA_DUMP_TDUMP_PATTERN
Variável Uso
%uid ID do usuário
%job Nome da tarefa
%y Ano (2 dígitos)
%m Mês (2 dígitos)
%d Dia (2 dígitos)
%H Hora (2 dígitos)
%M Minuto (2 dígitos)
%S Segundo (2 dígitos)
CEEDUMP
Dump do LE (Language Environment). Um dump do sistema de resumo formatado que mostra rastreios de pilha para cada encadeamento que está no processo JVM, junto com informações de registro e um dump curto de armazenamento para cada registro.

O dump é gravado em um arquivo z/OS UNIX chamado CEEDUMP.aaaammdd.hhmmss.pid, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.

HEAPDUMP
Um dump formatado (uma lista) dos objetos que estão no heap Java.

O dump é gravado em um arquivo z/OS UNIX chamado HEAPDUMP.aaaammdd.hhmmss.pid.TXT, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.

Note que o Developer for System z fornece um comando do operador para acionar este dump. Consulte o capítulo "Comandos do Operador" no Guia de Configurações do Host (SC23-7658) para obter mais detalhes.

JAVADUMP
Uma análise formatada da JVM. Contém informações de diagnóstico relacionadas à JVM e ao aplicativo Java, como o ambiente de aplicativos, encadeamentos, pilha nativa, bloqueios e memória.

O dump é gravado em um arquivo z/OS UNIX chamado JAVADUMP.aaaammdd.hhmmss.pid.TXT, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.

Note que o Developer for System z fornece um comando do operador para acionar este dump. Consulte o capítulo "Comandos do Operador" no Guia de Configurações do Host (SC23-7658) para obter mais detalhes.

Consulte o Java Diagnostic Guide (SC34-6358) para obter informações adicionais sobre dumps de JVM e o Language Environment Debugging Guide (GA22-7560) para obter informações específicas de LE.

Locais de Dump do z/OS UNIX

A JVM verifica a existência de cada um dos seguintes locais e as permissões de gravação e armazena os arquivos CEEDUMP, HEAPDUMP e JAVADUMP no primeiro local disponível. Observe que você deve possuir espaço em disco livre suficiente para que o arquivo de dump seja gravado corretamente.

  1. O diretório na variável de ambiente _CEE_DMPTARG, se localizado. Essa variável está configurada em rsed.envvars como /tmp. Ela pode ser alterada para /dev/null para evitar a criação de arquivos dump.
  2. O diretório de trabalho atual, se o diretório não for o diretório raiz (/) e se o diretório for gravável.
  3. O diretório na variável de ambiente TMPDIR (uma variável de ambiente que indica o local de um diretório temporário se ele não for /tmp), se localizado.
  4. O diretório /tmp.
  5. Se o dump não puder ser armazenado em nenhum dos locais mencionados anteriormente, ele será colocado em stderr.

Rastreio

rastreio do JES Job Monitor

O rastreio do JES Job Monitor é controlado pelo operador do sistema, conforme descrito em "Comandos do operador" no Guia de Configuração do Host (SC23-7658).

rastreio RSE

Há vários arquivos de log criados pelos componentes relacionados ao RSE. A maioria está localizada em userlog/$LOGNAME/, em que userlog é o valor combinado das diretivas user.log eDSTORE_LOG_DIRECTORY em rsed.envvars, e $LOGNAME é o ID do usuário de logon (em maiúsculas). Se a diretiva user.log for comentada ou não estiver presente, o caminho inicial do usuário será usado. O caminho inicial é definido no segmento de segurança OMVS do ID de usuário. Se a diretiva DSTORE_LOG_DIRECTORY for comentada ou não estiver presente, então .eclipse/RSE/ será anexado ao valor user.log.

A quantidade de dados gravados em ffs*.log, lock.log e rsecomm.log é controlada pelo comando do operador modify rsecommlog ou pela configuração de debug_level in rsecomm.properties. Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) e "(Opcional) Rastreio RSE" no Guia de Configuração do Host (SC23-7658) para obter detalhes adicionais.

A criação dos arquivos de log .dstore* é controlada pelas opções de inicialização -DDSTORE_* Java, conforme descrito em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).

Nota:
  • O diretório .eclipse e os arquivos de log .dstore* começam com um ponto (.), o que os torna ocultos. Use o comando ls -lA do z/OS UNIX para listar arquivos e diretórios ocultos. Ao usar o cliente Developer for System z, selecione a página de preferências Janela > Preferências... > Sistemas Remotos > Arquivos e ative "Mostrar arquivos ocultos".
  • Os arquivos de log .dstore* são criados em ASCII. Use o comando do z/OS UNIX, iconv -f ISO8859-1 -t IBM-1047 .dstore*, para exibi-los no EBCDIC (ao usar a página de códigos IBM-1047).
  • Diferente dos arquivos *.log, os arquivos de log do .dstore* não são removidos automaticamente na reconexão do cliente. A remoção desses arquivos é uma ação manual.

Os arquivos de log específicos do daemon RSE e do conjunto de encadeamentos do RSE estão localizados em daemon-home, em que daemon-home é o valor da diretiva daemon.log em rsed.envvars. Se a diretiva daemon.log for comentada ou não estiver presente, o diretório inicial do ID do usuário designado à tarefa iniciada RSED será usado. O diretório inicial é definido no segmento de segurança OMVS do ID do usuário.

A quantidade de dados gravada em rsedaemon.log e em rseserver.log é controlada pelos comandos do operador modify rsedaemonlog e modify rseserverlog ou configurando debug_level em rsecomm.properties . Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) e "(Opcional) Rastreio RSE" no Guia de Configuração do Host (SC23-7658) para obter detalhes adicionais.

serverlogs.count, stderr.*.log e stdout.*.log são criados apenas se a diretiva enable.standard.log em rsed.envvars estiver ativa, ou se a função for dinamicamente ativada com o comando do operador modify rsestandardlog on.

rastreio CARMA

O usuário pode controlar a quantidade de informações de rastreio que o CARMA gera configurando o Nível de Rastreio na guia de propriedades da conexão CARMA no cliente. As opções para o Nível de Rastreio são:

O valor-padrão é o seguinte:

Log de Erros

Consulte Arquivos de Log para obter informações adicionais sobre as localizações do arquivo de log.

Rastreio de feedback de erro

O procedimento a seguir permite reunir informações necessárias para diagnosticar problemas de feedback de erro com procedimentos de construção remota. Esse rastreio causará diminuição no desempenho e deverá ser realizado somente sob a orientação do IBM Support Center. Todas as referências a hlq neste seção referem-se ao qualificador de alto nível usado durante a instalação do Developer for System z. O padrão da instalação é FEK, mas isto talvez não se aplique ao seu site.

  1. Faça uma cópia de backup do procedimento de compilação ELAXFCOC ativo. Este procedimento é enviado por padrão no conjunto de dados hlq.SFEKSAMP, mas pode ter sido copiado para um local diferente (por exemplo, SYS1.PROCLIB), conforme descrito em "Procedimentos de construção remota ELAXF*" no Guia de Configuração do Host (SC23-7658).
  2. Altere o procedimento ELAXFCOC ativo para incluir a cadeia 'MAXTRACE' na opção de compilação EXIT(ADEXIT(ELAXMGUX)).
    //COBOL  EXEC PGM=IGYCRCTL,REGION=2048K,
    //*            PARM=('EXIT(ADEXIT(ELAXMGUX))',
    //             PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))',
    //             'ADATA',
    //             'LIB',
    //             'TEST(NONE,SYM,SEP)',
    //             'LIST',
    //             'FLAG(I,I)'&CICS &DB2 &COMP)
    Nota: É necessário duplicar os apóstrofos em MAXTRACE. A opção agora é: EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX)).
  3. Execute uma Verificação de Sintaxe Remota no programa COBOL para o qual você deseja rastreio detalhado.
  4. A parte SYSOUT da saída JES começará listando os nomes dos conjuntos de dados para SIDEFILE1, SIDEFILE2, SIDEFILE3 e SIDEFILE4.
    ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
    SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
    ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
    SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
    ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
    SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
    ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
    SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
    Nota: Dependendo das suas configurações, SIDEFILE1 e SIDEFILE2 podem estar apontando para uma instrução DD (SUCCESSFUL OPEN SIDEFILE1 - NAME = DD:WSEDSF1). Consulte a parte JESJCL da saída (localizada antes da parte SYSOUT) para obter o nome real do conjunto de dados.
           22 //COBOL.WSEDSF1 DD DISP=MOD,
              // DSN=uid.ERRCOB.member.SF.Z682746.XML
           23 //COBOL.WSEDSF2 DD DISP=MOD,
              // DSN=uid.ERRCOB.member.SF.Z682747.XML
  5. Copie esses quatro conjuntos de dados em seu PC, por exemplo, criando um projeto COBOL local no Developer for System z e incluindo os conjuntos de dados SIDEFILE1->4.
  6. Copie o log da tarefa do JES completo em seu PC, por exemplo, abrindo a saída de tarefas no Developer for System z e salvando-a no projeto local selecionando Arquivo > Salvar Como ....
  7. Restaure o procedimento ELAXFCOC para o estado original, desfazendo a alteração (remova a cadeia ''MAXTRACE'' nas opções de compilação) ou restaurando o backup.
  8. Envie os arquivos coletados (SIDEFILE1->4 e log da tarefa) para o centro de suporte IBM.

Bits de permissão do z/OS UNIX

O Developer for System z requer que o sistema de arquivo z/OS UNIX e alguns arquivos z/OS UNIX tenham certos bits de permissão configurados.

atributo do sistema de arquivos SETUID

O Explorador de Sistema Remoto (RSE) é o componente do Developer for System z que fornece serviços principais, como conectar o cliente ao host. Ele deve ter permissão para executar tarefas como criar o ambiente de segurança do usuário.

O sistema de arquivos (HFS ou zFS) em que o Developer for System z está instalado deve ser montado com o bit de permissão SETUID ativado (este é o padrão do sistema). A montagem do sistema de arquivo com o parâmetro NOSETUID impedirá o Developer for System z de criar o ambiente de segurança do usuário e falhará no pedido de conexão. Outros indicadores para este problema de configuração são:

Erros semelhantes (tais como as mensagens BPXP014I e BPXP015I) podem ser esperados se os sistemas de arquivos que hospedam binários de Java ou z/OS UNIX são montados com o parâmetro NOSETUID.

Use o comando TSO ISHELL para listar o status atual do bit SETUID. No painel ISHELL, selecione Sistemas_de_arquivos > 1. Montar tabela... para listar os sistemas de arquivos montados. O comando da linha a mostrará os atributos para o sistema de arquivos selecionado, em que o campo "Ignorar SETUID" deve ser 0.

Autorização de controle de programa

O Explorador de Sistema Remoto (RSE) é o componente do Developer for System z que fornece serviços principais, como conectar o cliente ao host. Ele deve executar o programa controlado para realizar tarefas como a comutação para o ID do usuário do cliente.

O bit de controle de programa do z/OS UNIX é configurado durante a instalação do SMP/E onde necessário, exceto para a interface Java para seu produto de segurança, conforme documentado no Capítulo 2. Considerações de segurança. Este bit de permissão pode se perder caso você não o tenha preservado durante uma cópia manual dos diretórios Developer for System z.

Os seguintes arquivos do Developer for System z devem ser controlados pelo programa:

Use o comando do z/OS UNIX, ls -E, para listar os atributos estendidos, em que o bit de controle de programa é marcado com a letra p, conforme exibido na amostra a seguir ($ é o prompt do z/OS UNIX):

$ cd /usr/lpp/rdz
$ ls -E lib/fekf*
-rwxr-xr-x  -ps-  2 user     group      94208 Jul  8 12:31 lib/fekfdir.dll

Use o comando extattr +p do z/OS UNIX para configurar o bit de controle de programa manualmente, conforme exibido na seguinte amostra ($ e # são o prompt do z/OS UNIX):

$ cd /usr/lpp/rdz
$ su
# extattr +p lib/fekf*
# exit
$ ls -E lib/fekf*
-rwxr-xr-x  -ps-  2 user     group      94208 Jul  8 12:31 lib/fekfdir.dll
Nota: Para utilizar o comando extattr +p, você deve ter pelo menos acesso de LEITURA ao perfil BPX.FILEATTR.PROGCTL na classe FACILITY do software de segurança ou ser um superusuário (UID 0) se esse perfil não estiver definido. para obter informações adicionais, consulte UNIX System Services Planning (GA22-7800).

Autorização APF

O Explorador de Sistema Remoto (RSE) é o componente do Developer for System z que fornece serviços principais, como conectar o cliente ao host. Ele deve executar autorizado pelo APF a fim de executar tarefas como exibir uso de recurso de processo detalhado.

O bit APF z/OS UNIX é definido durante a instalação do SMP/E onde necessário. Este bit de permissão pode se perder caso você não o tenha preservado durante uma cópia manual dos diretórios Developer for System z.

Os arquivos do Developer for System z a seguir devem ser autorizados pelo APF:

Use o comando do z/OS UNIX, ls -E, para listar os atributos estendidos, em que o bit APF é marcado com a letra a, conforme exibido na amostra a seguir ($ é o prompt do z/OS UNIX):

$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x  aps-  2 user     group     114688 Sep 17 06:41 bin/fekfrivp

Use o comando extattr +a do z/OS UNIX para configurar o bit APF manualmente, conforme exibido na amostra a seguir ($ e # são os prompts do z/OS UNIX):

$ cd /usr/lpp/rdz
$ su
# extattr +a bin/fekfrivp
# exit
$ ls -E bin/fekfrivp
-rwxr-xr-x  aps-  2 user     group     114688 Sep 17 06:41 bin/fekfrivp
Nota: Para que seja possível usar o comando extattr +a, você deve ter ao menos o acesso de LEITURA no perfil BPX.FILEATTR.APF na classe FACILITY do seu software de segurança ou ser um superusuário (UID 0), caso este perfil não esteja definido. para obter informações adicionais, consulte UNIX System Services Planning (GA22-7800).

Sticky Bit

Alguns dos serviços opcionais do Developer for System z requerem que os módulos de carregamento do MVS estejam disponíveis para o z/OS UNIX. Isso é feito ao criar um stub (um arquivo fictício) no z/OS UNIX com o bit "sticky" ativado. Quando o stub é executado, o z/OS UNIX procurará um módulo de carregamento MVS com o mesmo nome e executará o módulo de carregamento em vez disso.

O sticky bit do z/OS UNIX é configurado durante a instalação do SMP/E onde necessário. Esses bits de permissão podem ser perdidos se você não os preservou durante uma cópia manual dos diretórios do Developer for System z.

Os arquivos do Developer for System z a seguir devem ter o sticky bit em:

Use o comando ls -l do z/OS UNIX para listar as permissões, em que o sticky bit é marcado com a letra t, conforme exibido na seguinte amostra ($ é o prompt do z/OS UNIX):

$ cd /usr/lpp/rdz
$ ls -l bin/CRA*
-rwxr-xr-t   2 user     group         71 Jul  8 12:31 bin/CRASTART

Utilize o comando chmod +p do z/OS UNIX para configurar o sticky bit manualmente, conforme exibido na seguinte amostra ($ e # é o prompt do z/OS UNIX):

$ cd /usr/lpp/rdz
$ su
# chmod +t bin/CRA*
# exit
$ ls -l bin/CRA*
-rwxr-xr-t   2 user     group         71 Jul  8 12:31 bin/CRASTART
Nota: Para poder utilizar o comando chmod, você deve ter pelo menos o acesso READ ao perfil SUPERUSER.FILESYS.CHANGEPERMS na classe UNIXPRIV do software de segurança ou ser um superusuário (UID 0) se esse perfil não estiver definido. para obter informações adicionais, consulte UNIX System Services Planning (GA22-7800).

Portas TCP/IP reservadas

Com o comando netstat (TSO ou z/OS UNIX), você pode obter uma visão geral das portas atualmente em uso. A saída desse comando será semelhante ao exemplo a seguir. As portas usadas são o último número (atrás de "..") na coluna "Soquete Local". Como estas portas já estão em uso, elas não podem ser usadas para a configuração do Developer for System z.

IPv4

MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP           16:36:42
User Id  Conn     Local Socket           Foreign Socket         State
-------  ----     ------------           --------------         -----
BPXOINIT 00000014 0.0.0.0..10007         0.0.0.0..0             Listen
INETD4   0000004D 0.0.0.0..512           0.0.0.0..0             Listen
RSED     0000004B 0.0.0.0..4035          0.0.0.0..0             Listen
JMON     00000038 0.0.0.0..6715          0.0.0.0..0             Listen
 

IPv6

MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP           12:46:25
User Id  Conn     State
-------  ----     -----
BPXOINIT 00000018 Listen
  Local Socket:   0.0.0.0..10007
  Foreign Socket: 0.0.0.0..0
INETD4   00000046 Listen
  Local Socket:   0.0.0.0..512
  Foreign Socket: 0.0.0.0..0
RSED     0000004B Listen
  Local Socket:   0.0.0.0..4035
  Foreign Socket: 0.0.0.0..0
JMON     00000037 Listen
  Local Socket:   0.0.0.0..6715
  Foreign Socket: 0.0.0.0..0

Outra limitação que pode existir são as portas TCP/IP reservadas. Há os dois lugares comuns a seguir para reservar as portas TCP/IP:

Estas portas reservadas podem ser listadas com o comando netstat portl (TSO ou z/OS UNIX), que cria uma saída como esta do exemplo a seguir:

MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP           17:08:32
Port# Prot User     Flags    Range       IP Address
----- ---- ----     -----    -----       ----------
00007 TCP  MISCSERV DA
00009 TCP  MISCSERV DA
00019 TCP  MISCSERV DA
00020 TCP  OMVS     D
00021 TCP  FTPD1    DA
00025 TCP  SMTP     DA
00053 TCP  NAMESRV  DA
00080 TCP  OMVS     DA
03500 TCP  OMVS     DAR      03500-03519
03501 TCP  OMVS     DAR      03500-03519

Consulte Communications Server: IP System Administrator’s Commands (SC31-8781) para obter informações adicionais sobre o comando NETSTAT.

Nota: O comando NETSTAT mostra somente as informações definidas em PROFILE.TCPIP, que devem sobrepor as definições de BPXPRMxx. Em caso de dúvidas ou problemas, verifique o membro parmlib de BPXPRMxx para verificar as portas sendo reservadas aqui.

Tamanho do espaço de endereço

O daemon RSE, que é um processo z/OS UNIX Java, exige um tamanho de região grande para executar suas funções. Portanto, é importante definir limites de armazenamento grandes para espaços de endereço do OMVS.

Requisitos da JCL de Inicialização

O daemon RSE é iniciado pela JCL utilizando BPXBATSL, cujo tamanho da região deve ser 0.

Limitações Definidas em SYS1.PARMLIB(BPXPRMxx)

Configure MAXASSIZE em SYS1.PARMLIB(BPXPRMxx), que define o tamanho da região do espaço de endereço (processo) do OMVS como 2G. Esse é o tamanho máximo permitido. Esse é um limite amplo do sistema e, dessa forma, ativo em todos os espaços de endereço do z/OS UNIX. Se não for desejado, será possível configurar o limite também apenas para o Developer for System z em seu software de segurança.

Esse valor pode ser verificado e configurado dinamicamente (até o próximo IPL) com os seguintes comandos de console, conforme descrito em MVS System Commands (GC28-1781):

  1. DISPLAY OMVS,O
  2. SETOMVS MAXASSIZE=2G

Limitações Armazenadas no Perfil de Segurança

Verifique ASSIZEMAX no segmento OMVS do ID do usuário do daemon e configure-o como 2147483647 ou, de preferência, como NONE para utilizar o valor SYS1.PARMLIB(BPXPRMxx).

Utilizando RACF, esse valor pode ser verificado e configurado com os seguintes comandos TSO, conforme descrito em Security Server RACF Command Language Reference (SA22-7687):

  1. LISTUSER userid NORACF OMVS
  2. ALTUSER userid OMVS(NOASSIZEMAX)

Limitações Impostas por Saídas do Sistema

Certifique-se de não permitir que saídas do sistema IEFUSI ou IEALIMIT controlem os tamanhos de regiões de espaços de endereços OMVS. Uma forma possível de fazer isso é pela codificação de SUBSYS(OMVS,NOEXITS) em SYS1.PARMLIB(SMFPRMxx).

Os valores SYS1.PARMLIB(SMFPRMxx) podem ser verificados e ativados com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):

  1. DISPLAY SMF,O
  2. SET SMF=xx

Limitações para Endereçamento de 64 Bits

A palavra-chave MEMLIMIT em SYS1.PARMLIB(SMFPRMxx) limita o quanto uma tarefa de armazenamento virtual de 64 bits pode alocar acima da barra de 2GB. Ao contrário do parâmetro REGION no JCL, o MEMLIMIT=0M significa que o processo não pode usar o armazenamento virtual acima da barra.

Se o MEMLIMIT não estiver especificado em SMFPRMxx, o valor-padrão será 0M, assim as tarefas serão limitadas ao (31 bits) 2GB abaixo da barra. O padrão alterado no z/OS 1.10 para 2G, permitindo que as tarefas de 64 bits usem até 4GB (os 2GB abaixo da barra e os 2GB acima da barra concedidos por MEMLIMIT).

Os valores SYS1.PARMLIB(SMFPRMxx) podem ser verificados e ativados com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):

  1. DISPLAY SMF,O
  2. SET SMF=xx

O MEMLIMIT também pode ser especificado como parâmetro na placa EXEC no JCL. Se nenhum parâmetro MEMLIMIT estiver especificado, o padrão será o valor definido para SMF, exceto quando o REGION=0M estiver especificado, em tal caso o padrão será NOLIMIT.

Informações Variadas

Encerramento Anormal por Falta de Espaço B37 de Feedback de Erro

Quando um usuário seleciona o feedback de erro durante uma ação de compilação, vários conjuntos de dados temporários são criados pelo Developer for System z. Quando um desses conjuntos de dados tem falta de espaço, as tarefas de compilação terminam com um encerramento anormal por falta de espaço B37-04.

Ajuste a alocação de espaço em FEK.SFEKPROC(FEKFERRF) quando os usuários tiverem esse problema. O valor padrão é SPACE(200,40) TRACKS.

Limites do sistema

SYS1.PARMLIB(BPXPRMxx) define muitas limitações relacionadas ao z/OS UNIX, que pode ser acessado quando muitos clientes do Developer for System z estão ativos. A maioria dos valores de BPXPRMxx pode ser alterada dinamicamente com os comandos do console SETOMVS e SET OMVS.

Use o comando do console SETOMVS LIMMSG=ALL para que o z/OS UNIX exiba mensagens do console (BPXI040I) quando qualquer dos limites BPXPRMxx estiver prestes a ser atingido.

Conexão recusada

Cada conexão RSE inicia diversos processos que são permanentemente ativos. Novas conexões podem ser recusadas devido ao limite configurado em SYS1.PARMLIB(BPXPRMxx) na quantidade de processos, especialmente quando os usuários compartilham o mesmo UID (como ao utilizar o segmento OMVS padrão).

Outra origem de conexões recusadas é o limite da quantidade de espaços de endereço do z/OS e de usuários do z/OS UNIX ativos.

OutOfMemoryError

Um conjunto de encadeamentos do RSE pode falhar com uma mensagem OutOfMemoryError sendo registrada. Esse erro está relacionado ao tamanho do heap Java e pode ocorrer se os usuários ativos deste conjunto de encadeamentos usarem mais recursos do que o esperado. As causas comuns desse erro são as seguintes:

Para resolver esse problema, é possível fazer o seguinte:

Emulador de Conexão do Host

Capítulo 13. Configurando o SSL e a Autenticação X.509

Este apêndice é fornecido para ajudar você com alguns dos problemas comuns que você pode encontrar ao configurar Secure Socket Layer (SSL) ou durante a verificação ou modificação de uma configuração existente. Este apêndice também fornece uma configuração de amostra para dar suporte aos usuários se autenticando com um certificado X.509.

Comunicação segura significa garantir que seu parceiro de comunicação seja o que alega ser e transmitir informações de forma que dificulte a interceptação e leitura dos dados por terceiros. O SSL fornece essa capacidade em uma rede TCP/IP. Funciona utilizando certificados digitais para se identificar e um protocolo de chave pública para criptografar a comunicação. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre certificados digitais e o protocolo de chave pública usados pelo SSL.

As ações necessárias para configurar as comunicações SSL para o Developer for System z variam de site para site, dependendo das necessidades exatas, do método de comunicação RSE usado e do que já está disponível no site.

Neste apêndice, clonaremos as definições de RSE atuais para que tenhamos uma 2a conexão do daemon RSE que utilizará SSL. Também criaremos nossos próprios certificados de segurança a serem usados pelas diferentes partes da conexão RSE.

Todo este apêndice apresenta uma convenção de nomenclatura uniforme:

Algumas tarefas descritas nas seções a seguir esperam que você esteja ativo no z/OS UNIX. Isso pode ser feito emitindo o comando do TSO OMVS. Use o comando exit para retornar ao TSO.

Decida Usar o SSL ou TLS Como o Método de Criptografia

A variável DSTORE_SSL_ALGORITHM na diretiva _RSE_JAVAOPTS de rsed.envvars permite escolher entre o SSL e sua Segurança da Camada de Transporte (TLS) sucessora como o método de criptografia, conforme documentado em "Definindo Parâmetros de Inicialização Java Extra com o _RSE_JAVAOPTS" no Guia de Configuração do Host (S517-9094).

Decidir Onde Armazenar Chaves Privadas e Certificados

Os certificados de identidade e as chaves de criptografia/descriptografia usadas pelo SSL são armazenados em um arquivo de chaves. Existem diferentes implementações deste arquivo de chaves, dependendo do tipo de aplicativo.

No entanto, todas as implementações seguem o mesmo princípio. Um comando gera um par de chaves (uma chave pública e uma chave privada associada). O comando agrupa então a chave pública em um certificado X.509 auto-assinado, que é armazenado como uma cadeia de certificados de elemento único. Essa cadeia de certificados e a chave privada são armazenadas como uma entrada (identificada por um alias) em um arquivo-chave.

O daemon RSE é um aplicativo SSL do Sistema e utiliza um arquivo de banco de dados de chaves. Esse banco de dados de chaves pode ser um arquivo físico criado por gskkyman ou um conjunto de chaves gerenciado pelo seu software de segurança compatível com SAF (por exemplo, RACF). O servidor RSE (que é iniciado pelo daemon) é um aplicativo Java SSL e usa um arquivo keystore criado por keytool ou um conjunto de chaves gerenciado pelo seu software de segurança.

Tabela 39. Mecanismos de armazenamento de certificado SSL
Armazenamento de certificado Criado e gerenciado por Daemon RSE Servidor RSE
conjunto de chaves Produto de segurança compatível com SAF suportados suportados
banco de dados de chaves gskkyman do z/OS UNIX suportados /
keystore keytool do Java / suportados

Para conectar por meio de SSL, é necessário o keystore e o banco de dados principal, como um arquivo z/OS UNIX ou um conjunto de chaves compatível com SAF:

Nota:
  • Conjuntos de chaves compatíveis com SAF é o método preferido para gerenciar certificados.
  • Um certificado compartilhado poderá ser usado se o daemon RSE e o servidor RSE usarem o mesmo método de gerenciamento de certificado.
  • O daemon RSE deve ser executado controlado pelo programa. O uso do SSL do Sistema implica que SYS1.SIEALNKE deve se tornar controlado pelo programa pelo software de segurança.
  • Para executar um aplicativo SSL do Sistema (conexão daemon), o SYS1.SIEALNKE deve estar em LINKLIST ou em STEPLIB. Se você preferir o método STEPLIB, inclua a seguinte instrução no fim de rsed.envvars.
    STEPLIB=$STEPLIB:SYS1.SIEALNKE

    Porém, lembre-se de que:

    • A utilização de STEPLIB no z/OS UNIX tem um impacto de desempenho negativo.
    • Se uma biblioteca STEPLIB for autorizada pelo APF, todas serão autorizadas. As bibliotecas perderão sua autorização do APF se forem combinadas com as bibliotecas no STEPLIB não autorizadas.
  • O SSL do Sistema utiliza o ICSF (Integrated Cryptographic Service Facility), se estiver disponível. O ICSF oferece suporte criptográfico a hardware que será usado, em vez de algoritmos de software do SSL do Sistema. Consulte System SSL Programming (SC24-5901) para obter informações adicionais.

Consulte Security Server RACF Security Administrator’s Guide (SA22-7683) para obter informações sobre RACF e caracteres digitais. A documentação de gskkyman pode ser localizada em System SSL Programming (SC24-5901) e a documentação de keytool está disponível em http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.

Criar um Conjunto de Chaves com o RACF

Não execute esta etapa se utilizar o gskkyman para criar o banco de dados de chaves do daemon RSE e o keytool para criar o keystore do servidor RSE.

O comando RACDCERT instala e mantém chaves privadas e certificados no RACF. O RACF suporta várias chaves privadas e certificados para serem gerenciados como um grupo. Esses grupos são chamados anéis de chave.

Consulte Security Server RACF Command Language Reference (SA22-7687) para obter detalhes sobre o comando RACDCERT.

RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
SETROPTS RACLIST(FACILITY) REFRESH

RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') +
  OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) +
  NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE)

RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) +
  DEFAULT USAGE(PERSONAL))

A amostra anterior inicia criando os perfis necessários e permitindo que o ID de usuário STCRSE acesse os conjuntos de chaves e os certificados pertencentes a esse ID de usuário. O ID do usuário usado deve corresponder ao ID do usuário usado para executar o daemon do RSE SSL. A próxima etapa é criar um novo certificado auto-assinado com rótulo rdzrse. Não é necessária senha. Esse certificado é incluído em um anel de chaves recém-criado (rdzssl.racf). Assim como com o certificado, não é necessária senha para o anel de chave.

O resultado pode ser verificado com a seguinte opção list:

RACDCERT ID(stcrse) LIST
Informações do certificado digital para o usuário STCRSE:

 Rótulo: rdzrse
 ID do Certificado: 2QjW1OXi0sXZ1aaEqZmihUBA
 Status: TRUST
 Data de Início: 24/05/2007 0h
 Data de Encerramento:   21/05/2017 23h59min59s
 Número de Série:
      >00<
 Nome do Emissor:
      >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
 Nome do Assunto:
      >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
 Tipo de Chave Privada: Não-ICSF
 Tamanho da Chave Privada: 1024
 Associações de Anel:
   Proprietário do Anel: STCRSE
   Anel:
      >rdzssl.racf<

(Opcional) Usando um Certificado Assinado

Os certificados podem ser auto-assinados ou assinados por uma Autoridade de Certificação (CA). Um certificado assinado por uma CA significa que a CA garante que o proprietário do certificado é quem afirma ser. O processo de assinatura inclui as credenciais de CA (também um certificado) no certificado, tornando-o uma cadeia de certificados com vários elementos.

Ao usar um certificado assinado por uma CA, você pode evitar perguntas sobre validação confiável pelo cliente do Developer for System z, se o cliente já confiar na CA.

Siga estas etapas para criar e utilizar um certificado assinado pela CA:

  1. Crie um certificado autoassinado.
    RACDCERT ID(stcrse) GENCERT WITHLABEL('rdzrse') . . .
  2. Crie um pedido de assinatura para este certificado.
    RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
  3. Envie o pedido de assinatura para a CA de sua escolha.
  4. Verifique se as credenciais de CA (também um certificado) já são conhecidas.
    RACDCERT CERTAUTH LIST
  5. Marque o certificado de CA como confiável.
    RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST

    Ou inclua o certificado de CA no banco de dados.

    RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
  6. Inclua o certificado assinado no banco de dados; ele substituirá o auto-assinado.
    RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
    Nota: NÃO exclua o certificado auto-assinado antes de substituí-lo. Se você fizer isso, perderá a chave privada fornecida com o certificado, inutilizando-o.
  7. Crie um conjunto de chaves.
    RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
  8. Inclua o certificado assinado no conjunto de chaves.
    RACDCERT ID(stcrse) CONNECT(ID(stcrse) LABEL('rdzrse') 
    RING(rdzssl.racf))
  9. Inclua o certificado de CA no conjunto de chaves.
    RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') 
    RING(rdzssl.racf))

Observe que o certificado CA usado para assinar seu certificado pode, por sua vez, também ser assinado por outro certificado CA, de nível mais alto. Se isso acontecer, o certificado CA de nível mais alto também deverá ser incluído no conjunto de chaves. Esse processo se repete até que o certificado CA de nível mais alto seja um certificado CA raiz, que é sempre um certificado autoassinado.

Clonar a Configuração RSE Existente

Nesta etapa, uma nova instância dos arquivos de configuração do RSE é criada, para que a configuração SSL possa ser executada paralelamente com a(s) existente(s). Os comandos de amostra a seguir esperam que os arquivos de configuração estejam em /etc/rdz/, que é o local padrão usado em "Configuração de customização" no Guia de Configuração do Host (SC23-7658).

$ cd /etc/rdz
$ mkdir ssl
$ cp rsed.envvars ssl
$ cp ssl.properties ssl
$ ls ssl
rsed.envvars    ssl.properties

Os comandos do z/OS UNIX listados no exemplo anterior criam um subdiretório chamado ssl e o preenchem com os arquivos de configuração que precisam de mudanças. Podemos compartilhar os outros arquivos de configuração, o diretório de instalação e os componentes do MVS, porque não são específicos do SSL.

Ao reutilizar a maioria dos arquivos de configuração existentes, podemos nos concentrar nas alterações realmente necessárias para configurar o SSL e evitar fazer a configuração completa do RSE novamente. (Por exemplo, podemos evitar a definição de um novo local para ISPF.conf.)

Atualizar rsed.envvars para Ativar a Coexistência

Até agora, as definições são uma cópia exata da configuração atual, o que implica que os logs do novo daemon RSE sobreporão os arquivos de log atuais do servidor. O RSE também precisa saber onde localizar os arquivos de configuração que não foram copiados para o diretório ssl. Os dois problemas podem ser tratados por mudanças secundárias em rsed.envvars.

$ oedit /etc/rdz/ssl/rsed.envvars
      -> change: _RSE_RSED_PORT=4047
      -> change: -Ddaemon.log=/var/rdz/logs/ssl
      -> change: -Duser.log=/var/rdz/logs/ssl
      -> add at the END:
         # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
         CFG_BASE=/etc/rdz
         CLASSPATH=.:$CFG_BASE:$CLASSPATH 
         # -- 

As mudanças no exemplo anterior definem um novo local de log (que será criado pelo daemon RSE se o local do log não existir). As mudanças também atualizam o CLASSPATH para que os processos RSE do SSL procurem arquivos de configuração primeiramente no diretório atual (/etc/rdz/ssl) e, em seguida, procurem no diretório original (/etc/rdz).

Atualizar ssl.properties para Ativar SSL

Atualizando ssl.properties, o RSE é orientado a iniciar o uso da comunicação criptografada por SSL.

$ oedit /etc/rdz/ssl/ssl.properties
      -> change: enable_ssl=true
      -> uncomment and change: daemon_keydb_file=rdzssl.racf
      -> uncomment and change: daemon_key_label=rdzrse
      -> uncomment and change: server_keystore_file=rdzssl.racf
      -> uncomment and change: server_keystore_label=rdzrse
      -> uncomment and change: server_keystore_type=JCERACFKS

As mudanças no exemplo anterior ativam o SSL e informam ao daemon RSE e ao servidor RSE que o certificado (compartilhado) deles está armazenado com o rótulo de rdzrse no conjunto de chaves rdzssl.racf. A palavra-chave JCERACFKS informa ao servidor RSE que um conjunto de chaves compatível com SAF é usado como keystore.

Observe que o SSL do Sistema (usado pelo daemon) sempre usa o ICSF, a interface com o hardware criptográfico System z, quando disponível. Para poder compartilhar as definições de daemon com o servidor usando o ICSF, especifique server_keystore_type JCECCARACFKS. Aqui, um conjunto de chaves compatível com SAF também é usado como armazenamento de chaves públicas, mas a chave privada é armazenada no ICSF. Conforme documentado no Cryptographic Services ICSF Administrator's Guide (SA22-7521), o ICSF usa perfis nas classes de segurança CSFKEYS e CSFSERV para controlar quem pode usar chaves e serviços criptográficos.

Ativar SSL Criando um Novo Daemon RSE

Conforme já mencionado, criaremos uma segunda conexão que utilizará SSL, o que significa a criação de um novo daemon do RSE. O daemon do RSE pode ser uma tarefa iniciada ou uma tarefa do usuário. O método de tarefa do usuário para configuração (teste) inicial será usado. s instruções a seguir esperam que a JCL de amostra esteja em FEK.#CUST.PROCLIB(RSED), que é o local padrão usado em "Configuração de customização" no Guia de Configuração do Host (SC23-7658):

  1. Crie um novo membro FEK.#CUST.PROCLIB(RSEDSSL) e copie na JCL de amostra FEK.#CUST.PROCLIB(RSED).
  2. Customize RSEDSSL incluindo uma placa de tarefa na parte superior e uma instrução exec na parte inferior. Forneça também o local dos arquivos de configuração relacionados a SSL (/etc/rdz/ssl), conforme descrito na seguinte amostra de código. Observe que forçamos o uso do ID de usuário STCRSE, pois esse ID de usuário recebeu a autoridade de acesso apropriada para certificados e conjuntos de chaves em uma etapa anterior.
Figura 30. RSEDSSL - Tarefa do usuário do daemon RSE para SSL
//RSEDSSL  JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE
//*
//* RSE DAEMON - SSL
//*
//RSED     PROC TMPDIR=,
//            PORT=,
//            IVP=,                   * 'IVP' to do an IVP test
//            CNFG='/etc/rdz/ssl',
//            HOME='/usr/lpp/rdz'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG -P&PORT -T&TMPDIR'  
//STDOUT   DD SYSOUT=*  
//STDERR   DD SYSOUT=*  
//         PEND 
//* 
//RSED     EXEC RSED 
//*

Nota: O ID de usuário designado à tarefa RSEDSSL deve ter as mesmas autorizações que o daemon RSE original. O perfil FACILITY BPX.SERVER e o perfil PTKTDATA IRRPTAUTH.FEKAPPL.* são elementos-chave aqui.

Testar a Conexão

A configuração do host SSL é completa e o daemon RSE para SSL pode ser iniciado ao enviar a tarefa FEK.#CUST.PROCLIB(RSEDSSL) criada anteriormente.

A nova configuração pode agora ser testada conectando-se com o cliente Developer for System z. Como criamos uma nova configuração para ser usada pelo SSL (clonando uma existente), uma nova conexão deverá ser definida no cliente utilizando-se a porta 4047 para o daemon RSE.

Na conexão, o host e o cliente começarão com alguma troca para configurar um caminho seguro. Parte dessa troca é o intercâmbio de certificados. Se o cliente Developer for System z não reconhecer o certificado do host ou a CA que o assinou, o cliente Developer for System z perguntará ao usuário se é possível confiar nesse certificado.

Figura 31. Diálogo Importar Certificado do Host
Importar Certificado do Host

Clicando no botão Concluir, o usuário pode aceitar esse certificado como confiável; depois disso, a inicialização da conexão continuará.

Nota: O daemon RSE e o servidor RSE podem utilizar dois locais de certificados diferentes, resultando em dois certificados diferentes e, portanto, em duas confirmações.

Quando um certificado é conhecido do cliente, esse diálogo não é mostrado novamente. A lista de certificados confiáveis pode ser gerenciada selecionando Janela > Preferências... > Sistemas Remotos > SSL, que mostra o seguinte diálogo:

Figura 32. Diálogo Preferências - SSL
preferências

Se a comunicação SSL falhar, o cliente retornará uma mensagem de erro. Informações adicionais estão disponíveis nos diferentes arquivos de log do servidor e do usuário, conforme descrito em Criação de Log de Daemon RSE e de Conjunto de Encadeamento e criação de logs do usuário do RSE.

(Opcional) Incluir Suporte de Autenticação de Cliente X.509

O daemon RSE suporta que os próprios usuários se autentiquem com um certificado X.509. Usar a comunicação criptografada SSL é um pré-requisito para essa função por ser uma extensão para a autenticação de host com um certificado usado no SSL.

Há várias maneiras de fazer a autenticação de certificado para um usuário, conforme descrito em Autenticação de cliente usando certificados X.509. As próximas etapas documentam a configuração necessária para suportar o método em que o software de segurança autentica o certificado utilizando a extensão de certificado HostIdMappings.

  1. Altere o certificado que identifica a Autoridade de Certificação (CA) usado para assinar o certificado do cliente para um certificado de CA altamente confiável. Embora o status TRUST seja suficiente para a validação de certificado, é feita uma mudança para HIGHTRUST por ser usado para a parte de autenticação de certificado do processo de logon.
    RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
  2. Inclua o certificado de CA no conjunto de chaves rdzssl.racf para que esteja disponível para validar os certificados de cliente.
    RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') +
      RING(rdzssl.racf))

    Isso conclui a configuração do software de segurança para o certificado de CA.

  3. Defina um recurso (formato IRR.HOST.hostname) na classe SERVAUTH para o nome do host, CDFMVS08.RALEIGH.IBM.COM, definido na extensão HostIdMappings do certificado do cliente.
    RDEFINE SERVAUTH  IRR.HOST.CDFMVS08.RALEIGH.IBM.COM  UACC(NONE)
  4. Conceda ao ID do usuário da tarefa iniciada do RSE, STCRSE, acesso a esse recurso com autoridade READ.
    PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM  CLASS(SERVAUTH) +
      ACCESS(READ) ID(stcrse)
  5. Ative suas mudanças para a classe SERVAUTH. Use o primeiro comando se a classe SERVAUTH ainda não estiver ativa. Use o segundo para atualizar uma configuração ativa.
    SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
    ou
    SETROPTS RACLIST(SERVAUTH) REFRESH

    Isso conclui a configuração do software de segurança para a extensão HostIdMappings.

  6. Reinicie a tarefa iniciada do RSE para começar a aceitar logons de clientes usando os certificados X.509.

(Opcional) Criar um Banco de Dados de Chaves com gskkyman

Não execute esta etapa se você usar um conjunto de chaves compatível com SAF para o banco de dados principal do daemon RSE.

gskkyman é um programa z/OS UNIX baseado em shell e orientado por menus, que cria, preenche e gerencia um arquivo z/OS UNIX que contém chaves privadas, pedidos de certificado e certificados. Esse arquivo z/OS UNIX é chamado de banco de dados de chaves.

Nota: As seguintes instruções podem ser necessárias para configurar o ambiente para gskkyman. Consulte System SSL Programming (SC24-5901) para obter mais informações sobre isso.
PATH=$PATH:/usr/lpp/gskssl/bin
export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH
export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl
$ gskkyman       Menu do Banco de Dados

   1 - Criar novo banco de dados
   
Digite o número da opção: 1
Digite o nome do banco de dados de chaves (pressione ENTER para retornar ao menu): rdzssl.kdb
Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl
Digite novamente a senha do banco de dados: rsessl
Digite a expiração da senha em dias (pressione ENTER para nenhuma expiração):
Digite o comprimento do registro do banco de dados (pressione ENTER para utilizar 2500):

Banco de dados de chaves /etc/rdz/ssl/rdzssl.kdb criado.

Pressione ENTER para continuar.

       Menu do Key Management

       6 - Criar um certificado auto-assinado
   
Digite o número da opção (pressione ENTER para retornar ao menu anterior): 6

       Tipo de Certificado

   5 - Certificado do usuário ou do servidor com chave RSA de 1024 bits
   
Selecione o tipo de certificado (pressione ENTER para retornar ao menu): 5
Digite o rótulo (pressione ENTER para retornar ao menu): rdzrse
Digite o nome do assunto para o certificado
  Nome comum (necessário): rdz rse ssl
  Unidade organizacional (opcional): rdz
  Organização (necessário): IBM
  Cidade/Localidade (opcional): Raleigh
  Estado/Província (opcional): NC
  País/Região (2 caracteres - necessário): US
Digite o número de dias que o certificado permanecerá válido (padrão 365): 3650

Digite 1 para especificar nomes alternativos de assunto ou 0 para continuar: 0

Aguarde .....

Certificado criado.

Pressione ENTER para continuar.

       Menu do Key Management

         0 - Sair do programa

Digite o número da opção (pressione ENTER para retornar ao menu anterior): 0
$ ls -l rdzssl.*
total 152
-rw-------   1 IBMUSER  SYS1       35080 May 24 14:24 rdzssl.kdb
-rw-------   1 IBMUSER  SYS1          80 May 24 14:24 rdzssl.rdb
$ chmod 644 rdzssl.*
$ ls -l rdzssl.*
-rw-r--r--   1 IBMUSER  SYS1       35080 May 24 14:24 rdzssl.kdb
-rw-r--r--   1 IBMUSER  SYS1          80 May 24 14:24 rdzssl.rdb

A amostra anterior inicia criando um banco de dados de chaves chamado rdzssl.kdb com a senha rsessl. Quando o banco de dados existir, ele será preenchido por meio da criação de um novo certificado auto-assinado, válido durante 10 anos (sem contar os dias extras). O certificado é armazenado com o rótulo rdzrse e com a mesma senha (rsessl) usada para o banco de dados de chaves (esse é um requisito do RSE).

gskkyman aloca o banco de dados de chaves com uma máscara de bits de permissão 600 (muito segura) (só o proprietário tem acesso). A menos que o daemon utilize o mesmo ID do usuário que o criador do banco de dados de chaves, as permissões devem ser configuradas menos restritivas. 644 (o proprietário tem leitura/gravação, todos têm leitura) é uma máscara útil para o comando chmod.

O resultado pode ser verificado ao selecionar a opção Mostrar Informações do Certificado no submenu Gerenciar Chaves e Certificados, como a seguir:

$ gskkyman

       Menu do Banco de Dados

   2 - Abrir banco de dados
   
Digite o número da opção: 2
Digite o nome do banco de dados de chaves (pressione ENTER para retornar ao menu): rdzssl.kdb
Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl

       Menu do Key Management

          1 - Gerenciar chaves e certificados
   
Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1

       Lista de Chaves e Certificados

          1 - rdzrse

   Digite o número do rótulo (ENTER para retornar ao menu de seleção, p para lista anterior: 1

       Menu Chave e Certificado

   1 - Mostrar informações do certificado
   
Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1

                        Informações do Certificado

                 Rótulo: rdzrse
             ID do Registro: 14
      ID do Registro do Emissor: 14
               Confiável: Sim
               Versão: 3
         Número serial: 45356379000ac997
           Nome do emissor: rdz rse ssl
                        rdz
                        IBM
                        Raleigh
                        NC
                                  Nome do assunto: rdz rse ssl
                        rdz
                        IBM
                        Raleigh
                        NC
                                Data de efetivação: 24/05/2007
       Data de expiração: 21/05/2017
  Algoritmo de chave pública: rsaEncryption
       Tamanho da chave pública: 1024
   Algoritmo de assinatura: sha1WithRsaEncryption
      ID exclusivo do emissor: Nenhum
     ID exclusivo do assunto: Nenhum
  Número de extensões: 3

Digite 1 para exibir extensões, 0 para retornar ao menu: 0

       Menu Chave e Certificado

     0 - Sair do programa

Digite o número da opção (pressione ENTER para retornar ao menu anterior): 0

A amostra ssl.properties a seguir mostra que as diretivas daemon_* são diferentes da amostra do conjunto de chaves SAF anterior.

$ oedit /etc/rdz/ssl/ssl.properties
      -> change: enable_ssl=true
      -> uncomment and change: daemon_keydb_file=rdzssl.kdb
      -> uncomment and change: daemon_keydb_password=rsessl
      -> uncomment and change: daemon_key_label=rdzrse
      -> uncomment and change: server_keystore_file=rdzssl.racf
      -> uncomment and change: server_keystore_label=rdzrse
      -> uncomment and change: server_keystore_type=JCERACFKS

As mudanças anteriores ativam o SSL e informam ao daemon RSE que o certificado está armazenado com o rótulo rdzrse no banco de dados de chaves rdzssl.kdb com a senha rsessl. O servidor RSE ainda está usando um conjunto de chaves compatível com SAF.

(Opcional) Criar um Keystore com keytool

Não execute esta etapa se você utilizar um conjunto de chaves compatível com SAF para o keystore do servidor RSE.

"keytool -genkey" gera um par de chaves privadas e um certificado auto-assinado correspondente que são armazenados como uma entrada (identificada por um alias) em um arquivo keystore (novo).

Nota: Java deve ser incluído nos diretórios de procura de comando. A instrução a seguir pode ser necessária para executar o keytool, em que /usr/lpp/java/J5.0 é o diretório em que Java está instalado: PATH=$PATH:/usr/lpp/java/J5.0/bin

Todas as informações podem ser transmitidas como um parâmetro, mas devido às limitações no comprimento da linha de comandos, será necessária uma certa interatividade, como a seguir:

$ cd /etc/rdz/ssl
$ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass
 rsessl -keypass rsessl
Qual é o seu nome e sobrenome?
  [Desconhecido]:  rdz rse ssl
Qual é o nome de sua unidade organizacional?
  [Desconhecido]:  rdz
Qual é o nome de sua organização?
  [Desconhecido]:  IBM
Qual é o nome de sua cidade ou localidade?
  [Desconhecido]:  Raleigh
Qual é o nome de seu estado ou província?
  [Desconhecido]:  NC
Qual é o código do país de duas letras para esta unidade?
  [Desconhecido]:  US
CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US está correto? (digite "sim"
ou "não")
  [não]:  sim
$ ls -l rdzssl.*
-rw-r--r--   1 IBMUSER  SYS1        1224 May 24 14:17 rdzssl.jks

O certificado autoassinado criado no exemplo anterior é válido durante aproximadamente 10 anos (não contando o dia 29 de fevereiro). Ele é armazenado em /etc/rdz/ssl/rdzssl.jks utilizando o alias rdzrse. Sua senha (rsessl) é idêntica à senha do armazenamento de chaves, que é um requisito para o RSE.

O resultado pode ser verificado com a opção -list, como a seguir:

$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v
Nome do alias: rdzrse
Data de criação: 24 de maio de 2007
Tipo de entrada: keyEntry
Comprimento da cadeia de certificados: 1
Certificado 1¨:
Proprietário: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Emissor: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Número serial: 46562b2b
Válido de: 24/5/07 14h17 até: 21/5/17 14h17
Impressões digitais do certificado:
         MD5:  9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80
         SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C

A amostra ssl.properties a seguir mostra que as diretivas server_* são diferentes da amostra do conjunto de chaves SAF anterior.

$ oedit /etc/rdz/ssl/ssl.properties
      -> change: enable_ssl=true
      -> uncomment and change: daemon_keydb_file=rdzssl.racf
      -> uncomment and change: daemon_key_label=rdzrse
      -> uncomment and change: server_keystore_file=rdzssl.jks
      -> uncomment and change: server_keystore_password=rsessl
      -> uncomment and change: server_keystore_label=rdzrse
      -> optionally uncomment and change: server_keystore_type=JKS

As mudanças anteriores ativam o SSL e informam ao servidor RSE que o certificado está armazenado com o rótulo rdzrse no armazenamento de chaves rdzssl.jks com a senha rsessl. O daemon RSE ainda está usando um conjunto de chaves compatível com SAF.

Capítulo 14. Configurando o TCP/IP

Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o TCP/IP ou durante a verificação ou a modificação de uma configuração existente.

Consulte Communications Server: IP Configuration Guide (SC31-8775) e Communications Server: IP Configuration Reference (SC31-8776) para obter informações adicionais sobre a configuração do TCP/IP.

Dependência do nome do host

Com o uso de APPC para o serviço TSO Commands, o Developer for System z depende de o TCP/IP ter o nome do host correto quando for inicializado. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.

Você pode testar sua configuração TCP/IP com o Installation Verification Program (IVP) do fekfivpt. O comando deve retornar uma saída como nesta amostra ($ é o prompt do z/OS UNIX):

$ fekfivpt

Quarta-feira, 2 de julho de 2008, 13h11min54s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars

-------------------------------------------------------------
Configuração do resolvedor TCP/IP (ordem de procura do z/OS UNIX):
-------------------------------------------------------------
Inicialização de Rastreio do Resolvedor Concluída -> 2008/07/02 13:11:54.745964

res_init Resolver values:
 Global Tcp/Ip Dataset  = None
 Default Tcp/Ip Dataset = None
 Local Tcp/Ip Dataset   = /etc/resolv.conf
 Translation Table      = Default
 UserId/JobName         = USERID
 Caller API             = LE C Sockets
 Caller Mode            = EBCDIC
 (L) DataSetPrefix = TCPIP
 (L) HostName      = CDFMVS08
 (L) TcpIpJobName  = TCPIP
 (L) DomainOrigin  = RALEIGH.IBM.COM
 (L) NameServer    = 9.42.206.2
                     9.42.206.3
 (L) NsPortAddr    = 53            (L) ResolverTimeout    = 10
 (L) ResolveVia    = UDP           (L) ResolverUdpRetries = 1
 (*) Options NDots = 1
 (*) SockNoTestStor
 (*) AlwaysWto     = NO            (L) MessageCase        = MIXED
 (*) LookUp        = DNS LOCAL
res_init Succeeded
res_init Started: 2008/07/02 13:11:54.755363
res_init Ended: 2008/07/02 13:11:54.755371
************************************************************************
MVS TCP/IP NETSTAT CS V1R9       TCPIP Name: TCPIP           13:11:54
Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled

-------------------------------------------------------------
endereço IP do host:
-------------------------------------------------------------
hostName=CDFMVS08
hostAddr=9.42.112.75
bindAddr=9.42.112.75
localAddr=9.42.112.75

Êxito, os endereços correspondem

Compreendendo os Resolvedores

O resolvedor atua em nome de programas como um cliente que acessa servidores de nomes para resolução de nome para endereço e de endereço para nome. Para resolver a consulta do programa solicitante, o resolvedor pode acessar os servidores de nomes disponíveis, utilize definições locais (por exemplo, /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO ou ETC.IPNODES) ou utilize uma combinação delas.

Quando o espaço de endereços do resolvedor é iniciado, ele lê um conjunto de dados de configuração do resolvedor opcional apontado pelo cartão SETUP DD no procedimento JCL do resolvedor. Se as informações de configuração não forem fornecidas, o resolvedor usará a ordem de procura nativa aplicável do MVS ou do z/OS UNIX sem nenhuma informação de GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES ou COMMONSEARCH.

Compreendendo as Ordens de Procura das Informações de Configuração

É importante compreender o ordem de procura dos arquivos de configuração usados pelas funções TCP/IP, e quando você pode sobrescrever a ordem de procura padrão com variáveis de ambiente, JCL ou outras variáveis fornecidas. Este conhecimento permite acomodar o conjunto de dados local e padrões de nomenclatura de arquivos HFS, e é útil conhecer o conjunto de dados da configuração ou o arquivo HFS em uso ao diagnosticar problemas.

Um outro ponto importante a ser observado é que quando uma ordem de procura é aplicada para qualquer arquivo de configuração, a procura finaliza com o primeiro arquivo localizado. Portanto, podem ocorrer resultados inesperados se você colocar informações de configuração em um arquivo que nunca é encontrado, pois outros arquivos aparecem antes na ordem de procura, ou porque o arquivo não está incluído na ordem de procura escolhida pelo aplicativo.

Ao procurar por arquivos de configuração, você pode informar explicitamente ao TCP/IP onde estão a maioria dos arquivos de configuração utilizando instruções DD nos procedimentos JCL ou configurando variáveis de ambiente. Caso contrário, você pode deixar o TCP/IP determinar dinamicamente o local dos arquivos de configuração, com base nas ordens de procura documentadas em Communications Server: IP Configuration Guide (SC31-8775).

O componente de configuração da pilha do TCP/IP utiliza o TCPIP.DATA durante a inicialização da pilha do TCP/IP para determinar o HOSTNAME da pilha. Para obter seu valor, a ordem de procura do ambiente do z/OS UNIX é usada.

Nota: Use o recurso do resolvedor de rastreio para determinar que os valores de TCPIP.DATA estão sendo usados pelo resolvedor e de onde eles foram lidos. Para obter informações sobre como iniciar o rastreio dinamicamente, consulte Communications Server: IP Diagnosis Guide (GC31-8782). Depois que o rastreio for ativado, emita um comando TSO NETSTAT HOME e um comando shell netstat -h do z/OS UNIX para exibir os valores. A emissão de um PING de um nome de host do TSO e a partir do shell do z/OS UNIX também mostra a atividade de qualquer servidor DNS que possa estar configurado.

Ordens de Procura Usadas no Ambiente do z/OS UNIX

O arquivo ou tabela específico que é procurado pode ser um conjunto de dados MVS ou um arquivo HFS, dependendo das definições de configuração do resolvedor e da presença de determinados arquivos no sistema.

Arquivos de Base da Configuração do Resolvedor

O arquivo de base da configuração do resolvedor contém instruções TCPIP.DATA. Além das diretivas do resolvedor, ele é referido para determinar, entre outras coisas, o prefixo do conjunto de dados (valor da instrução DATASETPREFIX) a ser usado ao tentar acessar alguns arquivos de configuração especificados nesta seção.

A ordem de procura usada para acessar o arquivo de configuração do resolvedor de base é a seguinte:

  1. GLOBALTCPIPDATA

    Se definido, o valor da instrução de configuração GLOBALTCPIPDATA do resolvedor é usado (consulte também Compreendendo os Resolvedores). A procura continua por um arquivo de configuração adicional. A procura finaliza com o próximo arquivo localizado.

  2. O valor da variável de ambiente RESOLVER_CONFIG

    O valor da variável de ambiente é usado. Esta procura falhará se o arquivo não existir ou estiver alocado exclusivamente em outro lugar.

  3. /etc/resolv.conf
  4. Cartão //SYSTCPD DD

    O conjunto de dados alocado para o SYSTCPD de nome DD é usado. No ambiente z/OS UNIX, um processo-filho não possui acesso ao DD SYSTCPD. Isto porque a alocação de SYSTCPD não é herdada do processo-pai por meio das chamadas de função fork() ou exec.

  5. userid.TCPIP.DATA

    userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço, tarefa ou encadeamento).

  6. jobname.TCPIP.DATA

    jobname é o nome especificado na instrução JOB da JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.

  7. SYS1.TCPPARMS(TCPDATA)
  8. DEFAULTTCPIPDATA

    Se definido, o valor da instrução de configuração DEFAULTTCPIPDATA do resolvedor é usado (consulte também Compreendendo os Resolvedores).

  9. TCPIP.TCPIP.DATA

Tabelas de Conversão

As tabelas de conversão (EBCDIC-to-ASCII e ASCII-to-EBCDIC) são consultadas para determinar os conjuntos de dados de conversão a serem usados. A ordem de procura usada para acessar o arquivo de configuração é a seguinte. A ordem de procura termina quando o primeiro arquivo é localizado:

  1. O valor da variável de ambiente X_XLATE. O valor da variável de ambiente é o nome da tabela de conversão produzida pelo comando CONVXLAT do TSO.
  2. userid.STANDARD.TCPXLBIN

    userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).

  3. jobname.STANDARD.TCPXLBIN

    jobname é o nome especificado na instrução JOB da JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.

  4. hlq.STANDARD.TCPXLBIN

    hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.

  5. Se nenhuma tabela for encontrada, o resolvedor usará uma tabela padrão codificada permanentemente, idêntica à tabela listada no membro do conjunto de dados SEZATCPX(STANDARD).

Tabelas do Host Local

Por padrão, o resolvedor primeiro tenta utilizar qualquer servidor de nomes de domínios configurado para pedidos de resolução. Se o pedido de resolução não puder ser satisfeito, as tabelas do host local são usadas. O comportamento do resolvedor é controlado pelas instruções TCPIP.DATA.

As instruções do resolvedor TCPIP.DATA definem se e como os servidores de nomes de domínios devem ser usados. A instrução LOOKUP TCPIP.DATA também pode ser usada para controlar como os servidores de nomes de domínios e as tabelas do host local são usadas. Para obter mais informações sobre instruções TCPIP.DATA, consulte Communications Server: IP Configuration Reference (SC31-8776).

O resolvedor utiliza a ordem de procura exclusiva Ipv4 para obter informações de nomes de sites incondicionalmente para chamadas de API getnetbyname. A ordem de procura exclusiva de Ipv4 para informações de nome de site é a seguinte. A procura termina quando o primeiro arquivo é localizado:

  1. O valor da variável de ambiente X_SITE

    O valor da variável de ambiente é o nome do arquivo de informações HOSTS.SITEINFO criado pelo comando MAKESITE do TSO.

  2. O valor da variável de ambiente X_ADDR

    O valor da variável de ambiente é o nome do arquivo de informações HOSTS.ADDRINFO criado pelo comando MAKESITE do TSO.

  3. /etc/hosts
  4. userid.HOSTS.SITEINFO

    userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).

  5. jobname.HOSTS.SITEINFO

    jobname é o nome especificado na instrução JOB da JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.

  6. hlq.HOSTS.SITEINFO

    hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.

Aplicando Estas Informações de Configuração ao Developer for System z

Conforme informado anteriormente, o Developer for System z depende de o TCP/IP ter o nome de host correto quando inicializado, ao utilizar APPC. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.

O exemplo a seguir tem como foco algumas tarefas de configuração para o TCP/IP e o Resolvedor. Observe que isso não abrange uma configuração completa do TCP/IP ou do Resolver, ela destaca alguns aspectos principais que podem ser aplicáveis no seu site:

  1. Na JCL a seguir, é possível ver que o TCP/IP usará SYS1.TCPPARMS(TCPDATA) para determinar o nome do host da pilha.
    //TCPIP    PROC PARMS=’CTRACE(CTIEZB00)’,PROF=TCPPROF,DATA=TCPDATA
    //*
    //* TCP/IP NETWORK
    //*
    //TCPIP    EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS
    //PROFILE  DD  DISP=SHR,DSN=SYS1.TCPPARMS(&PROF)
    //SYSTCPD  DD  DISP=SHR,DSN=SYS1.TCPPARMS(&DATA)
    //SYSPRINT DD  SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
    //ALGPRINT DD  SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
    //CFGPRINT DD  SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
    //SYSOUT   DD  SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
    //CEEDUMP  DD  SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
    //SYSERROR DD  SYSOUT=*
  2. SYS1.TCPPARMS(TCPDATA) informa que o nome do sistema desejado é o nome do host e para não usar um servidor de nomes de domínio (DNS); todos os nomes serão resolvidos através da consulta de tabela do site.
    ; HOSTNAME especifica o nome do host TCP deste sistema. Se não
    ; especificado, o HOSTNAME padrão será o nome do nó especificado
    ; no membro IEFSSNxx PARMLIB.
    ;
    ; HOSTNAME
    ;
    ; DOMAINORIGIN especifica a origem do domínio que será anexado
    ; nos nomes dos hosts transmitidos para o resolvedor. Se um nome
    ; de host contiver
    algum ponto, então DOMAINORIGIN não será anexado
    ; ao nome do host.
    ;
    DOMAINORIGIN  RALEIGH.IBM.COM
    ;
    ; NSINTERADDR especifica o endereço IP do servidor de nomes.
    ; LOOPBACK (14.0.0.0) especifica o servidor de nomes local. Se um servidor
    ; de nomes não será usado, então não codifique uma instrução NSINTERADDR.
    ; (Comente a linha NSINTERADDR abaixo). Isto fará com que todos os nomes
    ; sejam resolvidos por meio de consulta na tabela de sites.
    ;
    ; NSINTERADDR  14.0.0.0
    ;
    ; TRACE RESOLVER realizará um rastreio completo de todas as consultas e
    ; fará com que as respostas do servidor de nomes ou tabelas de sites sejam
    ; gravadas no
    console do usuário. Este comando é destinado somente para
    ; finalidades de depuração.
    ;
    ; TRACE RESOLVER
  3. No JCL do Resolvedor você vê que a instrução DD SETUP não é usada. Conforme mencionado em Compreendendo os Resolvedores, isto significa que GLOBALTCPIPDATA e outras variáveis não serão usadas.
    //RESOLVER PROC PARMS=’CTRACE(CTIRES00)’
    //*
    //* IP NAME RESOLVER - START WITH SUB=MSTR
    //*
    //RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
    //*SETUP    DD  DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
  4. Se você assumir que a variável de ambiente RESOLVER_CONFIG não está configurada, poderá ver na Tabela 40 que o Resolvedor tentará usar /etc/resolv.conf como arquivo de configuração base.
    TCPIPJOBNAME TCPIP
    DomainOrigin RALEIGH.IBM.COM
    HostName CDFMVS08

    Conforme mencionado em Ordens de Procura Usadas no Ambiente do z/OS UNIX, o arquivo de base da configuração contém instruções TCPIP.DATA. Se o nome do sistema for CDFMVS08 (TCPDATA informou que o nome do sistema é usado como nome do host), você poderá ver que /etc/resolv.conf está em sincronismo com SYS1.TCPPARMS(TCPDATA) . Não há definições DNS, portanto a consulta à tabela de sites será usada.

  5. A Tabela 40 também informa que, se não for necessário fazer nada, usar a tabela de conversão ASCII-EBCDIC padrão.
  6. Assumindo que o comando MAKESITE do TSO não seja usado (pode criar as variáveis X_SITE e X_ADDR), /etc/hosts será a tabela de sites usada para consulta de nomes.
    #  Resolver /etc/hosts file cdfmvs08
    9.42.112.75   cdfmvs08                     # CDFMVS08 Host
    9.42.112.75   cdfmvs08.raleigh.ibm.com     # CDFMVS08 Host
    127.0.0.1     localhost

    O conteúdo mínimo deste arquivo é a informação sobre o sistema atual. Na amostra anterior, cdfmvs08 e cdfmvs08.raleigh.ibm.com são definidos como um nome válido para o endereço IP do sistema z/OS.

    Se você estivesse usando servidor de nomes de domínio (DNS), o DNS conteria as informações de /etc/hosts, e /etc/resolv.conf e SYS1.TCPPARMS(TCPDATA) teriam instruções que identificariam o DNS para o sistema.

    Para evitar confusão, e aconselhável manter os arquivos de configuração do TCP/IP e do Resolver em sincronismo um com o outro.

Tabela 40. Definições locais disponíveis para o resolvedor
Descrição do Tipo do Arquivo APIs afetadas Arquivos do Candidato
Arquivos de Base da Configuração do Resolvedor Todas as APIs
  1. GLOBALTCPIPDATA
  2. variável de ambiente RESOLVER_CONFIG
  3. /etc/resolv.conf
  4. SYSTCPD DD-name
  5. userid.TCPIP.DATA
  6. jobname.TCPIP.DATA
  7. SYS1.TCPPARMS(TCPDATA)
  8. DEFAULTTCPIPDATA
  9. TCPIP.TCPIP.DATA
Tabelas de Conversão Todas as APIs
  1. variável de ambiente X_XLATE
  2. userid.STANDARD.TCPXLBIN
  3. jobname.STANDARD.TCPXLBIN
  4. hlq.STANDARD.TCPXLBIN
  5. Tabela de conversão fornecida pelo resolvedor, membro STANDARD em SEZATCPX
Tabelas do Host Local
endhostent
endnetent
getaddrinfo
gethostbyaddr
gethostbyname
gethostent
GetHostNumber
GetHostResol
GetHostString
getnameinfo
getnetbyaddr
getnetbyname
getnetent
IsLocalHost
Resolve
sethostent
setnetent
IPv4
  1. variável de ambiente X_SITE
  2. variável de ambiente X_ADDR
  3. /etc/hosts
  4. userid.HOSTS.xxxxINFO
  5. jobname.HOSTS.xxxxINFO
  6. hlq.HOSTS.xxxxINFO

IPv6

  1. GLOBALIPNODES
  2. variável de ambiente RESOLVER_IPNODES
  3. userid.ETC.IPNODES
  4. jobname.ETC.IPNODES
  5. hlq.ETC.IPNODES
  6. DEFAULTIPNODES
  7. /etc/ipnodes

Nota: A Tabela 40 é uma cópia parcial de uma tabela em Communications Server: IP Configuration Guide (SC31-8775). Consulte esse manual para obter a tabela completa.

O Endereço do Host Não É Resolvido Corretamente

Quando ocorrerem problemas nos quais o TCP/IP Resolver não pode resolver o endereço do host corretamente, muitas vezes isso é devido a um arquivo de configuração do resolvedor ausente ou incompleto. Uma indicação clara desse problema é a seguinte mensagem em lock.log:

clientip(0.0.0.0) <> callerip(<endereço IP do host>)

Para verificar isso, execute o IVP de TCP/IP, fekfivpt, conforme descrito em "Verificação da instalação" no Guia de Configuração do Host (SC23-7658). A seção de configuração do resolvedor da saída será semelhante à seguinte amostra:

Inicialização de Rastreio do Resolvedor Concluída -> 2008/07/02 13:11:54.745964

res_init Resolver values:
 Global Tcp/Ip Dataset  = None
 Default Tcp/Ip Dataset = None
 Local Tcp/Ip Dataset   = /etc/resolv.conf
 Translation Table      = Default
 UserId/JobName         = USERID
 Caller API             = LE C Sockets
 Caller Mode            = EBCDIC

Certifique-se de que as definições no arquivo (ou conjunto de dados) referido pelo "Local Tcp/Ip Dataset" estejam corretas.

Esse campo ficará em branco se você não utilizar um nome padrão para o arquivo resolvedor de IP (utilizando a ordem de procura do z/OS UNIX). Nesse caso, inclua a seguinte instrução em rsed.envvars, em que <arquivo do resolvedor> ou <dados do resolvedor> representa o nome do arquivo do resolvedor de IP:

RESOLVER_CONFIG=<arquivo do resolvedor>

ou

RESOLVER_CONFIG=’<conjunto de dados do resolvedor>’

Bibliografia

Publicações Referenciadas

As publicações a seguir são referenciadas neste documento:

Tabela 41. Publicações Referenciadas
Título da publicação Número da ordem Referência Web site de referência
Diretório do Programa para IBM Rational Developer for System z GI11-8298 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Program Directory for IBM Rational Developer for System z Host Utilities GI13-2864 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System zPré-requisitos S517-9092 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System z Host Configuration Quick Start GI11-9201 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System zGuia de Configuração do Host S517-9094 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System zReferência de Configuração do Host S517-9857 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System z Guia do Utilitário de Configuração do Host SC14-7282 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System z Messages and Codes SC14-7497 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System zRespostas a problemas comuns de manutenção e configuração de host SC14-7373 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System z Common Access Repository Manager Developer's Guide SC23-7660 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Rational Developer for System zPré-requisitos S517-9092 Developer for System z http://www.ibm.com/software/rational/products/developer/systemz/library/index.html
Rational Developer for System z Host Configuration Quick Start GI11-9201 Developer for System z http://www.ibm.com/software/rational/products/developer/systemz/library/index.html
SCLM Developer Toolkit: Guia do Administrador SC23-9801 Developer for System z http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Usando APPC para fornecer serviços de comando TSO SC14-7291 White Paper http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Usando Gateway do Cliente ISPF para fornecer serviços CARMA SC14-7292 White Paper http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Communications Server IP Configuration Guide SC31-8775 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server IP Configuration Reference SC31-8776 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server IP Diagnosis Guide GC31-8782 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server IP System Administrator's Commands SC31-8781 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server SNA Network Implementation Guide SC31-8777 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server SNA Operations SC31-8779 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Cryptographic Services System SSL Programming SC24-5901 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
DFSMS Macro Instructions for Data Sets SC26-7408 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
DFSMS Using Data Sets SC26-7410 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Language Environment Customization SA22-7564 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Language Environment Debugging Guide GA22-7560 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Diagnóstico do MVS: Ferramentas e Auxílio de Serviço GA22-7589 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Initialization and Tuning Guide SA22-7591 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Initialization and Tuning Reference SA22-7592 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS JCL Reference SA22-7597 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Planning APPC/MVS Management SA22-7599 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Planning Workload Management SA22-7602 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS System Commands SA22-7627 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Security Server RACF Command Language Reference SA22-7687 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Security Server RACF Security Administrator's Guide SA22-7683 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Customização de TSO/E SA22-7783 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
TSO/E REXX Reference SA22-7790 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
UNIX System Services Command Reference SA22-7802 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
UNIX System Services Planning GA22-7800 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
UNIX System Services User's Guide SA22-7801 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Utilizando os Serviços de Sistemas REXX e z/OS UNIX SA22-7806 z/OS 1.13 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Java™ Diagnostic Guide SC34-6650 Java 6.0 http://www.ibm.com/developerworks/java/jdk/diagnosis/
Guia do Usuário do Java SDK and Runtime Environment / Java 6.0 http://www-03.ibm.com/servers/eserver/zseries/software/java/
Resource Definition Guide SC34-6430 CICSTS 3.1 http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html
Resource Definition Guide SC34-6815 CICSTS 3.2 http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html
Resource Definition Guide SC34-7000 CICSTS 4.1 https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html
Resource Definition Guide SC34-7181 CICSTS 4.2 https://publib.boulder.ibm.com/infocenter/cicsts/ v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/ library/library_html.html
RACF Security Guide SC34-6454 CICSTS 3.1 http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html
RACF Security Guide SC34-6835 CICSTS 3.2 http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html
RACF Security Guide SC34-7003 CICSTS 4.1 https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html
RACF Security Guide SC34-7179 CICSTS 4.2 https://publib.boulder.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html
Referência de Linguagem SC27-1408 Enterprise COBOL para z/OS http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html

Os Web sites a seguir são referidos neste documento:

Tabela 42. Web Sites Referidos
Descrição Web site de referência
Developer for System z: Centro de Informações http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp
Developer for System z Biblioteca http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Developer for System z: Página Inicial http://www-03.ibm.com/software/products/us/en/developerforsystemz/
Serviço recomendado do Developer for System z http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335
Solicitação de aprimoramento de Developer for System z https://www.ibm.com/developerworks/support/rational/rfe/
Biblioteca do z/OS na Internet http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Centro de Informações do CICSTS https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp
IBM Tivoli Directory Server http://www-01.ibm.com/software/tivoli/products/directory-server/
Plug-ins de Ferramentas de Determinação de Problemas http://www-01.ibm.com/software/awdtools/deployment/pdtplugins/
Download do Apache Ant http://ant.apache.org/
Documentação do keytool Java http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html
Página inicial de suporte de CA https://support.ca.com/

Publicações Informativas

As publicações a seguir podem ser úteis para você compreender os problemas de configuração dos componentes do sistema host necessários:

Tabela 43. Publicações Informativas
Título da publicação Número da ordem Referência Website de referência
ABCs do z/OS System Programming Volume 9 (z/OS UNIX) SG24-6989 Redbook http://www.redbooks.ibm.com/
Guia do Programador de Sistema’ para: Workload Manager SG24-6472 Redbook http://www.redbooks.ibm.com/
Implementação do TCPIP Volume 1: Funções Base, Conectividade e Roteamento SG24-7532 Redbook http://www.redbooks.ibm.com/
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance SG24-7534 Redbook http://www.redbooks.ibm.com/
TCP/IP Implementation Volume 4: Security and Policy-Based Networking SG24-7535 Redbook http://www.redbooks.ibm.com/
Tivoli Directory Server para z/OS SG24-7849 Redbook http://www.redbooks.ibm.com/

Glossário

Ação de Bloqueio
Bloqueia um membro.
Application Server
  1. Um programa que manipula todas as operações do aplicativo entre computadores baseados em navegador e aplicativos ou bancos de dados de negócios de back-end da organização. Essa é uma classe especial de appservers baseados em Java que seguem o padrão J2EE. O código da J2EE pode ser facilmente colocado entre esses appservers. Pode suportar JSPs e servlets para conteúdo da Web dinâmico e EJBs para transações e acesso ao banco de dados.
  2. O destino de um pedido de um aplicativo remoto. No ambiente do DB2, a função de servidor de aplicativos é fornecida pelo recurso de dados distribuídos e é utilizada para acessar os dados do DB2 a partir de aplicativos remotos.
  3. Um programa do servidor em uma rede distribuída que fornece o ambiente de execução para um programa aplicativo.
  4. O destino de um pedido de um solicitador de aplicativo. O sistema de gerenciamento de banco de dados (DBMS) no site do servidor de aplicativos fornece os dados solicitados.
  5. Software que manipula a comunicação com o cliente que está solicitando um recurso e consultas do Content Manager.
Arquivo de Resposta
  1. Um arquivo que contém um conjunto de respostas predefinidas para perguntas feitas por um programa e que é usado para que não seja necessário digitar esses valores um a um.
  2. Um arquivo ASCII que pode ser customizado com os dados de definição e de configuração e que automatiza uma instalação. Os dados de definição e de configuração seriam digitados durante uma instalação interativa, mas com um arquivo de resposta a instalação pode prosseguir sem nenhuma intervenção.
Atributo Bidirecional
Tipo de Texto, Orientação de Texto, Troca Numérica e Troca Simétrica.
Banco de Dados
Um conjunto de itens de dados inter-relacionados ou independentes que são armazenados para servir um ou mais aplicativos.
Biblioteca de Carregamento
Uma biblioteca que contém módulos de carregamento.
Bidirecional (bi-di)
Pertencente a scripts, como Árabe e Hebraico, que geralmente são executados da direita para a esquerda, exceto números, que são executados da esquerda para a direita. Essa definição é do Glossário LISA (Localization Industry Standards Association).
Buffer de Erro
Uma parte do armazenamento utilizada para conter temporariamente informações de saída de erro.
Compilar
  1. Em linguagens ILE (Integrated Language Environment), para converter instruções de origem em módulos que, então, podem ser ligados a programas ou programas de serviços.
  2. Para traduzir todo o programa ou parte dele, expresso em um idioma de alto nível em um programa de computador expresso em uma linguagem intermediária, uma linguagem Assembly ou uma linguagem da máquina.
Conjunto de Dados
A principal unidade de armazenamento e recuperação de dados, que consiste em um conjunto de dados em uma das muitas organizações prescritas e descritas pelas informações de controle às quais o sistema tem acesso.
Contêiner
  1. No CoOperative Development Environment/400, um objeto de sistema que contém e organiza arquivos de origem. Uma biblioteca i5/OS ou um conjunto de dados particionado por MVS são exemplos e um contêiner.
  2. No J2EE, uma entidade que fornece serviços de gerenciamento de ciclo de vida, segurança, implementação e tempo de execução para componentes. (Sun) Cada tipo de contêiner (EJB, Web, JSP, servlet, applet e cliente aplicativo) também fornece serviços específicos ao componente
  3. Em Serviços de Recuperação e Mídia de Backup, o objeto físico usado para armazenar e mover mídia, como uma caixa, um estojo ou um rack.
  4. Em um servidor de fita virtual (VTS), um receptáculo em que um ou mais volumes lógicos exportados (LVOLs) podem ser armazenados. Um volume temporário que contém um ou mais LVOLs e reside fora de uma biblioteca de VTS é considerado o contêiner para esses volumes.
  5. Uma localização do armazenamento físico dos dados. Por exemplo, um arquivo, um diretório ou um dispositivo.
  6. Uma coluna ou uma linha que é usada para organizar o layout de um portlet ou outro contêiner em uma página.
  7. Um elemento da interface com o usuário que contém objetos. No gerenciador de pastas, um objeto que pode conter outras pastas ou documentos.
Depurar
Para detectar, diagnosticar e eliminar erros em programas.
Desinstalação Silenciosa
Um processo de desinstalação que não envia mensagens para o console, mas armazena mensagens e erros em arquivos de log depois que o comando de desinstalação é invocado.
Gateway
  1. Um componente de middleware que faz uma ponte entre a Internet e os ambientes de intranet durante chamadas de serviço da Web.
  2. Software que fornece serviços entre os nós de extremidades e o restante do ambiente Tivoli.
  3. Um componente de um VoIP (Voice over Internet Protocol) que fornece uma ponte entre o VoIP e ambientes alternados em circuito.
  4. Um dispositivo ou um programa usado para conectar redes ou sistemas com diferentes arquiteturas de rede. Os sistemas podem ter diferentes características, como protocolos de comunicação diferentes, arquitetura da rede diferente ou políticas de segurança diferentes; nesse caso, o gateway desempenha a função de tradução e também de conexão.
ID da Ação
Um identificador numérico para uma ação entre 0 e 999
Instalação Silenciosa
Uma instalação que não envia mensagens para o console, mas armazena mensagens e erros em arquivos de log. Além disso, uma instalação silenciosa pode utilizar arquivos de resposta para entrada de dados.
Instância do Repositório
Um projeto ou um componente que existe em um SCM.
Interactive System Productivity Facility (ISPF)
Um programa licenciado IBM que serve como um editor de tela inteira e um gerenciador de diálogos. Utilizado para gravar programas aplicativos, permite gerar painéis de tela padrão e diálogos interativos entre o programador do aplicativo e o usuário terminal. O ISPF consiste em quatro componentes principais: o DM, o PDF, o SCLM e o C/S. O componente DM é o Dialog Manager, que fornece serviços para diálogos e usuários finais. O componente PDF é o Program Development Facility, que fornece serviços para auxiliar o diálogo ou o desenvolvedor de aplicativos. O componente SCLM é o Software Configuration Library Manager, que fornece serviços para que desenvolvedores de aplicativos gerenciem suas bibliotecas de desenvolvimento de aplicativos. O componente C/S é o Client/Server, que permite executar o ISPF em uma estação de trabalho programável, para exibir os painéis que usam a função de exibição do sistema operacional da estação de trabalho e para integrar ferramentas e dados da estação de trabalho a ferramentas e dados do host.
Intérprete
Um programa que traduz e executa cada instrução de uma linguagem de programação de alto nível antes de traduzir e executar a próxima instrução.
Isomórfico
Cada elemento composto (em outras palavras, um elemento contendo outros elementos) do documento da instância XML iniciando a partir da raiz tem um, e apenas um, item do grupo COBOL correspondente cuja profundidade de aninhamento é idêntica à profundidade de aninhamento de seu equivalente XML. Cada elemento não-composto (em outras palavras, um elemento que não contém outros elementos) do documento da instância XML iniciando a partir da parte superior tem um e apenas um item elementar COBOL correspondente cuja profundidade de aninhamento é idêntica ao nível de aninhamento de seu equivalente XML e cujo endereço de memória no tempo de execução pode ser exclusivamente identificado.
Lista de Tarefas
Uma lista de procedimentos que podem ser executados por um único fluxo de controle.
Não isomórfico
Um mapeamento simples de itens COBOL e elementos XML pertencentes a documentos XML e grupos COBOL que não têm formas idênticas (não-isomórfico). O mapeamento não-isomórfico também pode ser criado entre elementos não-isomórficos de estruturas isomórficas.
Nome da Shell
O nome da interface shell.
Perspectiva
Um grupo de visualizações que mostram vários aspectos dos recursos do ambiente de trabalho. O usuário do ambiente de trabalho pode alternar perspectivas, dependendo da tarefa disponível, e customizar o layout de visualizações e editores na perspectiva.
Perspectiva Sistemas Remotos
Fornece uma interface para gerenciar sistemas remotos utilizando convenções semelhantes a ISPF.
RAM
Repository Access Manager
Repositório
  1. Uma área de armazenamento de dados. Cada repositório tem um nome e um tipo de item de negócios associado. Por padrão, o nome será igual ao nome do item de negócios. Por exemplo, um repositório para faturas será chamado Faturas. Há dois tipos de repositórios de informações: local (específico ao processo) e global (reutilizável).
  2. Um conjunto de dados VSAM em que os estados de processos BTS são armazenados. Quando um processo não está sendo executado sob o controle do BTS, seu estado (e os estados de suas atividades constituintes) é preservado com a gravação em um conjunto de dados do repositório. Os estados de todos os processos de um tipo de processo específico (e de suas instâncias de atividade) são armazenados no mesmo conjunto de dados do repositório. Registros de vários tipos de processo podem ser gravados no mesmo repositório.
  3. Uma área de armazenamento persistente para código de origem e outros recursos de aplicativo. Em um ambiente de programação em equipe, um repositório compartilhado permite o acesso de multiusuários aos recursos de aplicativo.
  4. Um conjunto de informações sobre os gerenciadores de filas que são membros de um cluster. Essas informações incluem nomes de gerenciadores de filas, seus locais, seus canais, quais filas eles hospedam, etc.
Script da Shell
Um arquivo que contém comandos que podem ser interpretados pelo shell. O usuário digita o nome do arquivo de script no prompt do comando shell para fazer com que a shell execute os comandos do script.
Seção de Ligação
A seção da divisão de dados de uma unidade ativada (um programa chamado ou um método invocado) que descreve itens de dados disponíveis da unidade de ativação (um programa ou um método). Esses itens de dados podem ser usados como referência tanto pela unidade ativada quanto pela unidade de ativação.
Sessão de Depuração
As atividades de depuração que ocorrem entre o momento em que o desenvolvedor inicia um depurador e o momento em que ele sai dali.
Shell
Uma interface de software entre usuários e o sistema operacional que interpreta comandos e interações com o usuário e comunica-os ao sistema operacional. Um computador pode ter várias camadas de shells para diversos níveis de interação com o usuário.
Sidedeck
Uma biblioteca que publica as funções de um programa DLL. Os nomes de entrada e de módulo são armazenados na biblioteca após a compilação do código de origem.
Sistema de Arquivo Remoto
Um sistema de arquivo que reside em um servidor ou sistema operacional separado.
Sistema Remoto
Qualquer outro sistema na rede com o qual o sistema possa se comunicar.
Solicitação de Construção
Um pedido do cliente para executar uma transação de construção.
Transação de Construção
Uma tarefa iniciada no MVS para executar construções após um pedido de construção ser recebido do cliente.
URL
Uniform Resource Locator
Visualização Console de Saída
Exibe a saída de um processo e permite fornecer entrada do teclado a um processo.
Visualização Definição de Dados
Contém uma representação local de bancos de dados e seus objetos e fornece recursos para manipular esses objetos e exportá-los para um banco de dados remoto
Visualização Navegador
Fornece uma visualização hierárquica dos recursos do Ambiente de Trabalho.
Visualização Repositórios
Exibe os locais de repositório CVS que foram incluídos no Ambiente de Trabalho.
Visualização Saída
Exibe mensagens, parâmetros e resultados relacionados aos objetos com os quais você trabalha
Visualização Servidores
Exibe uma lista de todos os servidores e as configurações associadas a eles.

Avisos sobre a Documentação para o IBM Rational Developer for System z

© Copyright IBM Corporation 2009, 2013.

Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação ou divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.

Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos.

É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos nesta publicação em outros países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não IBM são de responsabilidade do Cliente.

A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não lhe garante direito algum sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:

Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240

Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:

Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan

O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS A ELAS NÃO SE LIMITANDO, AS GARANTIAS IMPLÍCITAS DE NÃO INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, essa disposição pode não se aplicar ao Cliente.

Essas informações podem conter imprecisões técnicas ou erros tipográficos. São feitas alterações periódicas nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aviso prévio.

Referências nestas informações a websites não IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses websites. Os materiais contidos nesses websites não fazem parte dos materiais desse produto IBM e a utilização desses websites é de inteira responsabilidade do Cliente.

A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.

Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:

Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240

Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em alguns casos o pagamento de uma taxa.

O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato Internacional de Licença do Programa IBM ou de qualquer outro contrato equivalente.

Todos os dados de desempenho aqui contidos foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em nível de desenvolvimento e não há garantia de que estas medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas medidas podem ter sido estimadas por extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados aplicáveis para seu ambiente específico.

As informações relativas a produtos não IBM foram obtidas junto aos fornecedores dos respectivos produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não IBM. Dúvidas sobre os recursos de produtos não IBM devem ser encaminhadas diretamente a seus fornecedores.

Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aviso prévio e representam apenas metas e objetivos.

Estas informações foram projetadas apenas com o propósito de planejamento. As informações aqui contidas estão sujeitas a alterações antes que os produtos descritos estejam disponíveis.

Estas informações contêm exemplos de dados e relatórios utilizados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos incluem nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança com os nomes e endereços utilizados por uma empresa real é mera coincidência.

Licença de Copyright

Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de amostra sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de amostra são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não é responsável por nenhum dano decorrente do uso dos programas de amostra.

Cada cópia ou parte destes programas de amostra ou qualquer trabalho derivado deve incluir um aviso de copyright com os dizeres:

© (nome da empresa) (ano). Partes deste código são derivadas dos Programas de Amostras da IBM Corp. © Copyright IBM Corp. 2009, 2013.

Se estas informações estiverem sendo exibidas em cópia eletrônica, as fotografias e ilustrações coloridas podem não aparecer.

Reconhecimentos de Marca Registrada

IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corp., registradas em vários países no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM está disponível na web em www.ibm.com/legal/copytrade.shtml.

Adobe, o logotipo Adobe, PostScript e o logotipo PostScript são marcas ou marcas registradas da Adobe Systems Incorporated nos Estados Unidos e/ou em outros países.

Linux é uma marca registrada de Linus Torvalds nos Estados Unidos e/ou em outros países.

Windows é uma marca registrada da Microsoft Corporation nos Estados Unidos e/ou em outros países.

UNIX é uma marca registrada do The Open Group nos Estados Unidos e em outros países.

Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Oracle e/ou de suas afiliadas.

Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas.

Licença de Copyright

Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não é responsável por nenhum dano decorrente do uso dos programas de amostra.

Reconhecimentos de Marca Registrada

IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corp., registradas em vários países no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM está disponível na Web em www.ibm.com/legal/copytrade.shtml.

CA Endevor é uma marca registrada da CA Technologies.

Rational é uma marca registrada da International Business Machines Corporation e da Rational Software Corporation nos Estados Unidos e/ou em outros países.

Intel e Pentium são marcas registradas da Intel Corporation nos Estados Unidos e/ou em outros países.

Microsoft, Windows e o logotipo Windows são marcas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.

Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e em outros países.

UNIX é uma marca registrada do The Open Group nos Estados Unidos e em outros países.

Índice

Caracteres Especiais
A B C D E F G H I J K L M N O P R S T U V W X Z
Caracteres Especiais A B C D E F G H I J K L M N O P R S T U V W X Z
Feedback