IBM Rational IBM Rational Developer para System z

Guia de Configuração do Host

Versão 7.6.1
S517-9094-04
Nota

Antes de usar este documento, leia as informações gerais em Notas de Documentação para IBM Rational Developer para System z.

Quinta Edição (Maio de 2010)

Esta edição aplica-se ao IBM Rational Developer para System z Versão 7.6.1 (número do programa 5724-T07) e a todas modificações e releases subsequentes, até indicado de forma diferente 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 através 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 pelo correio ao seguinte endereço:

Av. Pasteur, 138-146
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 sobre Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.

Copyright International Business Machines Corporation 2005, 2010.

Índice

Figuras
Tabelas
Sobre este Documento
Quem Deve Usar este Documento
Resumo das Mudanças
Descrição do Conteúdo do Documento
Planejamento
Customização Básica
(Opcional) CARMA (Common Access Repository Manager)
(Opcional) Application Deployment Manager
(Opcional) SCLM Developer Toolkit
(Opcional) Outras Tarefas de Customização
Verificação de Instalação
Comandos do operador
Resolução de Problemas de Configuração
Considerações de segurança
Entendendo o Developer para System z
Considerações WLM
Considerações de Ajuste
Considerações de Desempenho
Considerações sobre o CICSTS
Customizando o Ambiente TSO
Executando várias instâncias
Guia de Migração
Configurando o SSL e a Autenticação X.509
Configurando o TCP/IP
Configurando o INETD
Configurando o APPC
Requisitos
Customização do Developer para System z
Planejamento
Considerações de Migração
Considerações de Planejamento
Visão Geral do Produto
Exigências de Capacidade
Requisitos de Tempo
Considerações sobre Pré-Instalação
Opção de Configuração
Requisito de produtos
Recursos Necessários
Considerações de Pré-configuração
Gerenciamento de Carga de Trabalho
Uso de Recursos e Limites do Sistema
Configuração Necessária de Produtos de Requisito
Considerações de ID do Usuário
Considerações do Servidor
Método de Configuração
Considerações sobre Pré-implementação
Lista de Verificação do Cliente
Customização Básica
Requisitos e Lista de Verificação
Configuração da Customização
Alterações PARMLIB
Configurar Limites do z/OS UNIX no BPXPRMxx
Incluir Tarefas Iniciadas em COMMNDxx
Definições de LPA em LPALSTxx
Autorizações APF em PROGxx
Definições de LINKLIST no PROGxx
Definições de LINKLIST e LPA de Requisito
Definições LINKLIST para Outros Produtos
Alterações do PROCLIB
JES Job Monitor
Daemon RSE
Daemon de Bloqueio
Limitações da JCL para a Variável PARM
Procedimentos de Construção Remota ELAXF*
Definições de Segurança
FEJJCNFG, Arquivo de Configuração do JES Job Monitor
Arquivo de Configuração do RSE rsed.envvars
Definindo o PORTRANGE Disponível para o Servidor RSE
Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS
Definindo Parâmetros Extras de Inicialização Java com _RSE_CMDSERV_OPTS
ISPF.conf, Arquivo de Configuração do TSO/ISPF Client Gateway do ISPF
Componentes Opcionais
Verificação de Instalação
(Opcional) CARMA (Common Access Repository Manager)
Requisitos e Lista de Verificação
Componentes do CARMA
Notas de Migração VSAM do CARMA
Interface RSE para CARMA
Inicialização do Servidor CARMA Usando Submissão em Lote
Ajustar CRASRV.properties
Ajustar CRASUBMT
(Opcional) Inicialização Alternativa do Servidor CARMA Utilizando CRASTART
Ajustar CRASRV.properties
Ajustar crastart.conf
(Opcional) Inicialização Alternativa do Servidor CARMA Usando TSO/ISPF Client Gateway
Ajustar CRASRV.properties
Ajustar ISPF.conf
(Opcional) Ativando os RAM (Repository Access Managers) de Amostra
Ativando o PDS RAM
Ativando o RAM do SCLM
Ativando o RAM da Estrutura
(Opcional) Ativando o CA Endevor® SCM RAM
Requisitos e Lista de Verificação
Defina o CA Endevor® SCM RAM
Inicialização do CA Endevor® SCM RAM Usando Submissão em Lote
Inicialização do CA Endevor® SCM RAM Usando CRASTART
(Opcional) Customize CRANDVRA
(Opcional) Customize o CA Endevor® SCM RAM
(Opcional) Suportando Múltiplos RAMs
Exemplo
(Opcional) IRXJCL versus CRAXJCL
Criar CRAXJCL
(Opcional) Application Deployment Manager
Requisitos e Lista de Verificação
Repositório do CRD
CICS Administrative Utility
RESTful versus Serviços da Web
Servidor CRD Usando a Interface RESTful
Região de Conexão Primária do CICS
Regiões de Conexão Não-primária do CICS
(Opcional) Customizar IDs de Transação do Servidor CRD
Servidor CRD Usando a Interface do Serviço da Web
Manipulador de Mensagens do Pipeline
região de conexão primária do CICS
regiões de conexão não-primária do CICS
(Opcional) Repositório de Manifesto
(Opcional) SCLM Developer Toolkit
Requisitos e Lista de Verificação
Pré-requisitos
Atualizações do ISPF.conf para SCLMDT
Atualizações do rsed.envvars para SCLMDT
(Opcional) Tradução de Nome Longo/Abreviado
Criar LSTRANS.FILE, o VSAM de Conversão de nome Longo/Curto
Atualizações de rsed.envvars para Conversão de Nomes Longos/Curtos
(Opcional) Instalar e Customizar Ant
Atualizações SCLM para SCLMDT
Remover Arquivos Antigos de WORKAREA
(Opcional) Outras Tarefas de Customização
(Opcional) Procedimento Armazenado do DB2
Alterações do Workload Manager (WLM)
Alterações do PROCLIB
Mudanças no DB2
(Opcional) Suporte de Enterprise Service Tools (EST)
(Opcional) Suporte de Idioma Bidirecional do CICS
(Opcional) Mensagens de Erro IRZ de Diagnóstico
(Opcional) Criptografia SSL do RSE
(Opcional) Rastreio de RSE
(Opcional) Grupos de Propriedade Baseados em Host
(Opcional) Projetos Baseados no Host
(Opcional) Integração do File Manager
(Opcional) Caracteres Não-editáveis
(Opcional) Usando REXEC (ou SSH)
Ações Remotas (Baseadas em Host) para Subprojetos z/OS UNIX
Método de Conexão Alternativo do RSE
Configuração de REXEC (ou SSH)
(Opcional) Transação APPC para o Serviço de Comandos TSO
Preparação
Implementação
Considerações sobre Uso de APPC
(Opcional) Limpeza de WORKAREA
Verificação de Instalação
Verificar Tarefas Iniciadas
JMON, JES Job Monitor
LOCKD, Daemon de Bloqueio
RSED, Daemon RSE
Verificar Serviços
Inicialização do IVP
Disponibilidade de Porta
Configuração de TCP/IP
Conexão do Daemon RSE
Conexão do JES Job Monitor
Conexão do Daemon de Bloqueio
Conexão do TSO/ISPF Client Gateway do ISPF
(Opcional) Conexão do Serviço TSO Commands Utilizando APPC
(Opcional) Conexão SCLMDT
(Opcional) Conexão REXEC
(Opcional) Script de Shell REXEC/SSH
Informações do Developer para System z
Comandos do Operador
Start (S)
JES Job Monitor
Daemon RSE
Daemon de Bloqueio
Modify (F)
JES Job Monitor
Daemon RSE
Daemon de Bloqueio
Stop (P)
Mensagens do Console
JES Job Monitor
Daemon RSE, Servidor do Conjunto de Encadeamento RSE e Daemon de Bloqueio
Como Ler um Diagrama de Sintaxe
Símbolos
Operandos
Exemplo de Sintaxe
Caracteres Não Alfanuméricos e Espaços em Branco
Selecionando Mais de Um Operando
Mais Longo que Uma Linha
Fragmentos de Sintaxe
Resolução de Problemas de Configuração
Análise de Log e de Configuração Usando FEKLOGS
Arquivos de Log
Criação de Logs do JES Job Monitor
Criação de Log do Daemon de Bloqueio
Criação de Log de Daemon RSE e de Conjunto de Encadeamento
Criação de Log de Usuário do RSE
Criação de Log de Integração do Fault Analyzer
Criação de Log de Integração do File Manager
Criação de Log do SCLM Developer Toolkit
Criação de Logs do CARMA
Criação de Logs de Transações APPC (Serviço de Comandos do TSO)
Criação de Log de Teste IVP do fekfivpi
Criação de Log de Teste IVP do fekfivps
Arquivos de Dump
Dumps do MVS
Dumps de Java
Locais do Dump do z/OS UNIX
Rastreio
Rastreio do JES Job Monitor
Rastreio do RSE
Rastreio do Daemon de Bloqueio
Rastreio do CARMA
Rastreio de Feedback de Erro
Bits de Permissão do z/OS UNIX
Atributo de Sistema de Arquivo 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
Transação APPC e Serviço de Comandos do TSO
Informações Diversas
Limites do Sistema
Problemas de Requisitos Conhecidos
Emulador de Conexão do Host
Considerações sobre 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
Segurança de Conexão
Limitar Comunicação Externa a Portas Especificadas
Criptografia de Comunicação Usando SSL
Verificação de Port Of Entry
Portas TCP/IP
Comunicação Externa
Comunicação Interna
Portas CARMA e TCP/IP
Usando os PassTickets
Criação de Log de Auditoria
Controle 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 por SSL
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)
Segurança do CICSTS
Repositório do CRD
Transações do CICS
Comunicação Criptografada por SSL
Segurança de SCLM
Arquivos de Configuração do Developer para System z
JES Job Monitor - FEJJCNFG
RSE - rsed.envvars
RSE - ssl.properties
Definições de Segurança
Requisitos e Lista de Verificação
Ativar Configurações e Classes de Segurança
Definição de um Segmento OMVS para os Usuários do Developer para System z
Definir os Perfis do Conjunto de Dados
Definir as Tarefas Iniciadas do Developer para System z
Definir a Segurança de Comando do JES
Definir o RSE como um Servidor z/OS UNIX Seguro
Definir Bibliotecas Controladas pelo Programa MVS para o RSE
Definir Proteção de Aplicativo para RSE
Definir o Suporte PassTicket para o RSE
Definir Arquivos Controlados pelo Programa z/OS UNIX para o RSE
Verificar Configurações de Segurança
Entendimento do Developer para System z
Visão Geral do Componente
RSE como um Aplicativo Java
Donos das Tarefas
Fluxo de Conexão
Daemon de Bloqueio
Liberando um Bloqueio
Estrutura do Diretório z/OS UNIX
Atualizar Privilégios para Administradores que Não São de Sistema
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
Considerações de Ajuste
Uso de Recursos
Visão Geral
Contagem do Espaço de Endereço
Contagem de Processos
Contagem de Encadeamentos
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)
Definições de Vários Recursos
Placa EXEC na JCL do Servidor
FEK.#CUST.PARMLIB(FEJJCNFG)
SYS1.PARMLIB(IEASYSxx)
SYS1.PARMLIB(IVTPRMxx)
SYS1.PARMLIB(ASCHPMxx)
Monitoramento
Monitoramento de RSE
Monitorando 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
Considerações de Desempenho
Usar Sistemas de Arquivos zFS
Evite o Uso de STEPLIB
Aprimorar o Acesso às Bibliotecas do Sistema
Bibliotecas de Tempo de Execução do Ambiente de Linguagem (LE)
Desenvolvimento do Aplicativo
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
Considerações sobre o CICSTS
RESTful versus Serviços da Web
Regiões de Conexão Primária versus Não-primária
Log de Instalação do Recurso do CICS
segurança do Application Deployment Manager
Segurança do Repositório do 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
Customizando o Ambiente TSO
O Serviço TSO Commands
Métodos de Acesso
Usando o Método de Acesso do TSO/ISPF Client Gateway
Customização Básica - ISPF.conf
Avançado - Usar Perfis do ISPF Existentes
Avançado - Usando um Exec de Alocação
Avançado - Usar Vários Execs de Alocação
Avançado - Vários Arquivos ISPF.conf com várias Configurações do Developer para System z
Usando o Método de Acesso do APPC
Customização Básica - JCL de Transação APPC
Avançado - Usar Perfis do ISPF Existentes
Avançado - Usando um Exec de Alocação
Avançado - Várias Transações APPC com Várias Configurações do Developer para System z
Executando Várias Instâncias
Configuração Idêntica em um Sysplex
Arquivos de Configuração Diferentes de Níveis de Software Idênticos
Todas as Outras Situações
Guia de Migração
Considerações de Migração
Fazendo Backup de Arquivos Configurados Anteriormente
Notas de Migração da Versão 7.6.1
Migrar da Versão 7.5 para a Versão 7.6
IBM Rational Developer para System z, FMID HHOP760
Arquivos Configuráveis
Migrar da Versão 7.1 para a Versão 7.5
IBM Rational Developer para System z, FMID HHOP750
Arquivos Configuráveis
Migrar da Versão 7.0 para a Versão 7.1
IBM Rational Developer para System z, FMID HHOP710
IBM CARMA, FMID HCMA710
Arquivos Configuráveis
Apêndices
Apêndice A. Configurando o SSL e a Autenticação X.509
Decidir Onde Armazenar Chaves Privadas e Certificados
Criar um Anel de Chave 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
Apêndice B. 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 no Developer para System z
O Endereço do Host Não É Resolvido Corretamente
Apêndice C. Configurando o INETD
inetd.conf
ETC.SERVICES
Ordem de Procura Usada no Ambiente z/OS UNIX
Ordem de Procura Usada no Ambiente MVS Ambiente
Definições de Portas PROFILE.TCPIP
/etc/inetd.pid
Inicialização
/etc/rc
/etc/inittab
BPXBATCH
Sessão de Shell
Segurança
Requisitos do Developer para System z
INETD
REXEC (ou SSH)
Apêndice D. Configurando o APPC
VSAM
VTAM
SYS1.PARMLIB(APPCPMxx)
SYS1.PARMLIB(ASCHPMxx)
Ativando Alterações do APPC
Definindo a Transação de Serviço Comandos do TSO
(Opcional) Opções de Configuração Alternativas
Nome de Transação Alternativo
Várias LUs
Segurança da LU
Apêndice E. Requisitos
Pré-requisitos de Host do z/OS
z/OS
SMP/E
SDK para z/OS Java 2 Technology Edition
Co-requisitos de Host do z/OS
z/OS
Compilador de COBOL
Compilador PL/I
Debug Tool para z/OS
CICS Transaction Server
IMS
DB2 para z/OS
Rational Team Concert para System z
File Manager
Fault Analyzer
REXX
Ported tools
Ant
Endevor®
Bibliografia
Publicações Referenciadas
Publicações Informativas
Glossário
Notas de Documentação para IBM Rational Developer para System z
Licença de Copyright
Reconhecimentos de Marca Registrada
Índice Remissivo

Figuras

  1. JMON - Tarefa Iniciada do JES Job Monitor
  2. RSED - tarefa iniciada do daemon RSE
  3. LOCKD - Tarefa iniciada do daemon de bloqueio
  4. RSED - inicialização do daemon RSE alternativo
  5. rsed.stdin.sh - inicialização do daemon RSE alternativo
  6. FEJJCNFG, arquivo de configuração do JES Job Monitor
  7. rsed.envvars - Arquivo de configuração do RSE
  8. (continuação)
  9. ISPF.conf - Arquivo de Configuração do ISPF
  10. CRASRV.properties - Arquivo de configuração CARMA
  11. CRASRV.properties - inicialização do CARMA usando submissão em lote
  12. CRASUBMT - inicialização do CARMA utilizando submissão em lote
  13. CRASRV.properties - Inicialização alternativa do CARMA *CRASTART
  14. crastart.conf - Inicialização alternativa do CARMA *CRASTART
  15. CRASRV.properties - Inicialização alternativa do CARMA *ISPF
  16. ISPF.conf - Inicialização alternativa do CARMA *ISPF
  17. Figura x1. CRASRV.properties - inicialização do CA Endevor® SCM RAM usando submissão em lote
  18. Figura x2. Inicialização do CRASUBCA - CA Endevor® SCM RAM usando submissão em lote
  19. Figura x3. CRASRV.properties - inicialização do CA Endevor® SCM RAM usando CRASTART
  20. crastart.conf - CA Endevor® inicialização do SCM RAM usando CRASTART
  21. Atualizações do ISPF.conf para SCLMDT
  22. Atualizações do rsed.envvars para SCLMDT
  23. FLM02LST - JCL de Configuração da Conversão de Nomes Longos/Curtos
  24. ELAXMSAM - Tarefa de Procedimento Armazenado do DB2
  25. ELAXMJCL - Definição do procedimento armazenado do DB2
  26. ssl.properties - Arquivo de configuração SSL
  27. rsecomm.properties - Arquivo de configuração da criação de log
  28. propertiescfg.properties - Arquivo de configuração de grupos de propriedades baseado no host
  29. projectcfg.properties - Arquivo de configuração de projetos baseados no host
  30. FMIEXT.properties - Arquivo de configuração do File Manager
  31. uchars.settings - Arquivo de configuração de caracteres não editáveis
  32. REXX para Painéis ISPF do APPC
  33. Comando do operador START JMON
  34. Comando do operador START RSED
  35. Comando do operador START LOCKD
  36. Comando do operador MODIFY JMON
  37. Comando do operador MODIFY RSED
  38. Comando do operador MODIFY LOCKD
  39. Comando do operador STOP
  40. Portas TCP/IP
  41. Visão geral do componente
  42. RSE como um aplicativo Java
  43. donos das tarefas
  44. Fluxo de conexão
  45. Fluxo do daemon de bloqueio
  46. estrutura do diretório z/OS UNIX
  47. classificação WLM
  48. Número máximo de espaços de endereço
  49. Número de espaços de endereços por cliente
  50. Número máximo de processos
  51. Número de processos por cliente
  52. Número máximo de encadeamentos do conjunto de encadeamento do RSE
  53. Número máximo de encadeamentos do JES Job Monitor
  54. Uso de recursos com 5 logons
  55. Uso de recursos com 5 logons (continuação)
  56. Uso de recursos ao editar um membro PDS
  57. Uso do espaço do sistema de arquivos z/OS UNIX
  58. Uso do recurso de configuração de amostra
  59. ADNJSPAU - Administrative utility do CICSTS
  60. FEKAPPCC - criar uma segunda transação APPC
  61. RSEDSSL - Tarefa do usuário do daemon RSE para SSL
  62. Diálogo Importar Certificado do Host
  63. Diálogo Preferências - SSL
  64. JCL de Inicialização do INETD
  65. JCL para Criar VSAMs do APPC
  66. SYS1.SAMPLIB(ATBAPPL)
  67. SYS1.PARMLIB(APPCPMxx)
  68. SYS1.PARMLIB(ASCHPMxx)

Tabelas

  1. Recursos Necessários
  2. Recursos Opcionais
  3. Administradores necessários para as tarefas necessárias
  4. Administradores Necessários para Tarefas Opcionais
  5. Lista de Verificação do Cliente - Partes Obrigatórias
  6. Lista de Verificação do Cliente - Partes Opcionais
  7. Procedimento ELAXF* de amostra
  8. Lista de Verificação para Qualificadores de Alto Nível ELAXF*
  9. Matriz de Permissão do Comando LIMIT_COMMANDS
  10. Variáveis de crastart.conf
  11. IDs de Transação do Servidor CRD Padrão
  12. IDs de Transação do Servidor CRD Padrão
  13. Lista de Verificação do Administrador de SCLM
  14. Mecanismos de armazenamento de certificado SSL
  15. Tipos de keystore válidos
  16. Lista de verificação de transações APPC
  17. IVPs para Serviços
  18. Status do erro do conjunto de encadeamento
  19. Mensagens de Console do RSE
  20. Variáveis de JAVA_DUMP_TDUMP_PATTERN
  21. Comandos do Console do JES Job Monitor
  22. Matriz de Permissão do Comando LIMIT_COMMANDS
  23. Perfis JESSPOOL Estendidos
  24. Matriz de permissão de navegação LIMIT_VIEW
  25. Mecanismos de armazenamento de certificado SSL
  26. Variáveis de configuração de segurança
  27. Comandos do Operador do JES2 Job Monitor
  28. Comandos do Operador do JES3 Job Monitor
  29. subsistemas de ponto de entrada WLM
  30. qualificadores de trabalho WLM
  31. cargas de trabalho WLM
  32. cargas de trabalho WLM STC
  33. Cargas de trabalho WLM OMVS
  34. Carga de trabalhos WLM JES
  35. Cargas de trabalho WLM ASCH
  36. Cargas de trabalho WLM CICS
  37. Uso de recursos comuns
  38. Uso de recursos obrigatórios específicos do usuário
  39. Uso de recursos específicos do usuário
  40. Contagem do espaço de endereço
  41. Limites de espaço de endereço
  42. Contagem de processos
  43. Limites do processo
  44. Contagem de encadeamentos
  45. Limites de encadeamento
  46. Diretivas de saída do log
  47. Customizações da Versão 7.6
  48. Customizações da Versão 7.5
  49. Customizações da Versão 7.1
  50. Mecanismos de armazenamento de certificado SSL
  51. Definições locais disponíveis para o resolvedor
  52. Publicações Referenciadas
  53. Web Sites Referidos
  54. Publicações Informativas

Sobre este Documento

Este documento descreve a configuração das funções do IBM Rational Developer para System z. Ele inclui instruções sobre como configurar o IBM Rational Developer para System z Versão 7.6.1 em seu sistema host z/OS.

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

Para releases anteriores, incluindo IBM WebSphere Developer para System z, IBM WebSphere Developer para zSeries e IBM® WebSphere Studio Enterprise Developer, use as informações de configuração encontradas no Guia de Configuração do Host e nos Diretórios de Programas desses releases.

Quem Deve Usar este Documento

Este documento foi planejado para programadores de sistema que instalam e configuram o IBM Rational Developer para System z Versão 7.6.1, FMID HHOP760, em seus sistemas host z/OS.

Ele lista com detalhes as diferentes etapas necessárias para uma configuração completa do produto, incluindo alguns cenários não padrão. Para utilizar este documento, você precisa estar familiarizado com os Serviços do Sistema z/OS UNIX e os sistemas host MVS.

Resumo das Mudanças

Esta seção resume as alterações do Guia de Configuração do Host do Rational Developer para System z Versão 7.6.1, S517-9094-04 (atualizado em Maio de 2010).

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

Este documento contém informações previamente apresentadas no Guia de Configuração do Host do Rational Developer para System z Versão 7.6, SC23-7658-03.

Novas informações:

Descrição do Conteúdo do Documento

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

Planejamento

Use as informações deste capítulo para planejar a instalação e a implementação do Developer para System z.

Customização Básica

As etapas de customização abaixo são para uma configuração básica do Developer para System z:

(Opcional) CARMA (Common Access Repository Manager)

O Common Access Repository Manager (CARMA) é um auxílio de produtividade para os desenvolvedores criam Repository Access Managers (RAMs). Um RAM é uma interface de programação de aplicativos (API) para z/OS baseada em Software Configuration Managers (SCMs).

Em seguida, os aplicativos gravados pelo usuário podem iniciar um servidor CARMA que carrega os RAMS(s) e fornece uma interface padrão para acessar o SCM.

O IBM® Rational® Developer para System z Interface para CA Endevor® Software Configuration Manager fornece aos clientes do Developer para System z acesso direto ao CA Endevor® SCM.

(Opcional) Application Deployment Manager

O Developer para System z utiliza determinadas funções do Application Deployment Manager como uma abordagem de implementação comum para vários componentes. A customização opcional ativa mais recursos do Gerenciador de Implementação do Aplicativo e pode incluir os seguintes serviços no Developer para System z:

(Opcional) SCLM Developer Toolkit

O SCLM Developer Toolkit fornece as ferramentas necessárias para estender os recursos do SCLM para o cliente. O SCLM por si só é um gerenciador de código de origem baseado em host enviado como parte do ISPF.

O SCLM Developer Toolkit possui um plug-in baseado em Eclipse que faz a interface com o SCLM e fornece acesso a todos os processos do SCLM para desenvolvimento de código legado, bem como suporte para o desenvolvimento completo do Java e do J2EE na estação de trabalho com sincronização para SCLM no mainframe, incluindo compilação, montagem e implementação do código J2EE a partir do mainframe.

(Opcional) Outras Tarefas de Customização

Esta seção combina uma variedade de tarefas opcionais de customização. Siga as instruções na seção apropriada para configurar o serviço desejado.

Verificação de Instalação

Após concluir a customização do produto, é possível usar os Installation Verification Programs (IVPs) descritos neste capítulo para verificar o êxito da configuração dos componentes principais do produto.

Comandos do operador

Este capítulo fornece uma visão geral dos comandos disponíveis do operador (ou console) para o Developer para System z.

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 Developer para System z e contém as seguintes seções:

Considerações de segurança

O Developer para System fornece acesso do 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.

Entendendo o Developer para System z

O host Developer para System z consiste em vários componentes que interagem para fornecer ao cliente acesso aos dados e serviços do host. Entender o design desses componentes pode ajudar você a tomar as decisões de configuração corretas.

Considerações WLM

Ao contrário dos aplicativos z/OS tradicionais, o Developer para System z não é um aplicativo monolítico que pode ser facilmente identificado para o Workload Manager (WLM). O Developer para System z consiste em diversos componentes que interagem para dar ao cliente acesso aos serviços e dados de 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 para 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 atua como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamento processam as cargas de trabalho do cliente.

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

Considerações de Desempenho

z/OS é um sistema operacional altamente customizável, e (às vezes pequenas) mudanças no sistema podem ter um enorme impacto no desempenho geral. Este capítulo destaca algumas das mudanças que podem ser feitas para melhorar o desempenho do Developer para System z.

Considerações sobre o CICSTS

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

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 para System z.

Executando várias instâncias

Há vezes em que você quer várias instâncias do Developer para System z ativas no mesmo sistema, por exemplo, ao testar um upgrade. Entretanto, alguns recursos, como portas TCP/IP, não podem ser compartilhados, portanto, os padrões nem sempre são aplicáveis. Use as informações neste capítulo para planejar a coexistência de instâncias diferentes do Developer para System z, após a qual você poderá usar esse guia de configuração para customizá-las.

Guia de Migração

Esta seção destaca as alterações na instalação e na configuração em comparação a releases anteriores do produto. Também fornece algumas diretrizes gerais para migrar para este release. Consulte as seções relacionadas neste manual para obter informações adicionais.

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.

Configurando o INETD

Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o INETD ou durante a verificação ou a modificação de uma configuração existente. INETD é usado pelo Developer para System z para a funcionalidade REXEC/SSH.

Configurando o APPC

Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o APPC (Advanced Program-to-Program Communication) ou durante a verificação e a modificação de uma configuração existente.

Requisitos

Este apêndice lista os pré-requisitos e co-requisitos do host para esta versão do Developer para System z.

Customização do Developer para System z

Planejamento

Use as informações deste capítulo, junto com as informações do Apêndice E. Requisitos, para planejar a instalação e implementação do Developer para System z. Os seguintes assuntos são descritos:

Considerações de Migração

O Guia de Migração descreve as alterações de instalação e configuração comparadas aos releases anteriores do produto. Use essas informações para planejar a migração para o release atual do Developer para System z.

Notas:
  1. Se você for um usuário anterior do IBM Rational Developer para System z, IBM WebSphere Developer para System z, IBM WebSphere Developer para zSeries ou IBM WebSphere Studio Enterprise Developer, é recomendável salvar os arquivos customizados relacionados ANTES de instalar o IBM Rational Developer para System z Versão 7.6.1. Consulte o Guia de Migração para obter uma visão geral dos arquivos que precisam ser customizados.
  2. Consulte o Executando Várias Instâncias, se planeja executar várias instâncias do Developer para System z.

Considerações de Planejamento

Visão Geral do Produto

O Developer para System z consiste em um cliente, instalado no computador pessoal do usuário, e em um servidor, instalado em um ou mais hosts. Esta documentação enfocará no host que está sendo um sistema z/OS. Porém, outros sistemas operacionais como AIX e Linux® no System z também são suportados.

O cliente fornece aos desenvolvedores um ambiente de desenvolvimento baseado no Eclipse que facilita uma interface gráfica uniforme com o host, e que, entre outras coisas, pode transferir trabalho do host para o cliente, economizando recursos no host.

A parte do host consiste em várias tarefas ativas permanentemente e tarefas que são iniciadas ad-hoc. Essas tarefas permitem que o cliente trabalhe com os vários componentes do seu host z/OS, tais como conjuntos de dados MVS, comandos TSO, arquivos e comandos z/OS UNIX, envio de tarefas e saída de tarefas.

O Developer para System z pode também interagir com subsistemas e outros softwares aplicativos no host, tal como o CICS, a Ferramenta de Depuração e SCMs (Software Configuration Managers), se o Developer para System z estiver configurado para isso e se esses produtos (correquisitos) estiverem disponíveis.

Consulte o Entendimento do Developer para System z para obter um entendimento básico do design do Developer para System z.

Consulte o Web site do Developer para System z, http://www-01.ibm.com/software/awdtools/rdz/, ou o seu representante local IBM para saber mais sobre a funcionalidade oferecida pelo Developer para System z.

Exigências de Capacidade

Capacidades mínimas de SMP/E são necessárias para a instalação de um host do Developer para System z.

A configuração do Developer para System z exige mais do que as permissões e o conhecimento típicos de programação de sistema, portanto, é possível que haja necessidade de uma mínima assistência de terceiros. A Tabela 3 e a Tabela 4 listam os administradores necessários para as tarefas de customização necessárias e opcionais.

Requisitos de Tempo

O tempo necessário para instalar e configurar os componentes de host do Developer para System z depende de vários fatores, tais como:

A experiência tem mostrado que o processo de instalação e de configuração do host do Developer para System z exige de um a quatro dias para ser concluído. Esse requisito de tempo é para que uma instalação limpa seja executada por um programador de sistema experiente. Se ocorrerem problemas ou se as qualificações necessárias não estiverem disponíveis, então a configuração demorará mais tempo.

Considerações sobre Pré-Instalação

Consulte o Program Directory para IBM Rational Developer para System z (GI11-8298) para obter instruções detalhadas sobre a instalação SMP/E do produto.

Nota:
O sistema de arquivos (HFS ou zFS) em que o Developer para 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 arquivos com o parâmetro NOSETUID impedirá o Developer para System z de criar o ambiente de segurança do usuário e falhará no pedido de conexão do cliente.

Consulte o Executando Várias Instâncias se desejar executar várias instâncias do Developer para System z.

Opção de Configuração

O Developer para System z fornece uma opção para acessar o serviço TSO Commands. A opção escolhida aqui impacta a configuração necessária de pré-requisitos. Um dos seguintes métodos deve ser selecionado e configurado:

Nota:
O TSO/ISPF Client Gateway do ISPF também é usado pelo SCLM Developer Toolkit e, opcionalmente, por um método de inicialização alternativo para o CARMA (Common Access Repository Manager).

Requisito de produtos

O Apêndice E. Requisitos possui uma lista de softwares obrigatórios que devem ser instalados e estar em funcionamento para que o Developer para System z funcione. Há também uma lista de software de correquisito para suportar recursos específicos do Developer para System z. Esses requisitos devem ser instalados e estar em funcionamento no tempo de execução para que o recurso correspondente funcione conforme projetado.

Consulte o Rational Developer para System z Prerequisites (SC23-7659) na biblioteca on-line do Developer para System z, em http://www-01.ibm.com/software/awdtools/rdz/library/ para obter uma lista atualizada de produtos obrigatórios e de correquisitos para a sua versão do Developer para System z. Planeje antecipadamente para ter esses produtos de requisito disponíveis, uma vez que isso pode levar algum tempo, dependendo das políticas em seu site. Os principais requisitos para uma configuração básica são os seguintes:

Nota:
O PTF APAR PM073 para o Developer para System z deve ser aplicado ao usar uma versão 64 bits do Java. O PTF está disponível por meio da página de serviço recomendada do Developer para System z,http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335.

Recursos Necessários

O Developer para System z requer a alocação dos recursos do sistema listados na Tabela 1. Os recursos listados na Tabela 2 são necessários para serviços opcionais. Planeje antecipadamente para ter esses recursos disponíveis, uma vez que pode levar algum tempo para obtê-los, dependendo das políticas em seu site.

Nota:
O Developer para System z consiste em múltiplas tarefas que se comunicam entre si e o cliente. Essas tarefas usam vários cronômetros para detectar perda de comunicação com seu parceiro ou seus parceiros. Isso significa que podem surgir problemas de tempo limite (devido à falta de tempo de CPU durante a janela de tempo limite) nos sistemas com uma carga de CPU pesada ou configurações incorretas de Gerenciamento de Carga de Trabalho (WLM) no Developer para system z.
Tabela 1. Recursos Necessários
Recurso Valor Padrão Informações
Conjunto de dados autorizado APF FEK.SFEKAUTH Autorizações APF em PROGxx
tarefa iniciada JMON, RSED e LOCKD Considerações do Servidor
porta para uso limitado por host 6715 FEJJCNFG, Arquivo de Configuração do JES Job Monitor
porta para uso limitado por host 4036 Arquivo de Configuração do RSE rsed.envvars
porta para comunicação cliente-host 4035 Alterações do PROCLIB
intervalo de portas para comunicação cliente-host qualquer porta disponível é usada Definindo o PORTRANGE Disponível para o Servidor RSE
Definição da segurança do aplicativo Acesso universal de LEITURA para FEKAPPL Definir Proteção de Aplicativo para RSE
Definições de segurança PassTicket nenhum padrão Definir o Suporte PassTicket para o RSE
Tabela 2. Recursos Opcionais
Recurso Valor Padrão Informações
conjunto de dados LINKLIST FEK.SFEKAUTH e FEK.SFEKLOAD (Opcional) SCLM Developer Toolkit
conjunto de dados LPA FEK.SFEKLPA (Opcional) CARMA (Common Access Repository Manager)
intervalo de portas para uso confinado no host 5227-5326 (100 portas) (Opcional) CARMA (Common Access Repository Manager)
portas para uso limitado por host qualquer porta disponível é usada (Opcional) Transação APPC para o Serviço de Comandos TSO
porta para comunicação cliente-host nenhum padrão (Opcional) Application Deployment Manager
atualização da CSD do CICS diversos valores (Opcional) Application Deployment Manager
atualização do CICS JCL FEK.SFEKLOAD

A configuração do Developer para System z exige mais do que as permissões e o conhecimento típicos de programação de sistema, portanto, é possível que haja necessidade de uma mínima assistência de terceiros. A Tabela 3 e a Tabela 4 listam os administradores necessários para as tarefas de customização necessárias e opcionais.

Tabela 3. Administradores necessários para as tarefas necessárias
Administrador Tarefa Informações
Sistema Ações típicas do programador de sistema são necessárias para todas as tarefas de customização N/D
Security
  • Definir segmento OMVS para usuários do Developer para System z
  • Definir perfis do conjunto de dados
  • Definir tarefas iniciadas
  • Definir segurança de comando do operador
  • Definir os perfis do servidor z/OS UNIX
  • Definir segurança do aplicativo
  • Definir suporte PassTicket
  • Definir conjuntos de dados controlados pelo programa
  • Definir os arquivos do z/OS UNIX controlados pelo programa
Considerações sobre Segurança
TCP/IP Definir novas portas TCP/IP Portas TCP/IP
WLM Designar os objetivos da tarefa iniciada para os processos de servidores e seus filhos Considerações WLM
Tabela 4. Administradores Necessários para Tarefas Opcionais
Administrador Tarefa Informações
Sistema Ações típicas do programador de sistema são necessárias para todas as tarefas de customização N/D
Security
  • Definir perfis do conjunto de dados
  • Definir conjuntos de dados controlados pelo programa
  • Definir permissão para enviar tarefas xxx*
  • Definir segurança da transação do CICS
  • Incluir certificado para SSL
  • Definir suporte de certificado de cliente X.509
TCP/IP Definir novas portas TCP/IP Portas TCP/IP
SCLM
  • Definir tradutores de idiomas SCLM para suporte JAVA/J2EE
  • Definir tipos de SCLM para suporte JAVA/J2EE
(Opcional) SCLM Developer Toolkit
CICS TS
  • Atualização de JCL da região do CICS
  • Atualização da CSD da região do CICS
  • Definir grupo do CICS
  • Definir nomes de transação do CICS
  • Definir um programa para o CICS
DB2 Definir um procedimento armazenado do DB2 (Opcional) Procedimento Armazenado do DB2
WLM
  • Designar metas a um procedimento armazenado do DB2
  • Designar metas do tipo TSO para uma transação APPC
APPC Definir uma transação APPC (Opcional) Transação APPC para o Serviço de Comandos TSO

Considerações de Pré-configuração

Gerenciamento de Carga de Trabalho

Ao contrário dos aplicativos tradicionais do z/OS, o Developer para System z não é um aplicativo monolítico que pode ser facilmente identificado para Workload Manager (WLM). O Developer para System z consiste de vários componentes que interagem para fornecer ao cliente acesso aos dados e serviços do host. Consulte o Considerações WLM para planejar apropriadamente a sua configuração WLM.

Uso de Recursos e Limites do Sistema

Quando estiver em uso, o Developer para System z usará um número variável de recursos do sistema, como espaços de endereços e processos e encadeamentos z/OS UNIX. A disponibilidade desses recursos é limitada por várias definições do sistema. Consulte o Considerações de Ajuste para estimar o uso de recursos-chave, para que você possa planejar a configuração do sistema de acordo.

Configuração Necessária de Produtos de Requisito

Consulte o programador de sistemas do MVS, o administrador de segurança e o administrador TCP/IP para verificar se os produtos e o software de requisito estão instalados, testados e funcionando. Algumas tarefas de customização de requisito que são facilmente negligenciadas estão listadas a seguir:

Considerações de ID do Usuário

O ID do usuário de um usuário do Developer para System z deve ter, pelo menos, os seguintes atributos:

Considerações do Servidor

O Developer para System z consiste em 3 servidores ativos permanentemente, que podem ser tarefas iniciadas ou tarefas do usuário. Esses servidores fornecem os serviços necessários entre si ou iniciam outros servidores (como encadeamentos z/OS UNIX ou tarefas do usuário) para fornecer o serviço.

O JES Job Monitor (JMON) fornece todos os serviços relacionados ao JES.

Explorador de Sistemas Remotos O (RSE) é o componente do Developer para System z que fornece serviços principais, como conectar o cliente ao host.

Conforme documentado no Portas TCP/IP, certos serviços do host, e suas portas, devem estar disponíveis para conexão com o cliente e devem ser definidos para seu firewall que protege o host. Todas as outras portas usadas pelo Developer para System z possuem tráfego apenas do host. A seguir há uma lista das portas necessárias para um configuração básica do Developer para System z.

Nota:
Clientes anteriores (versão 7.0 e mais antiga) comunicam-se diretamente com o JES Job Monitor (usando o protocolo tcp), porta padrão 6715.

Método de Configuração

Começando com a versão 7.6.1, o Developer para System z fornece um método alternativo, usando um aplicativo do painel ISPF, para configurar o lado de host do produto. Isso fornece a você uma escolha dos seguintes métodos:

Considerações sobre Pré-implementação

O Developer para System z suporta a clonagem de uma instalação para um sistema diferente, evitando a necessidade de instalar o SMP/E em cada sistema.

Os seguintes conjuntos de dados, diretórios e arquivos são obrigatórios para a implementação em outros sistemas. Se você copiou um arquivo para um local diferente, esse arquivo deverá substituir seu correspondente nas listas a seguir.

Nota:
A lista a seguir não inclui as necessidades de implementação do software obrigatório e de correquisito.
Notas:
  1. FEK e /usr/lpp/rdz são o qualificador e o caminho de alto nível 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 da Customização para obter informações adicionais).
  2. Você deve instalar o Developer para System z em um sistema de arquivos privado (HFS ou zFS) para facilitar a implementação e partes do produto z/OS UNIX.
  3. 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 para 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 para System z.

Lista de Verificação do Cliente

Os usuários do cliente do Developer para System z devem conhecer o resultado de determinadas customizações do host, como números de portas TCP/IP, para que o cliente funcione corretamente. Use essas listas de verificação para reunir as informações necessárias.

A lista de verificação na Tabela 5 lista os resultados necessários de etapas de customização obrigatórias. A Tabela 6 lista os resultados necessários das etapas de customização opcionais.

Tabela 5. Lista de Verificação do Cliente - Partes Obrigatórias
Customização Valor
Número da porta do servidor do JES Job Monitor (padrão 6715):

Consulte SERV_PORT em FEJJCNFG, Arquivo de Configuração do JES Job Monitor.

Número da porta TCP/IP do daemon RSE (padrão 4035):

Consulte o Daemon RSE.

Tabela 6. Lista de Verificação do Cliente - Partes Opcionais
Customização Valor
Local dos procedimentos de ELAXF* se não estiverem em uma biblioteca de procedimentos do sistema:

Consulte a nota sobre JCLLIB em Procedimentos de Construção Remota ELAXF*.

Procedimento ou nomes de etapas dos procedimentos de ELAXF* se tiverem sido alterados:

Consulte a nota sobre a alteração deles em Procedimentos de Construção Remota ELAXF*.

Nome do procedimento armazenado do DB2 (padrão ELAXMSAM):

Consulte informações sobre procedimentos armazenados do DB2 no Executando Várias Instâncias.

Local do procedimento armazenado do DB2, se não estiver em uma biblioteca de procedimentos do sistema:

Consulte o (Opcional) Procedimento Armazenado do DB2.

(correquisito) Número da porta TN3270 para Emulador de Conexão do Host (padrão 23).

Consulte o Considerações sobre Segurança

(correquisito) Número da porta REXEC ou SSH (padrão 512 ou 22, respectivamente):

Consulte o (Opcional) Usando REXEC (ou SSH).

Local do arquivo server.zseries se o método de conexão REXEC/SSH for usado (padrão /etc/rdz).

Consulte o (Opcional) Usando REXEC (ou SSH).

Local do CRA#ASLM JCL para alocações de conjuntos de dados SCLM RAM do CARMA (padrão FEK.#CUST.JCL):

Consulte a nota sobre CRA#ASLM em Ativando o RAM do SCLM.

Customização Básica

As etapas de customização a seguir são para uma configuração básica do Developer para System z. Consulte os capítulos sobre os componentes opcionais para seus requisitos de customização.

Requisitos e Lista de Verificação

Você precisará da assistência de um administrador de segurança e de um administrador de TCP/IP para concluir essa tarefa de customização, que requer os seguintes recursos e tarefas de customização especiais:

Para verificar a instalação e começar a usar o Developer para System z no seu site, você deve executar as seguintes tarefas. A menos que especificado o contrário, todas as tarefas são obrigatórias.

  1. Crie cópias customizáveis de amostras e crie o ambiente de trabalho para o Developer para system z. Para obter detalhes, consulte Configuração da Customização.
  2. Atualize os limites do sistema z/OS UNIX, inicie as tarefas iniciadas, defina os conjuntos de dados LINKLIST e autorizados por APF e, opcionalmente, os conjuntos de dados LPA. Para obter detalhes, consulte Alterações PARMLIB.
  3. Crie procedimentos de tarefa iniciada e procedimentos de compilação/link. Para obter detalhes, consulte Alterações do PROCLIB.
  4. Atualize as definições de segurança. Para obter detalhes, consulte Definições de Segurança. Você deve também estar ciente e compreender como os PassTickets são usados para estabelecer a segurança do encadeamento. Consulte Usando os PassTickets para obter detalhes.
  5. Customize os arquivos de configuração do Developer para System z. Para obter detalhes, consulte:

Configuração da Customização

O Developer para System z é fornecido com vários arquivos de configuração de amostra e a JCL de amostra. Para evitar sobrescrever suas customizações ao realizar manutenção, é aconselhável copiar todos esses membros e arquivos z/OS UNIX para um local diferente e customizar a cópia.

Algumas funções do Developer para System z também requerem a existência de determinados diretórios no z/OS UNIX, que devem ser criados durante a customização do produto. Para facilitar o esforço de instalação, uma tarefa de amostra, FEKSETUP, é fornecida para criar as cópias e os requisitos necessários.

Customize e envie o membro de amostra FEKSETUP no conjunto de dados FEK.SFEKSAMP para criar cópias customizáveis de arquivos de configuração e JCL de configuração e para criar diretórios do z/OS UNIX necessários. As etapas necessárias de customização são descritas dentro do membro.

Esta tarefa executa as seguintes ações:

Notas:
  1. As etapas de configuração nesta publicação usam os locais de membro/arquivo criados pela tarefa FEKSETUP, a menos que indicado de outra maneira. As amostras originais, que não devem ser atualizadas, podem ser localizadas em FEK.SFEKSAMP e /usr/lpp/rdz/samples/.
  2. Se desejar manter todos os arquivos Developer para System z z/OS UNIX no mesmo sistema de arquivo (HFS ou zFS), e também desejar colocar os arquivos de configuração no /etc/rdz, utilize os links simbólicos para resolver este problema. Os seguintes comandos de amostra z/OS UNIX criam um novo diretório no sistema de arquivo existente (/usr/lpp/rdz/cust) e definem um link simbólico (/etc/rdz) para ele:
    mkdir /usr/lpp/rdz/cust
    ln -s /usr/lpp/rdz/cust /etc/rdz

Alterações PARMLIB

Consulte MVS Referência de Ajuste e Inicialização (SA22-7592) para obter informações adicionais sobre as definições PARMLIB listadas a seguir. Consulte o MVS System Commands (SA22-7627) para obter informações adicionais sobre os comandos do console de amostra.

Configurar Limites do z/OS UNIX no BPXPRMxx

O Explorador de Sistemas Remotos (RSE), que fornece os serviços principais, como conexão do cliente com o host, é um processo baseado no z/OS UNIX. Portanto, é importante configurar valores corretos para os limites do sistema z/OS UNIX no BPXPRMxx, com base no número de usuários simultaneamente ativos do Developer para System z e em sua carga de trabalho média.

Consulte o Considerações de Ajuste para obter mais informações sobre os diferentes limites definidos por BPXPRMxx e seu impacto no Developer para System z.

MAXASSIZE especifica o tamanho máximo da região do espaço de endereço (processo). Configure MAXASSIZE em SYS1.PARMLIB(BPXPRMxx) como 2G. Esse é o valor 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 isso não for o que você deseja, então poderá definir o limite também apenas para o Developer para System z em seu software de segurança, conforme descrito em Definir as Tarefas Iniciadas do Developer para System z.

MAXTHREADS especifica o número máximo de encadeamentos ativos para um único processo. Configure MAXTHREADS em SYS1.PARMLIB(BPXPRMxx) como 1500 ou mais alto. Esse é um limite amplo do sistema e, dessa forma, ativo em todos os espaços de endereço do z/OS UNIX. Se isso não for o que você deseja, então poderá definir o limite também apenas para o Developer para System z em seu software de segurança, conforme descrito em Definir as Tarefas Iniciadas do Developer para System z.

MAXTHREADTASKS especifica o número máximo de tarefas MVS ativas para um único processo. Configure MAXTHREADTASKS em SYS1.PARMLIB(BPXPRMxx) como 1500 ou mais alto. Esse é um limite amplo do sistema e, dessa forma, ativo em todos os espaços de endereço do z/OS UNIX. Se isso não for o que você deseja, então poderá definir o limite também apenas para o Developer para System z em seu software de segurança, conforme descrito em Definir as Tarefas Iniciadas do Developer para System z.

MAXPROCUSER especifica o número máximo de processos que um único ID de usuário do z/OS UNIX pode ter simultaneamente ativo. Configure MAXPROCUSER em SYS1.PARMLIB(BPXPRMxx) como 50 ou superior. Essa configuração deve ser um limite amplo do sistema, uma vez que deve estar ativo para cada cliente que usa o Developer para System z.

Esses valores podem ser verificados e configurados dinamicamente (até o próximo IPL) com os seguintes comandos do console:

Notas:
  1. Consulte o Tamanho do Espaço de Endereço para obter informações adicionais sobre outros locais em que tamanhos de espaço do endereço possam ser definidos ou limitados.
  2. O valor de MAXPROCUSER usado acima baseia-se nos usuários que têm um UID (ID do Usuário) exclusivo do z/OS UNIX. Aumente esse valor se os usuários compartilharem o mesmo UID.
  3. Certifique-se de que outros valores de BPXPRMxx, como aqueles para MAXPROCSYS e MAXUIDS, são suficientes para manipular a quantidade esperada de usuários do Developer para System z atualmente ativos. Consulte Considerações de Ajuste para obter mais detalhes.

Incluir Tarefas Iniciadas em COMMNDxx

Inclua comandos de inicialização para os servidores Developer para System z RSED, LOCKD e JMON para SYS1.PARMLIB(COMMANDxx) para iniciá-los automaticamente no próximo sistema IPL.

Após os servidores serem definidos e configurados, eles podem ser iniciados dinamicamente (até o próximo IPL) com os seguintes comandos do console:

Nota:
O daemon de bloqueio deve ser iniciado antes de usuários do Developer para System z efetuarem logon no daemon RSE. Isso é para que o daemon de bloqueio possa rastrear os pedidos de bloqueio do conjunto de dados por esses usuários. Portanto, é necessário iniciar o daemon de bloqueio na inicialização do sistema.

Definições de LPA em LPALSTxx

O serviço Common Access Repository Manager (CARMA) (opcional) suporta métodos de inicialização de servidor alternativos que não requerem o uso de um iniciador JES. A alternativa mais flexível requer que o módulo CRASTART na biblioteca de carregamento FEK.SFEKLPA esteja na LPA (Área do Pacote de Links).

Os conjuntos de dados de LPA são definidos em SYS1.PARMLIB(LPALSTxx).

As definições de LPA podem ser configuradas dinamicamente (até o próximo IPL) com os seguintes comandos do console:

Autorizações APF em PROGxx

Para que o JES Job Monitor acesse arquivos de spool do JES, o módulo FEJJMON na biblioteca de carregamento FEK.SFEKAUTH e nas bibliotecas de tempo de execução LE (Language Environment) (CEE.SCEERUN*) deve ser autorizado por APF.

Para que o serviço SCLM Developer Toolkit (opcional) funcione, o módulo BWBTSOW na biblioteca de carregamento FEK.SFEKAUTH e na biblioteca de tempo de execução do REXX (REXX.*.SEAGLPA) deve ser autorizado por APF.

Para que o ISPF crie o Gateway do Cliente TSO/ISPF, o módulo ISPZTSO em SYS1.LINKLIB deve ser autorizado pela APF. O TSO/ISPF Client Gateway é usado pelo serviço TSO Commands do Developer para System z', SCLM Developer Toolkit e opcionalmente CARMA.

As autorizações APF são definidas em SYS1.PARMLIB(PROGxx), se seu site seguiu as recomendações da IBM.

As autorizações APF podem ser configuradas dinamicamente (até o próximo IPL) com os seguintes comandos do console, em que volser é o volume onde o conjunto de dados reside se não for gerenciado pelo SMS:

Notas:
  1. Quando você utiliza a Biblioteca Alternativa para o pacote de produto REXX, o nome da biblioteca de tempo de execução REXX padrão é REXX.*.SEAGALT, em vez de REXX.*.SEAGLPA, conforme usado na amostra anterior.
  2. Bibliotecas LPA, como REXX.*.SEAGLPA, são autorizadas automaticamente por APF quando localizadas em LPA e, portanto, não requerem definições explícitas.
  3. Alguns dos produtos de correquisito, como a Ferramenta de Depuração IBM, exigem também autorização APF. Consulte os guias de customização do produto relacionados para obter informações adicionais sobre isso.

Definições de LINKLIST no PROGxx

Definições LINKLIST para o Developer para System z podem ser agrupadas em 3 categorias:

Para que o serviço SCLM Developer Toolkit (opcional) funcione, todos os módulos BWB* nas bibliotecas de carregamento FEK.SFEKAUTH e FEK.SFEKLOAD devem ser disponibilizados por meio do STEPLIB ou LINKLIST.

Se você optar por utilizar o STEPLIB, deverá definir as bibliotecas não disponíveis por meio do LINKLIST na diretiva STEPLIB de rsed.envvars, no arquivo de configuração do RSE. Porém, lembre-se de que:

Os conjuntos de dados LINKLIST são definidos em SYS1.PARMLIB(PROGxx), se seu site seguiu as recomendações da IBM.

As definições necessárias serão semelhantes às seguintes, em que listname é o nome do conjunto LINKLIST que será ativado e volser é o volume no qual o conjunto de dados residirá se não estiver catalogado no catálogo principal:

As definições de LINKLIST podem ser criadas dinamicamente (até o próximo IPL) com o seguinte grupo de comandos de console, em que listname é o nome do conjunto LINKLIST atual e volser é o volume no qual o conjunto de dados residirá se não estiver catalogado no catálogo principal:

  1. LNKLST DEFINE,NAME=LLTMP,COPYFROM=CURRENT
  2. LNKLST ADD NAME=LLTMP,DSN=FEK.SFEKAUTH,VOL=volser
  3. LNKLST ADD NAME=LLTMP,DSN=FEK.SFEKLOAD
  4. LNKLST ACTIVATE,NAME=LLTMP
  5. LNKLST UNDEFINE,NAME=listname
  6. LNKLST UPDATE,JOB=*

Definições de LINKLIST e LPA de Requisito

Explorador de Sistemas Remotos (RSE) é um processo z/OS UNIX que requer acesso às bibliotecas de carregamento do MVS. As seguintes bibliotecas (pré-requisito) devem ser disponibilizadas, através de STEPLIB ou LINKLIST/LPALIB:

As seguintes bibliotecas adicionais devem ser disponibilizadas, por meio de STEPLIB ou de LINKLIST/LPALIB, para suportar o uso de serviços opcionais. Essa lista não inclui conjuntos de dados que são específicos para um produto com o qual o Developer para System z interage, como a Ferramenta de Depuração IBM:

Notas:
  1. Quando você utiliza a Biblioteca Alternativa para o pacote de produto REXX, o nome da biblioteca de tempo de execução REXX padrão é REXX.*.SEAGALT, em vez de REXX.*.SEAGLPA, conforme usado na amostra anterior.
  2. As bibliotecas projetadas para colocação de LPA, como REXX.*.SEAGLPA, podem exigir controle de programa adicional e/ou autorizações do APF se forem acessadas através de LINKLIST ou STEPLIB.
  3. Alguns dos produtos de correquisito, como a Ferramenta de Depuração IBM, exigem também definições STEPLIB ou LINKLIST/LPALIB. Consulte os guias de customização do produto relacionados para obter informações adicionais sobre isso.
  4. Se CEE.SCEELKED estiver em LINKLIST ou em STEPLIB, TCPIP.SEZALOAD deverá ser colocado antes de CEE.SCEELKED. Se isso não for feito, o sistema 0C1 encerrará de forma anormal para as chamadas do soquete TCP/IP REXX.

Os conjuntos de dados LINKLIST são definidos em SYS1.PARMLIB(PROGxx), se seu site seguiu as recomendações da IBM. Os conjuntos de dados de LPA são definidos em SYS1.PARMLIB(LPALSTxx).

Se você optar por utilizar o STEPLIB, deverá definir as bibliotecas não disponíveis por meio do LINKLIST/LPALIB na diretiva STEPLIB de rsed.envvars, no arquivo de configuração do RSE. Porém, lembre-se de que:

Definições LINKLIST para Outros Produtos

O cliente do Developer para System z possui um componente de geração de códigos chamado Enterprise Service Tools (EST). Para que o código gerado emita mensagens de erro de diagnóstico, todos os módulos IRZ* e IIRZ* da biblioteca de carregamento FEK.SFEKLOAD devem ser disponibilizados por meio do STEPLIB ou LINKLIST.

Os conjuntos de dados LINKLIST são definidos em SYS1.PARMLIB(PROGxx), se seu site seguiu as recomendações da IBM.

Se você optar por usar o STEPLIB, deverá definir as bibliotecas não disponíveis por meio do LINKLIST na diretiva STEPLIB da tarefa que executa o código (IMS ou tarefas em lote). Entretanto, lembre-se do seguinte:

Alterações do PROCLIB

Os procedimentos de construção remota e a tarefa iniciada listados a seguir devem residir em uma biblioteca de procedimentos do sistema definida para seu subsistema JES. Nas instruções a seguir, a biblioteca de procedimentos padrão da IBM, SYS1.PROCLIB, é usada.

JES Job Monitor

Customize o membro de tarefa iniciada de amostra FEK.#CUST.PROCLIB(JMON), conforme descrito no membro, e copie-o para SYS1.PROCLIB. Conforme mostrado na amostra de código abaixo, você deve fornecer o seguinte:

Figura 1. JMON - Tarefa Iniciada do JES Job Monitor
//*
//* JES JOB MONITOR
//*
//JMON     PROC PRM=,                  * PRM='-TV' TO START TRACING
//            LEPRM='RPTOPTS(ON)', 
//            HLQ=FEK,
//            CFG=FEK.#CUST.PARMLIB(FEJJCNFG)
//*
//JMON     EXEC PGM=FEJJMON,REGION=0M,TIME=NOLIMIT,
//            PARM=('&LEPRM,ENVAR("_CEE_ENVFILE_S=DD:ENVIRON")/&PRM')
//STEPLIB  DD DISP=SHR,DSN=&HLQ..SFEKAUTH
//ENVIRON  DD DISP=SHR,DSN=&CFG
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//         PEND
//*
Notas:
  1. Consulte o Comandos do Operador para obter informações adicionais sobre os parâmetros de inicialização.
  2. A JCL de amostra é enviada inicialmente como FEK.SFEKSAMP(FEJJJCL) e é renomeada para FEK.#CUST.PROCLIB(JMON) em Configuração da Customização.
  3. O rastreio também poderá ser controlado pelos comandos de console, conforme descrito no Comandos do Operador.
  4. Esta tarefa deve ser designada para SYSSTC ou ter objetivo equivalente no Workload Manager (WLM).
  5. A variável de ambiente LE _CEE_ENVFILE_S requer z/OS 1.8 ou versão mais alta. A variável pode ser substituída por _CEE_ENVFILE em níveis mais antigos do z/OS, mas devido a um erro no tempo de execução C, a variável TZ no arquivo de configuração do JES Job Monitor (FEJJCNFG) pode não ser interpretada corretamente.

Daemon RSE

Customize o membro de tarefa iniciada de amostra FEK.#CUST.PROCLIB(RSED), conforme descrito no membro, e copie-o para o SYS1.PROCLIB. Conforme mostrado na amostra de código abaixo, você deve fornecer o seguinte:

Figura 2. RSED - tarefa iniciada do daemon RSE
//*
//* RSE DAEMON
//*
//RSED     PROC IVP='',                        * 'IVP' to do an IVP test
//            PORT=4035,
//            HOME='/usr/lpp/rdz',
//            CNFG='/etc/rdz'
//*
//RSE      EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
//            PARM='PGM  &HOME/bin/rsed.sh &IVP &PORT &CNFG'
//STDERR   DD SYSOUT=*
//STDOUT   DD SYSOUT=*
//         PEND
//*
Nota:

Daemon de Bloqueio

Customize o membro de tarefa iniciada de amostra FEK.#CUST.PROCLIB(LOCKD), conforme descrito no membro, e copie-o para SYS1.PROCLIB. Conforme mostrado na amostra de código abaixo, você deve fornecer o seguinte:

Figura 3. LOCKD - Tarefa iniciada do daemon de bloqueio
//*
//* RSE LOCK DAEMON
//*
//LOCKD    PROC HOME='/usr/lpp/rdz',
//            CNFG='/etc/rdz',
//            LOG=1
//*
//LOCKD    EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
              PARM=PGM &HOME./bin/lockd.sh &CNFG &LOG'
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//         PEND
//*
Notas:
  1. Consulte o Comandos do Operador para obter informações adicionais sobre os parâmetros de inicialização.
  2. A JCL de amostra é enviada inicialmente como FEK.SFEKSAMP(FEKLOCKD) e é renomeada para FEK.#CUST.PROCLIB(LOCKD) em Configuração da Customização.
  3. Esta tarefa deve ser designada para SYSSTC ou ter objetivo equivalente no Workload Manager (WLM).

Limitações da JCL para a Variável PARM

O comprimento máximo para a variável PARM é de 100 caracteres, o que poderá causar problemas se você utilizar nomes de diretórios customizados. Para ignorar esse problema, você pode:

Procedimentos de Construção Remota ELAXF*

O Developer para System z fornece procedimentos JCL de amostra que podem ser usados para a geração de JCL, construções de projetos remotos e recursos de verificação de sintaxe remotos de mapas BMS do CICS, de telas MFS do IMS, de programas COBOL, PL/I, Assembler e C/C++. Esses procedimentos permitem que instalações apliquem seus próprios padrões e garante que os desenvolvedores utilizem os mesmos procedimentos com as mesmas opções e níveis do compilador.

Os procedimentos de amostra e suas funções são listados na Tabela 7.

Tabela 7. Procedimento ELAXF* de amostra
Membro Propósito
ELAXFADT Procedimento de amostra para montagem e depuração de programas assembler de Alto Nível.
ELAXFASM Procedimento de amostra para montagem de programas assembler de alto nível.
ELAXFBMS Procedimento de amostra para criação do objeto BMS do CICS e a cópia correspondente, dsect, ou incluir membro.
ELAXFCOC Procedimento de amostra para realizar compilações COBOL, conversão do CICS integrado e conversão do DB2 integrado.
ELAXFCOP Procedimento de amostra para realizar o pré-processamento DB2 das instruções EXEC de SQL incorporadas em programas COBOL.
ELAXFCOT Procedimento de amostra para realizar a conversão do CICS de instruções EXEC CICS incorporadas nos programas COBOL.
ELAXFCPC Procedimento de amostra para realizar compilações C.
ELAXFCPP Procedimento de amostra para realizar compilações C++.
ELAXFCP1 Procedimento de amostra para compilações COBOL com instruções de pré-processador SCM (-INC e ++INCLUDE).
ELAXFDCL Procedimento de amostra para executar um programa no modo TSO.
ELAXFGO Procedimento de amostra para a etapa IR.
ELAXFLNK Procedimento de amostra para vincular os programas assembler C/C++, COBOL, PLI e de Alto Nível.
ELAXFMFS Procedimento de amostra para criar telas IMS MFS.
ELAXFPLP Procedimento de amostra para realizar o pré-processamento DB2 de instruções EXEC de SQL incorporadas nos programas PLI.
ELAXFPLT Procedimento de amostra para realizar a conversão do CICS das instruções EXEC CICS incorporadas nos programas PLI.
ELAXFPL1 Procedimento de amostra para realizar compilações PL/I, conversão do CICS integrado e conversão do DB2 integrado.
ELAXFPP1 Procedimento de amostra para compilações PL/I com instruções de pré-processador SCM (-INC e ++INCLUDE).
ELAXFTSO Procedimento de amostra para executar/depurar código do DB2 gerado no modo TSO.
ELAXFUOP Procedimento de amostra para a geração da etapa UOPT ao construir programas que executam nos subsistemas CICS ou IMS.

Os nomes dos procedimentos e os nomes das etapas nos procedimentos correspondem às propriedades padrão que são fornecidas com o cliente Developer para System z. Se você decidir alterar o nome de um procedimento ou o nome de uma etapa em um procedimento, o arquivo de propriedades correspondente em todos os clientes também deverá ser atualizado. É recomendável que você não altere os nomes dos procedimentos e das etapas.

Customize os membros do procedimento de construção de amostra, FEK.#CUST.PROCLIB(ELAXF*), conforme descrito nos membros, e copie-os para SYS1.PROCLIB. Você deve fornecer os qualificadores de alto nível corretos para diferentes bibliotecas de produto, conforme descrito em Tabela 8.

Tabela 8. Lista de Verificação para Qualificadores de Alto Nível ELAXF*
Produto HLQ Padrão Valor
Developer para System z FEK
CICS CICSTS32.CICS
DB2 DSN910
IMS IMS
COBOL IGY.V4R1M0
PL/I IBMZ.V3R8M0
C/C++ CBC
LE CEE
LINKLIB do sistema SYS1
MACLIB do sistema SYS1

Se os procedimentos ELAXF* não puderem ser copiados para uma biblioteca de procedimentos de sistema, solicite aos usuários do Developer para System z incluírem uma placa JCLLIB (logo após a placa JOB) nas propriedades da tarefa no cliente.

//MYJOB    JOB <parâmetros_da_tarefa>
//PROCS JCLLIB ORDER=(FEK.#CUST.PROCLIB)

Definições de Segurança

Customize e envie o membro de amostra FEKRACF no conjunto de dados FEK.#CUST.JCL para criar as definições de segurança para o Developer para System z. O usuário que enviar essa tarefa deve ter privilégios de administrador de segurança, como sendo RACF SPECIAL.

Nota:

A seguinte lista das definições obrigatórias relacionadas a segurança para Developer para System z são discutidas em detalhe em Considerações sobre Segurança. Esse capítulo discute também aspectos gerais relacionados à segurança do Developer para System z, incluindo aspectos de segurança de produtos de requisito que não são abordados pela tarefa de amostra FEKRACF.

Nota:
A tarefa FEKRACF de amostra contém mais que apenas comandos do RACF. A última etapa das definições de segurança consiste em tornar um arquivo do z/OS UNIX controlado por programa. Dependendo das políticas em seu site, essa pode ser uma tarefa para o programador de sistema e não para o administrador de segurança.
Atenção: O pedido de conexão com o cliente falhará se a segurança do aplicativo e os PassTickets não estiverem configurados corretamente.

FEJJCNFG, Arquivo de Configuração do JES Job Monitor

O JES Job Monitor (JMON) fornece todos os serviços relacionados ao JES. O comportamento do JES Job Monitor pode ser controlado com as definições em FEJJCNFG.

O FEJJCNFG está localizado em FEK.#CUST.PARMLIB, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Customize o membro de configuração do JES Job Monitor de amostra FEJJCNFG, conforme mostrado na seguinte amostra. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado; não são permitidos comentários na mesma linha.

Nota:
A tarefa iniciada JMON deve ser reiniciada para assimilar as mudanças feitas.
Figura 6. FEJJCNFG, arquivo de configuração do JES Job Monitor
SERV_PORT=6715
TZ=EST5EDT
#_BPXK_SETIBMOPT_TRANSPORT=TCPIP
#APPLID=FEKAPPL
#AUTHMETHOD=SAF
#CODEPAGE=UTF-8
#CONCHAR=$
#CONSOLE_NAME=JMON
#GEN_CONSOLE_NAME=OFF
#HOST_CODEPAGE=IBM-1047
#LIMIT_COMMANDS=NOLIMIT
#LIMIT_VIEW=USERID
#LISTEN_QUEUE_LENGTH=5
#MAX_DATASETS=32
#MAX_THREADS=200
#TIMEOUT=3600
#TIMEOUT_INTERVAL=1200
#SUBMITMETHOD=TSO
#TSO_TEMPLATE=FEK.#CUST.CNTL(FEJTSO)
SERV_PORT

O número da porta para o servidor de host do JES Job Monitor. A porta padrão é 6715. Altere conforme desejado, no entanto, ambos servidor e os clientes Developer para System z devem ser configurados com o mesmo número de porta. Se você alterar o número da porta do servidor, todos os clientes também deverão alterar a porta do JES Job Monitor para este sistema na Visualização de Sistemas Remotos.

Nota:
  • Antes de selecionar uma porta, verifique se ela está disponível em seu sistema com os comandos do TSO NETSTAT e NETSTAT PORTL.
  • Ao utilizar um cliente da versão 7.1 ou posterior, toda a comunicação nesta porta é confinada para a sua máquina host z/OS.
TZ
Seletor de fuso horário. O padrão é EST5EDT. O fuso horário padrão é UTC +5 horas (horário de verão do horário padrão na costa leste dos Estados Unidos). Altere isso para representar seu fuso horário. Informações adicionais podem ser localizadas no UNIX System Services Command Reference (SA22-7802).

As definições a seguir são opcionais. Se omitidas, valores padrão serão usados conforme especificados abaixo:

_BPXK_SETIBMOPT_TRANSPORT
Especifica o nome da pilha TCPIP a ser utilizada. O padrão é TCPIP. Remova o comentário e altere para o nome de pilha TCPIP solicitado, conforme definido na instrução TCPIPJOBNAME no TCPIP.DATA relacionado.
Nota:
  • Codificar uma instrução SYSTCPD DD no servidor JCL não configura a afinidade de pilha solicitada.
  • Quando esta diretiva não está ativa, o JES Job Monitor se liga a cada pilha disponível no sistema (BIND INADDRANY).
APLICADO
Especifica o identificador do aplicativo usado para identificar o JES Job Monitor para seu software de segurança. O padrão é FEKAPPL. Remova o comentário e altere para o ID do aplicativo desejado.
Nota:
Esse valor deve corresponder ao ID do aplicativo configurado para o RSE no arquivo de configuração rsed.envvars. Se esses valores forem diferentes, o RSE não pode conectar o cliente ao JES Job Monitor.
AUTHMETHOD
O padrão é SAF, o que significa que a interface de segurança System Authorization Facility (SAF) é usada. Não faça alterações, a menos que você seja orientado pelo centro de suporte da IBM.
CODEPAGE
A página de códigos da estação de trabalho. O padrão é UTF-8. A página de códigos da estação de trabalho é configurada como UTF-8 e geralmente não deve ser alterada. Talvez seja necessário remover o comentário da diretiva e alterar UTF-8 para corresponder à página de códigos da estação de trabalho, se você tiver dificuldades com os caracteres NLS, como o símbolo da moeda.
CONCHAR
Especifica o caractere de comando do console do JES. CONCHAR tem CONCHAR=$ como padrão para JES2, ou CONCHAR=* para JES3. Remova o comentário e altere para o caractere do comando solicitado.
CONSOLE_NAME
Especifica o nome do console do EMCS usado para emitir comandos com relação a tarefas (Suspender, Liberar, Cancelar e Limpar). O padrão é JMON. Remova o comentário e altere para o nome de console desejado, utilizando as diretrizes a seguir.

Independentemente do nome de console usado, o ID de usuário cliente que solicita o comando é usado como a LU do console, deixando um rastreio nas mensagens IEA630I e IEA631 do syslog.

IEA630I OPERATOR console NOW ACTIVE,
SYSTEM=sysid, LU=id
IEA631I OPERATOR console NOW INACTIVE, SYSTEM=sysid, LU=id
GEN_CONSOLE_NAME
Ativa ou desativa a geração automática de nomes de consoles alternativos. O padrão é OFF. Remova o comentário e altere para ON para ativar nomes de console alternativos.

Esta diretiva somente é usada quando CONSOLE_NAME é igual a &SYSUID e o ID do usuário não está disponível no console.

Se GEN_CONSOLE_NAME=ON, um nome de console alternativo é gerado, anexando um único dígito numérico ao ID do usuário. Os dígitos 0 a 9 são tentados. Se nenhum console disponível for localizado, o comando emitido pelo cliente falha.

Se GEN_CONSOLE_NAME=OFF, o comando emitido pelo cliente falha.

Nota:
As únicas configurações válidas são ON e OFF.
HOST_CODEPAGE
A página de códigos do host. O padrão é IBM-1047. Remova o comentário e altere para estabelecer correspondência com a página de códigos do host.

A partir da versão 7.6.1, os clientes do Developer para System z ignoram o valor do HOST_CODEPAGE especificado aqui e usam a página de códigos especificada localmente nas propriedades do subsistema "MVS Files".

Nota:
Até mesmo para clientes recentes, o JES Job Monitor usará a página de códigos do host especificada no HOST_CODEPAGE durante a configuração inicial de comunicação do cliente inicial.
LIMIT_COMMANDS
Define em que tarefas o usuário pode emitir comandos JES selecionados (Mostrar JCL, Suspender, Liberar, Cancelar e Limpar). O padrão (LIMIT_COMMANDS=USERID) limita os comandos às tarefas que pertencem ao usuário. Remova o comentário dessa diretiva e especifique LIMITED ou NOLIMIT para permitir que o usuário emita comandos em relação a todos os arquivos em spool, se for permitido pelo produto de segurança.
Tabela 9. 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
Nota:
As únicas configurações válidas são USERID, LIMITED e NOLIMIT.
LIMIT_VIEW
Define qual saída o usuário pode visualizar. O padrão (LIMIT_VIEW=NOLIMIT) permite que o usuário visualize todas as saídas do JES, se for permitido pelo produto de segurança. Remova o comentário dessa diretiva e especifique USERID para limitar a visualização à saída que pertence ao usuário.
Nota:
As únicas configurações válidas são USERID e NOLIMIT.
LISTEN_QUEUE_LENGTH
O comprimento da fila de atendimento do TCP/IP. O padrão é 5. Não faça alterações, a menos que você seja orientado pelo centro de suporte da IBM.
MAX_DATASETS
O número máximo de conjuntos de dados de saída em spool que o JES Job Monitor retornará para o cliente (por exemplo, SYSOUT, SYSPRINT, SYS00001 e assim por diante). O padrão é 32. O valor máximo é 2147483647.
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.
TIMEOUT
O período de tempo, em segundos, antes que um encadeamento seja eliminado devido à falta de interação com o cliente. O padrão é 3600 (1 hora). O valor máximo é 2147483647. TIMEOUT=0 desativa a função.
TIMEOUT_INTERVAL
O número de segundos entre as verificações de tempo limite. O padrão é 1200. O valor máximo é 2147483647.
SUBMITMETHOD=TSO
Enviar tarefas por meio do TSO. O padrão (SUBMITMETHOD=JES) envia jobs diretamente para o JES. Remova o comentário dessa diretiva e especifique TSO para enviar a tarefa através do comando TSO SUBMIT. Esse método permite que saídas do TSO sejam invocadas, porém, ele prejudica o desempenho e, por essa razão, não é recomendado.
Nota:
  • As únicas configurações válidas são TSO e JES.
  • Se SUBMITMETHOD=TSO for especificado, então TSO_TEMPLATE também deve ser definido.
TSO_TEMPLATE
JCL do wrapper para envio de tarefa através de TSO. O valor padrão é FEK.#CUST.CNTL(FEJTSO). Esta instrução faz referência ao nome completo do membro da JCL a ser usado como um wrapper para o envio TSO. Consulte a instrução SUBMITMETHOD para obter informações adicionais.
Nota:
  • Uma tarefa do wrapper de amostra é fornecida em FEK.#CUST.CNTL(FEJTSO). Consulte este membro para obter informações adicionais sobre a customização necessária.
  • TSO_TEMPLATE não possui nenhum efeito a menos que SUBMITMETHOD=TSO também seja especificado.

Arquivo de Configuração do RSE rsed.envvars

Os processos de daemon de bloqueio RSE e de servidor RSE (daemon RSE, conjunto de encadeamentos do RSE e servidor RSE) usam as definições em rsed.envvars. Serviços opcionais do Developer para System z e de terceiros também podem utilizar esse arquivo de configuração para definir variáveis de ambiente para seu uso.

O RSE (Explorador de Sistemas Remotos) fornece os serviços principais, como conectar o cliente ao host e iniciar outros servidores para serviços específicos. O daemon de bloqueio fornece serviços de rastreamento para bloqueios de conjuntos de dados.

O rsed.envvars está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Consulte o seguinte arquivo de amostra rsed.envvars, que deve ser customizado para corresponder ao ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado; não são permitidos comentários na mesma linha. As continuações de linha e os espaços ao redor do sinal de igual (=) não são suportadas.

Nota:
As tarefas iniciadas RSED e LOCKD devem ser reiniciadas para assimilar as mudanças feitas.
Figura 7. rsed.envvars - Arquivo de configuração do RSE
#=============================================================
# (1) definições necessárias
JAVA_HOME=/usr/lpp/java/J5.0
RSE_HOME=/usr/lpp/rdz
_RSE_LOCKD_PORT=4036
_RSE_HOST_CODEPAGE=IBM-1047
TZ=EST5EDT
LANG=C
PATH=/bin:/usr/sbin
_CEE_DMPTARG=/tmp
STEPLIB=NONE
#STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
_RSE_SAF_CLASS=/usr/include/java_classes/IRRRacf.jar
_RSE_JAVAOPTS=""
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms1m -Xmx256m"
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddaemon.log=/var/rdz/logs"
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.log=/var/rdz/logs"
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_LOG_DIRECTORY="
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=60"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threads=1000"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dminimum.threadpool.process=1"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threadpool.process=100"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dipv6=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dkeep.last.log=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.standard.log=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.port.of.entry=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.certificate.mapping=false"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.automount=true" 
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.audit.log=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.cycle=30"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.retention.period=0"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddeny.nonzero.port=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dsingle.logon=false"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dprocess.cleanup.interval=0"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DAPPLID=FEKAPPL"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDENY_PASSWORD_SAVE=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DHIDE_ZOS_UNIX=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IDLE_SHUTDOWN_TIMEOUT=3600000"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_TRACING_ON=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_MEMLOGGING_ON=true"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
#=============================================================
# (2) definições necessárias para TSO/ISPF Client Gateway
_CMDSERV_BASE_HOME=/usr/lpp/ispf
_CMDSERV_CONF_HOME=/etc/rdz
_CMDSERV_WORK_HOME=/var/rdz
#STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB
_RSE_CMDSERV_OPTS=""
#_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS&ISPPROF=&SYSUID..ISPPROF" 
#============================================================= 
# (3) definições necessárias para SCLM Developer Toolkit 
_SCLMDT_CONF_HOME=/var/rdz/sclmdt   
#STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD  
#_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE  
#ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1  
#=============================================================  
# (4) definições opcionais  
#_RSE_PORTRANGE=8108-8118  
#_BPXK_SETIBMOPT_TRANSPORT=TCPIP  
#_FEKFSCMD_TP_NAME_=FEKFRSRV 
#_FEKFSCMD_PARTNER_LU_=lu_name 
#GSK_CRL_SECURITY_LEVEL=HIGH 
#GSK_LDAP_SERVER=ldap_server_url 
#GSK_LDAP_PORT=ldap_server_port 
#GSK_LDAP_USER=ldap_userid 
#GSK_LDAP_PASSWORD=ldap_server_password 
#============================================================= 
Figura 8. (continuação)
# (5) não alterar, a menos que seja orientado pelo centro de suporte da IBM 
_CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" 
_BPX_SHAREAS=YES 
_BPX_SPAWN_SCRIPT=YES 
JAVA_PROPAGATE=NO 
RSE_LIB=$RSE_HOME/lib 
PATH=.:$JAVA_HOME/bin:$RSE_HOME/bin:$_CMDSERV_BASE_HOME/bin:$PATH 
LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$RSE_LIB:$RSE_LIB/icuc 
LIBPATH=.:/usr/lib:$LIBPATH 
CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/zosserver.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_miners.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/universalminers.jar:$RSE_LIB/mvsminers.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/carma.jar:$RSE_LIB/luceneminer.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/mvsluceneminer.jar:$RSE_LIB/cdzminer.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/mvscdzminer.jar:$RSE_LIB/jesminers.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/FAMiner.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/mvsutil.jar:$RSE_LIB/jesutils.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/lucene-core-2.3.2.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/cdtparser.jar 
CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar 
CLASSPATH=$CLASSPATH:$_RSE_SAF_CLASS 
CLASSPATH=.:$CLASSPATH 
_RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DISPF_OPTS='$_RSE_CMDSERV_OPTS'" 
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DA_PLUGIN_PATH=$RSE_LIB"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xbootclasspath/p:$RSE_LIB/bidiTools.jar"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dfile.encoding=$_RSE_HOST_CODEPAGE" 
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dconsole.encoding=$_RSE_HOST_CODEPAGE"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_SPIRIT_ON=true"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_EXPIRY_TIME=6" 
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_INTERVAL_TIME=6"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dcom.ibm.cacheLocalHost=true"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" 
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlow.heap.usage.ratio=15"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.heap.usage.ratio=40"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_ENABLED=true"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_RESPONSE_TIMEOUT=30000" 
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IO_SOCKET_READ_TIMEOUT=90000"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DRSECOMM_LOGFILE_MAX=0"
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.port=$_RSE_LOCKD_PORT"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.cleanup.interval=1440"  
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion"  
_RSE_SERVER_CLASS=org.eclipse.dstore.core.server.Server  
_RSE_DAEMON_CLASS=com.ibm.etools.zos.server.RseDaemon  
_RSE_POOL_SERVER_CLASS=com.ibm.etools.zos.server.ThreadPoolProcess  
_RSE_LOCKD_CLASS=com.ibm.ftt.rse.mvs.server.miners.MVSLockDaemon 
_RSE_SERVER_TIMEOUT=120000 
_SCLMDT_BASE_HOME=$RSE_HOME 
_SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME 
CGI_DTWORK=$_SCLMDT_WORK_HOME 
#============================================================= 
# (6) variáveis adicionais de ambiente
Nota:
Links simbólicos são permitidos ao especificar diretórios em rsed.envvars.

As seguintes definições são requeridas:

JAVA_HOME
Diretório inicial Java. O padrão é /usr/lpp/java/J5.0. Altere para corresponder com a sua instalação doJava.
RSE_HOME
Diretório inicial do RSE. O padrão é /usr/lpp/rdz. Altere para corresponder à instalação do Developer para System z.
_RSE_LOCKD_PORT
Número da porta do daemon de bloqueio RSE. O padrão é 4036. Pode ser alterado, se desejado.
Nota:
  • Antes de selecionar uma porta, verifique se ela está disponível em seu sistema com os comandos do TSO NETSTAT e NETSTAT PORTL.
  • Toda a comunicação nesta porta está confinada à máquina host do z/OS.
_RSE_HOST_CODEPAGE
A página de códigos do host. O padrão é IBM-1047. Altere para corresponder à página de códigos do host.
TZ
Seletor de fuso horário. O padrão é EST5EDT. O fuso horário padrão é UTC +5 horas (horário de verão do horário padrão na costa leste dos Estados Unidos). Altere para corresponder ao fuso horário.

Informações adicionais podem ser localizadas no UNIX System Services Command Reference (SA22-7802).

LANG
Especifica o nome do código do idioma padrão. O padrão é C. O C especifica o código do idioma POSIX e (por exemplo) Ja_JP especifica o código do idioma japonês. Altere para corresponder ao código do idioma.
PATH
Caminho de comandos. O padrão é /bin:/usr/sbin:.. Pode ser alterado, se desejado.
_CEE_DMPTARG
Local de dump do Language Environment (LE) do z/OS UNIX usado pela Java Virtual Machine (JVM). O padrão é /tmp.
STEPLIB
Acesse conjuntos de dados MVS que não estão no LINKLIST/LPALIB. O padrão é NONE.

Você pode ignorar a necessidade de ter bibliotecas (pré-requisito) no LINKLIST/LPALIB removendo o comentário e customizando uma ou mais das seguintes diretivas STEPLIB. Consulte o Alterações PARMLIB para obter informações adicionais sobre o uso das bibliotecas listadas abaixo:

STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB
STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD
Nota:
  • A utilização de STEPLIB no z/OS UNIX tem um impacto de desempenho negativo.
  • Se uma biblioteca STEPLIB for autorizada pelo APF, todas deverão ser autorizadas. As bibliotecas perderão sua autorização do APF se forem combinadas com bibliotecas não-autorizadas pelo STEPLIB.
  • As bibliotecas que são designadas para a colocação de LPA podem exigir controle de programa adicional e autorizações de APF se elas forem acessadas por meio de LINKLIST ou STEPLIB.
  • Codificar uma instrução STEPLIB DD no servidor JCL não configura a concatenação de STEPLIB necessária.
RSE_SAF_CLASS
Especifica a interface Java para seu produto de segurança. O padrão é /usr/include/java_classes/IRRRacf.jar. Altere para corresponder à configuração do software de segurança.
Nota:
A partir do z/OS 1.10, o /usr/include/java_classes/IRRRacf.jar que faz parte do SAF, fornecido com o z/OS de base, também estará disponível para clientes não-RACF.
RSE_JAVAOPTS
Opções Java adicionais específicas do RSE. . Consulte o Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS para obter informações adicionais sobre esta definição.

O Developer para System z utiliza o TSO/ISPF Client Gateway do ISPF por padrão para o serviço TSO Commands. Uma transação APPC é usada quando a seguinte opção _RSE_JAVAOPTS está sem comentários:

RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"

As definições a seguir são necessárias se o TSO/ISPF Client Gateway do ISPF for usado para o serviço TSO Commands, SCLM Developer Toolkit ou CARMA.

_CMDSERV_BASE_HOME
Diretório inicial para o código do ISPF que fornece o serviço TSO/ISPF Client Gateway. O padrão é /usr/lpp/ispf. Altere para corresponder à instalação do ISPF. Essa diretiva será necessária apenas se o TSO/ISPF Client Gateway do ISPF for usado.
_CMDSERV_CONF_HOME
Diretório de configuração base do ISPF. O padrão é /etc/rdz. Altere para corresponder ao local do ISPF.conf, o arquivo de customização do Gateway do Cliente TSO/ISPF. Essa diretiva será necessária apenas se o TSO/ISPF Client Gateway do ISPF for usado.
_CMDSERV_WORK_HOME
Diretório de trabalho base do ISPF. O padrão é /var/rdz. Altere para corresponder ao local do diretório WORKAREA usado pelo TSO/ISPF Client Gateway. Essa diretiva será necessária apenas se o TSO/ISPF Client Gateway do ISPF for usado.

Notas:

STEPLIB
STEPLIB está descrito anteriormente na seção de definições necessárias.
RSE_CMDSERV_OPTS
Opções Java adicionais específicas do TSO/ISPF Client Gateway. O padrão é "". Consulte o Definindo Parâmetros Extras de Inicialização Java com _RSE_CMDSERV_OPTS para obter informações adicionais sobre esta definição. Essa diretiva será necessária apenas se o TSO/ISPF Client Gateway do ISPF for usado.

As definições a seguir são necessárias se o SCLM Developer Toolkit for utilizado.

SCLMDT_CONF_HOME
Diretório de configuração base do SCLM Developer Toolkit. O padrão é /var/rdz/sclmdt. Altere para corresponder ao local do diretório CONFIG usado pelo SCLMDT para armazenar informações do projeto SCLM. Essa diretiva é necessária apenas quando o SCLMDT for usado.
Nota:
SCLMDT incluirá /CONFIG e /CONFIG/PROJECT ao caminho especificado em SCLMDT_CNF_HOME. Não o inclua você próprio.
STEPLIB
STEPLIB está descrito anteriormente na seção de definições necessárias.
_SCLMDT_TRANTABLE
Nome do VSAM de tradução de nomes completos/abreviados. O padrão é FEK.#CUST.LSTRANS.FILE. Remova o comentário e altere para corresponder ao nome usado na tarefa de amostra do SCLM ISP.SISPSAMP(FLM02LST). Essa diretiva será necessária apenas se a tradução do nome completo/abreviado no SCLM Developer Toolkit for usada.
ANT_HOME
Diretório inicial da instalação Ant. O padrão é /usr/lpp/Apache/Ant/apache-ant-1.7.1. Altere para corresponder à instalação Ant. Essa diretiva será necessária apenas se o suporte para construção JAVA/J2EE for utilizado com o SCLM Developer Toolkit.

As definições a seguir são opcionais. Se forem omitidas, os valores padrão serão usados:

_RSE_PORTRANGE
Especifica o intervalo de portas que o servidor RSE pode abrir para comunicação com um cliente. Qualquer porta pode ser usada por padrão. Consulte o Definindo o PORTRANGE Disponível para o Servidor RSE para obter informações adicionais sobre esta definição. Essa é uma diretiva opcional.
_BPXK_SETIBMOPT_TRANSPORT
Especifica o nome da pilha TCP/IP a ser usada. O padrão é TCPIP. Remova o comentário e altere para o nome da pilha TCP/IP solicitado, conforme definido na instrução TCPIPJOBNAME no TCPIP.DATA relacionado Essa é uma diretiva opcional.
Nota:
  • Codificar uma instrução SYSTCPD DD no servidor JCL não configura a afinidade de pilha solicitada.
  • Quando esta diretiva não está ativa, o RSE se liga a cada pilha disponível no sistema (BIND INADDRANY).
_FEKFSCMD_TP_NAME_
Nome do programa de transações APPC. O valor padrão é FEKFRSRV. Remova o comentário e altere esta definição se você não utilizar o nome padrão do programa de transações ao definir a transação APPC. Essa é uma diretiva opcional.
_FEKFSCMD_PARTNER_LU_
Force o servidor RSE a utilizar esta LU de parceiro APPC. O padrão é a LU de base especificada durante a configuração de APPC. Esta é uma diretiva opcional.
GSK_CRL_SECURITY_LEVEL
Especifica o nível de segurança que os aplicativos SSL usarão ao contatar servidores LDAP para verificar CRLs para certificados revogados durante a validação de certificado. O padrão é MEDIUM. Remova o comentário e altere para impingir o uso do valor especificado. Essa é uma diretiva opcional. Os valores a seguir são válidos:
Nota:
Esta diretiva exige z/OS 1.9 ou superior.
GSK_LDAP_SERVER
Especifica um ou mais nomes de hosts de servidores LDAP separados por espaços em branco. Remova o comentário e altere para impingir o uso dos servidores LDAP especificados para obter sua CRL. Essa é uma diretiva opcional.

O nome do host pode ser um endereço TCP/IP ou uma URL. Cada nome de host pode conter um número de porta opcional separado do nome do host por dois pontos (:).

GSK_LDAP_PORT
Especifica a porta do servidor LDAP. O padrão é 389. Remova o comentário e altere para impingir o uso do valor especificado. Essa é uma diretiva opcional.
GSK_LDAP_USER
Especifica o nome distinto a usar ao conectar ao servidor LDAP. Remova o comentário e altere para impingir o uso do valor especificado. Essa é uma diretiva opcional.
GSK_LDAP_PASSWORD
Especifica a senha a usar ao conectar ao servidor LDAP. Remova o comentário e altere para impingir o uso do valor especificado. Essa é uma diretiva opcional.

As definições a seguir são necessárias e não devem ser alteradas, a menos que você seja orientado pelo centro de suporte da IBM:

_CEE_RUNOPTS
Opções de tempo de execução do LE (Language Environment). O padrão é "ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)". Não modifique.
_BPX_SHAREAS
Executar processos em primeiro plano no mesmo espaço de endereço que o shell. O padrão é YES. Não modifique.
_BPX_SPAWN_SCRIPT
Execute scripts de shell diretamente da função spawn(). O padrão é YES. Não modifique.
JAVA_PROPAGATE
Propaga o contexto de segurança e de carga de trabalho durante a criação do encadeamento (apenas Java versão 1.4 e mais antiga). O padrão é NO. Não modifique.
RSE_LIB
Caminho da biblioteca RSE. O padrão é $RSE_HOME/lib. Não modifique.
PATH
Caminho de comandos. O padrão é .:$JAVA_HOME/bin:$RSE_HOME/bin:$_CMDSERV_BASE_HOME/bin:$PATH. Não modifique.
LIBPATH
Caminho de bibliotecas. O padrão é longo demais para repetir. Não modifique.
CLASSPATH
Caminho de classes. O padrão é longo demais para repetir. Não modifique.
_RSE_CMDSERV_OPTS
Opções Java adicionais específicas do serviço Comandos do TSO. O padrão é "&SESSION=SPAWN$_RSE_CMDSERV_OPTS". Não modifique.
_RSE_JAVAOPTS
Opções Java adicionais específicas do RSE. O padrão é longo demais para repetir. Não modifique.
_RSE_SERVER_CLASS
Classe Java do servidor RSE. O padrão é org.eclipse.dstore.core.server.Server. Não modifique.
_RSE_DAEMON_CLASS
Classe Java para o daemon RSE. O padrão é com.ibm.etools.zos.server.RseDaemon. Não modifique.
_RSE_POOL_SERVER_CLASS
Classe Java para o conjunto de encadeamentos do RSE. O padrão é com.ibm.etools.zos.server.ThreadPoolProcess. Não modifique.
_RSE_LOCKD_CLASS
Classe Java para o daemon de bloqueio RSE. O padrão é com.ibm.ftt.rse.mvs.server.miners.MVSLockDaemon. Não modifique.
_RSE_SERVER_TIMEOUT
Valor de tempo limite do servidor RSE (aguardando o cliente) em milissegundos. O padrão é 120000 (2 minutos). Não modifique.
SCLMDT_BASE_HOME
Diretório inicial para o código do SCLM Developer Toolkit. O padrão é $RSE_HOME. Não modifique.
SCLMDT_WORK_HOME
Diretório de trabalho base do SCLM Developer Toolkit. O padrão é $_CMDSERV_WORK_HOME. Não modifique.
CGI_DTWORK
Suporte do SCLM Developer Toolkit para clientes antigos. O padrão é $_SCLMDT_WORK_HOME. Não modifique.

Definindo o PORTRANGE Disponível para o Servidor RSE

Essa é uma parte da customização de rsed.envvars que especifica as portas nas quais o servidor RSE pode se comunicar com o cliente. 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 a conexão do cliente. 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:

Para especificar o intervalo de portas para o cliente se comunicar com o z/OS, remova o comentário e customize a seguinte linha no rsed.envvars:

#_RSE_PORTRANGE=8108-8118
Nota:
Antes de selecionar um intervalo de portas, verifique se o intervalo está disponível em seu sistema com os comandos NETSTAT e NETSTAT PORTL.

O formato do PORTRANGE é: _RSE_PORTRANGE=min-max (max é não-inclusivo; por exemplo, _RSE_PORTRANGE=8108-8118 significa que números de porta de 8108 a 8117 são utilizáveis). O número da porta usado pelo servidor RSE é determinado na seguinte ordem:

  1. Se um número de porta diferente de zero for especificado nas propriedades do subsistema no cliente, o número de porta especificado será usado. Se a porta não estiver disponível, a conexão falhará. Esta configuração não é recomendada.
    Nota:
    O host pode negar este tipo de pedido de conexão ao especificar a diretiva deny.nonzero.port=true em rsed.envvars. Consulte o Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS para obter informações adicionais sobre esta diretiva.
  2. Se o número de porta nas propriedades do subsistema for 0, e se _RSE_PORTRANGE for especificado no rsed.envvars, o intervalo de portas especificado pelo _RSE_PORTRANGE será usado. Se nenhuma porta no intervalo estiver disponível, a conexão falhará.
  3. Se o número de porta nas propriedades do subsistema for 0, e _RSE_PORTRANGE não for especificado no rsed.envvars, nenhuma porta disponível será usada.
Nota:
Quando um servidor abrir uma porta e estiver atendendo, o número da porta não poderá ser utilizado por outro servidor, porém, depois de conectado, o mesmo número de porta poderá ser utilizado novamente. Isso significa que o número de portas no intervalo não limita o número de usuários conectados simultaneamente.

Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS

Com as diferentes diretivas _RSE_*OPTS, rsed.envvars oferece a possibilidade de fornecer parâmetros extras para Java ao iniciar os processos RSE. As opções de amostra incluídas em rsed.envvars podem ser ativadas pela remoção dos comentários.

_RSE_JAVAOPTS define opções Java padrão e específicas do RSE.

_RSE_JAVAOPTS=""
Inicialização variável. Não modifique.
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms1m -Xmx256m"
Defina o tamanho de heap inicial (Xms) e máximo (Xmx). Os padrões são 1M e 256M, respectivamente. Altere para aplicar os valores de tamanho de heap desejados. Se esta diretiva for comentada a linha, os valores padrão Java, que são 4M e 512M respectivamente, (1M e 64M para Java 5.0) serão usados.
Nota:
Consulte o Definições de Recursos Principais para determinar os valores ideais para essa diretiva.
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddaemon.log=/var/rdz/logs"
Diretório que contém o daemon RSE, a criação de log de servidor e os dados de auditoria do RSE. O padrão é /var/rdz/logs. Altere para aplicar o local desejado. Se essa diretiva for comentada, o diretório inicial do ID de usuário designado ao daemon RSE será usado. O diretório inicial é definido no segmento de segurança OMVS do ID do usuário.
Nota:
Se esta diretiva (ou sua contraparte, o diretório inicial) não especificar um caminho absoluto (o caminho não inicia com uma barra (/)), o local real do log é relativo ao diretório de configuração (pelo padrão /etc/rdz).
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.log=/var/rdz/logs"
Diretório que conduz aos logs específicos do usuário. O padrão é /var/rdz/logs. Altere para aplicar o local desejado. Se essa diretiva for comentada, o diretório inicial do ID do usuário cliente será usado. O diretório inicial é definido no segmento de segurança OMVS do ID do usuário.
Nota:
  • Se esta diretiva (ou sua contraparte, o diretório inicial) não especificar um caminho absoluto (o caminho não inicia com uma barra (/)), o local real do log é ralativo ao diretório de configuração (pelo padrão /etc/rdz).
  • O caminho completo para os logs do usuário é userlog/dstorelog/$LOGNAME/, em que userlog é o valor da diretiva user.log, dstorelog é o valor da diretiva DSTORE_LOG_DIRECTORY e $LOGNAME é o ID do usuário do cliente, em maiúsculas.
  • Assegure-se de que os bits de permissão para userlog/dstorelog estejam configurados de modo que cada cliente possa criar $LOGNAME.
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_LOG_DIRECTORY="
Esse diretório está anexado ao caminho especificado na diretiva user.log. Juntos, eles criam o caminho que conduz aos logs específicos do usuário. O padrão é null-string. Altere para impingir o uso do diretório especificado. Se essa diretiva for comentada, .eclipse/RSE/ será usado.
Nota:
  • O caminho completo para os logs do usuário é userlog/dstorelog/$LOGNAME/, em que userlog é o valor da diretiva user.log, dstorelog é o valor da diretiva DSTORE_LOG_DIRECTORY e $LOGNAME é o ID do usuário do cliente, em maiúsculas.
  • O diretório especificado aqui é relativo ao diretório especificado em user.log e, dessa forma, pode não começar com uma barra (/).
  • Assegure-se de que os bits de permissão para userlog/dstorelog estejam configurados de modo que cada cliente possa criar $LOGNAME.

As diretivas a seguir são comentadas por padrão.

#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=60"
Quantidade máxima de clientes atendidos por um conjunto de encadeamentos. O padrão é 60. 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=1000"
Valor máximo dos encadeamentos ativos em um conjunto de encadeamentos para permitir clientes novos. O padrão é 1000. 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. Observe que cada conexão do cliente usa vários encadeamentos (16 ou mais) e que outros limites podem impedir 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.
#_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.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dipv6=true"
Versão TCP/IP. O padrão é false, significando que uma interface IPv4 será usada Remova o comentário e especifique true para utilizar uma interface IPv6.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dkeep.last.log=true"
Mantenha uma cópia dos arquivos de log do host pertencentes à sessão anterior. O padrão é false. Remova o comentário e especifique true para renomear os arquivos de log anteriores para *.last durante a inicialização do servidor e a conexão do cliente.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.standard.log=true"
Grave os fluxos stdout e stderr dos conjuntos de encadeamento em um arquivo de log. O padrão é false. Remova o comentário e especifique true para salvar os fluxos stdout e stderr. Os arquivos de log resultantes estão localizados no diretório mencionado pela diretiva daemon.log.
Nota:
  • O comando do operador MODIFY RSESTANDARDLOG pode ser usado para parar e iniciar dinamicamente a atualização dos arquivos de log de fluxo.
  • Não haverá arquivos de log stdout.log e stderr.log específicos do usuário quando a diretiva enable.standard.log estiver ativa. Os dados específicos do usuário são gravados agora no fluxo do conjunto de encadeamento do RSE correspondente.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.port.of.entry=true"
Opção de verificação de Port Of Entry (POE). O padrão é false. Remova o comentário e especifique true para aplicar a verificação de POE para conexões do cliente. Durante a verificação de POE, o endereço IP do cliente é mapeado para uma zona de segurança de rede por seu software de segurança. O ID de usuário cliente deve ter permissão para utilizar o perfil que define a zona de segurança.
Nota:
  • A verificação de POE também deve ser ativada no produto de segurança.
  • A ativação da verificação de POE também ficará disponível para outros serviços z/OS UNIX, como INETD.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.certificate.mapping=false"
Use seu software de segurança para autenticar um logon com um certificado X.509. O padrão é true. Remova o comentário e especifique false para que o daemon RSE faça a autenticação sem depender do suporte do X.509 de seu software de segurança.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.automount=true"
Suporte diretórios iniciais criados pela montagem automática do z/OS UNIX. O padrão é false. Remova o comentário e especifique true para assegurar que a montagem automática do z/OS UNIX usa o ID de usuário cliente como proprietário do diretório.
Nota:
A montagem automática do z/OS UNIX usa o ID do usuário do processo que invocou o serviço ao criar um sistema de arquivo. Se esta opção estiver desativada, este processo será o servidor do conjunto de encadeamentos RSE (STCRSE do ID do usuário). Se esta opção estiver ativada, um novo processo temporário será criado usando o ID de usuário cliente antes de invocar o serviço.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.audit.log=true"
Opção de auditoria. O padrão é false. Remova o comentário e especifique true para aplicar o log de auditoria de ações feitas pelos clientes. Os logs de auditoria são gravados no local do log do daemon RSE. Consulte a opção daemon.log da variável _RSE_JAVAOPTS para saber onde ela está.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.cycle=30"
Número de dias armazenado no arquivo de log de auditoria 1. O padrão é 30. Remova o comentário e customize para controlar quantos dados de auditoria serão gravados no arquivo de log de auditoria 1. O valor máximo é 365.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.retention.period=0"
Número de dias durante os quais os logs de auditoria são mantidos. O padrão é 0 (sem limite). Remova o comentário e customize para excluir logs de auditoria após um determinado número de dias. O valor máximo é 365.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddeny.nonzero.port=true"
Desaprove o cliente escolher um número de porta de comunicação. O padrão é false. Remova o comentário e especifique true para recusar conexões em que o cliente especifica qual porta do host deve ser usada pelo servidor RSE para a conexão. Consulte o Definindo o PORTRANGE Disponível para o Servidor RSE para obter informações adicionais.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dsingle.logon=false"
Desaprove um ID do usuário efetuar logon em múltiplos horários. O padrão é true. Remova o comentário e especifique false para permitir que um usuário efetue logon múltiplas vezes em um único daemon RSE.
Nota:
Uma segunda tentativa de efetuar logon fará com que a primeira seja cancelada pelo host, se esta diretiva não estiver ativa ou configurada como false. Este cancelamento será acompanhado pela mensagem do console FEK210I.
RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dprocess.cleanup.interval=0"
Remova automaticamente os conjuntos de encadeamentos RSE que estão em um estado de erro irrecuperável. Pelo padrão, conjuntos de encadeamentos RSE com erro não são removidos automaticamente. Remova o comentário e customize para remover automaticamente servidores dos conjuntos de encadeamentos RSE errados a cada intervalo (unidade de intervalos em segundos). Especificar 0 desativa a função.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DAPPLID=FEKAPPL"
ID do aplicativo do servidor RSE. O padrão é FEKAPPL. Remova o comentário e customize essa opção para impingir o uso do ID do aplicativo desejado.
Nota:
  • O ID do aplicativo deve ser definido para seu software de segurança. Se isso não for feito, o cliente não poderá efetuar logon.
  • Consulte Usando os PassTickets para obter informações sobre implicações de segurança ao alterar este valor.
  • O ID do aplicativo deve corresponder ao ID do aplicativo usado pelo JES Job Monitor. Consulte FEJJCNFG, Arquivo de Configuração do JES Job Monitor para aprender como definir o ID do aplicativo para JES Job Monitor.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDENY_PASSWORD_SAVE=true"
Opção de salvamento de senha. O padrão é false. Remova o comentário e especifique true para evitar que os usuários salvem suas senhas de host no cliente. As senhas salvas anteriormente serão removidas. Essa opção funciona apenas com clientes da versão 7.1 e superior.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DHIDE_ZOS_UNIX=true"
Oculte a opção z/OS UNIX. O padrão é false. Remova o comentário e especifique true para evitar que os usuários vejam os elementos z/OS UNIX (estrutura de diretórios e linha de comandos) no cliente. Essa opção funciona apenas com clientes da versão 7.6 e superior.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IDLE_SHUTDOWN_TIMEOUT=3600000"
Desconecte clientes inativos. Por padrão, os clientes inativos não são desconectados. Remova o comentário e customize para desconectar os clientes que estão inativos pelo total listado de milissegundos (3600000 igual a 1 hora).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_TRACING_ON=true"
Inicie o rastreio do dstore. Utilize apenas quando orientado pelo IBM Support Center. Observe que o arquivo de log .dstoreTrace resultante é criado em Unicode (ASCII), e não em EBCDIC.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_MEMLOGGING_ON=true"
Inicie o rastreio de memória do dstore. Utilize apenas quando orientado pelo IBM Support Center. Observe que o arquivo de log resultante .dstoreMemLogging é criado em Unicode (ASCII), e não em EBCDIC.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
Use uma transação APPC para o serviço TSO Commands. Por padrão, o TSO/ISPF Client Gateway do ISPF é usado. Remova o comentário para utilizar uma transação APPC. Não altere o valor designado.

Definindo Parâmetros Extras de Inicialização Java com _RSE_CMDSERV_OPTS

Com as diferentes diretivas _RSE_*OPTS, rsed.envvars oferece a possibilidade de fornecer parâmetros extras para Java ao iniciar os processos RSE. As opções de amostra incluídas em rsed.envvars podem ser ativadas pela remoção dos comentários.

As diretivas _RSE_CMDSERV_OPTS são opções Java específicas do RSE e estarão em vigor apenas quando o TSO/ISPF Client Gateway do ISPF for usado pelo Developer para System z. (Esse é o padrão).

_RSE_CMDSERV_OPTS=""
Inicialização variável. Não modifique.
_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS &ISPROF=&SYSUID..ISPROF="
Use um perfil ISPF existente para a inicialização do ISPF. Remova o comentário e altere o nome do conjunto de dados para utilizar o perfil ISPF especificado.

As seguintes variáveis podem ser usadas no nome do conjunto de dados:

ISPF.conf, Arquivo de Configuração do TSO/ISPF Client Gateway do ISPF

O TSO/ISPF Client Gateway do ISPF utiliza as definições em ISPF.conf para criar um ambiente válido para executar comandos do TSO e do ISPF em lote. O Developer para System z utiliza esse ambiente para executar alguns serviços baseados em MVS. Esses serviços incluem o serviço TSO Commands, o serviço SCLM Developer Toolkit e um método de inicialização alternativo do CARMA.

O ISPF.conf está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Linhas de comentários são iniciadas com um asterisco (*) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado. Não são permitidos comentários na mesma linha. Continuações de linha não são suportadas. Ao concatenar nomes de conjuntos de dados, inclua-os na mesma linha e separe os nomes com uma vírgula (,).

Além de fornecer os nomes corretos para os conjuntos de dados do ISPF, você deve também incluir o nome do conjunto de dados de serviço TSO Commands, FEK.SFEKPROC, na instrução SYSPROC ou SYSEXEC, conforme mostrado no exemplo a seguir.

Figura 9. ISPF.conf - Arquivo de Configuração do ISPF
* REQUIRED:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD

* OPTIONAL:
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
*ISPF_timeout = 900
Nota:

Componentes Opcionais

As etapas de customização acima são para uma configuração básica do Developer para System z. Consulte os capítulos sobre os componentes opcionais para seus requisitos de customização:

Verificação de Instalação

A descrição de vários programas de verificação de instalação (IVPs) está localizada em Verificação de Instalação, porque alguns dos IVPs são para os componentes opcionais.

(Opcional) CARMA (Common Access Repository Manager)

O Common Access Repository Manager (CARMA) é um auxílio de produtividade para os desenvolvedores criam Repository Access Managers (RAMs). Um RAM é uma API (Interface de Programação do Aplicativo) para os SCMs (Software Configuration Managers) baseados no z/OS.

Em seguida, os aplicativos gravados pelo usuário podem iniciar um servidor CARMA que carrega os RAMs e fornece uma interface padrão para acesso ao SCM.

O Developer para System z suporta vários métodos para iniciar um servidor CARMA, cada um com seus próprios benefícios e desvantagens.

Requisitos e Lista de Verificação

Você precisará da ajuda de um administrador de segurança e um administrador de TCP/IP para concluir esta tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

Para iniciar o uso do CARMA em seu site, é necessário executar as tarefas a seguir. A menos que especificado o contrário, todas as tarefas são obrigatórias.

  1. Crie componentes necessários do CARMA. Para obter detalhes, consulte Componentes do CARMA.
  2. Customização inicial dos arquivos de configuração do RSE para fazer interface com o CARMA. A customização completa depende do método escolhido para iniciar o CARMA. Para obter detalhes, consulte Interface RSE para CARMA.
  3. Escolha um método para iniciar o CARMA e execute a customização necessária dos arquivos de configuração relacionados. Para obter detalhes, consulte:
  4. Ative, opcionalmente, os Repository Access Managers (RAMs) de amostra. Para obter detalhes, consulte (Opcional) Ativando os RAM (Repository Access Managers) de Amostra.
  5. Opcionalmente, ative o CA Endevor® RAM. Para obter detalhes, consulte (Opcional) Ativando o CA Endevor® SCM RAM.
  6. Crie, opcionalmente, CRAXJCL como substituição para IRXJCL. Para obter detalhes, consulte (Opcional) IRXJCL versus CRAXJCL.
Nota:
Os membros de amostra referidos neste capítulo estão localizados em FEK.#CUST.* e /etc/rdz, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP) . Consulte Configuração da Customização para obter mais detalhes.

Componentes do CARMA

Os seguintes componentes do CARMA devem ser customizados, independentemente do método de inicialização escolhido. Os membros de amostra referenciados abaixo estão localizados 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 da Customização para obter mais detalhes.

  1. Customize e envie a JCL FEK.#CUST.JCL(CRA$VDEF). Consulte a documentação em CRA$VDEF para obter instruções de customização. CRA$VDEF cria e prepara o conjunto de dados VSAM de configuração do CARMA, CRADEF.
  2. Customize e envie a JCL FEK.#CUST.JCL(CRA$VMSG). Consulte a documentação em CRA$VMSG para obter instruções de customização. CRA$VMSG cria e prepara o conjunto de dados VSAM de mensagens do CARMA, CRAMSG.
  3. Customize e envie a JCL FEK.#CUST.JCL(CRA$VSTR). Consulte a documentação em CRA$VSTR para obter instruções de customização. CRA$VSTR cria e prepara o conjunto de dados VSAM de informações customizadas do CARMA, CRASTRS.
Nota:

Notas de Migração VSAM do CARMA

O Developer para System z A versão 7.6.1 suporta um novo layout de estrutura de dados para o conjunto de dados VSAM de informações customizadas do CARMA, CRASTRS, para remover as limitações do comprimento das mensagens.

Anterior a versão 7.6.1. Developer para System z, as cadeias definidas no conjunto de dados VSAM de informações customizadas do CARMA são limitadas para comprimentos pré-definidos. Esta limitação força os desenvolvedores RAM a diminuírem as cadeias descritivas ou usar plug-ins do lado do cliente para exibir as cadeias de duração longa.

Developer para System z A versão 7.6.1 suporta um novo layout de estrutura de dados de comprimento variável para o conjunto de dados VSAM de informações customizadas do CARMA CRASTRS, onde as cadeias são separadas por um caractere delimitador em vez de serem de comprimento fixo.

Customize e submeta o FEK.SFEKSAMP(CRA#VS2) JCL para converter o seu conjunto de dados VSAM de informações customizadas do CARMA de comprimento fixo existente CRASTRS para o novo formato de comprimento variável.

Nota:

Interface RSE para CARMA

O servidor CARMA fornece uma API padrão para outros produtos baseados em host para acessar um ou mais SCMs (Software Configuration Managers). Entretanto, ele não fornece métodos para comunicação direta com um PC cliente. Para isso, ele depende de outros produtos, como o servidor RSE. O servidor RSE utiliza as configurações de CRASRV.properties para iniciar e se conectar a um servidor CARMA.

O CRASRV.properties está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
A tarefa iniciada RSED deve ser reiniciada para assimilar as mudanças feitas.
Figura 10. CRASRV.properties - Arquivo de configuração CARMA
# CRASRV.properties - Opções de configuração do CARMA
#
port.start=5227
port.range=100
startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex
clist.dsname='FEK.#CUST.CNTL(CRASUBMT)'
crastart.stub=/usr/lpp/rdz/bin/CRASTART
crastart.configuration.file=/etc/rdz/crastart.conf
crastart.syslog=Partial
crastart.timeout=420
#crastart.steplib=FEK.SFEKLPA
#crastart.tasklib=TASKLIB
port.start
Primeira porta utilizada para comunicação entre o CARMA e o servidor RSE. A porta padrão é 5227. A comunicação nesta porta está confinada para a máquina host.
Nota:
Antes de selecionar uma porta, verifique se ela está disponível em seu sistema com os comandos NETSTAT e NETSTAT PORTL. Consulte Portas TCP/IP Reservadas para obter informações adicionais.
port.range
Intervalo de portas, começando em port.start, que será usado para a comunicação do CARMA. O padrão é 100. Por exemplo, ao utilizar os padrões, as portas de 5227 até 5326 (inclusive) podem ser usadas pelo CARMA.
startup.script.name
Define o caminho absoluto do script de inicialização do CARMA. O padrão é /usr/lpp/rdz/bin/carma.startup.rex. Esse REXX exec acionará a inicialização de um servidor CARMA.
clist.dsname
Define o método de inicialização para o servidor CARMA.

O padrão é 'FEK.#CUST.CNTL(CRASUBMT)'. Esse CLIST iniciará um servidor CARMA ao abrir uma conexão utilizando o método de submissão em lote.

crastart.stub
Stub do z/OS UNIX para chamar CRASTART. O padrão é /usr/lpp/rdz/bin/CRASTART. Esse stub disponibiliza o módulo de carregamento CRASTART baseado em MVS para os processos do z/OS UNIX. Essa diretiva será usada apenas se a diretiva clist.dsname tiver *CRASTART como valor.
crastart.configuration.file
Especifica o nome do arquivo de configuração CRASTART. O padrão é /etc/rdz/crastart.conf. Esse arquivo especifica as alocações de conjuntos de dados e chamadas de programas necessárias para iniciar um servidor CARMA. Essa diretiva será usada apenas se a diretiva clist.dsname tiver *CRASTART como valor.
crastart.syslog
Especifica quantas informações são gravadas no log do sistema, enquanto CRASTART inicia um servidor CARMA. O padrão é Partial. Valores válidos são:
A (Tudo) Todas as informações de rastreio são impressas no SYSLOG
P (Parcial) Apenas informações de conexão, desconexão e erro são impressas no SYSLOG
qualquer outra coisa Apenas condições de erro são impressas no SYSLOG

Essa diretiva será usada apenas se a diretiva clist.dsname tiver *CRASTART como valor.

crastart.timeout
O período de tempo, em segundos, antes de um servidor CARMA ser encerrado devido à falta de atividade. O padrão é 420 (7 minutos). Essa diretiva será usada apenas se a diretiva clist.dsname tiver *CRASTART como valor.
crastart.steplib
O local do módulo CRASTART quando acessado por meio da diretiva STEPLIB em rsed.envvars. O padrão é FEK.SFEKLPA. Remova o comentário e customize essa diretiva se o módulo CRASTART não puder fazer parte de LPA ou LINKLIST. Observe que problemas de controle do programa e de APF podem surgir se o módulo CRASTART não estiver em LPA. Essa diretiva será utilizada apenas se a diretiva clist.dsname tiver *CRASTART como valor.
crastart.tasklib
Nome alternativo para o nome TASKLIB DD em crastart.conf. O padrão é TASKLIB. Remova o comentário e customize essa diretiva se o nome DD TASKLIB tiver um significado especial para SCM ou RAM e não puder ser usado como substituto de STEPLIB. Essa diretiva será usada apenas se a diretiva clist.dsname tiver *CRASTART como valor.

Inicialização do Servidor CARMA Usando Submissão em Lote

As informações nesta seção descrevem como configurar o método padrão para o Developer para System z iniciar um servidor CARMA. Essa etapa de customização poderá ser ignorada se você utilizar outro método de inicialização.

O Developer para System z usa, por padrão, o método de inicialização do servidor CARMA de submissão em lote que não exige que o módulo CRASTART esteja no LPA e que não depende do TSO/ISPF Client Gateway. O método envia o servidor CARMA como uma tarefa em lote de longa execução no JES.

Ajustar CRASRV.properties

O servidor RSE utiliza as configurações em /etc/rdz/CRASRV.properties para iniciar e se conectar a um servidor CARMA, conforme documentado em Interface RSE para CARMA. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

Altere o valor da diretiva clist.dsname para o conjunto de dados e nome do membro do CLIST de inicialização do servidor CARMA CRASUBMT, como mostrado no seguinte exemplo. Consulte Interface RSE para CARMA para obter informações adicionais sobre diretivas diferentes.

Figura 11. CRASRV.properties - inicialização do CARMA usando submissão em lote
port.start=5227
port.range=100
startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex
clist.dsname='FEK.#CUST.CNTL(CRASUBMT)'

Ajustar CRASUBMT

Customize a CLIST CRASUBMT, conforme mostrado na amostra de código a seguir. Consulte a documentação em CRASUBMT para obter instruções de customização. A CLIST CRASUBMT envia um servidor CARMA.

O CRASUBMT está localizado em FEK.#CUST.CNTL, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Figura 12. CRASUBMT - inicialização do CARMA utilizando submissão em lote
PROC 1 PORT TIMEOUT(420)
SUBMIT * END($$)
//CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
//RUN      EXEC PGM=IKJEFT01,DYNAMNBR=25,REGION=1024K,TIME=NOLIMIT
//STEPLIB  DD DISP=SHR,DSN=FEK.SFEKLOAD
//*        DD DISP=SHR,DSN=FEK.#CUST.LOAD
//CRADEF   DD DISP=SHR,DSN=FEK.#CUST.CRADEF
//CRAMSG   DD DISP=SHR,DSN=FEK.#CUST.CRAMSG
//CRASTRS  DD DISP=SHR,DSN=FEK.#CUST.CRASTRS
//*CRARAM1  DD DISP=SHR,DSN=FEK.#CUST.CRARAM1
//*
//ISPPROF  DD DISP=(NEW,DELETE,DELETE),
//            SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB,UNIT=SYSALLDA
//ISPMLIB  DD DISP=SHR,DSN=ISP.SISPMENU
//ISPPLIB  DD DISP=SHR,DSN=ISP.SISPPENU
//ISPSLIB  DD DISP=SHR,DSN=ISP.SISPSENU
//ISPTLIB  DD DISP=SHR,DSN=ISP.SISPTENU
//ISPEXEC  DD DISP=SHR,DSN=ISP.SISPEXEC
//SYSPROC  DD DISP=SHR,DSN=ISP.SISPCLIB
//*
//CARMALOG DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
ISPSTART PGM(CRASERV) PARM(&PORT &TIMEOUT)
//*
$$
EXIT CODE(0)
Nota:

(Opcional) Inicialização Alternativa do Servidor CARMA Utilizando CRASTART

As informações nesta seção descrevem como configurar um método alternativo para o Developer para System z iniciar um servidor CARMA. Essa etapa de customização poderá ser ignorada se você utilizar outro método de inicialização.

O Developer para System z suporta um método de inicialização alternativo do servidor CARMA que não depende do TSO/ISPF Client Gateway e que não envia uma tarefa do servidor utilizando um iniciador JES. O método utiliza CRASTART para iniciar o servidor CARMA como uma subtarefa com RSE e é semelhante ao serviço TSO/ISPF Client Gateway.

Nota:
Detalhes do processo de inicialização do CARMA são mostrados em rsecomm.log. Consulte (Opcional) Rastreio de RSE para obter informações adicionais sobre a configuração do nível de detalhes de rsecomm.log.

Ajustar CRASRV.properties

O servidor RSE utiliza as configurações em /etc/rdz/CRASRV.properties para iniciar e se conectar a um servidor CARMA, conforme documentado em Interface RSE para CARMA. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

Altere o valor da diretiva clist.dsname para *CRASTART e forneça os valores corretos para as diretivas crastart.*, como mostrado no seguinte exemplo. Consulte Interface RSE para CARMA para obter informações adicionais sobre diretivas diferentes.

Figura 13. CRASRV.properties - Inicialização alternativa do CARMA *CRASTART
port.start=5227
port.range=100
startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex
clist.dsname=*CRASTART
crastart.stub=/usr/lpp/rdz/bin/CRASTART
crastart.configuration.file=/etc/rdz/crastart.conf
crastart.syslog=Partial
crastart.timeout=420
#crastart.steplib=FEK.SFEKLPA
#crastart.tasklib=TASKLIB
Nota:
O encerramento de forma anormal 522 do sistema para módulo CRASERV ocorrerá se o parâmetro JWT no membro SMFPRMxx parmlib estiver configurado como um valor mais baixo do que o valor do tempo limite em CRASRV.properties. Isso não causa impacto nas operações do CARMA, pois o servidor é reiniciado automaticamente, se necessário.

Ajustar crastart.conf

Mantenha uma impressão do CRASUBMT customizado (consulte Inicialização do Servidor CARMA Usando Submissão em Lote ) pronta para facilitar a referência durante essa etapa de customização. A impressão será importante mesmo se você não tiver customizado o membro.

CRASTART utiliza as definições em crastart.conf para criar um ambiente válido para executar comandos TSO e ISPF em lote. O Developer para System z utiliza esse ambiente para executar o servidor CARMA chamado CRASERV.

O crastart.conf está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
As mudanças são efetivadas para todos os servidores CARMA iniciados após a atualização.

As etapas de customização a seguir são necessárias para ajustar o arquivo de configuração exibido na amostra de código abaixo.

Nota:
As definições de crastart.conf não podem ser divididas em várias linhas.
Figura 14. crastart.conf - Inicialização alternativa do CARMA *CRASTART
* crastart.conf - Opções de alocação do CARMA

TASKLIB  = FEK.SFEKLOAD
CRADEF   = FEK.#CUST.CRADEF
CRAMSG   = FEK.#CUST.CRAMSG
CRASTRS  = FEK.#CUST.CRASTRS
*CRARAM1  = FEK.#CUST.CRARAM1
*
CARMALOG = SYSOUT(H)
SYSTSPRT = SYSOUT(H)
SYSTSIN  = DUMMY
-COMMAND=ALLOC FI(SCRATCH) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) UNIT(VIO)
*
PROGRAM=IKJEFT01 CRASERV &CRAPRM1. &CRAPRM2.

As seguintes variáveis podem ser usadas no arquivo de configuração:

Tabela 10. Variáveis de crastart.conf
&CRAUSER. ID do usuário de logon do cliente.
&CRADATE. Data atual no formato Dyyyyddd (7 caracteres do calendário juliano).
&CRATIME. Hora atual no formato Thhmmss (hora - minuto - segundo).
&CRAPRM3. através de &CRAPRM9.

Variáveis adicionais com valores designados pelo usuário. O uso destas variáveis requer a customização da inicialização do CARMA do REXX referenciado no startup.script.name em CRASRV.properties.

Quando você usa estas variáveis, é recomendável customizar uma cópia do REXX de inicialização padrão, /usr/lpp/rdz/bin/carma.startup.rex e apontar startup.script.name para esta cópia. Isto é para evitar que você perca o seu trabalho quando a manutenção atualizar o REXX padrão.

símbolo do sistema Qualquer símbolo do sistema definido em SYS1.PARMLIB(IEASYMxx)
-<DD> Um traço (-) seguido de um nome DD definido anteriormente atua como uma referência anterior *.ddname na JCL. O DD original deve ser alocado utilizando a instrução -COMMAND.
Nota:
Não há nenhuma variável para o prefixo TSO, pois o TSO não está ativo quando o arquivo de configuração é interpretado.

(Opcional) Inicialização Alternativa do Servidor CARMA Usando TSO/ISPF Client Gateway

As informações nesta seção descrevem como configurar um método alternativo para o Developer para System z iniciar um servidor CARMA. Essa etapa de customização poderá ser ignorada se você utilizar outro método de inicialização.

O Developer para System z suporta um método de inicialização alternativo do servidor CARMA que não requer que o módulo CRASTART esteja no LPA e que não envia uma tarefa do servidor utilizando um iniciador JES. O método utiliza o TSO/ISPF Client Gateway do ISPF e é semelhante à forma padrão de acesso ao serviço TSO Commands.

Nota:
Detalhes do processo de inicialização do CARMA são mostrados em rsecomm.log. Consulte (Opcional) Rastreio de RSE para obter informações adicionais sobre a configuração do nível de detalhes de rsecomm.log.

Ajustar CRASRV.properties

O servidor RSE utiliza as configurações em /etc/rdz/CRASRV.properties para iniciar e se conectar a um servidor CARMA, conforme documentado em Interface RSE para CARMA. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

Altere o valor da diretiva clist.dsname para *ISPF, como mostrado no seguinte exemplo. Consulte Interface RSE para CARMA para obter informações adicionais sobre diferentes diretivas.

Figura 15. CRASRV.properties - Inicialização alternativa do CARMA *ISPF
port.start=5227
port.range=100
startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex
clist.dsname=*ISPF

Ajustar ISPF.conf

Mantenha uma impressão do CRASUBMT customizado (consulte Inicialização do Servidor CARMA Usando Submissão em Lote ) pronta para facilitar a referência durante essa etapa de customização. A impressão será importante mesmo se você não tiver customizado o membro.

O TSO/ISPF Client Gateway do ISPF usa as definições no ISPF.conf para criar um ambiente válido para executar comandos TSO e ISPF em lote. O Developer para System z utiliza esse ambiente para executar o servidor CARMA.

O ISPF.conf está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
As mudanças são efetivadas para todos os servidores CARMA iniciados após a atualização.

As etapas de customização a seguir são necessárias para ajustar o arquivo de configuração exibido na amostra de código abaixo.

Nota:
Não inclua os DDs SYSTSIN, SYSTSOUT ou CARMALOG, nem qualquer outra instrução DD que use construções JES, como dados do fluxo de entrada e SYSOUT=. Essas entradas devem ser convertidas para utilizar conjuntos de dados.
Figura 16. ISPF.conf - Inicialização alternativa do CARMA *ISPF
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispllib=FEK.SFEKLOAD
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
CRADEF =FEK.#CUST.CRADEF
CRAMSG =FEK.#CUST.CRAMSG
CRASTRS=FEK.#CUST.CRASTRS
*CRARAM1=FEK.#CUST.CRARAM1
allocjob=FEK.#CUST.CNTL(CRAISPRX)

A DD CARMALOG refere-se a SYSOUT=* por padrão, que não pode ser mapeada em ISPF.conf. Não é possível mapear o DD diretamente para um conjunto de dados, já que todos os usuários do Developer para System z estarão utilizando o mesmo arquivo ISPF.conf e, portanto, os mesmos conjuntos de dados.

No entanto, conforme descrito no Customizando o Ambiente TSO, seção Avançado - Usando um Exec de Alocação, você pode utilizar um exec de alocação para criar e alocar um conjunto de dados baseado no ID de usuário ativo. Consulte o membro de amostra CRAISPRX no conjunto de dados FEK.#CUST.CNTL como um exemplo que aloca DD CARMALOG para o nome do conjunto de dados TSOPREFIX'.'USERID'.CRA.'TIMESTAMP'.CARMALOG'.

Nota:

(Opcional) Ativando os RAM (Repository Access Managers) de Amostra

Os Repository Access Managers (RAMs) são APIs gravadas pelo usuário na interface com Software Configuration Managers (SCMs) do z/OS. Siga as instruções nas seções abaixo para os RAMs de amostra que você deseja ativar.

Nota:
Os RAMs de amostra são fornecidos com o propósito de testar a configuração do ambiente CARMA e como exemplos para que você desenvolva seus próprios RAMs. NÃO utilize os RAMs de amostra fornecidos em um ambiente de produção.

Consulte Rational Developer para System z Common Access Repository Manager Developer's Guide (SC23-7660) para obter informações adicionais sobre RAMs de amostra e código de origem de amostra fornecidos.

Os membros de amostra referenciados abaixo estão localizados 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 da Customização para obter mais detalhes.

Ativando o PDS RAM

O PDS RAM fornece uma lista de conjuntos de dados semelhante a Arquivos MVS -> Meus Conjuntos de Dados na visualização Sistemas Remotos. O PDS RAM usa o RAM ID 0 por padrão.

Nota:
O PDS RAM espera que o CARMA seja iniciado dentro do ISPF (usando ISPSTART).

  1. Customize e envie a JCL FEK.#CUST.JCL(CRA#VPDS). Consulte a documentação em CRA#VPDS para obter instruções de customização. CRA#VPDS cria e prepara o conjunto de dados VSAM de mensagens do PDS RAM.
  2. Inclua a instrução DD CRARAM1 no método de inicialização selecionado do CARMA e forneça o nome do conjunto de dados do VSAM de mensagem do PDS RAM.

Ativando o RAM do SCLM

O SCLM RAM fornece uma entrada básica no SCLM, o Software Configuration Manager do ISPF. O SCLM RAM usa o RAM ID 1 por padrão.

Nota:
O SCLM RAM espera que o CARMA seja iniciado dentro do ISPF (usando ISPSTART).

  1. Customize e envie a JCL FEK.#CUST.JCL(CRA#VSLM). Consulte a documentação em CRA#VSLM para obter instruções de customização. CRA#VSLM cria e prepara o conjunto de dados VSAM de mensagens do SCLM RAM.
  2. Inclua a instrução DD CRARAM2 no método de inicialização selecionado do CARMA e forneça o nome do conjunto de dados do VSAM de mensagem do SCLM RAM.
  3. Customize a JCL FEK.#CUST.JCL(CRA#ASLM). Consulte a documentação em CRA#ASLM para obter instruções de customização. CRA#ASLM aloca os conjuntos de dados necessários pelos clientes SCLM RAM.
    Nota:
    Cada usuário deve enviar FEK.#CUST.JCL(CRA#ASLM) uma vez antes de usar o CARMA com o SCLM RAM. Se isso não for feito, o resultado será um erro de alocação.

Ativando o RAM da Estrutura

O RAM de base fornece uma estrutura de base que pode ser usada para desenvolver seus próprios RAMs. O RAM de base usa o RAM ID 3 por padrão.

  1. Customize e envie a JCL FEK.#CUST.JCL(CRA#CRAM). Consulte a documentação em CRA#CRAM para obter instruções de customização. CRA#CRAM compila a RAM da estrutura.
  2. Inclua a biblioteca de carregamento que contém o módulo RAM da estrutura compilada, CRARAMSA, na STEPLIB DD do método de inicialização CARMA selecionado (TASKLIB DD do método CRASTART).

(Opcional) Ativando o CA Endevor® SCM RAM

O IBM® Rational® Developer para System z Interface para CA Endevor ® Software Configuration Manager fornece aos clientes do Developer para System z acesso direto ao CA Endevor® SCM. A partir daqui, o IBM® Rational® Developer para System z Interface para CA Endevor® SCM é abreviado como CA Endevor® SCM RAM (Repository Access Manager).

Em contradição com os RAMs de amostras documentados nesta publicação, o CA Endevor® SCM RAM é um tipo de produção RAM. Você não deve ativar os dois tipos de RAM na mesma configuração.

Atenção: As tarefas de configuração fornecidas para CA Endevor® SCM RAM substituem a configuração do CARMA ativa por uma que somente suspende o CA Endevor® SCM RAM.

Nota:
O método de inicialização do TSO/ISPF Client Gateway não pode ser usado junto com o CA Endevor® SCM RAM.

Requisitos e Lista de Verificação

Você precisa da assistência de um administrador de segurança e um administrador TCP/IP para completar esta tarefa de customização, que requer os seguintes recursos ou tarefas de customização especiais:

Para iniciar usando o CA Endevor® SCM RAM no seu site, você deve executar as seguintes tarefas. A menos que especificado o contrário, todas as tarefas são obrigatórias.

  1. Aloque e prepare os conjuntos de dados VSAM que definem o CA Endevor® SCM RAM no CARMA. Para obter detalhes, consulte Defina o CA Endevor® SCM RAM.
  2. Escolha o seu método de inicialização preferido, submissão em lote ou CRASTART, e faça a customização requerida dos arquivos de configuração relacionados. Para obter detalhes, consulte:
  3. Opcionalmente, customize o executável de alocação usado para a alocação dinâmica de conjuntos de dado específicos do usuário. Para obter detalhes, consulte (Opcional) Customize CRANDVRA.
  4. Opcionalmente, customize os arquivos de configuração específicos do CA Endevor® SCM RAM. Para obter detalhes, consulte (Opcional) Customize o CA Endevor® SCM RAM.

Defina o CA Endevor® SCM RAM

Os seguintes componentes do CARMA devem ser customizados, independentemente do método de inicialização escolhido. Os membros de amostra referenciados abaixo estão localizados 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 da Customização para obter mais detalhes.

  1. Customize e envie a JCL FEK.#CUST.JCL(CRA#VCAD). Consulte a documentação em CRA$VDEF para obter instruções de customização. CRA#VCAD cria e prepara o conjunto de dados VSAM de configuração do CARMA, CRADEF.
  2. Customize e envie a JCL FEK.#CUST.JCL(CRA$VMSG). Consulte a documentação em CRA$VMSG para obter instruções de customização. CRA$VMSG cria e prepara o conjunto de dados VSAM de mensagens do CARMA, CRAMSG.
    Nota:
    Essa é a mesma tarefa dos RAMs de amostra.
  3. Customize e envie a JCL FEK.#CUST.JCL(CRA#VCAS). Consulte a documentação em CRA$VSTR para obter instruções de customização. CRA#VCAS cria e prepara o conjunto de dados VSAM de informações customizadas do CARMA, CRASTRS.
Nota:

Inicialização do CA Endevor® SCM RAM Usando Submissão em Lote

Não execute esta etapa se você usar o método CRASTART para iniciar o servidor CARMA com o CA Endevor® SCM RAM.

O Developer para System z pode usar o método de inicialização do Servidor CARMA de submissão em lote para iniciar o CA Endevor® SCM RAM. O método envia o servidor CARMA como uma tarefa em lote de longa execução no JES.

Consulte Inicialização do Servidor CARMA Usando Submissão em Lote para obter informações adicionais sobre o método de inicialização de submissão em lote.

Ajustar CRASRV.properties

O servidor RSE utiliza as configurações em /etc/rdz/CRASRV.properties para iniciar e se conectar a um servidor CARMA, conforme documentado em Interface RSE para CARMA. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

Altere o valor da diretiva clist.dsname para o conjunto de dados e nome do membro do CLIST de inicialização do servidor CARMA CRASUBCA, como mostrado no seguinte exemplo. Consulte Interface RSE para CARMA para obter informações adicionais sobre diretivas diferentes.

Figura 17. Figura x1. CRASRV.properties - inicialização do CA Endevor® SCM RAM usando submissão em lote
port.start=5227
port.range=100
startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex
clist.dsname='FEK.#CUST.CNTL(CRASUBCA)'

Ajustar CRASUBCA

Customize o CLIST CRASUBCA, como mostrado na amostra de código a seguir. Consulte a documentação dentro do CRASUBCA para obter instruções de customização. O CLIST CRASUBCA CLIST submete um servidor CARMA para o CA Endevor® SCM.

O CRASUBCA está localizado no FEK.#CUST.CNTL, a menos que você tenha especificado um local diferente ao customizar e submeter a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Figura 18. Figura x2. Inicialização do CRASUBCA - CA Endevor® SCM RAM usando submissão em lote
PROC 1 PORT TIMEOUT(420)
SUBMIT * END($$)
//CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) 
//RUN      EXEC PGM=IKJEFT01,DYNAMNBR=125,REGION=0M,TIME=NOLIMIT, 
//            PARM='%CRANDVRA NDVRC1 PGM(CRASERV) PARM(&PORT &TIMEOUT)' 
//STEPLIB  DD DISP=SHR,DSN=FEK.SFEKLOAD
//         DD DISP=SHR,DSN=CA.NDVR.AUTHLIB
//         DD DISP=SHR,DSN=CA.NDVRU.AUTHLIB
//CRADEF   DD DISP=SHR,DSN=FEK.#CUST.CRADEF
//CRAMSG   DD DISP=SHR,DSN=FEK.#CUST.CRAMSG
//CRASTRS  DD DISP=SHR,DSN=FEK.#CUST.CRASTRS
//*
//SYSPROC  DD DISP=SHR,DSN=ISP.SISPCLIB
//         DD DISP=SHR,DSN=FEK.SFEKPROC
//ISPEXEC  DD DISP=SHR,DSN=ISP.SISPEXEC
//ISPMLIB  DD DISP=SHR,DSN=ISP.SISPMENU
//ISPPLIB  DD DISP=SHR,DSN=ISP.SISPPENU
//ISPSLIB  DD DISP=SHR,DSN=ISP.SISPSENU
//ISPTLIB  DD DISP=SHR,DSN=ISP.SISPTENU
//ISPCTL0  DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//            SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB
//ISPCTL1  DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//            SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB
//ISPPROF  DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//            SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//*
//CARMALOG DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DUMMY
//*
//CONLIB   DD DISP=SHR,DSN=CA.NDVR.CONLIB
//JCLOUT   DD SYSOUT=(A,INTRDR),DCB=(LRECL=80,RECFM=F,BLKSIZE=80)
//EXT1ELM  DD DISP=(NEW,DELETE),UNIT=SYSALLDA,
//            RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5))
//EXT1DEP  DD DISP=(NEW,DELETE),UNIT=SYSALLDA,
//            RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5))
//MSG3FILE DD DISP=(NEW,DELETE),UNIT=SYSALLDA,
//            RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5))
//C1MSGS1  DD DISP=(NEW,DELETE),UNIT=SYSALLDA,
//            RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5))
//C1EXMSGS DD DISP=(NEW,DELETE),UNIT=SYSALLDA,
//            RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5))
//TYPEMAP  DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRATMAP)
//SHOWVIEW DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRASHOW)
$$
EXIT CODE(0)
Nota:

Inicialização do CA Endevor® SCM RAM Usando CRASTART

Não execute esta etapa se você usar o método de submissão em lote para iniciar o servidor CARMA com o CA Endevor® SCM RAM.

O Developer para System z pode usar o método CRASTART de inicialização do servidor CARMA para iniciar o CA Endevor® SCM RAM. O método usa o CRASTART para iniciar o servidor CARMA como uma subtarefa dentro do RSE.

Consulte (Opcional) Inicialização Alternativa do Servidor CARMA Utilizando CRASTART para obter informações adicionais sobre o método de inicialização CRASTART.

Nota:
Detalhes do processo de inicialização do CARMA são mostrados em rsecomm.log. Consulte (Opcional) Rastreio de RSE para obter informações adicionais sobre a configuração do nível de detalhes de rsecomm.log.

Ajustar CRASRV.properties

O servidor RSE utiliza as configurações em /etc/rdz/CRASRV.properties para iniciar e se conectar a um servidor CARMA, conforme documentado em Interface RSE para CARMA. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

Altere o valor da diretiva clist.dsname para *CRASTART e forneça os valores corretos para as diretivas crastart.*, como mostrado no seguinte exemplo. Consulte Interface RSE para CARMA para obter informações adicionais sobre diretivas diferentes.

Figura 19. Figura x3. CRASRV.properties - inicialização do CA Endevor® SCM RAM usando CRASTART
port.start=5227
port.range=100
startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex
clist.dsname=*CRASTART
crastart.stub=/usr/lpp/rdz/bin/CRASTART
crastart.configuration.file=/etc/rdz/crastart.endevor.conf
crastart.syslog=Partial
crastart.timeout=420
#crastart.steplib=FEK.SFEKLPA
#crastart.tasklib=TASKLIB
Nota:
O encerramento de forma anormal 522 do sistema para módulo CRASERV ocorrerá se o parâmetro JWT no membro SMFPRMxx parmlib estiver configurado como um valor mais baixo do que o valor do tempo limite em CRASRV.properties. Isto não impacta nas operações do CARMA porque o servidor é reiniciado automaticamente, caso necessário.

Ajuste crastart.endevor.conf

O CRASTART usa as definições no crastart.endevor.conf para criar um ambiente válido (TSO/ISPF) para invocar o CA Endevor® SCM. O Developer para System z usa este ambiente para executar o CA Endevor ® SCM RAM.

O crastart.endevor.conf está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente ao customizar e submeter a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
As mudanças são efetivadas para todos os servidores CARMA iniciados após a atualização.
Figura 20. crastart.conf - CA Endevor® inicialização do SCM RAM usando CRASTART
TASKLIB = FEK.SFEKLOAD,CA.NDVR.AUTHLIB,CA.NDVRU.AUTHLIB
CRADEF   = FEK.#CUST.CRADEF
CRAMSG   = FEK.#CUST.CRAMSG
CRASTRS  = FEK.#CUST.CRASTRS

SYSPROC = ISP.SISPCLIB,FEK.SFEKPROC
SYSEXEC = ISP.SISPEXEC
ISPMLIB = ISP.SISPMENU
ISPPLIB = ISP.SISPPENU
ISPSLIB = ISP.SISPSENU
-COMMAND=ALLOC FI(ISPCTL0)  NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) 
BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA)
-COMMAND=ALLOC FI(ISPCTL1)  NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) 
BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA)
-COMMAND=ALLOC FI(ISPPROF)  NEW DELETE DSORG(PO) DIR(5) RECFM(F,B) LRECL(80) 
BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA)
ISPTLIB = -ISPPROF,ISP.SISPTENU
ISPTABL = -ISPPROF

CARMALOG = SYSOUT(H)
SYSPRINT= SYSOUT(H)
SYSTSPRT = SYSOUT(H)
SYSTSIN  = DUMMY

TYPEMAP = FEK.#CUST.PARMLIB(CRATMAP)
SHOWVIEW= FEK.#CUST.PARMLIB(CRASHOW)
CONLIB  = CA.NDVR.CONLIB
-COMMAND=ALLOC FI(JCLOUT)   SYSOUT(A) WRITER(INTRDR) RECFM(F) LRECL(80) 
BLKSIZE(80)
-COMMAND=ALLOC FI(EXT1ELM)  NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) 
BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA)
-COMMAND=ALLOC FI(EXT1DEP)  NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) 
BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA)
-COMMAND=ALLOC FI(MSG3FILE) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) 
BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA)
-COMMAND=ALLOC FI(C1EXMSGS) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) 
BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA)
-COMMAND=ALLOC FI(C1MSGS1)  NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) 
BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA)

PROGRAM=IKJEFT01 %CRANDVRA NDVRC1 PGM(CRASERV) PARM(&CRAPRM1.
&CRAPRM2.)

(Opcional) Customize CRANDVRA

Os métodos de inicialização de submissão em lote e CRASTART invocam o executável REXX CRANDVRA para alocar os conjuntos de dados específicos de usuários pelo CA Endevor® SCM RAM.

DD Nome do conjunto de dados Tipo
DEPEND &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.DEPEND Permanente
BROWSE &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.BROWSE Temporário
C1PRINT &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.LISTING Temporário

Você pode customizar uma cópia deste executável REXX de alocação se certos padrões, como o nome do conjunto de dados, não corresponderem aos padrões do seu site. O CRANDVRA está localizado em FEK.SFEKPROC, a menos que você tenha usado um qualificador de alto nível diferente durante a instalação do SMP/E do Developer para System z.

Consulte a documentação dentro do CRANDVRA para obter instruções de customização.

Nota:
É recomendável copiar a alocação REXX de amostra para um novo conjunto de dados e customizar esta cópia para evitar sobrescrevê-la ao realizar manutenção. Ao fazê-lo, você deve atualizar a referência para SFEKPROC no SYSEXEC DD do método de inicialização do CARMA da sua escolha para que ele corresponda ao nome do seu novo conjunto de dados.

(Opcional) Customize o CA Endevor® SCM RAM

Os seguintes componentes do CARMA podem ser customizados, independentemente do método de inicialização escolhido. Os membros da amostra referenciados abaixo estão localizados em FEK.#CUST.PARMLIB, a menos que você tenha especificado um local diferente ao customizar e submeter a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

  1. (Opcional) Customize FEK.#CUST.PARMLIB(CRASHOW). Consulte a documentação dentro do CRASHOW para instruções de customização. O CRASHOW define os filtros padrão para os ambientes, sistemas e assim por diante do CA Endevor®.
  2. (Opcional) Customize FEK.#CUST.PARMLIB(CRATMAP). Consulte a documentação dentro do CRATMAP para obter instruções de customização. O CRATMAP substitui o tipo de CA Endevor® SCM por mapeamentos de extensão do arquivo.

(Opcional) Suportando Múltiplos RAMs

O CARMA permite que múltiplos RAMs sejam definidos e possam ser executados concomitantemente. Porém, uma vez que há somente um servidor CARMA ativo por usuário, mesmo quando há múltiplos RAMs, algumas mudanças de configuração podem ser necessárias para fazer com que esta configuração funcione.

Os RAMs são definidos por um desenvolvedor RAM no conjunto de dados VSAM de configuração do CARMA CRADEF. Durante a inicialização,o servidor CARMA CRASERV identificará todos os RAMs definidos e apresentará as informações para o cliente RAM. O usuário poderá então selecionar um ou mais RAMs, que serão carregados no servidor CARMA.

Uma vez que os RAMs estão ativos como plug-ins do servidor CARMA, você deve assegurar que todos os pré-requisitos (como as alocações do conjunto de dados) para cada um dos RAMs estejam disponíveis no espaço de endereço do servidor CARMA. Isto pode requerer mudanças nas amostras de configuração do CARMA, como CRASUBMT ou crastart.conf, que são enviados com o Developer para System z.

Exemplo

No exemplo a seguir, você inicia a partir de uma configuração existente com o CA Endevor® SCM RAM, usando o método de inicialização CRASTART, e inclui o PDS RAM da amostra.

Definições para o CA Endevor® SCM RAM:

Definições para o PDS RAM:

O processo inicia com um desenvolvedor RAM reunindo os dados e informações necessários para programador de sistema completar a configuração.

  1. Extraia os dados específicos para o PDS RAM dos membros do SFEKVSM2 (estes membros mantêm definições para todos os RAMs de amostra, não somente os PDS RAM).
  2. Funda estes dados com os membros do CA Endevor® SCM RAM SFEKVSM2.
  3. Crie uma lista de pré-requisitos específicos de PDS RAM:

Depois o programador de sistema usa estes dados para criar conjuntos de dados VSAM do CARMA atualizados e usa as informações sobre os pré-requisitos para criar um arquivo de configuração CRASTART que é capaz de suportar os dois RAMs.

  1. Use os dados combinados como entrada para as tarefas CRA$VDEF e CRA$VSTR para criar a configuração do CARMA atualizada e os conjuntos de dados VSAM de informações customizadas CRADEF e CRASTRS.
  2. Inclua uma definição CRARAM1 para crastart.endevor.conf:
        CRARAM1  = FEK.#CUST.CRARAM1
  3. Verifique a instrução do PROGRAMA no crastart.endevor.conf para assegurar que ele seja capaz de fornecer o ambiente necessário para os dois RAMs:
    PROGRAM=IKJEFT01 %CRANDVRA NDVRC1 PGM(CRASERV)
      PARM(&CRAPRM1. &CRAPRM2.)

O SCM RAM do CA Endevor® é ativo em um ambiente ISPF, o que implica que o ambiente TSO requerido pelo PDS RAM também está disponível.

(Opcional) IRXJCL versus CRAXJCL

Se o servidor CARMA for iniciado utilizando TSO (IKJEFTxx), você pode ter problemas se os RAMs chamarem serviços que, por sua vez, chamam a interface em lote REXX IRXJCL. O problema poderá ocorrer quando os processadores chamados pela RAM tiverem sido executados anteriormente sem o TSO ou apenas no TSO on-line, e alocarem dinamicamente DD SYSTSIN ou SYSTSPRT. Um programa de amostra CRAXJCL é fornecido para oferecer uma solução alternativa para esse problema.

Seu processador poderá falhar se ele tentar alocar SYSTSIN ou SYSTSPRT (necessárias para IRXJCL) porque o TSO em lote (necessário para CARMA) já possui esses nomes de DD alocados e abertos. O módulo de substituição CRAXJCL tenta alocar SYSTSIN e SYSTSPRT para DUMMY, mas ignora os erros que ocorrerem se as alocações falharem.

Isso significa que quando seus processadores forem executados em um ambiente CARMA iniciado pelo TSO, as alocações para SYSTSIN e SYSTSPRT serão as mesmas que aquelas usadas pelo CARMA. Quando os processadores forem executados fora do TSO/CARMA, as alocações de SYSTSIN e SYSTSPRINT serão criadas pelo CRAXJCL. Portanto, seus processadores não devem depender do conteúdo do conjunto de dados alocado para SYSTSIN.

Assume-se que as chamadas para IRXJCL usam o campo PARM para transmitir o nome do REXX e os parâmetros de inicialização, conforme documentado em TSO/E REXX Reference (SA22-7790). Isso significa que SYSTSIN pode ser utilizado com segurança pelo CARMA. Qualquer saída enviada para SYSTSPRT pelo IRXJCL terminará no log do CARMA.

Os processadores que chamam o módulo de substituição CRAXJCL não devem tentar alocar DD SYSTSIN ou SYSTSPRT antes de chamar CRAXJCL.

Criar CRAXJCL

O módulo de substituição CRAXJCL é fornecido no formato de origem porque você precisará customizá-lo para especificar as alocações específicas que deseja utilizar para SYSTSPRT. SYSTSIN geralmente deve ser alocado para um conjunto de dados fictício.

O código de origem do assembler de amostra e uma tarefa de amostra de compilação/ligação são fornecidos como FEK.#CUST.ASM(CRAXJCL) e FEK.#CUST.JCL(CRA#CIRX) respectivamente, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP) . Consulte Configuração da Customização para obter mais detalhes.

Customize o código de origem do assembler CRAXJCL de acordo com suas necessidades, utilizando a documentação no membro. Em seguida, customize e envie a JCL CRA#CIRX para criar o módulo de carregamento CRAXJCL. Consulte a documentação em CRA#CIRX para obter instruções de customização.

(Opcional) Application Deployment Manager

O Developer para System z utiliza determinadas funções do Application Deployment Manager como uma abordagem de implementação comum para vários componentes. As etapas de customização listadas neste capítulo serão necessárias se seus desenvolvedores utilizarem qualquer uma das funções a seguir:

Nota:
O Enterprise Service Tools (EST) inclui diversas ferramentas, como o Modelador de Fluxo de Serviço (SFM) e os Serviços XML para a Empresa (XSE).

Customizar o Application Deployment Manager inclui o servidor CICS Resource Definition (CRD), que eé executado como um aplicativo do CICS no z/OS para suportar as seguintes funções:

Administradores do CICS podem localizar mais informações sobre o servidor CRD no Considerações sobre o CICSTS.

Requisitos e Lista de Verificação

Você precisará da assistência de um administrador do CICS, um administrador de TCP/IP e um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

Para iniciar o uso do Application Deployment Manager em seu site, é necessário executar as tarefas a seguir. A menos que especificado o contrário, todas as tarefas são obrigatórias.

  1. Crie o repositório CRD. Para obter detalhes, consulte Repositório do CRD.
  2. Escolha a interface do CICS interface (RESTful ou Serviço da Web) a ser usada. (As interfaces podem coexistir). Para obter detalhes, consulte RESTful versus Serviços da Web.
  3. Se desejar, faça as customizações específicas de RESTful. Para obter detalhes, consulte Servidor CRD Usando a Interface RESTful.
  4. Se desejar, faça as customizações específicas do Serviço da Web. Para obter detalhes, consulte Servidor CRD Usando a Interface do Serviço da Web.
  5. Crie, opcionalmente, o repositório de manifesto. Para obter detalhes, consulte (Opcional) Repositório de Manifesto.

Repositório do CRD

Customize e envie a tarefa ADNVCRD para alocar e inicializar o conjunto de dados VSAM do repositório CRD. Consulte a documentação no membro para obter instruções de customização.

ADNVCRD está localizado 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 da Customização para obter mais detalhes.

É aconselhável criar um repositório separado para cada região de conexão primária do CICS. O compartilhamento do repositório implica que todas as regiões CICS relacionadas utilizarão os mesmos valores armazenados no repositório.

Nota:

Os usuários precisam de acesso READ ao repositório CRD e os administradores do CICS precisam de acesso UPDATE.

CICS Administrative Utility

O Developer para System z fornece o administrative utility 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 é chamado pela tarefa de amostra ADNJSPAU. O uso desse utilitário requer acesso UPDATE ao repositório do CRD.

O ADNJSPAU está localizado 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 da Customização para obter mais detalhes.

Informações adicionais estão disponíveis em Considerações sobre o CICSTS.

RESTful versus Serviços da Web

O CICS Transaction Server fornece na versão 4.1 e superior suporte para uma interface HTTP projetada usando os 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 para System versão 7.6 ou superior.

As interfaces RESTful e de Serviço da Web podem ser ativadas simultaneamente em uma única região do 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.

Servidor CRD Usando a Interface RESTful

As informações desta seção descrevem como definir o servidor CRD que usa a interface RESTful para se comunicar com o cliente do Developer para System z.

As interfaces RESTful e de Serviço da Web podem ser ativadas simultaneamente em uma única região do 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ão de Conexão Primária do CICS

O servidor CRD deve ser definido para a região de conexão primária. Essa é a WOR (Web Owning Region) que processará os pedidos de Serviço da Web do Developer para System z.

Regiões de Conexão Não-primária do CICS

O servidor CRD também pode ser usado com uma ou mais regiões de conexão não-primária adicionais, que geralmente são Application Owning Regions (AOR).

Nota:
Não é necessário executar estas etapas se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recurso do CICS.

(Opcional) Customizar IDs de Transação do Servidor CRD

O Developer para System z fornece várias transações que são usadas pelo servidor CRD ao definir e consultar os recursos do CICS.

Tabela 11. IDs de Transação do Servidor CRD Padrão
Transação Descrição
ADMS Para pedidos da ferramenta Processamento de Manifesto para alterar os recursos do CICS. Geralmente, isso é destinado aos administradores do CICS.
ADMI Para pedidos que definem, instalam ou desinstalam recursos do CICS.
ADMR Para todos os outros pedidos que recuperam informações ambientais ou sobre recursos do CICS.

Você pode alterar os IDs da transação para que correspondam aos padrões do site seguinte estas etapas:

  1. Customize e envie ADNTXNC para criar o módulo de carregamento ADNRCUST. Consulte a documentação no membro para obter instruções de customização.
  2. Coloque o módulo de carregamento ADNRCUST resultante na concatenação RPL do CICS (instrução DD DFHRPL) das regiões do CICS em que o servidor CRD está definido.
  3. Customize e envie ADNCSDTX para definir ADNRCUST como o programa para as regiões do CICS em que o servidor CRD está definido. Consulte a documentação no membro para obter instruções de customização.

Nota:
O servidor CRD RESTful sempre tentará carregar o módulo de carregamento ADNRCUST. Portanto, você pode obter uma pequena melhora no desempenho criando e definindo o módulo de carregamento ADNRCUST, mesmo se não alterar os IDs da transação.

Servidor CRD Usando a Interface do Serviço da Web

As informações desta seção descrevem como definir o servidor CRD que usa a interface do Serviço da Web para se comunicar com o cliente do Developer para System z.

As interfaces RESTful e de Serviço da Web podem ser ativadas simultaneamente em uma única região do 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.

Manipulador de Mensagens do Pipeline

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. Consulte o Considerações sobre o CICSTS para saber mais sobre o manipulador de mensagens de pipeline e a configuração de segurança necessária.

O Developer para 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 ADNTMSGH, dependendo da operação solicitada. O código de origem COBOL de amostra é fornecido para permitir customizações específicas do site para ADNTMSGH:

Tabela 12. IDs de Transação do Servidor CRD Padrão
Transação Descrição
ADMS Para pedidos da ferramenta Processamento de Manifesto para alterar recursos do CICS. Geralmente, isso é destinado aos administradores do CICS.
ADMI Para pedidos que definam, instalem ou desinstalem recursos do CICS.
ADMR Para todos os outros pedidos que recuperam as informações de ambiente e de recurso do CICS.

Utilizando o padrão:

Customizando ADNTMSGH:

Os membros de amostra ADNMSGH* estão localizados em FEK.#CUST.JCL e em FEK.#CUST.COBOL, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Nota:
Certifique-se de que o módulo de carregamento ADNTMSGH customizado seja localizado antes de qualquer referência à FEK.SFEKLOAD, caso contrário, o padrão será usado.

região de conexão primária do CICS

O servidor CRD deve ser definido para a região de conexão primária. Essa é a região que processará pedidos de serviço do Developer para System z.

regiões de conexão não-primária do CICS

O servidor CRD também pode ser usado com uma ou mais regiões de conexão não-primária adicionais, que geralmente são Application Owning Regions (AOR).

Nota:
Não será necessário executar estas etapas se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recursos do CICS.

(Opcional) Repositório de Manifesto

O Developer para System z permite que clientes procurem e, opcionalmente, alterem manifestos descrevendo recursos do CICS selecionados. Dependendo das permissões configuradas pelo administrador do CICS, as alterações podem ser feitas diretamente ou exportadas para o repositório de manifesto para processamento adicional por um administrador do CICS.

Nota:

Customize e envie a tarefa ADNVMFST para alocar e inicializar o conjunto de dados VSAM do repositório de manifesto e para defini-la na região de conexão primária do CICS. Consulte a documentação no membro para obter instruções de customização. Um repositório de manifesto separado deve ser criado para cada região de conexão primária do CICS. Todos os usuários precisam de acesso UPDATE ao repositório de manifesto.

ADNVMFST está localizado 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 da Customização para obter mais detalhes.

(Opcional) SCLM Developer Toolkit

O SCLM Developer Toolkit fornece as ferramentas necessárias para estender os recursos do SCLM para o cliente. O SCLM por si só é um gerenciador de código de origem baseado em host enviado como parte do ISPF.

O SCLM Developer Toolkit possui um plug-in baseado em Eclipse que faz a interface com o SCLM e fornece acesso a todos os processos do SCLM para o desenvolvimento de código legado, bem como suporte para o desenvolvimento completo do Java e J2EE na estação de trabalho com sincronização para SCLM no mainframe, incluindo construção, montagem e implementação do código J2EE a partir do mainframe.

Requisitos e Lista de Verificação

Você precisará da assistência de um administrador de SCLM e, opcionalmente, de um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos e/ou tarefas de customização especiais:

Para iniciar o uso do SCLM Developer Toolkit em seu site, é necessário executar as tarefas a seguir. A menos que especificado o contrário, todas as tarefas são obrigatórias.

  1. Verifique e ajuste os pré-requisitos e as atualizações de PARMLIB. Para obter detalhes, consulte Pré-requisitos.
  2. Customize os arquivos de configuração do Developer para System z. Para obter detalhes, consulte:
  3. Defina, opcionalmente, o suporte à conversão de nomes longos/curtos. Para obter detalhes, consulte (Opcional) Tradução de Nome Longo/Abreviado.
  4. Instale e customize, opcionalmente, o Ant para que utilize o suporte à construção de JAVA/J2EE. Para obter detalhes, consulte (Opcional) Instalar e Customizar Ant.
  5. Atualize o SCLM para definir partes específicas do SCLMDT. Para obter detalhes, consulte Atualizações SCLM para SCLMDT.
  6. Opcionalmente, configure a automação para limpar, periodicamente, a área de trabalho SCLMDT. Para obter detalhes, consulte Remover Arquivos Antigos de WORKAREA.

Pré-requisitos

Consulte o Apêndice E. Requisitos para obter uma lista de manutenções necessárias do SCLM.

Esse apêndice documenta também as especificações Ant necessárias para construções JAVA/J2EE no SCLM Developer Toolkit.

Atenção: O SCLM Developer Toolkit requer o uso do ISPF's TSO/ISPF Client Gateway, o que implica que o z/OS 1.8 ou superior é necessário.

Conforme descrito em Alterações PARMLIB, o SCLM Developer Toolkit requer customização adicional de configurações do sistema. Essas alterações incluem:

Além disso, o SCLM Developer Toolkit utiliza o SDSF ou o comando do TSO OUTPUT para recuperar o status de conclusão da tarefa e a saída de tarefas. Ambos os métodos requerem atenção adicional:

Os usuários precisam de permissão READ, WRITE e EXECUTE para os diretórios z/OS UNIX /tmp/ e /var/rdz/WORKAREA/. O diretório WORKAREA/ está localizado em /var/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Atualizações do ISPF.conf para SCLMDT

O SCLM Developer Toolkit usa as estruturas padrão do ISPF/SCLM, portanto, assegure-se de que a biblioteca de estruturas ISP.SISPSLIB esteja alocada na concatenação ISPSLIB no ISPF.conf. O uso do conjunto de dados ISP.SISPSENU é opcional.

O ISPF.conf está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
As mudanças são efetivadas para todos os clientes que se conectam ao host após a atualização.

O código de amostra a seguir mostra o arquivo ISPF.conf, que deve ser customizado para corresponder ao seu ambiente do sistema. As linhas de comentário iniciam com um asterisco (*). Inclua conjuntos de dados na concatenação na mesma linha e separe os nomes com uma vírgula (,). Consulte ISPF.conf, Arquivo de Configuração do TSO/ISPF Client Gateway do ISPF para obter mais detalhes sobre como customizar o ISPF.conf.

Figura 21. Atualizações do ISPF.conf para SCLMDT
* REQUIRED:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB

* OPTIONAL:
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
*ISPF_timeout = 900
Nota:

Atualizações do rsed.envvars para SCLMDT

O SCLM Developer Toolkit utiliza algumas diretivas configuradas em rsed.envvars para localizar conjuntos de dados e diretórios.

O rsed.envvars está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
A tarefa iniciada RSED deve ser reiniciada para assimilar as mudanças feitas.

A amostra de código a seguir mostra as diretivas SCLMDT em rsed.envvars, que deve ser customizado para corresponder ao seu ambiente do sistema. Consulte Arquivo de Configuração do RSE rsed.envvars para obter mais detalhes sobre a customização de rsed.envvars.

Figura 22. Atualizações do rsed.envvars para SCLMDT
_SCLMDT_CONF_HOME=/var/rdz/sclmdt
#STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD
#_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE
#ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1
_SCLMDT_BASE_HOME=$RSE_HOME
_SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME 
CGI_DTWORK=$_SCLMDT_WORK_HOME

(Opcional) Tradução de Nome Longo/Abreviado

O SCLM Developer Toolkit fornece a capacidade para armazenar arquivos com nomes longos (que são nomes de arquivos com mais de 8 caracteres ou compostos por letras maiúsculas e minúsculas) no SCLM. Isso pode ser feito usando um arquivo VSAM que contém o mapeamento do nome do arquivo longo para o nome do membro de 8 caracteres usado no SCLM.

Nota:

Criar LSTRANS.FILE, o VSAM de Conversão de nome Longo/Curto

Customize e envie o membro de amostra FLM02LST na biblioteca de amostra do ISPF ISP.SISPSAMP para criar o VSAM de conversão de nomes longos/abreviados. As etapas de configuração nesta publicação esperam que o VSAM seja denominado FEK.#CUST.LSTRANS.FILE, conforme mostrado na JCL de configuração de amostra a seguir.

Figura 23. FLM02LST - JCL de Configuração da Conversão de Nomes Longos/Curtos
//FLM02LST JOB <parâmetros da tarefa>
//*
//* CUIDADO: Isso não é um procedimento JCL nem uma tarefa completa.
//* Antes de usar esta amostra, você deverá fazer as seguintes
//* modificações:
//* 1.	Altere os parâmetros da tarefa de acordo com os requisitos do sistema.
//* 2. Altere ****** para o volume que conterá o VSAM.
//* 3. Altere todas as referências de FEK.#CUST.LSTRANS.FILE para 
//*    corresponder à sua convenção de nomenclatura para o VSAM 

de conversão do SCLM. //* //CREATE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE FEK.#CUST.LSTRANS.FILE SET MAXCC=0 DEFINE CLUSTER(NAME(FEK.#CUST.LSTRANS.FILE) - VOLUMES(******) - RECORDSIZE(58 2048) - SHAREOPTIONS(3 3) - CYLINDERS(1 1) - KEYS(8 0) - INDEXED) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.INDEX)) /* DEFINE ALTERNATE INDEX WITH NONUNIQUE KEYS -> ESDS */ DEFINE ALTERNATEINDEX(- NAME(FEK.#CUST.LSTRANS.FILE.AIX) - RELATE(FEK.#CUST.LSTRANS.FILE) - RECORDSIZE(58 2048) - VOLUMES(******) - CYLINDERS(1 1) - KEYS(50 8) - UPGRADE - NONUNIQUEKEY) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.AIX.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.AIX.INDEX)) /* //* //PRIME EXEC PGM=IDCAMS,COND=(0,LT) //SYSPRINT DD SYSOUT=* //INITREC DD * INITREC1 /* //SYSIN DD * REPRO INFILE(INITREC) - OUTDATASET(FEK.#CUST.LSTRANS.FILE) IF LASTCC = 4 THEN SET MAXCC=0 BLDINDEX IDS(FEK.#CUST.LSTRANS.FILE) - ODS(FEK.#CUST.LSTRANS.FILE.AIX) IF LASTCC = 0 THEN - DEFINE PATH (NAME(FEK.#CUST.LSTRANS.FILE.PATH) - PATHENTRY (FEK.#CUST.LSTRANS.FILE.AIX)) /*
Nota:
Os usuários precisam da autoridade UPDATE para esse conjunto de dados VSAM, conforme descrito em Considerações sobre Segurança.

Atualizações de rsed.envvars para Conversão de Nomes Longos/Curtos

Antes de usar a conversão de nomes longos/curtos, remova o comentário e configure a variável de ambiente rsed.envvars _SCLMDT_TRANTABLE para que corresponda ao nome do VSAM de conversão de nomes longos/curtos.

O rsed.envvars está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

Nota:
A tarefa iniciada RSED deve ser reiniciada para assimilar as mudanças feitas.

(Opcional) Instalar e Customizar Ant

Esta etapa será necessária apenas se você planejar utilizar o suporte à construção JAVA/J2EE no SCLM.

Apache Ant é uma ferramenta de construção Java de software livre e pode ser transferida por download de http://ant.apache.org/. O Ant consiste em arquivos de texto e scripts que são distribuídos no formato ASCII e, portanto, requerem que uma conversão ASCII/EBCDIC seja executada no z/OS UNIX.

Execute as seguintes etapas para implementar Ant no z/OS e para defini-lo para o Developer para System z:

Por exemplo:

Para testar se a inicialização do Ant foi bem-sucedida:

Nota:
Configurar a instrução PATH assim é necessário apenas para teste, não para uso operacional.

Atualizações SCLM para SCLMDT

O próprio SCLM também requer customização para funcionar com o SCLM Developer Toolkit. Consulte o IBM Rational Developer para System z SCLM Developer Toolkit Administrator's Guide (SC23-9801) para obter informações adicionais sobre as tarefas de customização necessárias:

Para concluir a customização e as tarefas de definição de projetos, o administrador de SCLM precisa conhecer vários valores customizáveis do Developer para System z, conforme descrito em Tabela 13.

Tabela 13. Lista de Verificação do Administrador de SCLM
Descrição
  • Valor Padrão
  • Onde encontrar a resposta
Valor
Biblioteca de amostra do Developer para System z
  • FEK.SFEKSAMV
  • Instalação SMP/E
Diretório de amostra do Developer para System z
  • /usr/lpp/rdz/samples
  • Instalação SMP/E
Diretório bin Java
  • /usr/lpp/java/J5.0/bin
  • rsed.envvars - $JAVA_HOME/bin
Diretório bin Ant
  • /usr/lpp/Apache/Ant/apache-ant-1.7.1/bin
  • rsed.envvars - $ANT_HOME/bin
Diretório home WORKAREA
  • /var/rdz
  • rsed.envvars - $_CMDSERV_CONF_HOME
Diretório home de configuração de projeto do SCLMDT
  • /var/rdz/sclmdt
  • rsed.envvars - $_SCLMDT_CONF_HOME
VSAM de tradução de nomes longos/abreviados
  • FEK.#CUST.LSTRANS.FILE
  • rsed.envvars - $_SCLMDT_TRANTABLE

Remover Arquivos Antigos de WORKAREA

SCLM Developer Toolkit e TSO/ISPF Client Gateway do ISPF compartilham o mesmo WORKAREA, que pode precisar de limpeza periódica. Consulte (Opcional) Limpeza de WORKAREA para obter informações adicionais sobre isso.

(Opcional) Outras Tarefas de Customização

Esta seção combina uma variedade de tarefas opcionais de customização. Siga as instruções na seção apropriada para configurar o serviço desejado.

(Opcional) Procedimento Armazenado do DB2

Você precisará da assistência de um administrador de WLM e de um administrador de DB2 para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

  • Atualização do WLM
  • Novo membro PROCLIB
  • Atualização do DB2

O Developer para System z fornece um procedimento armazenado do DB2 de amostra (Construtor de Procedimentos Armazenados PL/I e COBOL) com o propósito de construir Procedimentos Armazenados COBOL e PL/I a partir do cliente do Developer para System z.

Nota:
Os membros de amostra ELAXM* estão localizados em FEK.#CUST.JCL e FEK.#CUST.PROCLIB, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Alterações do Workload Manager (WLM)

Use os painéis do WLM (workload management) para associar um ambiente de aplicativos ao procedimento JCL do espaço de endereços WLM para o Stored Procedure Builder para PL/I e COBOL. Consulte MVS Planning Workload Management (SA22-7602) para obter informações sobre como fazer isso.

Nota:
Você pode criar um novo ambiente de aplicativos no WLM para o Stored Procedure Builder para PL/I e COBOL, ou você pode incluir as definições necessárias em um ambiente existente.

Alterações do PROCLIB

Customize a tarefa de Procedimento Armazenado de amostra FEK.#CUST.PROCLIB(ELAXMSAM), conforme descrito no membro, e copie-a para SYS1.PROCLIB. Conforme mostrado na amostra de código a seguir, você deve fornecer o seguinte:

Figura 24. ELAXMSAM - Tarefa de Procedimento Armazenado do DB2
//ELAXMSAM PROC RGN=0M,
//            NUMTCB=1,
//            APPLENV=#wlmwd4z,
//            DB2SSN=#ssn,
//            DB2PRFX='DSN810',
//            COBPRFX='IGY.V3R4M0',
//            PLIPRFX='IBMZ.V3R6M0',
//            LIBPRFX='CEE',
//            LODPRFX='FEK'
//*
//DSNX9WLM EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,DYNAMNBR=10,
//            PARM='&DB2SSN,&NUMTCB,&APPLENV'
//STEPLIB  DD DISP=SHR,DSN=&DB2PRFX..SDSNEXIT
//         DD DISP=SHR,DSN=&DB2PRFX..SDSNLOAD
//         DD DISP=SHR,DSN=&LIBPRFX..SCEERUN
//         DD DISP=SHR,DSN=&COBPRFX..SIGYCOMP
//         DD DISP=SHR,DSN=&PLIPRFX..SIBMZCMP
//SYSEXEC  DD DISP=SHR,DSN=&LODPRFX..SFEKPROC
//SYSTSPRT DD SYSOUT=*
//CEEDUMP  DD SYSOUT=*
//SYSABEND DD DUMMY
//SYSUT1   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//SYSUT2   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//SYSUT3   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//SYSUT4   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//SYSUT5   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//SYSUT6   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//SYSUT7   DD  UNIT=SYSALLDA,SPACE=(CYL,(1,1))
//*
Nota:

Mudanças no DB2

Customize e envie o membro de amostra ELAXMJCL no conjunto de dados FEK.#CUST.JCL para definir o Procedimento Armazenado para o DB2. Consulte a documentação no membro para obter instruções de customização.

Figura 25. ELAXMJCL - Definição do procedimento armazenado do DB2
//ELAXMJCL JOB <parâmetros da tarefa>
//JOBPROC  JCLLIB ORDER=(#hlq.SDSNPROC)
//JOBLIB   DD DISP=SHR,DSN=#hlq.SDSNEXIT
//         DD DISP=SHR,DSN=#hlq.SDSNLOAD
//*
//RUNTIAD  EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
 DSN S(#ssn) R(1) T(1)
 RUN PROGRAM(DSNTIAD) PLAN(DSNTIAD) -
 LIB('#hlq.RUNLIB.LOAD')
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
 CREATE PROCEDURE SYSPROC.ELAXMREX
  ( IN  FUNCTION_REQUEST   VARCHAR(20)      CCSID EBCDIC
  , IN  SQL_ROUTINE_NAME   VARCHAR(27)      CCSID EBCDIC
  , IN  SQL_ROUTINE_SOURCE VARCHAR(32672)   CCSID EBCDIC
  , IN  BIND_OPTIONS       VARCHAR(1024)    CCSID EBCDIC
  , IN  COMPILE_OPTIONS    VARCHAR(255)     CCSID EBCDIC
  , IN  PRECOMPILE_OPTIONS VARCHAR(255)     CCSID EBCDIC
  , IN  PRELINK_OPTIONS    VARCHAR(32672)   CCSID EBCDIC
  , IN  LINK_OPTIONS       VARCHAR(255)     CCSID EBCDIC
  , IN  ALTER_STATEMENT    VARCHAR(32672)   CCSID EBCDIC
  , IN  SOURCE_DATASETNAME VARCHAR(80)      CCSID EBCDIC
  , IN  BUILDOWNER         VARCHAR(8)       CCSID EBCDIC
  , IN  BUILDUTILITY       VARCHAR(18)      CCSID EBCDIC
  , OUT RETURN_VALUE       VARCHAR(255)     CCSID EBCDIC )
 PARAMETER STYLE GENERAL  RESULT SETS 1
 LANGUAGE REXX            EXTERNAL NAME   ELAXMREX
 COLLID   DSNREXCS        WLM ENVIRONMENT ELAXMSAM
 PROGRAM TYPE MAIN        MODIFIES SQL DATA
 STAY RESIDENT NO         COMMIT ON RETURN NO
 ASUTIME NO LIMIT         SECURITY USER;

 COMMENT ON PROCEDURE SYSPROC.ELAXMREX IS
 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMREX), INTERFACE LEVEL 0.01';

 GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMREX TO PUBLIC;
//*
Nota:
Certifique-se de que a cláusula WLM ENVIRONMENT na instrução CREATE PROCEDURE especifique o nome do procedimento do ambiente WLM que foi definido para o Construtor do Procedimento Armazenado PL/I e COBOL (padrão ELAXMSAM).

(Opcional) Suporte de Enterprise Service Tools (EST)

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

O cliente do Developer para System z possui um componente de geração de códigos chamado Enterprise Service Tools (EST). Dependendo do tipo de código que está sendo gerado, esse código baseia-se nas funções fornecidas pela instalação do host do Developer para System z. Como tornar essas funções disponíveis está descrito nas seguintes seções:

Nota:
O Enterprise Service Tools (EST) inclui diversas ferramentas, como o Modelador de Fluxo de Serviço (SFM) e os Serviços XML para a Empresa (XSE).

(Opcional) Suporte de Idioma Bidirecional do CICS

Você precisará da assistência de um administrador do CICS para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

  • Atualização de JCL da região do CICS
  • Definir um programa para o CICS

O componente EST (Enterprise Service Tools) do Developer para System z suporta formatos diferentes das mensagens de interface em árabe e hebraico, assim como a apresentação de dados bidirecionais e a edição em todos os editores e visualizações. Em aplicativos terminais, telas da esquerda para a direita e da direita para a esquerda são suportadas, assim como campos numéricos e campos com orientação oposta à tela.

A funcionalidade e os recursos bidirecionais adicionais incluem:

Além disso, o código gerado por EST pode suportar transformação bidi em ambientes diferentes do CICS SFR (Service Flow Runtime). Um exemplo são os aplicativos em lote. Você pode criar os geradores de EST para incluir chamadas nas rotinas de conversão bidirecional, especificando as opções de transformação bidirecional apropriadas nos assistentes de geração EST e vinculando os programas gerados com a biblioteca de conversão bidirecional apropriada, FEK.SFEKLOAD.

Execute as seguintes tarefas para ativar o suporte à linguagem bidirecional do CICS:

  1. Coloque os módulos de carregamento FEJBDCMP e FEJBDTRX do FEK.SFEKLOAD na concatenação RPL do CICS (instrução DD DFHRPL). É recomendável fazer isso incluindo o conjunto de dados de instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.
    Nota:
    Se você não concatenar o conjunto de dados de instalação, mas copiar os módulos para um conjunto de dados novo ou existente, lembre-se de que esse módulos são DLLs e DEVEM residir em uma biblioteca PDSE.
  2. Definir FEJBDCMP e FEJBDTRX como programas para o CICS usando o comando CEDA apropriado, por exemplo:

    CEDA DEF PROG(FEJBDCMP) LANG(LE) G(xxx)
    CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)

(Opcional) Mensagens de Erro IRZ de Diagnóstico

Essa tarefa de customização não exige assistência, mas exige os seguintes recursos ou tarefas de customização especiais:

  • Atualização de LINKLIST
  • Atualização de JCL da região CICS

O cliente do Developer para System z possui um componente de geração de códigos chamado Enterprise Service Tools (EST). Para que o código gerado por EST emita mensagens de erro de diagnóstico, todos os módulos IRZ* e IIRZ* da biblioteca de carregamento FEK.SFEKLOAD devem ser disponibilizados por meio do código gerado. EST pode gerar códigos para os seguintes ambientes:

Quando o código gerado for executado em uma transação do CICS, então inclua todos os módulos IRZ* e IIRZ* no FEK.SFEKLOAD para o DFHRPL DD da região CICS. É recomendável fazer isso incluindo o conjunto de dados de instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.

Para todas as outras situações, torne todos os módulos IRZ* e IIRZ* no FEK.SFEKLOAD disponíveis por meio de STEPLIB ou LINKLIST. É recomendável fazer isso incluindo o conjunto de dados de instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.

Se você decidir usar o STEPLIB, deverá definir os módulos não disponíveis por meio do LINKLIST na diretiva STEPLIB da tarefa que executa o código.

Se os módulos de carregamento não estiverem disponíveis e um erro for encontrado pelo código gerado, a seguinte mensagem será emitida:

IRZ9999S Falha ao recuperar o texto de uma mensagem de tempo de execução 

do Ambiente de Linguagem. Verifique se o módulo de mensagem de tempo de execução do Ambiente de Linguagem do recurso IRZ está instalado em DFHRPL ou em STEPLIB.

(Opcional) Criptografia SSL do RSE

Você precisará da assistência de um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

  • Atualização de LINKLIST
  • Regra de segurança para incluir conjuntos de dados controlados pelo programa
  • (Opcional) Regra de segurança para incluir certificado para SSL

A comunicação externa (cliente-host) pode ser criptografada utilizando-se SSL (Secure Socket Layer). Esse recurso é desativado por padrão e é controlado pelas configurações no ssl.properties.

O ssl.properties está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

O cliente se comunica com o daemon RSE durante a configuração de conexão e com o servidor RSE durante a sessão real. Os dois fluxos de dados são criptografados quando o SSL é ativado.

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 SSL são necessárias 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 14. 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 Java / suportados
Nota:

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

A amostra de código a seguir mostra o arquivo ssl.properties de amostra, que deve ser customizado para corresponder a seu ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado; não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.

Figura 26. ssl.properties - Arquivo de configuração SSL
# ssl.properties - arquivo de configuração SSL
enable_ssl=false

# Daemon Properties

#daemon_keydb_file=
#daemon_keydb_password=
#daemon_key_label=

# Server Properties

#server_keystore_file=
#server_keystore_password=
#server_keystore_label=
#server_keystore_type=JCERACFKS

As propriedades do daemon e do servidor precisarão ser configuradas somente se você ativar o SSL. Consulte o Apêndice A. Configurando o SSL e a Autenticação X.509 para obter informações adicionais sobre a configuração do SSL.

enable_ssl
Ative ou desative a comunicação SSL. O padrão é false. As únicas opções válidas são true e false.
daemon_keydb_file
Nome do anel de chaves RACF (ou produto de segurança semelhante). Forneça o nome do banco de dados de chaves se você utilizou gskkyman para criar um banco de dados de chaves em vez de utilizar um anel de chaves. Remova o comentário e customize essa diretiva se o SSL estiver ativado.
daemon_keydb_password
Deixe a linha comentada ou em branco se você usar um conjunto de chaves, caso contrário, forneça a senha do banco de dados de chaves. Remova o comentário e customize essa diretiva se o SSL estiver ativado e você estiver usando um banco de dados de chaves gskkyman.
daemon_key_label
O rótulo do certificado usado no anel de chaves ou banco de dados de chaves, se não estiver definido como padrão. O comentário deve ser removido, se o padrão for usado. Remova o comentário e customize essa diretiva se o SSL estiver ativado e você não estiver usando o certificado de segurança padrão.
server_keystore_file
Nome do keystore criado pelo comando Java's keytool, ou o nome do conjunto de chaves RACF (ou produto de segurança semelhante) se server_keystore_type=JCERACFKS. Remova o comentário e customize essa diretiva se o SSL estiver ativado.
server_keystore_password
Deixe a linha comentada ou em branco se você utilizar um conjunto de chaves, caso contrário, forneça a senha do keystore. Remova o comentário e customize essa diretiva se o SSL estiver ativado e você estiver utilizando um keystore keytool.
server_keystore_label
O rótulo do certificado usado no conjunto de chaves ou keystore. O padrão é o primeiro certificado válido encontrado. Remova o comentário e customize essa diretiva se o SSL estiver ativado e você não estiver usando o certificado de segurança padrão.
server_keystore_type
Tipo de keystore. O padrão é JKS. Valores válidos são:
Tabela 15. Tipos de keystore válidos
Palavra-chave Tipo de keystore
JKS Keystore Java
JCERACFKS Conjunto de chaves compatível com SAF, em que a chave privada do certificado é armazenada no banco de dados de segurança.
JCECCARACFKS O conjunto de chaves compatível com SAF, em que a chave privada do certificado é armazenada usando ICSF, a interface para o hardware criptográfico do System z.
Nota:
No momento da publicação, o IBM z/OS Java exige uma atualização do arquivo /usr/lpp/java/J5.0/lib/security/java.security para suportar JCECCARACFKS. A seguinte linha deve ser incluída:
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA

O arquivo resultante será semelhante a este:

security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
security.provider.2=com.ibm.jsse2.IBMJSSEProvider2
security.provider.3=com.ibm.crypto.provider.IBMJCE
security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
security.provider.5=com.ibm.security.cert.IBMCertPath
security.provider.6=com.ibm.security.sasl.IBMSASL 

(Opcional) Rastreio de RSE

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

O Developer para System z suporta diferentes níveis de rastreio do fluxo do programa interno para propósitos de resolução de problemas. O RSE e alguns dos serviços chamados pelo RSE usam as configurações no rsecomm.properties para conhecer o nível desejado de detalhes nos logs de saída.

Atenção: A alteração destas configurações pode causar diminuição no desempenho e deverá ser realizada somente sob a orientação do IBM Support Center.

O rsecomm.properties está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.

A amostra de código a seguir mostra o arquivo rsecomm.properties, que pode ser customizado para corresponder às suas necessidades de rastreio. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado; não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.

Figura 27. rsecomm.properties - Arquivo de configuração da criação de log
# server.version - DO NOT MODIFY!
server.version=5.0.0

# Logging level
# 0 - Log error messages
# 1 - Log error and warning messages
# 2 - Log error, warning and info messages
debug_level=1

# Log location
# Log_To_StdOut
# Log_To_File
log_location=Log_To_File
server.version
Versão do servidor de criação de log. O padrão é 5.0.0. Não modifique.
debug_level
Nível de detalhe para logs de saída. O padrão é 1 (registrar mensagens de erro e de aviso). Observe que debug_level controla o nível de detalhe de vários serviços (e, portanto, vários arquivos de saída). O aumento do nível de detalhe causará diminuição no desempenho e deverá ser realizado somente sob a orientação do IBM Support Center. Consulte Rastreio do RSE para obter informações adicionais sobre quais logs são controlados por essa diretiva.

Os valores válidos são os seguintes:

0 Registrar apenas mensagens de erro.
1 Registrar mensagens de erro e de aviso.
2 Mensagens de erro de log, de aviso e informativa.
Nota:
debug_level pode ser alterado dinamicamente com o comando do operador modify rsecommlog, conforme descrito no Comandos do Operador.
log_location
Meio de saída para a criação de log relacionada ao RSE. O padrão é Log_To_File. Não altere ao usar o método de conexão do daemon RSE (padrão), a menos que direcionado pelo centro de suporte IBM.

Os valores válidos são os seguintes:

Log_To_File Enviar mensagens de log para um arquivo separado no diretório de saída do log.
  • Daemon RSE: rsedaemon.log em daemonlog
  • Conjuntos de encadeamento RSE: rseserver.log em daemonlog
  • Usuário: rsecomm.log em userlog/.eclipse/RSE/$LOGNAME
Log_To_StdOut Enviar mensagens de log para stdout.
  • Daemon RSE: roteado novamente para DD STDOUT na tarefa iniciada RSED
  • Conjuntos de encadeamentos do RSE: indefinido
  • Usuário: roteado novamente para stdout.log em userlog/.eclipse/RSE/$LOGNAME

daemonlog é o valor da diretiva daemon.log em rsed.envvars. Se a diretiva daemon.log for comentada ou não estiver presente, o caminho inicial do ID de usuário designado à tarefa iniciada RSED será usado. O caminho inicial é definido no segmento de segurança OMVS do ID de usuário.

Os logs específicos do usuário vão para userlog/.eclipse/RSE/$LOGNAME, em que userlog é o valor da diretiva user.log 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.

(Opcional) Grupos de Propriedade Baseados em Host

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

Os clientes do Developer para System z podem definir grupos de propriedades que contém valores padrão para várias propriedades (por exemplo, as opções do compilador COBOL a serem usadas durante a compilação do código de origem COBOL). O Developer para System z possui alguns valores padrão integrados, mas permite também a definição de padrões customizados, específicos do sistema.

O local dos arquivos de configuração do valor padrão e do grupo de propriedades customizadas é definido em propertiescfg.properties, que está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

A amostra de código a seguir mostra o arquivo propertiescfg.properties, que deve ser customizado para corresponder ao seu ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado. Não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.

Figura 28. propertiescfg.properties - Arquivo de configuração de grupos de propriedades baseado no host
#
# grupos de propriedades baseados no host - arquivo de configuração raiz
#
ENABLED=FALSE
RDZ-VERSION=7.5.0.0
PROPERTY-GROUP=/var/rdz/properties
DEFAULT-VALUES=/var/rdz/properties
ATIVADO
Indica se o Developer para System z utilizará os arquivos de configuração do valor padrão e do grupo de propriedades. O padrão é FALSE. As únicas opções válidas são TRUE e FALSE.
RDZ-VERSION
Nível mínimo de cliente do Developer para System z para usar grupos de propriedades baseadas no host. O padrão é 7.5.0.0. Não modifique.
PROPERTY-GROUP
O local do arquivo de configuração do grupo de propriedades. O padrão é /var/rdz/properties.
DEFAULT-VALUES
O local do arquivo de configuração do valor padrão. O padrão é /var/rdz/properties.

Consulte o Centro de Informações do Developer para System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para obter informações adicionais sobre a criação do arquivo de configuração do grupo de propriedades (propertygroups.xml) e o arquivo de configuração do valor-padrão (defaultvalues.xml).

(Opcional) Projetos Baseados no Host

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

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 com base no usuário. Esses "projetos baseados no host" parecem e funcionam exatamente como os projetos definidos no cliente, exceto pelo fato de que suas estruturas, membros e propriedades não podem ser modificados pelo cliente e são acessíveis apenas quando conectados ao host.

O local das definições de projeto é definido em projectcfg.properties, que está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

A amostra de código a seguir mostra o arquivo projectcfg.properties, que deve ser customizado para corresponder ao seu ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado. Não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.

Figura 29. projectcfg.properties - Arquivo de configuração de projetos baseados no host
#
# Projetos baseados em host - arquivo de configuração raiz
#
# WSED-VERSION - não modifique!
WSED-VERSION=7.0.0.0
# especifique o local dos arquivos de definição do projeto baseado em host
PROJECT-HOME=/var/rdz/projects
WSED-VERSION
Nível mínimo de cliente do Developer para System z para usar projetos baseados no host. O padrão é 7.0.0.0. Não modifique.
PROJECT-HOME
O diretório base para as definições de projeto. O padrão é /var/rdz/projects.

Nota:
Par ativar projetos baseados no host, um arquivo project.instance deve existir em /var/rdz/projects/USERID, em que /var/rdz/projects é o local dos arquivos de definição de projeto e USERID é o ID do usuário (em maiúsculas) com o qual o desenvolvedor efetua logon.

Consulte o Centro de Informações do Developer para System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para obter informações adicionais sobre projetos baseados no host.

(Opcional) Integração do File Manager

Você precisará da assistência de um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

  • Regra de segurança para incluir conjuntos de dados controlados pelo programa

O Developer para System z suporta acesso direto do cliente a um conjunto limitado de funções do IBM File Manager para z/OS. O IBM File Manager para z/OS oferece ferramentas abrangentes para trabalhar com conjuntos de dados do MVS, arquivos z/OS UNIX, dados do DB2, IMS e CICS. Essas ferramentas incluem utilitários já familiares de procura, edição, cópia e impressão localizados no ISPF, aprimorados para atender às necessidades dos desenvolvedores de aplicativos. Na versão atual do Developer para System z, apenas a procura e a edição dos conjuntos de dados MVS (incluindo todos os tipos de VSAM), criando e editando modelos de conjuntos de dados MVS (incluindo modelos dinâmicos) e os utilitários de cópia avançados são suportados.

Observe que o produto IBM File Manager para z/OS deve ser solicitado, instalado e configurado separadamente. Consulte o Rational Developer para System z Prerequisites (SC23-7659) para saber qual o nível do File Manager é necessário em sua versão do Developer para System z. A instalação e customização deste produto não está descrita neste manual.

Observe que o Developer para System z e o File Manager não suportam mais a interface em lote para acessar serviços do File Manager. O uso do listener do File Manager é necessário agora.

Nota:
Além das tarefas de configuração normais do listener, descritas na documentação do File Manager, o Developer para System z exige que os conjuntos de dados STEPLIB do servidor sejam controlados pelo programa.

As definições da Integração do File Manager necessárias para o Developer para System z estão armazenadas em FMIEXT.properties, que está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.

A amostra de código a seguir mostra o arquivo FMIEXT.properties, que deve ser customizado para corresponder ao seu ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado. Não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.

Figura 30. FMIEXT.properties - Arquivo de configuração do File Manager
# Propriedades de Extensão do FMI (File Manager Integration)
#
enabled=false    
fmlistenport=1960

ativado
Indica se o listener do File Manager está disponível no mesmo sistema host ou não. O valor padrão é false. Os únicos valores permitidos são true e false.
fmlistenport
Porta usada pelo listener do File Manager. O padrão é 1960. A comunicação nesta porta está confinada para a máquina host.

(Opcional) Caracteres Não-editáveis

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

Alguns caracteres não são convertidos adequadamente entre as páginas de códigos do host (baseadas em EBCDIC) e as páginas de códigos do cliente (baseadas em ASCII). O editor do cliente Developer para System z utiliza as definições no arquivo uchars.settings para identificar esses caracteres não editáveis. Ao abrir um conjunto de dados com um caractere identificado em uchars.settings, o editor impingirá o modo somente leitura para evitar que o conjunto de dados seja corrompido quando ele for salvo.

O uchars.settings está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas. Observe também que é recomendado não alterar esse arquivo, a menos que você seja orientado pelo centro de suporte da IBM.

Figura 31. uchars.settings - Arquivo de configuração de caracteres não editáveis
# uchars.settings - pontos de código não editáveis
#
*          *          0D 15 25;

# DBCS (japonês, coreano e & chinês)
IBM-930    *          0D 15 1E 1F 25;
IBM-933    *          0D 15 1E 1F 25;
IBM-935    *          0D 15 1E 1F 25;
IBM-937    *          0D 15 1E 1F 25;
IBM-939    *          0D 15 1E 1F 25;
IBM-1390   *          0D 15 1E 1F 25;
IBM-1399   *          0D 15 1E 1F 25;
IBM-1364   *          0D 15 1E 1F 25;
IBM-1371   *          0D 15 1E 1F 25;
IBM-1388   *          0D 15 1E 1F 25;

# UNICODE
UTF-8      *          0D 0A;
UTF-16BE   *          0D 0A;
UTF-16LE   *          0D 0A;
UTF-16     *          0D 0A;

O arquivo consiste de várias entradas no seguinte formato:

HOST-CODEPAGE  LOCAL-CODEPAGE  HEX-CODEPOINTS ;

Em que HEX-CODEPOINTS é uma lista delimitada por espaços em branco de pontos de código hexadecimais de 2 dígitos que identificam os caracteres não editáveis. A lista deve terminar com um ponto e vírgula (;).

As regras de sintaxe a seguir são aplicadas:

(Opcional) Usando REXEC (ou SSH)

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

REXEC (Execução Remota) é um serviço TCP/IP para permitir que clientes executem um comando no host. O SSH (Secure Shell) é um serviço semelhante, mas aqui todas as comunicações são criptografadas utilizando o SSL (Secure Socket Layer). O Developer para System z usa qualquer serviço para executar ações remotas (baseadas em host) em subprojetos z/OS UNIX.

O Developer para System z também pode ser configurado para usar o REXEC (ou SSH) para iniciar um servidor RSE no host. Observe, no entanto, que cada conexão iniciada dessa forma resultará em um servidor RSE separado, cada um utilizando um quantidade razoável de recursos do sistema. Portanto, esse método de conexão alternativo é viável apenas para um pequeno número de conexões.

Além disso, como o método de conexão alternativa do REXEC (ou SSH) ignora o daemon RSE, ele não terá acesso a todos os serviços do host descritos nesta publicação, como processamento e auditoria de servidor único. Entre em contato com o suporte da IBM para saber se um serviço de host específico é suportado pelo método de conexão alternativo REXEC.

Nota:
O Developer para System z utiliza a versão de REXEC do z/OS UNIX, e não a versão do TSO.

Ações Remotas (Baseadas em Host) para Subprojetos z/OS UNIX

As ações remotas (baseadas em host) para subprojetos z/OS UNIX exigem que REXEC ou SSH estejam ativos no host. Se o REXEC/SSH não estiver configurado para utilizar a porta padrão, o cliente Developer para System z deve definir a porta correta a ser usada por subprojetos do z/OS UNIX. Isso pode ser feito selecionando a página de preferências Janela > Preferências... > z/OS Soluções > Subprojetos do USS > Opções de Ação Remota. Consulte o Configuração de REXEC (ou SSH) para saber qual porta é usada.

Método de Conexão Alternativo do RSE

Os clientes do Developer para System z precisam conhecer os dois valores para iniciar a conexão do RSE por meio do REXEC (ou SSH), como a seguir:

Configuração de REXEC (ou SSH)

O Communications Server IP Configuration Guide (SC31-8775) descreve as etapas necessárias para configurar o REXEC (ou o SSH). Consulte o Apêndice C. Configurando o INETD para conhecer algumas considerações de configuração específicas do Developer para System z (não existem etapas de configuração específicas do Developer para System z).

Uma porta comum usada pelo REXEC é 512. Para verificar isso, você pode verificar os serviços /etc/inetd.conf e /etc/services para localizar o número de porta usado.

O mesmo princípio aplica-se ao SSH. Sua porta comum é 22 e o nome do servidor é sshd.

Nota:
/etc/inetd.conf e /etc/services podem ter nomes diferentes. Consulte o Apêndice C. Configurando o INETD para obter informações adicionais.

(Opcional) Transação APPC para o Serviço de Comandos TSO

Você precisará da assistência de um administrador de APPC e de um administrador de WLM para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:

  • Atualização de LINKLIST
  • Transação APPC
  • Atualização do WLM

O serviço TSO Commands pode ser implementado como um programa de transações APPC, FEKFRSRV. Essa transação age como um servidor host para executar comandos do TSO e do ISPF que são emitidos a partir da estação de trabalho. A APPC não é necessária na estação de trabalho, pois o cliente se comunica com o FEKFRSRV por meio do RSE. Cada cliente pode ter uma conexão ativa com vários hosts ao mesmo tempo.

Nota:

Preparação

Consulte MVS Planning Workload Management (SA22-7602) para obter informações adicionais sobre o gerenciamento de WLM/SRM. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre segmentos OMVS e perfis de proteção de conjuntos de dados.

Implementação

Nota:
Os membros de amostra FEKAPPC* estão localizados 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 da Customização para obter mais detalhes.

  1. Definir as informações de planejamento (classe) para o planejador de transações APPC se não estiver utilizando uma classe de transação existente. Inclua uma definição em SYS1.PARMLIB(ASCHPMxx) para a classe a ser usada pelo programa de transações FEKFRSRV. Essa classe é usada na JCL de amostra FEK.#CUST.JCL(FEKAPPCC). Portanto, a classe em FEKAPPCC deve corresponder à classe definida em SYS1.PARMLIB(ASCHPMxx). Por exemplo:
    CLASSADD
      CLASSNAME(A)
      MAX(20)
      MIN(1)
      MSGLIMIT(200)
     
    Nota:
    • O serviço TSO Commands precisa que as especificações padrão sejam especificadas nas seções OPTIONS e TPDEFAULT de SYS1.PARMLIB(ASCHPMxx). Consulte o Apêndice D. Configurando o APPC para obter informações adicionais.
    • A classe de transação APPC usada deve ter iniciadores APPC suficientes para permitir um inicializador para cada usuário simultâneo do Developer para System z.
  2. Defina a transação do APPC que agirá como um servidor de comandos. Você pode utilizar a JCL de amostra FEK.#CUST.JCL(FEKAPPCC) para definir essa transação. As instruções sobre como customizar esta JCL estão localizadas na JCL.
    Nota:
    1. Se você alterou o nome do programa de transações (padrão FEKFRSRV) nesta etapa, o novo nome deverá ser designado à _FEKFSCMD_TP_NAME_ em rsed.envvars, conforme descrito em Arquivo de Configuração do RSE rsed.envvars.
    2. A transação APPC utiliza o REXX exec FEKFRSRV, localizado em FEK.SFEKPROC. Não altere esta localização se desejar que seja possível que a manutenção SMP/E seja ativada automaticamente.
    3. A JCL de amostra também é fornecida para exibir, FEK.#CUST.JCL(FEKAPPCL), ou excluir, FEK.#CUST.JCL(FEKAPPCX), a transação.
  3. Ative o RSE para utilizar APPC ao remover o comentário da diretiva RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" em rsed.envvars, conforme descrito em Arquivo de Configuração do RSE rsed.envvars.
  4. Controle a prioridade de dispatch do programa de transações associando FEKFRSRV a um grupo de domínios e de desempenhos no WLM (Workload Manager). Como o FEKFRSRV emite comandos do TSO, ele deve ser designado a um grupo de desempenho TSO.
  5. Defina um segmento OMVS padrão para o sistema ou um indivíduo para cada usuário do Developer para System z.
  6. Forneça aos usuários do Developer para System z o acesso READ para FEK.SFEKPROC, a biblioteca executável TSO do Developer para System z.

Considerações sobre Uso de APPC

(Opcional) Limpeza de WORKAREA

Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais.

O TSO/ISPF Client Gateway do ISPF e a função SCLM Developer Toolkit usam o diretório WORKAREA para armazenar arquivos de trabalho temporários, que são removidos antes de a sessão ser fechada. Entretanto, a saída temporária é às vezes deixada para trás, por exemplo, se existir um erro de comunicação durante o processamento. Por essa razão, é recomendável limpar o diretório WORKAREA regularmente.

O z/OS UNIX fornece um script de shell, skulker, que exclui arquivos com base no diretório em que estão e em suas idades. Combinado com o daemon cron do z/OS UNIX, que executa comandos em datas e horas especificadas, você pode configurar uma ferramenta automatizada que limpe periodicamente o diretório WORKAREA. Consulte o UNIX System Services Command Reference (SA22-7802) para obter informações adicionais sobre o script skulker e o daemon cron.

Nota:
O WORKAREA está localizado em /var/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.

Verificação de Instalação

Após concluir a customização do produto, é possível usar os Installation Verification Programs (IVPs) descritos neste capítulo para verificar o êxito da configuração dos componentes principais do produto.

Verificar Tarefas Iniciadas

JMON, JES Job Monitor

Inicie a tarefa iniciada JMON (ou a tarefa do usuário). As informações de inicialização no DD STDOUT devem terminar com a seguinte mensagem:

JM200I Inicialização do servidor concluída.

Se a tarefa terminar com o código de retorno 66, FEK.SFEKAUTH não será autorizada pelo APF.

Nota:
Inicie o JES Job Monitor antes de continuar com os outros testes do IVP.

LOCKD, Daemon de Bloqueio

Inicie a tarefa iniciada LOCKD (ou a tarefa do usuário). O daemon de bloqueio emite a seguinte mensagem do console na inicialização bem-sucedida:

FEK501I Lock daemon started, port=4036, cleanup interval=1440,
 log level=1

RSED, Daemon RSE

Inicie a tarefa RSED iniciada (ou tarefa do usuário) com o parâmetro IVP=IVP. Com esse parâmetro, o servidor será encerrado após executar alguns testes de verificação de instalação. A saída desses testes está disponível em DD STDOUT. No caso de alguns erros, os dados também estão disponíveis em DD STDERR. Os dados de STDOUT devem ser semelhantes à seguinte amostra:

Nota:
Inicie o daemon RSE sem o parâmetro IVP, antes de continuar com os outros testes do IVP. O daemon RSE emite a seguinte mensagem do console na inicialização bem-sucedida:
FEK002I RseDaemon started. (port=4035)
teste do IVP do daemon RSE

Quarta-feira, 2 de julho, 17h11min52s 2008 UTC
uid=8(STCRSE) gid=1(STCGROUP)

A porta do daemon RSE é 4035
Arquivos de configuração do RSE localizados em /etc/rdz

-------------------------------------------------------------
variáveis de ambiente atuais
-------------------------------------------------------------
@="/usr/lpp/rdz/bin/rsed.sh" @[1]="4035" @[2]="/etc/rdz"
CGI_DTCONF="/var/rdz/sclmdt"
CGI_DTWORK="/var/rdz"
CGI_TRANTABLE="FEK.#CUST.LSTRANS.FILE"
CLASSPATH=".:/usr/lpp/rdz/lib:/usr/lpp/rdz/lib/dstore_core.jar:/usr/lpp/
ERRNO="0"
HOME="/tmp"
IFS="
"
JAVA_HOME="/usr/lpp/java/J5.0"
JAVA_PROPAGATE="NO"
LANG="C"
LIBPATH=".:/usr/lib:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/classi
LINENO="66"
LOGNAME="STCRSE"
MAILCHECK="600"
OLDPWD="/tmp"
OPTIND="1"
PATH=".:/usr/lpp/java/J5.0/bin:/usr/lpp/rdz/bin:/usr/lpp/ispf/bin:/bin:/
PPID="33554711"
PS1="\$ "
PS2="> "
PS3="#? "
PS4="+ "
PWD="/etc/rdz"
RANDOM="27298"
RSE_CFG="/etc/rdz"
RSE_HOME="/usr/lpp/rdz"
RSE_LIB="/usr/lpp/rdz/lib"
SECONDS="0"
SHELL="/bin/sh"
STEPLIB="NONE"
TZ="EST5EDT"
_BPX_SHAREAS="YES"
_BPX_SPAWN_SCRIPT="YES"
_CEE_DMPTARG="/tmp"
_CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)"
_CMDSERV_BASE_HOME="/usr/lpp/ispf"
_CMDSERV_CONF_HOME="/etc/rdz"
_CMDSERV_WORK_HOME="/var/rdz"
_RSE_CMDSERV_OPTS="&SESSION=SPAWN"
_RSE_DAEMON_CLASS="com.ibm.etools.zos.server.RseDaemon"
_RSE_DAEMON_IVP_TEST="1"
_RSE_DAEMON_PORT="4035"
_RSE_JAVAOPTS=" -DISPF_OPTS='&SESSION=SPAWN' -DA_PLUGIN_PATH=/usr/lpp/rd
_RSE_POOL_SERVER_CLASS="com.ibm.etools.zos.server.ThreadPoolProcess"
_RSE_PWD="/tmp"
_RSE_SERVER_CLASS="org.eclipse.dstore.core.server.Server"
_RSE_SERVER_TIMEOUT="120000"
_SCLMDT_BASE_HOME="/usr/lpp/rdz"
_SCLMDT_CONF_HOME="/var/rdz/sclmdt"
_SCLMDT_TRANTABLE="FEK.#CUST.LSTRANS.FILE"
_SCLMDT_WORK_HOME="/var/rdz"
_SCLM_BASE="/var/rdz/WORKAREA"
_SCLM_BWBCALL="/usr/lpp/rdz/bin/BWBCALL"
_SCLM_DWGET="/var/rdz/WORKAREA"
_SCLM_DWTRANSFER="/var/rdz/WORKAREA"
_SCLM_J2EEPUT="/var/rdz/WORKAREA"

-------------------------------------------------------------
teste de inicialização java...
-------------------------------------------------------------
java versão "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-2008031
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-2008
J9VM - 20080314_17962_bHdSMr
JIT  - 20080130_0718ifx2_r8
GC   - 200802_08)
JCL  - 20080314

-------------------------------------------------------------
teste do IVP de TCP/IP...
-------------------------------------------------------------

Quarta-feira, 2 de julho de 2008, 13h11min54s EDT
uid=8(STCRSE) gid=1(STCGROUP)
utilizando /etc/rdz/rsed.envvars

-------------------------------------------------------------
Configuração do resolvedor TCP/IP (ordem de procura do z/OS UNIX):
-------------------------------------------------------------
Resolver Trace Initialization Complete -> 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         = STCRSE
 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

-------------------------------------------------------------
PassTicket IVP test...
-------------------------------------------------------------

Success, PassTicket IVP finished normally

-------------------------------------------------------------
IVP do daemon RSE finalizado

Verificar Serviços

A instalação do Developer para System z fornece vários Installation Verification Programs (IVP) para os serviços básicos e opcionais. Os scripts do IVP estão localizados no diretório de instalação, padrão /usr/lpp/rdz/bin/.

Tabela 17. IVPs para Serviços
fekfivpa (Opcional) Conexão do Serviço TSO Commands Utilizando APPC
fekfivpd Conexão do Daemon RSE
fekfivpi Conexão do TSO/ISPF Client Gateway do ISPF
fekfivpj Conexão do JES Job Monitor
fekfivpl Conexão do Daemon de Bloqueio
fekfivpr (Opcional) Conexão REXEC
fekfivps (Opcional) Conexão SCLMDT
fekfivpt Configuração de TCP/IP
fekfivpz (Opcional) Script de Shell REXEC/SSH

As tarefas descritas abaixo 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.

Um tamanho de região grande é necessário para o ID do usuário que executa os IVPs, pois as funções, como Java, que exigem muita memória, serão executadas. Você deve definir o tamanho da região como 131072 kilobytes (128 megabytes) ou mais alto.

O seguinte erro de amostra é uma indicação clara de um tamanho de região insuficiente. (Mas outros erros podem ocorrer, também. Por exemplo, Java pode falhar ao iniciar).

CEE5213S The signal SIGPIPE was received.
%z/OS UNIX command%: command was killed by signal number 13
    %line-number% *-*   %REXX command%
       +++ RC(137) +++ 

Nota:
As tarefas iniciadas do Developer para System z devem estar ativas antes de iniciar o teste do IVP.

Inicialização do IVP

Todos os comandos de amostra nesta seção esperam que certas variáveis de ambiente sejam configuradas. Dessa forma, os scripts do IVP ficam disponíveis através da instrução PATH e o local dos arquivos de configuração customizados é conhecido. Use os comandos pwd e cd para verificar e alterar seu diretório atual para o diretório com os arquivos de configuração customizados. O shell script ivpinit pode então ser usado para configurar as variáveis de ambiente RSE, como na seguinte amostra ($ é o prompt do z/OS UNIX):

$ pwd
/u/userid
$ cd /etc/rdz
$ . ./ivpinit
Arquivos de configuração do RSE localizados em /etc/rdz -- padrão
incluído /usr/lpp/rdz/bin em PATH

O primeiro "." (ponto) em . ./ivpinit é um comando do z/OS UNIX para executar o shell no ambiente atual, para que os conjuntos de variáveis do ambiente no shell sejam efetivados após sair do shell. O segundo ponto está relacionado ao diretório atual.

Nota:

Para obter informações sobre o diagnóstico de problemas de conexão do RSE, consulte Resolução de Problemas de Configuração ou as Notas Técnicas na Página de Suporte do Developer para System z, em http://www-306.ibm.com/software/awdtools/rdz/support/.

Disponibilidade de Porta

A disponibilidade da porta do JES Job Monitor, do daemon RSE e, opcionalmente, de REXEC ou SSH pode ser verificada emitindo-se o comando netstat. O resultado deve mostrar as portas usadas por esses serviços, como nas seguintes amostras ($ é o prompt do z/OS UNIX):

IPv4

$ netstat
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP       13:57:36
User Id  Conn     Local Socket      Foreign Socket    State
-------  ----     ------------      --------------    -----
RSED     0000004B 0.0.0.0..4035          0.0.0.0..0             Listen
LOCKD    0000004C 0.0.0.0..4036     0.0.0.0..0        Listen
JMON     00000037 0.0.0.0..6715     0.0.0.0..0        Listen

IPv6

$ netstat
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP       14:03:35
User Id  Conn     State
-------  ----     -----
RSED     0000004B Listen
  Local Socket:   0.0.0.0..4035
  Foreign Socket: 0.0.0.0..0
LOCKD    0000004C Listen
  Local Socket:   0.0.0.0..4036
  Foreign Socket: 0.0.0.0..0
JMON     00000037 Listen
  Local Socket:   0.0.0.0..6715
  Foreign Socket: 0.0.0.0..0

Configuração de TCP/IP

Com o uso de APPC para o serviço TSO Commands, o Developer para 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. Consulte o Apêndice B. Configurando o TCP/IP para obter informações adicionais sobre a configuração TCP/IP e do Resolver. Verifique as configurações atuais executando o seguinte comando:

fekfivpt
Nota:
Esse IVP emite o comando TCPIP netstat, que pode ser protegido contra execução por seu software de segurança.

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

o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

-------------------------------------------------------------
Configuração do resolvedor TCP/IP (ordem de procura do z/OS UNIX):
-------------------------------------------------------------
Resolver Trace Initialization Complete -> 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

Conexão do Daemon RSE

Para verificar a conexão do daemon RSE, execute o seguinte comando. Substitua 4035 pela porta usada pelo daemon RSE e USERID por um ID de usuário válido.

fekfivpd 4035 USERID

Depois de solicitar uma senha, o comando deve retornar uma saída como essa no seguinte exemplo ($ é o prompt do z/OS UNIX):

$ fekfivpd 4035 USERID

Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars

o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

Senha:
SSL está desativado
conectado
8108
570655399
Bem-sucedido
Nota:
Ao testar uma conexão ativada pelo SSL, verifique se você especificou a porta correta, caso receba esta mensagem de erro: gsk_secure_socket_init() falhou: Soquete fechado pelo parceiro remoto.

Conexão do JES Job Monitor

Para verificar a conexão do JES Job Monitor, execute o seguinte comando. Substitua 6715 pelo número da porta do JES Job Monitor.

fekfivpj 6715

O comando deve retornar a mensagem de confirmação do JES Job Monitor, como na seguinte amostra ($ é o prompt do z/OS UNIX):

$ fekfivpj 6715

Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)
using /etc/rdz/rsed.envvars

o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

hostName=CDFMVS08
hostAddr=9.42.112.75
Aguardando resposta do JES Job Monitor...
ACKNOWLEDGE01v03

Bem-sucedido

Conexão do Daemon de Bloqueio

Verifique a conexão do daemon de bloqueio executando o seguinte comando.

fekfivpl

O comando deve retornar uma saída como na seguinte amostra ($ é o prompt do z/OS UNIX):

$ fekfivpl

Segunda-feira, 29 de junho de 2009, 8h00m38s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars

o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

hostName=CDFMVS08
hostAddr=9.42.112.75

Registrando usuário no Daemon de Bloqueio...
Aguardando resposta do Daemon de Bloqueio...

Consultando o Daemon de Bloqueio...
Aguardando resposta do Daemon de Bloqueio...
USERID


Cancelando o registro do usuário do Daemon de Bloqueio...
Aguardando resposta do Daemon de Bloqueio...

Consultando o Daemon de Bloqueio...
Aguardando resposta do Daemon de Bloqueio...


Bem-sucedido

Conexão do TSO/ISPF Client Gateway do ISPF

Verifique a conexão com o TSO/ISPF Client Gateway do ISPF executando o seguinte comando:

fekfivpi

O comando deve retornar o resultado de verificações relacionadas ao TSO/ISPF Client Gateway do ISPF, (variáveis, módulos HFS, início e parada da sessão TSO/ISPF), como na seguinte amostra ($ é o prompt do z/OS UNIX):

$ fekfivpi
 
Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars
 
o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

-------------------------------------------------------------
conteúdo do /etc/rdz/ISPF.conf:
-------------------------------------------------------------
 
ispmlib=ISP.SISPMENU 
isptlib=ISP.SISPTENU 
ispplib=ISP.SISPPENU 
ispslib=ISP.SISPSLIB 
sysproc=ISP.SISPCLIB,FEK.SFEKPROC 
 
-------------------------------------------------------------
Verificação de instalação do host para o RSE
Verifique as mensagens de log do IVP do HOST a seguir:
-------------------------------------------------------------

Conexão RSE e verificação apenas de inicialização da sessão TSO/ISPF base

*** VERIFICAR: VARIÁVEIS DE AMBIENTE - variável de ambiente exibidas a seguir:

Server PATH         = 
/usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin:
/bin:/usr/sbin:.

STEPLIB             = FEK.SFEKAUTH:FEK.SFEKLOAD

_CMDSERV_BASE_HOME  = /usr/lpp/ispf
_CMDSERV_CONF_HOME  = /etc/rdz
_CMDSERV_WORK_HOME  = /var/rdz
-------------------------------------------------------------
*** CHECK : USS MODULES
Verificando o Diretório ISPF : /usr/lpp/ispf
Verificando módulos em /usr/lpp/ispf/bin directory
Verificando arquivo de configuração do ISPF ISPF.conf
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
*** VERIFICAR: INICIALIZAÇÃO DO TSO/ISPF
(A sessão do TSO/ISPF será inicializada)
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
*** VERIFICAR: Encerrando a sessão IVP do TSO/ISPF
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
Verificação da instalação do host concluída com êxito
-------------------------------------------------------------
Nota:
Se alguma verificação ISPF falhar, informações mais detalhadas serão mostradas.

fekfivpi tem os seguintes parâmetros opcionais não-posicionais:

-file
fekfivpi pode produzir grandes quantidades de saída (centenas de linhas). O parâmetro -file envia essa saída para um arquivo, userlog/.eclipse/RSE/$LOGNAME/fekfivpi.log, em que userlog é o valor da diretiva user.log em rsed.envvars e $LOGNAME é o ID do usuário (em maiúsculas). Se a diretiva user.log for comentada ou não estiver presente, o caminho inicial será usado. O caminho inicial é definido em seu segmento de segurança OMVS.
-debug
O parâmetro -debug cria saída de teste detalhada. Não utilize essa opção, a menos que orientado pelo IBM Support Center.

(Opcional) Conexão do Serviço TSO Commands Utilizando APPC

Verifique a conexão com o servidor do TSO Commands (usando APPC), ao executar o seguinte comando. Substitua USERID por um ID do usuário válido:

fekfivpa USERID

Depois de solicitar uma senha, o comando deve retornar a conversação do APPC, como na amostra a seguir ($ é o prompt do z/OS UNIX):

$ fekfivpa USERID
Digite a Senha:
 
Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars
 
o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

20070607 13:57:18.584060 /usr/lpp/rdz/bin/fekfscmd: version=Oct 2003
20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ********
20070607 13:57:18.586800 APPC: Allocate succeeded
20070607 13:57:18.587022  Conversation id is 0DDBD3F80000000D
20070607 13:57:18.587380 APPC: Set Send Type succeeded
20070607 13:57:26.736674 APPC: Confirm succeeded
20070607 13:57:26.737027  Req to send recd value is  0
20070607 13:57:26.737546 APPC: SEND_DATA return_code = 0
20070607 13:57:26.737726  request_to_send_received =  0
20070607 13:57:26.737893  Send Data succeeded
20070607 13:57:26.738169 APPC: Set Prepare to Receive type succeeded
20070607 13:57:26.738580 APPC: Prepare to Receive succeeded
20070607 13:57:26.808899 APPC: Receive data
20070607 13:57:26.809122  RCV return_code = 0
20070607 13:57:26.809270  RCV data_received= 2
20070607 13:57:26.809415  RCV received_length= 29
20070607 13:57:26.809556  RCV status_received= 4
20070607 13:57:26.809712  RCV req_to_send= 0
20070607 13:57:26.809868  Receive succeeded
:IP: 0 9.42.112.75 1674 50246
20070607 13:57:26.810533 APPC: CONFIRMED succeeded

(Opcional) Conexão SCLMDT

Verifique a conexão com o SCLM Developer Toolkit executando o seguinte comando:

fekfivps

O comando deve retornar o resultado de verificações relacionadas ao SCLM Developer Toolkit (variáveis, módulos HFS, tempo de execução do REXX, início e parada da sessão TSO/ISPF), como na seguinte amostra ($ é o prompt z/OS UNIX):

$ fekfivps

Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars
 
o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

-------------------------------------------------------------
conteúdo do /etc/rdz/ISPF.conf:
-------------------------------------------------------------
 
ispmlib=ISP.SISPMENU 
isptlib=ISP.SISPTENU 
ispplib=ISP.SISPPENU 
ispslib=ISP.SISPSLIB 
sysproc=ISP.SISPCLIB,FEK.SFEKPROC 
-------------------------------------------------------------
Verificação de instalação do host para o RSE
Verifique as mensagens de log do IVP do HOST a seguir:
-------------------------------------------------------------

*** VERIFICAR: VARIÁVEIS DE AMBIENTE - variável de ambiente exibidas a seguir:

Server PATH         = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin:
/bin:/usr/sbin:.

STEPLIB             = FEK.SFEKAUTH:FEK.SFEKLOAD

_CMDSERV_BASE_HOME  = /usr/lpp/ispf
_CMDSERV_CONF_HOME  = /etc/rdz
_CMDSERV_WORK_HOME  = /var/rdz
_SCLMDT_CONF_HOME  = /var/rdz/sclmdt
_SCLMDT_WORK_HOME  = /var/rdz
_SCLMDT_TRANTABLE  = FEK.#CUST.LSTRANS.FILE 

-------------------------------------------------------------
*** CHECK : VERIFICAÇÃO DE CONFIGURAÇÃO DO CAMINHO JAVA
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
*** CHECK : USS MODULES
Verificando o Diretório ISPF : /usr/lpp/ispf
Verificando módulos no diretório /usr/lpp/ispf/bin
Verificando o arquivo de configuração do ISPF ISPF.conf
Verificando o diretório bin de instalação : /usr/lpp/rdz/bin
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
*** VERIFICAR: AMBIENTE DE TEMPO DE EXECUÇÃO DO REXX
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
*** VERIFICAR: INICIALIZAÇÃO DO TSO/ISPF
(A sessão do TSO/ISPF será inicializada)
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
*** VERIFICAR: Encerrando a sessão IVP do TSO/ISPF
RC=0
MSG: BEM-SUCEDIDO

-------------------------------------------------------------
Verificação da instalação do host concluída com êxito
-------------------------------------------------------------
Nota:
Se alguma verificação SCLMDT falhar, informações mais detalhadas serão mostradas.

fekfivps tem os seguintes parâmetros opcionais e não-posicionais:

-file
fekfivps pode produzir grandes quantidades de saída (centenas de linhas). O parâmetro -file envia essa saída para um arquivo, userlog/.eclipse/RSE/$LOGNAME/fekfivps.log, em que userlog é o valor da diretiva user.log em rsed.envvars e $LOGNAME é o ID do usuário (em maiúsculas). Se a diretiva user.log for comentada ou não estiver presente, o caminho inicial será usado. O caminho inicial é definido em seu segmento de segurança OMVS.
-debug
O parâmetro -debug cria saída de teste detalhada. Não utilize essa opção, a menos que orientado pelo IBM Support Center.

(Opcional) Conexão REXEC

Para verificar a conexão REXEC, execute o seguinte comando. Substitua 512 pela porta usada pelo REXEC e USERID por um ID de usuário válido.

fekfivpr 512 USERID

Depois de solicitar uma senha, o comando deve retornar o rastreio REXEC, um aviso de tempo limite, a versão Java e a mensagem do servidor RSE, como na seguinte amostra ($ é o prompt do z/OS UNIX):

$ fekfivpr 512 USERID
Digite a Senha:
 
Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars
 
o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

$ EZYRC01I  Chamando a função rexec_af com o seguinte:
EZYRC02I  Host: CDFMVS08, user USERID, cmd cd /etc/rdz;export RSE_USER_ID=USERI
D;./server.zseries -ivp, port 512
EZYRC19I  Data socket = 4, Control socket = 6.

teste do IVP do servidor RSE

CDFMVS08 -- Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)

Arquivos de configuração RSE localizados em /etc/rdz --default
 
O ID do usuário RSE éUSERID --default

-------------------------------------------------------------
Limites de tamanho do Espaço de Endereço
-------------------------------------------------------------
o limite de tamanho do espaço de endereço atual é 2147483647 (2048,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

-------------------------------------------------------------
histórico do serviço
-------------------------------------------------------------
Sexta-feira, 19 de junho de 2009 00h01m00s -- COPY -- HHOP760 v7600 

criado em 18 de junho de 2009 ------------------------------------------------------------- espera ver mensagens de tempo limite após um teste de IVP bem-sucedido ------------------------------------------------------------- iniciando servidor RSE no plano de fundo -- Sexta-feira,
19 de junho de 2009 15h59m05s EDT ------------------------------------------------------------- java versão "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T ativado) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 Iniciando Servidor DStore... Servidor Iniciado com Êxito 8108 Servidor executando em: CDFMVS08

Nota:

(Opcional) Script de Shell REXEC/SSH

Esse teste de IVP pode ser ignorado se o teste anterior, descrito em (Opcional) Conexão REXEC, for concluído com êxito.

Verifique se o script de shell usado pela conexão REXEC e SSH, executando o seguinte comando:

fekfivpz

O comando deve retornar um aviso de tempo limite, a versão Java e a mensagem do servidor RSE, como na seguinte amostra ($ é o prompt do z/OS UNIX):

$ fekfivpz

Quarta-feira, 2 de julho de 2008, 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)

utilizando /etc/rdz/rsed.envvars

o limite de tamanho do espaço de endereço atual é 1914675200 (1826,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

-------------------------------------------------------------

Teste do IVP do servidor RSE

CDFMVS08 -- Quarta-feira, 2 de julho de 2008 15h00m27s EDT
uid=1(USERID) gid=0(GROUP)

Arquivos de configuração do RSE localizados em /etc/rdz --default
O ID do usuário RSE éUSERID --default

-------------------------------------------------------------
Limites de tamanho do Espaço de Endereço
-------------------------------------------------------------
o limite de tamanho do espaço de endereço atual é 2147483647 (2048,0 MB)
o limite de tamanho do espaço de endereço máximo é 2147483647 (2048,0 MB)

-------------------------------------------------------------
histórico do serviço
-------------------------------------------------------------
Sexta-feira, 19 de junho de 2009 00h01m00s -- COPY -- HHOP760 v7600 

criado em 18 de junho de 2009 ------------------------------------------------------------- espera ver mensagens de tempo limite após um teste de IVP bem-sucedido ------------------------------------------------------------- iniciando servidor RSE no plano de fundo -- Sexta-feira,
19 de junho de 2009 15h59m05s EDT ------------------------------------------------------------- java versão "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T ativado) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 Iniciando Servidor DStore... Servidor Iniciado com Êxito 8108 Servidor executando em: CDFMVS08
Nota:

Informações do Developer para System z

Comandos do Operador

Este capítulo fornece uma visão geral dos comandos disponíveis do operador (ou console) para o Developer para System z. Consulte o Como Ler um Diagrama de Sintaxe se não estiver familiarizado com os diagramas de sintaxe usados para explicar o formato de comando.

Start (S)

Use o comando START para iniciar dinamicamente uma tarefa iniciada (STC). A versão abreviada do comando é a letra S.

JES Job Monitor

Figura 33. Comando do operador START JMON
JES Job Monitor
procname
O nome do membro em uma biblioteca de procedimentos que é usada para iniciar o servidor. O nome padrão usado durante a configuração do host é JMON.
HLQ=install_hlq
Qualificador de alto nível usado para instalar o Developer para System z. O padrão é FEK.
CFG=config_member
Nome absoluto do conjunto de dados e do membro do arquivo de configuração do JES Job Monitor. O padrão é FEK.#CUST.PARMLIB(FEJJCNFG).
PRM=-TV
Ativar o modo detalhado (rastreio). O rastreio causará diminuição no desempenho e deverá ser realizado somente sob a orientação do IBM Support Center.

Daemon RSE

Figura 34. Comando do operador START RSED
Daemon RSE
procname
O nome do membro em uma biblioteca de procedimentos que é usada para iniciar o servidor. O nome padrão usado durante a configuração do host é RSED.
PORT=port
A porta usada pelo daemon RSE para os clientes se conectarem. O padrão é 4035.
HOME='install_path'
O prefixo do caminho e o /usr/lpp/rdz obrigatório usado para instalar o Developer para System z. O padrão é '/usr/lpp/rdz'. Observe que o caminho do z/OS UNIX faz distinção entre maiúsculas e minúsculas e que deve ser colocado entre aspas simples (') para preservar os caracteres minúsculos.
CNFG='config_path'
Local absoluto dos arquivos de configuração armazenados no z/OS UNIX. O padrão é '/etc/rdz'. Observe que o caminho do z/OS UNIX faz distinção entre maiúsculas e minúsculas e que deve ser colocado entre aspas simples (') para preservar os caracteres minúsculos.
IVP=IVP
Não inicia o servidor, mas executa o Installation Verification Program (IVP) do daemon RSE.

Daemon de Bloqueio

Figura 35. Comando do operador START LOCKD
Daemon de Bloqueio
procname
O nome do membro em uma biblioteca de procedimentos que é usada para iniciar o servidor. O nome padrão usado durante a configuração do host é LOCKD .
HOME='install_path'
O prefixo do caminho e o /usr/lpp/rdz obrigatório usado para instalar o Developer para System z. O padrão é '/usr/lpp/rdz'. Observe que o caminho do z/OS UNIX faz distinção entre maiúsculas e minúsculas e que deve ser colocado entre aspas simples (') para preservar os caracteres minúsculos.
CNFG='config_path'
Local absoluto dos arquivos de configuração armazenados no z/OS UNIX. O padrão é '/etc/rdz'. Observe que o caminho do z/OS UNIX faz distinção entre maiúsculas e minúsculas e que deve ser colocado entre aspas simples (') para preservar os caracteres minúsculos.
LOG=log_level
O nível de detalhe da saída no DD STDOUT.

Modify (F)

O comando MODIFY permite consultar e alterar dinamicamente as características de uma tarefa ativa. A versão abreviada do comando é a letra F.

JES Job Monitor

Figura 36. Comando do operador MODIFY JMON
JES Job Monitor
procname
O nome do membro em uma biblioteca de procedimentos que foi usada para iniciar o servidor. O nome padrão usado durante a configuração do host é JMON.
-TV
Ativar o modo detalhado (rastreio). O rastreio causará diminuição no desempenho e deverá ser realizado somente sob a orientação do IBM Support Center.
-TN
Desativar o modo detalhado (rastreio).

Daemon RSE

Figura 37. Comando do operador MODIFY RSED
comando do operador MODIFY RSED
procname
O nome do membro em uma biblioteca de procedimentos que foi usada para iniciar o servidor. O nome padrão usado durante a configuração do host é RSED.
DISPLAY CLIENT
Exibe os clientes ativos.
<id do cliente> : <id do usuário> : <conectado desde>
DISPLAY PROCESS[,CLEANUP,DETAIL]
Exibe os processos do conjunto de encadeamento RSE. Pode haver vários processos, que são usados para balanceamento de carga dos usuários conectados.
ID do processo(<ID do processo>) Uso de Memória

(<uso do heap Java>%) Clientes(<número de clientes>) Ordem(<ordem de inicialização>)
<status do erro>
Nota:
  • <processid> pode ser usado em comandos do operador z/OS UNIX específicos do processo.
  • Cada processo tem seu próprio heap Java, cujo tamanho pode ser configurado em rsed.envvars.
  • <ordem de inicialização> é um número sequencial que indica a ordem em que os conjuntos de encadeamentos foram iniciados. O número corresponde ao número usado no nome do arquivo dos arquivos stderr.*.log e stdout.*.log.

Em situações normais, o <status do erro> é em branco. O Tabela 18 documenta os possíveis valores não-em branco para <status do erro>.

Tabela 18. Status do erro do conjunto de encadeamento
Estado Descrição
*erro grave* O processo do conjunto de encadeamento encontrou um erro irrecuperável e operações interrompidas. Os outros campos de status mostram os últimos valores conhecidos. Use a opção CLEANUP do comando de modificação DISPLAY PROCESS para remover essa entrada da tabela.
*processo interrompido* O processo do conjunto de encadeamento foi interrompido por Java, z/OS UNIX ou por um comando do operador. Os outros campos de status mostram os últimos valores conhecidos. Use a opção CLEANUP do comando de modificação DISPLAY PROCESS para remover essa entrada da tabela.
*tempo limite* O processo do conjunto de encadeamento não respondeu de maneira adequada ao daemon RSE durante uma solicitação de conexão do cliente. Os outros campos de status mostram os valores atuais. O conjunto de encadeamento é excluído para solicitações futuras de conexão do cliente. O status *tempo limite* é redefinido quando um cliente atendido por este conjunto de encadeamento efetua logoff.

Informações adicionais são fornecidas quando a opção DETAIL do comando de modificação do DISPLAY PROCESS é usado:

ID do processo(33555087) ASId(002E) Nome da Tarefa (RSED8) Ordem(1)
 PROCESS LIMITS:    CURRENT  HIGHWATER      LIMIT
  JAVA HEAP USAGE(%)     10         56        100
  CLIENTS                 0         25         60
  MAXFILEPROC            83        103      64000
  MAXPROCUSER            97         99        200
  MAXTHREADS              9         14       1500
  MAXTHREADTASKS          9         14       1500

O campo ASId é o ID do espaço de endereço, em nota hexadecimal. A tabela de limites do processo mostra o uso do recurso atual, o limite máximo para o uso do recurso e o limite de recurso. Note que devido a outros fatores de limitação, o limite definido pode nunca ser alcançado.

CANCEL ID=clientid
Cancela uma conexão do cliente com base no ID do cliente, que é mostrado no comando DISPLAY CLIENT modify.
CANCEL USER=userid
Cancela uma conexão do cliente com base no ID de usuário cliente, que é mostrado no comando modify DISPLAY CLIENT.
RSECOMMLOG {ON,OFF,I,W,E,2,1,0}
Controla o nível de rastreio do servidor RSE (rsecomm.log) e os serviços do conjunto de dados do MVS (lock.log e ffs*.log). O padrão de inicialização é definido em rsecomm.properties. Existem três níveis de detalhes disponíveis:
E ou 0 ou OFF Mensagens de erro apenas.
W ou 1 Mensagens de erro e de aviso. Essa é a configuração padrão em rsecomm.properties.
I ou 2 ou ON Mensagens de erro, de aviso e informativas.

O rastreio detalhada prejudica o desempenho e deverá ser feito apenas com orientação do centro de suporte IBM.

RSEDAEMONLOG {ON,OFF,I,E,2,0}
Controla o nível de detalhes do rastreio do daemon RSE (rsedaemon.log). O padrão de inicialização é definido em rsecomm.properties. Existem dois níveis de detalhes disponíveis:
E ou 0 ou OFF Mensagens de erro apenas.
I ou 2 ou ON Mensagens de erro, de aviso e informativas.

O rastreio detalhada prejudica o desempenho e deverá ser feito apenas com orientação do centro de suporte IBM.

RSESERVERLOG {ON,OFF,I,E,2,0}
Controla o nível de detalhes do rastreio dos conjuntos de encadeamento RSE (rseserver.log). O padrão de inicialização é definido em rsecomm.properties. Existem dois níveis de detalhes disponíveis:
E ou 0 ou OFF Mensagens de erro apenas.
I ou 2 ou ON Mensagens de erro, de aviso e informativas.

O rastreio detalhada prejudica o desempenho e deverá ser feito apenas com orientação do centro de suporte IBM.

RSESTANDARDLOG {ON,OFF}
Desativa (OFF) ou ativa (ON) a atualização dos arquivos de log mantidos nos fluxos stdout e stderr dos conjuntos de encadeamento (stdout.*.log e stderr.*.log). O padrão de inicialização é definido pela diretiva enable.standard.log em rsed.envvars.

O rastreio detalhada prejudica o desempenho e deverá ser feito apenas com orientação do centro de suporte IBM.

SWITCH
Alterna para um novo arquivo de log de auditoria.
Nota:

Daemon de Bloqueio

Figura 38. Comando do operador MODIFY LOCKD
Daemon de Bloqueio
procname
O nome do membro em uma biblioteca de procedimentos que foi usada para iniciar o servidor. O nome padrão usado durante a configuração do host é LOCKD .
QUERY dataset[(member)]
Consulte o status de bloqueio do conjunto de dados ou membro listado. O servidor responderá com uma das mensagens a seguir:
BPXM023I (stclock) dataset[(member)] NOT LOCKED 
BPXM023I (stclock) dataset[(member)] LOCKED BY userid 
Nota:
  • O servidor também relatará bloqueios de relatórios mantidos por outros produtos, como o ISPF.
  • Os bloqueios mantidos pelos clientes do Developer para System z que não conseguiram se registrar com o daemon de bloqueio resultarão no espaço de endereço do servidor do conjunto de encadeamento (RSEDx) que está sendo relatado como o proprietário do bloqueio.

    A mensagem do console FEK513W é gerada quando o servidor RSE não consegue registrar o cliente com o daemon de bloqueio. Os valores ASID e TCB mencionados nesta mensagem podem ser comparados em relação à saída do comando do operador D GRS,RES=(*,dataset[(member)]) para localizar o usuário real que está mantendo o bloqueio.

Stop (P)

Use o comando STOP para parar uma tarefa ativa. A versão abreviada do comando é a letra P.

Figura 39. Comando do operador STOP
procname
O nome do membro em uma biblioteca de procedimentos que foi usada para iniciar o servidor. Os nomes padrão usados durante a configuração do host são JMON, RSED e LOCKD para o JES Job Monitor, o daemon RSE e o daemon de bloqueio, respectivamente.

Mensagens do Console

JES Job Monitor

O JES Job Monitor não possui mensagens de console específicas de um produto. O servidor conta com o z/OS e o JES para gerar mensagens do console para ações realizadas por clientes do Developer para System z.

Daemon RSE, Servidor do Conjunto de Encadeamento RSE e Daemon de Bloqueio

A Tabela 19 lista as mensagens do console específicos de um produto geradas pelo daemon RSE, pelo servidor do conjunto de encadeamentos RSE e pelo daemon de bloqueio.

Tabela 19. Mensagens de Console do RSE
ID da Mensagem Texto de mensagem
FEK001I RseDaemon sendo inicializado em modo bit {0}
FEK002I RseDaemon iniciado. (porta={0})
FEK003I Pára o comando que está sendo processado
FEK004I RseDaemon: Tamanho Máximo de Heap={0}MB e Tamanho do AS privado={1}MB
FEK005I Processo do servidor iniciado. (processId={0})
FEK009I RseDaemon está aguardando o processo do servidor iniciar.
FEK010I (local do rsed.envvars = {0})
FEK011I (diretório do log = {0})
FEK100E O valor da porta/tempo limite do daemon deve ser dígitos
FEK101E JRE {0} ou superior necessário
FEK102E Argumentos inválidos recebidos: {0}
FEK103E Disco Quase Cheio em {0}
FEK104E O número máximo de processos foi atingido
FEK105E Erro ao enviar dados de auditoria (rc={0})
FEK110E Falha de socket(). razão=({0})
FEK111E Falha de setsockopt(). razão=({0})
FEK112E Falha de bind(). razão=({0})
FEK113E Falha de listen(). razão=({0})
FEK114E Falha de accept(). razão=({0})
FEK115E Falha de write(). razão=({0})
FEK116E Falha de pipe(). razão=({0})
FEK117E Falha de socketpair(). razão=({0})
FEK118E Falha de select(). razão=({0})
FEK119E Falha de _console(). razão=({0})
FEK130E Falha de gsk_environment_open(). razão=({0})
FEK131E Falha de gsk_attribute_set_enum(GSK_PROTOCOL_SSLV2). razão=({0})
FEK132E Falha de gsk_attribute_set_enum(GSK_PROTOCOL_SSLV3). razão=({0})
FEK133E Falha de gsk_attribute_set_enum(GSK_PROTOCOL_TLSV1). razão=({0})
FEK134E Falha de gsk_attribute_set_buffer(GSK_KEYRING_FILE). razão=({0})
FEK135E Falha de gsk_attribute_set_buffer(GSK_KEYRING_PW). razão=({0})
FEK136E Falha de gsk_environment_init(). razão=({0})
FEK137E Falha de gsk_secure_socket_open(). razão=({0})
FEK138E Falha de gsk_attribute_set_numeric_value(GSK_FD). razão=({0})
FEK139E Falha de gsk_attribute_set_buffer(GSK_KEYRING_LABEL). razão=({0})
FEK140E Falha de gsk_attribute_set_enum(GSK_SESSION_TYPE). razão=({0})
FEK141E Falha de gsk_attribute_set_callback(GSK_IO_CALLBACK). razão=({0})
FEK142E Falha de gsk_secure_socket_init(). razão=({0})
FEK143E Falha de gsk_attribute_set_enum(GSK_CLIENT_AUTH_TYPE). razão=({0})
FEK144E Falha de gsk_get_cert_info. razão=({0})
FEK145E Falha de gsk_secure_socket_read(). razão=({0})
FEK146E Falha de gsk_secure_socket_write(). razão=({0})
FEK150E RseDaemon encerrado de forma anormal; {0}
FEK201I O comando {0} foi processado
FEK202E Comando Inválido Fornecido
FEK203E Comando de Exibição Inválido: Exibir Processo|Cliente
FEK204E Comando de Cancelamento Inválido: Cancelar ID=|Usuário=
FEK205E O comando não foi processado devido a ALTERNAÇÕES consecutivas
FEK206E O Recurso de Log de Auditoria não está ativo
FEK207I Nenhum Cliente a ser exibido
FEK208I {0} cancelado
FEK209I Nenhum Processo a ser exibido
FEK210I {0} cancelado devido a logon duplicado
FEK501I Daemon de bloqueio iniciado, porta={0}, intervalo de limpeza={1}, nível de log={2}
FEK502I Daemon de bloqueio sendo encerrado
FEK510E Daemon de bloqueio, porta ausente
FEK511E Daemon de bloqueio, porta errada, porta={0}
FEK512E Daemon de bloqueio, erro de soquete, porta={0}
FEK513W Daemon de bloqueio, falha de registro, ASID={0}, TCB={1}, USER={2}
FEK514W Daemon de bloqueio, nível de log errado, nível de log={0}
BPXM023I (stclock) dataset[(member)] NOT LOCKED
BPXM023I (stclock) dataset[(member)] LOCKED BY userid
BPXM023I Comando (stclock), WRONG COMMAND
BPXM023I Comando (stclock), MISSING ARGUMENT
BPXM023I Argumento (stclock), WRONG ARGUMENT

Como Ler um Diagrama de Sintaxe

O diagrama de sintaxe mostra como especificar um comando para que o sistema operacional possa interpretar corretamente o que você digitar. Leia o diagrama de sintaxe da esquerda para a direita e de cima para baixo, seguindo a linha horizontal (o caminho principal).

Símbolos

Os símbolos a seguir são usados em diagramas de sintaxe:

Símbolo Descrição
>> Marca o início do diagrama de sintaxe.
> Indica que o diagrama de sintaxe continua.
| Marca o início e o fim de um fragmento ou parte do diagrama de sintaxe.
>< Marca o fim do diagrama de sintaxe.

Operandos

Os tipos de operandos a seguir são usados em diagramas de sintaxe:

Os operandos são classificados como palavras-chave ou variáveis:

Exemplo de Sintaxe

No exemplo a seguir, o comando USER é uma palavra-chave. O parâmetro variável necessário é user_id e o parâmetro variável opcional é password. Substitua os parâmetros de variáveis pelos seus próprios valores:

>>--USER--user_id-*----------*----------------------------------><
                  *-password-*

Caracteres Não Alfanuméricos e Espaços em Branco

Se um diagrama mostrar um caractere não alfanumérico (como parênteses, pontos finais, vírgulas, sinais de igual e espaços em branco), você deverá codificar o caractere como parte da sintaxe. Neste exemplo, você deve codificar OPERAND=(001 0.001):

>>--OPERAND--=--(--001-- --0.001--)------------------------><

Selecionando Mais de Um Operando

Uma seta para a esquerda em um grupo de operandos significa que mais de um operando pode ser selecionado, ou apenas um pode ser repetido:

>>--*----------------------*----------------------------><
    *-REPEATABLE_OPERAND_1-*
    *-REPEATABLE_OPERAND_2-*
    *-<--------------------*

Mais Longo que Uma Linha

Se um diagrama for mais longo que uma linha, a primeira linha terminará com uma ponta de seta única e a segunda linha começará com uma ponta de seta única:

>>--| A primeira linha de um diagrama de sintaxe que é mais longo que uma linha |-->
>--| A continuação dos subcomandos, parâmetros ou ambos |---------><

Fragmentos de Sintaxe

Alguns diagramas podem conter fragmentos de sintaxe, que servem para dividir diagramas que são muito longos, complexos ou repetitivos. Os nomes dos fragmentos de sintaxe são compostos por letras maiúsculas e minúsculas e são mostrados no diagrama e no título do fragmento. O fragmento é colocado abaixo do diagrama principal:

 >>--| Fragmento de sintaxe |---------------------------------------><

Fragmento de sintaxe:
|--1ST_OPERAND--,--2ND_OPERAND--,--3RD_OPERAND--|

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 Developer para System z e contém as seguintes seções:

Informações adicionais estão disponíveis na seção Suporte do Web site do Developer para System z (http://www-306.ibm.com/software/awdtools/rdz/support/) 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 Web site (http://www-306.ibm.com/software/awdtools/rdz/library/), você também pode localizar a versão mais recente da documentação do Developer para System z, incluindo whitepapers.

O Developer para System z Centro de Informações do (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) documenta o cliente Developer para System z e como ele interage com o host (a partir de 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 achar que o Developer para System z perdeu uma determinada 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 de Configuração Usando FEKLOGS

O Developer para System z fornece uma tarefa de amostra, FEKLOGS, que reúne todos os arquivos de log z/OS UNIX, bem como as informações de instalação e de configuração do Developer para 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 da Customização 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 SDSF podem usar o comando da linha XDC em SDSF para salvar a saída de tarefa em um conjunto de dados, que, por sua vez, pode ser fornecido ao centro de suporte IBM.

Arquivos de Log

O Developer para 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 o Comandos do Operador para obter informações adicionais.

Criação de Logs do JES Job Monitor

Criação de Log do Daemon de Bloqueio

Criação de Log de Daemon RSE e de Conjunto de Encadeamento

Nota:

Criação de Log de Usuário do RSE

Nota:

Criação de Log de Integração do Fault Analyzer

Criação de Log de Integração do File Manager

Criação de Log do SCLM Developer Toolkit

Criação de Logs do CARMA

Criação de Logs de Transações APPC (Serviço de Comandos do TSO)

Criação de Log de Teste IVP do fekfivpi

Criação de Log de Teste IVP do fekfivps

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. Portanto, pode ser que eles não sejam criados, ou criados em localizações diferentes da mencionada abaixo.

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 para 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. Se você não deseja que dumps de transação sejam criados, inclua a variável de ambiente IBM_JAVA_ZOS_TDUMP=NO em rsed.envvars.

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 20. 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 do 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 do Dump do z/OS UNIX.

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 do Dump do z/OS UNIX.

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 do 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 acima, ele é colocado no stderr.

Rastreio

Rastreio do JES Job Monitor

O rastreio do JES Job Monitor é controlado pelo operador do sistema, conforme descrito no Comandos do Operador.

Rastreio do 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 e (Opcional) Rastreio de RSE para obter mais detalhes.

A criação dos arquivos de log .dstore* é controlada pelas opções de inicialização -DDSTORE_* Java, conforme descrito em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.

Nota:

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 e (Opcional) Rastreio de RSE para obter mais detalhes.

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 do Daemon de Bloqueio

O log específico do daemon de bloqueio está localizado no STDOUT DD da tarefa iniciada LOCKD. A quantidade de dados gravados no log é controlada pelo parâmetro de inicialização LOG. Consulte Comandos do Operador e (Opcional) Rastreio de RSE para obter mais detalhes.

Rastreio do 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 para 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. Esse procedimento é o padrão fornecido no conjunto de dados hlq.SFEKSAMP, mas pode ter sido copiado para um local diferente, como SYS1.PROCLIB, conforme descrito em Procedimentos de Construção Remota ELAXF*.
  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 para System z e incluindo os 4 conjuntos de dados SIDEFILE1->.
  6. Copie o log da tarefa do JES completo em seu PC, por exemplo, abrindo a saída de tarefas no Developer para 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 IBM Support Center.

Bits de Permissão do z/OS UNIX

O Developer para 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 de Sistema de Arquivo SETUID

O RSE (Explorador de Sistema Remoto) é o componente Developer para System z que fornece os serviços principais, como de conexão do 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 para 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 para System z de criar o ambiente de segurança do usuário e falhará no pedido de conexão.

Use o comando TSO ISHELL para listar o status atual do bit SETUID. No painel ISHELL, selecione Sistemas_de_arquivo > 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 RSE (Explorador de Sistema Remoto) é o componente Developer para System z que fornece os serviços principais, como de conexão do 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 Considerações sobre 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 para System z.

Os seguintes arquivos do Developer para System z devem ser controlados pelo programa:

Nota:
Os arquivos libicu*64.* somente estão presentes se você tiver aplicado o PTF Developer para System z que endereça o APAR AM07305 para ativar o suporte 64 bits.

Use o comando z/OS UNIX ls -E para listar os atributos estendidos, em que o bit de controle de programa está marcado com a letra p, conforme mostrado na seguinte amostra ($ é 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 mais informações, consulte UNIX System Services Planning (GA22-7800).

Autorização APF

O Remote Systems Explorer (RSE) é o componente do Developer para System z que fornece serviços principais como conectar o cliente ao host. Ele deve executar o APF autorizado para realizar tarefas como exibir uso do recurso do processo detalhado.

O z/OS UNIX APF bit é configurado 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 do Developer para System z.

Os seguintes arquivos do Developer para System z devem ter autorização APF:

Use o comando do z/OS UNIX ls -E para listar os atributos estendidos, em que o APF bit é marcado com a letra a, como mostrado na seguinte amostra ($ é o prompt do z/OS UNIX):

$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x  aps-  2 usuário     grupo     114688 Sep 17 06:41 bin/fekfrivp

Use o comando do z/OS UNIX extattr +a para configurar o APF bit manualmente, como mostrado na seguinte amostra ($ 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 usuário     grupo     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 Planejamento de Serviços do Sistema UNIX (GA22-7800).

Sticky Bit

Alguns dos serviços opcionais do Developer para 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 "sticky" bit 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 no lugar.

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 para System z.

Os seguintes arquivos do Developer para System z devem ter o sticky bit ativado:

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

Use o comando z/OS UNIX chmod +t para configurar o sticky bit manualmente, conforme mostrado na seguinte amostra ($ e # são 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 deste comando será semelhante ao exemplo abaixo. As portas usadas são o último número (após "..") na coluna "Local Socket". Como estas portas já estão em uso, elas não podem ser usadas para a configuração do Developer para 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 isso não for o que você deseja, então poderá configurar o limite apenas para o Developer para 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 em z/OS 1.10 para 2G, permitindo que tarefas de 64 bits usem até 4GB (os 2GB abaixo da barra e os 2GB acima da barra concedidos pelo 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.

Transação APPC e Serviço de Comandos do TSO

Se não puder utilizar a versão APPC do serviço TSO Commands, haverá duas áreas nas quais os problemas poderão surgir: iniciando a transação do servidor APPC e conectando ao RSE.

O REXX fornecido em (Opcional) Transação APPC para o Serviço de Comandos TSO pode ajudar a resolver problemas de APPC, pois você tem a possibilidade de gerenciar o APPC interativamente por meio dos painéis ISPF. Lembre-se, no entanto, de que você pode desativar a transação com essa ferramenta; a transação ainda está lá, mas não aceitará nenhuma conexão.

A lista a seguir é uma seleção de Notas Técnicas atualmente disponíveis no Web site de suporte (http://www-306.ibm.com/software/awdtools/rdz/support/). Consulte o Web site de suporte para obter mais informações:

Nota:
Esta lista não é definitiva. Verifique o Web site de suporte para obter Notas Técnicas adicionais.

Informações Diversas

Limites do Sistema

SYS1.PARMLIB(BPXPRMxx) define muitas limitações relacionadas ao z/OS UNIX, que pode ser acessado quando muitos clientes do Developer para 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.

Problemas de Requisitos Conhecidos

Falhas ao Abrir Conjuntos de Dados MVS

Ao usar o APPC para o serviços TSO Commands, a leitura e a gravação de um conjunto de dados MVS exige o uso de um domínio do sistema de arquivos físico do soquete. Se o sistema de arquivo não estiver definido adequadamente ou não tiver soquetes suficientes, o gerenciador de bloqueio (FFS) poderá falhar nos pedidos de leitura/gravação. Os arquivos ffs*.log mostrarão mensagens como a seguinte:

Verifique se o membro SYS1.PARMLIB(BPXPRMxx) contém as seguintes instruções:

FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT)
NETWORK DOMAINNAME(AF_UNIX)
        DOMAINNUMBER(1)
        MAXSOCKETS(2000)
        TYPE(UDS)

Outra causa provável para esse problema, durante o uso de APPC para o serviço TSO Commands, é que o TCP/IP Resolver não pode resolver o endereço do host de modo adequado 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>)

Execute o IVP TCP/IP do fekfivpt, conforme descrito em Verificação de Instalação. A seção de configuração do resolvedor da saída será semelhante à seguinte amostra:

Resolver Trace Initialization Complete -> 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 no rsed.envvars, em que <arquivo resolvedor> ou <dados do resolvedor> representam o nome do arquivo resolvedor de IP:

RESOLVER_CONFIG=<arquivo resolvedor>

ou

RESOLVER_CONFIG='<conjunto de dados do resolvedor>'

Emulador de Conexão do Host

Considerações sobre Segurança

O Developer para 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 para System z dependem de que o sistema de arquivo em que eles residem seja seguro. 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:

Consulte o Entendimento do Developer para System z para saber sobre os conceitos básicos de design do Developer para System z.

Métodos de Autenticação

O Developer para System z suporta várias maneiras de autenticar um ID do usuário fornecido por um cliente an conexão.

Observe que os dados de autenticação fornecidos pelo cliente são usados somente uma vez durante a configuração da conexão inicial. Quando 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.

Observe que esse método de autenticação é suportado apenas pelo método de conexão do daemon RSE e que o SSL deve estar ativado.

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.

Segurança de Conexão

Diferentes níveis de segurança de comunicação são suportados pelo RSE, que controla toda a comunicação entre os serviços de cliente e do Developer para System z:

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 a conexão do cliente. 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, que é descrito em (Opcional) Usando REXEC (ou SSH).

Criptografia de Comunicação Usando SSL

Todos os fluxos de dados externos do Developer para System z que passam pelo RSE podem ser criptografados utilizando-se Secure Socket Layer (SSL). O uso de SSL é controlado pelas configurações no arquivo de configuração ssl.properties, conforme descrito em Comunicação Criptografada por SSL.

O Emulador de Conexão do Host no cliente se conecta a um servidor TN3270 no host. O uso de SSL é controlado pelo TN3270, conforme documentado em Communications Server IP Configuration Guide (SC31-8775).

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 para 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.

Portas TCP/IP

Figura 40. Portas TCP/IP
Portas TCP/IP

A Figura 40 mostra as portas TCP/IP que podem ser usadas pelo Developer para System z. As setas mostram a parte que faz a conexão (lado da ponta da seta) e o que 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:

Comunicação Interna

Vários serviços do host Developer para 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:

Nota:
Os clientes anteriores (versão 7.0 e anteriores) comunicam-se diretamente com o servidor JES Job Monitor, porta padrão 6715.

Portas CARMA e TCP/IP

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 um pedido de conexão, o extrator do CARMA, que fica ativo como um encadeamento de usuário em um conjunto de encadeamento RSE, encontrará uma porta livre em um intervalo especificado no arquivo de configuração CRASRV.properties e se conectará a ela. 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 pode enviar pedidos ao servidor e receber os resultados.

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

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 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.

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 o OMVSAPPL como ID do aplicativo porque ele abrirá uma chave secreta para a maioria dos aplicativos 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).

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 para 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 em rsed.envvars influenciam a função de auditoria, conforme documentado em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.

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.

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 para obter uma lista de mensagens do console geradas pelo RSE.

Dados 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 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.

Os arquivos de log de auditoria possuem a máscara de bit de permissão 640 (-rw-r-----), o que significa que o proprietário (uid do daemon RSE z/OS UNIX) possui acesso de leitura e gravação, e o grupo do proprietário (padrão) possui acesso de leitura. Todas as outras tentativas de acesso sã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 UNIXPRIV.

Segurança do JES

O Developer para 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 para 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 21. Comandos do Console do JES Job Monitor
Ações JES2 JES3
Suspen
der
$Hx(jobid)

with x = {J, S or T}

*F,J=jobid,H
Libera
ção
$Ax(jobid)

with x = {J, S or T}

*F,J=jobid,R
Cance
lar
$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 21 são limitados por padrão às tarefas que pertencem ao usuário. Isso pode ser alterado com a diretiva LIMIT_COMMANDS, conforme documentado em FEJJCNFG, Arquivo de Configuração do JES Job Monitor.

Tabela 22. 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 23. Perfis JESSPOOL Estendidos
Comando Perfil JESSPOOL Acesso Necessário
Suspen
der
nodeid.userid.jobname.jobid ALTER
Libe
ração
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, haverá um comportamento diferente para o valor LIMITED e NOLIMIT de LIMIT_COMMANDS, conforme descrito em Tabela 9. 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 de operador, como os outros comandos JES Job Monitor (Suspender, Liberar, Cancelar e Limpar), portanto, as limitações abaixo 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 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.

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.

Tabela 24. 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 por SSL

A comunicação externa (cliente-host) pode ser criptografada utilizando-se SSL (Secure Socket Layer). Esse recurso é desativado por padrão e é controlado pelas configurações em ssl.properties, conforme documentado em (Opcional) Criptografia SSL do RSE.

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 25. 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 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.

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 através de LINKLIST ou da diretiva STEPLIB em rsed.envvars.

O ID do usuário do RSE (STCRSE nos comandos de amostra abaixo) 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.

Consulte o Apêndice A. Configurando o SSL e a Autenticação X.509 para obter mais detalhes sobre como ativar o SSL para Developer para System z.

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 é passado adiante para 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 do RSE fará a autenticação.

Se bem-sucedido, o processo de autenticação determinará o ID de usuário a ser usado para esta sessão, que será, então, testado pelo daemon RSE para assegurar que seja útil no sistema host em que o daemon 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 para 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 Arquivo de Configuração do RSE rsed.envvars para obter informações sobre estas variáveis de amostra:

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 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 para System z, pois esses filtros mapeiam todos os certificados para um único ID de usuário. O resultado é que todos os seus usuários do Developer para System z efetuarão logon com o mesmo ID de 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 informações adicionais sobre certificados X.509, como são gerenciados pelo RACF e como definir filtros de nomes de certificados. 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

O Developer para System z pode realizar autenticação básica de certificado X.509 sem depender de 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 para 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:

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.

Segurança do CICSTS

O Developer para 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 Considerações sobre o 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 para 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.

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 para System z

Há vários arquivos de configuração do Developer para System z cujas diretivas afetam a configuração da segurança. 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.

RSE - rsed.envvars

Nota:
Detalhes sobre essas e outras diretivas rsed.envvars estão disponíveis em Arquivo de Configuração do RSE rsed.envvars.

RSE - ssl.properties

Nota:
Detalhes sobre essas e outras diretivas ssl.properties estão disponíveis em (Opcional) Criptografia SSL do RSE.

Definições de Segurança

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

FEKRACF está localizado 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 da Customização para obter mais detalhes.

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

Nota:

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

Requisitos e Lista de Verificação

Para concluir a configuração de segurança, o administrador de segurança precisa conhecer os valores listados na Tabela 26. Esses valores foram definidos durante as etapas anteriores da instalação e da customização do Developer para System z.

Tabela 26. Variáveis de configuração de segurança
Descrição
  • Valor Padrão
  • Onde encontrar a resposta
Valor
Qualificador de alto nível do produto Developer para System z
  • FEK
  • Instalação SMP/E
Qualificador de alto nível de customização do Developer para System z
Nome da tarefa iniciada do JES Job Monitor
Nome da tarefa iniciada do daemon RSE
Nome da tarefa iniciada do daemon de bloqueio
ID do aplicativo

A lista a seguir é uma visão geral das ações necessárias para concluir a configuração de segurança básica de Developer para System z. Conforme documentado nas seções abaixo, é possível usar diferentes métodos para preencher esses requisitos, dependendo do nível de segurança desejado. Consulte as seções anteriores para obter informações sobre a configuração de segurança de serviços opcionais do Developer para System z.

Ativar Configurações e Classes de Segurança

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

Definição de um Segmento OMVS para os Usuários do Developer para System z

Um segmento RACF OMVS (ou equivalente) que especifica um ID de usuário (UID), um diretório inicial e um comando shell z/OS UNIX válidos diferentes de zero, devem ser definidos para cada usuário do Developer para System z. Seus grupos padrão também requerem um segmento OMVS com um ID do grupo.

Substitua os seguintes marcadores #userid, #user-identifier, #group-name e #group-identifier dos comandos RACF de amostra por valores reais:

Embora isso não seja recomendado, você pode utilizar o segmento OMVS compartilhado definido no perfil BPX.DEFAULT.USER da classe FACILITY para atender aos requisito do segmento OMVS para Developer para System z.

Definir os Perfis do Conjunto de Dados

O acesso READ para usuários e ALTER para programadores de sistema é suficiente para a maioria dos conjuntos de dados do Developer para System z. Substitua o marcador #sysprog por IDs de usuário válidos ou nomes de grupos do RACF. Além disso, pergunte ao programador de sistema que instalou e configurou o produto os nomes corretos do conjunto de dados. 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:

Alguns dos componentes opcionais do Developer para 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 para System z e usuários a permissão READ para os seguintes conjuntos de dados:

Nota:
Quando você utiliza a Biblioteca Alternativa para o pacote do produto REXX, o nome da biblioteca de tempo de execução REXX padrão é REXX.*.SEAGALT. em vez de REXX.*.SEAGLPA, conforme usado na amostra acima.

Definir as Tarefas Iniciadas do Developer para System z

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

Notas:
  1. Assegure-se de que os IDs de usuário das tarefas iniciadas sejam protegidos especificando-se a palavra-chave NOPASSWORD.
  2. 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.
  3. O daemon RSE exige um tamanho de espaço de endereço grande (2GB) para operação adequada. Você deve definir esse valor na variável ASSIZEMAX do segmento OMVS para o ID do usuário STCRSE. Isso para garantir que o daemon RSE obterá o tamanho da região necessário, independentemente de alterações em MAXASSIZE em SYS1.PARMLIB(BPXPRMxx).
  4. 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. Isso garante que o RSE obterá o limite de encadeamento necessário, independentemente de alterações em MAXTHREADS ou MAXTHREADTASKS em SYS1.PARMLIB(BPXPRMxx). Consulte o Considerações de Ajuste para determinar o valor correto para o limite de encadeamento.
  5. 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.

Talvez você queira restringir o ID do usuário STCRSE. Os usuários com o atributo RESTRICTED não podem acessar recursos (MVS) protegidos que eles não estão especificamente autorizados a acessar.

ALTUSER STCRSE RESTRICTED

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

Atenção: Se você usar IDs de usuário restritos, deverá incluir explicitamente a permissão para acessar um recurso com os comandos PERMIT do TSO ou z/OS UNIX setfacl. Isso inclui recursos em que a documentação do Developer para System z usa UACC (como o perfil ** da classe PROGRAM) ou em que depende das convenções comuns do z/OS UNIX (como se todos tivessem permissão de leitura e execução para bibliotecas Java). Teste isto antes de ativá-lo em um sistema de produção.

Definir a Segurança de Comando do 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.

Os seguintes comandos de amostra RACF oferecem aos usuários do Developer para System z acesso condicional a um conjunto limitado de comandos JES (Suspender, 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:
Atenção: Definir os comandos JES com o acesso universal NONE no software de segurança pode afetar outros aplicativos e operações. Teste isto antes de ativá-lo em um sistema de produção.

A Tabela 27 e a Tabela 28 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 27. 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
Libe
ração
$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 28. 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
Libe
ração
*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:

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 os comandos JES por outros meios.

Definir o RSE como um Servidor z/OS UNIX Seguro

O RSE requer acesso UPDATE para o perfil BPX.SERVER para criar/excluir o ambiente de segurança do encadeamento do cliente. Se esse perfil não estiver definido, UID(0) será necessário para o RSE.

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. Isso pode afetar outros aplicativos e operações z/OS UNIX. Teste isto antes de ativá-lo em um sistema de produção. Consulte o UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre os diferentes níveis de segurança.

Definir Bibliotecas Controladas pelo Programa MVS para o RSE

Os servidores com autoridade para BPX.SERVER devem ser executados em um ambiente limpo controlado pelo programa. Isso implica que todos os programas chamados pelo RSE também devem ser controlados pelo programa. Para as bibliotecas de carregamento do MVS, o controle de programa é gerenciado pelo seu software de segurança.

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. Ele confunde e complica o caminho de procura usado pelo software de segurança. Nesse caso, você deve mesclar as definições * existentes com a ** nova. A IBM recomenda usar o perfil **, conforme documentado em Security Server RACF Security Administrator's Guide (SA22-7683).

As bibliotecas adicionais a seguir (pré-requisito) devem ser controladas pelo programa para suportar o uso de serviços opcionais. Essa lista não inclui conjuntos de dados que são específicos para um produto com o qual o Developer para System z interage, como a Ferramenta de Depuração IBM.

Nota:
As bibliotecas que são projetadas para colocação de LPA também requerem autorizações de controle de programa se forem acessadas através de LINKLIST ou STEPLIB. Esta publicação documenta o uso das seguintes bibliotecas LPA:

Definir Proteção de 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 com mais detalhes em Definir o Suporte PassTicket para o RSE, o RSE suporta o uso de um ID do aplicativo diferente de FEKAPPL. A definição de classe do APPL deve corresponder ao ID do aplicativo real usado pelo RSE.

Atenção: O pedido de conexão com o cliente falhará se o perfil do aplicativo não estiver definido ou quando o usuário não tiver acesso de LEITURA para o perfil.

Definir o Suporte PassTicket para o RSE

A senha do cliente,' (ou outro meio de identificação como um certificado X.509), somente é usada para verificar a sua identidade na conexão. Depois disso, os PassTickets são usados para manter a segurança do encadeamento.

PassTickets são senha geradas pelo sistema com uma duração de aproximadamente 10 minutos. Os PassTickets baseiam-se em uma chave secreta. Essa chave é um número de 64 bits (16 caracteres hexadecimais). Substitua nos comandos de amostra do RACF, a seguir, o marcador key16 por uma cadeia hexadecimal de 16 caracteres fornecida pelo usuário (caracteres de 0 a 9 e de A a F).

O RSE suporta o uso de um ID do aplicativo diferente de FEKAPPL. Remova o comentário e customize a opção "APPLID=FEKAPPL" no rsed.envvars para ativar isto, como documentado em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS. 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 é MVS seguido pelo ID do sistema SMF', porque isto abrirá a chave secreta para a maioria dos aplicativos MVS (incluindo as tarefas em lote).

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

Definir Arquivos Controlados pelo Programa z/OS UNIX para o RSE

Os servidores com autoridade para BPX.SERVER devem ser executados em um ambiente limpo controlado pelo programa. Isso implica que todos os programas chamados pelo RSE também devem ser controlados pelo programa. Para arquivos do z/OS UNIX, o controle do 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:

Verificar Configurações de Segurança

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

Entendimento do Developer para System z

O host do Developer para 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.

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

Visão Geral do Componente

Figura 41. Visão geral do componente
Visão geral do componente

A Figura 41 mostra uma visão geral generalizada do layout do Developer para 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 atua como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamento 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 42. RSE como um aplicativo Java
RSE como um aplicativo Java

A Figura 42 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 para 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 para 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 42, 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.

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.

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 43. donos das tarefas
Donos das tarefas

O Figura 43 mostra uma visão geral básica do dono das credenciais de segurança usadas por várias tarefas do Developer para 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.

O Figura 43 mostra as tarefas iniciadas do Developer para system z (LOCKD, JMON and RSED, as tarefas iniciadas de amostra e os serviços do sistema com os quais o Developer para System z se comunica. O Application Deployment Manager (ADM) é ativo dentro de uma região CICS. O FMNCAS é a tarefa iniciada do File Manager. 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. Estes espaços de endereço podem ser uma tarefa em lote MVS, uma transação APPC ou um processo-filho do z/OS UNIX. Note que um processo-filho do z/OS UNIX é ativo em um iniciador z/OS UNIX (BPXAS) e o processo-filho aparece como 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 File Manager iniciará um espaço de endereço novo para cada conjunto de dados (ou membro) que ele tenha que processar em nome do Developer para 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 43 permanecem no sistema tempo suficiente para serem visíveis. Porém, é recomendável estar ciente que, devido a maneira com que o z/OS UNIX é designado, há também vários espaços de endereços temporários de curta duração.

Fluxo de Conexão

Figura 44. Fluxo de conexão
Fluxo de conexão

A Figura 44 mostra uma visão geral esquemática de como um cliente se conecta ao host usando o Developer para System z. Ela explica também resumidamente 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 acima mostra o design orientado a encadeamentos 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. Dentro do conjunto de encadeamento, 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 (16 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á. Observe que 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.
  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 exigem autenticação permite que o Developer para System z invoque esses serviços à vontade, sem armazenar a senha ou solicitá-la constantemente 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.

Daemon de Bloqueio

Figura 45. Fluxo do daemon de bloqueio
Fluxo do daemon de bloqueio

O Figura 45 mostra uma visão geral esquemática de como um daemon de bloqueio determina qual o cliente do Developer para System z possui um bloqueio do conjunto de dados.

  1. O cliente efetua logon, que cria um encadeamento do servidor RSE específico do usuário (USER) dentro de um conjunto de encadeamento (RSEDx).
  2. O servidor RSE registra um usuário recém-conectado no daemon de bloqueio. As informações de registro contêm o Identificador de Espaço de Endereço (que é o ASID do conjunto de encadeamento), o identificador (específico do usuário) do Task Control Block (TCB) e o ID do usuário.
  3. O cliente abre um conjunto de dados na edição, que instrui o servidor RSE para obter um bloqueio exclusivo no conjunto de dados.
  4. O sistema registra o ASID, TCB e o nome da tarefa (RSEDx) do solicitante como parte do processo de bloqueio. Essas informações são armazenadas nas filas GRS (Global Resource Serialization).
  5. Um operador (ou servidor RSE em nome de um cliente) consulta o daemon de bloqueio do status de bloqueio do conjunto de dados.
  6. O daemon de bloqueio varre as filas GRS para aprender se o conjunto de dados está bloqueado.
  7. O daemon recupera o ASID, o TCB e o nome da tarefa do proprietário de bloqueio.
  8. O ASID e o TCB recuperado são comparados em relação às combinações ASID e TCB de clientes registrados.
  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 uma configuração de um único servidor de Developer para System z, em que vários usuários são designados a um único espaço de endereço do conjunto de encadeamento, o z/OS perdeu a capacidade de controlar quem possui um bloqueio em um conjunto de dados ou membro. Os comandos do sistema param no nível de espaço de endereço, que é o conjunto de encadeamento.

Para especificar esse problema, o Developer para System z fornece o daemon de bloqueio. O daemon de bloqueio pode controlar todos os bloqueios de conjuntos de dados/membros realizados pelos usuários do RSE, bem como os bloqueios realizados por outros produtos, como o ISPF.

O servidor RSE registra um usuário recém-conectado no daemon de bloqueio. As informações de registro contêm o Identificador de Espaço de Endereço (que é o ASID do conjunto de encadeamento), o ID (específico do usuário) do Task Control Block (TCB) e o ID do usuário.

Observe que o registro é feito apenas no momento da conexão, de modo que todos os usuários ativos do RSE antes de o daemon de bloqueio ser iniciado (ou reiniciado) não serão registrados.

Quando o daemon de bloqueio recebe uma consulta de conjunto de dados (por meio de um comando do operador de consulta de modificação ou do cliente por meio do servidor RSE), o daemon varre as filas Global Resource Serialization (GRS) do sistema. Se o ASID e o TCB corresponderem ao de um usuário registrado, o ID do usuário é retornado como um proprietário de bloqueio. Caso contrário, o nome da tarefa/ID do usuário relacionado ao ASID é retornado como proprietário de bloqueio.

Uma mensagem do console (FEK513W) com as informações de registro será exibida se o registro falhar. Isso permite que um operador corresponda os valores em relação à saída de um comando do operador DISPLAY GRS,RES=(*,dataset*) a fim de localizar o proprietário do bloqueio.

Nota:
Os registros bem-sucedidos também são listados no DD STDOUT do servidor se log_level estiver configurado para 2. Isso é útil para realizar o mapeamento manual para registros bem-sucedidos que foram removidos após um reinício do daemon de bloqueio.

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 operação cancelar modificação do RSE, conforme descrito no Comandos do Operador. Os bloqueios do conjunto de dados ativo que pertencem a esse usuário são liberados durante o processo.

Estrutura do Diretório z/OS UNIX

Figura 46. estrutura do diretório z/OS UNIX
Estrutura do diretório z/OS UNIX

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

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

Os dados em alguns diretórios, como /var/rdz/projects/, são mantidos por administradores que não são de sistema, como gerentes de projetos, que podem não ter muitos privilégios de atualização em z/OS UNIX. Se houver apenas um ID de usuário mantendo os arquivos, isso não será problema depois que o ID do usuário tiver se tornado proprietário do diretório e de tudo no diretório.

chown -R IBMUSER /var/rdz/projects/

Quando vários IDs de usuário precisarem de permissão de atualização no diretório, você poderá trabalhar com os bits de permissão do grupo.

  1. Crie um grupo em seu software de segurança que tenha um segmento OMVS válido e conecte todos os IDs do usuário que precisarem de acesso de atualização. Esse é preferivelmente seu grupo padrão.
    ADDGROUP RDZPROJ OMVS(GID(1200))
    CONNECT IBMUSER GROUP(RDZPROJ)
    ALTUSER IBMUSER DFLTGRP(RDZPROJ)
  2. Use o comando z/OS UNIX chgrp para designar o grupo ao diretório e a todos os arquivos contidos nele. Esse comando deve ser repetido sempre que um novo arquivo for incluído e o ID do grupo desejado não for o grupo padrão do ID do usuário que incluiu o arquivo.
    chgrp -R IBMUSER /var/rdz/projects/
  3. Use o comando z/OS UNIX chmod para conceder permissão de atualização ao grupo inteiro para o diretório e a todos os arquivos contidos nele.
    chmod -R 775 /var/rdz/projects/

Considerações WLM

Ao contrário dos aplicativos tradicionais z/OS, o Developer para System z não é um aplicativo monolítico que possa ser identificado facilmente para Workload Manager (WLM). O Developer para 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 Entendimento do Developer para 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 47. classificação WLM
classificação WLM

O Figura 47 mostra uma visão geral básica dos subsistemas por meio dos quais cargas de trabalho são apresentadas para WLMDeveloper para System z.

O Application Deployment Manager (ADM) é ativo dentro de uma região CICS e, por essa razão, seguirá as regras de classificação CICS no WLM.

O daemon RSE (RSED), daemon de bloqueio (LOCKD) e o JES Job Monitor (JMON) são Developer para System z tarefas iniciadas (ou tarefas em lote de longa execução), cada uma com seu 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 é ativo em um espaço de endereço separado (usando um inicializador 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 para System z algumas cargas de trabalho, como o o serviço TSO Commands (TSO cmd) ou CARMA, podem executar em subsistemas diferentes.

Os espaços de endereços listados em Figura 47 permanecem no sistema tempo suficiente para serem visíveis, mas é recomendável estar ciente que, devido a maneira como o z/OS UNIX é designado, 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 do) nome de tarefa para todos os espaços de endereços baseados em OMVS, estabelecidos pelo conjunto de encadeamentos.

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

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 29 lista os tipos de subsistema que podem receber cargas de trabalho Developer para System z.

Tabela 29. subsistemas de ponto de entrada 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.

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

Tabela 30. 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 para 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 para 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:

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

Tabela 31. cargas de trabalho WLM
Descrição Nome da tarefa Carga de trabalho
JES Job Monitor JMON STC
Daemon de bloqueio LOCKD 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
Construção do z/OS UNIX build (comandos do shell) <userid>x OMVS
Shell z/OS UNIX <userid> OMVS
Tarefa do File Manager <userid>x OMVS
Application Deployment Manager 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 para System z:

Quando usar os objetivos de tempo de resposta:

Quando usar objetivos de velocidade:

STC

Todas as tarefas iniciadas, daemon RSE, daemon de Bloqueio e JES Job Monitor do Developer para System z estão atendendo pedidos de clientes em tempo real.

Tabela 32. cargas de trabalho WLM STC
Descrição Nome da tarefa Carga de trabalho
JES Job Monitor JMON STC
Daemon de bloqueio LOCKD 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á o "x" na coluna "Nome da Tarefa" por um número aleatório de 1 dígito).

Tabela 33. 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
Construção do z/OS UNIX build (comandos do shell) <userid>x OMVS
Shell 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 para System z. O uso mais comum é para construções MVS, onde uma tarefa é submetida e monitorada para determinar quando ela termina. Mas o Developer para System z também poderia iniciar um servidor CARMA em lote e comunicar-se com ele usando TCP/IP.

Tabela 34. 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 para System z, o ISPF Client Gateway é usado para executar comandos TSO e ISPF não interativos. Devido a razões históricas, o Developer para System z também suporta executar estes comandos por meio de uma transação APPC.

Tabela 35. 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 do Developer para System z opcional ativo dentro de uma região do CICS Transaction Server.

Tabela 36. Cargas de trabalho WLM CICS
Descrição Nome da tarefa Carga de trabalho
Application Deployment Manager CICSTS CICS

O WLM suporta múltiplos tipos de gerenciamento que podem ser usado para CICS:

Considerações de Ajuste

Conforme explicado no Entendimento do Developer para System z, o RSE (Remote Systems Explorer) é o núcleo do Developer para System z. Para gerenciar as conexões e as cargas de trabalho 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 atua como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamento processam as cargas de trabalho do cliente.

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

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

Uso de Recursos

Use as informações desta seção para avaliar o uso normal e máximo de recursos pelo Developer para System z, para que você possa planejar a 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:

Visão Geral

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

A Tabela 37 fornece uma visão geral dos recursos principais usados pelas tarefas iniciadas do Developer para System z. Esses recursos são alocados apenas uma vez. Eles são compartilhados entre todos os clientes do Developer para System z.

Tabela 37. Uso de recursos comuns
Tarefa iniciada Espaços de endereço Processos Encadeamentos
JMON 1 1 3
LOCKD 1 3 10
RSED 1 3 11
RSEDx (a) 2 10
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.

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

Tabela 38. 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
File Manager 1 1 2

A Tabela 39 fornece uma visão geral dos recursos principais usados por cada cliente do Developer para 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 38.

Tabela 39. 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 - - - 16 1
Cronômetro para tempo limite inativo - - - 1 -
Expandir PDS(E) ISPF ISPF ISPF - -
Abrir conjunto de dados ISPF ISPF ISPF - -
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 - -
Integração do File Manager ISPF + FM ISPF + FM ISPF + FM - -
Integração do Analisador de Falha - - - - -
Nota:
O ISPF pode ser substituído pelo APPC, exceto para o SCLM Developer Toolkit.

Contagem do Espaço de Endereço

A Tabela 40 lista os espaços de endereço que são usados pelo Developer para System z, em que "u" na coluna "Contagem" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente que usam 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 40. Contagem do espaço de endereço
Contador Descrição Nome da tarefa Compar
tilhado
Termina após
1 JES Job Monitor JMON SIM Nunca
1 Daemon de bloqueio LOCKD SIM Nunca
1 Daemon RSE RSED 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) (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
(c) File Manager <userid>x Não Conclusão da tarefa

Nota:

Use a fórmula da Figura 48 para avaliar o número máximo de espaços de endereço usado pelo Developer para System z.

Figura 48. 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 da Figura 49 para avaliar o número máximo de espaços de endereço usados por um cliente do Developer para System z (sem contar os espaços de endereço temporários não documentados).

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

Em que,

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

Tabela 41. 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

A Tabela 42 lista o número de processos por espaço de endereço que é usado pelo Developer para System z. "u" nos "Espaços de Endereço" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função.

Tabela 42. Contagem de processos
Processos Espaços de endereço Descrição ID do usuário
1 1 JES Job Monitor STCJMON
3 1 Daemon de bloqueio STCLOCK
3 1 Daemon 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) <userid>
1 3u Build z/OS UNIX (comandos do shell) <userid>
1 1u Shell do z/OS UNIX <userid>
1 (c) File Manager <userid>
(5) (u) SCLM Developer Toolkit <userid>

Nota:

Use a fórmula da Figura 50 para avaliar o número máximo de processos usados pelo Developer para System z.

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

Em que,

Use a fórmula da Figura 51 para avaliar o número máximo de processos usados por um cliente do Developer para System z (sem contar os processos temporários não documentados).

Figura 51. Número de processos por cliente

Em que,

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

Tabela 43. 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

A Tabela 44 lista o número de encadeamentos usados pelas funções selecionadas do Developer para 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 44. Contagem de encadeamentos
              Encadeamentos
ID do usuário Descrição
RSEDx Ativado Autoinicia
lização
- 3 + 1u - STCJMON JES Job Monitor
- 10 2 STCLOCK Daemon de bloqueio
- 11 2 STCRSE Daemon RSE
10 (a) + 16u - 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)
- 1u (d) 2u <userid> Build z/OS UNIX (comandos do shell)
6u 1u - STCRSE e <userid> Shell do z/OS UNIX
- 2u (c) - <userid> File Manager
- (5) - <userid> SCLM Developer Toolkit
1u - - STCRSE Cronômetro para tempo limite inativo
Nota:

Use a fórmula da Figura 52 para avaliar o número máximo de encadeamentos usado por um conjunto de encadeamento do RSE. Use a fórmula da Figura 53 para avaliar o número máximo de encadeamentos usados pelo JES Job Monitor.

Figura 52. Número máximo de encadeamentos do conjunto de encadeamento do RSE
Número máximo de encadeamentos
Figura 53. 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 45 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 45. 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 do espaço de endereço e, portanto, o armazenamento disponível para blocos de controle relacionados ao encadeamento.
rsed.envvars Xmx Define o tamanho máximo do heap Java. Esse armazenamento é reservado e, portanto, não está mais disponível para blocos de controle relacionados ao 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 do cliente em um conjunto de encadeamento do 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.

Uso de Armazenamento

O RSE é um aplicativo Java, que implica que o planejamento de uso de armazenamento (memória) do Developer para System z deve levar dois limites de alocação de armazenamento em consideração, o tamanho de heap Java e o tamanho do 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.

O tamanho de heap máximo Java é definido em rsed.envvars com a diretiva Xmx. Se essa diretiva não for especificada, Java usará um tamanho padrão de 64 MB.

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.

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 para 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:

Análise do Uso de Armazenamento de Amostra

As telas nas figuras a seguir mostram alguns números de amostra do uso de recursos para uma configuração padrão do Developer para System z com uma modificação. O tamanho máximo de heap Java é definido como 10 MB, uma vez que um máximo pequeno resultará em um uso percentil maior e os limites do tamanho de heap serão atingidos com mais rapidez.

Figura 54. 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
 LOCKD             1,60     28,7 M        14183
 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
 LOCKD             1,64     28,8 M        14259
 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
 LOCKD             1,66     28,9 M        14268
 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
 LOCKD             1,67     29,0 M        14277
 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
 LOCKD             1,68     29,0 M        14286
 RSED              4,61     32,9 M        16125
 RSED8             4,77     62,3 M        27404
Figura 55. 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
 LOCKD             1,69     29,1 M        14295
 RSED              4,64     32,9 M        16229
 RSED8             4,78     62,4 M        27413
 RSED9             4,60     56,6 M        24065

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

Figura 56. 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
 LOCKD             1,73     30,5 M        14179
 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
 LOCKD             1,76     30,6 M        14255
 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
 LOCKD             1,78     30,6 M        14255
 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
 LOCKD             1,78     30,6 M        14255
 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 56 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 para System z, que não são gravados em uma instrução DD, termina 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 no Resolução de Problemas de Configuração, o Developer for System z grava os logs do host relacionados ao RSE nos seguintes diretórios do 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 57. 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 57 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 para obter uma lista de mensagens do console geradas pelo RSE.

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

Tabela 46. 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 modificar rsecommlog <level> Altera dinamicamente o nível de detalhes do log de rsecomm.log
Comando do operador modificar rsedaemonlog <level> Altera dinamicamente o nível de detalhes do log de rsedaemon.log
Comando do operador modificar 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.

O Developer para System z, junto com o software obrigatório, como o ISPF Client Gateway, grava também dados temporários em /tmp e em /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 para System z sempre tenta limpar esses arquivos temporários, mas a limpeza manual, conforme documentada em (Opcional) Limpeza de WORKAREA, pode ser executada a qualquer momento virtualmente.

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 fornecido com o Developer para System z destina-se a instalações de tamanho médio e pequeno que não exigem os componentes opcionais do Developer para System z. Arquivo de Configuração do RSE rsed.envvars descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis precisam de atenção especial:

_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx256m"
Defina o tamanho de heap inicial (Xms) e máximo (Xmx). Os padrões são 128M e 256M, respectivamente. Altere para aplicar os valores de tamanho de heap desejados. Se esta diretiva for comentada a linha, os valores padrão do Java serão usados, que são 4M e 512M, respectivamente (1M e 64M para Java 5.0).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=60"
Quantidade máxima de clientes atendidos por um conjunto de encadeamentos. O padrão é 60. 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=1000"
Valor máximo dos encadeamentos ativos em um conjunto de encadeamentos para permitir clientes novos. O padrão é 1000. 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. Observe que cada conexão do cliente utiliza vários encadeamentos (16 ou mais) e que outros limites podem impedir 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=10"
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.
#_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 para 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 16 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 deve ficar abaixo da linha 16 MB.
  • Cada cliente usa pelo menos 16 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).

Definições de Vários Recursos

Placa EXEC na JCL do Servidor

Recomenda-se que as definições a seguir sejam incluídas na placa JCL dos servidores Developer para 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
Recomenda-se que TIME=NOLIMIT seja usado para todos os servidores Developer para System z. Isso porque o tempo de CPU de todos os clientes do Developer para System z se 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 para System z destina-se a instalações de porte médio e pequeno. FEJJCNFG, Arquivo de Configuração do JES Job Monitor descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis exigem 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 seguintes diretivas são conhecidas por impactar o Developer para 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 a 32767. Observe que
a soma dos
           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 para 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)

O membro parmlib ASCHPMxx contém informações de planejamento para o planejador de transações ASCH e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer para 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 para 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 para 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 para 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 z/OS UNIX

A maioria dos limites z/OS UNIX que é do interesse do Developer para 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 que se conectam ao host, não apenas o Developer para System z, mas também sua infraestrutura de rede deve ser capaz de tratar a carga de trabalho. O gerenciamento de rede é um assunto amplo e bem documentado que fica fora do escopo da documentação do Developer para System z. Portanto, apenas os seguintes ponteiros são fornecidos.

Monitorando Sistemas de Arquivos z/OS UNIX

O Developer para System z usa sistemas de arquivos z/OS UNIX para armazenar vários tipos de dados, como arquivos de log 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.FEK.HHOP760) 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 para System z tenta incluir 60 usuários em um único conjunto de encadeamento. Entretanto, nossos requisitos indicam que o tempo limite de inatividade estará ativo. A Tabela 44 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 60 usuários em um único conjunto de encadeamento, uma vez que 60*(16+1)=1020 e maximum.threads é definido como 1000, por padrão.

Poderíamos aumentar maximum.threads, mas devido ao requisito ter uma média de 5 MB de heap Java por usuário, optamos por diminuir o maximum.clients para 50. Isso nos mantém dentro do tamanho máximo padrão de heap Java de 256 MB (5*50 = 250).

Com 50 clientes por conjunto de encadeamentos e a necessidade de suportar 500 conexões, sabemos agora que precisaremos de 10 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 como documentado em Definindo Limites, é possível iniciar a monitoração do uso dos recursos pelo Developer para System z para verificar se é necessário o ajuste de algumas variáveis. O Figura 58 mostra o uso dos recursos após 495 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 58. Uso do recurso de configuração de amostra
BPXM023I (STCRSE)
 ProcessId(16779764) Memory Usage(10%) Clients(50) Order(1)
 ProcessId(67108892) Memory Usage(16%) Clients(50) Order(2)
 ProcessId(67108908) Memory Usage(10%) Clients(50) Order(3)
 ProcessId(67108898) Memory Usage(16%) Clients(50) Order(4)
 ProcessId(67108916) Memory Usage(16%) Clients(50) Order(5)
 ProcessId(67108897) Memory Usage(16%) Clients(50) Order(6)
 ProcessId(67108921) Memory Usage(16%) Clients(50) Order(7)
 ProcessId(83886146) Memory Usage(16%) Clients(50) Order(8)
 ProcessId(67108920) Memory Usage(16%) Clients(50) Order(9)
 ProcessId(3622    ) Memory Usage(8%) Clients(45) Order(10)

 Nome Tarefa Tempo de CPU  Armazen.     EXCP
 --------   -----------    -------  ----------
 JMON              1.74     43.0M         2753
 LOCKD            10.05     31.9M        24621
 RSED              6.65     40.1M        41780
 RSED1             8.17    187.0M        76566
 RSED2            13.04    184.9M        78946
 RSED3            17.77    181.1M        76347
 RSED4            11.63    174.9M        74638
 RSED5            15.27    172.9M        72883
 RSED6            13.85    180.8M        75031
 RSED7             9.79    174.3M        76636
 RSED8            21.59    176.1M        70583
 RSED8            18.88    184.7M        76953
 RSED9             9.52    189.8M        80490

Considerações de 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 para 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 para System z possui um padrão de arquivo de configuração STEPLIB=NONE codificado em rsed.envvars, conforme descrito em rsed.envvars. Pelos motivos mencionados acima, é aconselhável não alterar essa diretiva e colocar 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 do Ambiente de Linguagem (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 do Aplicativo

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 acima são amostras de possíveis candidatas 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 para System z pode ser equilibrado pela configuração das metas corretas para os processos. Algumas diretrizes gerais são listadas abaixo:

Consulte MVS Planning Workload Management (SA22-7602) para obter informações adicionais sobre este 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.

Por padrão, o tamanho de heap inicial de uma z/OS Java Virtual Machine (JVM) é 1 megabyte. O tamanho máximo é de 64 megabytes. Os limites podem ser configurados com as opções da linha de comandos -Xms (inicial) e -Xmx (máximo) Java.

No Developer para System z, as opções da linha de comandos Java são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars, conforme descrito em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.

#_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. Esse método é documentado em (Opcional) Usando REXEC (ou SSH).

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.

-Xquickstart é apropriada para aplicativos de curta execução, principalmente aqueles em que o tempo de execução não está concentrado em um número menor 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. Três delas são apresentadas na amostra abaixo ($ é 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:

Considerações sobre o 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:

O Developer para System z aborda esses problemas permitindo que administradores do CICS controlem os 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 faz 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) Application Deployment Manager para obter informações adicionais sobre as tarefas necessárias para configurar o Application Deployment Manager no sistema host.

Customizar o Application Deployment Manager inclui os seguintes serviços no Developer para System z:

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

Consulte o Centro de Informações do Developer para System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para saber mais sobre os serviços disponíveis do Application Deployment Manager no release atual do Developer para System z.

RESTful versus Serviços da Web

O CICS Transaction Server fornece na versão 4.1 e superior suporte para uma interface HTTP projetada usando os 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 para System versão 7.6 ou superior.

As interfaces RESTful e de Serviço da Web podem ser ativadas simultaneamente em uma única região do 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. Essa região é conhecida pelo Application Deployment Manager 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 do 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 CICSPlex SM Business Application Services (BAS) for usado para gerenciar suas definições de recursos do CICS, então a diretiva CICSPlex SM EYUPARM BASLOGMSG deve ser configurada como (YES) para que os logs sejam criados.

segurança do Application Deployment Manager

Segurança do 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. Consulte Definir os Perfis do Conjunto 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 seqüê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 para 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 o (Opcional) Application Deployment Manager para obter informações adicionais sobre a customização de IDs da transação.

Transação Descrição
ADMS Para pedidos 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 os logs do CICS para obter mensagens como a seguir, e executar ações corretivas, conforme documentado no 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 para System z fornece o administrative utility 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 da Customização 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:

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 para 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 para 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 para System z.

Consulte a seguinte amostra de código ADNJSPAU.

Figura 59. 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()
*
* 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)
*
* 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 para 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 para 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:

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 sucesso na linha <número da última linha de 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 última linha de 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 o 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 desconhecido 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 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 da palavra-chave inválido para a 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 VSAM> FC=<código de função VSAM> FB=<código de feedback 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 de leitura de 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.

Customizando o Ambiente TSO

Este apêndice é fornecido para ajudá-lo a imitar um procedimento de logon do TSO incluindo instruções DD e conjuntos de dados no ambiente TSO no Developer para System z.

O Serviço TSO Commands

O serviço TSO Commands é o componente Developer para 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 para 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 para 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 para System z, será necessário para executá-los.

Métodos de Acesso

A partir da versão 7.1, o Developer para System z fornece uma opção para acessar o serviço TSO Commands.

Nota:
O serviço TSO/ISPF Client Gateway do ISPF substitui a função do SCLM Developer Toolkit usada na versão 7.1.

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

Customização Básica - 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 para System z. Existe apenas um arquivo de configuração ISPF.conf ativo, que é usado por todos os usuários do Developer para 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

Avançado - 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_CMDSERV_OPTS no rsed.envvars.

#_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_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:

Avançado - 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 = FEK.#CUST.CNTL(CRAISPRX)

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).

Avançado - Usar Vários 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:

Avançado - Vários Arquivos ISPF.conf com várias Configurações do Developer para System z

Se os cenários do exec de alocação descritos acima não puderem tratar de suas necessidades específicas, você poderá criar diferentes instâncias do servidor de comunicação RSE do Developer para System z, cada uma utilizando seu próprio arquivo ISPF.conf. A desvantagem principal do método descrito a seguir é que os usuários do Developer para 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: _CMDSERV_CONF_HOME=/etc/rdz/tso2
      -> uncomment and change: -Ddaemon.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 para System z que exigem alterações no diretório tso2 recém-criado. A variável _CMDSERV_CONF_HOME em rsed.envvars deve ser atualizada para definir um novo diretório inicial ISPF.conf e o daemon.log deve ser atualizado para definir um novo local de log (que é criado automaticamente se ele 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 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 _CMDSERV_WORK_HOME em rsed.envvars) pode ser compartilhada entre as duas 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.

Consulte as seções relacionadas nesta publicação para obter informações adicionais sobre as ações mostradas acima.

Usando o Método de Acesso do APPC

Customização Básica - JCL de Transação APPC

A definição de uma transação APPC consiste em parâmetros APPC e um JCL de transação. A JCL de amostra para criar uma transação APPC do Developer para System z, FEK.#CUST.JCL(FEKAPPCC), contém duas opções para definir a JCL da transação, com e sem suporte ISPF.

//SYSIN    DD DDNAME=SYSINISP          * use SYSINTSO or SYSINISP

O cliente obtém o ambiente TSO/ISPF definido na JCL de transação, portanto, customizando esta seção seguindo regras DD regulares, você pode customizar o ambiente para o cliente.

...
//CMDSERV  EXEC PGM=IKJEFT01,DYNAMNBR=50,
//  PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//SYSPROC  DD DISP=SHR,DSN=FEK.SFEKPROC
//ISPPLIB  DD DISP=SHR,DSN=ISP.SISPPENU
//ISPMLIB  DD DISP=SHR,DSN=ISP.SISPMENU
//ISPTLIB  DD DISP=SHR,DSN=ISP.SISPTENU
//ISPSLIB  DD DISP=SHR,DSN=ISP.SISPSENU
//ISPPROF  DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//            SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD DUMMY
//MYDD     DD DISP=SHR,DSN=HLQ1.LLQ1
//            DISP=SHR,DSN=HLQ2.LLQ2
Nota:
Uma transação APPC existente pode ser modificada utilizando painéis ISPF APPC.

Avançado - Usar Perfis do ISPF Existentes

Se o suporte do ISPF for selecionado, o Developer para System z criará por padrão um perfil temporário do ISPF para o serviço TSO Commands. Entretanto, você pode instruir o Developer para System z a utilizar uma cópia de um perfil existente do ISPF. Conforme descrito na tarefa de amostra FEK.SFEKSAMP(FEKAPPCC), você deve fazer o seguinte:

...
//COPY     EXEC PGM=IEBCOPY   * (optional) clone existing ISPF profile
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DISP=SHR,DSN=&SYSUID..ISPROF//SYSUT2   DD DISP=(MOD,PASS),DSN=&&PROF,
//            UNIT=SYSALLDA,
//            LIKE=&SYSUID..ISPROF
//*
//CMDSERV  EXEC PGM=IKJEFT01,DYNAMNBR=50,
//  PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//*ISPPROF  DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//*            SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//ISPPROF  DD DISP=(OLD,DELETE,DELETE),DSN=&&PROF
Nota:
Se for usado um nome de conjunto de dados inválido, a inicialização da transação APPC (e, portanto, o serviço TSO Commands) falhará.

Avançado - Usando um Exec de Alocação

A transação da amostra JCL chama o serviço do TSO Commands diretamente ao passar seu nome (FEKFRSRV) como parâmetro para programar IKJEFT01. É possível alterar isto para chamar um outro executável. Este executável pode fazer alocações baseadas no ID do usuário atual e, em seguida, chamar o serviço do TSO Commands.

Ao contrário do método de acesso do TSO/ISPF Client Gateway, as variáveis armazenadas no perfil do ISPF do usuário podem ser usadas por esse exec para ajudá-lo a customizar o ambiente. Mas lembre-se de que as atualizações no perfil serão perdidas no final da sessão, pois você está utilizando uma cópia temporária, não o perfil real.

Observe, no entanto, que o uso de um exec de alocação na transação APPC não é suportado e a descrição acima está no estado em que se encontra.

Avançado - Várias Transações APPC com Várias Configurações do Developer para System z

Se for necessário vários ambientes TSO exclusivos, você pode criar instâncias diferentes do servidor de comunicação RSE do Developer para System z', cada uma utilizando sua própria transação APPC. A desvantagem principal do método descrito a seguir é que os usuários do Developer para 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
$ ls /etc/rdz/tso2/
rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
      -> uncomment and change: _FEKFSCMD_TP_NAME_=FEKFTSO2
      -> uncomment and change: -Ddaemon.log=/var/rdz/logs/tso2
      -> add at the END:
         # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
         CFG_BASE=/etc/rdz
         CLASSPATH=.:$CFG_BASE:$CLASSPATH 
         # -- 

Os comandos acima criam um novo diretório tso2 e copiam os arquivos de configuração do Developer para System z que precisam de mudanças para o novo local. A variável _FEKFSCMD_TP_NAME_ em rsed.envvars deve ser atualizada para definir o novo nome da transação APPC, e o daemon.log deve ser atualizado para definir um novo local de log do daemon (que é criado automaticamente se ele 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 tso2.

Figura 60. FEKAPPCC - criar uma segunda transação APPC
//FEKAPPCC JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=&SYSUID
//*
//TPADD    EXEC PGM=ATBSDFMU
//SYSSDLIB DD DISP=SHR,DSN=SYS1.APPCTP
//SYSSDOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN    DD DDNAME=SYSINISP          * use SYSINTSO or SYSINISP
//SYSINISP DD DATA,DLM='QT'
     TPADD
       TPNAME(FEKFTSO2)
       ACTIVE(YES)
       TPSCHED_DELIMITER(DLM1)
       KEEP_MESSAGE_LOG(ERROR)
       MESSAGE_DATA_SET(&SYSUID..FEKFTSO2.&TPDATE..&TPTIME..LOG)
       DATASET_STATUS(MOD)
       CLASS(A)
       JCL_DELIMITER(DLM2)
//FEKFTSO2 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
//*
//CMDSERV  EXEC PGM=IKJEFT01,DYNAMNBR=50,
//  PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//SYSPROC  DD DISP=SHR,DSN=FEK.SFEKPROC
//ISPPLIB  DD DISP=SHR,DSN=ISP.SISPPENU
//ISPMLIB  DD DISP=SHR,DSN=ISP.SISPMENU
//ISPTLIB  DD DISP=SHR,DSN=ISP.SISPTENU
//ISPSLIB  DD DISP=SHR,DSN=ISP.SISPSENU
//ISPPROF  DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//            SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD DUMMY
//MYDD     DD DISP=SHR,DSN=HLQ1.LLQ1
//            DISP=SHR,DSN=HLQ2.LLQ2
DLM2
DLM1
QT

Em seguida, crie uma nova transação APPC customizando e enviando a tarefa de amostra FEK.#CUST.JCL(FEKAPPCC), conforme exibido na amostra acima. Além da customização normal (descrita na JCL), você também deve alterar o TPNAME para TPNAME(FEKFTSO2) para corresponder à definição _FEKFSCMD_TP_NAME_ no novo rsed.envvars. Você deve alterar também o nome na variável MESSAGE_DATA_SET e o nome do JOB da JCL da transação.

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.

Consulte as seções relacionadas nesta publicação para obter informações adicionais sobre as ações mostradas acima.

Executando Várias Instâncias

Há situações em que você deseja várias instâncias do Developer para 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 para 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 para 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 para 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:

Configuração Idêntica em um Sysplex

Os arquivos de configuração do Developer para System z (e código) podem ser compartilhados através de sistemas diferentes em um sysplex, com cada sistema executando a sua própria cópia idêntica do Developer para System z, se algumas recomendações forem obedecidas.

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 para 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 SSL mencionada acima, 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
      -> uncomment and change: -Ddaemon.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 acima copiam os arquivos de configuração do Developer para System z que exigem alterações para um diretório ssl recém-criado. A variável daemon.log em rsed.envvars deve ser atualizada para definir um novo local de log (que é criado automaticamente se ele 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 nesta publicação para obter informações adicionais sobre as ações mostradas acima.

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 para 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 para System z:

Uma visão geral mais detalhada é listada a seguir:

Guia de Migração

Considerações de Migração

Esta seção destaca as alterações na instalação e na configuração em comparação a releases anteriores do produto. Também fornece algumas diretrizes gerais para migrar para este release. Consulte as seções relacionadas neste manual para obter informações adicionais.

Nota:
As informações de migração listadas aqui são para as versões do Developer para System z ainda suportadas na hora da publicação.

Fazendo Backup de Arquivos Configurados Anteriormente

Se você for um usuário anterior do Developer para System z, recomenda-se salvar os arquivos customizados relacionados antes de instalar esta versão do IBM Developer para System z.

Os arquivos customizáveis do Developer para system z podem ser localizados nos seguintes locais:

As configurações anteriores do Developer para system z também documentam as mudanças nos arquivos de configuração pertencentes por outros produtos.

Notas de Migração da Versão 7.6.1

As seguintes notas de migração são específicas para a versão 7.6.1. Elas são válidas para migração a partir da versão 7.6 ou são adições às notas de migração da versão existente 7.6.

Migrar da Versão 7.5 para a Versão 7.6

IBM Rational Developer para System z, FMID HHOP760

Arquivos Configuráveis

A Tabela 47 fornece uma visão geral de arquivos que foram customizados na versão 7.6. Observe que as bibliotecas de amostra do Developer para System z, FEK.SFEKSAMP, FEK.SFEKSAMV e /usr/lpp/rdz/samples/, são fornecidas com mais membros customizáveis que os listados aqui, como o código de origem de amostra do CARMA e as tarefas para compilá-las.

Nota:
A tarefa de amostra FEKSETUP copia todos os membros listados em conjuntos de dados e diretórios diferentes, padrão FEK.#CUST.* e /etc/rdz/*.
Tabela 47. Customizações da Versão 7.6
Membro/Arquivo Local padrão Propósito Notas de migração
FEKSETUP
FEK.SFEKSAMP
[FEK.#CUST.JCL]
JCL para criar conjuntos de dados e diretórios e preenchê-los com arquivos customizáveis Atualizado para incluir novos membros customizáveis
JMON
FEK.SFEKSAMP(FEJJJCL)
[FEK.#CUST.PROCLIB]
JCL para JES Job Monitor Opção incluída para alterar opções LE
FEJJJCL
FEK.SFEKSAMP
[FEK.#CUST.PROCLIB(JMON)]
Nome de remessa para o membro de JMON Consulte o membro de JMON
RSED
FEK.SFEKSAMP(FEKRSED)
[FEK.#CUST.PROCLIB]

JCL para daemon RSE none
FEKRSED
FEK.SFEKSAMP
[FEK.#CUST.PROCLIB(RSED)]

Nome de remessa para membro de RSED Consulte o membro de RSED
LOCKD
FEK.SFEKSAMP(FEKLOCKD)
[FEK.#CUST.PROCLIB]

JCL para daemon de bloqueio NOVO, customização é necessária
FEKLOCKD
FEK.SFEKSAMP
[FEK.#CUST.PROCLIB(LOCKD)]

Nome de remessa para o membro LOCKD Consulte o membro LOCKD
ELAXF*
FEK.SFEKSAMP
[FEK.#CUST.PROCLIB]

JCL para construções de projetos remotos, etc. none
FEKRACF
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para definições de segurança Atualizações menores
FEJJCNFG
FEK.SFEKSAMP
[FEK.#CUST.PARMLIB]

Arquivo de configuração do JES Job Monitor Novas diretivas opcionais foram incluídas
FEJTSO
FEK.SFEKSAMP
[FEK.#CUST.CNTL]

JCL para emissões TSO none
CRA$VMSG
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criação do VSAM de mensagens do CARMA none
CRA$VDEF
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criação do VSAM de configuração do CARMA none
CRA$VSTR
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criação do VSAM de informações customizadas do CARMA none
CRASUBMT
FEK.SFEKSAMP
[FEK.#CUST.CNTL]

CLIST de inicialização em lote do CARMA none
CRASUBCA
FEK.SFEKSAMP
[FEK.#CUST.CNTL]

CLIST de inicialização em lote do CARMA para CA Endevor® SCM RAM NOVO, customização é opcional
CRASHOW
FEK.SFEKSAMP
[FEK.#CUST.PARMLIB]

Configuração do CARMA para CA Endevor® SCM RAM NOVO, customização é opcional
CRATMAP
FEK.SFEKSAMP
[FEK.#CUST.PARMLIB]

Configuração do CARMA para CA Endevor® SCM RAM NOVO, customização é opcional
CRANDVRA FEK.SFEKPROC REXX de alocação do CARMA para CA Endevor® SCM RAM NOVO, customização é opcional
CRAISPRX
FEK.SFEKSAMP
[FEK.#CUST.CNTL]

Exec de alocação de DD de amostra para CARMA utilizando TSO/ISPF Client Gateway none
CRA#VSLM
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criar VSAM de mensagem do SCLM RAM none
CRA#ASLM
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criar conjuntos de dados do SCLM RAM none
CRA#VPDS
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criar VSAM de mensagem do PDS RAM none
CRA#CRAM
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para compilar RAM da estrutura none
CRA#VCAD
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para a criação do VSAM de configuração do CARMA VSAM para CA Endevor® SCM RAM NOVO, customização é opcional
CRA#VCAS
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para a criação do VSAM de informações customizadas do CARMA para CA Endevor® SCM RAM NOVO, customização é opcional
CRA#UADD
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para mesclagem de definições da RAM NOVO, customização é opcional
CRA#UQRY
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para extração de definições da RAM NOVO, customização é opcional
CRAXJCL
FEK.SFEKSAMP
[FEK.#CUST.ASM]

Código de origem de amostra para substituição de IRXJCL none
CRA#CIRX
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para compilar CRAXJCL none
ADNCSDRS
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para definir o servidor CRD RESTful como a região primária do CICS NOVO, customização é opcional
ADNCSDTX
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para definir os IDs de transação alternativa como a região do CICS NOVO, customização é opcional
ADNTXNC
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criação de IDs de transação alternativa NOVO, customização é opcional
ADNMSGHC
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para compilar ADNMSGHS Renomeado, era ADNCMSGH
ADNMSGHS
FEK.SFEKSAMP
[FEK.#CUST.COBOL]

Código de origem de amostra para o Manipulador de Mensagem de Pipeline Renomeado, era ADNSMSGH
ADNVCRD
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criar o repositório do CRD Renomeado, era ADNVSAM
ADNCSDWS
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para definir o servidor CRD de Serviço da Web como a região primária do CICS Renomeado, era ADNPCCSD
ADNCSDAR
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para definir o servidor CRD para regiões não-primárias do CICS Renomeado, era ADNARCSD
ADNJSPAU
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para atualizar os padrões do CRD Foram incluídas definições para o serviço RESTful, é necessário refazer as customizações
ADNVMFST
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criar e definir o repositório do Manifesto Renomeado, era ADNMFEST
ELAXMSAM
FEK.SFEKSAMP
[FEK.#CUST.PROCLIB]

Procedimento JCL do espaço de endereços WLM para o Stored Procedure Builder para PL/I e COBOL none
ELAXMJCL
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para definir Stored Procedure Builder para PL/I e COBOL para o DB2 none
FEKAPPCC
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para criação de uma transação APPC none
FEKAPPCL
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para exibição de uma transação APPC none
FEKAPPCX
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para exclusão de uma transação APPC none
FEKLOGS
FEK.SFEKSAMP
[FEK.#CUST.JCL]

JCL para coletar arquivos de log NOVO, customização é opcional
rsed.envvars
/usr/lpp/rdz/samples/
[/etc/rdz/]

Variáveis de ambiente do RSE Cópias mais antigas devem ser substituídas por esta (as customizações devem ser refeitas).
ISPF.conf
/usr/lpp/rdz/samples/
[/etc/rdz/]

arquivo de configuração do TSO/ISPF Client Gateway ISP.SISPCLIB incluído em SYSPROC para SCLMDT
CRASRV.properties
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração CARMA none
crastart.conf
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração do CARMA para uso de CRASTART none
crastart.endevor.conf
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração do CARMA para uso do CRASTART para CA Endevor® SCM RAM NOVO, customização é opcional
ssl.properties
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração SSL RSE Novas diretivas opcionais foram incluídas
rsecomm.properties
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração de rastreio RSE none
propertiescfg.properties
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração de grupos de propriedades baseados em host none
projectcfg.properties
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração de projetos baseados em host none
FMIEXT.properties
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração de Integração do File Manager Cópias mais antigas devem ser substituídas por esta (as customizações devem ser refeitas).
uchars.settings
/usr/lpp/rdz/samples/
[/etc/rdz/]

Arquivo de configuração de caracteres não editáveis none

Migrar da Versão 7.1 para a Versão 7.5

IBM Rational Developer para System z, FMID HHOP750

Arquivos Configuráveis

A Tabela 48 fornece uma visão geral de arquivos que foram customizados na versão 7.5. Observe que as bibliotecas de amostra do Developer para System z, FEK.SFEKSAMP, FEK.SFEKSAMV e /usr/lpp/rdz/samples/, são fornecidas com mais membros customizáveis que os listados aqui, como o código de origem do CARMA de amostra e as tarefas para compilá-las.

Nota:
A tarefa de amostra FEKSETUP copia todos os membros listados em conjuntos de dados e diretórios diferentes, padrão FEK.#CUST.* e /etc/rdz/*.
Tabela 48. Customizações da Versão 7.5
Membro/Arquivo Local padrão Propósito Notas de migração
FEKSETUP FEK.SFEKSAMP

[FEK.#CUST.JCL]

JCL para criar conjuntos de dados e diretórios e preenchê-los com arquivos customizáveis NOVO, customização é necessária
JMON FEK.SFEKSAMP(FEJJJCL)

[FEK.#CUST.PROCLIB]

JCL para JES Job Monitor STEPLIB alterado para SFEKAUTH
RSED FEK.SFEKSAMP(FEKRSED)

[FEK.#CUST.PROCLIB]

JCL para daemon RSE NOVO, customização é necessária
ELAXF* FEK.SFEKSAMP

[FEK.#CUST.PROCLIB]

JCL para construções de projetos remotos, etc. ELAXFTSO, ELAXFCP1 e ELAXFPP1 são novos
FEKRACF FEK.SFEKSAMP

[FEK.#CUST.JCL]

JCL para definições de segurança NOVO, necessário
FEJJCNFG FEK.SFEKSAMP

[FEK.#CUST.PARMLIB]

Arquivo de configuração do JES Job Monitor
  • Algumas diretivas se tornaram opcionais
  • Novas diretivas opcionais foram incluídas
FEJTSO FEK.SFEKSAMP

[FEK.#CUST.CNTL]

JCL para emissões TSO O nome da tarefa agora pode ser uma variável
CRAISPRX FEK.SFEKSAMP

[FEK.#CUST.CNTL]

Exec de alocação de DD de amostra para CARMA utilizando TSO/ISPF Client Gateway NOVO, customização é opcional
CRAXJCL FEK.SFEKSAMP

[FEK.#CUST.ASM]

Código de origem de amostra para substituição de IRXJCL NOVO, customização é opcional
CRA#CIRX FEK.SFEKSAMP

[FEK.#CUST.JCL]

JCL para compilar CRAXJCL NOVO, customização é opcional
ADNSMSGH FEK.SFEKSAMP

[FEK.#CUST.COBOL]

Código de origem de amostra para o Manipulador de Mensagem de Pipeline As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas)
ADNPCCSD FEK.SFEKSAMP

[FEK.#CUST.JCL]

JCL para definir o servidor CRD para a região primária do CICS As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas)
ADNJSPAU FEK.SFEKSAMP

[FEK.#CUST.JCL]

JCL para atualizar os padrões do CRD NOVO, customização é opcional
ADNMFEST FEK.SFEKSAMP

[FEK.#CUST.JCL]

JCL para criar e definir o repositório do Manifesto NOVO, customização é opcional
rsed.envvars /usr/lpp/rdz/samples/

[/etc/rdz/]

Variáveis de ambiente do RSE As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas)
ISPF.conf /usr/lpp/rdz/samples/

[/etc/rdz/]

arquivo de configuração do TSO/ISPF Client Gateway Idêntico ao ISPF.conf fornecido com SCLMDT na v7.1
CRASRV.properties /usr/lpp/rdz/samples/

[/etc/rdz/]

Arquivo de configuração CARMA
  • Local e nome do script de inicialização alterados
  • Novas diretivas opcionais foram incluídas
crastart.conf /usr/lpp/rdz/samples/

[/etc/rdz/]

Arquivo de configuração do CARMA para uso de CRASTART NOVO, customização é opcional
FMIEXT.properties /usr/lpp/rdz/samples/

[/etc/rdz/]

Arquivo de configuração de Integração do File Manager
  • Local e nome do script de inicialização alterados
  • Novas diretivas opcionais foram incluídas
uchars.settings /usr/lpp/rdz/samples/

[/etc/rdz/]

Arquivo de configuração de caracteres não editáveis NOVO, customização é opcional

Migrar da Versão 7.0 para a Versão 7.1

IBM Rational Developer para System z, FMID HHOP710

IBM CARMA, FMID HCMA710

Arquivos Configuráveis

A tabela 23 fornece uma visão geral de arquivos que foram customizados na versão 7.1. Observe que as bibliotecas de amostra do CARMA e do Developer para System z, CRA.SCRASAMP, FEK.SFEKSAMP e /usr/lpp/wd4z/rse/lib/, são fornecidas com mais membros customizáveis que os listados aqui, como o código de origem do CARMA de amostra e as tarefas para compilá-las.

Tabela 49. Customizações da Versão 7.1
Membro/Arquivo Local padrão Propósito Notas de migração
ELAXF* FEK.SFEKSAMP JCL para construções de projetos remotos, e outras tarefas ELAXFADT é novo
CRA$VMSG CRA.SCRASAMP JCL para criação do VSAM de mensagens do CARMA
  • renomeado, era CRAMREPR
  • o VSAM criado por essa tarefa foi atualizado
CRA$VDEF CRA.SCRASAMP JCL para criação do VSAM de configuração do CARMA
  • renomeado, era CRAREPR
  • o VSAM criado por essa tarefa foi atualizado
CRA$VSTR CRA.SCRASAMP JCL para criação do VSAM de informações customizadas do CARMA renomeado, era CRASREPR
CRASUBMT CRA.SCRASAMP CLIST de inicialização em lote do CARMA incluir DD CARMALOG
CRA#VSLM CRA.SCRASAMP JCL para criar VSAM de mensagem do SCLM RAM renomeado, era CRALREPR
CRA#ASLM CRA.SCRASAMP JCL para criar conjuntos de dados do SCLM RAM renomeado, era CRASALX
CRA#VPDS CRA.SCRASAMP JCL para criar VSAM de mensagem do PDS RAM renomeado, era CRATREPR
CRA#CRAM CRA.SCRASAMP JCL para compilar RAM da estrutura renomeado, era CRARAMCM
FEKAPPCC FEK.SFEKSAMP JCL para criação de uma transação APPC explorar o suporte ISPF NEST
rsed.envvars
/usr/lpp/wd4z/rse/lib/
[/etc/wd4z/]

Variáveis de ambiente do RSE As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas)
FMIEXT.properties
/usr/lpp/wd4z/rse/lib/
[/etc/wd4z/]

Arquivo de configuração de Integração do File Manager NOVO, customização é necessária, quando usada

Apêndices

Apêndice A. Configurando o SSL e a Autenticação X.509

Este apêndice é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar ao configurar o SSL (Secure Socket Layer) ou durante a verificação e/ou modificação de uma configuração existente. Este apêndice fornece também uma configuração de amostra para suportar usuários que se autenticam 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 para 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 2ª 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 abaixo 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.

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 50. 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 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:

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 Anel de Chave 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 acima é iniciada criando-se os perfis necessários e permitindo que o ID de usuário STCRSE acesse os conjuntos de chaves e os certificados pertencentes por 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 para 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))

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 da Customização.

$ 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 acima 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
	   -> uncomment and change: -Ddaemon.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 acima 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 acima ativam o SSL e informam ao daemon RSE e ao servidor RSE que seus certificados (compartilhados) estão armazenados com o rótulo 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.

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. As 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 da Customização:

  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. Fornece também um novo número de porta (4047) e o local dos arquivos de configuração relacionados ao SSL (/etc/rdz/ssl), conforme mostrado na amostra de código a seguir. 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 61. 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 IVP='',                        * 'IVP' to do an IVP test
//            PORT=4047,
//            HOME='/usr/lpp/rdz',
//            CNFG='/etc/rdz/ssl'
//*
//RSE      EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
//            PARM='PGM &HOME./bin/rsed.sh &IVP &PORT &CNFG' 
//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 os 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 para 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 para System z não reconhecer o certificado do host ou a CA que o assinou, o cliente Developer para System z perguntará ao usuário se é possível confiar nesse certificado.

Figura 62. 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 63. 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 Log de 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 informações adicionais 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 acima inicia criando um banco de dados de chaves chamado rdzssl.kdb com a senha rsessl. Quando o banco de dados existir, ele será preenchido através 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 Brasil - Centro de Traduções Rodovia SP 101 km 09 CEP 13185-900 Hortolândia, SP NC US Nome do assunto: rdz rse ssl rdz IBM Brasil - Centro de Traduções Rodovia SP 101 km 09 CEP 13185-900 Hortolândia, SP NC US 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 acima 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 auto-assinado criado acima é 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 acima ativam o SSL e informam ao servidor RSE que o certificado está armazenado com o rótulo rdzrse no keystore rdzssl.jks com a senha rsessl. O daemon RSE ainda está usando um conjunto de chaves compatível com SAF.

Apêndice B. 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 para 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):
-------------------------------------------------------------
Resolver Trace Initialization Complete -> 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 no Developer para System z

Conforme informado anteriormente, o Developer para 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.

No exemplo a seguir, nós concentraremos em algumas tarefas de configuração para o TCP/IP e o Resolver. 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 abaixo vemos que o TCP/IP utilizará 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 deve ser o nome do host e que um servidor de nomes de domínio (DNS) não é usado; 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. Na JCL do Resolver vemos que a instrução SETUP DD 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 assumirmos que a variável de ambiente RESOLVER_CONFIG não está configurada, podemos ver na Tabela 51 que o Resolvedor tentará utilizar /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) podemos 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 51 também informa que não é necessário fazer nada para utilizar 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 acima, definimos cdfmvs08 e cdfmvs08.raleigh.ibm.com como um nome válido para o endereço IP do nosso sistema z/OS.

    Se estivéssemos utilizando um DNS (servidor de nomes de domínios), o DNS conteria as informações de /etc/hosts e /etc/resolv.conf e SYS1.TCPPARMS(TCPDATA) teriam instruções que identificam o DNS em nosso 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 51. 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 51 é 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 fekfivpt TCP/IP IVP, conforme descrito em Verificação de Instalação. A seção de configuração do resolvedor da saída será semelhante à seguinte amostra:

Resolver Trace Initialization Complete -> 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 no rsed.envvars, em que <arquivo resolvedor> ou <dados do resolvedor> representam o nome do arquivo resolvedor de IP:

RESOLVER_CONFIG=<arquivo resolvedor>

ou

RESOLVER_CONFIG='<conjunto de dados do resolvedor>'

Apêndice C. Configurando o INETD

Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o INETD ou durante a verificação ou a modificação de uma configuração existente. INETD é usado pelo Developer para System z para a funcionalidade REXEC/SSH.

O daemon do INETD fornece gerenciamento de serviço para uma rede IP. Ele reduz o carregamento do sistema, invocando outros daemons apenas quando forem necessários e fornecendo vários serviços de Internet simples (como echo) internamente. O INETD lê o arquivo de configuração inetd.conf para determinar quais serviços adicionais fornecer. ETC.SERVICES é usado para vincular os serviços a portas.

inetd.conf

Os serviços que dependem do INETD são definidos em inetd.conf, lido pelo INETD no momento da inicialização. O local padrão e o nome de inetd.conf é /etc/inetd.conf. Um arquivo inetd.conf de amostra pode ser encontrado em /samples/inetd.conf.

As seguintes regras de sintaxe se aplicam às entradas de inetd.conf:

Cada entrada consiste em 7 campos posicionais, correspondendo ao formato:

service_name socket_type protocol wait_flag userid server_program
                        server_program_arguments

[ip_address:]service_name
ip_address é um IP local, seguido por dois pontos (:). Se especificado, o endereço será usado, em vez de INADDR_ANY, ou o padrão atual. Para solicitar especificamente INADDR_ANY, utilize "*:". Se ip_address (ou dois-pontos) for especificado sem nenhuma outra entrada na linha, será o padrão para linhas subsequentes, até que um novo padrão seja especificado. service_name é um nome de serviço bem conhecido ou definido pelo usuário. O nome especificado deve corresponder a um dos nomes de servidor definidos em ETC.SERVICES.
socket_type
stream ou dgram, para indicar que um soquete de fluxo ou de datagrama é usado para o serviço.
protocol[,sndbuf=n[,rcvbuf=n]]

protocol pode ser tcp[4|6] ou udp[4|6], e é usado para qualificar o nome do serviço. O nome do serviço e o protocolo devem corresponder a uma entrada em ETC.SERVICES, exceto que "4" ou "6" não deve ser incluído na entrada ETC.SERVICES.

sndbuf e rcvbuf especificam o tamanho dos buffers de envio e recebimento. O tamanho, representado por n, pode estar em bytes, ou um "k" ou "m" pode ser incluído para indicar kilobytes ou megabytes respectivamente. sndbug e rcvbuf pode ser usado na ordem.

wait_flag[.max]

wait ou nowait.wait indica que o daemon é de encadeamento único e outro pedido não será submetido a manutenção até que o primeiro seja concluído. Se nowait for especificado, o INETD emitirá uma aceitação quando um pedido de conexão for recebido no soquete de fluxo. Se a espera for especificada, será responsabilidade do servidor emitir a aceitação, se este for um soquete de fluxo.

max é o número máximo de usuários permitidos para solicitar manutenção em um intervalo de 60 segundos. O padrão é 40. Se for excedido, a porta do serviço será encerrada.

userid[.group]

userid é o ID do usuário em que o daemon bifurcado deve ser executado. Esse ID do usuário pode ser diferente do ID do usuário do INETD. As permissões designadas a este ID do usuário depenem das necessidades do serviço. O ID do usuário do INETD precisa da permissão BPX.DAEMON para alternar o processo bifurcado para este ID do usuário.

O valor group opcional, separado do ID do usuário por um ponto (.), permite que o servidor seja executado com um ID de grupo diferente do padrão para este ID do usuário.

server_program
server_program é o nome do caminho completo do serviço. Por exemplo, /usr/sbin/rlogind é o nome do caminho completo para o comando rlogind.
server_program_arguments
Máximo de 20 argumentos. O primeiro argumento é o nome do servidor.

ETC.SERVICES

O INETD utiliza ETC.SERVICES para mapear números de porta e protocolos para os serviços que deve suportar. Ele pode ser um conjunto de dados MVS ou um arquivo z/OS UNIX. Uma amostra é fornecida em SEZAINST(SERVICES), que também está disponível como /usr/lpp/tcpip/samples/services. A ordem de procura para ETC.SERVICES depende do método de inicialização do INETD; z/OS UNIX ou MVS nativo.

As seguintes regras de sintaxe se aplicam à especificação de informações de serviços:

Cada entrada consiste de quatro campos posicionais correspondendo ao formato:

service_name   port_number/protocol   aliases 

service_name
Especifica um nome de serviço bem conhecido ou definido pelo usuário
port_number
Especifica o número da porta do soquete usado para o serviço
protocol
Especifica o protocolo de transporte usado para o serviço. Os valores válidos são tcp e udp
aliases
Especifica uma lista de nomes de serviços não-oficiais

Ordem de Procura Usada no Ambiente z/OS UNIX

A ordem de procura usada para acessar ETC.SERVICES no z/OS UNIX é a seguinte. A procura termina quando o primeiro arquivo é localizado:

  1. /etc/services
  2. userid.ETC.SERVICES

    userid é o ID do usuário usado para iniciar INETD

    .
  3. hlq.ETC.SERVICES

    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.

Ordem de Procura Usada no Ambiente MVS Ambiente

A ordem de procura usada para acessar ETC.SERVICES no MVS nativo é a seguinte. A procura termina quando o primeiro conjunto de dados é localizado:

  1. //Placa DD SERVICES

    O conjunto de dados alocado para a instrução DD SERVICES é usado

  2. userid.ETC.SERVICES

    userid é o ID do usuário usado para iniciar INETD

    .
  3. jobname.ETC.SERVICES

    jobname é o nome especificado na instrução JOB JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado

  4. hlq.ETC.SERVICES

    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.

Nota:
O início do INETD por meio de BPXPATCH não resulta na utilização da ordem de procura nativa do MVS, pois BPXBATCH executa o comando inicial no ambiente z/OS UNIX. A ordem de procura nativa do MVS é usada apenas ao iniciar um módulo de carregamento MVS, como o SEZALOAD(FTP).

Definições de Portas PROFILE.TCPIP

Não confunda as definições PORT (ou PORTRANGE) em PROFILE.TCPIP com as portas definidas em ETC.SERVICES, pois essas definições têm finalidades diferentes. As portas definidas em PROFILE.TCPIP são usadas pelo TCPIP para ver se a porta está reservada para um determinado serviço. ETC.SERVICES é usado pelo INETD para mapear uma porta para um serviço.

Quando o INETD recebe um pedido em uma porta monitorada, bifurca um processo-filho (com o serviço solicitado) chamado inetdx, em que inetd é o nome da tarefa do INETD (depende do método de inicialização) e x é um número de dígito único.

Isso complica a reserva de porta, portanto, se uma porta monitorada do INETD for reservada em PROFILE.TCPIP, é aconselhável usar o nome do procedimento JCL iniciado para o Espaço de Endereço de Kernel do z/OS UNIX para permitir que quase todos os processos sejam ligados à porta. Normalmente, esse nome é OMVS, a menos que um nome diferente seja especificado explicitamente no parâmetro STARTUP_PROC do membro BPXPRMxx parmlib.

A lista a seguir explica como determinar o nome da tarefa, de acordo com o ambiente em que o aplicativo é executado:

Nota:
Embora não seja aconselhável fazer isso, as portas definidas em ETC.SERVICES podem ser diferentes do número da porta reservada para o serviço em PROFILE.TCPIP.

/etc/inetd.pid

O processo do INETD cria um arquivo temporário, /etc/inetd.pid, que contém o PID (ID do processo) do daemon INETD em execução no momento. Esse valor de PID é usado para identificar registros syslog originados do processo INETD e para fornecer o valor PID para comandos que requerem um, como kill. Também é usado como um mecanismo de bloqueio para impedir que mais de um 1 processo INETD esteja ativo.

Inicialização

A implementação de INETD do z/OS UNIX está localizada por padrão em /usr/sbin/inetd e suporta dois parâmetros de inicialização opcionais não-posicionais:

/usr/sbin/inetd [-d] [inetd.conf] 

-d
Opção de depuração. A opção de depuração é gravada em stderr, que pode ser encaminhada para um arquivo pelo daemon syslogd. Consulte Communications Server IP Configuration Guide (SC31-8775) para obter informações adicionais sobre syslogd. Observe que, quando iniciado dessa forma, o INETD não bifurcará um processo-filho para iniciar um serviço.
inetd.conf
Arquivo de configuração. O valor padrão é /etc/inetd.conf

Você deve iniciar o INETD no momento do IPL. A forma mais comum de fazer isso é iniciá-lo no /etc/rc ou /etc/inittab (z/OS 1.8 e posterior apenas). Pode ser iniciado de uma tarefa ou uma tarefa iniciada utilizando BPXBATCH ou de uma sessão de shell de um usuário com autoridade apropriada.

/etc/rc

Quando iniciado a partir do script do shell de inicialização do z/OS UNIX, /etc/rc, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Um arquivo /etc/rc de amostra é fornecido como /samples/rc. Os seguintes comandos de amostra podem ser usados para iniciar o INETD:

# Start INETD
_BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf &
sleep 5

/etc/inittab

O z/OS 1.8 e superior oferecem um método alternativo, /etc/inittab, para emissão de comandos durante a inicialização do z/OS UNIX. /etc/inittab permite a definição do parâmetro respawn, que reinicia o processo automaticamente quando ele é encerrado (um WTOR é enviado ao operador para um segundo reinício, em 15 minutos). Quando iniciado a partir de /etc/inittab, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Um /etc/inittab de amostra é fornecido como /samples/inittab. O seguinte comando de amostra pode ser usado para iniciar o INETD:

# Start INETD
inetd::respfrk:/usr/sbin/inetd /etc/inetd.conf

Nota:
Lembre-se de que o parâmetro respfrk usado na amostra transferirá o atributo respawn para todos os processos bifurcados, incluindo o RSE. Quando o cliente encerrar a conexão, respawn a iniciará novamente. O servidor RSE será encerrado novamente mais tarde, devido ao tempo limite. Consulte UNIX System Services Planning (GA22-7800) para saber mais sobre inittab.

BPXBATCH

O método de inicialização BPXBATCH funciona para tarefas iniciadas e tarefas do usuário. Observe que o INETD é um processo em segundo plano, portanto a etapa BPXBATCH iniciando o INETD será encerrada em segundos após a inicialização. Quando iniciado pelo BPXBATCH, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. A JCL listada na seguinte amostra de código é um procedimento de amostra para iniciar INETD (a etapa KILL remove um processo INETD ativo, se houver algum):

Figura 64. JCL de Inicialização do INETD
//INETD    PROC PRM=
//*
//KILL     EXEC PGM=BPXBATCH,REGION=0M,
//         PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill'
//*
//INETD    EXEC PGM=BPXBATCH,REGION=0M,
//            PARM='PGM /usr/sbin/inetd &PRM'
//STDERR   DD SYSOUT=*
//* STDIN, STDOUT e STDENV são padronizados como /dev/null
//*

Nota:

Sessão de Shell

Quando iniciado a partir de uma sessão shell, o INETD utiliza a procura do z/OS UNIX para localizar ETC.SERVICES. Os seguintes comandos de amostra podem ser usados (por uma pessoa com autoridade suficiente) para parar e iniciar o INETD (# é o prompt do z/OS UNIX):

# ps -e | grep inetd
      7 ?         0:00 /usr/sbin/inetd
# kill 7
# _BPX_JOBNAME='INETD' /usr/sbin/inetd &
Nota:
Esse método não é aconselhável para a inicialização inicial; /etc/rc ou /etc/inittab são mais apropriados, pois são executados quando o z/OS UNIX é inicializado.

Segurança

O INETD é um processo do z/OS UNIX e, portanto, requer definições OMVS válidas no software de segurança para o ID do usuário associado ao INETD. UID, HOME e PROGRAM devem ser configurados para o ID do usuário, junto com o GID para o grupo padrão do usuário. Se o INETD for iniciado pelo /etc/rc ou pelo /etc/inittab, o ID do usuário será herdado do kernel z/OS UNIX, padrão OMVSKERN.

ADDGROUP OMVSGRP OMVS(GID(1))
ADDUSER OMVSKERN DFLTGRP(OMVSGRP) NOPASSWORD +
        OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))

INETD é um daemon que exige acesso a funções como setuid(). Portanto, o ID do usuário usado para iniciar o INETD requer acesso READ ao perfil BPX.DAEMON na classe FACILITY. Se esse perfil não estiver definido, UID 0 será obrigatório.

PERMIT BPX.DAEMON CLASS(FACILITY) ACCESS(READ) ID(OMVSKERN)

O ID do usuário do INETD requer permissão EXECUTE para o programa inetd (/usr/sbin/inetd), acesso READ para os arquivos inetd.conf e ETC.SERVICES e acesso WRITE para /etc/inetd.pid. Se você deseja executar o INETD sem o UID 0, pode conceder acesso CONTROL ao perfil SUPERUSER.FILESYS na classe UNIXPRIV para fornecer as permissões necessárias para os arquivos z/OS UNIX.

Os programas que requerem autoridade de daemon devem ser controlados por programa, se BPX.DAEMON estiver definido na classe FACILITY. Isso já é feito para o programa INETD padrão (/usr/sbin/inetd), mas deve ser definido manualmente se você utilizar uma cópia ou uma versão customizada. Use o comando extattr +p para tornar um arquivo z/OS UNIX controlado por programa. Use a classe RACF PROGRAM para tornar um módulo de carregamento MVS controlado por programa.

Os programadores de sistema que precisam reiniciar o INETD em sua sessão de shell iniciarão o INETD utilizando suas permissões. Portanto, devem ter a mesma lista de permissões que o ID do usuário do INETD regular. Além disso, também precisam de permissões para listar e parar o processo do INETD. Isso pode ser feito de várias maneiras.

Consulte UNIX System Services Command Reference (SA22-7802) para saber mais sobre os comandos extattr e su. Consulte UNIX System Services Planning (GA22-7800) para saber mais sobre a classe UNIXPRIV e perfis BPX.* na classe FACILITY. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre as definições de segmento OMVS e a classe PROGRAM.

Requisitos do Developer para System z

O Developer para System z depende do INETD para gerenciar REXEC e/ou SSH. Ele também pode impor requisitos adicionais para a configuração do INETD descrita acima.

REXEC (ou SSH) é usado para os dois seguintes propósitos, conforme descrito em (Opcional) Usando REXEC (ou SSH).

As ações remotas em subprojetos z/OS UNIX não requerem configurações especiais. O método de inicialização RSE alternativo, no entanto, requer configurações especiais.

INETD

As configurações ambientais do INETD, informadas ao iniciar um processo, e as permissões para o ID do usuário do INETD, devem ser definidas adequadamente para que o INETD inicie o servidor RSE.

REXEC (ou SSH)

O daemon REXEC (ou SSH) que é iniciado pelo INETD quando um cliente se conecta à porta 512 (ou 22, respectivamente) é usado para fazer autenticação, iniciar o servidor RSE e retornar o número da porta para favorecer a comunicação com o cliente. Para isso, o ID do usuário designado ao daemon do REXEC (ou SSH) (em inetd.conf) requer as seguintes permissões:

Apêndice D. Configurando o APPC

Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o APPC (Advanced Program-to-Program Communication) ou durante a verificação e a modificação de uma configuração existente.

Consulte MVS Planning: APPC/MVS Management (SA22-7599) e MVS Initialization and Tuning Reference (SA22-7592) para obter informações adicionais sobre o gerenciamento de APPC e sobre os membros parmlib discutidos abaixo.

Observe que isso não abrange uma configuração completa do APPC, apenas destaca alguns aspectos principais que podem ser aplicáveis a seu site.

O membro SYS1.SAMPLIB(ATBALL) contém uma lista e descrições de todos os membros relacionados ao APPC (amostra) em SYS1.SAMPLIB.

VSAM

APPC/MVS armazena seus dados de configuração nos seguintes membros SYS1.PARMLIB e dois conjuntos de dados VSAM:

Um TP é um programa aplicativo que utiliza o APPC para se comunicar com um TP no mesmo sistema, ou em outro, para acessar recursos. A configuração do APPC para o Developer para System z ativa um novo TP chamado FEKFRSRV, mencionado como o serviço TSO Commands.

A tarefa a seguir é uma concatenação dos membros de amostra SYS1.SAMPLIB(ATBTPVSM) e SYS1.SAMPLIB(ATBSIVSM), e pode ser usada para definir os VSAMs do APPC.

Figura 65. JCL para Criar VSAMs do APPC
//APPCVSAM JOB <parâmetros da tarefa>
//*
//* CUIDADO: Isso não é um procedimento JCL nem uma tarefa completa.
//* Antes de usar esta amostra, você deverá fazer as seguintes
//* modificações:
//* 1.	Altere os parâmetros da tarefa de acordo com os requisitos do sistema.
//* 2.	Altere ****** para o volume que conterá os VSAMs do APPC.
//*
//TP       EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
   DEFINE CLUSTER (NAME(SYS1.APPCTP) -
                   VOLUME(******) -
                   INDEXED REUSE -
                   SHAREOPTIONS(3 3) -
                   RECORDSIZE(3824 7024) -
                   KEYS(112 0) -
                   RECORDS(300 150)) -
          DATA    (NAME(SYS1.APPCTP.DATA)) -
          INDEX   (NAME(SYS1.APPCTP.INDEX))
//*
//SI       EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
   DEFINE CLUSTER (NAME(SYS1.APPCSI) -
                   VOLUME(******) -
                   INDEXED REUSE -
                   SHAREOPTIONS(3 3) -
                   RECORDSIZE(248 248) -
                   KEYS(112 0) -
                   RECORDS(50 25)) -
          DATA    (NAME(SYS1.APPCSI.DATA)) -
          INDEX   (NAME(SYS1.APPCSI.INDEX))
//*

VTAM

O APPC é uma implementação do protocolo SNA (Systems Network Architecture) LU 6.2. O SNA oferece formatos e protocolos que definem uma variedade de componentes SNA físicos e lógicos, como a Unidade Lógica (LU). A LU 6.2 é um tipo de unidade lógica desenvolvida especificamente para controlar a comunicação entre os programas aplicativos.

Para utilizar SNA no MVS, você precisa instalar e configurar o VTAM (Virtual Telecommunications Access Method). O VTAM deve estar ativo antes que as tarefas do sistema APPC possam ser usadas.

A parte específica do APPC da configuração VTAM consiste em três etapas:

  1. Defina o nome de modo usado (por exemplo, APPCHOST) como VTAM usando SYS1.SAMPLIB(ATBLJOB) para fazer a montagem e a edição de link de SYS1.SAMPLIB(ATBLMODE) em SYS1.VTAMLIB. Consulte o membro SYS1.SAMPLIB(ATBLMODE) para obter detalhes.
  2. Definir APPC/MVS como um aplicativo VTAM, copiando o membro de amostra SYS1.SAMPLIB(ATBAPPL) para um conjunto de dados na concatenação SYS1.VTAMLST. Consulte o membro SYS1.SAMPLIB(ATBAPPL) para obter detalhes.
  3. Use o comando do console v net,act,id=atbappl para ativar o aplicativo recém-definido (em que net é igual ao nome da tarefa iniciada do VTAM). Use o comando do console d net,appls para verificar se o aplicativo está ativo. Inclua o nome do membro em SYS1.VTAMLST(ATCCONxx) se quiser que seja ativado quando o VTAM for iniciado.

O ACBNAME de MVSLU01 usado no membro de amostra SYS1.SAMPLIB(ATBAPPL) pode ser usado para corresponder aos padrões do site, mas deve corresponder às definições no membro SYS1.PARMLIB(APPCPMxx).

Figura 66. SYS1.SAMPLIB(ATBAPPL)
MVSLU01 APPL   ACBNAME=MVSLU01,                                        C
               APPC=YES,                                               C
               AUTOSES=0,                                              C
               DDRAINL=NALLOW,                                         C
               DLOGMOD=APPCHOST,                                       C
               DMINWNL=5,                                              C
               DMINWNR=5,                                              C
               DRESPL=NALLOW,                                          C
               DSESLIM=10,                                             C
               LMDENT=19,                                              C
               MODETAB=LOGMODES,                                       C
               PARSESS=YES,                                            C
               SECACPT=CONV,                                           C
               SRBEXIT=YES,                                            C
               VPACING=1

Consulte Communications Server IP SNA Network Implementation Guide (SC31-8777) para obter informações adicionais sobre a configuração de VTAM.

SYS1.PARMLIB(APPCPMxx)

Para ativar e suportar o fluxo de comunicação entre os sistemas, os sites devem definir Unidades Lógicas (LUs) entre as sessões que podem ser ligadas. Um site precisa definir, pelo menos, uma LU antes que o processamento de APPC/MVS possa ocorrer, mesmo quando o processamento APPC permanecer em um sistema único. As LUs são algumas das definições realizadas em SYS1.PARMLIB(APPCPMxx).

O serviço TSO Commands requer que o APPC seja configurado para ter uma LU de base que possa manipular pedidos de entrada e saída.

A definição da LU deve ser incluída no membro SYS1.PARMLIB(APPCPMxx) e precisa incluir os parâmetros BASE e SCHED(ASCH). O membro APPCPMxx também especifica quais conjuntos de dados VSAM de TP e de SI VSAM serão usados.

A amostra de código a seguir é um membro SYS1.PARMLIB(APPCPMxx) que pode ser usado para o serviço TSO Commands.

Figura 67. SYS1.PARMLIB(APPCPMxx)
LUADD
  ACBNAME(MVSLU01)
  BASE
  SCHED(ASCH)
  TPDATA(SYS1.APPCTP)
SIDEINFO DATASET(SYS1.APPCSI)

Quando um sistema possui vários nomes de LU, pode ser necessário fazer alterações, dependendo de qual LU o sistema seleciona como LU BASE. A LU BASE para o sistema é determinada da seguinte forma:

  1. A LU base do sistema é representada pela última instrução LUADD que contém os parâmetros NOSCHED e BASE. Esse tipo de LU base do sistema permitirá que os pedidos de saída sejam processados quando nenhum planejador de transação estiver ativo.
  2. Se nenhuma instrução LUADD contiver NOSCHED e BASE, a LU base do sistema será representada pela última instrução LUADD que contém o parâmetro BASE e especifica ASCH como planejador de transações APPC/MVS. Isto pode ser realizado codificando SCHED(ASCH) ou não codificando o parâmetro SCHED (ASCH é o valor padrão para SCHED).
    Nota:
    O comando do operador D APPC,LU,ALL mostrará todas as definições de LU ativas e marcará a LU de base.

Se seu sistema possui uma LU com parâmetros BASE e NOSCHED, esta LU seria usada como a LU BASE mas o serviço TSO Commands não funcionará porque esta LU não possui um planejador de transações para manipular pedidos para a transação FEKFRSRV. Se esta LU não puder ser alterada para remoção do parâmetro NOSCHED, a variável de ambiente rsed.envvars (_FEKFSCMD_PARTNER_LU) pode ser configurada para a LU que possui BASE e SCHED(ASCH), tal como:

_FEKFSCMD_PARTNER_LU=MVSLU01

Consulte Arquivo de Configuração do RSE rsed.envvars para obter informações adicionais sobre rsed.envvars.

SYS1.PARMLIB(ASCHPMxx)

O planejador de transações APPC/MVS (nome padrão é ASCH) inicia e planeja programas de transações em resposta aos pedidos de entrada para conversões. O membro SYS1.PARMLIB(ASCHPMxx) controla seu funcionamento, por exemplo, com definições de classe da transação.

A classe de transação APPC usada para o serviço TSO Commands deve ter iniciadores APPC suficientes para permitir um iniciador para cada usuário do Developer para System z.

O serviço TSO Commands também precisa das especificações padrão para ser especificado nas seções OPTIONS e TPDEFAULT.

A amostra de código a seguir é um membro SYS1.PARMLIB(ASCHPMxx) que pode ser usado para o serviço TSO Commands.

Figura 68. SYS1.PARMLIB(ASCHPMxx)
CLASSADD
  CLASSNAME(A)
  MAX(20)
  MIN(1)
  MSGLIMIT(200)

OPTIONS
  DEFAULT(A)

TPDEFAULT
  REGION(2M)
  TIME(5)
  MSGLEVEL(1,1)
  OUTCLASS(X)
Nota:

Ativando Alterações do APPC

As alterações na configuração documentadas nas etapas acima agora podem ser ativadas. Isso pode ser feito de diversas maneiras, dependendo das circunstâncias:

Os comandos de console D APPC e D ASCH podem ser usados para verificar a configuração do APPC. Consulte MVS System Commands (GC28-1781) para obter informações adicionais sobre os comandos do console mencionados.

Definindo a Transação de Serviço Comandos do TSO

Quando o APPC/MVS está ativo, o serviço TSO Commands do Developer para System z pode ser definido, conforme descrito em (Opcional) Transação APPC para o Serviço de Comandos TSO.

A maneira documentada para definir a transação do APPC é customizar e enviar a FEK.#CUST.JCL(FEKAPPCC).

A transação APPC também pode ser definida interativamente por meio da interface ISPF do APPC, documentada em um white paper. Esse White Paper descreve também como configurar a transação APPC para coletar informações de contabilidade específicas ao usuário.

O White Paper do APPC e do WebSphere Developer para System z (SC23-5885-00) está disponível na biblioteca da Internet em Developer para System z, http://www-306.ibm.com/software/awdtools/rdz/library/.

Nota:
A JCL do TP, usada pelo APPC para iniciar o serviço Comandos do TSO, foi alterada no Developer para System z versão 7.1. Se você seguir as orientações no White Paper para definir o TP, deverá incluir a palavra-chave NESTMACS na linha PARM, por exemplo:
//  PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'

(Opcional) Opções de Configuração Alternativas

O Developer para System z suporta opções de configuração APPC e VTAM alternativas, sendo que algumas estão documentadas nesta seção.

Nome de Transação Alternativo

O nome da transação padrão para o serviço TSO Commands é FEKFRSRV, conforme descrito em (Opcional) Transação APPC para o Serviço de Comandos TSO. Conforme descrito na mesma seção, esse nome pode ser alterado ao definir a transação para APPC.

Observe que a alteração do nome da transação no APPC significa que o novo nome deverá ser designado a _FEKFSCMD_TP_NAME_ em rsed.envvars, conforme descrito em Arquivo de Configuração do RSE rsed.envvars.

Várias LUs

APPC é um protocolo de comunicação que permite que um programa (o nó parceiro) interaja com um programa no host (o nó local). Com o Developer para System z, o nó parceiro (servidor TSO Commands) e o nó local (servidor RSE) ficam ativos no mesmo sistema z/OS. Por padrão, ambos usam a mesma definição de LU (BASE) para estabelecer comunicação.

Você pode especificar um nome de LU parceira alternativo para o serviço TSO Commands na diretiva _FEKFSCMD_PARTNER_LU_ de rsed.envvars, conforme descrito em Arquivo de Configuração do RSE rsed.envvars. Observe que não é possível alterar a LU local, que deve ser sempre uma LU BASE válida (com as palavras-chave BASE e SCHED).

Segurança da LU

O VTAM suporta uma configuração de APPC segura, na qual a comunicação entre a LU parceira e a local deve ser definida para o software de segurança.

Ele é ativado ao incluir VERIFY=REQUIRED na definição do VTAM da LU (BASE) local. As definições de segurança devem ser feitas na classe APPCLU, conforme descrito em MVS Planning: APPC/MVS Management (SA22-7599).

Observe que se essa configuração estiver ativa no VTAM e a configuração de seu software de segurança não estiver concluída, a comunicação com o serviço TSO Commands falhará na inicialização sem qualquer mensagem no log do sistema indicando que o VTAM recusou a configuração da conexão. O teste IVP do APPC (fekfivpa) falhará com a mensagem "Return code 1 - Allocate Failure no retry".

Apêndice E. Requisitos

Este apêndice lista os pré-requisitos e correquisitos do host para esta versão do Developer para System z.

Consulte Rational Developer para System z Prerequisites (SC23-7659) na biblioteca on-line do Developer para System z em http://www-01.ibm.com/software/awdtools/rdz/library/ para obter uma lista atualizada de requisitos obrigatórios e opcionais.

Os produtos listados nesta seção estão todos disponíveis no momento da publicação deste manual. Consulte o Web site do IBM Software Support Lifecycle http://www.ibm.com/software/support/lifecycle/, para ver se um produto selecionado ainda está disponível no momento em que você desejar usar a função relacionada do Developer para System z.

Pré-requisitos de Host do z/OS

O uso do Developer para System z exige que você tenha o seguinte ambiente com os pré-requisitos apropriados:

z/OS

Um dos seguintes níveis deve estar instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5694-A01 z/OS v 1.11

ISPF:

  • APAR OA29489 (TSO/ISPF Client Gateway)
    PTF UA51713

TCP/IP:

  • Nenhum PTF ou Nível de Serviço necessário
5694-A01 z/OS v 1.10

ISPF:

  • APAR OA29489 (TSO/ISPF Client Gateway)
    PTF UA51712

TCP/IP:

  • APAR PK74282 (crescimento de armazenamento fixo CSM)
    PTF UK41810
5694-A01 z/OS v 1.9

ISPF:

  • APAR OA29489 (TSO/ISPF Client Gateway)
    PTF UA51687

TCP/IP:

  • APAR PK74282 (crescimento de armazenamento fixo CSM)
    PTF UK41812
5694-A01 z/OS v 1.8

ISPF:

  • APAR OA20345 (saída de comando aninhada)
    PTF UA33575
  • APAR OA20449 (incluir suporte ao NESTMACS)
    PTF UA34052
  • APAR OA29489 (TSO/ISPF Client Gateway)
    PTF UA51686

TCP/IP:

  • APAR PK74282 (crescimento de armazenamento fixo CSM)
    PTF UK41811

O Web site do produto relacionado é:

http://www-03.ibm.com/systems/z/os/zos/
Notas:
  1. Ações remotas (baseadas em host) para subprojetos do z/OS UNIX exigem que a versão z/OS UNIX de REXEC ou SSH esteja ativa no host.
  2. O z/OS inclui os seguintes componentes, que precisam ser instalados, configurados e estar funcionando:

SMP/E

Para instalar o Developer para System z, um dos seguintes níveis deve ser instalado:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-G44 IBM System Modification Program Extended (SMP/E) para z/OS v 3.5 Nenhum PTF ou Nível de Serviço necessário
5655-G44 IBM System Modification Program Extended (SMP/E) para z/OS v 3.4 Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www-03.ibm.com/systems/z/os/zos/smpe/

SDK para z/OS Java 2 Technology Edition

Para suportar aplicativos que usam o Remote Systems Explorer (RSE), um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-R32 IBM 64-bit SDK para z/OS, Java 2 Technology Edition, v 6.0 release de serviço 7
5655-R31 IBM 31-bit SDK para z/OS, Java 2 Technology Edition, v 6.0 release de serviço 7
5655-N99 IBM 64-bit SDK para z/OS, Java 2 Technology Edition, v 5.0 release de serviço 11
5655-N98 IBM 31-bit SDK para z/OS, Java 2 Technology Edition, v 5.0 release de serviço 11

O Web site do produto relacionado é:

http://www.ibm.com/servers/eserver/zseries/software/java/
Nota:
O PTF para Developer para System z APAR PM07305 deve ser aplicado ao usar uma versão de 64-bit do Java. O PTF está disponível por meio da página de serviço recomendada do Developer para System z, http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335.

Co-requisitos de Host do z/OS

Os produtos listados nesta seção e outros softwares declarados são necessários para suportar recursos específicos do Developer para System z. O cliente da estação de trabalho do Developer para System z pode ser instalado com êxito sem esses requisitos. Porém, um requisito do host estabelecido deve estar instalado e em funcionamento no tempo de execução para que o recurso correspondente funcione conforme projetado.

z/OS

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5694-A01 z/OS v 1.11

HLASM

Nenhum PTF ou Nível de Serviço necessário

XL C/C++

Nenhum PTF ou Nível de Serviço necessário

SCLM

Nenhum PTF ou Nível de Serviço necessário

LE (PL/I)

Nenhum PTF ou Nível de Serviço necessário

TN3270

Nenhum PTF ou Nível de Serviço necessário
5694-A01 z/OS v 1.10

HLASM

Nenhum PTF ou Nível de Serviço necessário

XL C/C++

Nenhum PTF ou Nível de Serviço necessário

SCLM

Nenhum PTF ou Nível de Serviço necessário

LE (PL/I)

Nenhum PTF ou Nível de Serviço necessário

TN3270

Nenhum PTF ou Nível de Serviço necessário
5694-A01 z/OS v 1.9

HLASM

Nenhum PTF ou Nível de Serviço necessário

XL C/C++

Nenhum PTF ou Nível de Serviço necessário

SCLM

  • APAR OA27379 (Procura SCLM)
    PTF UA46330 + UA46331, UA46332, UA46333, UA46334
    (dependente do- idioma)

LE (PL/I)

Nenhum PTF ou Nível de Serviço necessário

TN3270

Nenhum PTF ou Nível de Serviço necessário
5694-A01 z/OS v 1.8

HLASM

Nenhum PTF ou Nível de Serviço necessário

XL C/C++

Nenhum PTF ou Nível de Serviço necessário

SCLM

  • APAR OA21104 (modo de construção informativo)
    PTF UA35046 + UA35056, UA35057, UA35058 ou
    UA35059 (dependente do idioma)
  • APAR OA16924 (aprimorar SCLMINFO)
    PTF UA29772 + UA29922, UA29923, UA29924 ou
    UA29925 (dependente do idioma)
  • APAR OA16804 (incluir suporte substituto ao ID do usuário)
    PTF UA33524 + UA33533, UA33534, UA33535 ou
    UA33536 (dependente do idioma)

LE (PL/I)

  • APAR PK41552 (novas mensagens de PL/I para
    Developer para System z )
    PTF UK24482 (Inglês) ou UK24483 (Japonês)

TN3270

Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www-03.ibm.com/systems/z/os/zos/
Nota:
  1. JES3 v 1.10 ou superior é um co-requisito para usuários do JES3 que desejam usar o suporte do Monitor de Tarefas para visualizar a saída de tarefas ativas.
  2. O High Level Assembler (HLASM) deve estar instalado no host com o nível de serviço listado, a fim de compilar programas assembler desenvolvidos ou editados no Developer para System z.

    O Web site do produto relacionado é:

  3. O compilador XL C/C++ deve estar instalado no host com o nível de serviço listado, a fim de compilar programas C/C++ desenvolvidos ou editados no Developer para System z.

    O Web site do produto relacionado é:

  4. O SCLM deve estar instalado no host com o nível de serviço listado, a fim de suportar o SCLM Developer Toolkit.

    O Web site do produto relacionado é:

    Nota:
    • O APAR OA16804 só será necessário se você quiser usar criação, promoção e implementação seguras.
    • O APAR OA26997 só é necessário para suporte de segurança de membro.
    • O APAR OA27379 só é necessário para suporte de segurança de membro ou funcionalidade de procura SCLM.
  5. O Ambiente de Linguagem deve ser instalado no host com o nível de serviço listado, a fim de suportar o Enterprise Service Tools para PL/I.

    O Web site do produto relacionado é:

  6. O TN3270 deve estar instalado no host com o nível de serviço listado, a fim de suportar o emulador do Host Connect. O TN3270 é uma parte do componente de Serviços IP do IBM Communications Server.

    O Web site do produto relacionado é:

Compilador de COBOL

Para compilar programas COBOL desenvolvidos ou editados no Developer para System z, um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-S71 IBM Enterprise COBOL para z/OS v 4.2 Nenhum PTF ou Nível de Serviço necessário
5655-S71 IBM Enterprise COBOL para z/OS v 4.1 Nenhum PTF ou Nível de Serviço necessário
5535-G53 IBM Enterprise COBOL para z/OS v 3.4 Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www.ibm.com/software/awdtools/cobol/zos/
Nota:
O IBM Enterprise COBOL para z/OS v 4.1 é necessário para que o Enterprise Service Tools gere a Conversão XML Compilada que usa o recurso XML PARSE baseado em XMLSS no COBOL v 4.1.

Compilador PL/I

Para compilar programas PL/I desenvolvidos ou editados no Developer para System z, um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-H31 IBM Enterprise PL/I para z/OS v 3.9 Nenhum PTF ou Nível de Serviço necessário
5655-H31 IBM Enterprise PL/I para z/OS v 3.8 Nenhum PTF ou Nível de Serviço necessário
5655-H31 IBM Enterprise PL/I para z/OS v 3.7 Nenhum PTF ou Nível de Serviço necessário
5655-H31 IBM Enterprise PL/I para z/OS v 3.6 Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www.ibm.com/software/awdtools/pli/plizos/

Debug Tool para z/OS

Para suportar depuração remota do Developer para System z, um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto Linguagem de Programação Níveis de APARs, PTFs ou Serviço Necessários
5655-V50 IBM Debug Tool para z/OS V10.1 COBOL, PL/I, C/C++, assembler e recursos adicionais todas as manutenções disponíveis
5655-U27 IBM Debug Tool para z/OS V9.1 COBOL, PL/I, C/C++, assembler e recursos adicionais todas as manutenções disponíveis
5655-S16 IBM Debug Tool Utilities and Advanced Functions para z/OS V8.1.0 COBOL, PL/I, C/C++, assembler e recursos adicionais todas as manutenções disponíveis
5655-S17 IBM Debug Tool para z/OS V8.1.0 COBOL, PL/I, Assembler e C/C++ todas as manutenções disponíveis
Nota:
Suporte para configurações de depuração CICS no IBM Rational Developer para System z v7.6.1 ou mais alta requer uma Ferramenta de Depuração IBM v10.1 ou v9.1 (PTF número - UK52904).

O Web site do produto relacionado é:

http://www.ibm.com/software/awdtools/debugtool/
Nota:
O Debug Tool Utilities and Advanced Functions (DTU&AF) é um superconjunto do Debug Tool.

Começando com a versão 9, o Debug Tool para z/OS e os Utilitários e as Funções Avançadas da Ferramenta de Depuração foram mesclados em uma única oferta.

CICS Transaction Server

Para suportar aplicativos com instruções integradas do CICS, um dos seguintes níveis deve ser instalado:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-S97 IBM CICS Transaction Server para z/OS v 4.1 Nenhum PTF ou Nível de Serviço necessário
5697-E93 IBM CICS Transaction Server para z/OS v 3.2 UK34221
5697-E93 IBM CICS Transaction Server para z/OS v 3.1 UK15767, UK15764, UK11782, UK11294, UK12233, UK12521, UK15261, UK15271, UK34221, UK34078

O Web site do produto relacionado é:

http://www.ibm.com/software/htp/cics/tserver/
Nota:

IMS

Para suportar aplicativos que usam banco de dados IMS e comunicações de dados, um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5635-A02 IBM IMS v 11.1 Nenhum PTF ou Nível de Serviço necessário
5635-A01 IBM IMS v 10.1 Nenhum PTF ou Nível de Serviço necessário
5655-J38 IBM IMS v 9.1 Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www.ibm.com/software/data/ims/ims/
Nota:

DB2 para z/OS

Para suportar o DB2, um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5635-DB2 IBM DB2 para z/OS v 9.1 Nenhum PTF ou Nível de Serviço necessário
5625-DB2 IBM DB2 Universal Database para z/OS v 8.1 Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www.ibm.com/software/data/db2/zos/

Rational Team Concert para System z

Para controle de origem baseado no Jazz que usa projetos remotos do Developer para System z, o seguinte nível deve ser instalado.

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5724-V82 Rational Team Concert para System z Server v 2.0

FMID HAHA200 - Servidor de Time

  • UK54064
  • UK54071
  • UK54073
  • UK54095
  • UK54098

FMID HAHB200 - Kit de ferramentas

  • UK54065
  • UK54066
  • UK54099

FMID HAHC200 - Monitor de Tarefa

  • Nenhum PTF ou Nível de Serviço necessário

FMID HAHD200 - Agente BuildForge

  • UK54097

O Web site do produto relacionado é:

http://www-01.ibm.com/software/awdtools/rtcz/
Nota:
O Rational Team Concert Server v 1.0 ou Rational Team Concert para System z Server v 1.0.1 fornece suporte seletivo para algumas funções do Developer para System z, como projetos locais. Recomendamos o Rational Team Concert para System z Server v 2.0.0.2 para uma experiência mais integrada e com todos os recursos

File Manager

Para suportar a integração do File Manager, um dos seguintes níveis deve ser instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-U29 IBM File Manager para z/OS v 10.1
  • UK54428

O Web site do produto relacionado é:

http://www.ibm.com/software/awdtools/filemanager/

Fault Analyzer

Para suportar a integração do Fault Analyzer, os seguintes níveis devem estar instalados no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5655-V51 IBM Fault Analyzer v 10.1 Nenhum PTF ou Nível de Serviço necessário
5655-U28 IBM Fault Analyzer v 9.1 Nenhum PTF ou Nível de Serviço necessário
5655-S15 IBM Fault Analyzer v 8.1 Nenhum PTF ou Nível de Serviço necessário

O Web site do produto relacionado é:

http://www.ibm.com/software/awdtools/faultanalyzer/

REXX

Para usar o SCLM Developer Toolkit, um dos seguintes níveis deve estar instalado no host:

Número do Programa Nome do Produto PTFs ou Níveis de Serviço Necessários
5695-014 IBM Library para REXX no zSeries v 1.4 Nenhum PTF ou Nível de Serviço necessário
5695-014 IBM Library para REXX no zSeries Alternate Library v 1.4.0 (FMIDs HWJ9143, JWJ9144) Nenhum PTF ou Nível de Serviço necessário

Uma versão do REXX/370 Alternate Library está disponível no Web site do produto:

http://www.ibm.com/software/awdtools/rexx/rexxzseries/

Ported tools

O IBM Ported Tools para z/OS deve ser instalado (no z/OS UNIX) para utilizar o sftp ou scp para realizar uma implementação segura no SCLM Developer Toolkit.

Uma versão do IBM Ported Tools para z/OS está disponível no Web site do produto:

http://www-03.ibm.com/servers/eserver/zseries/zos/unix/port_tools.html

Ant

O Apache Ant deve ser instalado (no z/OS UNIX) para executar construções JAVA/J2EE no SCLM Developer Toolkit.

O Apache Ant é uma ferramenta de construção de software livre, baseada em Java, que você pode transferir por download no Web site do produto:

http://ant.apache.org/

Endevor®

O CA Endevor® Software Change Manager Release 12 deve ser instalado para o uso da Interface do Developer para System z para CA Endevor® SCM.

CA Endevor® SCM é um produto do CA. O Web site do produto relacionado é:

http://www.ca.com/us/products/product.aspx?ID=259

Bibliografia

Publicações Referenciadas

As publicações a seguir são referenciadas neste documento:

Tabela 52. Publicações Referenciadas
Título da publicação Número do pedido Referência Web site de referência
Java Diagnostic Guide SC34-6650 Java 5.0 http://www.ibm.com/developerworks/java/jdk/diagnosis/
Guia do Usuário do Java SDK and Runtime Environment / Java 5.0 http://www-03.ibm.com/servers/eserver/zseries/software/java/
Program Directory for IBM Rational Developer for System z GI11-8298 Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
Rational Developer for System z Common Access Repository Manager Developer's Guide SC23-7660 Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
Pré-requisitos do Rational Developer para System z S517-9092 Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
Iniciação Rápida da Configuração do Host do Rational Developer para System z GI11-9201 Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
Rational Developer for System z Host Planning Guide GI11-8296 Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
SCLM Developer Toolkit: Guia do Administrador SC23-9801 Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
APPC and WebSphere Developer for System z SC23-5885 Whitepaper http://www-306.ibm.com/software/awdtools/rdz/library/
Communications Server IP Configuration Guide SC31-8775 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server IP Configuration Reference SC31-8776 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server IP Diagnosis Guide GC31-8782 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server IP System Administrator's Commands SC31-8781 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server SNA Network Implementation Guide SC31-8777 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Communications Server SNA Operations SC31-8779 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Cryptographic Services System SSL Programming SC24-5901 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
DFSMS Macro Instructions for Data Sets SC26-7408 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
DFSMS Using Data Sets SC26-7410 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Language Environment Customization SA22-7564 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Language Environment Debugging Guide GA22-7560 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Initialization and Tuning Guide SA22-7591 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Initialization and Tuning Reference SA22-7592 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS JCL Reference SA22-7597 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Planning APPC/MVS Management SA22-7599 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS Planning Workload Management SA22-7602 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
MVS System Commands SA22-7627 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Security Server RACF Command Language Reference SA22-7687 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Security Server RACF Security Administrator's Guide SA22-7683 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
Customização de TSO/E SA22-7783 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
TSO/E REXX Reference SA22-7790 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
UNIX System Services Command Reference SA22-7802 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
UNIX System Services Planning GA22-7800 z/OS 1.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
UNIX System Services User's Guide SA22-7801 z/OS 1.9 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.9 http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/
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
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
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 53. Web Sites Referidos
Descrição Web site de referência
Centro de Informações do Developer para System z http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp
Suporte do Developer para System z http://www-306.ibm.com/software/awdtools/rdz/support/
Biblioteca do Developer para System z http://www-306.ibm.com/software/awdtools/rdz/library/
Página Inicial do Developer para System z http://www-306.ibm.com/software/awdtools/rdz/
Serviço recomendado para o Developer para System z http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335
Pedido de aprimoramento para o Developer para 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
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 para os componentes do host necessários:

Tabela 54. Publicações Informativas
Título da publicação Número do pedido Referência Web site 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/

Glossário

A

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.

B

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 usada para conter temporariamente informações de saída de erro.

C

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.

D

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.

G

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.

I

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.

L

Lista de Tarefas
Uma lista de procedimentos que podem ser executados por um único fluxo de controle.

N

Não-isomórfico
Um mapeamento simples de itens COBOL e de elementos XML que pertencem a documentos XML e a grupos COBOL que não são idênticos na forma (não-isomórficos). 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.

P

Pedido de Construção
Um pedido do cliente para executar uma transação de construção.
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.

R

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 fonte 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.

S

Script da Shell
Um arquivo que contém comandos que podem ser interpretados pela 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 fonte.
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.

T

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.

U

URL
Uniform Resource Locator

V

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.
Visualização Console de Saída
Exibe a saída de um processo e permite fornecer entrada do teclado a um processo.

Notas de Documentação para IBM Rational Developer para System z

© Copyright IBM Corporation - 2010

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

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ças com relação a informações sobre 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:

Licença de Propriedade Intelectual
Lei de Propriedade Legal e Intelectual
IBM Japan, Ltd.
3-2-12, Roppongi, Minato-ku, Tokyo 106-8711 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 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 explícitas ou implícitas em determinadas transações; portanto, esta 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 a qualquer momento sem aviso prévio.

Referências nestas informações a Web sites que não sejam da IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a estes Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é 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 Rational Software
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 de Licença de Programa Internacional IBM ou de qualquer outro contrato equivalente.

Quaisquer dados de desempenho contidos aqui foram determinados em ambientes controlados. Portanto, os resultados obtidos em outros ambientes operacionais poderão 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 as mesmas em sistemas disponíveis em geral. Além disso, algumas medidas podem ter sido estimadas através de extrapolação. Os resultados reais podem ser diferentes. Os usuários deste documento devem verificar os dados aplicáveis para o 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 contêm exemplos de dados e relatórios usados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança a esses nomes e endereços usados por uma empresa comercial real é mera coincidência.

Licença de Copyright

Essas informações contêm programas de exemplos aplicativos 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 completamente testados em todas as condições. Portanto, a IBM não pode garantir ou implicar confiabilidade, manutenção, ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de qualquer tipo. A IBM não será responsabilizada por qualquer 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árias jurisdições no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual das marcas registradas da IBM está disponível na Web em www.ibm.com/legal/copytrade.shtml.

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 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 da The Open Group nos Estados Unidos e/ou em outros países.

Índice Remissivo

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