IBM Rational IBM Rational Developer para System z

Guia de Configuração do Host

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:

• IBM Rational Developer para System z é chamado Developer para System z.
• Common Access Repository Manager é abreviado para CARMA.
• Software Configuration and Library Manager Developer Toolkit é chamado SCLM Developer Toolkit, abreviado como SCLMDT.
• O z/OS UNIX® System Services é chamado de z/OS UNIX.
• O Customer Information Control System Transaction Server é chamado de CICSTS, abreviado como CICS.

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:

• Correções e informações adicionais apresentadas nas Notas sobre o Release de Configuração do Host do Rational Developer para System z v7.6 estão incorporadas.
• Notas de migração específicas da versão 7.6.1. Consulte o Notas de Migração da Versão 7.6.1.
• Visão geral do documento incluído. Consulte o Descrição do Conteúdo do Documento.
• Suporte para Java Java™. Consulte o Apêndice E. Requisitos.
• Configuração do produto através de painéis ISPF. Consulte o Considerações de Pré-configuração.
• Novas diretivas no rsed.envvars. Consulte o Arquivo de Configuração do RSE rsed.envvars.
• Novos membros proclib. Consulte o Procedimentos de Construção Remota ELAXF*.
• Novo layout VSAM do CARMA. Consulte o Notas de Migração VSAM do CARMA.
• Suportar múltiplos RAMs do CARMA. Consulte o (Opcional) Suportando Múltiplos RAMs.
• Novas opções do Application Deployment Manager. Consulte o Administrative Utility.
• Novo layout VSAM do Application Deployment Manager. Consulte o Notas de Migração do Utilitário Administrativo
• Novos comandos do operador. Consulte o Comandos do Operador.
• Novas mensagens do console. Consulte o Mensagens do Console
• Informações sobre o Gerenciamento de Carga de Trabalho. Consulte o Considerações WLM.

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:

• Configuração de customização
• Alterações do PARMLIB
• alterações do PROCLIB
• Definições de segurança
• FEJJCNFG, arquivo de configuração do JES Job Monitor
• rsed.envvars, arquivo de configuração do RSE
• ISPF.conf, Arquivo de configuração do ISPF's TSO/ISPF Client Gateway

(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:

• O IBM CICS Explorer fornece uma infraestrutura baseada em Eclipse para visualizar e gerenciar recursos CICS e ativa maior integração entre as ferramentas CICS.
• O cliente e o servidor do CICS Resource Definition (CRD) fornecem as seguintes funções:
  • Editor do CICS Resource Definition
  • Permite que os desenvolvedores de aplicativos definam recursos CICS de forma limitada, controlada e segura.
  • Evita acesso no desenvolvimento do CICS a conjuntos de dados VSAM desautorizados ou incorretos, fornecendo ao administrador do CICS controle sobre o atributo físico do nome do conjunto de dados nas definições de Arquivo.
  • Diversos auxílios no desenvolvimento do CICS
  • Diversos auxílios no desenvolvimento de Serviço da Web do CICS

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

• procedimento armazenado do DB2
• Suporte de Enterprise Service Tools (EST)
• suporte à linguagem bidirecional do CICS
• IRZ de diagnóstico, mensagens de erro
• criptografia SSL do RSE
• rastreio RSE
• grupos de propriedades baseados no host
• Projetos Baseados em Host
• Integração do File Manager
• caracteres não editáveis
• Usando REXEC (ou SSH)
• transação APPC para o serviço TSO Commands
• limpeza da WORKAREA

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:

• Análise de log e de configuração usando FEKLOGS
• Arquivos de Log
• Arquivos de dump
• Rastreio
• Bits de permissão do z/OS UNIX
• Portas TCP/IP reservadas
• Tamanho do espaço de endereço
• Transação APPC e serviço TSO Commands
• Informações Variadas

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
• Considerações de Planejamento
• Considerações sobre Pré-Instalação
• Considerações de Pré-configuração
• Considerações sobre Pré-implementação
• Lista de Verificação do Cliente

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.

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 configuração atual do z/OS UNIX e de TCP/IP
• a disponibilidade de software obrigatório e de manutenção
• se os segmentos OMVS estão ou não definidos para usuários do Developer para System z
• a disponibilidade do usuário, que instalou com êxito o cliente, para testar a instalação e relatar quaisquer problemas que possam ocorrer

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.

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:

• O serviço TSO/ISPF Client Gateway do ISPF, que requer um nível mínimo de serviço do ISPF. Este é o método padrão usado nas amostras fornecidas.
• Uma transação APPC (como em releases pré-versão 7.1)

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:

• z/OS 1.8 ou superior
• ISPF APAR OA29489 (TSO/ISPF Client Gateway)
• Java 5.0 ou versão mais recente

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.

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.

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:

• Todos os usuários do Developer para System z devem ter acesso READ e EXECUTE aos diretórios Java.
• Todos os usuários do Developer para System z devem ter acesso READ, WRITE e EXECUTE ao diretório /tmp/.
• Ações remotas (baseadas em host) para subprojetos do z/OS UNIX requerem que a versão z/OS UNIX do REXEC ou SSH esteja ativada no host.

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:

• Acesso ao TSO (com um tamanho de região normal).
  Nota:
  Um tamanho de região grande é necessário para o ID do usuário que executa os IVPs (Programas de Verificação da Instalação), pois as funções exigem muita memória (como Java) serão executadas. Você deve definir o tamanho da região como 131072 kilobytes (128 megabytes) ou mais alto.
• Um segmento OMVS definido para o sistema de segurança (por exemplo, RACF), ambos para o ID do usuário e seu grupo padrão.
  • O campo HOME deve referir-se a um diretório inicial alocado para o usuário (com acesso READ, WRITE e EXECUTE).
  • O campo PROGRAM no segmento OMVS deve ser /bin/sh ou outro shell z/OS UNIX válido, como /bin/tcsh.
  • O campo ASSIZEMAX não deve ser definido, para esses padrões do sistema serão usados.
  • O ID do usuário não requer UID 0.

    Exemplo (comando LISTUSER userid NORACF OMVS):

    USER=userid
    
    OMVS INFORMATION
    ----------------
    UID= 0000003200
    HOME= /u/userid
    PROGRAM= /bin/sh
    CPUTIMEMAX= NONE
    ASSIZEMAX= NONE
    FILEPROCMAX= NONE
    PROCUSERMAX= NONE
    THREADSMAX= NONE
    MMAPAREAMAX= NONE

  • O grupo padrão do ID do usuário requer um GID.

    Exemplo (comando LISTGRP group NORACF OMVS):

    GROUP group
    
    OMVS INFORMATION
    ----------------
    GID= 0000003243

• Acesso READ e EXECUTE aos diretórios e arquivos de instalação e configuração do Developer para System z, padrão /usr/lpp/rdz/*, /etc/rdz/* e /var/rdz/*.
• Acesso READ, WRITE e EXECUTE ao diretório Developer para System z WORKAREA, padrão /var/rdz/WORKAREA.
• Acesso READ aos conjuntos de dados de instalação do Developer para System z, padrão FEK.SFEK*.

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.
• O Daemon de Bloqueio (LOCKD) fornece serviços de rastreamento para bloqueios de conjuntos de dados.
• 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 RSE consiste em 2 entidades lógicas:
  • O Daemon RSE (RSED), que gerencia a configuração da conexão e que é responsável pela execução em modo de servidor único.
  • Servidor RSE, que manipula pedidos individuais do cliente.

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

• Os mecanismos de segurança usados pelo JES Job Monitor dependem de os conjuntos de dados em que eles residem serem seguros. Isso significa que apenas os administradores de sistemas confiáveis deverão estar aptos a atualizarem as bibliotecas e os arquivos de configuração.

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

• Desde a versão 7.5, o daemon RSE não é mais um processo gerenciado pelo INETD, mas uma tarefa iniciada.
• Desde a versão 7.5, o servidor RSE utiliza um único modelo de servidor, enquanto em versões anteriores, cada conexão entre cliente e host tinha um servidor RSE privado.
• Diferentes níveis de segurança de comunicação são suportados pelo RSE:
  • A comunicação externa (cliente-host) pode ser limitada a portas especificadas. Esse recurso é desativado por padrão.
  • A comunicação externa (cliente-host) pode ser criptografada utilizando SSL. Esse recurso é desativado por padrão.
  • A verificação de Port Of Entry (POE) pode ser utilizada para permitir acesso apenas a endereços TCP/IP confiáveis. Esse recurso é desativado por padrão.
• O RSE também suporta vários métodos de autenticação de cliente:
  • ID do Usuário e Senha
  • ID do Usuário e Senha Única
  • Certificado X.509
• Os mecanismos de segurança usados pelo RSE dependem de o sistema de arquivo em que eles residem ser seguro. Isso significa que apenas os administradores de sistemas confiáveis deverão estar aptos a atualizarem as bibliotecas e os arquivos de configuração.

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.

• Daemon RSE para a configuração da comunicação de cliente-host (utilizando o protocolo tcp), porta padrão 4035.
• Servidor RSE para comunicação de cliente-host (utilizando o protocolo tcp). Por padrão, qualquer porta disponível é usada, mas isto pode ser limitado a um intervalo específico.

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:

• Usar um aplicativo do painel ISPF. Isto o guia através das etapas de customização requeridas e etapas de customização opcionais. Para obter informações adicionais, consulte a White Paper do Utilitário de Configuração do Host, disponível na biblioteca da Internet do Developer para System z, http://www-306.ibm.com/software/awdtools/rdz/library/.
• Usar o O Guia de Iniciação Rápida da Configuração do Host. Isso o guia através das etapas de customização requeridas. O escopo deste guia é limitado a uma configuração básica.
• Usar o Guia de Configuração do Host. Isso o guia através das etapas de customização requeridas e todas as etapas de customização opcionais. Todas as opções configuráveis são cobertas neste guia, incluindo alguns cenários não padrão

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.

• FEK.SFEKAUTH(*)
• FEK.SFEKLOAD(*)
• FEK.SFEKPROC(*)
• FEK.#CUST.PARMLIB(*)
• FEK.#CUST.PROCLIB(*)
• /usr/lpp/rdz/*
• /etc/rdz/*
• /var/rdz/* (apenas estrutura do diretório)
• partes opcionais:
  • FEK.SFEKLPA(*)
  • FEK.#CUST.CNTL(*)
  • definições, conjuntos de dados, arquivos e diretórios resultantes das tarefas de customização em FEK.#CUST.JCL

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.

   • Archive: cd /SYS1/usr/lpp/rdz; tar -cSf /u/userid/rdz.tar
   • Restore: cd /SYS2/usr/lpp/rdz; tar -xSf /u/userid/rdz.tar

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.

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:

• Conjunto de dados autorizado APF
• Várias atualizações PARMLIB
• Várias atualizações de software de segurança
• Várias portas TCP/IP para comunicação interna e de cliente-host

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:
   • FEJJCNFG, Arquivo de Configuração do JES Job Monitor
   • Arquivo de Configuração do RSE rsed.envvars
   • ISPF.conf, Arquivo de Configuração do TSO/ISPF Client Gateway do ISPF

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:

• Criar FEK.#CUST.PARMLIB e preenchê-lo com arquivos de configuração de amostra.
• Criar FEK.#CUST.PROCLIB e preenchê-lo com membros SYS1.PROCLIB de amostra.
• Criar FEK.#CUST.JCL e preenchê-lo com JCL de configuração de amostra.
• Criar FEK.#CUST.CNTL e preencher com scripts de inicialização do servidor de amostra.
• Criar FEK.#CUST.ASM e preenchê-lo com o código-fonte do assembler de amostra.
• Criar FEK.#CUST.COBOL e preenchê-lo com o código de origem do COBOL de amostra.
• Criar /etc/rdz/* e preencher com arquivos de configuração de amostra.
• Criar /var/rdz/* como diretórios de trabalho para várias funções do Developer para System z.

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:

• DISPLAY OMVS,O
• SETOMVS MAXASSIZE=2G
• SETOMVS MAXTHREADS=1500
• SETOMVS MAXTHREADTASKS=1500
• SETOMVS MAXPROCUSER=50

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:

• S RSED
• S LOCKD
• S JMON

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:

• SETPROG LPA,ADD,DSN=FEK.SFEKLPA

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:

• SETPROG APF,ADD,DSN=FEK.SFEKAUTH,SMS
• SETPROG APF,ADD,DSN=CEE.SCEERUN,VOL=volser
• SETPROG APF,ADD,DSN=CEE.SCEERUN2,VOL=volser
• SETPROG APF,ADD,DSN=REXX.V1R4M0.SEAGLPA,VOL=volser
• SETPROG APF,ADD,DSN=SYS1.LINKLIB,VOL=volser

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:

• Bibliotecas de carregamento do Developer para System z necessárias para funções do Developer para System z. Essas definições são descritas nesta seção.
• Bibliotecas de carregamento de requisitos necessárias para funções do Developer para System z. Essas definições são descritas em Definições de LINKLIST e LPA de Requisito.
• Bibliotecas de carregamento do Developer para System z necessárias por outros produtos. Essas definições são descritas em Definições LINKLIST para Outros Produtos.

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:

• o uso de STEPLIB no z/OS UNIX provoca um impacto negativo no desempenho.
• 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.

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:

• LNKLST ADD NAME(listname) DSNAME(FEK.SFEKAUTH) VOLUME(volser)
• LNKLST ADD NAME(listname) DSNAME(FEK.SFEKLOAD)

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:

• Biblioteca de carregamento do sistema
  • SYS1.LINKLIB
• Tempo de execução do Ambiente de Linguagem
  • CEE.SCEERUN
  • CEE.SCEERUN2
• Biblioteca de classes DLL do C++
  • CBC.SCLBDLL
• TSO/ISPF Client Gateway do ISPF
  • ISP.SISPLOAD
  • ISP.SISPLPA

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:

• Biblioteca de tempo de execução REXX (para o SCLM Developer Toolkit)
  • REXX.*.SEAGLPA
• Biblioteca de carregamento do sistema (para criptografia de SSL)
  • SYS1.SIEALNKE
• Biblioteca de carregamento TCP/IP (ao usar APPC para o serviço TSO Commands)
  • TCPIP.SEZALOAD

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:

• 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 incluídas na STEPLIB DD em uma JCL não são propagadas para os processos z/OS UNIX iniciados pela JCL.

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:

• 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 no STEPLIB.

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:

• O qualificador de alto nível da biblioteca de carregamento (autorizada), padrão FEK
• O arquivo de configuração do JES Job Monitor, padrão FEK.#CUST.PARMLIB(FEJJCNFG)

//*
//* 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
//*

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:

• A porta daemon do RSE, padrão 4035.
• O diretório inicial no qual o Developer para System z está instalado, padrão /usr/lpp/rdz.
• O local dos arquivos de configuração, padrão /etc/rdz

//*
//* 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
//*

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:

• O diretório inicial em que o Developer para System z está instalado, padrão /usr/lpp/rdz.
• O local dos arquivos de configuração, padrão /etc/rdz.
• O nível de detalhe de log inicial, padrão 1.

//*
//* 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
//*

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:

• Usar links simbólicos

  Os links simbólicos podem ser usados como abreviação de um nome de diretório longo. O comando de amostra z/OS UNIX a seguir define um link simbólico (/usr/lpp/rdz) para outro diretório (/long/directory/name/usr/lpp/rdz).

  ln -s /long/directory/name/usr/lpp/rdz /usr/lpp/rdz

• Usar STDIN

  Quando o campo PARM estiver vazio, BPXBATSL iniciará um shell z/OS UNIX e executará o script de shell fornecido pelo STDIN. Observe que STDIN deve ser um arquivo z/OS UNIX (alocado como ORDONLY) e que usar STDIN desativa o uso de variáveis PROC para a porta, etc. Observe também que o shell executará os scripts de logon de shell /etc/profile e $HOME/.profile.

  Para utilizar esse método, primeiro você deve atualizar a JCL de inicialização para corresponder a algo como a seguinte amostra:

  Figura 4. RSED - inicialização do daemon RSE alternativo

  //*
  //* RSE DAEMON - USING STDIN
  //*
  //RSED     PROC CNFG='/etc/rdz'
  //*
  //RSE      EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT
  //STDOUT   DD SYSOUT=*
  //STDERR   DD SYSOUT=*
  //STDIN    DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.stdin.sh'
  //STDENV   DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.envvars'
  //         PEND
  //*

  Segundo, você deve criar o script de shell (/etc/rdz/rsed.stdin.sh neste exemplo), que iniciará o daemon RSE. O conteúdo desse script será semelhante ao seguinte:

  Figura 5. rsed.stdin.sh - inicialização do daemon RSE alternativo

  /long/directory/name/usr/lpp/rdz/bin/rsed.sh 4035 /etc/rdz

  Nota:
  É recomendável alocar rsed.envvars para STDENV na JCL de inicialização do daemon, uma vez que isso define algumas diretivas do z/OS UNIX que ajudam a economizar recursos do sistema ao usar esse método de inicialização.

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.

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.

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.

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.

• Ativar configurações e classes de segurança
• Definir um segmento OMVS para usuários do Developer para System z
• Definir perfis do conjunto de dados
• Definir as tarefas iniciadas JMON, RSED e LOCKD
• Definir a segurança de comando do JES
• Definir RSE como um servidor z/OS UNIX seguro
• Definir bibliotecas controladas pelo programa MVS para RSE
• Definir segurança do aplicativo para RSE
• Definir suporte PassTicket para RSE
• Definir arquivos controlados pelo programa z/OS UNIX para RSE

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.

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.

• CONSOLE_NAME deve ser um nome de console que consiste em 2 a 8 caracteres alfanuméricos ou em '&SYSUID' (sem as aspas).
• Se um nome de console for especificado, um único console com esse nome é usado para todos os usuários. Se o console com esse nome estiver em uso, o comando emitido pelo cliente falhará.
• Se &SYSUID for especificado, o ID de usuário cliente será usado como o nome do console. Assim, um console diferente é usado para cada usuário. Se o console com esse nome estiver em uso (por exemplo, o usuário estiver usando o SDSF ULOG), o comando emitido pelo cliente pode falhar, dependendo da configuração de GEN_CONSOLE_NAME.

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.

#=============================================================
# (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 
#============================================================= 

# (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

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:

• O TSO/ISPF Client Gateway incluirá /WORKAREA ao caminho especificado em _CMDSERV_WORK_HOME. Não o inclua você próprio.
• Se você não usar a tarefa de amostra SFEKSAMP(FEKSETUP) para construir o ambiente customizável, então deverá verificar se o diretório WORKAREA existe no caminho especificado em _CMDSERV_WORK_HOME. Os bits de permissão do diretório devem ser 777.

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:

• LOW - A validação do certificado não falhará se o servidor LDAP não puder ser contatado.
• MEDIUM - A validação do certificado requer que o servidor LDAP possa ser contatado, mas não requer que uma CRL seja definida. Esse é o padrão
• HIGH - A validação do certificado requer que o servidor LDAP possa ser contatado e que uma CRL seja definida.

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.

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

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.

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:

• &SYSUID, para substituir o ID do usuário do desenvolvedor
• &SYSPREF, para substituir o prefixo TSO do desenvolvedor

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.

* 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

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:

• (Opcional) CARMA (Common Access Repository Manager)
• (Opcional) Application Deployment Manager
• (Opcional) SCLM Developer Toolkit
• (Opcional) Procedimento Armazenado do DB2
• (Opcional) Suporte de Idioma Bidirecional do CICS
• (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)
• (Opcional) Transação APPC para o Serviço de Comandos TSO
• (Opcional) Limpeza de WORKAREA

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.

• O método de "submissão em lote" inicia o servidor CARMA enviando uma tarefa. Esse é o método padrão usado nos arquivos de configuração de amostra fornecidos. O benefício desse método é que os logs do CARMA são facilmente acessados na saída de tarefas. Ele também permite o uso de JCL de servidor customizado para cada desenvolvedor, que é mantido pelo próprio desenvolvedor. Entretanto, esse método utiliza um iniciador de JES por desenvolvedor que iniciar um servidor CARMA.
• O método "CRASTART" inicia o servidor CARMA como uma subtarefa dentro do RSE. Ele fornece uma configuração bastante flexível utilizando um arquivo de configuração separado, que define alocações de conjuntos de dados, e chamadas de programas necessárias para iniciar um servidor CARMA. Esse método fornece o melhor desempenho e utiliza o mínimo de recursos, mas requer que o módulo CRASTART esteja localizado no LPA.
• O método "TSO/ISPF Client Gateway" usa o TSO/ISPF Client Gateway do ISPF para criar um ambiente TSO ou ISPF, no qual o servidor CARMA é iniciado. Ele permite alocações de conjuntos de dados flexíveis utilizando as possibilidades do ISPF.conf. Entretanto, esse método não é adequado para acessar SCMs que interferem em operações normais do TSO ou ISPF.

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:

• Intervalo de portas TCP/IP para comunicação interna
• regra de segurança para permitir que os desenvolvedores atualizem para arquivos CARMA VSAM
• (Opcional) Regra de segurança para permitir que usuários enviem tarefas CRA*
• (opcional) Atualização de LPA

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:
   • Inicialização do Servidor CARMA Usando Submissão em Lote
   • (Opcional) Inicialização Alternativa do Servidor CARMA Utilizando CRASTART
   • (Opcional) Inicialização Alternativa do Servidor CARMA Usando TSO/ISPF Client Gateway
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.

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.

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.

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.

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

• *CRASTART indica que o servidor CARMA deve ser iniciado como uma subtarefa dentro do RSE utilizando CRASTART. Consulte (Opcional) Inicialização Alternativa do Servidor CARMA Utilizando CRASTART para obter mais detalhes. Se você especificar *CRASTART, será necessário especificar também as diretivas crastart.*.
• *ISPF indica que o servidor CARMA deve ser iniciado utilizando o TSO/ISPF Client Gateway do ISPF. Consulte o (Opcional) Inicialização Alternativa do Servidor CARMA Usando TSO/ISPF Client Gateway para obter mais detalhes.
• Qualquer outro valor define o local de CRASUBMT CLIST, utilizando convenções de nomenclatura ao estilo TSO. Com aspas ('), o nome do conjunto de dados é uma referência absoluta, sem aspas ('), o nome do conjunto de dados é prefixado com o ID do usuário do cliente, e não com o prefixo do TSO. Esse último requer que todos os usuários do CARMA mantenham seu próprio CRASUBMT CLIST.

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.

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.

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)

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

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.

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

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.

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.

• Inclua os conjuntos de dados alocados para a concatenação STEPLIB do procedimento CRASUBMT para a instrução TASKLIB em crastart.conf.
• Crie entradas para os DDs obrigatórios CRADEF, CRAMSG e CRSTRS do VSAM do CARMA. Use os nomes de conjuntos de dados fornecidos no procedimento CRASUBMT (customizado).
• Inclua qualquer instrução DD customizada e as concatenações de conjuntos de dados relacionadas, disponíveis no procedimento CRASUBMT (customizado). Por exemplo, inclua a instrução CRARAM1 DD e o nome do conjunto de dados, caso utilize a amostra PDS RAM. Observe que você pode utilizar nomes de conjuntos de dados (alocados com DISP=SHR), SYSOUT e constructos DUMMY.
• Opcionalmente, inclua qualquer comando BPXWDYN utilizando a instrução -COMMAND. Pode haver várias instruções -COMMAND. BPXWDYN permite que você faça alocações mais complexas, incluindo a criação de conjuntos de dados temporários, disposições diferentes de SHR, alocações para outros subsistemas, etc. Consulte Usando REXX e os Serviços do Sistema z/OS UNIX (SA22-7806) para obter informações adicionais do BPXWDYN.
• Selecione o método de chamada de programa desejado utilizando a instrução PROGRAM. O método recomendado é "PROGRAM=IKJEFT01 CRASERV &CRAPRM1. &CRAPRM2.", já que ele fornece um ambiente TSO que pode manipular uma combinação de conjuntos de dados APF e não-APF. Consulte a amostra crastart.conf para conhecer outros métodos.

* 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:

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

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.

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.

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.

• Forneça os nomes corretos para os conjuntos de dados do ISPF obrigatórios (entretanto, não aloque ISPPROF, ele é alocado dinamicamente).
• Anexe o proclib do Developer para System z, FEK.SFEKPROC, à instrução SYSPROC ou SYSEXEC, para que o CRASRVI exec possa ser localizado pelo sistema. Esse exec inicia o servidor CARMA (e, assim, substitui a SYSTSIN DD do CRASUBMT).
• Inclua a concatenação DD STEPLIB do procedimento CRASUBMT na instrução ispllib.
• Crie entradas obrigatórias para as DDs CRADEF, CRAMSG e CRSTRS do VSAM do CARMA. Use os nomes de conjuntos de dados fornecidos no procedimento CRASUBMT (customizado).
• Inclua qualquer instrução DD e a concatenação do conjunto de dados relacionado, disponível no procedimento CRASUBMT (customizado. Por exemplo, inclua a instrução CRARAM1 DD e o nome do conjunto de dados, caso utilize a amostra PDS RAM. Observe que você pode utilizar apenas os nomes de conjuntos de dados (alocados com DISP=SHR).
• Opcionalmente, remova o comentário e customize a diretiva allocexec para fazer alocações adicionais utilizando um exec.

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

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

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.

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.

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.

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:

• Intervalo de portas TCP/IP para comunicação interna
• (Opcional) Regra de segurança para permitir que usuários enviem tarefas CRA*
• (opcional) Atualização de LPA

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:
   • Inicialização do CA Endevor® SCM RAM Usando Submissão em Lote
   • Inicialização do CA Endevor® SCM RAM Usando CRASTART
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.

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.

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.

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)

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.

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.

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

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.

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.

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.

(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:

• FEK.SFEKVSM2(CRA0VCAD) - definições CRADEF
• FEK.SFEKVSM2(CRA0VCAS) - definições CRASTRS
• /etc/rdz/crastart.endevor.conf - arquivo de configuração CRASTART

Definições para o PDS RAM:

• FEK.SFEKVSM2(CRA0VDEF) - definições CRADEF
• FEK.SFEKVSM2(CRA0VSTR) - definições CRASTRS
• FEK.#CUST.CRARAM1 - definições CRARAM1

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:
   • DD CRARAM1, vinculado ao FEK.#CUST.CRARAM1
   • Ambiente TSO

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.)
   
   • IKJEFT01: TSO, usado para permitir certas chamadas autorizadas em um ambiente não autorizado e usado como ambiente para executar o executável de pré-alocação SCM RAM do CA Endevor®.
   • Executável de pré-alocação SCM RAM do %CRANDVRA: CA Endevor® (localizado em FEK.SFEKPROC), que aloca conjuntos de dados de trabalho específicos de usuário temporários (e permanentes).
   • NDVRC1: backend do CA Endevor® que possui uma construção no mecanismo para executar comandos TSO and ISPF.
   • PGM(CRASERV): comando para iniciar um servidor CARMA, no formato de comando ISPF
   • PARM(&CRAPRM1. &CRAPRM2.): parâmetros para CRASERV, no formato de comando ISPF. &CRAPRM1 é a porta para ser usada e &CRAPRM2 é o valor de tempo limite.

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:

• Enterprise Service Tools (EST)
• BMS Screen Designer
• MFS Screen Designer
• Geração de Código CICSTS

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:

• Consultas de recursos do CICS
• Pedidos de instalação e de desinstalação da definição de recursos do CICS nos dois ambientes CICSplex SM e não-CICSplex SM
• Pedidos de phase-in do conjunto de mapas e programa
• Pedidos de varredura de pipeline
• Pedidos de exportação, importação e atualização de manifesto

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:

• Porta TCP/IP para comunicação externa
• Atualização de JCL da região CICS
• Atualização de CSD da região CICS
• Definição de grupo para a região CICS
• Regra de segurança para permitir que administradores atualizem um VSAM do Application Deployment Manager
• Configuração de segurança do CICSTS
• (Opcional) Definição de nomes da transação CICS
• (Opcional) Regra de segurança para permitir que usuários atualizem um VSAM do Application Deployment Manager

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.
   • Defina o servidor CRD como a região de conexão primária do CICS
   • Defina, opcionalmente, o servidor CRD para as regiões de conexão não-primárias do CICS.
   • Opcionalmente, customize os IDs de transação do servidor CRD.
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.
   • Inclua o manipulador de mensagens do pipeline (possivelmente customizados) na concatenação RPL do CICS.
   • Defina o servidor CRD para a região de conexão primária do CICS.
   • Defina, opcionalmente, o servidor CRD para as regiões de conexão não-primárias do CICS.
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.

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.

• Coloque os módulos de carregamento FEK.SFEKLOAD(ADNCRD*, ADNANAL e ADNREST) na concatenação RPL do CICS (instrução DD DFHRPL) da região de conexão primária do CICS. É recomendável fazer isso incluindo o conjunto de dados da instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.
• Customize e envie a tarefa ADNCSDRS para atualizar a CSD (CICS System Definition) para a região de conexão primária do CICS. Consulte a documentação no membro para obter instruções de customização.

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

• Use o comando CEDA apropriado para instalar o grupo do Application Deployment Manager para essa região, por exemplo:

  CEDA INSTALL GROUP(ADNPCRGP)

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

• Coloque o módulo de carregamento do Application Deployment Manager FEK.SFEKLOAD(ADNCRD*) na concatenação RPL do CICS (instrução DD DFHRPL) dessas regiões de conexão não-primária. É recomendável fazer isso incluindo o conjunto de dados da instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.
• Customize e envie a tarefa ADNCSDAR para atualizar a CSD dessas regiões de conexão não-primária. Consulte a documentação no membro para obter instruções de customização.

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

• Use o comando CEDA apropriado para instalar o grupo do Application Deployment Manager para essas regiões, por exemplo:

  CEDA INSTALL GROUP(ADNARRGP)

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

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.

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:

Utilizando o padrão:

• Coloque o módulo de carregamento FEK.SFEKLOAD(ADNTMSGH) na concatenação RPL do CICS (instrução DD DFHRPL) da região de conexão primária do CICS. É recomendável fazer isso incluindo o conjunto de dados da instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.

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.

• Customize o código de origem do Manipulador de Mensagens do Pipeline (COBOL) da amostra, FEK.#CUST.COBOL(ADNMSGHS), para que ele corresponda aos padrões do seu site'.
• Customize e submeta a tarefa FEK.#CUST.JCL(ADNMSGHC) para compilar a origem customizada ADNMSGHS. Consulte a documentação dentro do ADNMSGHC para obter instruções de customização. Observe que o módulo de carregamento resultante deve receber o nome de ADNTMSGH.
• Coloque o módulo de carregamento ADNTMSGH resultante na concatenação RPL do CICS (instrução DD DFHRPL) da região de conexão primária do CICS.

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.

• Coloque os módulos de carregamento FEK.SFEKLOAD(ADNCRD*, ADNANAL e ADNREST) na concatenação RPL do CICS (instrução DD DFHRPL) da região de conexão primária do 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. Observe que o módulo de carregamento do manipulador de mensagens do pipeline, ADNTMSGH, também deve ser colocado na concatenação RPL, conforme descrito em Manipulador de Mensagens do Pipeline.
• Customize e envie a tarefa ADNCSDWS para atualizar a CSD (CICS System Definition) para a região de conexão primária do CICS. Consulte a documentação no membro para obter instruções de customização. Observe que os IDs de transação usados nesta tarefa devem corresponder àqueles usados pelo Manipulador de Mensagens do Pipeline (que podem ter sido customizados).

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

• Use o comando CEDA apropriado para instalar o grupo do Application Deployment Manager para essa região, por exemplo:

  CEDA INSTALL GROUP(ADNPCRGP)

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

• Coloque os módulos de carregamento do Application Deployment ManagerFEK.SFEKLOAD(ADNCRD*) na concatenação RPL do CICS (instrução DD DFHRPL) dessas regiões de conexão não-primária. É 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.
• Customize e envie a tarefa ADNCSDAR para atualizar a CSD dessas regiões de conexão não-primária. Consulte a documentação no membro para obter instruções de customização.

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

• Use o comando CEDA apropriado para instalar o grupo do Application Deployment Manager para essas regiões, por exemplo:

  CEDA INSTALL GROUP(ADNARRGP)

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

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:

• Atualizações de APF e LINKLIST
• Definir tradutores de idiomas SCLM para suporte JAVA/J2EE
• Definir tipos de SCLM para suporte JAVA/J2EE
• (Opcional) Regra de segurança para permitir que os usuários atualizem para um SCLM VSAM
• (opcional) Instalação de Ant

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:
   • Atualizações do ISPF.conf para SCLMDT
   • Atualizações do rsed.envvars para SCLMDT
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.

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

• (BPXPRMxx) Aumentar o número de processos por ID do usuário do z/OS UNIX.
• (PROGxx) Autorizar por APF SYS1.LINKLIB e o tempo de execução REXX, REXX.V1R4M0.SEAGLPA ou REXX.V1R4M0.SEAGALT.
• (PROGxx/LPALSTxx) Coloque ISP.SISPLPA, ISP.SISPLOAD, SYS1.LINKLIB e o tempo de execução do REXX em LINKLIST/LPALIB.

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:

• O SDSF deve ser ordenado, instalado e configurado separadamente. Também requer o uso do JES2.
• As configurações padrão do comando OUTPUT do TSO permitem que um usuário recupere a saída de tarefa que começa apenas com seu ID de usuário. Se você desejar usar o recurso OUTPUT completamente, poderá ser necessário modificar a saída do TSO/E de amostra IKJEFF53 para que um usuário possa recuperar a saída de tarefas que ele possui, mas que não começa com esse ID do usuário. Para obter informações adicionais sobre essa saída, consulte-o TSO/E Customization (SA22-7783).

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.

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.

* 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

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.

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.

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

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.

//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))
/*

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.

(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:

• Faça o download, em formato binário, do arquivo Ant compactado mais recente no sistema de arquivo z/OS UNIX. É recomendável fazer download da versão .zip do ANT devido aos problemas que podem ser encontrados no z/OS durante a extração de versões de formato com sufixo tar.gz ou tar.bz2.
• Abra uma sessão de linha de comandos z/OS UNIX para continuar a instalação, por exemplo, com o comando TSO OMVS.
• Crie um diretório inicial para a instalação de Ant com o comando mkdir -p /home-dir e torne-o seu diretório atual com o comando cd /home-dir.
• Use o comando de extração JAR jar -xf apache-ant-1.7.1.zip para extrair o arquivo para o diretório atual. Um diretório bin Java deverá estar em seu PATH z/OS UNIX local para usar o comando jar. Caso contrário, qualifique o comando com o local bin Java (por exemplo, /usr/lpp/java/J5.0/bin/jar -xf apache-ant-1.7.1.zip).
• Converta todos os arquivos de texto do Ant para EBCDIC (opcionalmente customizando e) executando o script de amostra /usr/lpp/rdz/samples/BWBTRANT.
  Nota:
  Execute esse script apenas uma vez. Várias execuções corromperão a instalação do Ant.
• Para verificar se a tradução foi bem-sucedida, localize e procure no arquivo de texto no diretório ANT, como apache-ant-1.7.1/README. Se o arquivo estiver legível, a conversão foi bem-sucedida.
• Use o comando chmod -R 755 * para permitir que todos os usuários READ e EXECUTE arquivos no diretório ANT.
• Antes de usar o Ant, configure as variáveis de ambiente rsed.envvars JAVA_HOME e ANT_HOME.
  • O JAVA_HOME é necessário para apontar o diretório inicial do Java, por exemplo:

    JAVA_HOME=/usr/lpp/java/IBM/J5.0

  • ANT_HOME deve apontar para o diretório home do Ant, por exemplo:

    ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1

Por exemplo:

• TSO OMVS
• mkdir -p /usr/lpp/Apache/Ant
• cd /usr/lpp/Apache/Ant
• jar -xf /u/userid/apache-ant-1.7.1
• /usr/lpp/rdz/samples/BWBTRANT
• cat ./apache-ant-1.7.1/README
• chmod -R 755 *
• oedit /etc/rsed.envvars

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

• Inclua os diretórios bin do Ant e do Java na variável de ambiente PATH.

  Exemplo:

  Exporte PATH=/usr/lpp/Apache/Ant/apache-ant-1.7.1/bin:$PATH
  exporte PATH=/usr/lpp/java/IBM/J5.0/bin:$PATH

• Execute ant -version para exibir a versão, se a instalação tiver sido bem-sucedida.

  Exemplo:

  ant -version

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:

• Definir tradutores de idiomas para suporte JAVA/J2EE
• Definir tipos de SCLM para suporte JAVA/J2EE

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.

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
• (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)
• (Opcional) Transação APPC para o Serviço de Comandos TSO
• (Opcional) Limpeza de WORKAREA

(Opcional) Procedimento Armazenado 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.

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.

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:

• O nome do ambiente de aplicativos definido no WLM para este Procedimento Armazenado
• O nome do subsistema do DB2
• O qualificador de alto nível de vários conjuntos de dados

//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))
//*

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.

//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;
//*

(Opcional) Suporte de Enterprise Service Tools (EST)

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:

• (Opcional) Application Deployment Manager
• (Opcional) Suporte de Idioma Bidirecional do CICS
• (Opcional) Mensagens de Erro IRZ de Diagnóstico

(Opcional) Suporte de Idioma Bidirecional do 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:

• O solicitante do serviço EST especifica de forma dinâmica os atributos bidirecionais das mensagens de interface.
• O processamento de dados bidirecional em fluxos de serviços tem como base atributos bidirecionais (tipo de texto, orientação de texto, troca numérica e troca simétrica). Esses atributos podem ser especificados em diferentes estágios da criação de fluxo para ambos os fluxos de interface e do terminal.
• O código de tempo de execução gerado pelo EST inclui a conversão dos dados entre os campos em mensagens que possuem atributos bidirecionais diferentes.

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

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:

• CICS
• IMS
• lote MVS

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

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.

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.

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

security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA

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

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.

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.

# 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

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.

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

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.

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

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

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.

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.

# 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

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.

# 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:

• 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 dados; não são permitidos comentários na mesma linha.
• Um asterisco (*) pode ser usado para HOST-CODEPAGE e/ou LOCAL-CODEPAGE. Ele atua como um curinga e representa todas as páginas de código.
• Entradas específicas têm precedência sobre as entradas genéricas (curinga).
• "host-cp *" tem precedência se "host-cp *" e "* local-cp" forem especificados e não forem substituídos por "host-cp local-cp".
• Se o mesmo par de páginas de códigos for especificado mais de uma vez, a última entrada será usada.

(Opcional) Usando REXEC (ou SSH)

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.

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:

• O diretório no qual o script de inicialização server.zseries está localizado.

  O server.zseries 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.

  Nota:
  Para desencorajar o uso do REXEC (ou SSH) como método de logon alternativo, o server.zseries não é mais copiado automaticamente para /etc/rdz. Se desejar usar esta função, você deve copiá-la manualmente a partir do /usr/lpp/rdz/bin, como mostrado no seguinte comando de amostra:

  cp /usr/lpp/rdz/bin/server.zseries /etc/rdz

• A porta que está sendo usada.

  Consulte o Configuração de REXEC (ou SSH) para saber qual porta é usada.

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.

• Localize o nome do serviço (1ª palavra, exec, neste exemplo) do servidor rexecd (7ª palavra) em /etc/inetd.conf.

  exec  stream tcp nowait OMVSKERN /usr/sbin/orexecd rexecd -LV

• Localize a porta (2ª palavra, 512, neste exemplo) conectada a este nome de serviço (1ª palavra) em /etc/services.

  exec      512/tcp      #REXEC   Command Server

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

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

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.

Preparação

• As tarefas a seguir são um pré-requisito e devem ser concluídas antes da configuração do Servidor de Comandos do TSO. As publicações mencionadas descrevem essas tarefas.
  1. Instale, configure e inicie o VTAM no sistema z/OS. Consulte Communications Server IP SNA Network Implementation Guide (SC31-8777) para obter informações adicionais.
  2. Instale, configure e inicie o TCP/IP no sistema z/OS. Consulte o Apêndice B. Configurando o TCP/IP para obter informações adicionais.
  3. Configure e inicie o APPC e o subsistema ASCH (planejador de transações APPC). Consulte o Apêndice D. Configurando o APPC para obter informações adicionais.
• A amostra REXX a seguir pode ser usada para gerenciar o APPC através de painéis ISPF.
  Figura 32. REXX para Painéis ISPF do APPC

  /* REXX -- administração APPC utilizando painéis ISPF */
  address ISPEXEC
  "LIBDEF ISPMLIB DATASET ID('ICQ.ICQMLIB') STACK"
  "LIBDEF ISPPLIB DATASET ID('ICQ.ICQPLIB') STACK"
  "LIBDEF ISPSLIB DATASET ID('ICQ.ICQSLIB') STACK"
  "LIBDEF ISPTLIB DATASET ID('ICQ.ICQTLIB') STACK"
  address TSO "ALTLIB ACT APPLICATION(CLIST)",
              "DSN('ICQ.ICQCCLIB') UNCOND QUIET"
  "SELECT CMD(%ICQASRM0) NEWAPPL(ICQ) PASSLIB"
  address TSO "ALTLIB DEACT APPLICATION(CLIST) QUIET"
  "LIBDEF ISPMLIB"
  "LIBDEF ISPPLIB"
  "LIBDEF ISPSLIB"
  "LIBDEF ISPTLIB"
  exit

  Nota:
  Lembre-se de que é possível desativar a transação APPC com esta ferramenta; a transação ainda está lá, mas não aceitará nenhuma conexão.
• A definição da transação APPC requer habilidades em diversas áreas do sistema operacional MVS. Consulte administradores experientes utilizando a seguinte lista de verificação antes de continuar.

  Tabela 16. Lista de verificação de transações APPC

  Experiência	Informações necessárias: Valor Padrão Onde encontrar a resposta	Valor
  APPC	Nome do conjunto de dados de TPDATA Padrão: SYS1.APPCTP O valor está listado em SYS1.PARMLIB(APPCPMxx)
  APPC	Nome da transação a ser usada (talvez não exista) Padrão: FEKFRSRV Transações existentes podem ser consultadas selecionando-se "Administração de Perfis TP" no menu ISPF APPC
  APPC	Classe de transação APPC a ser usada Padrão: A As classes APPC são definidas em SYS1.PARMLIB(ASCHPMxx)
  WLM/SRM	Grupo e domínio de desempenho do TSO Sem padrão IBM (dependente do site)
  RACF	Cada usuário do Developer para System z possui acesso a um segmento OMVS (isto é necessário) Sem padrão IBM (dependente do site) O comando RACF do TSO LU userid OMVS exibirá um segmento OMVS pessoal existente
  RACF	Cada usuário do Developer para System z deve ter acesso READ ao hlq.SFEKPROC(FEKFRSRV) Sem padrão IBM (dependente do site) O comando RACF do TSO LD AUTHUSER DATASET('hlq.SFEKPROC.**') exibirá usuários e grupos e seus níveis de acesso aos conjuntos de dados abrangidos pelo perfil do conjunto de dados

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

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

• 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. Para obter informações sobre a customização de TCP/IP e do Resolver, consulte Apêndice B. Configurando o TCP/IP e Instruções de Configuração de TCPIP.DATA em Communications Server IP Configuration Reference (SC31-8776).

  Você pode testar sua configuração TCP/IP iniciando o daemon RSE com o parâmetro IVP=IVP ou com o programa de verificação de instalação fekfivpt (IVP), conforme documentado no Verificação de Instalação .

• Com o uso de APPC para o serviço TSO Commands, o Developer para System z requer um soquete extra (porta TCP/IP) para a comunicação limitada pelo host por arquivo MVS aberto. Qualquer porta disponível será usada. Esse mecanismo de seleção de porta não pode ser alterado.
• Com o uso de APPC para o serviço TSO Commands, a leitura e a gravação de um conjunto de dados do MVS exige o uso de um domínio do sistema de arquivo 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. Consulte o Falhas ao Abrir Conjuntos de Dados MVS.
• Ao usar APPC para o serviço TSO Commands para evitar a configuração do TSO/ISPF Client Gateway do ISPF, lembre-se de que outros serviços, como o SCLM Developer Toolkit, contam com o TSO/ISPF Client Gateway.
• Consulte o Apêndice D. Configurando o APPC para obter as considerações gerais de uso de APPC

(Opcional) Limpeza de WORKAREA

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.

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.

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:

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

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) +++ 

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.

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

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

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

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

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

(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

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

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

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

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.

• 0 : Somente mensagens de erro do log.
• 1 : Mensagens de erro e de aviso do log (padrão).
• 2 : Mensagens de erro, aviso e informativas do log.

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

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

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.

Daemon de Bloqueio

Figura 38. Comando do operador MODIFY LOCKD

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.

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:

Operandos

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

• Os operandos obrigatórios são exibidos na linha de caminho principal:

  >>--REQUIRED_OPERAND--><

• Os operandos opcionais são exibidos abaixo da linha de caminho principal:

  >>-*------------------*-><
     *-OPTIONAL_OPERAND-*

• Os operandos padrão são exibidos acima da linha de caminho principal:

     *-DEFAULT_OPERAND-*
  >>-*-----------------*-><

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

• As palavras-chave são constantes que devem ser fornecidas. Se a palavra-chave aparecer no diagrama de sintaxe com letras maiúsculas e minúsculas, a parte de minúsculas será a abreviação para a palavra-chave (por exemplo, KEYword). As palavras-chave não fazem distinção entre maiúsculas e minúsculas. Você pode codificá-las em maiúsculas ou minúsculas.
• As variáveis estão em itálico, aparecem em letras minúsculas e representam nomes ou valores fornecidos. Por exemplo, um nome do conjunto de dados é uma variável. As variáveis podem fazer distinção entre maiúsculas e minúsculas.

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:

• Análise de Log e de Configuração Usando FEKLOGS
• Arquivos de Log
• Arquivos de Dump
• Rastreio
• Bits de Permissão do z/OS UNIX
• Portas TCP/IP Reservadas
• Tamanho do Espaço de Endereço
• Transação APPC e Serviço de Comandos do TSO
• Informações Diversas

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.

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:

• userlog/$LOGNAME/

  Os arquivos de log específicos do usuário estão localizados em userlog/$LOGNAME/, em que userlog é o valor combinado das diretivas user.log e DSTORE_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.

  • .dstoreMemLogging - Criação de log de uso de memória do armazenamento de dados
  • .dstoreTrace - Criação de log de ação do armazenamento de dados
  • fa.log - O log do Fault Analyzer Integration
  • fekfivpi.log - O log do teste IVP do fekfivpi
  • fekfivps.log - O log do teste IVP do fekfivps
  • ffs.log - O log do servidor Foreign File System (FFS), que executa funções MVS nativas
  • ffsget.log - O log do leitor de arquivos, que lê um conjunto de dados sequencial ou um membro PDS
  • ffsput.log - O log do gravador de arquivos, que grava um conjunto de dados sequencial ou um membro PDS
  • lock.log - O log do gerenciador de bloqueios, que bloqueia/desbloqueia um conjunto de dados sequencial ou um membro PDS
  • rmt_class_loader.cache.jar - O cache das classes carregadas pelo carregador da classe remota do RSE
  • rsecomm.log - O log do servidor RSE, que manipula os comandos do cliente e a criação de logs de comunicação de todos os serviços que dependem do RSE (pode conter rastreio de pilha de exceção Java)
  • stderr.log - Os dados direcionados da saída de erro padrão stderr
  • stdout.log - Os dados redirecionados de stdout, saída padrão
  Nota:
  O diretório .eclipse e os arquivos de log .dstore* começam com um ponto (.), o que os torna ocultos. Use o comando ls -lA do z/OS UNIX para listar arquivos e diretórios ocultos. Ao utilizar o cliente do Developer para System z, selecione a página de preferências Janela > Preferências... > Sistemas Remotos > Arquivos e ative "Mostrar Arquivos Ocultos".
• daemon-home

  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.

  • rsedaemon.log - O log do daemon RSE
  • rseserver.log - O log dos conjuntos de encadeamento RSE
  • audit.log - A trilha de auditoria do RSE
  • serverlogs.count - Contador para criação de log de fluxos do conjunto de encadeamento RSE
  • stderr.*.log - Fluxo de erro padrão do conjunto de encadeamento RSE
  • stdout.*.log - Fluxo de saída padrão do conjunto de encadeamento RSE

Criação de Logs do JES Job Monitor

• SYSOUT DD

  Criação de logs de operações normais. O valor padrão na amostra de JCL FEK.#CUST.PROCLIB(JMON) é SYSOUT=*.

• SYSPRINT DD

  Criação de logs de rastreio. O valor padrão na amostra de JCL FEK.#CUST.PROCLIB(JMON) é SYSOUT=*. O rastreio é ativado com o parâmetro -TV; consulte Rastreio do JES Job Monitor para obter mais detalhes.

Criação de Log do Daemon de Bloqueio

• STDOUT DD

  Os dados redirecionados de stdout, saída padrão Java. O valor padrão na amostra JCL FEK.#CUST.PROCLIB(LOCKD) é SYSOUT=*.

• STDERR DD

  Os dados redirecionados de stderr, saída de erro padrão Java. O valor padrão na amostra JCL FEK.#CUST.PROCLIB(LOCKD) é SYSOUT=*.

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

• STDOUT DD

  Os dados redirecionados de stdout, saída padrão Java de daemon RSE. O valor padrão no JCL da amostra FEK.#CUST.PROCLIB(RSED) é SYSOUT=*.

• STDERR DD

  Os dados redirecionados de stderr, saída de erro padrão Java do daemon RSE. O valor padrão no JCL da amostra FEK.#CUST.PROCLIB(RSED) é SYSOUT=*.

• daemon-home

  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.

  • rsedaemon.log - O log do daemon RSE
  • rseserver.log - O log dos conjuntos de encadeamento RSE
  • audit.log - A trilha de auditoria do RSE
  • serverlogs.count - Contador para criação de log de fluxos do conjunto de encadeamento RSE
  • stderr.*.log - Fluxo de erro padrão do conjunto de encadeamento RSE
  • stdout.*.log - Fluxo de saída padrão do conjunto de encadeamento RSE

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

• userlog/$LOGNAME/

  Há vários arquivos de log criados pelos componentes relacionados ao RSE. Todos estão localizados em userlog/$LOGNAME/, em que userlog é o valor combinado das diretivas user.log e DSTORE_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.

  • .dstoreMemLogging - Criação de log de uso de memória do armazenamento de dados
  • .dstoreTrace - Criação de log de ação do armazenamento de dados
  • ffs.log - O log do servidor Foreign File System (FFS), que executa funções MVS nativas
  • ffsget.log - O log do leitor de arquivos, que lê um conjunto de dados sequencial ou um membro PDS
  • ffsput.log - O log do gravador de arquivos, que grava um conjunto de dados sequencial ou um membro PDS
  • lock.log - O log do gerenciador de bloqueio, que bloqueia ou desbloqueia um conjunto de dados sequencial ou um membro PDS
  • rmt_class_loader.cache.jar - O cache das classes carregadas pelo carregador da classe remota do RSE
  • rsecomm.log - O log do servidor RSE, que manipula os comandos do cliente e a criação de logs de comunicação de todos os serviços que dependem do RSE (pode conter rastreio de pilha de exceção Java)
  • stderr.log - Os dados redirecionados de stderr, saída de erro padrão
  • stdout.log - Os dados redirecionados de stdout, saída padrão

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

• userlog/$LOGNAME/

  A criação de log do Fault Analyzer Integration, em que userlog é o valor combinado das diretivas user.log e DSTORE_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.

  • fa.log - O log do Fault Analyzer Integration
  • rsecomm.log - Criação de logs de comunicação do Fault Analyzer Integration

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

• userlog/$LOGNAME/rsecomm.log

  A criação de log de comunicação do File Manager Integration, em que userlog é o valor combinado das diretivas user.log e DSTORE_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.

Criação de Log do SCLM Developer Toolkit

• userlog/$LOGNAME/rsecomm.log

  A criação de log de comunicação do SCLM Developer Toolkit, em que userlog é o valor combinado das diretivas user.log and DSTORE_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.

Criação de Logs do CARMA

• Tarefa do Servidor CARMA

  Ao abrir uma conexão com o CARMA e usar a interface em lote, FEK.#CUST.SYSPROC(CRASUBMT) iniciará uma tarefa do servidor (com o ID do usuário como proprietário) denominada CRAport, em que port é a porta TCP/IP usada.

• CARMALOG DD

  Se a instrução DD CARMALOG for especificada no método de inicialização do CARMA escolhido, a criação de logs do CARMA será redirecionada para essa instrução DD na tarefa do servidor, caso contrário, ela irá para SYSPRINT.

• SYSPRINT DD

  O SYSPRINT da tarefa do servidor mantém a criação de log do CARMA, se o CARMALOG da instrução DD não estiver definido.

• userlog/$LOGNAME/rsecomm.log

  A criação de log de comunicação de CARMA, em que userlog é o valor combinado das diretivas user.log e DSTORE_LOG_DIRECTORY em rsed.envvars, e $LOGNAME é o DI 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.

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

• SYSPRINT DD

  Quando o utilitário de administração APPC inclui e modifica um perfil de programa de transação (TP), ele verifica o perfil TP e seu JCL em busca de erros de sintaxe. A saída desta fase consiste de mensagens de erro de sintaxe do perfil TP, mensagens do processamento do utilitário e instruções de conversão da JCL. A criação de logs para mensagens desta fase é controlada pela instrução SYSPRINT DD para o utilitário ATBSDFMU. O valor padrão na amostra de JCL FEK.SFEKSAMP(FEKAPPCC) é SYSOUT=*. Consulte MVS Planning: APPC/MVS Management (SA22-7599) para obter mais detalhes.

• &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG

  Quando um TP é executado, as mensagens de tempo de execução do TP, tais como mensagens de alocação e finalização, vão para um log nomeado pela palavra-chave MESSAGE_DATA_SET em seu perfil TP. O valor padrão na amostra de JCL FEK.SFEKSAMP(FEKAPPCC) é &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Consulte MVS Planning: APPC/MVS Management (SA22-7599) para obter mais detalhes.

  Nota:
  Dependendo das definições de transações e os padrões de site do APPC, este arquivo de log talvez não apareça, a menos que a palavra-chave KEEP_MESSAGE_LOG(ALWAYS) seja incluída nas definições de transações. Consulte MVS Planning: APPC/MVS Management (SA22-7599) para obter informações adicionais sobre isso.

Criação de Log de Teste IVP do fekfivpi

• userlog/$LOGNAME/fekfivpi.log

  Saída do comando fekfivpi -file (teste IVP relacionado ao TSO/ISPF Client Gateway), em que userlog é o valor combinado das diretivas user.log e DSTORE_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.

Criação de Log de Teste IVP do fekfivps

• userlog/$LOGNAME/fekfivps.log

  Saída do comando fekfivps -file (teste IVP relacionado ao SCLMDT), em que userlog é o valor combinado das diretivas user.log e DSTORE_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.

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):

• SYSABEND
• SYSMDUMP
• SYSUDUMP
• CEEDUMP
• SYSPRINT
• SYSOUT

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.

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.

• Iniciar a tarefa iniciada JMON com o parâmetro PRM=-TV ativa o modo detalhado (rastreio)
• Os comandos modify -TV e modify -TN ativam e desativam o rastreio

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.

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:

• Desativar Criação de Log
• Log de Erros
• Log de Avisos
• Log Informativo
• Log de Depuraçã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:

• /usr/lpp/rdz/bin/
  • fekfdivp
  • fekfomvs
  • fekfrivp
• /usr/lpp/rdz/lib/
  • fekfdir.dll
  • libfekdcore.so
  • libfekfmain.so
• /usr/lpp/rdz/lib/icuc/
  • libicudata.dll
  • libicudata40.1.dll
  • libicudata40.dll
  • libicudata64.40.1.dll
  • libicudata64.40.dll
  • libicudata64.dll
  • libicuuc.dll
  • libicuuc40.1.dll
  • libicuuc40.dll
  • libicuuc64.40.1.dll
  • libicuuc64.40.dll
  • libicuuc64.dll

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

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:

• /usr/lpp/rdz/bin/
  • fekfomvs
  • fekfrivp

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

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:

• /usr/lpp/rdz/bin/
  • BWBTSOW
  • CRASTART

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

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:

• PROFILE.TCPIP

  Esse é o conjunto de dados referido pela instrução PROFILE DD da tarefa iniciada do TCP/IP, muitas vezes chamado de SYS1.TCPPARMS(TCPPROF).

  • PORT: Reserva uma porta para nomes de tarefas especificados.
  • PORTRANGE: Reserva um intervalo de portas para nomes de tarefas especificados.

  Consulte Communications Server: IP Configuration Guide (SC31-8775) para obter informações adicionais sobre essas instruções.

• SYS1.PARMLIB(BPXPRMxx)
  • INADDRANYPORT: Especifica o número da porta inicial para o intervalo de números de portas que o sistema reserva para utilização com PORT 0, ligações INADDR_ANY. Esse valor é necessário somente para CINET (várias pilhas TCP/IP ativas em um único host).
  • INADDRANYCOUNT: Especifica o número de portas que o sistema reserva, iniciando com o número de porta especificado no parâmetro INADDRANYPORT. Esse valor é necessário somente para CINET (várias pilhas TCP/IP ativas em um único host).
  Consulte UNIX System Services Planning (GA22-7800) e MVS Initialization and Tuning Reference (SA22-7592) para obter informações adicionais sobre essas instruções.