Antes de usar este documento, leia as informações gerais em Notas de Documentação para IBM Rational Developer para System z.
Esta edição aplica-se ao IBM Rational Developer para System z Versão 7.6.1 (número do programa 5724-T07) e a todas modificações e releases subsequentes, até indicado de forma diferente em novas edições.
Solicite as publicações pelo telefone ou fax. O IBM Software Manufacturing Solutions recebe os pedidos de publicações entre 8h30 e 19h, horário padrão na costa leste dos Estados Unidos. O número de telefone é (800) 879-2755. O número de fax é (800) 445-9269. O fax deve ser enviado para: Publications, 3rd floor.
Você também pode solicitar as publicações através de um representante IBM ou da filial da IBM que atende em sua região. As publicações não são guardadas no endereço a seguir.
A IBM agradece pelo seu comentário. Você pode enviar os comentários pelo correio ao seguinte endereço:
É possível enviar um fax com os seus comentários para: 1-800-227-5088 (Estados Unidos e Canadá)
Ao enviar informações à IBM, você concede à IBM o direito não-exclusivo de utilizar ou distribuir as informações da forma que julgar apropriada, sem incorrer em qualquer obrigação para com o Cliente.
Nota sobre Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.
Este documento descreve a configuração das funções do IBM Rational Developer para System z. Ele inclui instruções sobre como configurar o IBM Rational Developer para System z Versão 7.6.1 em seu sistema host z/OS.
De agora em diante, os seguintes nomes serão usados neste manual:
Para releases anteriores, incluindo IBM WebSphere Developer para System z, IBM WebSphere Developer para zSeries e IBM® WebSphere Studio Enterprise Developer, use as informações de configuração encontradas no Guia de Configuração do Host e nos Diretórios de Programas desses releases.
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.
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:
Esta seção resume as informações apresentadas neste documento.
Use as informações deste capítulo para planejar a instalação e a implementação do Developer para System z.
As etapas de customização abaixo são para uma configuração básica do Developer para System z:
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.
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 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.
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.
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.
Este capítulo fornece uma visão geral dos comandos disponíveis do operador (ou console) para o Developer para System z.
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:
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.
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.
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.
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.
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.
Este capítulo contém informações úteis para um administrador do CICS Transaction Server.
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.
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.
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.
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.
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.
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.
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.
Este apêndice lista os pré-requisitos e co-requisitos do host para esta versão do Developer para System z.
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:
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.
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.
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.
O tempo necessário para instalar e configurar os componentes de host do Developer para System z depende de vários fatores, tais como:
A experiência tem mostrado que o processo de instalação e de configuração do host do Developer para System z exige de um a quatro dias para ser concluído. Esse requisito de tempo é para que uma instalação limpa seja executada por um programador de sistema experiente. Se ocorrerem problemas ou se as qualificações necessárias não estiverem disponíveis, então a configuração demorará mais tempo.
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.
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 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:
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.
Recurso | Valor Padrão | Informações |
---|---|---|
Conjunto de dados autorizado APF | FEK.SFEKAUTH | Autorizações APF em PROGxx |
tarefa iniciada | JMON, RSED e LOCKD | Considerações do Servidor |
porta para uso limitado por host | 6715 | FEJJCNFG, Arquivo de Configuração do JES Job Monitor |
porta para uso limitado por host | 4036 | Arquivo de Configuração do RSE rsed.envvars |
porta para comunicação cliente-host | 4035 | Alterações do PROCLIB |
intervalo de portas para comunicação cliente-host | qualquer porta disponível é usada | Definindo o PORTRANGE Disponível para o Servidor RSE |
Definição da segurança do aplicativo | Acesso universal de LEITURA para FEKAPPL | Definir Proteção de Aplicativo para RSE |
Definições de segurança PassTicket | nenhum padrão | Definir o Suporte PassTicket para o RSE |
Recurso | Valor Padrão | Informações |
---|---|---|
conjunto de dados LINKLIST | FEK.SFEKAUTH e FEK.SFEKLOAD | (Opcional) SCLM Developer Toolkit |
conjunto de dados LPA | FEK.SFEKLPA | (Opcional) CARMA (Common Access Repository Manager) |
intervalo de portas para uso confinado no host | 5227-5326 (100 portas) | (Opcional) CARMA (Common Access Repository Manager) |
portas para uso limitado por host | qualquer porta disponível é usada | (Opcional) Transação APPC para o Serviço de Comandos TSO |
porta para comunicação cliente-host | nenhum padrão | (Opcional) Application Deployment Manager |
atualização da CSD do CICS | diversos valores | (Opcional) Application Deployment Manager |
atualização do CICS JCL | FEK.SFEKLOAD |
A configuração do Developer para System z exige mais do que as permissões e o conhecimento típicos de programação de sistema, portanto, é possível que haja necessidade de uma mínima assistência de terceiros. A Tabela 3 e a Tabela 4 listam os administradores necessários para as tarefas de customização necessárias e opcionais.
Administrador | Tarefa | Informações |
---|---|---|
Sistema | Ações típicas do programador de sistema são necessárias para todas as tarefas de customização | N/D |
Security |
|
Considerações sobre Segurança |
TCP/IP | Definir novas portas TCP/IP | Portas TCP/IP |
WLM | Designar os objetivos da tarefa iniciada para os processos de servidores e seus filhos | Considerações WLM |
Administrador | Tarefa | Informações |
---|---|---|
Sistema | Ações típicas do programador de sistema são necessárias para todas as tarefas de customização | N/D |
Security |
|
|
TCP/IP | Definir novas portas TCP/IP | Portas TCP/IP |
SCLM |
|
(Opcional) SCLM Developer Toolkit |
CICS TS |
|
|
DB2 | Definir um procedimento armazenado do DB2 | (Opcional) Procedimento Armazenado do DB2 |
WLM |
|
|
APPC | Definir uma transação APPC | (Opcional) Transação APPC para o Serviço de Comandos TSO |
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.
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.
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:
O ID do usuário de um usuário do Developer para System z deve ter, pelo menos, os seguintes atributos:
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
Exemplo (comando LISTGRP group NORACF OMVS):
GROUP group OMVS INFORMATION ---------------- GID= 0000003243
O Developer para System z consiste em 3 servidores ativos permanentemente, que podem ser tarefas iniciadas ou tarefas do usuário. Esses servidores fornecem os serviços necessários entre si ou iniciam outros servidores (como encadeamentos z/OS UNIX ou tarefas do usuário) para fornecer o serviço.
O JES Job Monitor (JMON) fornece todos os serviços relacionados ao JES.
Explorador de Sistemas Remotos O (RSE) é o componente do Developer para System z que fornece serviços principais, como conectar o cliente ao host.
Conforme documentado no Portas TCP/IP, certos serviços do host, e suas portas, devem estar disponíveis para conexão com o cliente e devem ser definidos para seu firewall que protege o host. Todas as outras portas usadas pelo Developer para System z possuem tráfego apenas do host. A seguir há uma lista das portas necessárias para um configuração básica do Developer para System z.
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:
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.
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.
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 | Valor |
---|---|
Número da porta do servidor do JES Job Monitor (padrão 6715):
Consulte SERV_PORT em FEJJCNFG, Arquivo de Configuração do JES Job Monitor. |
|
Número da porta TCP/IP do daemon RSE (padrão 4035):
Consulte o Daemon RSE. |
Customização | Valor |
---|---|
Local dos procedimentos de ELAXF* se não estiverem em uma
biblioteca de procedimentos do sistema:
Consulte a nota sobre JCLLIB em Procedimentos de Construção Remota ELAXF*. |
|
Procedimento ou nomes de etapas dos procedimentos de ELAXF* se tiverem sido alterados:
Consulte a nota sobre a alteração deles em Procedimentos de Construção Remota ELAXF*. |
|
Nome do procedimento armazenado do DB2 (padrão ELAXMSAM):
Consulte informações sobre procedimentos armazenados do DB2 no Executando Várias Instâncias. |
|
Local do procedimento armazenado do DB2, se não estiver em uma biblioteca de
procedimentos do sistema:
Consulte o (Opcional) Procedimento Armazenado do DB2. |
|
(correquisito) Número da porta TN3270 para Emulador de Conexão do Host (padrão 23).
Consulte o Considerações sobre Segurança |
|
(correquisito) Número da porta REXEC ou SSH (padrão 512 ou 22,
respectivamente):
Consulte o (Opcional) Usando REXEC (ou SSH). |
|
Local do arquivo server.zseries
se o método de conexão REXEC/SSH for usado (padrão /etc/rdz).
Consulte o (Opcional) Usando REXEC (ou SSH). |
|
Local do CRA#ASLM JCL para alocações de conjuntos de dados SCLM
RAM do CARMA (padrão FEK.#CUST.JCL):
Consulte a nota sobre CRA#ASLM em Ativando o RAM do SCLM. |
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.
Você precisará da assistência de um administrador de segurança e de um administrador de TCP/IP para concluir essa tarefa de customização, que requer os seguintes recursos e tarefas de customização especiais:
Para verificar a instalação e começar a usar o Developer para System z no seu site, você deve executar as seguintes tarefas. A menos que especificado o contrário, todas as tarefas são obrigatórias.
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:
mkdir /usr/lpp/rdz/cust ln -s /usr/lpp/rdz/cust /etc/rdz
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.
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:
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:
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:
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:
Definições LINKLIST para o Developer para System z podem ser agrupadas em 3 categorias:
Para que o serviço SCLM Developer Toolkit (opcional) funcione, todos os módulos BWB* nas bibliotecas de carregamento FEK.SFEKAUTH e FEK.SFEKLOAD devem ser disponibilizados por meio do STEPLIB ou LINKLIST.
Se você optar por utilizar o STEPLIB, deverá definir as bibliotecas não disponíveis por meio do LINKLIST na diretiva STEPLIB de rsed.envvars, no arquivo de configuração do RSE. Porém, lembre-se de que:
Os conjuntos de dados LINKLIST são definidos em SYS1.PARMLIB(PROGxx), se seu site seguiu as recomendações da IBM.
As definições necessárias serão semelhantes às seguintes, em que listname é o nome do conjunto LINKLIST que será ativado e volser é o volume no qual o conjunto de dados residirá se não estiver catalogado no catálogo principal:
As definições de LINKLIST podem ser criadas dinamicamente (até o próximo IPL) com o seguinte grupo de comandos de console, em que listname é o nome do conjunto LINKLIST atual e volser é o volume no qual o conjunto de dados residirá se não estiver catalogado no catálogo principal:
Explorador de Sistemas Remotos (RSE) é um processo z/OS UNIX que requer acesso às bibliotecas de carregamento do MVS. As seguintes bibliotecas (pré-requisito) devem ser disponibilizadas, através de STEPLIB ou LINKLIST/LPALIB:
As seguintes bibliotecas adicionais devem ser disponibilizadas, por meio de STEPLIB ou de LINKLIST/LPALIB, para suportar o uso de serviços opcionais. Essa lista não inclui conjuntos de dados que são específicos para um produto com o qual o Developer para System z interage, como a Ferramenta de Depuração IBM:
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:
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:
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.
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:
//*
//* 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
//*
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:
//* //* 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 //*
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:
//* //* 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 //*
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:
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
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:
//* //* 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:
/long/directory/name/usr/lpp/rdz/bin/rsed.sh 4035 /etc/rdz
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.
Membro | Propósito |
---|---|
ELAXFADT | Procedimento de amostra para montagem e depuração de programas assembler de Alto Nível. |
ELAXFASM | Procedimento de amostra para montagem de programas assembler de alto nível. |
ELAXFBMS | Procedimento de amostra para criação do objeto BMS do CICS e a cópia correspondente, dsect, ou incluir membro. |
ELAXFCOC | Procedimento de amostra para realizar compilações COBOL, conversão do CICS integrado e conversão do DB2 integrado. |
ELAXFCOP | Procedimento de amostra para realizar o pré-processamento DB2 das instruções EXEC de SQL incorporadas em programas COBOL. |
ELAXFCOT | Procedimento de amostra para realizar a conversão do CICS de instruções EXEC CICS incorporadas nos programas COBOL. |
ELAXFCPC | Procedimento de amostra para realizar compilações C. |
ELAXFCPP | Procedimento de amostra para realizar compilações C++. |
ELAXFCP1 | Procedimento de amostra para compilações COBOL com instruções de pré-processador SCM (-INC e ++INCLUDE). |
ELAXFDCL | Procedimento de amostra para executar um programa no modo TSO. |
ELAXFGO | Procedimento de amostra para a etapa IR. |
ELAXFLNK | Procedimento de amostra para vincular os programas assembler C/C++, COBOL, PLI e de Alto Nível. |
ELAXFMFS | Procedimento de amostra para criar telas IMS MFS. |
ELAXFPLP | Procedimento de amostra para realizar o pré-processamento DB2 de instruções EXEC de SQL incorporadas nos programas PLI. |
ELAXFPLT | Procedimento de amostra para realizar a conversão do CICS das instruções EXEC CICS incorporadas nos programas PLI. |
ELAXFPL1 | Procedimento de amostra para realizar compilações PL/I, conversão do CICS integrado e conversão do DB2 integrado. |
ELAXFPP1 | Procedimento de amostra para compilações PL/I com instruções de pré-processador SCM (-INC e ++INCLUDE). |
ELAXFTSO | Procedimento de amostra para executar/depurar código do DB2 gerado no modo TSO. |
ELAXFUOP | Procedimento de amostra para a geração da etapa UOPT ao construir programas que executam nos subsistemas CICS ou IMS. |
Os nomes dos procedimentos e os nomes das etapas nos procedimentos correspondem às propriedades padrão que são fornecidas com o cliente Developer para System z. Se você decidir alterar o nome de um procedimento ou o nome de uma etapa em um procedimento, o arquivo de propriedades correspondente em todos os clientes também deverá ser atualizado. É recomendável que você não altere os nomes dos procedimentos e das etapas.
Customize os membros do procedimento de construção de amostra, FEK.#CUST.PROCLIB(ELAXF*), conforme descrito nos membros, e copie-os para SYS1.PROCLIB. Você deve fornecer os qualificadores de alto nível corretos para diferentes bibliotecas de produto, conforme descrito em Tabela 8.
Produto | HLQ Padrão | Valor |
---|---|---|
Developer para System z | FEK | |
CICS | CICSTS32.CICS | |
DB2 | DSN910 | |
IMS | IMS | |
COBOL | IGY.V4R1M0 | |
PL/I | IBMZ.V3R8M0 | |
C/C++ | CBC | |
LE | CEE | |
LINKLIB do sistema | SYS1 | |
MACLIB do sistema | SYS1 |
Se os procedimentos ELAXF* não puderem ser copiados para uma biblioteca de procedimentos de sistema, solicite aos usuários do Developer para System z incluírem uma placa JCLLIB (logo após a placa JOB) nas propriedades da tarefa no cliente.
//MYJOB JOB <parâmetros_da_tarefa> //PROCS JCLLIB ORDER=(FEK.#CUST.PROCLIB)
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.
Atenção: O pedido de conexão com o cliente
falhará se a segurança do aplicativo e os PassTickets não estiverem configurados corretamente. |
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)
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.
As definições a seguir são opcionais. Se omitidas, valores padrão serão usados conforme especificados abaixo:
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
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.
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".
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 |
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:
Informações adicionais podem ser localizadas no UNIX System Services Command Reference (SA22-7802).
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
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.
Notas:
As definições a seguir são necessárias se o SCLM Developer Toolkit for utilizado.
As definições a seguir são opcionais. Se forem omitidas, os valores padrão serão usados:
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 (:).
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:
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:
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:
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.
As diretivas a seguir são comentadas por padrão.
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).
As seguintes variáveis podem ser usadas no nome do conjunto de dados:
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
Por exemplo:
ISPTRACE=nullfile
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:
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.
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.
Você precisará da ajuda de um administrador de segurança e um administrador de TCP/IP para concluir esta tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
Para iniciar o uso do CARMA em seu site, é necessário executar as tarefas a seguir. A menos que especificado o contrário, todas as tarefas são obrigatórias.
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.
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.
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
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.
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.
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.
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)'
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)
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.
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
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.
* 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:
&CRAUSER. | ID do usuário de logon do cliente. |
&CRADATE. | Data atual no formato Dyyyyddd (7 caracteres do calendário juliano). |
&CRATIME. | Hora atual no formato Thhmmss (hora - minuto - segundo). |
&CRAPRM3. através de &CRAPRM9. |
Variáveis adicionais com valores designados pelo usuário. O uso destas variáveis requer a customização da inicialização do CARMA do REXX referenciado no startup.script.name em CRASRV.properties. Quando você usa estas variáveis, é recomendável customizar uma cópia do REXX de inicialização padrão, /usr/lpp/rdz/bin/carma.startup.rex e apontar startup.script.name para esta cópia. Isto é para evitar que você perca o seu trabalho quando a manutenção atualizar o REXX padrão. |
símbolo do sistema | Qualquer símbolo do sistema definido em SYS1.PARMLIB(IEASYMxx) |
-<DD> | Um traço (-) seguido de um nome DD definido anteriormente atua como uma referência anterior *.ddname na JCL. O DD original deve ser alocado utilizando a instrução -COMMAND. |
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.
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
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.
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'.
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.
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.
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.
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.
O IBM® Rational® Developer para System z Interface para CA Endevor ® Software Configuration Manager fornece aos clientes do Developer para System z acesso direto ao CA Endevor® SCM. A partir daqui, o IBM® Rational® Developer para System z Interface para CA Endevor® SCM é abreviado como CA Endevor® SCM RAM (Repository Access Manager).
Em contradição com os RAMs de amostras documentados nesta publicação, o CA Endevor® SCM RAM é um tipo de produção RAM. Você não deve ativar os dois tipos de RAM na mesma configuração.
Atenção: As tarefas de configuração fornecidas para CA Endevor® SCM RAM substituem a configuração do CARMA ativa por uma que somente suspende o CA Endevor® SCM RAM. |
Você precisa da assistência de um administrador de segurança e um administrador TCP/IP para completar esta tarefa de customização, que requer os seguintes recursos ou tarefas de customização especiais:
Para iniciar usando o CA Endevor® SCM RAM no seu site, você deve executar as seguintes tarefas. A menos que especificado o contrário, todas as tarefas são obrigatórias.
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.
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.
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)'
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)
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.
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
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.)
Os métodos de inicialização de submissão em lote e CRASTART invocam o executável REXX CRANDVRA para alocar os conjuntos de dados específicos de usuários pelo CA Endevor® SCM RAM.
DD | Nome do conjunto de dados | Tipo |
---|---|---|
DEPEND | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.DEPEND | Permanente |
BROWSE | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.BROWSE | Temporário |
C1PRINT | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.LISTING | Temporário |
Você pode customizar uma cópia deste executável REXX de alocação se certos padrões, como o nome do conjunto de dados, não corresponderem aos padrões do seu site. O CRANDVRA está localizado em FEK.SFEKPROC, a menos que você tenha usado um qualificador de alto nível diferente durante a instalação do SMP/E do Developer para System z.
Consulte a documentação dentro do CRANDVRA para obter instruções de customização.
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.
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.
No exemplo a seguir, você inicia a partir de uma configuração existente com o CA Endevor® SCM RAM, usando o método de inicialização CRASTART, e inclui o PDS RAM da amostra.
Definições para o CA Endevor® SCM RAM:
Definições para o PDS RAM:
O processo inicia com um desenvolvedor RAM reunindo os dados e informações necessários para programador de sistema completar a configuração.
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.
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.
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.
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.
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:
Customizar o Application Deployment Manager inclui o servidor CICS Resource Definition (CRD), que eé executado como um aplicativo do CICS no z/OS para suportar as seguintes funções:
Administradores do CICS podem localizar mais informações sobre o servidor CRD no Considerações sobre o CICSTS.
Você precisará da assistência de um administrador do CICS, um administrador de TCP/IP e um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
Para iniciar o uso do Application Deployment Manager em seu site, é necessário executar as tarefas a seguir. A menos que especificado o contrário, todas as tarefas são obrigatórias.
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.
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.
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.
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.
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.
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.
CEDA INSTALL GROUP(ADNPCRGP)
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).
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.
CEDA INSTALL GROUP(ADNARRGP)
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.
Transação | Descrição |
---|---|
ADMS | Para pedidos da ferramenta Processamento de Manifesto para alterar os recursos do CICS. Geralmente, isso é destinado aos administradores do CICS. |
ADMI | Para pedidos que definem, instalam ou desinstalam recursos do CICS. |
ADMR | Para todos os outros pedidos que recuperam informações ambientais ou sobre recursos do CICS. |
Você pode alterar os IDs da transação para que correspondam aos padrões do site seguinte estas etapas:
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.
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:
Transação | Descrição |
---|---|
ADMS | Para pedidos da ferramenta Processamento de Manifesto para alterar recursos do CICS. Geralmente, isso é destinado aos administradores do CICS. |
ADMI | Para pedidos que definam, instalem ou desinstalem recursos do CICS. |
ADMR | Para todos os outros pedidos que recuperam as informações de ambiente e de recurso do CICS. |
Utilizando o padrão:
Customizando ADNTMSGH:
Os membros de amostra ADNMSGH* estão localizados em FEK.#CUST.JCL e em FEK.#CUST.COBOL, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.
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.
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.
CEDA INSTALL GROUP(ADNPCRGP)
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).
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.
CEDA INSTALL GROUP(ADNARRGP)
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.
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.
Você precisará da assistência de um administrador de SCLM e, opcionalmente, de um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos e/ou tarefas de customização especiais:
Para iniciar o uso do SCLM Developer Toolkit em seu site, é necessário executar as tarefas a seguir. A menos que especificado o contrário, todas as tarefas são obrigatórias.
Consulte o Apêndice E. Requisitos para obter uma lista de manutenções necessárias do SCLM.
Esse apêndice documenta também as especificações Ant necessárias para construções JAVA/J2EE no SCLM Developer Toolkit.
Atenção: O SCLM Developer Toolkit requer o
uso do ISPF's TSO/ISPF Client Gateway, o que implica que o z/OS 1.8 ou superior
é necessário. |
Conforme descrito em Alterações PARMLIB, o SCLM Developer Toolkit requer customização adicional de configurações do sistema. Essas alterações incluem:
Além disso, o SCLM Developer Toolkit utiliza o SDSF ou o comando do TSO OUTPUT para recuperar o status de conclusão da tarefa e a saída de tarefas. Ambos os métodos requerem atenção adicional:
Os usuários precisam de permissão READ, WRITE e EXECUTE para os diretórios z/OS UNIX /tmp/ e /var/rdz/WORKAREA/. O diretório WORKAREA/ está localizado em /var/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.
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
ispslib=hlq.USERSKEL,ISP.SISPSLIB
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
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.
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)) /*
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.
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:
JAVA_HOME=/usr/lpp/java/IBM/J5.0
ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1
Por exemplo:
Para testar se a inicialização do Ant foi bem-sucedida:
Exemplo:
Exporte PATH=/usr/lpp/Apache/Ant/apache-ant-1.7.1/bin:$PATH exporte PATH=/usr/lpp/java/IBM/J5.0/bin:$PATH
Exemplo:
ant -version
O próprio SCLM também requer customização para funcionar com o SCLM Developer Toolkit. Consulte o IBM Rational Developer para System z SCLM Developer Toolkit Administrator's Guide (SC23-9801) para obter informações adicionais sobre as tarefas de customização necessárias:
Para concluir a customização e as tarefas de definição de projetos, o administrador de SCLM precisa conhecer vários valores customizáveis do Developer para System z, conforme descrito em Tabela 13.
Descrição |
|
Valor |
---|---|---|
Biblioteca de amostra do Developer para System z |
|
|
Diretório de amostra do Developer para System z |
|
|
Diretório bin Java |
|
|
Diretório bin Ant |
|
|
Diretório home WORKAREA |
|
|
Diretório home de configuração de projeto do SCLMDT |
|
|
VSAM de tradução de nomes longos/abreviados |
|
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.
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.
Você precisará da assistência de um administrador de WLM e de um administrador de DB2 para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
|
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.
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.
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:
//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)) //*
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; //*
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
O cliente do Developer para System z possui um componente de geração de códigos chamado Enterprise Service Tools (EST). Dependendo do tipo de código que está sendo gerado, esse código baseia-se nas funções fornecidas pela instalação do host do Developer para System z. Como tornar essas funções disponíveis está descrito nas seguintes seções:
Você precisará da assistência de um administrador do CICS para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
|
O componente EST (Enterprise Service Tools) do Developer para System z suporta formatos diferentes das mensagens de interface em árabe e hebraico, assim como a apresentação de dados bidirecionais e a edição em todos os editores e visualizações. Em aplicativos terminais, telas da esquerda para a direita e da direita para a esquerda são suportadas, assim como campos numéricos e campos com orientação oposta à tela.
A funcionalidade e os recursos bidirecionais adicionais incluem:
Além disso, o código gerado por EST pode suportar transformação bidi em ambientes diferentes do CICS SFR (Service Flow Runtime). Um exemplo são os aplicativos em lote. Você pode criar os geradores de EST para incluir chamadas nas rotinas de conversão bidirecional, especificando as opções de transformação bidirecional apropriadas nos assistentes de geração EST e vinculando os programas gerados com a biblioteca de conversão bidirecional apropriada, FEK.SFEKLOAD.
Execute as seguintes tarefas para ativar o suporte à linguagem bidirecional do CICS:
CEDA DEF PROG(FEJBDCMP) LANG(LE) G(xxx) CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Essa tarefa de customização não exige assistência, mas exige os seguintes recursos ou tarefas de customização especiais:
|
O cliente do Developer para System z possui um componente de geração de códigos chamado Enterprise Service Tools (EST). Para que o código gerado por EST emita mensagens de erro de diagnóstico, todos os módulos IRZ* e IIRZ* da biblioteca de carregamento FEK.SFEKLOAD devem ser disponibilizados por meio do código gerado. EST pode gerar códigos para os seguintes ambientes:
Quando o código gerado for executado em uma transação do CICS, então inclua todos os módulos IRZ* e IIRZ* no FEK.SFEKLOAD para o DFHRPL DD da região CICS. É recomendável fazer isso incluindo o conjunto de dados de instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.
Para todas as outras situações, torne todos os módulos IRZ* e IIRZ* no FEK.SFEKLOAD disponíveis por meio de STEPLIB ou LINKLIST. É recomendável fazer isso incluindo o conjunto de dados de instalação na concatenação para que a manutenção aplicada esteja automaticamente disponível ao CICS.
Se você decidir usar o STEPLIB, deverá definir os módulos não disponíveis por meio do LINKLIST na diretiva STEPLIB da tarefa que executa o código.
Se os módulos de carregamento não estiverem disponíveis e um erro for encontrado pelo código gerado, a seguinte mensagem será emitida:
IRZ9999S Falha ao recuperar o texto de uma mensagem de tempo de execução
do Ambiente de Linguagem. Verifique se o módulo de mensagem de tempo de execução do Ambiente de Linguagem do recurso IRZ está instalado em DFHRPL ou em STEPLIB.
Você precisará da assistência de um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
|
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.
Armazenamento de certificado | Criado e gerenciado por | Daemon RSE | servidor RSE |
---|---|---|---|
conjunto de chaves | Produto de segurança compatível com SAF | suportados | suportados |
banco de dados de chaves | gskkyman do z/OS UNIX | suportados | / |
keystore | keytool Java | / | suportados |
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.
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
O arquivo resultante será semelhante a este:
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA security.provider.2=com.ibm.jsse2.IBMJSSEProvider2 security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.security.sasl.IBMSASL
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
O Developer para System z suporta diferentes níveis de rastreio do fluxo do programa interno para propósitos de resolução de problemas. O RSE e alguns dos serviços chamados pelo RSE usam as configurações no rsecomm.properties para conhecer o nível desejado de detalhes nos logs de saída.
Atenção: A alteração destas configurações pode causar diminuição no desempenho e
deverá ser realizada somente sob a orientação do IBM Support Center. |
O rsecomm.properties está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT.
A amostra de código a seguir mostra o arquivo rsecomm.properties, que pode ser customizado para corresponder às suas necessidades de rastreio. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado; não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.
# 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
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. |
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.
|
Log_To_StdOut | Enviar mensagens de log para stdout.
|
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.
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
Os clientes do Developer para System z podem definir grupos de propriedades que contém valores padrão para várias propriedades (por exemplo, as opções do compilador COBOL a serem usadas durante a compilação do código de origem COBOL). O Developer para System z possui alguns valores padrão integrados, mas permite também a definição de padrões customizados, específicos do sistema.
O local dos arquivos de configuração do valor padrão e do grupo de propriedades customizadas é definido em propertiescfg.properties, que está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.
A amostra de código a seguir mostra o arquivo propertiescfg.properties, que deve ser customizado para corresponder ao seu ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado. Não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.
# # 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
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).
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
Os projetos do z/OS podem ser definidos individualmente por meio da perspectiva Projetos do z/OS no cliente ou podem ser definidos centralmente no host e propagados para o cliente com base no usuário. Esses "projetos baseados no host" parecem e funcionam exatamente como os projetos definidos no cliente, exceto pelo fato de que suas estruturas, membros e propriedades não podem ser modificados pelo cliente e são acessíveis apenas quando conectados ao host.
O local das definições de projeto é definido em projectcfg.properties, que está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas.
A amostra de código a seguir mostra o arquivo projectcfg.properties, que deve ser customizado para corresponder ao seu ambiente do sistema. Linhas de comentários são iniciadas com um sinal de sustenido (#) ao utilizar uma página de códigos US. As linhas de dados só podem ter uma diretiva e seu valor designado. Não são permitidos comentários na mesma linha. Continuações de linha não são suportadas.
# # 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
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.
Você precisará da assistência de um administrador de segurança para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
|
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
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
Alguns caracteres não são convertidos adequadamente entre as páginas de códigos do host (baseadas em EBCDIC) e as páginas de códigos do cliente (baseadas em ASCII). O editor do cliente Developer para System z utiliza as definições no arquivo uchars.settings para identificar esses caracteres não editáveis. Ao abrir um conjunto de dados com um caractere identificado em uchars.settings, o editor impingirá o modo somente leitura para evitar que o conjunto de dados seja corrompido quando ele for salvo.
O uchars.settings está localizado em /etc/rdz/, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes. É possível editar o arquivo com o comando do TSO OEDIT. Observe que o RSE deve ser reiniciado para que as alterações sejam efetivadas. Observe também que é recomendado não alterar esse arquivo, a menos que você seja orientado pelo centro de suporte da IBM.
# 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:
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
REXEC (Execução Remota) é um serviço TCP/IP para permitir que clientes executem um comando no host. O SSH (Secure Shell) é um serviço semelhante, mas aqui todas as comunicações são criptografadas utilizando o SSL (Secure Socket Layer). O Developer para System z usa qualquer serviço para executar ações remotas (baseadas em host) em subprojetos z/OS UNIX.
O Developer para System z também pode ser configurado para usar o REXEC (ou SSH) para iniciar um servidor RSE no host. Observe, no entanto, que cada conexão iniciada dessa forma resultará em um servidor RSE separado, cada um utilizando um quantidade razoável de recursos do sistema. Portanto, esse método de conexão alternativo é viável apenas para um pequeno número de conexões.
Além disso, como o método de conexão alternativa do REXEC (ou SSH) ignora o daemon RSE, ele não terá acesso a todos os serviços do host descritos nesta publicação, como processamento e auditoria de servidor único. Entre em contato com o suporte da IBM para saber se um serviço de host específico é suportado pelo método de conexão alternativo REXEC.
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.
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 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.
cp /usr/lpp/rdz/bin/server.zseries /etc/rdz
Consulte o Configuração de REXEC (ou SSH) para saber qual porta é usada.
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.
exec stream tcp nowait OMVSKERN /usr/sbin/orexecd rexecd -LV
exec 512/tcp #REXEC Command Server
O mesmo princípio aplica-se ao SSH. Sua porta comum é 22 e o nome do servidor é sshd.
Você precisará da assistência de um administrador de APPC e de um administrador de WLM para concluir essa tarefa de customização, que exige os seguintes recursos ou tarefas de customização especiais:
|
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.
/* 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
Experiência | Informações necessárias:
|
Valor |
---|---|---|
APPC | Nome do conjunto de dados de TPDATA
|
|
APPC | Nome da transação a ser usada (talvez não exista)
|
|
APPC | Classe de transação APPC a ser usada
|
|
WLM/SRM | Grupo e domínio de desempenho do TSO
|
|
RACF | Cada usuário do Developer para System z possui acesso a um
segmento OMVS (isto é necessário)
|
|
RACF | Cada usuário do Developer para System z deve ter acesso READ ao hlq.SFEKPROC(FEKFRSRV)
|
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.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
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 .
Esta tarefa de customização não requer assistência, recursos especiais ou tarefas de customização especiais. |
O TSO/ISPF Client Gateway do ISPF e a função SCLM Developer Toolkit usam o diretório WORKAREA para armazenar arquivos de trabalho temporários, que são removidos antes de a sessão ser fechada. Entretanto, a saída temporária é às vezes deixada para trás, por exemplo, se existir um erro de comunicação durante o processamento. Por essa razão, é recomendável limpar o diretório WORKAREA regularmente.
O z/OS UNIX fornece um script de shell, skulker, que exclui arquivos com base no diretório em que estão e em suas idades. Combinado com o daemon cron do z/OS UNIX, que executa comandos em datas e horas especificadas, você pode configurar uma ferramenta automatizada que limpe periodicamente o diretório WORKAREA. Consulte o UNIX System Services Command Reference (SA22-7802) para obter informações adicionais sobre o script skulker e o daemon cron.
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.
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.
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
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
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/.
fekfivpa | (Opcional) Conexão do Serviço TSO Commands Utilizando APPC |
fekfivpd | Conexão do Daemon RSE |
fekfivpi | Conexão do TSO/ISPF Client Gateway do ISPF |
fekfivpj | Conexão do JES Job Monitor |
fekfivpl | Conexão do Daemon de Bloqueio |
fekfivpr | (Opcional) Conexão REXEC |
fekfivps | (Opcional) Conexão SCLMDT |
fekfivpt | Configuração de TCP/IP |
fekfivpz | (Opcional) Script de Shell REXEC/SSH |
As tarefas descritas abaixo esperam que você esteja ativo no z/OS UNIX. Isso pode ser feito emitindo o comando do TSO OMVS. Use o comando exit para retornar ao TSO.
Um tamanho de região grande é necessário para o ID do usuário que executa os IVPs, pois as funções, como Java, que exigem muita memória, serão executadas. Você deve definir o tamanho da região como 131072 kilobytes (128 megabytes) ou mais alto.
O seguinte erro de amostra é uma indicação clara de um tamanho de região insuficiente. (Mas outros erros podem ocorrer, também. Por exemplo, Java pode falhar ao iniciar).
CEE5213S The signal SIGPIPE was received. %z/OS UNIX command%: command was killed by signal number 13 %line-number% *-* %REXX command% +++ RC(137) +++
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.
/usr/lpp/rdz/bin/fekfivpr 512 USERIDAlém disso, a maioria dos scripts fekfivp* solicitará o local do rsed.envvars customizado se . ./ivpinit não for executado primeiro.
$ EXPORT STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Observe que a inclusão de uma biblioteca não autorizada pelo APF em um STEPLIB existente remove a autorização APF para conjuntos de dados STEPLIB existentes.
Observe também que se CEE.SCEELKED estiver em LINKLIST ou 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.
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/.
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
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
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
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
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
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:
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
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:
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
Erro de conexão Servidor: erro ao inicializar soquete: java.net.SocketTimeoutException: Tempo limite de aceitação excedido
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
Erro de conexão Servidor: erro ao inicializar soquete: java.net.SocketTimeoutException: Tempo limite de aceitação excedido
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.
Use o comando START para iniciar dinamicamente uma tarefa iniciada (STC). A versão abreviada do comando é a letra S.
O comando MODIFY permite consultar e alterar dinamicamente as características de uma tarefa ativa. A versão abreviada do comando é a letra F.
<id do cliente> : <id do usuário> : <conectado desde>
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>
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>.
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.
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.
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.
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.
O rastreio detalhada prejudica o desempenho e deverá ser feito apenas com orientação do centro de suporte IBM.
BPXM023I (stclock) dataset[(member)] NOT LOCKED BPXM023I (stclock) dataset[(member)] LOCKED BY userid
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.
Use o comando STOP para parar uma tarefa ativa. A versão abreviada do comando é a letra P.
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.
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.
ID da Mensagem | Texto de mensagem |
---|---|
FEK001I | RseDaemon sendo inicializado em modo bit {0} |
FEK002I | RseDaemon iniciado. (porta={0}) |
FEK003I | Pára o comando que está sendo processado |
FEK004I | RseDaemon: Tamanho Máximo de Heap={0}MB e Tamanho do AS privado={1}MB |
FEK005I | Processo do servidor iniciado. (processId={0}) |
FEK009I | RseDaemon está aguardando o processo do servidor iniciar. |
FEK010I | (local do rsed.envvars = {0}) |
FEK011I | (diretório do log = {0}) |
FEK100E | O valor da porta/tempo limite do daemon deve ser dígitos |
FEK101E | JRE {0} ou superior necessário |
FEK102E | Argumentos inválidos recebidos: {0} |
FEK103E | Disco Quase Cheio em {0} |
FEK104E | O número máximo de processos foi atingido |
FEK105E | Erro ao enviar dados de auditoria (rc={0}) |
FEK110E | Falha de socket(). razão=({0}) |
FEK111E | Falha de setsockopt(). razão=({0}) |
FEK112E | Falha de bind(). razão=({0}) |
FEK113E | Falha de listen(). razão=({0}) |
FEK114E | Falha de accept(). razão=({0}) |
FEK115E | Falha de write(). razão=({0}) |
FEK116E | Falha de pipe(). razão=({0}) |
FEK117E | Falha de socketpair(). razão=({0}) |
FEK118E | Falha de select(). razão=({0}) |
FEK119E | Falha de _console(). razão=({0}) |
FEK130E | Falha de gsk_environment_open(). razão=({0}) |
FEK131E | Falha de gsk_attribute_set_enum(GSK_PROTOCOL_SSLV2). razão=({0}) |
FEK132E | Falha de gsk_attribute_set_enum(GSK_PROTOCOL_SSLV3). razão=({0}) |
FEK133E | Falha de gsk_attribute_set_enum(GSK_PROTOCOL_TLSV1). razão=({0}) |
FEK134E | Falha de gsk_attribute_set_buffer(GSK_KEYRING_FILE). razão=({0}) |
FEK135E | Falha de gsk_attribute_set_buffer(GSK_KEYRING_PW). razão=({0}) |
FEK136E | Falha de gsk_environment_init(). razão=({0}) |
FEK137E | Falha de gsk_secure_socket_open(). razão=({0}) |
FEK138E | Falha de gsk_attribute_set_numeric_value(GSK_FD). razão=({0}) |
FEK139E | Falha de gsk_attribute_set_buffer(GSK_KEYRING_LABEL). razão=({0}) |
FEK140E | Falha de gsk_attribute_set_enum(GSK_SESSION_TYPE). razão=({0}) |
FEK141E | Falha de gsk_attribute_set_callback(GSK_IO_CALLBACK). razão=({0}) |
FEK142E | Falha de gsk_secure_socket_init(). razão=({0}) |
FEK143E | Falha de gsk_attribute_set_enum(GSK_CLIENT_AUTH_TYPE). razão=({0}) |
FEK144E | Falha de gsk_get_cert_info. razão=({0}) |
FEK145E | Falha de gsk_secure_socket_read(). razão=({0}) |
FEK146E | Falha de gsk_secure_socket_write(). razão=({0}) |
FEK150E | RseDaemon encerrado de forma anormal; {0} |
FEK201I | O comando {0} foi processado |
FEK202E | Comando Inválido Fornecido |
FEK203E | Comando de Exibição Inválido: Exibir Processo|Cliente |
FEK204E | Comando de Cancelamento Inválido: Cancelar ID=|Usuário= |
FEK205E | O comando não foi processado devido a ALTERNAÇÕES consecutivas |
FEK206E | O Recurso de Log de Auditoria não está ativo |
FEK207I | Nenhum Cliente a ser exibido |
FEK208I | {0} cancelado |
FEK209I | Nenhum Processo a ser exibido |
FEK210I | {0} cancelado devido a logon duplicado |
FEK501I | Daemon de bloqueio iniciado, porta={0}, intervalo de limpeza={1}, nível de log={2} |
FEK502I | Daemon de bloqueio sendo encerrado |
FEK510E | Daemon de bloqueio, porta ausente |
FEK511E | Daemon de bloqueio, porta errada, porta={0} |
FEK512E | Daemon de bloqueio, erro de soquete, porta={0} |
FEK513W | Daemon de bloqueio, falha de registro, ASID={0}, TCB={1}, USER={2} |
FEK514W | Daemon de bloqueio, nível de log errado, nível de log={0} |
BPXM023I | (stclock) dataset[(member)] NOT LOCKED |
BPXM023I | (stclock) dataset[(member)] LOCKED BY userid |
BPXM023I | Comando (stclock), WRONG COMMAND |
BPXM023I | Comando (stclock), MISSING ARGUMENT |
BPXM023I | Argumento (stclock), WRONG ARGUMENT |
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).
Os símbolos a seguir são usados em diagramas de sintaxe:
Símbolo | Descrição |
---|---|
>> | Marca o início do diagrama de sintaxe. |
> | Indica que o diagrama de sintaxe continua. |
| | Marca o início e o fim de um fragmento ou parte do diagrama de sintaxe. |
>< | Marca o fim do diagrama de sintaxe. |
Os tipos de operandos a seguir são usados em diagramas de sintaxe:
>>--REQUIRED_OPERAND--><
>>-*------------------*->< *-OPTIONAL_OPERAND-*
*-DEFAULT_OPERAND-* >>-*-----------------*-><
Os operandos são classificados como palavras-chave ou variáveis:
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-*
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--)------------------------><
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-* *-<--------------------*
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 |---------><
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--|
Este capítulo é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar durante a configuração do Developer para System z e contém as seguintes seções:
Informações adicionais estão disponíveis na seção Suporte do Web site do Developer para System z (http://www-306.ibm.com/software/awdtools/rdz/support/) onde é possível localizar as Notas Técnicas que trazem as informações mais recentes de nossa equipe de suporte.
Na seção Biblioteca do Web site (http://www-306.ibm.com/software/awdtools/rdz/library/), você também pode localizar a versão mais recente da documentação do Developer para System z, incluindo whitepapers.
O Developer para System z Centro de Informações do (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) documenta o cliente Developer para System z e como ele interage com o host (a partir de uma perspectiva do cliente').
Informações sobre valor também podem ser localizadas na biblioteca do z/OS na Internet, disponível em http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
Notifique-nos se achar que o Developer para System z perdeu uma determinada função. Você pode abrir uma Solicitação para Aprimoramento (RFE) em
https://www.ibm.com/developerworks/support/rational/rfe/
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.
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:
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.
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.
Criação de logs de operações normais. O valor padrão na amostra de JCL FEK.#CUST.PROCLIB(JMON) é SYSOUT=*.
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.
Os dados redirecionados de stdout, saída padrão Java. O valor padrão na amostra JCL FEK.#CUST.PROCLIB(LOCKD) é SYSOUT=*.
Os dados redirecionados de stderr, saída de erro padrão Java. O valor padrão na amostra JCL FEK.#CUST.PROCLIB(LOCKD) é SYSOUT=*.
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=*.
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=*.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Quando um programa está em execução no MVS, verifique os arquivos de dump do sistema e verifique a JCL em busca das seguintes instruções DD (dependendo do produto):
Consulte o MVS JCL Reference (SA22-7597) e o Language Environment Debugging Guide (GA22-7560) para obter informações adicionais sobre essas instruções DD.
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:
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.
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) |
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.
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.
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.
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.
O rastreio do JES Job Monitor é controlado pelo operador do sistema, conforme descrito no Comandos do Operador.
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.
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.
O usuário pode controlar a quantidade de informações de rastreio que o CARMA gera configurando o Nível de Rastreio na guia de propriedades da conexão CARMA no cliente. As opções para o Nível de Rastreio são:
O valor padrão é o seguinte:
Log de Erros
Consulte Arquivos de Log para obter informações adicionais sobre as localizações do arquivo de log.
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.
//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)
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'
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
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.
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.
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:
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
O Remote Systems Explorer (RSE) é o componente do Developer para System z que fornece serviços principais como conectar o cliente ao host. Ele deve executar o APF autorizado para realizar tarefas como exibir uso do recurso do processo detalhado.
O z/OS UNIX APF bit é configurado durante a instalação do SMP/E, onde necessário. Este bit de permissão pode se perder caso você não o tenha preservado durante uma cópia manual dos diretórios do Developer para System z.
Os seguintes arquivos do Developer para System z devem ter autorização APF:
Use o comando do z/OS UNIX ls -E para listar os atributos estendidos, em que o APF bit é marcado com a letra a, como mostrado na seguinte amostra ($ é o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz $ ls -E bin/fekfrivp -rwxr-xr-x aps- 2 usuário grupo 114688 Sep 17 06:41 bin/fekfrivp
Use o comando do z/OS UNIX extattr +a para configurar o APF bit manualmente, como mostrado na seguinte amostra ($ e # são os prompts do z/OS UNIX):
$ cd /usr/lpp/rdz $ su # extattr +a bin/fekfrivp # exit $ ls -E bin/fekfrivp -rwxr-xr-x aps- 2 usuário grupo 114688 Sep 17 06:41 bin/fekfrivp
Alguns dos serviços opcionais do Developer para System z requerem que os módulos de carregamento do MVS estejam disponíveis para o z/OS UNIX. Isso é feito ao criar um stub (um arquivo fictício) no z/OS UNIX com o "sticky" bit ativado. Quando o stub é executado, o z/OS UNIX procurará um módulo de carregamento MVS com o mesmo nome e executará o módulo de carregamento no lugar.
O sticky bit do z/OS UNIX é configurado durante a instalação do SMP/E onde necessário. Esses bits de permissão podem ser perdidos se você não os preservou durante uma cópia manual dos diretórios do Developer para System z.
Os seguintes arquivos do Developer para System z devem ter o sticky bit ativado:
Use o comando ls -l do z/OS UNIX para listar as permissões, em que o sticky bit é marcado com a letra t, conforme exibido na seguinte amostra ($ é o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Use o comando z/OS UNIX chmod +t para configurar o sticky bit manualmente, conforme mostrado na seguinte amostra ($ e # são o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz $ su # chmod +t bin/CRA* # exit $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
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:
Esse é o conjunto de dados referido pela instrução PROFILE DD da tarefa iniciada do TCP/IP, muitas vezes chamado de SYS1.TCPPARMS(TCPPROF).
Consulte Communications Server: IP Configuration Guide (SC31-8775) para obter informações adicionais sobre essas instruções.
Estas portas reservadas podem ser listadas com o comando netstat portl (TSO ou z/OS UNIX), que cria uma saída como esta do exemplo a seguir:
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 17:08:32 Port# Prot User Flags Range IP Address ----- ---- ---- ----- ----- ---------- 00007 TCP MISCSERV DA 00009 TCP MISCSERV DA 00019 TCP MISCSERV DA 00020 TCP OMVS D 00021 TCP FTPD1 DA 00025 TCP SMTP DA 00053 TCP NAMESRV DA 00080 TCP OMVS DA 03500 TCP OMVS DAR 03500-03519 03501 TCP OMVS DAR 03500-03519
Consulte Communications Server: IP System Administrator's Commands (SC31-8781) para obter informações adicionais sobre o comando NETSTAT.
O daemon RSE, que é um processo z/OS UNIX Java, exige um tamanho de região grande para executar suas funções. Portanto, é importante definir limites de armazenamento grandes para espaços de endereço do OMVS.
O daemon RSE é iniciado pela JCL utilizando BPXBATSL, cujo tamanho da região deve ser 0.
Configure MAXASSIZE em SYS1.PARMLIB(BPXPRMxx), que define o tamanho da região do espaço de endereço (processo) do OMVS como 2G. Esse é o tamanho máximo permitido. Esse é um limite amplo do sistema e, dessa forma, ativo em todos os espaços de endereço do z/OS UNIX. Se isso não for o que você deseja, então poderá configurar o limite apenas para o Developer para System z em seu software de segurança.
Esse valor pode ser verificado e configurado dinamicamente (até o próximo IPL) com os seguintes comandos de console, conforme descrito em MVS System Commands (GC28-1781):
Verifique ASSIZEMAX no segmento OMVS do ID do usuário do daemon e configure-o como 2147483647 ou, de preferência, como NONE para utilizar o valor SYS1.PARMLIB(BPXPRMxx).
Utilizando RACF, esse valor pode ser verificado e configurado com os seguintes comandos TSO, conforme descrito em Security Server RACF Command Language Reference (SA22-7687):
Certifique-se de não permitir que saídas do sistema IEFUSI ou IEALIMIT controlem os tamanhos de regiões de espaços de endereços OMVS. Uma forma possível de fazer isso é pela codificação de SUBSYS(OMVS,NOEXITS) em SYS1.PARMLIB(SMFPRMxx).
Os valores SYS1.PARMLIB(SMFPRMxx) podem ser verificados e ativados com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):
A palavra-chave MEMLIMIT em SYS1.PARMLIB(SMFPRMxx) limita o quanto uma tarefa de armazenamento virtual de 64 bits pode alocar acima da barra de 2GB. Ao contrário do parâmetro REGION no JCL, o MEMLIMIT=0M significa que o processo não pode usar o armazenamento virtual acima da barra.
Se o MEMLIMIT não estiver especificado em SMFPRMxx, o valor padrão será 0M, assim as tarefas serão limitadas ao (31 bits) 2GB abaixo da barra. O padrão alterado em z/OS 1.10 para 2G, permitindo que tarefas de 64 bits usem até 4GB (os 2GB abaixo da barra e os 2GB acima da barra concedidos pelo MEMLIMIT).
Os valores SYS1.PARMLIB(SMFPRMxx) podem ser verificados e ativados com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):
O MEMLIMIT também pode ser especificado como parâmetro na placa EXEC no JCL. Se nenhum parâmetro MEMLIMIT estiver especificado, o padrão será o valor definido para SMF, exceto quando o REGION=0M estiver especificado, em tal caso o padrão será NOLIMIT.
Se não puder utilizar a versão APPC do serviço TSO Commands, haverá duas áreas nas quais os problemas poderão surgir: iniciando a transação do servidor APPC e conectando ao RSE.
O REXX fornecido em (Opcional) Transação APPC para o Serviço de Comandos TSO pode ajudar a resolver problemas de APPC, pois você tem a possibilidade de gerenciar o APPC interativamente por meio dos painéis ISPF. Lembre-se, no entanto, de que você pode desativar a transação com essa ferramenta; a transação ainda está lá, mas não aceitará nenhuma conexão.
A lista a seguir é uma seleção de Notas Técnicas atualmente disponíveis no Web site de suporte (http://www-306.ibm.com/software/awdtools/rdz/support/). Consulte o Web site de suporte para obter mais informações:
SYS1.PARMLIB(BPXPRMxx) define muitas limitações relacionadas ao z/OS UNIX, que pode ser acessado quando muitos clientes do Developer para System z estão ativos. A maioria dos valores de BPXPRMxx pode ser alterada dinamicamente com os comandos do console SETOMVS e SET OMVS.
Use o comando do console SETOMVS LIMMSG=ALL para que o z/OS UNIX exiba mensagens do console (BPXI040I) quando qualquer dos limites BPXPRMxx estiver prestes a ser atingido.
Cada conexão RSE inicia diversos processos que são permanentemente ativos. Novas conexões podem ser recusadas devido ao limite configurado em SYS1.PARMLIB(BPXPRMxx) na quantidade de processos, especialmente quando os usuários compartilham o mesmo UID (como ao utilizar o segmento OMVS padrão).
Outra origem de conexões recusadas é o limite da quantidade de espaços de endereço do z/OS e de usuários do z/OS UNIX ativos.
Ao usar o APPC para o serviços TSO Commands, a leitura e a gravação de um conjunto de dados MVS exige o uso de um domínio do sistema de arquivos físico do soquete. Se o sistema de arquivo não estiver definido adequadamente ou não tiver soquetes suficientes, o gerenciador de bloqueio (FFS) poderá falhar nos pedidos de leitura/gravação. Os arquivos ffs*.log mostrarão mensagens como a seguinte:
Verifique se o membro SYS1.PARMLIB(BPXPRMxx) contém as seguintes instruções:
FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT) NETWORK DOMAINNAME(AF_UNIX) DOMAINNUMBER(1) MAXSOCKETS(2000) TYPE(UDS)
Outra causa provável para esse problema, durante o uso de APPC para o serviço TSO Commands, é que o TCP/IP Resolver não pode resolver o endereço do host de modo adequado devido a um arquivo de configuração do resolvedor ausente ou incompleto. Uma indicação clara desse problema é a seguinte mensagem em lock.log:
clientip(0.0.0.0) <> callerip(<endereço IP do host>)
Execute o IVP TCP/IP do fekfivpt, conforme descrito em Verificação de Instalação. A seção de configuração do resolvedor da saída será semelhante à seguinte amostra:
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC
Certifique-se de que as definições no arquivo (ou conjunto de dados) referido pelo "Local Tcp/Ip Dataset" estejam corretas.
Esse campo ficará em branco se você não utilizar um nome padrão para o arquivo resolvedor de IP (utilizando a ordem de procura do z/OS UNIX). Nesse caso, inclua a seguinte instrução no rsed.envvars, em que <arquivo resolvedor> ou <dados do resolvedor> representam o nome do arquivo resolvedor de IP:
RESOLVER_CONFIG=<arquivo resolvedor>
ou
RESOLVER_CONFIG='<conjunto de dados do resolvedor>'
O Developer para System z fornece acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. A validação dos pedidos de conexão, o fornecimento de comunicação segura entre o host e a estação de trabalho, e a atividade de autorização e auditoria são aspectos importantes da configuração do produto.
Os mecanismos de segurança usados pelos servidores e serviços do Developer para System z dependem de que o sistema de arquivo em que eles residem seja seguro. Isto indica que apenas administradores confiáveis de sistema podem ser capazes de atualizar as bibliotecas de programa e os arquivos de configuração.
Os seguintes tópicos são abordados neste capítulo:
Consulte o Entendimento do Developer para System z para saber sobre os conceitos básicos de design do Developer para System z.
O Developer para System z suporta várias maneiras de autenticar um ID do usuário fornecido por um cliente an conexão.
Observe que os dados de autenticação fornecidos pelo cliente são usados somente uma vez durante a configuração da conexão inicial. Quando um ID do usuário é autenticado, o ID do usuário e os PassTickets autogerados são usados para todas as ações que requerem autenticação.
O cliente fornece um ID de usuário e uma senha correspondente na conexão. O ID de usuário e a senha são usados para autenticar o usuário com seu produto de segurança.
Com base em um token exclusivo, uma senha única pode ser gerada por um produto de terceiro. Senhas únicas melhoram a configuração da segurança já que o token exclusivo não pode ser copiado e usado sem o conhecimento do usuário e uma senha interceptada é inútil já que é válida somente uma vez.
O cliente fornece um ID de usuário e a senha única na conexão, que é usada para autenticar o ID do usuário com a saída de segurança fornecida por terceiro. Espera-se que essa saída de segurança ignore os PassTickets usados para satisfazer pedidos de autenticação durante o processamento normal. Os PassTickets devem ser processados por seu software de segurança.
Um terceiro pode fornecer um ou mais certificados X.509 que podem ser usados para autenticar um usuário. Quando armazenado em dispositivos seguros, os certificados X.509 combinam uma configuração segura com facilidade de uso para o usuário (nenhum ID do usuário ou senha necessário).
Ao conectar, o cliente fornece um certificado selecionado e, como opção, uma extensão selecionada, que é usada para autenticar o ID do usuário com seu produto de segurança.
Observe que esse método de autenticação é suportado apenas pelo método de conexão do daemon RSE e que o SSL deve estar ativado.
A autenticação do cliente é realizada pelo daemon do RSE (ou REXEC/SSH) como parte do pedido de conexão do cliente. Depois de o usuário ser autenticado, os PassTickets gerados automaticamente são usados para todos os pedidos de autenticação futuros, incluindo o logon automático no JES Job Monitor.
Para que o JES Job Monitor valide o ID do usuário e o PassTicket apresentados pelo RSE, o JES Job Monitor deve ter permissão para avaliar o PassTicket. Isso implica no seguinte:
Diferentes níveis de segurança de comunicação são suportados pelo RSE, que controla toda a comunicação entre os serviços de cliente e do Developer para System z:
O programador de sistemas pode especificar as portas nas quais o servidor RSE pode se comunicar com o cliente. Por padrão, qualquer porta disponível é usada. Esse intervalo de portas não possui conexão com a porta do daemon RSE.
Para ajudar a compreender o uso da porta, segue uma breve descrição do processo de conexão do RSE:
Todos os fluxos de dados externos do Developer para System z que passam pelo RSE podem ser criptografados utilizando-se Secure Socket Layer (SSL). O uso de SSL é controlado pelas configurações no arquivo de configuração ssl.properties, conforme descrito em Comunicação Criptografada por SSL.
O Emulador de Conexão do Host no cliente se conecta a um servidor TN3270 no host. O uso de SSL é controlado pelo TN3270, conforme documentado em Communications Server IP Configuration Guide (SC31-8775).
O cliente Application Deployment Manager usa o Serviço da Web CICS TS ou a interface RESTful para chamar os serviços de host do Application Deployment Manager. O uso de SSL é controlado pelo CICS TS, conforme documentado no RACF Security Guide for CICS TS .
O Developer para System z suporta a verificação de Port Of Entry (POE), que permite que o host acesse apenas os endereços TCP/IP confiáveis. O uso de POE é controlado pela definição de perfis específicos em seu software de segurança e a diretiva enable.port.of.entry em rsed.envvars, conforme descrito em Verificação de Port Of Entry (POE).
Observe que a ativação de POE afetará outros aplicativos TCPIP que suportam a verificação de POE, como o INETD.
A Figura 40 mostra as portas TCP/IP que podem ser usadas pelo Developer para System z. As setas mostram a parte que faz a conexão (lado da ponta da seta) e o que conecta.
Defina as seguintes portas para seu firewall protegendo o host do z/OS, uma vez que são usadas para a comunicação de cliente-host (utilizando o protocolo tcp):
Vários serviços do host Developer para System z são executados em encadeamentos ou espaços de endereço separados e utilizam soquetes TCP/IP como mecanismo de comunicação. Todos esses serviços usam o RSE para comunicação com o cliente, tornando seu fluxo de dados confinado apenas ao host. Para alguns serviços, será usada qualquer porta disponível, para outros, o programador de sistema poderá escolher a porta ou o intervalo de portas que será usado:
Na maioria dos casos, como no daemon RSE, um servidor se conecta a uma porta e atende a pedidos de conexão. O CARMA, no entanto, usa uma abordagem diferente, uma vez que o servidor CARMA não está ativo ainda quando o cliente inicia o pedido de conexão.
Quando o cliente envia um pedido de conexão, o extrator do CARMA, que fica ativo como um encadeamento de usuário em um conjunto de encadeamento RSE, encontrará uma porta livre em um intervalo especificado no arquivo de configuração CRASRV.properties e se conectará a ela. O extrator inicia então o servidor CARMA e transmite o número da porta, para que o servidor saiba a que porta se conectar. Quando o servidor estiver conectado, o cliente pode enviar pedidos ao servidor e receber os resultados.
Portanto, a partir de uma perspectiva TCP/IP, RSE (por meio do extrator do CARMA) é o servidor que se conecta à porta e o servidor CARMA é o cliente que se conecta a ela.
Após o logon, os PassTickets são usados para estabelecer segurança de encadeamento no servidor RSE. Esse recurso não pode ser desativado. Os PassTickets são senhas geradas pelo sistema com um lifespan de aproximadamente 10 minutos. Os PassTickets gerados baseiam-se no algoritmo de criptografia DES, no ID do usuário, no ID do aplicativo, em um registro de data e hora e em uma chave secreta. Essa chave secreta é um número de 64 bits (16 caracteres hexadecimais) que deve ser definido para seu software de segurança.
Para ajudá-lo a compreender o uso de PassTicket, a seguir há uma breve descrição do processo de segurança do RSE:
A senha real do cliente não é mais necessária após a autenticação inicial, pois os produtos de segurança compatíveis com SAF podem avaliar as senhas PassTickets e comuns. O servidor RSE gera e utiliza um PassTicket cada vez que uma senha é solicitada, resultando em uma senha válida (temporária) para o cliente.
O uso de PassTickets permite que o RSE configure um ambiente de segurança específico do usuário à vontade, sem a necessidade de armazenar todos os IDs de usuário e senhas em uma tabela, o que poderia ser comprometido. Ele também permite métodos de autenticação de cliente que não usam senhas reutilizáveis, como certificados X.509.
Os perfis de segurança nas classesAPPL e PTKTDATA são necessários para que se possa usar os PassTickets. Esses perfis são específicos do aplicativo e, portanto, não afetam a configuração atual do sistema.
Os PassTickets sendo específicos do aplicativo implicam em o RSE e o JES Job Monitor usarem o mesmo ID de aplicativo (APPLID). Por padrão, ambos os servidores usam FEKAPPL como APPLID, mas isso pode ser alterado pela diretiva APPLID em rsed.envvars para o RSE e em FEJJCNFG para o JES Job Monitor.
Não é recomendável usar o OMVSAPPL como ID do aplicativo porque ele abrirá uma chave secreta para a maioria dos aplicativos z/OS UNIX. Também não é recomendável usar o ID do aplicativo padrão MVS, que é MVS seguido pelo ID do sistema SMF, porque isto abrirá uma chave secreta para a maioria dos aplicativos MVS (incluindo as tarefa em lote do usuário).
Atenção: O pedido de conexão do cliente
falhará se os PassTickets não estiverem configurados corretamente. |
O Developer para System z suporta a criação de log de auditoria das ações que são gerenciadas pelo daemon RSE. Os logs de auditoria são armazenados como arquivos de texto no diretório de log do daemon, utilizando o formato CSV (Comma Separated Value).
Várias opções em rsed.envvars influenciam a função de auditoria, conforme documentado em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.
O comando do operador modify switch pode ser usado para alternar manualmente para um novo arquivo de log de auditoria, conforme documentado em Comandos do Operador.
Uma mensagem de aviso é enviada para o console quando o sistema de arquivos que contém os arquivos de log de auditoria estiver em execução com pouco espaço livre. Essa mensagem do console (FEK103E) é repetida regularmente até que o problema de pouco espaço seja resolvido. Consulte Mensagens do Console para obter uma lista de mensagens do console geradas pelo RSE.
Um novo arquivo de log de auditoria é iniciado após um momento predeterminado ou quando o comando do operador modify switch é emitido. O arquivo de log antigo é salvo como audit.log.yyyymmdd.hhmmss, em que yyyymmdd.hhmmss é a data/registro de data e hora no qual o log foi fechado. A data/registro de data e hora do sistema designados ao arquivo indicam a criação do arquivo de log. A combinação das duas datas mostra o período de tempo abrangido por esse arquivo de log de auditoria.
As seguintes ações são registradas:
Cada ação registrada é armazenada (com uma data/registro de data e hora) utilizando o formato Comma Separated Value (CSV), que pode ser lido por uma ferramenta de automação ou de análise de dados.
Os arquivos de log de auditoria possuem a máscara de bit de permissão 640 (-rw-r-----), o que significa que o proprietário (uid do daemon RSE z/OS UNIX) possui acesso de leitura e gravação, e o grupo do proprietário (padrão) possui acesso de leitura. Todas as outras tentativas de acesso são negadas, a menos que isso seja feito por um superusuário (UID 0) ou alguém com permissão suficiente para o perfil SUPERUSER.FILESYS na classe UNIXPRIV.
O Developer para System z permite acesso do cliente ao spool do JES através do JES Job Monitor. O servidor fornece limitações de acesso básico, que podem ser estendidas com os recursos de proteção padrão do arquivo de spool de seu produto de segurança. As ações do operador (Suspender, Liberar, Cancelar e Limpar) nos arquivos de spool são feitas através do console EMCS, para o qual é necessário configurar permissões condicionais.
O JES Job Monitor não fornece aos usuários do Developer para System z acesso total de operador ao spool do JES. Apenas os comandos Suspender, Liberar, Cancelar e Limpar estão disponíveis e, por padrão, somente para arquivos em spool que pertencem ao usuário. Os comandos são emitidos selecionando a opção apropriada na estrutura de menus do cliente (sem prompt de comandos). O escopo dos comandos pode ser ampliado, utilizando perfis de segurança para definir para quais tarefas os comandos estão disponíveis.
Semelhante ao caractere de ação SDSF SJ, o JES Job Monitor também suporta o comando Mostrar JCL para recuperar a JCL que criou a saída de tarefa selecionada e o mostra em uma janela de editor. O JES Job Monitor recupera a JCL do JES, tornando-o uma função útil para situações em que o membro JCL original não é facilmente localizado.
Ações | JES2 | JES3 |
---|---|---|
Suspen
der |
$Hx(jobid)
with x = {J, S or T} |
*F,J=jobid,H |
Libera
ção |
$Ax(jobid)
with x = {J, S or T} |
*F,J=jobid,R |
Cance
lar |
$Cx(jobid)
with x = {J, S or T} |
*F,J=jobid,C |
Limpar | $Cx(jobid),P
with x = {J, S or T} |
*F,J=jobid,C |
Mostrar JCL | não-aplicável | não-aplicável |
Os comandos JES disponíveis listados na Tabela 21 são limitados por padrão às tarefas que pertencem ao usuário. Isso pode ser alterado com a diretiva LIMIT_COMMANDS, conforme documentado em FEJJCNFG, Arquivo de Configuração do JES Job Monitor.
Proprietário da tarefa | ||
---|---|---|
LIMIT_COMMANDS | Usuário | Outros |
USERID (padrão) | Permitido | Não permitido |
LIMITED | Permitido | Permitido somente se for permitido explicitamente por perfis de segurança |
NOLIMIT | Permitido | Permitido se for permitido pelos perfis de segurança ou quando a classe JESSPOOL não estiver ativa |
O JES utiliza a classe JESSPOOL para proteger os conjuntos de dados SYSIN/SYSOUT. Semelhante a SDSF, o JES Job Monitor estende o uso da classe JESSPOOL para proteger os recursos de tarefas também.
Se LIMIT_COMMANDS não for USERID, o JES Job Monitor consultará se há permissão para o perfil relacionado na classe JESSPOOL, conforme mostrado na tabela a seguir.
Comando | Perfil JESSPOOL | Acesso Necessário |
---|---|---|
Suspen
der |
nodeid.userid.jobname.jobid | ALTER |
Libe
ração |
nodeid.userid.jobname.jobid | ALTER |
Cancelar | nodeid.userid.jobname.jobid | ALTER |
Limpar | nodeid.userid.jobname.jobid | ALTER |
Mostrar JCL | nodeid.userid.jobname.jobid.JCL | READ |
Use as seguintes substituições na tabela anterior:
nodeid | O ID do nó NJE do subsistema JES de destino |
userid | ID do usuário local do proprietário da tarefa |
jobname | Nome da tarefa |
jobid | ID da tarefa do JES |
Se a classe JESSPOOL não estiver ativa, haverá um comportamento diferente para o valor LIMITED e NOLIMIT de LIMIT_COMMANDS, conforme descrito em Tabela 9. O comportamento é idêntico quando JESSPOOL está ativo, já que a classe, por padrão, nega a permissão se um perfil não estiver definido.
A segunda fase da segurança de comando em spool do JES, depois de especificar os destinos permitidos, inclui as permissões necessárias para realmente executar o comando do operador. Essa autorização de execução é aplicada pelas verificações de segurança do z/OS e do JES.
Observe que Mostrar JCL não é um comando de operador, como os outros comandos JES Job Monitor (Suspender, Liberar, Cancelar e Limpar), portanto, as limitações abaixo não se aplicam porque não há nenhuma verificação de segurança adicional.
O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário por meio de um console MCS estendido (EMCS), cujo nome é controlado com a diretiva CONSOLE_NAME, conforme documentado em FEJJCNFG, Arquivo de Configuração do JES Job Monitor.
Essa configuração permite que o administrador de segurança defina permissões granulares de execução de comandos usando as classes OPERCMDS e CONSOLE.
Supondo que a identidade do servidor JES Job Monitor, criando um console JMON a partir de uma sessão do TSO, seja impedida por seu software de segurança. Embora o console possa ser criado, o ponto de entrada é diferente (JES Job Monitor versus TSO). Os comandos JES emitidos a partir desse console falharão na verificação de segurança se a segurança estiver configurada conforme documentado nesta publicação e o usuário não tiver autoridade para comandos JES por outros meios.
Observe que o JES Job Monitor não poderá criar o console quando um comando tiver que ser executado se o nome do console já estiver sendo usado. Para evitar isso, o programador de sistema pode configurar a diretiva GEN_CONSOLE_NAME=ON no arquivo de configuração do JES Job Monitor ou o administrador de segurança pode definir perfis de segurança para que os usuários do TSO parem de criar um console. Os comandos de amostra do RACF a seguir impedem que qualquer indivíduo (exceto aqueles permitidos) crie um console TSO ou SDSF:
Consulte o Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre proteção de comandos do operador.
O JES Job Monitor permite acesso de procura a todos os arquivos em spool, por padrão. Isso pode ser alterado com a diretiva LIMIT_VIEW, conforme documentado em FEJJCNFG, Arquivo de Configuração do JES Job Monitor.
Proprietário da tarefa | ||
---|---|---|
LIMIT_VIEW | Usuário | Outros |
USERID | Permitido | Não permitido |
NOLIMIT (padrão) | Permitido | Permitido se for permitido pelos perfis de segurança ou quando a classe JESSPOOL não estiver ativa |
Para limitar os usuários às suas próprias tarefas no spool JES, defina a instrução "LIMIT_VIEW=USERID" no arquivo de configuração do JES Job Monitor, FEJJCNFG. Se os usuários precisarem de acesso a um intervalo maior de tarefas, mas não todas, use os recursos de proteção de arquivo de spool padrão do seu produto de segurança, como a classe JESSPOOL.
Ao definir a proteção adicional, lembre-se que o JES Job Monitor utiliza a SAPI (SYSOUT Application Program Interface) para acessar o spool. Isto significa que o usuário precisa de, pelo menos, acesso UPDATE aos arquivos de spool, mesmo para a funcionalidade de procura. Esse requisito não se aplicará se você executar o z/OS 1.7 (z/OS 1.8 para JES3) ou superior. Aqui, a permissão READ é suficiente para a funcionalidade de procura.
Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre a proteção do arquivo em spool do JES.
A comunicação externa (cliente-host) pode ser criptografada utilizando-se SSL (Secure Socket Layer). Esse recurso é desativado por padrão e é controlado pelas configurações em ssl.properties, conforme documentado em (Opcional) Criptografia SSL do RSE.
O daemon RSE e o servidor RSE suportam diferentes mecanismos para armazenar certificados devido a diferenças de arquitetura entre eles. Isso implica que as definições e os certificados SSL são necessários para o daemon RSE e para o servidor RSE. Um certificado compartilhado poderá ser usado se o daemon RSE e o servidor RSE usarem o mesmo método de gerenciamento de certificado.
Armazenamento de certificado | Criado e gerenciado por | Daemon RSE | servidor RSE |
---|---|---|---|
conjunto de chaves | produto de segurança compatível com SAF | suportados | suportados |
banco de dados de chaves | gskkyman do z/OS UNIX | suportados | / |
keystore | keytool Java | / | suportados |
Os conjuntos de chaves compatíveis com SAF podem armazenar a chave privada do certificado no banco de dados de segurança ou usando ICSF (Integrated Cryptographic Service Facility), a interface para o hardware de criptografia do System z.
ICSF é recomendado para o armazenamento de chaves privadas associadas a certificados digitais, porque é uma solução mais segura do que o gerenciamento de chaves privadas não-ICSF. O ICSF garante que as chaves privadas sejam criptografadas na chave mestra do ICSF e que o acesso a elas seja controlado por recursos gerais das classes de segurança CSFKEYS e CSFSERV. Além disso, o desempenho operacional é aprimorado, pois o ICSF utiliza o Coprocessador Criptográfico de hardware.
O daemon RSE utiliza funções SSL do Sistema para gerenciar as comunicações criptografadas por SSL. Isso implica que SYS1.SIEALNKE deve ser controlado pelo programa pelo software de segurança e estar disponível para o RSE através de LINKLIST ou da diretiva STEPLIB em rsed.envvars.
O ID do usuário do RSE (STCRSE nos comandos de amostra abaixo) precisa de autorização para acessar esse conjunto de chaves e os certificados relacionados quando os conjuntos de chaves compatíveis com SAF são usados para o daemon RSE ou o servidor RSE.
Consulte o Apêndice A. Configurando o SSL e a Autenticação X.509 para obter mais detalhes sobre como ativar o SSL para Developer para System z.
O daemon RSE suporta que os próprios usuários se autentiquem com um certificado X.509. Usar a comunicação criptografada SSL é um pré-requisito para essa função, uma vez que é uma extensão para a autenticação de host com um certificado usado no SSL.
O daemon RSE inicia o processo de autenticação de cliente pela validação do certificado de cliente. Alguns aspectos chave que são verificados são as datas de validade do certificado e a fidelidade da Autoridade de Certificação (CA) usada para assinar o certificado. Opcionalmente, também é possível consultar uma Lista de Revogação de Certificado (CRL) (terceiros).
Depois que o daemon RSE valida o certificado, ele é processado para autenticação. O certificado é passado adiante para seu produto de segurança para autenticação, a menos que a diretiva rsed.envvars enable.certificate.mapping esteja configurada como false, quando o daemon do RSE fará a autenticação.
Se bem-sucedido, o processo de autenticação determinará o ID de usuário a ser usado para esta sessão, que será, então, testado pelo daemon RSE para assegurar que seja útil no sistema host em que o daemon RSE está em execução.
A última verificação (que é feita para cada mecanismo de autenticação, não apenas certificados X.509) verifica se o ID do usuário tem permissão para usar o Developer para System z.
Se você estiver familiarizado com as classificações de segurança do SSL usadas por TCP/IP, a combinação dessas etapas de validação corresponderão às especificações de "Autenticação de Cliente Nível 3" (a mais alta disponível).
Parte do processo de validação do certificado inclui verificar se o certificado foi assinado por uma Autoridade de Certificação (CA) de confiança. Para fazer isso, o daemon do RSE deve ter acesso a um certificado que identifique a CA.
Ao usar o banco de dados de chaves gskkyman para sua conexão SSL, o certificado da CA deve ser incluído no banco de dados de chaves.
Ao usar um conjunto de chaves SAF (que é o método aconselhado), você deve incluir o certificado da CA em seu banco de dados de segurança como o certificado CERTAUTH com o atributo TRUST ou HIGHTRUST, conforme mostrado neste comando RACF de amostra:
Observe que a maioria dos produtos de segurança já tem os certificados para as CAs reconhecidas disponíveis em seu banco de dados com um status NOTRUST. Use os comandos RACF de amostra a seguir para listar os certificados de CA existentes e marcar um como confiável com base no rótulo designado a ele.
Quando o certificado da CA for incluído em seu banco de dados de segurança, ele deverá ser conectado ao conjunto de chaves RSE, conforme mostrado neste comando RACF de amostra:
Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter informações adicionais sobre o comando RACDCERT.
Atenção: Se você depender do daemon RSE em vez de seu software de segurança para autenticar um usuário, deverá tomar cuidado para não confundir as CAs com os status TRUST e HIGHTRUST no conjunto de chaves SAF ou no banco de dados de chaves gskkyman. O daemon do RSE não é capaz de diferenciar entre os dois, portanto, os certificados assinados por uma CA com status TRUST será válido para propósitos de autenticação de ID do usuário. |
Se desejado, é possível instruir o daemon do RSE para verificar uma ou mais Certificate Revocation Lists (CRL) para incluir segurança extra para o processo de validação. Isso é feito incluindo variáveis de ambiente relacionadas à CRL em rsed.envvars. Consulte Arquivo de Configuração do RSE rsed.envvars para obter informações sobre estas variáveis de amostra:
Consulte Cryptographic Services System Secure Sockets Layer Programming (SC24-5901) para obter informações adicionais sobre essas e outras variáveis de ambiente usadas pelo z/OS System SSL.
O RACF executa várias verificações para autenticar um certificado e retornar o ID do usuário associado. Observe que outros produtos de segurança podem fazer isso de forma diferente. Consulte a documentação de seu produto de segurança para obter informações adicionais sobre a função initACEE usada para realizar a autenticação (modo de consulta).
Os certificados são definidos como RACF usando o comando RACDCERT, como no seguinte exemplo:
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
O par ID do usuário e nome do host é válido se todas estas condições forem verdadeiras:
A definição da extensão HostIdMappings na sintaxe ASN.1 é:
id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1} HostIdMappings::= SET OF HostIdMapping HostIdMapping::= SEQUENCE{ hostName IMPLICIT[1] IA5String, subjectId IMPLICIT[2] IA5String, proofOfIdPossession IdProof OPTIONAL } IdProof::= SEQUENCE{ secret OCTET STRING, encryptionAlgorithm OBJECT IDENTIFIER }
Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre certificados X.509, como são gerenciados pelo RACF e como definir filtros de nomes de certificados. Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter informações adicionais sobre o comando RACDCERT.
O Developer para System z pode realizar autenticação básica de certificado X.509 sem depender de seu produto de segurança. A autenticação realizada pelo daemon do RSE requer que um ID do usuário e nome do host sejam definidos em uma extensão de certificado e está ativa somente se a diretiva enable.certificate.mapping em rsed.envvars estiver configurada para FALSE.
Essa função deverá ser usada se o seu produto de segurança não suportar autenticação de um usuário com base em um certificado X.509 ou se o seu certificado for causar falha no(s) teste(s) feito(s) por seu produto de segurança (por exemplo, o certificado possui um identificador falho para a extensão HostIdMappings e não há nenhum filtro ou definição em DIGTCERT).
O cliente consultará o usuário pelo identificador da extensão (OID) a ser usado, que é, por padrão, o OID de HostIdMappings, {1 3 18 0 2 18 1}.
O daemon do RSE extrairá o ID do usuário e o nome do host do mesmo usando o formato da extensão HostIdMappings. Esse formato está descrito em Autenticação por Software de Segurança.
O par ID do usuário e nome do host é válido se todas estas condições forem verdadeiras:
Atenção: Depende do administrador de segurança
assegurar que todas as CAs conhecidas do daemon RSE sejam altamente confiáveis, já que
o daemon RSE não pode verificar se aquele que assinou o certificado de cliente
é altamente confiável ou apenas confiável. Consulte Validação da Autoridade de Certificação (CA) para obter informações adicionais sobre certificados de
CA acessíveis. |
O Developer para System z suporta a verificação de Port Of Entry (POE), que permite que o host acesse apenas os endereços TCP/IP confiáveis. Esse recurso fica desativado por padrão e requer a definição do perfil de segurança BPX.POE, conforme mostrado nos seguintes comandos RACF de amostra:
Consulte o Communications Server IP Configuration Guide (SC31-8775) para obter informações adicionais sobre o controle de acesso à rede usando a verificação de POE.
O Developer para System z permite, através do Application Deployment Manager, que administradores do CICS controlem quais definições de recurso do CICS podem ser editadas pelo desenvolvedor, seus valores padrão e a exibição de uma definição de recurso do CICS por meio de um servidor CICS Resource Definition (CRD). Consulte Considerações sobre o CICSTS para obter informações adicionais sobre as definições de segurança necessárias do CICS TS.
O conjunto de dados de VSAM do repositório do servidor CRD contém todas as definições de recurso padrão e deve, portanto, ser protegido contra atualizações, mas os desenvolvedores devem ter permissão para ler os valores armazenados aqui.
O Developer para System z fornece várias transações que são usadas pelo servidor CRD durante a definição e a consulta de recursos do CICS. Quando a transação é conectada, a verificação de segurança de recurso do CICS, se ativada, garante que o ID do usuário esteja autorizado para executar o ID de transação.
O cliente Application Deployment Manager usa os Serviços da Web do CICS TS ou a interface RESTful para chamar o servidor CRD. O uso de SSL para essa comunicação é controlado pela definição TCPIPSERVICE do CICS TS, conforme documentado no RACF Security Guide for CICS TS.
O serviço SCLM Developer Toolkit oferece funcionalidade de segurança opcional para as funções Construir, Promover e Implementar.
Se a segurança for ativada para uma função pelo administrador de SCLM, as chamadas SAF serão feitas para verificar a autoridade para executar a função protegida com o ID do usuário do responsável pela chamada ou do substituto.
Consulte SCLM Developer Toolkit Administrator's Guide (SC23-9801), para obter informações adicionais sobre as definições de segurança SCLM necessárias.
Há vários arquivos de configuração do Developer para System z cujas diretivas afetam a configuração da segurança. Com base nas informações deste capítulo, o administrador de segurança e o programador de sistemas podem decidir quais devem ser as configurações para as diretivas a seguir.
Definir em relação a quais ações as tarefas podem ser realizadas (excluindo navegação e envio). Para obter informações adicionais, consulte Ações nas Tarefas - Limitações de Destino.
Definir quais arquivos de spool podem ser navegados. Para obter informações adicionais, consulte Acesso aos Arquivos de Spool.
ID do aplicativo usado para criação/validação do PassTicket. Para obter informações adicionais, consulte Usando os PassTickets.
Nega aos usuários o salvamento de sua senha do host no cliente. Para obter informações adicionais, consulte Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.
Cronômetro para desconectar clientes inativos. Para obter informações adicionais, consulte Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.
ID do aplicativo usado para criação/validação do PassTicket. Para obter informações adicionais, consulte Usando os PassTickets.
Ativar a verificação de Port Of Entry. Para obter informações adicionais, consulte Verificação de Port Of Entry (POE).
Use o seu produto de segurança para autenticar usuários com um certificado X.509. Para obter informações adicionais, consulte Autenticação de Cliente Usando Certificados X.509.
Local dos arquivos de log de auditoria. Para obter informações adicionais, consulte Criação de Log de Auditoria.
Local do certificado do daemon RSE. Para obter informações adicionais, consulte Comunicação Criptografada por SSL.
Nome do certificado do daemon RSE. Para obter informações adicionais, consulte Comunicação Criptografada por SSL.
Local do certificado do servidor RSE. Para obter informações adicionais, consulte Comunicação Criptografada por SSL.
Nome do certificado do servidor RSE. Para obter informações adicionais, consulte Comunicação Criptografada por SSL.
Tipo de armazenamento de chaves usado (armazenamento de chaves Java ou conjunto de chaves SAF). Para obter informações adicionais, consulte Comunicação Criptografada por SSL.
Customize e envie o membro de amostra FEKRACF, que possui os comandos de amostra do RACF e z/OS UNIX para criar as definições de segurança básicas para o Developer para System z.
FEKRACF está localizado em FEK.#CUST.JCL, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.
Consulte o RACF Command Language Reference (SA22-7687), para obter informações adicionais sobre os comandos RACF.
As seções a seguir descrevem as etapas necessárias, a configuração opcional e as possíveis alternativas.
Para concluir a configuração de segurança, o administrador de segurança precisa conhecer os valores listados na Tabela 26. Esses valores foram definidos durante as etapas anteriores da instalação e da customização do Developer para System z.
Descrição |
|
Valor |
---|---|---|
Qualificador de alto nível do produto Developer para System z |
|
|
Qualificador de alto nível de customização do Developer para System z |
|
|
Nome da tarefa iniciada do JES Job Monitor |
|
|
Nome da tarefa iniciada do daemon RSE |
|
|
Nome da tarefa iniciada do daemon de bloqueio |
|
|
ID do aplicativo |
|
A lista a seguir é uma visão geral das ações necessárias para concluir a configuração de segurança básica de Developer para System z. Conforme documentado nas seções abaixo, é possível usar diferentes métodos para preencher esses requisitos, dependendo do nível de segurança desejado. Consulte as seções anteriores para obter informações sobre a configuração de segurança de serviços opcionais do Developer para System z.
O Developer para System z utiliza uma variedade de mecanismos de segurança para assegurar um ambiente de host seguro e controlado para o cliente. Para fazer isso, várias classes e configurações de segurança devem estar ativas, conforme mostrado com os comandos de amostra do RACF a seguir:
SETROPTS LIST
SETROPTS GENERIC(FACILITY)
SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
SETROPTS GENERIC(STARTED)
RDEFINE STARTED ** STDATA(USER(=MEMBER) GROUP(STCGROUP) TRACE(YES))
SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
SETROPTS GENERIC(CONSOLE)
SETROPTS CLASSACT(CONSOLE) RACLIST(CONSOLE)
SETROPTS GENERIC(OPERCMDS)
SETROPTS CLASSACT(OPERCMDS) RACLIST(OPERCMDS)
SETROPTS GENERIC(APPL)
SETROPTS CLASSACT(APPL) RACLIST(APPL)
SETROPTS GENERIC(PTKTDATA)
SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA)
RDEFINE PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM)
Atenção: Alguns produtos, como o FTP, precisarão ser controlados pelo programa se "WHEN PROGRAM" estiver ativo. Teste isto antes de ativá-lo em um sistema de produção. |
SETROPTS GENERIC(SERVAUTH)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
Um segmento RACF OMVS (ou equivalente) que especifica um ID de usuário (UID), um diretório inicial e um comando shell z/OS UNIX válidos diferentes de zero, devem ser definidos para cada usuário do Developer para System z. Seus grupos padrão também requerem um segmento OMVS com um ID do grupo.
Substitua os seguintes marcadores #userid, #user-identifier, #group-name e #group-identifier dos comandos RACF de amostra por valores reais:
ALTUSER #userid OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
ALTGROUP #group-name OMVS(GID(#group-identifier))
Embora isso não seja recomendado, você pode utilizar o segmento OMVS compartilhado definido no perfil BPX.DEFAULT.USER da classe FACILITY para atender aos requisito do segmento OMVS para Developer para System z.
O acesso READ para usuários e ALTER para programadores de sistema é suficiente para a maioria dos conjuntos de dados do Developer para System z. Substitua o marcador #sysprog por IDs de usuário válidos ou nomes de grupos do RACF. Além disso, pergunte ao programador de sistema que instalou e configurou o produto os nomes corretos do conjunto de dados. FEK é o qualificador de alto nível padrão usado durante a instalação e FEK.#CUST é o qualificador de alto nível padrão para conjuntos de dados criados durante o processo de customização.
ADDGROUP (FEK) OWNER(IBMUSER) SUPGROUP(SYS1) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
ADDSD 'FEK.*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT 'FEK.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
Alguns dos componentes opcionais do Developer para System z exigem perfis adicionais do conjunto de dados de segurança. Substitua os marcadores #sysprog, #ram-developer e #cicsadmin por um ID de usuário válido ou nomes de grupos RACF:
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
Use os comandos de amostra do RACF a seguir para obter uma configuração mais segura onde o acesso READ também é controlado.
ADDGROUP (FEK) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB') OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(#db2)
SETROPTS GENERIC(DATASET) REFRESH
Ao controlar o acesso READ para conjuntos de dados do sistema, você deve fornecer aos servidores Developer para System z e usuários a permissão READ para os seguintes conjuntos de dados:
Os comandos de amostra RACF a seguir criam as tarefas iniciadas JMON, RSED e LOCKD, com IDs de usuário protegidos (STCJMON, STCRSE e STCLOCK, respectivamente) e agrupam o STCGROUP designado a eles. Substitua os marcadores #group-id e #user-id-* pelos IDs de OMVS válidos.
ADDGROUP STCGROUP OMVS(GID(#group-id)) DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCJMON DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR') OMVS(UID(#user-id-jmon) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON') OMVS(UID(#user-id-rse) HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCLOCK DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - LOCK DAEMON') OMVS(UID(#user-id-lock) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED JMON.* DATA('RDZ - JES JOBMONITOR') STDATA(USER(STCJMON) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED RSED.* DATA('RDZ - RSE DAEMON') STDATA(USER(STCRSE) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED LOCKD.* DATA('RDZ - LOCK DAEMON') STDATA(USER(STCLOCK) GROUP(STCGROUP) TRUSTED(NO))
SETROPTS RACLIST(STARTED) REFRESH
Talvez você queira restringir o ID do usuário STCRSE. Os usuários com o atributo RESTRICTED não podem acessar recursos (MVS) protegidos que eles não estão especificamente autorizados a acessar.
ALTUSER STCRSE RESTRICTED
Para assegurar que os usuários restritos não obtenham acesso aos recursos do sistema de arquivos z/OS UNIX por meio de "outros" bits de permissão, é necessário definir o perfil RESTRICTED.FILESYS.ACCESS na classe UNIXPRIV com UACC(NONE). Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre a restrição de IDs de usuários.
Atenção: Se você usar IDs de usuário restritos, deverá incluir
explicitamente a permissão para acessar um recurso com os comandos PERMIT do TSO ou z/OS UNIX setfacl.
Isso inclui recursos em que a documentação do Developer para System z usa
UACC (como o perfil ** da classe PROGRAM) ou
em que depende das convenções comuns do z/OS UNIX (como se todos tivessem permissão de leitura e
execução para bibliotecas Java).
Teste isto antes
de ativá-lo em um sistema de produção. |
O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário por meio de um console MCS estendido (EMCS), cujo nome é controlado com a diretiva CONSOLE_NAME, conforme documentado em FEJJCNFG, Arquivo de Configuração do JES Job Monitor.
Os seguintes comandos de amostra RACF oferecem aos usuários do Developer para System z acesso condicional a um conjunto limitado de comandos JES (Suspender, Liberar, Cancelar e Limpar). Os usuários só terão permissão de execução se emitirem os comandos por meio do JES Job Monitor. Substitua o marcador #console pelo nome real do console.
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Atenção: Definir os comandos JES com o acesso universal NONE no
software de segurança pode afetar outros aplicativos e operações. Teste isto antes
de ativá-lo em um sistema de produção. |
A Tabela 27 e a Tabela 28 mostram os comandos do operador emitidos para JES2 e JES3 e os perfis de segurança distintos que podem ser usados para protegê-los.
Ações | Comando | Perfil OPERCMDS | Acesso Necessário |
---|---|---|---|
Suspen
der |
$Hx(jobid)
with x = {J, S or T} |
jesname.MODIFYHOLD.BAT jesname.MODIFYHOLD.STC jesname.MODIFYHOLD.TSU |
UPDATE |
Libe
ração |
$Ax(jobid)
with x = {J, S or T} |
jesname.MODIFYRELEASE.BAT |
UPDATE |
Cancelar | $Cx(jobid)
with x = {J, S or T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
Limpar | $Cx(jobid),P
with x = {J, S or T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
Ações | Comando | Perfil OPERCMDS | Acesso Necessário |
---|---|---|---|
Suspen
der |
*F,J=jobid,H |
jesname.MODIFY.JOB |
UPDATE |
Libe
ração |
*F,J=jobid,R |
jesname.MODIFY.JOB |
UPDATE |
Cancelar | *F,J=jobid,C |
jesname.MODIFY.JOB |
UPDATE |
Limpar | *F,J=jobid,C |
jesname.MODIFY.JOB |
UPDATE |
Supondo que a identidade do servidor JES Job Monitor, criando um console JMON a partir de uma sessão do TSO, seja impedida por seu software de segurança. Embora o console possa ser criado, o ponto de entrada é diferente (JES Job Monitor versus TSO). Os comandos JES emitidos a partir desse console falharão na verificação de segurança se a segurança estiver configurada conforme documentado nesta publicação e o usuário não tiver autoridade para os comandos JES por outros meios.
O RSE requer acesso UPDATE para o perfil BPX.SERVER para criar/excluir o ambiente de segurança do encadeamento do cliente. Se esse perfil não estiver definido, UID(0) será necessário para o RSE.
Atenção: Definir o perfil BPX.SERVER
torna o z/OS UNIX um comutador completo da segurança de nível UNIX para a segurança de nível z/OS UNIX,
que é mais segura. Isso pode afetar outros aplicativos e operações z/OS UNIX. Teste isto antes
de ativá-lo em um sistema de produção.
Consulte o UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre os diferentes níveis de segurança. |
Os servidores com autoridade para BPX.SERVER devem ser executados em um ambiente limpo controlado pelo programa. Isso implica que todos os programas chamados pelo RSE também devem ser controlados pelo programa. Para as bibliotecas de carregamento do MVS, o controle de programa é gerenciado pelo seu software de segurança.
O RSE usa o tempo de execução do sistema (SYS1.LINKLIB), Language Environment' (CEE.SCEERUN*) e a biblioteca de carregamento do ISPF' TSO/ISPF Client Gateway (ISP.SISPLOAD).
As bibliotecas adicionais a seguir (pré-requisito) devem ser controladas pelo programa para suportar o uso de serviços opcionais. Essa lista não inclui conjuntos de dados que são específicos para um produto com o qual o Developer para System z interage, como a Ferramenta de Depuração IBM.
Durante o logon do cliente, o daemon RSE verifica se um usuário tem permissão para usar o aplicativo.
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
SETROPTS RACLIST(APPL) REFRESH
Conforme descrito com mais detalhes em Definir o Suporte PassTicket para o RSE, o RSE suporta o uso de um ID do aplicativo diferente de FEKAPPL. A definição de classe do APPL deve corresponder ao ID do aplicativo real usado pelo RSE.
Atenção: O pedido de conexão com o cliente falhará se o perfil do aplicativo não estiver definido ou quando o usuário não tiver acesso de LEITURA para o perfil. |
A senha do cliente,' (ou outro meio de identificação como um certificado X.509), somente é usada para verificar a sua identidade na conexão. Depois disso, os PassTickets são usados para manter a segurança do encadeamento.
PassTickets são senha geradas pelo sistema com uma duração de aproximadamente 10 minutos. Os PassTickets baseiam-se em uma chave secreta. Essa chave é um número de 64 bits (16 caracteres hexadecimais). Substitua nos comandos de amostra do RACF, a seguir, o marcador key16 por uma cadeia hexadecimal de 16 caracteres fornecida pelo usuário (caracteres de 0 a 9 e de A a F).
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16)) APPLDATA('NO REPLAY PROTECTION - DO NOT CHANGE') DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
O RSE suporta o uso de um ID do aplicativo diferente de FEKAPPL. Remova o comentário e customize a opção "APPLID=FEKAPPL" no rsed.envvars para ativar isto, como documentado em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS. As definições de classe PTKTDATA devem corresponder ao ID do aplicativo real usado pelo RSE.
Não é recomendável usar OMVSAPPL como ID do aplicativo porque ele abrirá a chave secreta para a maioria dos aplicativos do z/OS UNIX. Também não é recomendável usar o ID do aplicativo padrão MVS, que é MVS seguido pelo ID do sistema SMF', porque isto abrirá a chave secreta para a maioria dos aplicativos MVS (incluindo as tarefas em lote).
Atenção: O pedido de conexão do cliente
falhará se os PassTickets não estiverem configurados corretamente. |
Os servidores com autoridade para BPX.SERVER devem ser executados em um ambiente limpo controlado pelo programa. Isso implica que todos os programas chamados pelo RSE também devem ser controlados pelo programa. Para arquivos do z/OS UNIX, o controle do programa é gerenciado pelo comando extattr. Para executar esse comando, você precisa de acesso READ para o BPX.FILEATTR.PROGCTL na classe FACILITY ou ser UID(0).
O servidor RSE usa a biblioteca compartilhada Java do RACF (/usr/lib/libIRRRacf.so).
$ ls -Eog /usr/lib/libIRRRacf.so -rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
Use os seguintes comandos de amostra para exibir os resultados de suas customizações relacionadas à segurança.
O host do Developer para System z consiste em vários componentes que interagem para oferecer acesso ao cliente para os serviços e dados do host. Entender o design desses componentes pode ajudá-lo a tomar as decisões corretas de configuração.
Os seguintes tópicos são abordados neste capítulo:
A Figura 41 mostra uma visão geral generalizada do layout do Developer para System z em seu sistema host.
A descrição no parágrafo e a lista mostram a função central designada ao RSE. Com algumas exceções, toda a comunicação do cliente passa pelo RSE. Isso é permitido para uma configuração fácil da rede relacionada à segurança, uma vez que apenas um conjunto limitado de portas é usado para a comunicação entre o cliente e o host.
Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon atua como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamento processam as cargas de trabalho do cliente. Com base nos valores definidos no arquivo de configuração rsed.envvars e na quantidade real de conexões do cliente, vários espaços de endereço do conjunto de encadeamento podem ser iniciados pelo daemon.
A Figura 42 mostra uma visualização básica do uso de recursos (processos e armazenamento) pelo RSE.
O RSE é um aplicativo Java, que significa que ele está ativo no ambiente z/OS UNIX. Isso é permitido para facilitar o porting em diferentes plataformas host e comunicação direta com o cliente do Developer para System z, que é também um aplicativo Java (baseado na estrutura do Eclipse). Portanto, o conhecimento básico de como z/OS UNIX e Java funcionam é muito útil quando você tenta compreender o Developer para System z.
No z/OS UNIX, um programa é executada em um processo, que é identificado por um PID (ID do Processo). Cada programa é ativado em seu próprio processo, portanto invocar outro programa criará um novo processo. O processo que iniciou um processo é referenciado com um PPID (PID Pai), o novo processo é chamado de processo-filho. O processo-filho pode ser executado no mesmo espaço de endereço ou pode ser gerado (criado) em um novo espaço de endereço. Um novo processo que é executado no mesmo espaço de endereço pode ser comparado a executar um comando em TSO, enquanto aquele gerado em um novo espaço de endereço é semelhante a enviar uma tarefa em lote.
Observe que um processo pode ser único ou multiencadeado. Em um aplicativo multiencadeado (como o RSE), os diferentes encadeamentos competem por recursos do sistema como se eles fossem espaços de endereço separados (com menos gasto adicional).
Mapeando essas informações de processo para a amostra RSE na Figura 42, obtivemos o seguinte fluxo:
Aplicativos Java, como o RSE, não alocam armazenamento diretamente, mas usam serviços de gerenciamento de memória Java. Esses serviços, como alocação de armazenamento, liberação de armazenamento e coleta de lixo, funcionam dentro dos limites do heap Java. Os tamanhos mínimo e máximo do heap é definido (implicitamente ou explicitamente) durante a inicialização de Java.
Isso significa que a obtenção da maioria do tamanho de espaço de endereço disponível é um ato de equilíbrio da definição de um tamanho grande de heap enquanto deixa espaço suficiente para o z/OS armazenar uma quantidade variável de blocos de controle do sistema (dependendo do número de encadeamentos ativos).
O Figura 43 mostra uma visão geral básica do dono das credenciais de segurança usadas por várias tarefas do Developer para System z.
A propriedade de uma tarefa pode ser dividida em duas seções. As tarefas iniciadas são propriedades do ID do usuário que é designado para a tarefa iniciada em seu software de segurança. Todos as outras tarefas, com os conjuntos de encadeamentos (RSEDx) como exceção, são propriedades do ID de usuário cliente.
O Figura 43 mostra as tarefas iniciadas do Developer para system z (LOCKD, JMON and RSED, as tarefas iniciadas de amostra e os serviços do sistema com os quais o Developer para System z se comunica. O Application Deployment Manager (ADM) é ativo dentro de uma região CICS. O FMNCAS é a tarefa iniciada do File Manager. A tag USS REXEC representa o serviço do z/OS UNIX REXEC (ou SSH).
O daemon RSE (RSED) cria um ou mais espaços de endereço do conjunto de encadeamentos (RSEDx) para processar os pedidos dos clientes. Cada conjunto de encadeamentos RSE suporta múltiplos clientes e é propriedade do mesmo usuário como um daemon RSE. Cada cliente possui seus próprios encadeamentos dentro de um conjunto de encadeamentos, e estes encadeamentos são propriedades do ID de usuário cliente.
Dependendo das ações concluídas pelo cliente, um ou mais espaços de endereço adicionais podem ser iniciados, todos propriedades do ID de usuário cliente, para executar uma ação solicitada. Estes espaços de endereço podem ser uma tarefa em lote MVS, uma transação APPC ou um processo-filho do z/OS UNIX. Note que um processo-filho do z/OS UNIX é ativo em um iniciador z/OS UNIX (BPXAS) e o processo-filho aparece como uma tarefa iniciada no JES.
A criação destes espaços de endereços é mais frequentemente acionada por um encadeamento do usuário em um conjunto de encadeamentos, diretamente ou usando serviços do sistema como ISPF. Mas o espaço de endereço também poderia ser criado por um terceiro. Por exemplo, o File Manager iniciará um espaço de endereço novo para cada conjunto de dados (ou membro) que ele tenha que processar em nome do Developer para System z. z/OS UNIX REXEC ou SSH são envolvidos ao iniciar as construções no z/OS UNIX.
Os espaços de endereços do usuário terminam com a conclusão da tarefa ou quando um cronômetro de inatividade vence. As tarefas iniciadas permanecem ativas. Os espaços de endereços listados em Figura 43 permanecem no sistema tempo suficiente para serem visíveis. Porém, é recomendável estar ciente que, devido a maneira com que o z/OS UNIX é designado, há também vários espaços de endereços temporários de curta duração.
A Figura 44 mostra uma visão geral esquemática de como um cliente se conecta ao host usando o Developer para System z. Ela explica também resumidamente como os PassTickets são usados.
A descrição acima mostra o design orientado a encadeamentos do RSE. Em vez de iniciar um espaço de endereço por usuário, vários usuários são atendidos por um espaço de endereço de um único conjunto de encadeamento. Dentro do conjunto de encadeamento, cada extrator (um serviço específico do usuário) fica ativo em seu próprio encadeamento com o contexto de segurança do usuário designado a ele, garantindo uma configuração segura. Esse design acomoda um grande número de usuários com uso de recursos limitado, mas não significa que cada cliente usará vários encadeamentos (16 ou mais, dependendo das tarefas executadas).
Do ponto de vista da rede, o Developer para system z atua de forma semelhante ao FTP no modo passivo. O cliente se conecta a um ponto focal (daemon RSE) e, em seguida, elimina a conexão e reconecta ao número de porta fornecido pelo ponto focal. A seguinte lógica controla a seleção da porta que é usada na segunda conexão:
O uso de PassTickets para todos os serviços z/OS que exigem autenticação permite que o Developer para System z invoque esses serviços à vontade, sem armazenar a senha ou solicitá-la constantemente ao usuário. O uso de PassTickets para todos os serviços z/OS permite também métodos de autenticação alternativos durante o logon, como senhas únicas e certificados X.509.
O Figura 45 mostra uma visão geral esquemática de como um daemon de bloqueio determina qual o cliente do Developer para System z possui um bloqueio do conjunto de dados.
Com uma configuração de um único servidor de Developer para System z, em que vários usuários são designados a um único espaço de endereço do conjunto de encadeamento, o z/OS perdeu a capacidade de controlar quem possui um bloqueio em um conjunto de dados ou membro. Os comandos do sistema param no nível de espaço de endereço, que é o conjunto de encadeamento.
Para especificar esse problema, o Developer para System z fornece o daemon de bloqueio. O daemon de bloqueio pode controlar todos os bloqueios de conjuntos de dados/membros realizados pelos usuários do RSE, bem como os bloqueios realizados por outros produtos, como o ISPF.
O servidor RSE registra um usuário recém-conectado no daemon de bloqueio. As informações de registro contêm o Identificador de Espaço de Endereço (que é o ASID do conjunto de encadeamento), o ID (específico do usuário) do Task Control Block (TCB) e o ID do usuário.
Observe que o registro é feito apenas no momento da conexão, de modo que todos os usuários ativos do RSE antes de o daemon de bloqueio ser iniciado (ou reiniciado) não serão registrados.
Quando o daemon de bloqueio recebe uma consulta de conjunto de dados (por meio de um comando do operador de consulta de modificação ou do cliente por meio do servidor RSE), o daemon varre as filas Global Resource Serialization (GRS) do sistema. Se o ASID e o TCB corresponderem ao de um usuário registrado, o ID do usuário é retornado como um proprietário de bloqueio. Caso contrário, o nome da tarefa/ID do usuário relacionado ao ASID é retornado como proprietário de bloqueio.
Uma mensagem do console (FEK513W) com as informações de registro será exibida se o registro falhar. Isso permite que um operador corresponda os valores em relação à saída de um comando do operador DISPLAY GRS,RES=(*,dataset*) a fim de localizar o proprietário do bloqueio.
Sob circunstâncias normais, um conjunto de dados ou um membro fica bloqueado quando o cliente o abrir no modo de edição, e liberado quando o cliente fechar a sessão de edição.
Determinadas condições de erro podem evitar que esse mecanismo funcione como designado. Nesse caso, o usuário que mantém o bloqueio pode ser cancelado usando o comando do operação cancelar modificação do RSE, conforme descrito no Comandos do Operador. Os bloqueios do conjunto de dados ativo que pertencem a esse usuário são liberados durante o processo.
O Figura 46 mostra uma visão geral dos diretórios do z/OS UNIX usados pelo Developer para System z. A seguinte lista descreve cada diretório tocado pelo Developer para System z, como o local pode ser alterado e quem mantém os dados dentro dele.
Os dados em alguns diretórios, como /var/rdz/projects/, são mantidos por administradores que não são de sistema, como gerentes de projetos, que podem não ter muitos privilégios de atualização em z/OS UNIX. Se houver apenas um ID de usuário mantendo os arquivos, isso não será problema depois que o ID do usuário tiver se tornado proprietário do diretório e de tudo no diretório.
chown -R IBMUSER /var/rdz/projects/
Quando vários IDs de usuário precisarem de permissão de atualização no diretório, você poderá trabalhar com os bits de permissão do grupo.
ADDGROUP RDZPROJ OMVS(GID(1200)) CONNECT IBMUSER GROUP(RDZPROJ) ALTUSER IBMUSER DFLTGRP(RDZPROJ)
chgrp -R IBMUSER /var/rdz/projects/
chmod -R 775 /var/rdz/projects/
Ao contrário dos aplicativos tradicionais z/OS, o Developer para System z não é um aplicativo monolítico que possa ser identificado facilmente para Workload Manager (WLM). O Developer para System z consiste de vários componentes que interagem para fornecer ao cliente acesso para os serviços e dados do host. Como descrito em Entendimento do Developer para System z, alguns destes serviços estão ativos em espaços de endereços diferentes, resultando em classificações WLM diferentes.
Os seguintes tópicos são abordados neste capítulo:
O Figura 47 mostra uma visão geral básica dos subsistemas por meio dos quais cargas de trabalho são apresentadas para WLMDeveloper para System z.
O Application Deployment Manager (ADM) é ativo dentro de uma região CICS e, por essa razão, seguirá as regras de classificação CICS no WLM.
O daemon RSE (RSED), daemon de bloqueio (LOCKD) e o JES Job Monitor (JMON) são Developer para System z tarefas iniciadas (ou tarefas em lote de longa execução), cada uma com seu espaço de endereço individual.
Como documentado em RSE como um Aplicativo Java, o daemon RSE gera um processo-filho para cada servidor de conjunto de encadeamentos RSE (que suporta um número variável de clientes). Cada conjunto de encadeamentos é ativo em um espaço de endereço separado (usando um inicializador z/OS UNIX, BPXAS). Porque estes são processos gerados, eles são classificados usando as regras de classificação WLM OMVS, e não as regras de classificação de tarefa iniciada.
Os clientes que estão ativos em um conjunto de encadeamentos podem criar uma infinidade de outros espaços de endereços, dependendo das ações realizadas pelos usuários. Dependendo da configuração de Developer para System z algumas cargas de trabalho, como o o serviço TSO Commands (TSO cmd) ou CARMA, podem executar em subsistemas diferentes.
Os espaços de endereços listados em Figura 47 permanecem no sistema tempo suficiente para serem visíveis, mas é recomendável estar ciente que, devido a maneira como o z/OS UNIX é designado, há também vários espaços de endereços temporários de curta duração. Estes espaços de endereços temporários estão ativos nos subsistemas OMVS.
Note que enquanto os conjuntos de encadeamento RSE usam o mesmo ID do usuário e um nome de tarefa similar como o daemon RSE, todos os espaços de endereços iniciados por um conjunto de encadeamento são de propriedade do ID do usuário do cliente solicitando a ação. O ID de usuário cliente também é usado como (parte do) nome de tarefa para todos os espaços de endereços baseados em OMVS, estabelecidos pelo conjunto de encadeamentos.
Mais espaços de endereços são criados por outros serviços que o Developer para System z usa, como o File Manager (FMNCAS) ou z/OS UNIX REXEC (USS build).
O WLM usa regras de classificações para mapear o trabalho entrando no sistema para uma classe de serviço. Esta classificação é baseada nos qualificadores de trabalho. O primeiro qualificador (obrigatório) é um tipo de subsistema que recebe o pedido de trabalho. O Tabela 29 lista os tipos de subsistema que podem receber cargas de trabalho Developer para System z.
Tipos de subsistemas | Descrição do trabalho |
---|---|
ASCH | Os pedidos de trabalho incluem todos os programas de transação APPC planejados pelo planejador de transação da IBM-supplied APPC/MVS, ASCH. |
CICS | Os pedidos de trabalho incluem todas as transações processadas pelo CICS. |
JES | Os pedidos de trabalho incluem todos os trabalhos que o JES2 ou JES3 iniciam. |
OMVS | Os pedidos de trabalho incluem o trabalho processado nos espaços de endereços filhos bifurcados no z/OS UNIX System Services. |
STC | Os pedidos de trabalho incluem todo o trabalho iniciado pelos comandos START e MOUNT. O STC também inclui os espaços de endereços do componente do sistema. |
Tabela 30Tabela 2 lista qualificadores adicionais que podem ser usados para designar uma carga de trabalho para uma classe de serviço especifica. Consulte MVS Planejamento: Gerenciamento de Carga de Trabalho (SA22-7602) para obter detalhes adicionais sobre os qualificadores de trabalho listados.
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | Dados da Conta | x | x | x | x | |
LU | Nome LU (*) | x | ||||
PF | Perform (*) | x | x | |||
PRI | Prioridade | x | ||||
SE | Nome de Ambiente de Planejamento | x | ||||
SSC | Nome de Coleta de Subsistema | x | ||||
SI | Instância de Subsistema (*) | x | x | |||
SPM | Parâmetro de Subsistema | x | ||||
PX | Nome Sysplex | x | x | x | x | x |
SY | Nome do Sistema (*) | x | x | x | ||
TC | Transação/Classe de Trabalho (*) | x | x | |||
TN | Transação/Nome do Trabalho (*) | x | x | x | x | x |
UI | ID do usuário (*) | x | x | x | x | x |
Como documentado em Classificação de Carga de Trabalho, o Developer para System z cria tipos diferentes de cargas de trabalho no seu sistema. Estas diferentes tarefas comunicam-se entre si, o que implica que o tempo decorrido real tornar-se importante para evitar problemas de tempo limite para as conexões entre as tarefas. Como resultado, Developer para System z é recomendável que as tarefas sejam colocadas em classes de serviço de alto desempenho ou em classes de serviço de desempenho moderado com uma alta prioridade.
Uma revisão, e possivelmente uma atualização, dos seus objetivos WLM atuais é, por essa razão, aconselhado. Isto é especialmente verdadeiro para empresas tradicionais MVS novas no que diz respeito às cargas de trabalho OMVS de tempo crítico.
O Tabela 31 lista os espaços de endereços que são usados pelo Developer para System z. O z/OS UNIX subsituirá "x" na coluna "Nome da Tarefa" por um número aleatório de 1 dígito.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
JES Job Monitor | JMON | STC |
Daemon de bloqueio | LOCKD | STC |
Daemon RSE | RSED | STC |
Conjunto de encadeamento do RSE | RSEDx | OMVS |
ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid>x | OMVS |
Serviço do TSO Commands (APPC) | FEKFRSRV | ASCH |
CARMA (batch) | CRA<port> | JES |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF Client Gateway) | <userid> e <userid>x | OMVS |
Build MVS (tarefa em lote) | * | JES |
Construção do z/OS UNIX build (comandos do shell) | <userid>x | OMVS |
Shell z/OS UNIX | <userid> | OMVS |
Tarefa do File Manager | <userid>x | OMVS |
Application Deployment Manager | CICSTS | CICS |
As seguintes considerações gerais do WLM podem ajudar a definir apropriadamente as definições de objetivos corretas para Developer para System z:
Quando usar os objetivos de tempo de resposta:
Quando usar objetivos de velocidade:
Todas as tarefas iniciadas, daemon RSE, daemon de Bloqueio e JES Job Monitor do Developer para System z estão atendendo pedidos de clientes em tempo real.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
JES Job Monitor | JMON | STC |
Daemon de bloqueio | LOCKD | STC |
Daemon RSE | RSED | STC |
O JES Job Monitor fornece todos os serviços JES relacionados, como submeter tarefas, navegar em arquivos de spool e executar comandos do operador JES. É recomendável especificar um objetivo de velocidade de um período, e com alta prioridade, porque a tarefa não relata transações individuais para o WLM. O uso de recurso depende fortemente das ações do usuário e, por essa razão, vai variar, mas é esperado que seja de mínimo a moderado.
O daemon de bloqueio consulta as tabelas de enfileirar do GRS sobre o pedido do cliente e operador e compara o resultado com os usuários conhecidosDeveloper para System z. É recomendável que você especifique um objetivo de velocidade de um período e com prioridade alta porque a tarefa não relata transações individuais no WLM. É esperado ser mínimo o uso de recurso.
O daemon RSE trata da criação do logon e autenticação do cliente e gerencia os diferentes conjuntos de encadeamentos RSE. É recomendável que você especifique um objetivo de velocidade de um período e com prioridade alta porque a tarefa não relata transações individuais no WLM. Espera-se ser mínimo o uso de recurso, com um pico no começo do dia útil.
As cargas de trabalho OMVS podem ser divididas em dois grupos, conjuntos de encadeamentos RSE e todo o resto. Isto porque todas as cargas de trabalho, exceto os conjuntos de encadeamentos RSE, usam o ID de usuário cliente como base para o nome do espaço de endereço. (O z/OS UNIX substituirá o "x" na coluna "Nome da Tarefa" por um número aleatório de 1 dígito).
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
Conjunto de encadeamento do RSE | RSEDx | OMVS |
ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid>x | OMVS |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF Client Gateway) | <userid> e <userid>x | OMVS |
Construção do z/OS UNIX build (comandos do shell) | <userid>x | OMVS |
Shell z/OS UNIX | <userid> | OMVS |
Tarefa do File Manager | <userid>x | OMVS |
Um conjunto de encadeamentos RSE é como o coração e o cérebro do Developer para System z. Quase todos os dados circulam por aqui e os mineradores (encadeamentos específicos do usuário) dentro do conjunto de encadeamentos controlam as ações da maioria das outras tarefas relacionadas do Developer para System z. É recomendável que você especifique um objetivo de velocidade de um período e com prioridade alta porque a tarefa não relata transações individuais no WLM. O uso de recursos depende fortemente das ações do usuário e, por essa razão, vai variar, mas é esperado ser substancial.
Todas as cargas de trabalho restantes terminarão na mesma classe de serviço devido a uma convenção de nomenclatura do espaço de endereço comum. É recomendável especificar um objetivo de período múltiplo para esta classe de serviço. Os primeiros períodos deveriam ser de objetivos de tempo de resposta percentil e de alto desempenho, enquanto que o último período deveria possuir um objetivo de velocidade de desempenho moderado. Algumas cargas de trabalho, como a ISPF Client Gateway, relatarão transações individuais para o WLM, enquanto outras não.
O ISPF Client Gateway é um serviço ISPF invocado pelo Developer para System z para executar comandos TSO e ISPF não interativos. Isto inclui comandos explícitos emitidos pelo cliente e também os comandos implícitos emitidos pelo Developer para System z, como obter uma lista de membros PDS. O uso de recursos depende fortemente das ações do usuário, e, por essa razão, vai variar, mas é esperado ser o mínimo.
O CARMA é um servidor Developer para System z opcional usado para interagir com Software Configuration Managers (SCMs), baseados em host, tais como o CA Endevor® SCM. O Developer para System z permite diferentes métodos de inicialização para um servidor CARMA, alguns dos quais transformam-se em uma carga de trabalho OMVS. O uso de recursos depende fortemente das ações do usuário, e, por essa razão, vai variar, mas é esperado ser o mínimo.
Quando um cliente inicia uma construção para um projeto z/OS UNIX, o z/OS UNIX REXEC (ou SSH) iniciará uma tarefa que executa um número de comandos do shell z/OS UNIX para executar a construção. O uso dos recursos depende fortemente das ações do usuário e, por essa razão, vai variar, mas é esperado ser de moderado a substancial, dependendo do tamanho do projeto.
Esta carga de trabalho processa os comandos do shell z/OS UNIX que são emitidos pelo cliente. O uso dos recursos depende fortemente das ações do usuário, e, por essa razão, vai variar, mas é esperado ser o mínimo.
Embora não sejam espaços de endereços Developer para System z, os processos-filho do File Manager gerados são listados aqui porque eles podem ser iniciados por pedido de um cliente Developer para System z e estas tarefas usam a mesma convenção de nomenclatura como tarefas Developer para System z. Estas tarefas do File Manager processam ações do conjunto de dados não triviais do MVS, como edição formatada de um arquivo VSAM. O uso de recursos depende grandemente das ações do usuário e, por essa razão, vai variar, mas é esperado ser de mínimo a moderado.
Os processos em lote do JES gerenciado são usados de várias maneiras pelo Developer para System z. O uso mais comum é para construções MVS, onde uma tarefa é submetida e monitorada para determinar quando ela termina. Mas o Developer para System z também poderia iniciar um servidor CARMA em lote e comunicar-se com ele usando TCP/IP.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
CARMA (batch) | CRA<port> | JES |
Build MVS (tarefa em lote) | * | JES |
O CARMA é um servidor Developer para System z opcional usado para interagir com Software Configuration Managers (SCMs), baseados em host, tais como o CA Endevor® SCM. O Developer para System z permite diferentes métodos de inicialização para um servidor CARMA, alguns dos quais transformam-se em uma carga de trabalho JES. É recomendável especificar um objetivo de velocidade de um período, e com alta prioridade, porque a tarefa não relata transações individuais para o WLM. O uso de recursos depende fortemente das ações do usuário, e, por essa razão, vai variar, mas é esperado ser o mínimo.
Quando o cliente inicia uma construção para um projeto MVS, Developer para System z iniciará um trabalho em lote para executar a construção. O uso dos recursos depende fortemente das ações do usuário e, por essa razão, vai variar, mas é esperado ser de moderado a substancial, dependendo do tamanho do projeto. Estratégias diferentes de objetivos de desempenho moderado é aconselhável, dependendo das circunstâncias locais.
Nas versões atuais do Developer para System z, o ISPF Client Gateway é usado para executar comandos TSO e ISPF não interativos. Devido a razões históricas, o Developer para System z também suporta executar estes comandos por meio de uma transação APPC.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
Serviço do TSO Commands (APPC) | FEKFRSRV | ASCH |
O serviço TSO Commands pode ser iniciado como uma transação APPC pelo Developer para System z para executar os comandos TSO e ISPF não interativos. Isto inclui os comandos explícitos emitidos pelo cliente e também os comandos implícitos emitidos pelo Developer para System z, como obter uma lista de membros PDS. É recomendável especificar um objetivo de período múltiplo para esta classe de serviço. Para os primeiros períodos, é recomendável especificar objetivos de tempo de resposta percentil e de alto desempenho. Para o período final, é recomendável especificar um objetivo de velocidade de desempenho moderada. O uso dos recursos depende fortemente das ações do usuário, e, por essa razão, vai variar, mas é esperado ser o mínimo.
O Application Deployment Manager é um servidor do Developer para System z opcional ativo dentro de uma região do CICS Transaction Server.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
Application Deployment Manager | CICSTS | CICS |
O servidor opcional do Application Deployment Manager, que é ativo dentro de uma região CICSTS, permite que você transfira com segurança tarefas de gerenciamento CICSTS selecionadas para desenvolvedores. O uso dos recursos depende fortemente das ações do usuário, e, por essa razão, vai variar, mas é esperado ser o mínimo. O tipo de classe de serviço que você deveria usar depende das outras transações ativas nesta região CICS e, por essa razão, isso não é discutido em detalhe.
O WLM suporta múltiplos tipos de gerenciamento que podem ser usado para CICS:
O objetivo é configurado para uma classe de serviço que gerencia os espaços de endereço CICS. Só é possível usar um objetivo de velocidade de execução para esta classe de serviço. O WLM usa as regras de classificação JES ou STC para os espaços de endereços, mas não usa as regras de classificação do subsistema CICS para transações.
O objetivo de tempo de resposta pode ser configurado em uma classe de serviço designada para uma única transação ou um grupo de transações. O WLM usa as regras de classificações JES ou STC para os espaços de endereços e as regras de classificação de subsistema CICS para transações.
Conforme explicado no Entendimento do Developer para System z, o RSE (Remote Systems Explorer) é o núcleo do Developer para System z. Para gerenciar as conexões e as cargas de trabalho dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon atua como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamento processam as cargas de trabalho do cliente.
Isso torna o RSE um alvo principal para o ajuste da configuração do Developer para System z. Entretanto, a manutenção de centenas de usuários, cada um usando 16 ou mais encadeamentos, uma determinada quantidade de armazenamento e possivelmente 1 ou mais espaços de endereço exigem configuração adequada do Developer para System z e do z/OS.
Os seguintes tópicos são abordados neste capítulo:
Use as informações desta seção para avaliar o uso normal e máximo de recursos pelo Developer para System z, para que você possa planejar a configuração do sistema de acordo.
Ao usar os números e as fórmula apresentados nesta seção para definir os valores dos limites do sistema, lembre-se de que você está trabalhando com estimativas bastante precisas. Deixe margem suficiente ao configurar os limites do sistema para permitir o uso de recursos por tarefas temporárias e outras tarefas, ou por usuários que se conectam várias vezes ao host simultaneamente. (Por exemplo, por meio de RSE e de TN3270).
As tabelas a seguir oferecem uma visão geral do número de espaços de endereços, processos e encadeamentos usados pelo Developer para System z. Mais detalhes sobre os números apresentados aqui podem ser encontrados nas próximas seções:
A Tabela 37 fornece uma visão geral dos recursos principais usados pelas tarefas iniciadas do Developer para System z. Esses recursos são alocados apenas uma vez. Eles são compartilhados entre todos os clientes do Developer para System z.
Tarefa iniciada | Espaços de endereço | Processos | Encadeamentos |
---|---|---|---|
JMON | 1 | 1 | 3 |
LOCKD | 1 | 3 | 10 |
RSED | 1 | 3 | 11 |
RSEDx | (a) | 2 | 10 |
A Tabela 38 fornece uma visão geral dos recursos principais usados pelo software obrigatório. Esses recursos são alocados para cada cliente do Developer para System z que invoca a função relacionada.
Software obrigatório | Espaços de endereço | Processos | Encadeamentos |
---|---|---|---|
ISPF Client Gateway | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
File Manager | 1 | 1 | 2 |
A Tabela 39 fornece uma visão geral dos recursos principais usados por cada cliente do Developer para System z ao executar a função especificada. Valores não-numéricos, como ISPF, são uma referência ao valor correspondente na Tabela 38.
Ação do usuário
|
Espaços de endereço
ID do
usuário |
Processos
ID do
usuário |
Encadeamentos ID do usuário RSEDx JMON |
||
---|---|---|---|---|---|
Logon | - | - | - | 16 | 1 |
Cronômetro para tempo limite inativo | - | - | - | 1 | - |
Expandir PDS(E) | ISPF | ISPF | ISPF | - | - |
Abrir conjunto de dados | ISPF | ISPF | ISPF | - | - |
Comando TSO | ISPF | ISPF | ISPF | - | - |
Shell do z/OS UNIX | 1 | 1 | 1 | 6 | - |
Build MVS | 1 | - | - | - | - |
Build z/OS UNIX | 3 | 3 | 3 | - | - |
CARMA (batch) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 4 | - |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
Integração do File Manager | ISPF + FM | ISPF + FM | ISPF + FM | - | - |
Integração do Analisador de Falha | - | - | - | - | - |
A Tabela 40 lista os espaços de endereço que são usados pelo Developer para System z, em que "u" na coluna "Contagem" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente que usam a função. O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.
Contador | Descrição | Nome da tarefa | Compar
tilhado |
Termina após |
---|---|---|---|---|
1 | JES Job Monitor | JMON | SIM | Nunca |
1 | Daemon de bloqueio | LOCKD | SIM | Nunca |
1 | Daemon RSE | RSED | SIM | Nunca |
(a) | Conjunto de encadeamento do RSE | RSEDx | SIM | Nunca |
lu | ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid>x | Não | 15 minutos ou no logoff do usuário |
lu | Serviço do TSO Commands (APPC) | FEKFRSRV | Não | 60 minutos ou efetuar logoff do usuário |
lu | CARMA (batch) | CRA<port> | Não | 7 minutos ou no logoff do usuário |
lu | CARMA (crastart) | <userid>x | Não | 7 minutos ou no logoff do usuário |
4u | CARMA (ispf) | (1)<userid> ou (3)<userid>x | Não | 7 minutos ou no logoff do usuário |
(b) | Uso simultâneo do ISPF Client Gateway por 1 usuário | <userid>x | Não | Conclusão da tarefa |
1u | Build MVS (tarefa em lote) | * | Não | Conclusão da tarefa |
3u | Build z/OS UNIX (comandos do shell) | <userid>x | Não | Conclusão da tarefa |
1u | Shell do z/OS UNIX | <userid> | Não | Logoff do usuário |
(c) | File Manager | <userid>x | Não | Conclusão da tarefa |
Use a fórmula da Figura 48 para avaliar o número máximo de espaços de endereço usado pelo Developer para System z.
Em que,
X | SCLMDT | TSO por meio do Client Gateway | TSO por meio do APPC |
---|---|---|---|
1 | Não | Não | SIM |
1 | Não | SIM | Não |
1 | SIM | SIM | Não |
S | |
---|---|
0 | Sem CARMA |
1 | CARMA (batch) |
1 | CARMA (crastart) |
4 | CARMA (ispf) |
Use a fórmula da Figura 49 para avaliar o número máximo de espaços de endereço usados por um cliente do Developer para System z (sem contar os espaços de endereço temporários não documentados).
Em que,
As definições na Tabela 41 podem limitar o número real de espaços de endereço.
Local | Limite | Recursos afetados |
---|---|---|
rsed.envvars | maximum.threadpool.process | Limita o número de conjuntos de encadeamento do RSE |
IEASYMxx | MAXUSER | Limita o número de espaços de endereço |
ASCHPMxx | MAX | Limita o número de iniciadores APPC para o serviço TSO Commands (APPC) |
A Tabela 42 lista o número de processos por espaço de endereço que é usado pelo Developer para System z. "u" nos "Espaços de Endereço" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função.
Processos | Espaços de endereço | Descrição | ID do usuário |
---|---|---|---|
1 | 1 | JES Job Monitor | STCJMON |
3 | 1 | Daemon de bloqueio | STCLOCK |
3 | 1 | Daemon RSE | STCRSE |
2 | (a) | Conjunto de encadeamento do RSE | STCRSE |
2 | (b) | ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid> |
1 | 1u | Serviço do TSO Commands (APPC) | <userid> |
1 | 1u | CARMA (batch) | <userid> |
1 | 1u | CARMA (crastart) | <userid> |
1 | 1u | CARMA (ispf) | <userid> |
1 | 3u | Build z/OS UNIX (comandos do shell) | <userid> |
1 | 1u | Shell do z/OS UNIX | <userid> |
1 | (c) | File Manager | <userid> |
(5) | (u) | SCLM Developer Toolkit | <userid> |
Use a fórmula da Figura 50 para avaliar o número máximo de processos usados pelo Developer para System z.
Em que,
X | SCLMDT | TSO por meio do Client Gateway | TSO por meio do APPC |
---|---|---|---|
1 | Não | Não | SIM |
2 | Não | SIM | Não |
7 | SIM | SIM | Não |
S | |
---|---|
0 | Sem CARMA |
1 | CARMA (batch) |
1 | CARMA (crastart) |
4 | CARMA (ispf) |
Use a fórmula da Figura 51 para avaliar o número máximo de processos usados por um cliente do Developer para System z (sem contar os processos temporários não documentados).
Em que,
As definições na Tabela 43 podem limitar o número real de processos.
Local | Limite | Recursos afetados |
---|---|---|
BPXPRMxx | MAXPROCSYS | Limita o número total de processos |
BPXPRMxx | MAXPROCUSER | Limita o número de processos por UID do z/OS UNIX |
Nota:
A Tabela 44 lista o número de encadeamentos usados pelas funções selecionadas do Developer para System z. "u" nas colunas "Encadeamentos" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função. A contagem de encadeamento é listada por processo, à medida que os limites são definidos neste nível.
Encadeamentos |
ID do usuário | Descrição | ||
---|---|---|---|---|
RSEDx | Ativado | Autoinicia
lização |
||
- | 3 + 1u | - | STCJMON | JES Job Monitor |
- | 10 | 2 | STCLOCK | Daemon de bloqueio |
- | 11 | 2 | STCRSE | Daemon RSE |
10 (a) + 16u | - | 1 (a) | STCRSE | Conjunto de encadeamento do RSE |
- | 4u (b) | 1u (b) | <userid> | ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) |
- | 2u | - | <userid> | Serviço do TSO Commands (APPC) |
1u | 2u | - | STCRSE e <userid> | CARMA (batch) |
4u | 2u | - | STCRSE e <userid> | CARMA (crastart) |
5u | 4u | 3u | STCRSE e <userid> | CARMA (ispf) |
- | 1u (d) | 2u | <userid> | Build z/OS UNIX (comandos do shell) |
6u | 1u | - | STCRSE e <userid> | Shell do z/OS UNIX |
- | 2u (c) | - | <userid> | File Manager |
- | (5) | - | <userid> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Cronômetro para tempo limite inativo |
Use a fórmula da Figura 52 para avaliar o número máximo de encadeamentos usado por um conjunto de encadeamento do RSE. Use a fórmula da Figura 53 para avaliar o número máximo de encadeamentos usados pelo JES Job Monitor.
Em que,
X | SCLMDT | TSO por meio do Client Gateway | TSO por meio do APPC | Tempo limite |
---|---|---|---|---|
0 | Não | Não | SIM | Não |
0 | Não | SIM | Não | Não |
0 | SIM | SIM | Não | Não |
1 | Não | Não | SIM | SIM |
1 | Não | SIM | Não | SIM |
1 | SIM | SIM | Não | SIM |
S | |
---|---|
0 | Sem CARMA |
1 | CARMA (batch) |
4 | CARMA (crastart) |
5 | CARMA (ispf) |
As definições na Tabela 45 podem limitar o número real de encadeamentos em um processo, o que é da maior importância para os conjuntos de encadeamentos do RSE.
Local | Limite | Recursos afetados |
---|---|---|
BPXPRMxx | MAXTHREADS | Limita o número de encadeamentos em um processo. |
BPXPRMxx | MAXTHREADTASKS | Limita o número de tarefas MVS em um processo. |
BPXPRMxx | MAXASSIZE | Limita o tamanho do espaço de endereço e, portanto, o armazenamento disponível para blocos de controle relacionados ao encadeamento. |
rsed.envvars | Xmx | Define o tamanho máximo do heap Java. Esse armazenamento é reservado e, portanto, não está mais disponível para blocos de controle relacionados ao encadeamento. |
rsed.envvars | maximum.clients | Limita o número de clientes (e, portanto, seus encadeamentos) em um conjunto de encadeamento do RSE. |
rsed.envvars | maximum.threads | Limita o número de encadeamentos do cliente em um conjunto de encadeamento do RSE. |
FEJJCNFG | MAX_THREADS | Limita o número de encadeamentos no JES Job Monitor. |
O RSE é um aplicativo Java, que implica que o planejamento de uso de armazenamento (memória) do Developer para System z deve levar dois limites de alocação de armazenamento em consideração, o tamanho de heap Java e o tamanho do Espaço de Endereço.
Java oferece vários serviços para facilitar os esforços de codificação para aplicativos Java. Um desses serviços é o gerenciamento de armazenamento.
O gerenciamento de armazenamento Java aloca grandes blocos de armazenamento e os usa para pedidos de armazenamento pelo aplicativo. Esse armazenamento gerenciado por Java é chamado de heap Java. A coleta de lixo periódica (desfragmentação) reclama o espaço não utilizado no heap e reduz o seu tamanho.
O tamanho de heap máximo Java é definido em rsed.envvars com a diretiva Xmx. Se essa diretiva não for especificada, Java usará um tamanho padrão de 64 MB.
Cada conjunto de armazenamento do RSE (que atende às ações do cliente) é um aplicativo Java separado e, portanto, tem um heap Java pessoal. Observe que todos os conjuntos de encadeamento usam o mesmo arquivo de configuração rsed.envvars e, portanto, têm o mesmo limite de tamanho de heap Java.
O uso do conjunto de encadeamento do heap Java depende muito das ações executadas pelos clientes conectados. O monitoramento regular do uso de heap é necessário para definir o limite de tamanho de heap ideal. Use o comando do operador modificar processo de exibição para monitorar o uso de heap Java por conjuntos de encadeamento do RSE.
Todos os aplicativos z/OS, incluindo aplicativos Java, estão ative dentro de um espaço de endereço, e estão, portanto, ligados pelas limitações de tamanho do espaço de endereço.
O tamanho do espaço de endereço desejado é especificado durante a inicialização, por exemplo, com o parâmetro REGION em JCL. Entretanto, as configurações do sistema podem limitar o tamanho do espaço de endereço real. Consulte Tamanho do Espaço de Endereço para saber mais sobre esses limites.
Os conjuntos de encadeamento do RSE herdam os limites de tamanho do espaço de endereço do daemon RSE. O tamanho do espaço de endereço deve ser suficiente para abrigar o heap Java, o próprio Java, as áreas de armazenamento comuns e todos os blocos de controle que o sistema cria para suportar a atividade do conjunto de encadeamento, como um TCB (Bloco de Controle de Tarefa) por encadeamento. Observe que algum desse uso de armazenamento está abaixo da linha de 16 MB.
Você deve monitorar o tamanho do espaço de endereço real antes de alterar quaisquer configurações que o influenciem, como alterar o tamanho do heap Java ou a quantidade de usuários suportada por um único conjunto de encadeamento. Use o software de monitoramento regular do sistema para controlar o uso de armazenamento real pelo Developer para system z. Se você não tiver uma ferramenta de monitoramento dedicada, então informações básicas podem ser reunidas com ferramentas como a visualização SDSF DA ou TASID (uma ferramenta de informações do sistema como elas estão armazenadas no banco de dados disponível por meio da página da Web "Support and downloads" do ISPF).
Conforme mencionado antes, o uso de armazenamento real pelo Developer para System z é altamente influenciado pela atividade do usuário. Algumas ações usam uma quantidade fixa de armazenamento (por exemplo, logon), enquanto outras são variáveis (por exemplo, listando conjuntos de dados com um qualificador de alto nível especificado).
Observe que o RSE exibe o heap Java atual e o limite de tamanho de espaço de endereço durante a inicialização na mensagem do console FEK004I.
Use um dos seguintes cenários se o monitoramento mostrar que o tamanho de heap Java atual é insuficiente para a carga de trabalho real:
As telas nas figuras a seguir mostram alguns números de amostra do uso de recursos para uma configuração padrão do Developer para System z com uma modificação. O tamanho máximo de heap Java é definido como 10 MB, uma vez que um máximo pequeno resultará em um uso percentil maior e os limites do tamanho de heap serão atingidos com mais rapidez.
Tamanho Máx Heap=10 MB e privado AS Tamanho=1,959 MB inicialização BPXM023I (STCRSE) ID do Processo(268 ) Uso de Memória(7%) Clientes(0) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,01 2740 72 LOCKD 1,60 28,7 M 14183 RSED 4,47 32,8 M 15910 RSED8 1,15 27,4 M 12612 logon 1 BPXM023I (STCRSE) ID do Processo(268 ) Uso de Memória(13%) Clientes(1) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,01 2864 81 LOCKD 1,64 28,8 M 14259 RSED 4,55 32,8 M 15980 RSED8 3,72 55,9 M 24128 logon 2 BPXM023I (STCRSE) ID do Processo(268 ) Uso de Memória(23%) Clientes(2) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,02 2944 86 LOCKD 1,66 28,9 M 14268 RSED 4,58 32,9 M 16027 RSED8 4,20 57,8 M 25205 logon 3 BPXM023I (STCRSE) ID do Processo(268 ) Uso de Memória(37%) Clientes(3) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,02 3020 91 LOCKD 1,67 29,0 M 14277 RSED 4,60 32,9 M 16076 RSED8 4,51 59,6 M 26327 logon 4 BPXM023I (STCRSE) ID do Processo(268 ) Uso de Memória(41%) Clientes(4) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,02 3108 96 LOCKD 1,68 29,0 M 14286 RSED 4,61 32,9 M 16125 RSED8 4,77 62,3 M 27404
logon 5 BPXM023I (STCRSE) ID do Processo(268 ) Uso de Memória(41%) Clientes(4) ID do Processo(33554706) Uso de Memória(13%) Clientes(1) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,03 3184 101 LOCKD 1,69 29,1 M 14295 RSED 4,64 32,9 M 16229 RSED8 4,78 62,4 M 27413 RSED9 4,60 56,6 M 24065
A Figura 54 e a Figura 55 mostram um cenário em que 5 clientes efetuam logon em um daemon RSE com um heap Java de 10 MB.
Tamanho Máx Heap=10 MB e privado AS Tamanho=1,959 MB inicialização BPXM023I (STCRSE) ID do Processo(212 ) Uso de Memória(7%) Clientes(0) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,01 2736 71 LOCKD 1,73 30,5 M 14179 RSED 4,35 32,9 M 15117 RSED8 1,43 27,4 M 12609 logon BPXM023I (STCRSE) ID do Processo(212 ) Uso de Memória(13%) Clientes(1) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,01 2864 80 LOCKD 1,76 30,6 M 14255 RSED 4,48 33,0 M 15187 RSED8 3,53 53,9 M 24125 expandir árvore MVS grande (195 conjuntos de dados) BPXM023I (STCRSE) ID do Processo(212 ) Uso de Memória(13%) Clientes(1) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 0,01 2864 80 LOCKD 1,78 30,6 M 14255 RSED 4,58 33,1 M 16094 RSED8 4,28 56,1 M 24740 expandir PDS pequeno (21 membros) BPXM023I (STCRSE) ID do Processo(212 ) Uso de Memória(13%) Clientes(1) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- IBMUSER2 0,22 2644 870 JMON 0,01 2864 80 LOCKD 1,78 30,6 M 14255 RSED 4,61 33,1 M 16108 RSED8 4,40 56,2 M 24937 abrir membro de tamanho médio (86 linhas) BPXM023I (STCRSE) ID do Processo(212 ) Uso de Memória(13%) Clientes(1) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- IBMUSER2 0,22 2644 870 JMON 0,01 2864 80 RSED 4,61 33,1 M 16108 RSED8 8,12 62,7 M 27044
A Figura 56 mostra um cenário em que 1 cliente efetua logon em um daemon RSE com um heap Java de 10 MB e edita um membro PDS.
A maioria dos dados relacionados ao Developer para System z, que não são gravados em uma instrução DD, termina em um arquivo z/OS UNIX. O programador de sistema tem controle sobre os dados que são gravados e para onde eles vão. Entretanto, não há controle sobre a quantidade de dados gravada.
Os dados podem ser agrupados nas seguintes categorias:
Conforme documentado no Resolução de Problemas de Configuração, o Developer for System z grava os logs do host relacionados ao RSE nos seguintes diretórios do z/OS UNIX:
Por padrão, apenas as mensagens de erro e de aviso são gravadas nos logs. Portanto, se tudo correr conforme o planejado, esses diretórios devem manter apenas os arquivos vazios ou quase vazios(sem contar os logs de auditoria).
Você pode ativar a criação de log de mensagens informativas, preferivelmente na direção do centro de suporte IBM, o que aumenta perceptivelmente o tamanho dos arquivos de log.
inicialização $ ls -l /var/rdz/logs total 144 -rw-rw-rw- 1 STCRSE STCGRP 33642 Jul 10 12:10 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1442 Jul 10 12:10 rseserver.log logon $ ls -l /var/rdz/logs total 144 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 160 -rw-rw-rw- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 303 Jul 10 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stdout.log logoff $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 296 -rw-rw-rw- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 609 Jul 10 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 176 Jul 10 12:11 stdout.log parar $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
A Figura 57 mostra o uso mínimo do espaço do sistema de arquivos z/OS UNIX ao usar o nível de depuração 2 (mensagens informativas).
Exceto para logs de auditoria, os arquivos de log são sobrescritos em cada reinício (para a tarefa iniciada do RSE) ou logon (de um cliente), mantendo o tamanho total em verificação. A diretiva keep.last.log em rsed.envvars altera isso ligeiramente, uma vez que ela pode instruir o RSE a manter uma cópia dos logs anteriores. As cópias mais antigas são sempre removidas.
Uma mensagem de aviso é enviada ao console quando o sistema de arquivos que contém os arquivos de log de auditoria estiver em execução com pouco espaço livre e a auditoria estiver ativa. Essa mensagem do console (FEK103E) é repetida regularmente até que o problema de pouco espaço seja resolvido. Consulte Mensagens do Console para obter uma lista de mensagens do console geradas pelo RSE.
As definições na Tabela 46 controlam os dados que são gravados nos diretórios de log e onde os diretórios estão localizados.
Local | Diretriz | Funções |
---|---|---|
resecomm.properties | debug_level | Definir o nível de detalhes do log padrão. |
rsed.envvars | keep.last.log | Manter uma cópia dos logs anteriores antes da inicialização/logon. |
rsed.envvars | enable.audit.log | Manter um rastreio de auditoria de ações do cliente. |
rsed.envvars | enable.standard.log | Gravar os fluxos stdout e stderr do conjunto (ou conjuntos) de encadeamento em um arquivo de log. |
rsed.envvars | DSTORE_TRACING_ON | Ativar a criação de log de ações do DataStore. |
rsed.envvars | DSTORE_MEMLOGGING_ON | Ativar a criação de log do uso de memória do DataStore. |
Comando do operador | modificar rsecommlog <level> | Altera dinamicamente o nível de detalhes do log de rsecomm.log |
Comando do operador | modificar rsedaemonlog <level> | Altera dinamicamente o nível de detalhes do log de rsedaemon.log |
Comando do operador | modificar rseserverlog <level> | Altera dinamicamente o nível de detalhe do log de rseserver.log |
Comando do operador | modificar rsestandardlog {on|off} | Altera dinamicamente a atualização de std*.*.log |
rsed.envvars | daemon.log | Caminho inicial para a tarefa iniciada do RSE e os logs de auditoria. |
rsed.envvars | user.log | Caminho inicial para logs do usuário. |
O Developer para System z, junto com o software obrigatório, como o ISPF Client Gateway, grava também dados temporários em /tmp e em /var/rdz/WORKAREA. A quantidade de dados gravada aqui como resultado de ações do usuário é imprevisível, portanto você deve ter um amplo espaço livre nos sistemas de arquivos que mantêm esses diretórios.
O Developer para System z sempre tenta limpar esses arquivos temporários, mas a limpeza manual, conforme documentada em (Opcional) Limpeza de WORKAREA, pode ser executada a qualquer momento virtualmente.
As variáveis de ambiente definidas em rsed.envvars são usadas por RSE, Java e z/OS UNIX. O arquivo de amostra fornecido com o Developer para System z destina-se a instalações de tamanho médio e pequeno que não exigem os componentes opcionais do Developer para System z. Arquivo de Configuração do RSE rsed.envvars descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis precisam de atenção especial:
O RSE é um aplicativo Java, que significa que ele está ativo no ambiente z/OS UNIX. Isso promove o BPXPRMxx a se tornar um membro parmlib crucial, uma vez que ele contém os parâmetros que controlam o ambiente e os sistemas de arquivos do z/OS UNIX. O BPXPRMxx é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer para System z:
Use o comando do operador SETOMVS ou SET OMVS para
aumentar ou diminuir dinamicamente (até o próximo IPL) o valor de quaisquer variáveis BPXPRMxx anteriores. Para fazer uma alteração permanente, edite o membro BPXPRMxx que será usado para IPLs. Consulte MVS System Commands
(SA22-7627)
para obter informações adicionais sobre esses comandos do operador.
As definições a seguir são subparâmetros da instrução NETWORK.
Recomenda-se que as definições a seguir sejam incluídas na placa JCL dos servidores Developer para System z.
As variáveis de ambiente definidas em FEJJCNFG são usadas pelo JES Job Monitor. O arquivo de amostra fornecido com o Developer para System z destina-se a instalações de porte médio e pequeno. FEJJCNFG, Arquivo de Configuração do JES Job Monitor descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis exigem atenção especial:
IEASYSxx mantém parâmetros do sistema e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer para System z:
IVTPRMxx configura parâmetros para o Communication Storage Manager (CSM), e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer para System z:
O membro parmlib ASCHPMxx contém informações de planejamento para o planejador de transações ASCH e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer para System z:
Como as cargas de trabalho do usuário podem alterar a necessidade de recursos do sistema, o sistema deve ser monitorado regularmente para medir o uso de recursos de modo que o Rational Developer para System z e as configurações do sistema possam ser ajustadas em resposta aos requisitos do usuário. Os comandos a seguir podem ser usados para ajudar nesse processo de monitoramento.
Os conjuntos de encadeamentos RSE são o ponto focal para a atividade do usuário no Developer para System z e, assim, exigem monitoramento para o uso ideal. O daemon RSE pode ser consultado sobre informações que não podem ser reunidas com as ferramentas de monitoramento comuns do sistema.
FEK004I RseDaemon: Tamanho Máximo de Heap=65MB e Tamanho do AS privado=1,959MB
f rsed,appl=d p BPXM023I (STCRSE) ID do processo(16777456) Uso de Memória(33%) Clientes(4) Ordem(1)
Informações adicionais são fornecidas quando a opção DETAIL do comando de modificação do DISPLAY PROCESS é usado:
f rsed,appl=d p,detail BPXM023I (STCRSE) 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
A maioria dos limites z/OS UNIX que é do interesse do Developer para System z pode ser exibida usando comandos do operador. Alguns comandos mostram ainda o uso atual e a limite máximo de um limite específico. Consulte MVS System Commands (SA22-7627) para obter informações adicionais sobre esses comandos.
d omvs,o BPXO043I 13.10.16 DISPLAY OMVS 066 OMVS 000D ETC/INIT WAIT OMVS=(M7) CURRENT UNIX CONFIGURATION SETTINGS: MAXPROCSYS = 256 MAXPROCUSER = 16 MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT MAXCPUTIME = 1000 MAXUIDS = 200 MAXPTYS = 256 MAXMMAPAREA = 256 MAXASSIZE = 209715200 MAXTHREADS = 200 MAXTHREADTASKS = 1000 MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096 IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000 IPCMSGNIDS = 500 IPCSEMNIDS = 500 IPCSEMNOPS = 25 IPCSEMNSEMS = 1000 IPCSHMMPAGES = 25600 IPCSHMNIDS = 500 IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144 SUPERUSER = BPXROOT FORKCOPY = COW STEPLIBLIST = USERIDALIASTABLE= SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1 SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1 PRIORITYPG VALUES: NONE PRIORITYGOAL VALUES: NONE MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864 SHRLIBMAXPAGES = 4096 VERSION = / SYSCALL COUNTS = NO TTYGROUP = TTY SYSPLEX = NO BRLM SERVER = N/A LIMMSG = NONE AUTOCVT = OFF RESOLVER PROC = DEFAULT AUTHPGMLIST = NONE SWA = BELOW
d omvs,l BPXO051I 14.05.52 DISPLAY OMVS 904 OMVS 0042 ACTIVE OMVS=(69) SYSTEM WIDE LIMITS: LIMMSG=SYSTEM CURRENT HIGHWATER SYSTEM USAGE USAGE LIMIT MAXPROCSYS 1 4 256 MAXUIDS 0 0 200 MAXPTYS 0 0 256 MAXMMAPAREA 0 0 256 MAXSHAREPAGES 0 10 4096 IPCMSGNIDS 0 0 500 IPCSEMNIDS 0 0 500 IPCSHMNIDS 0 0 500 IPCSHMSPAGES 0 0 262144 * IPCMSGQBYTES --- 0 262144 IPCMSGQMNUM --- 0 10000 IPCSHMMPAGES --- 0 256 SHRLIBRGNSIZE 0 0 67108864 SHRLIBMAXPAGES 0 0 4096
O comando exibe limites máximos e o uso atual de um processo individual quando a palavra-chave PID=processid também for especificada.
d,omvs,l,pid=16777456 BPXO051I 14.06.28 DISPLAY OMVS 645 OMVS 000E ACTIVE OMVS=(76) USER JOBNAME ASID PID PPID STATE START CT_SECS STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914 LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs - PROCESS LIMITS: LIMMSG=NONE CURRENT HIGHWATER PROCESS USAGE USAGE LIMIT MAXFILEPROC 83 103 256 MAXFILESIZE --- --- NOLIMIT MAXPROCUSER 97 99 200 MAXQUEUEDSIGS 0 1 1000 MAXTHREADS 9 14 200 MAXTHREADTASKS 9 14 1000 IPCSHMNSEGS 0 0 500 MAXCORESIZE --- --- 4194304 MAXMEMLIMIT 0 0 16383P
d omvs,p BPXO046I 14.35.38 DISPLAY OMVS 092 OMVS 000E ACTIVE OMVS=(33) PFS CONFIGURATION INFORMATION PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED TCP SOCKETS AF_INET EZBPFINI 50000 244 8146 UDS SOCKETS AF_UNIX BPXTUINT 64 6 10 ZFS LOCAL FILE SYSTEM IOEFSCM 14:32.00 RECYCLING HFS LOCAL FILE SYSTEM GFUAINIT BPXFTCLN CLEANUP DAEMON BPXFTCLN BPXFTSYN SYNC DAEMON BPXFTSYN BPXFPINT PIPE BPXFPINT BPXFCSIN CHAR SPECIAL BPXFCSIN NFS REMOTE FILE SYSTEM GFSCINIT PFS NAME DESCRIPTION ENTRY STATUS FLAGS TCP41 SOCKETS EZBPFINI ACT CD TCP42 SOCKETS EZBPFINI ACT TCP43 SOCKETS EZBPFINI INACT SD TCP44 SOCKETS EZBPFINI INACT PFS PARM INFORMATION HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100) CURRENT VALUES: FIXED(55) VIRTUAL(100) NFS biod(6)
d omvs,pid=16777456 BPXO040I 15.30.01 DISPLAY OMVS 637 OMVS 000E ACTIVE OMVS=(76) USER JOBNAME ASID PID PPID STATE START CT_SECS STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914 LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs - THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE 0E08A00000000000 005E6DF0 OMVS .927 RCV FU 0E08F00000000001 005E6C58 .001 PTX JYNV 0E09300000000002 005E6AC0 7.368 PTX JYNV 0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV 0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV 0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
Ao suportar um grande número de clientes que se conectam ao host, não apenas o Developer para System z, mas também sua infraestrutura de rede deve ser capaz de tratar a carga de trabalho. O gerenciamento de rede é um assunto amplo e bem documentado que fica fora do escopo da documentação do Developer para System z. Portanto, apenas os seguintes ponteiros são fornecidos.
O Developer para System z usa sistemas de arquivos z/OS UNIX para armazenar vários tipos de dados, como arquivos de log e temporários. Use o comando z/OS UNIX df para verificar quantos descritores de arquivo ainda estão disponíveis e quanto espaço livre foi deixado antes que a próxima extensão do conjunto de dados subjacente HFS ou zFS seja criada.
$ df Mounted on Filesystem Avail/Total Files Status /tmp (OMVS.TMP) 1393432/1396800 4294967248 Available /u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Available /usr/lpp/rdz (OMVS.FEK.HHOP760) 3062/43200 4294967147 Available /var (OMVS.VAR) 27264/31680 4294967054 Available
A configuração de amostra a seguir mostra a configuração necessária para suportar estes requisitos:
Por padrão, o Developer para System z tenta incluir 60 usuários em um único conjunto de encadeamento. Entretanto, nossos requisitos indicam que o tempo limite de inatividade estará ativo. A Tabela 44 mostra que isso incluirá 1 encadeamento por cliente conectado. Esse encadeamento é um encadeamento de cronômetro e portanto ativo constantemente. Isso evitará que o RSE coloque 60 usuários em um único conjunto de encadeamento, uma vez que 60*(16+1)=1020 e maximum.threads é definido como 1000, por padrão.
Poderíamos aumentar maximum.threads, mas devido ao requisito ter uma média de 5 MB de heap Java por usuário, optamos por diminuir o maximum.clients para 50. Isso nos mantém dentro do tamanho máximo padrão de heap Java de 256 MB (5*50 = 250).
Com 50 clientes por conjunto de encadeamentos e a necessidade de suportar 500 conexões, sabemos agora que precisaremos de 10 espaços de endereço de conjunto de encadeamentos.
Usando as fórmulas mostradas anteriormente neste capítulo e os critérios mencionados no início desta seção, podemos determinar o uso do recurso que deve ser adaptado.
3 + A + N*(x + y + z) + (2 + N*0.01)
3 + 10 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1020
x + y + z
1 + 1 + 1 = 3
7 + 2*A + N*(x + y + z) + (10 + N*0.05)
7 + 2*10 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1562
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
9 + N*(16 + x + y + z) + (20 + N*0.1)
9 + 60*(16 + 1 + 4 + 0) + (20 + 60*0.1) = 1295
3 + N
3 + 500 = 503
500 + 3 = 503
Os 3 IDs do usuário extras são para STCJMON, STCLOCK e STCRSE, os IDs do usuário da tarefa iniciada do Developer para System z.
Agora que os números de uso de recursos são conhecidos, podemos customizar a limitação das diretivas com valores apropriados.
Esta mudança é opcional; o RSE iniciará novos conjuntos de encadeamentos, conforme necessário
Após ativar os limites do sistema como documentado em Definindo Limites, é possível iniciar a monitoração do uso dos recursos pelo Developer para System z para verificar se é necessário o ajuste de algumas variáveis. O Figura 58 mostra o uso dos recursos após 495 usuários terem efetuado logon. (O exemplo na figura apenas mostra a criação do logon. Nenhuma ação do usuário é indicada no exemplo).
BPXM023I (STCRSE) ProcessId(16779764) Memory Usage(10%) Clients(50) Order(1) ProcessId(67108892) Memory Usage(16%) Clients(50) Order(2) ProcessId(67108908) Memory Usage(10%) Clients(50) Order(3) ProcessId(67108898) Memory Usage(16%) Clients(50) Order(4) ProcessId(67108916) Memory Usage(16%) Clients(50) Order(5) ProcessId(67108897) Memory Usage(16%) Clients(50) Order(6) ProcessId(67108921) Memory Usage(16%) Clients(50) Order(7) ProcessId(83886146) Memory Usage(16%) Clients(50) Order(8) ProcessId(67108920) Memory Usage(16%) Clients(50) Order(9) ProcessId(3622 ) Memory Usage(8%) Clients(45) Order(10) Nome Tarefa Tempo de CPU Armazen. EXCP -------- ----------- ------- ---------- JMON 1.74 43.0M 2753 LOCKD 10.05 31.9M 24621 RSED 6.65 40.1M 41780 RSED1 8.17 187.0M 76566 RSED2 13.04 184.9M 78946 RSED3 17.77 181.1M 76347 RSED4 11.63 174.9M 74638 RSED5 15.27 172.9M 72883 RSED6 13.85 180.8M 75031 RSED7 9.79 174.3M 76636 RSED8 21.59 176.1M 70583 RSED8 18.88 184.7M 76953 RSED9 9.52 189.8M 80490
O z/OS é um sistema operacional altamente customizável, e (algumas vezes pequenas) alterações no sistema podem ter um grande impacto sobre o desempenho geral. Este capítulo destaca algumas alterações que podem ser feitas para aprimorar o desempenho do Developer para System z.
Consulte MVS Initialization and Tuning Guide (SA22-7591) e UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre o ajuste do sistema.
O zFS (zSeries File System) e o HFS (Hierarchical File System) são sistemas de arquivo UNIX que podem ser usados em um ambiente z/OS UNIX. No entanto, o zFS fornece os seguintes recursos e benefícios:
Consulte UNIX System Services Planning (GA22-7800) para saber mais sobre zFS.
Cada processo do z/OS UNIX que possui um STEPLIB que é propagado de pai para filho ou através de um exec consumirá cerca de 200 bytes de Extended Common Storage Area (ECSA). Se nenhuma variável de ambiente STEPLIB estiver definida, ou quando uma for definida como STEPLIB=CURRENT, o z/OS UNIX propagará todas as alocações TASKLIB, STEPLIB e JOBLIB atualmente ativas durante uma função fork(), spawn() ou exec().
O Developer para System z possui um padrão de arquivo de configuração STEPLIB=NONE codificado em rsed.envvars, conforme descrito em rsed.envvars. Pelos motivos mencionados acima, é aconselhável não alterar essa diretiva e colocar os conjuntos de dados de destino em LINKLIST ou LPA (Link Pack Area).
Determinadas bibliotecas do sistema e módulos de carregamento são intensamente usadas pelo z/OS UNIX e pelas atividades de desenvolvimento do aplicativo. O aprimoramento do acesso, como a inclusão na Área do Pacote de Links (LPA) pode aprimorar o desempenho do sistema. Consulte MVS Initialization and Tuning Reference (SA22-7592) para obter informações adicionais sobre a alteração de membros SYS1.PARMLIB descrito a seguir:
Quando programas C (incluindo o shell do z/OS UNIX) são executados, frequentemente usam rotinas da biblioteca de tempo de execução do LE (Language Environment). Em média, aproximadamente 4 MB da biblioteca de tempo de execução são carregados na memória para cada espaço de endereço executando um programa ativado para LE e copiados em cada fork.
CEE.SCEELPA
O conjunto de dados CEE.SCEELPA contém um subconjunto das rotinas de tempo de execução do LE, intensamente usadas pelo z/OS UNIX. Você deve incluir esse conjunto de dados em SYS1.PARMLIB(LPALSTxx) para ganho máximo de desempenho. Fazendo isso, os módulos são lidos do disco apenas uma vez e são armazenados em um local compartilhado.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Também é aconselhável colocar as bibliotecas de tempo de execução do LE CEE.SCEERUN e CEE.SCEERUN2 em LINKLIST, incluindo os conjuntos de dados em SYS1.PARMLIB(LNKLSTxx) ou SYS1.PARMLIB(PROGxx). Isso elimina o código extra STEPLIB do z/OS UNIX e há uma redução de entrada/saída devido ao gerenciamento pelo LLA e VLF, ou produtos semelhantes.
Se você decidir não colocar essas bibliotecas em LINKLIST, será necessário configurar a instrução STEPLIB apropriada no arquivo de configuração rsed.envvars, conforme descrito em rsed.envvars. Embora esse método sempre utilize armazenamento virtual adicional, pode aprimorar o desempenho definindo as bibliotecas de tempo de execução do LE para o LLA ou um produto semelhante. Isso reduz a E/S necessária para carregar os módulos.
Em sistemas em que o desenvolvimento de aplicativos é a principal atividade, o desempenho também pode ser beneficiado se você colocar o editor de ligação em um LPA dinâmico, incluindo as seguintes linhas em SYS1.PARMLIB(PROGxx):
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN) LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
Para desenvolvimento do C/C++, você também pode incluir o conjunto de dados do compilador CBC.SCCNCMP em SYS1.PARMLIB(LPALSTxx).
As instruções acima são amostras de possíveis candidatas de LPA, mas as necessidades no seu site podem variar. Consulte Language Environment Customization (SA22-7564) para obter informações sobre a colocação de outros módulos de carregamento do LE na LPA dinâmica. Consulte UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre a colocação de módulos de carregamento do compilador C/C++ em um LPA dinâmico.
Para aprimorar o desempenho da verificação de segurança realizada para o z/OS UNIX, defina o perfil BPX.SAFFASTPATH na classe FACILITY do software de segurança. Isso reduz o código extra ao realizar verificações de segurança do z/OS UNIX para uma ampla variedade de operações, incluindo verificação de acesso ao arquivo, verificação de acesso ao IPC e verificação de propriedade do processo. Consulte UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre esse perfil.
Cada site possui necessidades específicas e é possível customizar o sistema operacional z/OS para aproveitar ao máximo os recursos disponíveis de acordo com essas necessidades. Com gerenciamento de carga de trabalho, você define suas metas de desempenho e designa uma importância de negócios a cada meta. Você define as metas para o trabalho em termos de negócios e o sistema decide quantos recursos, como CPU e armazenamento, devem ser fornecidos para o trabalho, de acordo com a meta.
O desempenho do Developer para System z pode ser equilibrado pela configuração das metas corretas para os processos. Algumas diretrizes gerais são listadas abaixo:
Consulte MVS Planning Workload Management (SA22-7602) para obter informações adicionais sobre este assunto.
Com um heap de tamanho fixo, nenhuma expansão ou contração de heap ocorre e isso pode ocasionar significantes ganhos de desempenho em algumas situações. No entanto, a utilização de um heap de tamanho fixo geralmente não é uma boa ideia, porque atrasa o início de uma coleta de lixo até que o heap esteja cheio, momento em que será uma tarefa principal. Também aumenta o risco de fragmentação, o que requer uma compactação de heap. Portanto, utilize heaps de tamanho fixo só depois de desempenhar teste adequado ou quando orientado pelo IBM Support Center. Consulte Java Diagnostics Guide (SC34-6650) para obter informações adicionais sobre tamanhos de heap e coleta de lixo.
Por padrão, o tamanho de heap inicial de uma z/OS Java Virtual Machine (JVM) é 1 megabyte. O tamanho máximo é de 64 megabytes. Os limites podem ser configurados com as opções da linha de comandos -Xms (inicial) e -Xmx (máximo) Java.
No Developer para System z, as opções da linha de comandos Java são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars, conforme descrito em Definindo Parâmetros Extras de Inicialização Java com _RSE_JAVAOPTS.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
A opção -Xquickstart pode ser usada para melhorar o tempo de inicialização de alguns aplicativos Java. -Xquickstart faz com que o compilador Just In Time (JIT) seja executado com um subconjunto de otimizações, ou seja, uma compilação rápida. Essa compilação rápida permite melhorar o tempo de inicialização.
-Xquickstart é apropriada para aplicativos de curta execução, principalmente aqueles em que o tempo de execução não está concentrado em um número menor de métodos. -Xquickstart pode prejudicar o desempenho ser for usada em aplicativos de longa execução que contêm métodos ativos.
Para ativar a opção -Xquickstart para o servidor RSE, inclua a seguinte diretiva no final de rsed.envvars:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
O IBM Java Virtual Machine (JVM) versão 5 e superior permite compartilhar classes de aplicativos e de autoinicialização entre JVMs armazenando-as em um cache em memória compartilhada. O compartilhamento de classes reduz o consumo total de memória virtual quando mais de uma JVM compartilha um cache. O compartilhamento de classes também reduz o tempo de inicialização de uma JVM após o cache ser criado.
O cache de classe compartilhada é independente de qualquer JVM ativa e persiste além do tempo de vida da JVM que criou o cache. Como o cache de classe compartilhada persiste além do tempo de vida de qualquer JVM, o cache é atualizado dinamicamente para refletir quaisquer modificações que possam ter sido feitas em JARs ou classes no sistema de arquivo.
A sobrecarga para criar e preencher um novo cache é mínima. O custo de tempo de inicialização da JVM para uma única JVM normalmente é entre 0 e 5% menor em comparação com um sistema que não utiliza compartilhamento de classe, dependendo de quantas classes são carregadas. O aprimoramento do tempo de inicialização da JVM com um cache preenchido normalmente é entre 10% e 40% mais rápido em comparação com um sistema que não utiliza compartilhamento de classe, dependendo do sistema operacional e do número de classes carregadas. Várias JVMs em execução simultaneamente mostram maiores benefícios no tempo de inicialização total.
Consulte o Java SDK and Runtime Environment User Guide para obter informações adicionais sobre o compartilhamento de classe.
Para ativar o compartilhamento de classes para o servidor RSE, inclua a seguinte diretiva no final de rsed.envvars. A primeira instrução define um cache denominado RSE com acesso em grupo e permite que o servidor RSE seja iniciado, mesmo se o compartilhamento de classes falhar. A segunda instrução é opcional e configura o tamanho do cache para 6 megabytes (o padrão do sistema é 16 MB). A terceira instrução inclui os parâmetros de compartilhamento de classes nas opções de inicialização Java.
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m _RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
O tamanho máximo de cache compartilhado teórico é 2 GB. O tamanho de cache que você pode especificar é limitado pela quantidade de memória física e pelo espaço de troca disponíveis para o sistema. Como o espaço de endereço virtual de um processo é compartilhado entre o cache de classe compartilhada e o heap Java, o aumento do tamanho máximo do heap Java reduzirá o tamanho do cache da classe compartilhada que você pode criar.
O acesso ao cache de classe compartilhada é limitado por permissões do sistema operacional e permissões de segurança Java.
Por padrão, os caches de classe são criados com a segurança no nível do usuário, portanto, apenas o usuário que criou o cache pode acessá-lo. No z/OS UNIX, há uma opção, groupAccess, que fornece acesso a todos os usuários no grupo primário do usuário que criou o cache. Entretanto, independentemente do nível de acesso usado, um cache poderá ser destruído apenas pelo usuário que o criou ou por um usuário root (UID 0).
Consulte o Java SDK and Runtime Environment User Guide para obter informações adicionais sobre as opções extras de segurança utilizando um Java SecurityManager.
Algumas das configurações de SYS1.PARMLIB(BPXPRMxx) afetam o desempenho das classes compartilhadas. O uso de configurações incorretas pode interromper o funcionamento de classes compartilhadas. Essas configurações também podem ter implicações no desempenho. Para obter informações adicionais sobre implicações no desempenho e sobre o uso desses parâmetros, consulte MVS Initialization and Tuning Reference (SA22-7592) e UNIX System Services Planning (GA22-7800). Os parâmetros BPXPRMxx mais significativos que afetam a operação de classes compartilhadas são os seguintes:
Essas configurações afetam a quantidade de páginas de memória compartilhada disponíveis para a JVM. O tamanho da página compartilhada para um serviço do sistema z/OS UNIX de 31 bits é fixado em 4 KB. As classes compartilhadas tentam criar um cache de 16 MB por padrão. Entretanto, configure IPCSHMMPAGES para maior que 4096.
Se você configurar um tamanho de cache utilizando -Xscmx, a JVM arredondará o valor para o megabyte mais próximo. Você deve levar isso em consideração ao definir IPCSHMMPAGES no sistema.
Essas configurações afetam a quantidade de semáforos disponíveis para os processos UNIX. As classes compartilhadas usam semáforos IPC para a comunicação entre as JVMs.
O cache de classe compartilhada requer espaço em disco para armazenar informações de identificação sobre os caches que existem no sistema. Essas informações são armazenadas em /tmp/javasharedresources. Se o diretório de informações de identificação for excluído, a JVM não poderá identificar as classes compartilhadas no sistema e deverá recriar o cache.
O comando da linha Java -Xshareclasses pode utilizar diversas opções, sendo alguns utilitários de gerenciamento do cache. Três delas são apresentadas na amostra abaixo ($ é o prompt do z/OS UNIX). Consulte o Java SDK and Runtime Environment User Guide para obter uma visão geral completa das opções de linha de comandos suportadas.
$ java -Xshareclasses:listAllCaches Shared Cache OS shmid in use Last detach time RSE 401412 0 Mon Jun 18 17:23:16 2007 Could not create the Java virtual machine. $ java -Xshareclasses:name=RSE,printStats Current statistics for cache "RSE": base address = 0x0F300058 end address = 0x0F8FFFF8 allocation pointer = 0x0F4D2E28 cache size = 6291368 free bytes = 4355696 ROMClass bytes = 1912272 Metadata bytes = 23400 Metadata % used = 1% # ROMClasses = 475 # Classpaths = 4 # URLs = 0 # Tokens = 0 # Stale classes = 0 % Stale classes = 0% Cache is 30% full Could not create the Java virtual machine. $ java -Xshareclasses:name=RSE,destroy JVMSHRC010I Shared Cache "RSE" is destroyed Could not create the Java virtual machine.
Tradicionalmente, a função de definição de recursos para o CICS tem sido o domínio do administrador do CICS. Há uma resistência em permitir que o desenvolvedor de aplicativos defina recursos do CICS por vários motivos:
O Developer para System z aborda esses problemas permitindo que administradores do CICS controlem os padrões de definição de recurso do CICS e controlem as propriedades de exibição de um parâmetro de definição de recurso do CICS por meio do servidor CICS Resource Definition (CRD), que faz parte do Application Deployment Manager.
Por exemplo, o administrador do CICS pode fornecer certos parâmetros de definição de recurso do CICS que podem não ser atualizados pelo desenvolvedor de aplicativos. Outros parâmetros de definição de recurso do CICS podem ser atualizados, com ou sem os padrões fornecidos, ou o parâmetro de definição de recurso do CICS pode ser ocultado para evitar uma complexidade desnecessária.
Quando o desenvolvedor de aplicativos estiver satisfeito com as definições de recursos do CICS, elas poderão ser instaladas imediatamente no ambiente de teste do CICS em execução, ou poderão ser exportadas em um manifesto para edição e aprovação adicionais por um administrador do CICS. O administrador do CICS pode utilizar o administrative utility (utilitário em lote) ou a ferramenta Processamento de Manifesto para implementar as alterações de definição de recurso.
Consulte (Opcional) Application Deployment Manager para obter informações adicionais sobre as tarefas necessárias para configurar o Application Deployment Manager no sistema host.
Customizar o Application Deployment Manager inclui os seguintes serviços no Developer para System z:
O servidor CICS Resource Definition (CRD) do Application Deployment Manager consiste no próprio servidor CRD, um repositório CRD, definições de recursos CICS associadas e, ao usar a interface dos Serviços da Web, os arquivos de ligação do Serviço da Web e um manipulador de mensagens do pipeline de amostra. O servidor CRD deve ser executado em uma Web Owning Region (WOR), que é mencionado na documentação do Developer para System z como a região de conexão primária do CICS.
Consulte o Centro de Informações do Developer para System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) para saber mais sobre os serviços disponíveis do Application Deployment Manager no release atual do Developer para System z.
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.
Um ambiente de teste do CICS pode consistir de várias regiões Multi-Region Option (MRO) conectadas. Com o tempo, foram utilizadas designações não oficiais para classificar essas regiões. As designações típicas são Terminal Owning Region (TOR), Web Owning Region (WOR), Application Owning Region (AOR) e Data Owning Region (DOR).
Uma Web Owning Region é usada para implementar suporte aos Serviços da Web do CICS e o servidor CICS Resource Definition (CRD) do Application Deployment Manager deve ser executado nessa região. Essa região é conhecida pelo Application Deployment Manager como a região de conexão primária do CICS. O cliente do CRD implementa uma conexão de serviço da Web na região de conexão primária do CICS.
As regiões de conexão não-primárias do CICS são todas as outras regiões que o servidor CRD pode atender. Esse serviço inclui visualizar recursos utilizando IBM CICS Explorer e definir recursos utilizando o editor de definição de recurso do CICS.
Se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recurso do CICS da região de conexão primária do CICS, todas as outras regiões do CICS gerenciadas pelo BAS poderão ser atendidas pelo servidor CRD.
As regiões do CICS não gerenciadas pelo BAS requerem alterações adicionais para poderem ser atendidas pelo servidor CRD.
As ações feitas pelo servidor CRD em relação aos recursos do CICS são registradas na fila do CICS CSDL TD, que normalmente aponta para a DD MSGUSR de sua região do CICS.
Se CICSPlex SM Business Application Services (BAS) for usado para gerenciar suas definições de recursos do CICS, então a diretiva CICSPlex SM EYUPARM BASLOGMSG deve ser configurada como (YES) para que os logs sejam criados.
O conjunto de dados de VSAM do repositório do servidor CRD contém todas as definições de recurso padrão e deve, portanto, ser protegido contra atualizações, mas os desenvolvedores devem ter permissão para ler os valores armazenados aqui. Consulte Definir os Perfis do Conjunto de Dados para obter comandos RACF de amostra para proteger o repositório do CRD.
Quando uma mensagem SOAP for recebida pelo CICS por meio da interface de Serviço da Web, ela será processada por um pipeline. Um pipeline é um conjunto de manipuladores de mensagens que são executados em seqüência. O CICS lê o arquivo de configuração do pipeline para determinar quais manipuladores de mensagens devem ser chamados no pipeline. Um manipulador de mensagem é um programa no qual você pode executar processamento especial de pedidos e respostas de serviço da Web.
O Application Deployment Manager fornece um arquivo de configuração de pipeline de amostra que especifica a chamada de um manipulador de mensagens e um programa de processamento de cabeçalho SOAP.
O manipulador de mensagens do pipeline (ADNTMSGH) é usado para segurança através do processamento do ID do usuário e da senha no cabeçalho SOAP. ADNTMSGH é referido pelo arquivo de configuração de pipeline de amostra e, portanto, deve ser colocado na concatenação RPL do CICS.
CPIH é o ID da transação padrão que um aplicativo chamado por um pipeline executará. Geralmente, o CPIH é configurado para um nível mínimo de autorização.
O Developer para System z fornece várias transações que são usadas pelo servidor CRD durante a definição e a consulta de recursos do CICS. Esses IDs de transação são configurados pelo servidor CRD, dependendo da operação solicitada. Consulte o (Opcional) Application Deployment Manager para obter informações adicionais sobre a customização de IDs da transação.
Transação | Descrição |
---|---|
ADMS | Para pedidos da ferramenta Processamento de Manifesto para alterar recursos do CICS. Geralmente, isso é destinado aos administradores do CICS. Essa transação requer um alto nível de autorização. |
ADMI | Para pedidos que definam, instalem ou desinstalem recursos do CICS. Essa transação pode requerer um nível médio de autorização, dependendo das políticas do site. |
ADMR | Para todos os outros pedidos que recuperam as informações de ambiente e de recurso do CICS. Essa transação pode requerer um nível mínimo de autorização, dependendo das políticas do site. |
Alguns ou todos esses pedidos de definição de recurso feitos pelas transações do servidor CRD devem ser protegidos. No mínimo, os comandos de atualização (parâmetros de atualização padrão do serviço da Web, parâmetros padrão do descritor e o nome de arquivo para ligação do nome do conjunto de dados) devem ser protegidos para impedir que todos, exceto os administradores do CICS, emitam esses comandos usados para configurar padrões de recurso global.
Quando a transação é conectada, a verificação de segurança de recurso do CICS, se ativada, garante que o ID do usuário esteja autorizado para executar o ID de transação.
A verificação de recursos é controlada pela opção RESSEC na transação que está executando o parâmetro de inicialização do sistema RESSEC e, para o servidor do CRD, o parâmetro de inicialização do sistema XPCT.
A verificação de recursos ocorre apenas se o parâmetro de inicialização do sistema XPCT tiver um valor diferente de NO e a opção RESSEC da definição TRANSACTION for YES ou o parâmetro de inicialização do sistema RESSEC for ALWAYS.
Os seguintes comandos RACF mostram como as transações do servidor CRD podem ser protegidas. Consulte o RACF Security Guide for CICSTS para obter informações adicionais sobre a definição da segurança do CICS.
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#cicsadmin)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#cicsdeveloper)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
A criptografia SSL do fluxo de dados é suportada quando o cliente do Application Deployment Manager usa a interface dos Serviços da Web para invocar o servidor CRD. O uso de SSL para essa comunicação é controlado pela palavra-chave SSL(YES) na definição CICSTS TCPIPSERVICE, conforme documentado em RACF Security Guide para CICSTS.
O CICSTS fornece a capacidade de proteger os recursos e os comandos para manipulá-los. Algumas ações do Application Deployment Manager podem falhar se a segurança estiver ativada, mas não configurada completamente (por exemplo, concedendo permissões para manipular novos tipos de recursos).
Em caso de falha da função no Application Deployment Manager, examine os logs do CICS para obter mensagens como a seguir, e executar ações corretivas, conforme documentado no RACF Security Guide para CICSTS.
DFHXS1111 %date %time %applid %tranid Security violation by user %userid at netname %portname for resource %resource in class %classname. SAF codes are (X'safresp',X'safreas'). ESM codes are (X'esmresp',X'esmreas').
O Developer para System z fornece o administrative utility para permitir que administradores do CICS forneçam os valores padrão para as definições de recurso do CICS. Esses padrões podem ser somente de leitura ou podem ser editados pelo desenvolvedor de aplicativos.
O administrative utility fornece as seguintes funções:
O administrative utility é chamado pela tarefa de amostra ADNJSPAU no conjunto de dados FEK.#CUST.JCL. O uso desse utilitário requer acesso UPDATE ao repositório do CRD.
ADNJSPAU está localizado em FEK.#CUST.JCL, a menos que o programador do sistema z/OS tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte Configuração da Customização para obter mais detalhes.
As instruções de controle de entrada são usadas para atualizar o repositório do CRD de um ambiente de teste do CICS, para o qual as regras gerais de sintaxe a seguir se aplicam:
As definições de amostra a seguir seguem a estrutura dos comandos DFHCSDUP, conforme definido no CICS Resource Definition Guide para CICSTS. A única diferença é a inserção das seguintes palavras-chave de permissão de exibição usadas para agrupar valores de atributo em três conjuntos de permissões:
UPDATE | Os atributos que seguem essa palavra-chave serão atualizados por um desenvolvedor de aplicativos utilizando Developer para System z. Esse também é o padrão para atributos omitidos. |
PROTECT | Os atributos que seguem essa palavra-chave serão exibidos, mas estarão protegidos contra atualizações por um desenvolvedor de aplicativos utilizando Developer para System z. |
HIDDEN | Os atributos que seguem essa palavra-chave não serão exibidos e estarão protegidos contra atualizações por um desenvolvedor de aplicativos utilizando Developer para System z. |
Consulte a seguinte amostra de código ADNJSPAU.
//ADNJSPAU JOB <JOB PARAMETERS> //* //ADNSPAU EXEC PGM=ADNSPAU,REGION=1M //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD //ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0 //SYSPRINT DD SYSOUT=* //SYSIN DD * * * Parâmetros CICSPlex SM * DEFINE CPSMNAME( ) *DEFINE STAGINGGROUPNAME(ADMSTAGE) * * Regra de exportação de manifesto * DEFINE MANIFESTEXPORTRULE(installOnly) * * Padrões de definição de recurso do CICS * Atributos omitidos são padronizados como UPDATE. * * Atributos padrão DB2TRAN * DEFINE DB2TRAN() UPDATE DESCRIPTION() ENTRY() TRANSID() * * Atributos padrão DOCTEMPLATE * DEFINE DOCTEMPLATE() UPDATE DESCRIPTION() TEMPLATENAME() FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM() DDNAME(DFHHTML) MEMBERNAME() HFSFILE() APPENDCRLF(YES) TYPE(EBCDIC) * * Atributos padrão de arquivo * DEFINE FILE() UPDATE DESCRIPTION() RECORDSIZE() KEYLENGTH() RECORDFORMAT(V) ADD(NO) BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO) REMOTESYSTEM() REMOTENAME() PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1) STATUS(ENABLED) OPENTIME(FIRSTREF) DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1) TABLE(NO) MAXNUMRECS(NOLIMIT) READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS) UPDATEMODEL(LOCKING) LOAD(NO) JNLREAD(NONE) JOURNAL(NO) JNLSYNCREAD(NO) JNLUPDATE(NO) JNLADD(NONE) JNLSYNCWRITE(YES) RECOVERY(NONE) FWDRECOVLOG(NO) BACKUPTYPE(STATIC) PASSWORD() NSRGROUP() CFDTPOOL() TABLENAME()
* * Atributos padrão Mapset * DEFINE MAPSET() UPDATE DESCRIPTION() PROTECT RESIDENT(NO) STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO) ** Atributos padrão de tipo de processo * DEFINE PROCESSTYPE() UPDATE DESCRIPTION() FILE(BTS) PROTECT STATUS(ENABLED) AUDITLOG() AUDITLEVEL(OFF) * * Atributos padrão de programa * DEFINE PROGRAM() UPDATE DESCRIPTION() CEDF(YES) LANGUAGE(LE370) REMOTESYSTEM() REMOTENAME() TRANSID() PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT) DATALOCATION(ANY) DYNAMIC(NO) EXECKEY(USER) EXECUTIONSET(FULLAPI) RELOAD(NO) RESIDENT(NO) STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO) HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR) * * Atributos padrão TDQueue * DEFINE TDQUEUE() UPDATE DESCRIPTION() TYPE(INTRA) * Parâmetros de partição extra DDNAME() DSNAME() REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1) RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED) BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR) * Parâmetros de partição intra FACILITYID() TRANSID() TRIGERRLEVEL(1) USERID() * Parâmetros indiretos INDIRECTNAME() PROTECT WAIT(YES) WAITACTION(REJECT) * Parâmetros de partição extra DATABUFFERS(1) SYSOUTCLASS() ERROROPTION(IGNORE) OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT) * Parâmetros de partição intra ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Atributos padrão de transação
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* Atributos URDIMAP
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Nome de arquivo opcional para ligações de nome do conjunto de dados VSAM
*
*DEFINE DSBINDING() DSNAME()
/*
Developer para System z versão 7.6.1 incluiu suporte URIMAP no Administrative utility. Para poder usar o suporte URIMAP, o conjunto de dados VSAM do repositório CRD deve estar alocado com um tamanho de registro máximo de 3000. Até a Developer para System z versão 7.6.1, as tarefas de alocação do repositório CRD da amostra usam um tamanho de registro máximo de 2000.
Siga estas etapas para ativar o suporte URIMAP se você estiver ' usando um repositório CRD mais antigo:
As mensagens a seguir são emitidas pelo Administrative utility para a SYSPRINT DD. As mensagens CRAZ1803E, CRAZ1891E, CRAZ1892E e CRAZ1893E contêm códigos de status de arquivo, retorno do VSAM, função do VSAM e feedback do VSAM. Os códigos de retorno, função e feedback do VSAM são documentados em DFSMS Macro Instructions for Data Sets (SC26-7408). Os códigos de status de arquivo são documentados em Enterprise COBOL for z/OS Language Reference (SC27-1408).
Explicação: O administrative utility do programador de sistema foi concluído com sucesso.
Resposta do usuário: Nenhuma.
Explicação: O administrative utility do programador de sistema foi concluído com um ou mais avisos localizados durante o processamento de instruções de controle.
Resposta do usuário: Verifique outras mensagens de aviso.
Explicação: O administrative utility do programador de sistema encontrou um erro grave.
Resposta do usuário: Verifique outras mensagens de aviso.
Explicação: O administrative utility do programador de sistema encontrou um erro grave ao abrir o repositório do CRD.
Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.
Explicação: O administrative utility do programador de sistema encontrou uma instrução de controle de entrada desconhecida.
Resposta do usuário: Verifique se o comando DEFINE foi seguido por um espaço único e depois pela palavra-chave CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING, DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE ou TRANSACTION.
Explicação: O administrative utility do programador de sistema está processando a instrução de controle de entrada da palavra-chave DEFINE.
Resposta do usuário: Nenhuma.
Explicação: O administrative utility do programador de sistema encontrou uma regra de exportação de manifesto inválida.
Resposta do usuário: Verifique se o valor da palavra-chave MANIFESTEXPORTRULE é "installOnly", "exportOnly" ou "both".
Explicação: O administrative utility do programador de sistema estava processando uma instrução de controle DEFINE DSBINDING que não possui a palavra-chave DSNAME.
Resposta do usuário: Verifique se a instrução de controle DEFINE DSBINDING contém a palavra-chave DSNAME.
Explicação: O administrative utility do programador de sistema estava processando uma instrução de controle DEFINE e encontrou um valor inválido para a palavra-chave nomeada.
Resposta do usuário: Verifique se o comprimento e o valor da palavra-chave nomeada estão corretos.
Explicação: O administrative utility do programador de sistema estava processando uma instrução de controle DEFINE e encontrou um erro de sintaxe para a palavra-chave ou valor da palavra-chave.
Resposta do usuário: Verifique se o valor da palavra-chave está entre parênteses e imediatamente após a palavra-chave. A palavra-chave e o valor da palavra-chave devem estar contidos na mesma linha.
Explicação: O administrative utility do programador de sistema encontrou um erro de chave duplicada ao gravar no repositório CRD.
Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.
Explicação: O administrative utility do programador de sistema encontrou um erro grave ao gravar no repositório CRD.
Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.
Explicação: O administrative utility do programador de sistema encontrou um erro grave ao ler o repositório do CRD.
Resposta do usuário: Verifique os códigos de status, retorno, função e feedback do VSAM.
Este apêndice é fornecido para ajudá-lo a imitar um procedimento de logon do TSO incluindo instruções DD e conjuntos de dados no ambiente TSO no Developer para System z.
O serviço TSO Commands é o componente Developer para System z que executa comandos TSO e ISPF (em lote) e retorna o resultado para o cliente solicitante. Esses comandos podem ser solicitados implicitamente pelo produto ou explicitamente pelo usuário.
Os membros de amostra fornecidos com o Developer para System z criam um ambiente mínimo do TSO/ISPF. Se os desenvolvedores em sua loja precisarem de acesso a bibliotecas customizadas ou de terceiros, o programador de sistema z/OS deve incluir as instruções DD e as bibliotecas necessárias para o ambiente de serviço TSO Commands. Embora a implementação seja diferente no Developer para System z, a lógica por trás disso é idêntica ao procedimento de logon do TSO.
A partir da versão 7.1, o Developer para System z fornece uma opção para acessar o serviço TSO Commands.
Verifique o rsed.envvars para determinar qual método de acesso é usado para hosts da versão 7.1 e superior. Se os padrões tiverem sido usados durante o processo de configuração, rsed.envvars residirá em /etc/rdz/.
O arquivo de configuração ISPF.conf (localizado por padrão em /etc/rdz/) define o ambiente do TSO/ISPF usado pelo Developer para System z. Existe apenas um arquivo de configuração ISPF.conf ativo, que é usado por todos os usuários do Developer para System z.
A seção principal do arquivo de configuração define os nomes DD e as concatenações relacionadas do conjunto de dados, como no seguinte exemplo:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=ISP.SISPLOAD myDD=HLQ1.LLQ1,HLQ2.LLQ2
Por padrão, o TSO/ISPF Client Gateway cria um perfil temporário do ISPF para o serviço TSO Commands. Entretanto, você pode instruir o TSO/ISPF Client Gateway z a utilizar uma cópia de um perfil existente do ISPF. A chave aqui é a instrução _RSE_CMDSERV_OPTS no rsed.envvars.
#_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS &ISPPROF=&SYSUID..ISPPROF"
Remova o comentário da instrução (remova o sinal de sustenido (#) inicial) e forneça o nome completo do conjunto de dados do perfil existente do ISPF para utilizar esse recurso.
As seguintes variáveis podem ser usadas no nome do conjunto de dados:
A instrução allocjob no ISPF.conf (que está assinalada como comentário por padrão) aponta um exec que pode ser usado para fornecer alocações adicionais do conjunto de dados por ID do usuário.
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
Remova o comentário da instrução (remova o caractere de asterisco (*) inicial) e forneça a referência completa para o exec de alocação para utilizar esse recurso.
Embora o ISPF.conf suporte apenas a chamada de um exec de alocação, não há limites para um exec chamar outro exec. E o ID do usuário do cliente que está sendo transmitido como parâmetro abre os execs de alocação personalizados. Você pode, por exemplo, verificar se o membro USERID'.EXEC(ALLOC)' existe e executá-lo.
Uma variação elaborada para esse tema permite o uso de procedimentos de logon existentes do TSO, como a seguir:
Se os cenários do exec de alocação descritos acima não puderem tratar de suas necessidades específicas, você poderá criar diferentes instâncias do servidor de comunicação RSE do Developer para System z, cada uma utilizando seu próprio arquivo ISPF.conf. A desvantagem principal do método descrito a seguir é que os usuários do Developer para System z devem conectar-se a servidores diferentes no mesmo host para obter o ambiente TSO desejado.
$ cd /etc/rdz $ mkdir /etc/rdz/tso2 $ cp rsed.envvars /etc/rdz/tso2 $ cp ISPF.conf /etc/rdz/tso2 $ ls /etc/rdz/tso2 ISPF.conf rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> change: _CMDSERV_CONF_HOME=/etc/rdz/tso2 -> uncomment and change: -Ddaemon.log=/var/rdz/logs/tso2 -> add at the END: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/tso2/ISPF.conf -> change: change as needed
Os comandos no exemplo anterior copiam os arquivos de configuração do Developer para System z que exigem alterações no diretório tso2 recém-criado. A variável _CMDSERV_CONF_HOME em rsed.envvars deve ser atualizada para definir um novo diretório inicial ISPF.conf e o daemon.log deve ser atualizado para definir um novo local de log (que é criado automaticamente se ele não existir). A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para tso2. O arquivo ISPF.conf em si pode ser atualizado para atender às suas necessidades. Observe que a área de trabalho do ISPF (variável _CMDSERV_WORK_HOME em rsed.envvars) pode ser compartilhada entre as duas instâncias.
Agora resta apenas criar uma nova tarefa iniciada para o RSE que utiliza um novo número de porta e os novos arquivos de configuração /etc/rdz/tso2.
Consulte as seções relacionadas nesta publicação para obter informações adicionais sobre as ações mostradas acima.
A definição de uma transação APPC consiste em parâmetros APPC e um JCL de transação. A JCL de amostra para criar uma transação APPC do Developer para System z, FEK.#CUST.JCL(FEKAPPCC), contém duas opções para definir a JCL da transação, com e sem suporte ISPF.
//SYSIN DD DDNAME=SYSINISP * use SYSINTSO or SYSINISP
O cliente obtém o ambiente TSO/ISPF definido na JCL de transação, portanto, customizando esta seção seguindo regras DD regulares, você pode customizar o ambiente para o cliente.
... //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2
Se o suporte do ISPF for selecionado, o Developer para System z criará por padrão um perfil temporário do ISPF para o serviço TSO Commands. Entretanto, você pode instruir o Developer para System z a utilizar uma cópia de um perfil existente do ISPF. Conforme descrito na tarefa de amostra FEK.SFEKSAMP(FEKAPPCC), você deve fazer o seguinte:
...
//COPY EXEC PGM=IEBCOPY * (optional) clone existing ISPF profile
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=&SYSUID..ISPROF//SYSUT2 DD DISP=(MOD,PASS),DSN=&&PROF,
// UNIT=SYSALLDA,
// LIKE=&SYSUID..ISPROF
//*
//CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50,
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//*ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//* SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//ISPPROF DD DISP=(OLD,DELETE,DELETE),DSN=&&PROF
A transação da amostra JCL chama o serviço do TSO Commands diretamente ao passar seu nome (FEKFRSRV) como parâmetro para programar IKJEFT01. É possível alterar isto para chamar um outro executável. Este executável pode fazer alocações baseadas no ID do usuário atual e, em seguida, chamar o serviço do TSO Commands.
Ao contrário do método de acesso do TSO/ISPF Client Gateway, as variáveis armazenadas no perfil do ISPF do usuário podem ser usadas por esse exec para ajudá-lo a customizar o ambiente. Mas lembre-se de que as atualizações no perfil serão perdidas no final da sessão, pois você está utilizando uma cópia temporária, não o perfil real.
Observe, no entanto, que o uso de um exec de alocação na transação APPC não é suportado e a descrição acima está no estado em que se encontra.
Se for necessário vários ambientes TSO exclusivos, você pode criar instâncias diferentes do servidor de comunicação RSE do Developer para System z', cada uma utilizando sua própria transação APPC. A desvantagem principal do método descrito a seguir é que os usuários do Developer para System z devem conectar-se a servidores diferentes no mesmo host para obter o ambiente TSO desejado.
$ cd /etc/rdz $ mkdir /etc/rdz/tso2 $ cp rsed.envvars /etc/rdz/tso2 $ ls /etc/rdz/tso2/ rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> uncomment and change: _FEKFSCMD_TP_NAME_=FEKFTSO2 -> uncomment and change: -Ddaemon.log=/var/rdz/logs/tso2 -> add at the END: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Os comandos acima criam um novo diretório tso2 e copiam os arquivos de configuração do Developer para System z que precisam de mudanças para o novo local. A variável _FEKFSCMD_TP_NAME_ em rsed.envvars deve ser atualizada para definir o novo nome da transação APPC, e o daemon.log deve ser atualizado para definir um novo local de log do daemon (que é criado automaticamente se ele ainda não existir). A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para tso2.
//FEKAPPCC JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=&SYSUID //* //TPADD EXEC PGM=ATBSDFMU //SYSSDLIB DD DISP=SHR,DSN=SYS1.APPCTP //SYSSDOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSIN DD DDNAME=SYSINISP * use SYSINTSO or SYSINISP //SYSINISP DD DATA,DLM='QT' TPADD TPNAME(FEKFTSO2) ACTIVE(YES) TPSCHED_DELIMITER(DLM1) KEEP_MESSAGE_LOG(ERROR) MESSAGE_DATA_SET(&SYSUID..FEKFTSO2.&TPDATE..&TPTIME..LOG) DATASET_STATUS(MOD) CLASS(A) JCL_DELIMITER(DLM2) //FEKFTSO2 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //* //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2 DLM2 DLM1 QT
Em seguida, crie uma nova transação APPC customizando e enviando a tarefa de amostra FEK.#CUST.JCL(FEKAPPCC), conforme exibido na amostra acima. Além da customização normal (descrita na JCL), você também deve alterar o TPNAME para TPNAME(FEKFTSO2) para corresponder à definição _FEKFSCMD_TP_NAME_ no novo rsed.envvars. Você deve alterar também o nome na variável MESSAGE_DATA_SET e o nome do JOB da JCL da transação.
Agora resta apenas criar uma nova tarefa iniciada para o RSE que utiliza um novo número de porta e os novos arquivos de configuração /etc/rdz/tso2.
Consulte as seções relacionadas nesta publicação para obter informações adicionais sobre as ações mostradas acima.
Há situações em que você deseja várias instâncias do Developer para System z ativas no mesmo sistema, por exemplo, durante o teste de um upgrade. Entretanto, alguns recursos, como portas TCP/IP não podem ser compartilhadas, portanto os padrões nem sempre são aplicáveis. Use as informações neste apêndice para planejar a coexistência de instâncias diferentes do Developer para System z, após as quais você pode utilizar este guia de configuração para customizá-las.
Embora seja possível compartilhar certas partes do Developer para System z entre duas (ou mais) instâncias, isso NÃO é recomendado, a menos que seus níveis de software sejam idênticos e as únicas alterações sejam nos membros de configuração. O Developer para System z deixa espaço de customização suficiente para criar várias instâncias que não se sobrepõem, e recomendamos a utilização destes recursos.
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.
Os arquivos de configuração do Developer para System z (e código) podem ser compartilhados através de sistemas diferentes em um sysplex, com cada sistema executando a sua própria cópia idêntica do Developer para System z, se algumas recomendações forem obedecidas.
Em algum conjunto limitado de circunstâncias, é possível compartilhar tudo, menos (algumas das) as partes customizáveis. Um exemplo é fornecer acesso não-SSL para uso no site e comunicação codificada por SSL para uso externo.
Atenção: A configuração compartilhada NÃO PODE ser usada com segurança para
manutenção de teste, visualização técnica ou novo release. |
Para configurar outra instância de uma instalação ativa do Developer para System z, refaça as etapas de customização das partes que são diferentes, usando conjuntos de dados, diretórios e portas diferentes para evitar sobreposição da configuração atual.
Na amostra SSL mencionada acima, a configuração do daemon RSE atual pode ser fechada e depois a configuração clonada pode ser atualizada. Em seguida, a JCL de inicialização do daemon RSE pode ser clonada e customizada com uma nova porta TCP/IP e o local dos arquivos de configuração atualizado. As customizações MVS (JES Job Monitor, entre outras) podem ser compartilhadas entre instâncias SSL e não-SSL. Isso resultaria nas seguintes ações:
$ cd /etc/rdz $ mkdir /etc/rdz/ssl $ cp rsed.envvars /etc/rdz/ssl $ cp ssl.properties /etc/rdz/ssl $ ls /etc/rdz/ssl/ rsed.envvars ssl.properties $ oedit /etc/rdz/ssl/rsed.envvars -> uncomment and change: -Ddaemon.log=/var/rdz/logs/ssl -> add at the END: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/ssl/ssl.properties -> change: change as needed
Os comandos acima copiam os arquivos de configuração do Developer para System z que exigem alterações para um diretório ssl recém-criado. A variável daemon.log em rsed.envvars deve ser atualizada para definir um novo local de log (que é criado automaticamente se ele ainda não existir). A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para ssl. O próprio arquivo ssl.properties pode ser atualizado para corresponder às suas necessidades.
Agora resta criar uma nova tarefa iniciada para o RSE que usa um novo número de porta e os novos arquivos de configuração /etc/rdz/ssl.
Consulte as seções relacionadas nesta publicação para obter informações adicionais sobre as ações mostradas acima.
Quando alterações de código estiverem envolvidas (manutenção, visualizações técnicas, novo release), ou suas alterações forem razoavelmente complexas, é aconselhável fazer outra instalação do Developer para System z. Esta seção descreve os possíveis pontos de conflito entre as diferentes instalações.
A lista a seguir é uma breve visão geral dos itens que devem ser ou são altamente aconselhados a serem diferentes entre as instâncias do Developer para System z:
Uma visão geral mais detalhada é listada a seguir:
//SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMRXX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC ... , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMRXX COLLID DSNREXCS WLM ENVIRONMENT ELAXMWDZ PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMRXX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMRXX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMRXX TO PUBLIC; //
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.
Se você for um usuário anterior do Developer para System z, recomenda-se salvar os arquivos customizados relacionados antes de instalar esta versão do IBM Developer para System z.
Os arquivos customizáveis do Developer para system z podem ser localizados nos seguintes locais:
As configurações anteriores do Developer para system z também documentam as mudanças nos arquivos de configuração pertencentes por outros produtos.
definir uma classe de transação APPC para o serviço TSO Commands
configurar padrões do sistema z/OS UNIX
iniciar servidores na hora do IPL
incluir FEK.SFEKLPA no LPA
FEK.SFEKAUTH autorizado por APF
incluir FEK.SFEKAUTH e FEK.SFEKLOAD em LINKLIST
definir uma transação APPC para o serviço TSO Commands
associar um programa de transação APPC a um grupo de desempenho do TSO
designar um ambiente de aplicativos para um procedimento armazenado do DB2
definir uma classe de transação APPC para o serviço TSO Commands
configurar padrões do sistema z/OS UNIX
FEK.SFEKLOAD autorizado por APF
definir a porta do daemon RSE
definir o serviço do daemon RSE
definir o local do servidor TSO Commands
definir uma transação APPC para o serviço TSO Commands
associar um programa de transação APPC a um grupo de desempenho do TSO
designar um ambiente de aplicativos para um procedimento armazenado do DB2
definir uma classe de transação APPC para o serviço TSO Commands
configurar padrões do sistema z/OS UNIX
FEK.SFEKLOAD autorizado por APF
definir a porta do daemon RSE
definir o serviço do daemon RSE
definir uma transação APPC para o serviço TSO Commands
associar um programa de transação APPC a um grupo de desempenho do TSO
designar um ambiente de aplicativos para um procedimento armazenado do DB2
As seguintes notas de migração são específicas para a versão 7.6.1. Elas são válidas para migração a partir da versão 7.6 ou são adições às notas de migração da versão existente 7.6.
A Tabela 47 fornece uma visão geral de arquivos que foram customizados na versão 7.6. Observe que as bibliotecas de amostra do Developer para System z, FEK.SFEKSAMP, FEK.SFEKSAMV e /usr/lpp/rdz/samples/, são fornecidas com mais membros customizáveis que os listados aqui, como o código de origem de amostra do CARMA e as tarefas para compilá-las.
Membro/Arquivo | Local padrão | Propósito | Notas de migração |
---|---|---|---|
FEKSETUP |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criar conjuntos de dados e diretórios e preenchê-los com arquivos customizáveis | Atualizado para incluir novos membros customizáveis |
JMON |
FEK.SFEKSAMP(FEJJJCL) [FEK.#CUST.PROCLIB] |
JCL para JES Job Monitor | Opção incluída para alterar opções LE |
FEJJJCL |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(JMON)] |
Nome de remessa para o membro de JMON | Consulte o membro de JMON |
RSED |
FEK.SFEKSAMP(FEKRSED) [FEK.#CUST.PROCLIB] |
JCL para daemon RSE | none |
FEKRSED |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(RSED)] |
Nome de remessa para membro de RSED | Consulte o membro de RSED |
LOCKD |
FEK.SFEKSAMP(FEKLOCKD) [FEK.#CUST.PROCLIB] |
JCL para daemon de bloqueio | NOVO, customização é necessária |
FEKLOCKD |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(LOCKD)] |
Nome de remessa para o membro LOCKD | Consulte o membro LOCKD |
ELAXF* |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
JCL para construções de projetos remotos, etc. | none |
FEKRACF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definições de segurança | Atualizações menores |
FEJJCNFG |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Arquivo de configuração do JES Job Monitor | Novas diretivas opcionais foram incluídas |
FEJTSO |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
JCL para emissões TSO | none |
CRA$VMSG |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criação do VSAM de mensagens do CARMA | none |
CRA$VDEF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criação do VSAM de configuração do CARMA | none |
CRA$VSTR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criação do VSAM de informações customizadas do CARMA | none |
CRASUBMT |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
CLIST de inicialização em lote do CARMA | none |
CRASUBCA |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
CLIST de inicialização em lote do CARMA para CA Endevor® SCM RAM | NOVO, customização é opcional |
CRASHOW |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Configuração do CARMA para CA Endevor® SCM RAM | NOVO, customização é opcional |
CRATMAP |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Configuração do CARMA para CA Endevor® SCM RAM | NOVO, customização é opcional |
CRANDVRA | FEK.SFEKPROC | REXX de alocação do CARMA para CA Endevor® SCM RAM | NOVO, customização é opcional |
CRAISPRX |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
Exec de alocação de DD de amostra para CARMA utilizando TSO/ISPF Client Gateway | none |
CRA#VSLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criar VSAM de mensagem do SCLM RAM | none |
CRA#ASLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criar conjuntos de dados do SCLM RAM | none |
CRA#VPDS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criar VSAM de mensagem do PDS RAM | none |
CRA#CRAM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para compilar RAM da estrutura | none |
CRA#VCAD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para a criação do VSAM de configuração do CARMA VSAM para CA Endevor® SCM RAM | NOVO, customização é opcional |
CRA#VCAS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para a criação do VSAM de informações customizadas do CARMA para CA Endevor® SCM RAM | NOVO, customização é opcional |
CRA#UADD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para mesclagem de definições da RAM | NOVO, customização é opcional |
CRA#UQRY |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para extração de definições da RAM | NOVO, customização é opcional |
CRAXJCL |
FEK.SFEKSAMP [FEK.#CUST.ASM] |
Código de origem de amostra para substituição de IRXJCL | none |
CRA#CIRX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para compilar CRAXJCL | none |
ADNCSDRS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir o servidor CRD RESTful como a região primária do CICS | NOVO, customização é opcional |
ADNCSDTX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir os IDs de transação alternativa como a região do CICS | NOVO, customização é opcional |
ADNTXNC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criação de IDs de transação alternativa | NOVO, customização é opcional |
ADNMSGHC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para compilar ADNMSGHS | Renomeado, era ADNCMSGH |
ADNMSGHS |
FEK.SFEKSAMP [FEK.#CUST.COBOL] |
Código de origem de amostra para o Manipulador de Mensagem de Pipeline | Renomeado, era ADNSMSGH |
ADNVCRD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criar o repositório do CRD | Renomeado, era ADNVSAM |
ADNCSDWS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir o servidor CRD de Serviço da Web como a região primária do CICS | Renomeado, era ADNPCCSD |
ADNCSDAR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir o servidor CRD para regiões não-primárias do CICS | Renomeado, era ADNARCSD |
ADNJSPAU |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para atualizar os padrões do CRD | Foram incluídas definições para o serviço RESTful, é necessário refazer as customizações |
ADNVMFST |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criar e definir o repositório do Manifesto | Renomeado, era ADNMFEST |
ELAXMSAM |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
Procedimento JCL do espaço de endereços WLM para o Stored Procedure Builder para PL/I e COBOL | none |
ELAXMJCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para definir Stored Procedure Builder para PL/I e COBOL para o DB2 | none |
FEKAPPCC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para criação de uma transação APPC | none |
FEKAPPCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para exibição de uma transação APPC | none |
FEKAPPCX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para exclusão de uma transação APPC | none |
FEKLOGS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL para coletar arquivos de log | NOVO, customização é opcional |
rsed.envvars |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Variáveis de ambiente do RSE | Cópias mais antigas devem ser substituídas por esta (as customizações devem ser refeitas). |
ISPF.conf |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
arquivo de configuração do TSO/ISPF Client Gateway | ISP.SISPCLIB incluído em SYSPROC para SCLMDT |
CRASRV.properties |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração CARMA | none |
crastart.conf |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração do CARMA para uso de CRASTART | none |
crastart.endevor.conf |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração do CARMA para uso do CRASTART para CA Endevor® SCM RAM | NOVO, customização é opcional |
ssl.properties |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração SSL RSE | Novas diretivas opcionais foram incluídas |
rsecomm.properties |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de rastreio RSE | none |
propertiescfg.properties |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de grupos de propriedades baseados em host | none |
projectcfg.properties |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de projetos baseados em host | none |
FMIEXT.properties |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de Integração do File Manager | Cópias mais antigas devem ser substituídas por esta (as customizações devem ser refeitas). |
uchars.settings |
/usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de caracteres não editáveis | none |
A Tabela 48 fornece uma visão geral de arquivos que foram customizados na versão 7.5. Observe que as bibliotecas de amostra do Developer para System z, FEK.SFEKSAMP, FEK.SFEKSAMV e /usr/lpp/rdz/samples/, são fornecidas com mais membros customizáveis que os listados aqui, como o código de origem do CARMA de amostra e as tarefas para compilá-las.
Membro/Arquivo | Local padrão | Propósito | Notas de migração |
---|---|---|---|
FEKSETUP | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para criar conjuntos de dados e diretórios e preenchê-los com arquivos customizáveis | NOVO, customização é necessária |
JMON | FEK.SFEKSAMP(FEJJJCL)
[FEK.#CUST.PROCLIB] |
JCL para JES Job Monitor | STEPLIB alterado para SFEKAUTH |
RSED | FEK.SFEKSAMP(FEKRSED)
[FEK.#CUST.PROCLIB] |
JCL para daemon RSE | NOVO, customização é necessária |
ELAXF* | FEK.SFEKSAMP
[FEK.#CUST.PROCLIB] |
JCL para construções de projetos remotos, etc. | ELAXFTSO, ELAXFCP1 e ELAXFPP1 são novos |
FEKRACF | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para definições de segurança | NOVO, necessário |
FEJJCNFG | FEK.SFEKSAMP
[FEK.#CUST.PARMLIB] |
Arquivo de configuração do JES Job Monitor |
|
FEJTSO | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
JCL para emissões TSO | O nome da tarefa agora pode ser uma variável |
CRAISPRX | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
Exec de alocação de DD de amostra para CARMA utilizando TSO/ISPF Client Gateway | NOVO, customização é opcional |
CRAXJCL | FEK.SFEKSAMP
[FEK.#CUST.ASM] |
Código de origem de amostra para substituição de IRXJCL | NOVO, customização é opcional |
CRA#CIRX | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para compilar CRAXJCL | NOVO, customização é opcional |
ADNSMSGH | FEK.SFEKSAMP
[FEK.#CUST.COBOL] |
Código de origem de amostra para o Manipulador de Mensagem de Pipeline | As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas) |
ADNPCCSD | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para definir o servidor CRD para a região primária do CICS | As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas) |
ADNJSPAU | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para atualizar os padrões do CRD | NOVO, customização é opcional |
ADNMFEST | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
JCL para criar e definir o repositório do Manifesto | NOVO, customização é opcional |
rsed.envvars | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Variáveis de ambiente do RSE | As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas) |
ISPF.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
arquivo de configuração do TSO/ISPF Client Gateway | Idêntico ao ISPF.conf fornecido com SCLMDT na v7.1 |
CRASRV.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração CARMA |
|
crastart.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração do CARMA para uso de CRASTART | NOVO, customização é opcional |
FMIEXT.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de Integração do File Manager |
|
uchars.settings | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Arquivo de configuração de caracteres não editáveis | NOVO, customização é opcional |
A tabela 23 fornece uma visão geral de arquivos que foram customizados na versão 7.1. Observe que as bibliotecas de amostra do CARMA e do Developer para System z, CRA.SCRASAMP, FEK.SFEKSAMP e /usr/lpp/wd4z/rse/lib/, são fornecidas com mais membros customizáveis que os listados aqui, como o código de origem do CARMA de amostra e as tarefas para compilá-las.
Membro/Arquivo | Local padrão | Propósito | Notas de migração |
---|---|---|---|
ELAXF* | FEK.SFEKSAMP | JCL para construções de projetos remotos, e outras tarefas | ELAXFADT é novo |
CRA$VMSG | CRA.SCRASAMP | JCL para criação do VSAM de mensagens do CARMA |
|
CRA$VDEF | CRA.SCRASAMP | JCL para criação do VSAM de configuração do CARMA |
|
CRA$VSTR | CRA.SCRASAMP | JCL para criação do VSAM de informações customizadas do CARMA | renomeado, era CRASREPR |
CRASUBMT | CRA.SCRASAMP | CLIST de inicialização em lote do CARMA | incluir DD CARMALOG |
CRA#VSLM | CRA.SCRASAMP | JCL para criar VSAM de mensagem do SCLM RAM | renomeado, era CRALREPR |
CRA#ASLM | CRA.SCRASAMP | JCL para criar conjuntos de dados do SCLM RAM | renomeado, era CRASALX |
CRA#VPDS | CRA.SCRASAMP | JCL para criar VSAM de mensagem do PDS RAM | renomeado, era CRATREPR |
CRA#CRAM | CRA.SCRASAMP | JCL para compilar RAM da estrutura | renomeado, era CRARAMCM |
FEKAPPCC | FEK.SFEKSAMP | JCL para criação de uma transação APPC | explorar o suporte ISPF NEST |
rsed.envvars |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Variáveis de ambiente do RSE | As cópias antigas devem ser substituídas por esta (as customizações devem ser refeitas) |
FMIEXT.properties |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Arquivo de configuração de Integração do File Manager | NOVO, customização é necessária, quando usada |
Este apêndice é fornecido para auxiliá-lo com alguns problemas comuns que você pode encontrar ao configurar o SSL (Secure Socket Layer) ou durante a verificação e/ou modificação de uma configuração existente. Este apêndice fornece também uma configuração de amostra para suportar usuários que se autenticam com um certificado X.509.
Comunicação segura significa garantir que seu parceiro de comunicação seja o que alega ser e transmitir informações de forma que dificulte a interceptação e leitura dos dados por terceiros. O SSL fornece essa capacidade em uma rede TCP/IP. Funciona utilizando certificados digitais para se identificar e um protocolo de chave pública para criptografar a comunicação. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre certificados digitais e o protocolo de chave pública usados pelo SSL.
As ações necessárias para configurar as comunicações SSL para o Developer para System z variam de site para site, dependendo das necessidades exatas, do método de comunicação RSE usado e do que já está disponível no site.
Neste apêndice, clonaremos as definições de RSE atuais para que tenhamos uma 2ª conexão do daemon RSE que utilizará SSL. Também criaremos nossos próprios certificados de segurança a serem usados pelas diferentes partes da conexão RSE.
Todo este apêndice apresenta uma convenção de nomenclatura uniforme:
Algumas tarefas descritas abaixo esperam que você esteja ativo no z/OS UNIX. Isso pode ser feito emitindo o comando do TSO OMVS. Use o comando exit para retornar ao TSO.
Os certificados de identidade e as chaves de criptografia/descriptografia usadas pelo SSL são armazenados em um arquivo de chaves. Existem diferentes implementações deste arquivo de chaves, dependendo do tipo de aplicativo.
No entanto, todas as implementações seguem o mesmo princípio. Um comando gera um par de chaves (uma chave pública e uma chave privada associada). O comando agrupa então a chave pública em um certificado X.509 auto-assinado, que é armazenado como uma cadeia de certificados de elemento único. Essa cadeia de certificados e a chave privada são armazenadas como uma entrada (identificada por um alias) em um arquivo-chave.
O daemon RSE é um aplicativo SSL do Sistema e utiliza um arquivo de banco de dados de chaves. Esse banco de dados de chaves pode ser um arquivo físico criado por gskkyman ou um conjunto de chaves gerenciado pelo seu software de segurança compatível com SAF (por exemplo, RACF). O servidor RSE (que é iniciado pelo daemon) é um aplicativo Java SSL e usa um arquivo keystore criado por keytool ou um conjunto de chaves gerenciado pelo seu software de segurança.
Armazenamento de certificado | Criado e gerenciado por | Daemon RSE | servidor RSE |
---|---|---|---|
conjunto de chaves | Produto de segurança compatível com SAF | suportados | suportados |
banco de dados de chaves | gskkyman do z/OS UNIX | suportados | / |
keystore | keytool Java | / | suportados |
Para conectar por meio de SSL, é necessário o keystore e o banco de dados principal, como um arquivo z/OS UNIX ou um conjunto de chaves compatível com SAF:
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Porém, lembre-se de que:
Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações sobre RACF e caracteres digitais. A documentação de gskkyman pode ser localizada em System SSL Programming (SC24-5901) e a documentação de keytool está disponível em http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.
Não execute esta etapa se utilizar o gskkyman para criar o banco de dados de chaves do daemon RSE e o keytool para criar o keystore do servidor RSE.
O comando RACDCERT instala e mantém chaves privadas e certificados no RACF. O RACF suporta várias chaves privadas e certificados para serem gerenciados como um grupo. Esses grupos são chamados anéis de chave.
Consulte Security Server RACF Command Language Reference (SA22-7687) para obter detalhes sobre o comando RACDCERT.
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE) RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse) SETROPTS RACLIST(FACILITY) REFRESH RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') + OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) + NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE) RACDCERT ID(stcrse) ADDRING(rdzssl.racf) RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) + DEFAULT USAGE(PERSONAL))
A amostra acima é iniciada criando-se os perfis necessários e permitindo que o ID de usuário STCRSE acesse os conjuntos de chaves e os certificados pertencentes por esse ID de usuário. O ID do usuário usado deve corresponder ao ID do usuário usado para executar o daemon do RSE SSL. A próxima etapa é criar um novo certificado auto-assinado com rótulo rdzrse. Não é necessária senha. Esse certificado é incluído em um anel de chaves recém-criado (rdzssl.racf). Assim como com o certificado, não é necessária senha para o anel de chave.
O resultado pode ser verificado com a seguinte opção list:
RACDCERT ID(stcrse) LIST Informações do certificado digital para o usuário STCRSE: Rótulo: rdzrse ID do Certificado: 2QjW1OXi0sXZ1aaEqZmihUBA Status: TRUST Data de Início: 24/05/2007 0h Data de Encerramento: 21/05/2017 23h59min59s Número de Série: >00< Nome do Emissor: >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US< Nome do Assunto: >CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US< Tipo de Chave Privada: Não-ICSF Tamanho da Chave Privada: 1024 Associações de Anel: Proprietário do Anel: STCRSE Anel: >rdzssl.racf<
Os certificados podem ser auto-assinados ou assinados por uma Autoridade de Certificação (CA). Um certificado assinado por uma CA significa que a CA garante que o proprietário do certificado é quem afirma ser. O processo de assinatura inclui as credenciais de CA (também um certificado) no certificado, tornando-o uma cadeia de certificados com vários elementos.
Ao usar um certificado assinado por uma CA, você pode evitar perguntas sobre validação confiável pelo cliente do Developer para System z, se o cliente já confiar na CA.
Siga estas etapas para criar e utilizar um certificado assinado pela CA:
RACDCERT ID(stcrse) GENCERT WITHLABEL('rdzrse') . . .
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
RACDCERT CERTAUTH LIST
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
Ou inclua o certificado de CA no banco de dados.
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(ID(stcrse) LABEL('rdzrse') RING(rdzssl.racf))
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') RING(rdzssl.racf))
Nesta etapa, uma nova instância dos arquivos de configuração do RSE é criada, para que a configuração SSL possa ser executada paralelamente com a(s) existente(s). Os comandos de amostra a seguir esperam que os arquivos de configuração estejam em /etc/rdz/, que é o local padrão usado em Configuração da Customização.
$ cd /etc/rdz $ mkdir ssl $ cp rsed.envvars ssl $ cp ssl.properties ssl $ ls ssl rsed.envvars ssl.properties
Os comandos do z/OS UNIX listados acima criam um subdiretório chamado ssl e o preenchem com os arquivos de configuração que precisam de mudanças. Podemos compartilhar os outros arquivos de configuração, o diretório de instalação e os componentes do MVS, porque não são específicos do SSL.
Ao reutilizar a maioria dos arquivos de configuração existentes, podemos nos concentrar nas alterações realmente necessárias para configurar o SSL e evitar fazer a configuração completa do RSE novamente. (Por exemplo, podemos evitar a definição de um novo local para ISPF.conf.)
Até agora, as definições são uma cópia exata da configuração atual, o que implica que os logs do novo daemon RSE sobreporão os arquivos de log atuais do servidor. O RSE também precisa saber onde localizar os arquivos de configuração que não foram copiados para o diretório ssl. Os dois problemas podem ser tratados por mudanças secundárias em rsed.envvars.
$ oedit /etc/rdz/ssl/rsed.envvars -> uncomment and change: -Ddaemon.log=/var/rdz/logs/ssl -> add at the END: # -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
As mudanças acima definem um novo local de log (que será criado pelo daemon RSE se o local do log não existir). As mudanças também atualizam o CLASSPATH para que os processos RSE do SSL procurem arquivos de configuração primeiramente no diretório atual (/etc/rdz/ssl) e, em seguida, procurem no diretório original (/etc/rdz).
Atualizando ssl.properties, o RSE é orientado a iniciar o uso da comunicação criptografada por SSL.
$ oedit /etc/rdz/ssl/ssl.properties -> change: enable_ssl=true -> uncomment and change: daemon_keydb_file=rdzssl.racf -> uncomment and change: daemon_key_label=rdzrse -> uncomment and change: server_keystore_file=rdzssl.racf -> uncomment and change: server_keystore_label=rdzrse -> uncomment and change: server_keystore_type=JCERACFKS
As mudanças acima ativam o SSL e informam ao daemon RSE e ao servidor RSE que seus certificados (compartilhados) estão armazenados com o rótulo rdzrse no conjunto de chaves rdzssl.racf. A palavra-chave JCERACFKS informa ao servidor RSE que um conjunto de chaves compatível com SAF é usado como keystore.
Conforme já mencionado, criaremos uma segunda conexão que utilizará SSL, o que significa a criação de um novo daemon do RSE. O daemon do RSE pode ser uma tarefa iniciada ou uma tarefa do usuário. O método de tarefa do usuário para configuração (teste) inicial será usado. As instruções a seguir esperam que a JCL de amostra esteja em FEK.#CUST.PROCLIB(RSED), que é o local padrão usado em Configuração da Customização:
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE //* //* RSE DAEMON - SSL //* //RSED PROC IVP='', * 'IVP' to do an IVP test // PORT=4047, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz/ssl' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME./bin/rsed.sh &IVP &PORT &CNFG' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //PEND //* //RSED EXEC RSED //*
A configuração do host SSL é completa e o daemon RSE para SSL pode ser iniciado ao enviar a tarefa FEK.#CUST.PROCLIB(RSEDSSL) criada anteriormente.
A nova configuração pode agora ser testada conectando-se com o cliente Developer para System z. Como criamos uma nova configuração para ser usada pelo SSL (clonando uma existente), uma nova conexão deverá ser definida no cliente utilizando-se a porta 4047 para o daemon RSE.
Na conexão, o host e o cliente começarão com alguma troca para configurar um caminho seguro. Parte dessa troca é o intercâmbio de certificados. Se o cliente Developer para System z não reconhecer o certificado do host ou a CA que o assinou, o cliente Developer para System z perguntará ao usuário se é possível confiar nesse certificado.
Clicando no botão Concluir, o usuário pode aceitar esse certificado como confiável; depois disso, a inicialização da conexão continuará.
Quando um certificado é conhecido do cliente, esse diálogo não é mostrado novamente. A lista de certificados confiáveis pode ser gerenciada selecionando Janela > Preferências... > Sistemas Remotos > SSL, que mostra o seguinte diálogo:
Se a comunicação SSL falhar, o cliente retornará uma mensagem de erro. Informações adicionais estão disponíveis nos diferentes arquivos de log do servidor e do usuário, conforme descrito em Criação de Log de Daemon RSE e de Conjunto de Encadeamento e Criação de Log de Usuário do RSE.
O daemon RSE suporta que os próprios usuários se autentiquem com um certificado X.509. Usar a comunicação criptografada SSL é um pré-requisito para essa função por ser uma extensão para a autenticação de host com um certificado usado no SSL.
Há várias maneiras de fazer a autenticação de certificado para um usuário, conforme descrito em Autenticação de Cliente Usando Certificados X.509. As próximas etapas documentam a configuração necessária para suportar o método em que o software de segurança autentica o certificado utilizando a extensão de certificado HostIdMappings.
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') + RING(rdzssl.racf))
Isso conclui a configuração do software de segurança para o certificado de CA.
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) + ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH) ou SETROPTS RACLIST(SERVAUTH) REFRESH
Isso conclui a configuração do software de segurança para a extensão HostIdMappings.
Não execute esta etapa se você usar um conjunto de chaves compatível com SAF para o banco de dados principal do daemon RSE.
gskkyman é um programa z/OS UNIX baseado em shell e orientado por menus, que cria, preenche e gerencia um arquivo z/OS UNIX que contém chaves privadas, pedidos de certificado e certificados. Esse arquivo z/OS UNIX é chamado de banco de dados de chaves.
PATH=$PATH:/usr/lpp/gskssl/bin export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl $ gskkyman Menu do Banco de Dados 1 - Criar novo banco de dados Digite o número da opção: 1 Digite o nome do banco de dados de chaves (pressione ENTER para retornar ao menu):
rdzssl.kdb Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl Digite novamente a senha do banco de dados:
rsessl Digite a expiração da senha em dias (pressione ENTER para
nenhuma expiração): Digite o comprimento do registro do banco de dados (pressione ENTER
para utilizar 2500): Banco de dados de chaves /etc/rdz/ssl/rdzssl.kdb criado. Pressione ENTER para continuar. Menu do Key Management 6 - Criar um certificado auto-assinado Digite o número da opção (pressione ENTER para retornar ao menu anterior): 6 Tipo de Certificado 5 - Certificado do usuário ou do servidor com chave RSA de 1024 bits Selecione o tipo de certificado (pressione ENTER para retornar ao menu): 5 Digite o rótulo (pressione ENTER para retornar ao menu): rdzrse Digite o nome do assunto para o certificado Nome comum (necessário): rdz rse ssl Unidade organizacional (opcional): rdz Organização (necessário): IBM Cidade/Localidade (opcional): Raleigh Estado/Província (opcional): NC País/Região (2 caracteres - necessário): US Digite o número de dias que o certificado permanecerá válido (padrão 365): 3650 Digite 1 para especificar nomes alternativos de assunto ou 0 para continuar: 0 Aguarde ..... Certificado criado. Pressione ENTER para continuar. Menu do Key Management 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu anterior): 0 $ ls -l rdzssl.* total 152 -rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb -rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb $ chmod 644 rdzssl.* $ ls -l rdzssl.* -rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb -rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
A amostra acima inicia criando um banco de dados de chaves chamado rdzssl.kdb com a senha rsessl. Quando o banco de dados existir, ele será preenchido através da criação de um novo certificado auto-assinado, válido durante 10 anos (sem contar os dias extras). O certificado é armazenado com o rótulo rdzrse e com a mesma senha (rsessl) usada para o banco de dados de chaves (esse é um requisito do RSE).
gskkyman aloca o banco de dados de chaves com uma máscara de bits de permissão 600 (muito segura) (só o proprietário tem acesso). A menos que o daemon utilize o mesmo ID do usuário que o criador do banco de dados de chaves, as permissões devem ser configuradas menos restritivas. 644 (o proprietário tem leitura/gravação, todos têm leitura) é uma máscara útil para o comando chmod.
O resultado pode ser verificado ao selecionar a opção Mostrar Informações do Certificado no submenu Gerenciar Chaves e Certificados, como a seguir:
$ gskkyman Menu do Banco de Dados 2 - Abrir banco de dados Digite o número da opção: 2 Digite o nome do banco de dados de chaves (pressione ENTER para retornar ao menu):
rdzssl.kdb Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl Menu do Key Management 1 - Gerenciar chaves e certificados Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1 Lista de Chaves e Certificados 1 - rdzrse Digite o número do rótulo (ENTER para retornar ao menu
de seleção, p para lista anterior: 1 Menu Chave e Certificado 1 - Mostrar informações do certificado Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1 Informações do Certificado Rótulo: rdzrse ID do Registro: 14 ID do Registro do Emissor: 14 Confiável: Sim Versão: 3 Número serial: 45356379000ac997 Nome do emissor: rdz rse ssl rdz IBM Brasil - Centro de Traduções Rodovia SP 101 km 09 CEP 13185-900 Hortolândia, SP NC US Nome do assunto: rdz rse ssl rdz IBM Brasil - Centro de Traduções Rodovia SP 101 km 09 CEP 13185-900 Hortolândia, SP NC US Data de efetivação: 24/05/2007 Data de expiração: 21/05/2017 Algoritmo de chave pública: rsaEncryption Tamanho da chave pública: 1024 Algoritmo de assinatura: sha1WithRsaEncryption ID exclusivo do emissor: Nenhum ID exclusivo do assunto: Nenhum Número de extensões: 3 Digite 1 para exibir extensões, 0 para retornar ao menu: 0 Menu Chave e Certificado 0 - Sair do programa Digite o número da opção (pressione ENTER para retornar ao menu anterior): 0
A amostra ssl.properties a seguir mostra que as diretivas daemon_* são diferentes da amostra do conjunto de chaves SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties -> change: enable_ssl=true -> uncomment and change: daemon_keydb_file=rdzssl.kdb -> uncomment and change: daemon_keydb_password=rsessl -> uncomment and change: daemon_key_label=rdzrse -> uncomment and change: server_keystore_file=rdzssl.racf -> uncomment and change: server_keystore_label=rdzrse -> uncomment and change: server_keystore_type=JCERACFKS
As mudanças acima ativam o SSL e informam ao daemon RSE que o certificado está armazenado com o rótulo rdzrse no banco de dados de chaves rdzssl.kdb com a senha rsessl. O servidor RSE ainda está usando um conjunto de chaves compatível com SAF.
Não execute esta etapa se você utilizar um conjunto de chaves compatível com SAF para o keystore do servidor RSE.
"keytool -genkey" gera um par de chaves privadas e um certificado auto-assinado correspondente que são armazenados como uma entrada (identificada por um alias) em um arquivo keystore (novo).
Todas as informações podem ser transmitidas como um parâmetro, mas devido às limitações no comprimento da linha de comandos, será necessária uma certa interatividade, como a seguir:
$ cd /etc/rdz/ssl $ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass rsessl -keypass rsessl Qual é o seu nome e sobrenome? [Desconhecido]: rdz rse ssl Qual é o nome de sua unidade organizacional? [Desconhecido]: rdz Qual é o nome de sua organização? [Desconhecido]: IBM Qual é o nome de sua cidade ou localidade? [Desconhecido]: Raleigh Qual é o nome de seu estado ou província? [Desconhecido]: NC Qual é o código do país de duas letras para esta unidade? [Desconhecido]: US CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US está correto? (digite "sim" ou "não") [não]: sim $ ls -l rdzssl.* -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
O certificado auto-assinado criado acima é válido durante aproximadamente 10 anos (não contando o dia 29 de fevereiro). Ele é armazenado em /etc/rdz/ssl/rdzssl.jks utilizando o alias rdzrse. Sua senha (rsessl) é idêntica à senha do armazenamento de chaves, que é um requisito para o RSE.
O resultado pode ser verificado com a opção -list, como a seguir:
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v Nome do alias: rdzrse Data de criação: 24 de maio de 2007 Tipo de entrada: keyEntry Comprimento da cadeia de certificados: 1 Certificado 1¨: Proprietário: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US Emissor: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US Número serial: 46562b2b Válido de: 24/5/07 14h17 até: 21/5/17 14h17 Impressões digitais do certificado: MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80 SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
A amostra ssl.properties a seguir mostra que as diretivas server_* são diferentes da amostra do conjunto de chaves SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties -> change: enable_ssl=true -> uncomment and change: daemon_keydb_file=rdzssl.racf -> uncomment and change: daemon_key_label=rdzrse -> uncomment and change: server_keystore_file=rdzssl.jks -> uncomment and change: server_keystore_password=rsessl -> uncomment and change: server_keystore_label=rdzrse -> optionally uncomment and change: server_keystore_type=JKS
As mudanças acima ativam o SSL e informam ao servidor RSE que o certificado está armazenado com o rótulo rdzrse no keystore rdzssl.jks com a senha rsessl. O daemon RSE ainda está usando um conjunto de chaves compatível com SAF.
Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o TCP/IP ou durante a verificação ou a modificação de uma configuração existente.
Consulte Communications Server: IP Configuration Guide (SC31-8775) e Communications Server: IP Configuration Reference (SC31-8776) para obter informações adicionais sobre a configuração do TCP/IP.
Com o uso de APPC para o serviço TSO Commands, o Developer para System z depende de o TCP/IP ter o nome do host correto quando for inicializado. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.
Você pode testar sua configuração TCP/IP com o Installation Verification Program (IVP) do fekfivpt. O comando deve retornar uma saída como nesta amostra ($ é o prompt do z/OS UNIX):
$ fekfivpt Quarta-feira, 2 de julho de 2008, 13h11min54s EDT uid=1(USERID) gid=0(GROUP) utilizando /etc/rdz/rsed.envvars ------------------------------------------------------------- Configuração do resolvedor TCP/IP (ordem de procura do z/OS UNIX): ------------------------------------------------------------- Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC (L) DataSetPrefix = TCPIP (L) HostName = CDFMVS08 (L) TcpIpJobName = TCPIP (L) DomainOrigin = RALEIGH.IBM.COM (L) NameServer = 9.42.206.2 9.42.206.3 (L) NsPortAddr = 53 (L) ResolverTimeout = 10 (L) ResolveVia = UDP (L) ResolverUdpRetries = 1 (*) Options NDots = 1 (*) SockNoTestStor (*) AlwaysWto = NO (L) MessageCase = MIXED (*) LookUp = DNS LOCAL res_init Succeeded res_init Started: 2008/07/02 13:11:54.755363 res_init Ended: 2008/07/02 13:11:54.755371 ************************************************************************ MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54 Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled ------------------------------------------------------------- endereço IP do host: ------------------------------------------------------------- hostName=CDFMVS08 hostAddr=9.42.112.75 bindAddr=9.42.112.75 localAddr=9.42.112.75 Êxito, os endereços correspondem
O resolvedor atua em nome de programas como um cliente que acessa servidores de nomes para resolução de nome para endereço e de endereço para nome. Para resolver a consulta do programa solicitante, o resolvedor pode acessar os servidores de nomes disponíveis, utilize definições locais (por exemplo, /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO ou ETC.IPNODES) ou utilize uma combinação delas.
Quando o espaço de endereços do resolvedor é iniciado, ele lê um conjunto de dados de configuração do resolvedor opcional apontado pelo cartão SETUP DD no procedimento JCL do resolvedor. Se as informações de configuração não forem fornecidas, o resolvedor usará a ordem de procura nativa aplicável do MVS ou do z/OS UNIX sem nenhuma informação de GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES ou COMMONSEARCH.
É importante compreender o ordem de procura dos arquivos de configuração usados pelas funções TCP/IP, e quando você pode sobrescrever a ordem de procura padrão com variáveis de ambiente, JCL ou outras variáveis fornecidas. Este conhecimento permite acomodar o conjunto de dados local e padrões de nomenclatura de arquivos HFS, e é útil conhecer o conjunto de dados da configuração ou o arquivo HFS em uso ao diagnosticar problemas.
Um outro ponto importante a ser observado é que quando uma ordem de procura é aplicada para qualquer arquivo de configuração, a procura finaliza com o primeiro arquivo localizado. Portanto, podem ocorrer resultados inesperados se você colocar informações de configuração em um arquivo que nunca é encontrado, pois outros arquivos aparecem antes na ordem de procura, ou porque o arquivo não está incluído na ordem de procura escolhida pelo aplicativo.
Ao procurar por arquivos de configuração, você pode informar explicitamente ao TCP/IP onde estão a maioria dos arquivos de configuração utilizando instruções DD nos procedimentos JCL ou configurando variáveis de ambiente. Caso contrário, você pode deixar o TCP/IP determinar dinamicamente o local dos arquivos de configuração, com base nas ordens de procura documentadas em Communications Server: IP Configuration Guide (SC31-8775).
O componente de configuração da pilha do TCP/IP utiliza o TCPIP.DATA durante a inicialização da pilha do TCP/IP para determinar o HOSTNAME da pilha. Para obter seu valor, a ordem de procura do ambiente do z/OS UNIX é usada.
O arquivo ou tabela específico que é procurado pode ser um conjunto de dados MVS ou um arquivo HFS, dependendo das definições de configuração do resolvedor e da presença de determinados arquivos no sistema.
O arquivo de base da configuração do resolvedor contém instruções TCPIP.DATA. Além das diretivas do resolvedor, ele é referido para determinar, entre outras coisas, o prefixo do conjunto de dados (valor da instrução DATASETPREFIX) a ser usado ao tentar acessar alguns arquivos de configuração especificados nesta seção.
A ordem de procura usada para acessar o arquivo de configuração do resolvedor de base é a seguinte:
Se definido, o valor da instrução de configuração GLOBALTCPIPDATA do resolvedor é usado (consulte também Compreendendo os Resolvedores). A procura continua por um arquivo de configuração adicional. A procura finaliza com o próximo arquivo localizado.
O valor da variável de ambiente é usado. Esta procura falhará se o arquivo não existir ou estiver alocado exclusivamente em outro lugar.
O conjunto de dados alocado para o SYSTCPD de nome DD é usado. No ambiente z/OS UNIX, um processo-filho não possui acesso ao DD SYSTCPD. Isto porque a alocação de SYSTCPD não é herdada do processo-pai por meio das chamadas de função fork() ou exec.
userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço, tarefa ou encadeamento).
jobname é o nome especificado na instrução JOB da JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
Se definido, o valor da instrução de configuração DEFAULTTCPIPDATA do resolvedor é usado (consulte também Compreendendo os Resolvedores).
As tabelas de conversão (EBCDIC-to-ASCII e ASCII-to-EBCDIC) são consultadas para determinar os conjuntos de dados de conversão a serem usados. A ordem de procura usada para acessar o arquivo de configuração é a seguinte. A ordem de procura termina quando o primeiro arquivo é localizado:
userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).
jobname é o nome especificado na instrução JOB da JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
Por padrão, o resolvedor primeiro tenta utilizar qualquer servidor de nomes de domínios configurado para pedidos de resolução. Se o pedido de resolução não puder ser satisfeito, as tabelas do host local são usadas. O comportamento do resolvedor é controlado pelas instruções TCPIP.DATA.
As instruções do resolvedor TCPIP.DATA definem se e como os servidores de nomes de domínios devem ser usados. A instrução LOOKUP TCPIP.DATA também pode ser usada para controlar como os servidores de nomes de domínios e as tabelas do host local são usadas. Para obter mais informações sobre instruções TCPIP.DATA, consulte Communications Server: IP Configuration Reference (SC31-8776).
O resolvedor utiliza a ordem de procura exclusiva Ipv4 para obter informações de nomes de sites incondicionalmente para chamadas de API getnetbyname. A ordem de procura exclusiva de Ipv4 para informações de nome de site é a seguinte. A procura termina quando o primeiro arquivo é localizado:
O valor da variável de ambiente é o nome do arquivo de informações HOSTS.SITEINFO criado pelo comando MAKESITE do TSO.
O valor da variável de ambiente é o nome do arquivo de informações HOSTS.ADDRINFO criado pelo comando MAKESITE do TSO.
userid é o ID do usuário associado ao ambiente de segurança atual (espaço de endereço ou tarefa/encadeamento).
jobname é o nome especificado na instrução JOB da JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado.
hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
Conforme informado anteriormente, o Developer para System z depende de o TCP/IP ter o nome de host correto quando inicializado, ao utilizar APPC. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.
No exemplo a seguir, nós concentraremos em algumas tarefas de configuração para o TCP/IP e o Resolver. Observe que isso não abrange uma configuração completa do TCP/IP ou do Resolver, ela destaca alguns aspectos principais que podem ser aplicáveis no seu site:
//TCPIP PROC PARMS='CTRACE(CTIEZB00)',PROF=TCPPROF,DATA=TCPDATA //* //* TCP/IP NETWORK //* //TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS //PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF) //SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA) //SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136) //SYSERROR DD SYSOUT=*
; HOSTNAME especifica o nome do host TCP deste sistema. Se não ; especificado, o HOSTNAME padrão será o nome do nó especificado ; no membro IEFSSNxx PARMLIB. ; ; HOSTNAME ; ; DOMAINORIGIN especifica a origem do domínio que será anexado ; nos nomes dos hosts transmitidos para o resolvedor. Se um nome ; de host contiver algum ponto, então DOMAINORIGIN não será anexado ; ao nome do host. ; DOMAINORIGIN RALEIGH.IBM.COM ; ; NSINTERADDR especifica o endereço IP do servidor de nomes. ; LOOPBACK (14.0.0.0) especifica o servidor de nomes local. Se um servidor ; de nomes não será usado, então não codifique uma instrução NSINTERADDR. ; (Comente a linha NSINTERADDR abaixo). Isto fará com que todos os nomes ; sejam resolvidos por meio de consulta na tabela de sites. ; ; NSINTERADDR 14.0.0.0 ; ; TRACE RESOLVER realizará um rastreio completo de todas as consultas e ; fará com que as respostas do servidor de nomes ou tabelas de sites sejam ; gravadas no console do usuário. Este comando é destinado somente para ; finalidades de depuração. ; ; TRACE RESOLVER
//RESOLVER PROC PARMS='CTRACE(CTIRES00)' //* //* IP NAME RESOLVER - START WITH SUB=MSTR //* //RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS //*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP DomainOrigin RALEIGH.IBM.COM HostName CDFMVS08
Conforme mencionado em Ordens de Procura Usadas no Ambiente do z/OS UNIX, o arquivo de base da configuração contém instruções TCPIP.DATA. Se o nome do sistema for CDFMVS08 (TCPDATA informou que o nome do sistema é usado como nome do host) podemos ver que /etc/resolv.conf está em sincronismo com SYS1.TCPPARMS(TCPDATA). Não há definições DNS, portanto a consulta à tabela de sites será usada.
# Resolver /etc/hosts file cdfmvs08 9.42.112.75 cdfmvs08 # CDFMVS08 Host 9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host 127.0.0.1 localhost
O conteúdo mínimo deste arquivo é a informação sobre o sistema atual. Na amostra acima, definimos cdfmvs08 e cdfmvs08.raleigh.ibm.com como um nome válido para o endereço IP do nosso sistema z/OS.
Se estivéssemos utilizando um DNS (servidor de nomes de domínios), o DNS conteria as informações de /etc/hosts e /etc/resolv.conf e SYS1.TCPPARMS(TCPDATA) teriam instruções que identificam o DNS em nosso sistema.
Para evitar confusão, e aconselhável manter os arquivos de configuração do TCP/IP e do Resolver em sincronismo um com o outro.
Descrição do Tipo do Arquivo | APIs afetadas | Arquivos do Candidato |
---|---|---|
Arquivos de Base da Configuração do Resolvedor | Todas as APIs |
|
Tabelas de Conversão | Todas as APIs |
|
Tabelas do Host Local |
endhostent endnetent getaddrinfo gethostbyaddr gethostbyname gethostent GetHostNumber GetHostResol GetHostString getnameinfo getnetbyaddr getnetbyname getnetent IsLocalHost Resolve sethostent setnetent |
IPv4
IPv6
|
Quando ocorrerem problemas nos quais o TCP/IP Resolver não pode resolver o endereço do host corretamente, muitas vezes isso é devido a um arquivo de configuração do resolvedor ausente ou incompleto. Uma indicação clara desse problema é a seguinte mensagem em lock.log:
clientip(0.0.0.0) <> callerip(<endereço IP do host>)
Para verificar isso, execute o fekfivpt TCP/IP IVP, conforme descrito em Verificação de Instalação. A seção de configuração do resolvedor da saída será semelhante à seguinte amostra:
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = /etc/resolv.conf Translation Table = Default UserId/JobName = USERID Caller API = LE C Sockets Caller Mode = EBCDIC
Certifique-se de que as definições no arquivo (ou conjunto de dados) referido pelo "Local Tcp/Ip Dataset" estejam corretas.
Esse campo ficará em branco se você não utilizar um nome padrão para o arquivo resolvedor de IP (utilizando a ordem de procura do z/OS UNIX). Nesse caso, inclua a seguinte instrução no rsed.envvars, em que <arquivo resolvedor> ou <dados do resolvedor> representam o nome do arquivo resolvedor de IP:
RESOLVER_CONFIG=<arquivo resolvedor>
ou
RESOLVER_CONFIG='<conjunto de dados do resolvedor>'
Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o INETD ou durante a verificação ou a modificação de uma configuração existente. INETD é usado pelo Developer para System z para a funcionalidade REXEC/SSH.
O daemon do INETD fornece gerenciamento de serviço para uma rede IP. Ele reduz o carregamento do sistema, invocando outros daemons apenas quando forem necessários e fornecendo vários serviços de Internet simples (como echo) internamente. O INETD lê o arquivo de configuração inetd.conf para determinar quais serviços adicionais fornecer. ETC.SERVICES é usado para vincular os serviços a portas.
Os serviços que dependem do INETD são definidos em inetd.conf, lido pelo INETD no momento da inicialização. O local padrão e o nome de inetd.conf é /etc/inetd.conf. Um arquivo inetd.conf de amostra pode ser encontrado em /samples/inetd.conf.
As seguintes regras de sintaxe se aplicam às entradas de inetd.conf:
Cada entrada consiste em 7 campos posicionais, correspondendo ao formato:
service_name socket_type protocol wait_flag userid server_program server_program_arguments
protocol pode ser tcp[4|6] ou udp[4|6], e é usado para qualificar o nome do serviço. O nome do serviço e o protocolo devem corresponder a uma entrada em ETC.SERVICES, exceto que "4" ou "6" não deve ser incluído na entrada ETC.SERVICES.
sndbuf e rcvbuf especificam o tamanho dos buffers de envio e recebimento. O tamanho, representado por n, pode estar em bytes, ou um "k" ou "m" pode ser incluído para indicar kilobytes ou megabytes respectivamente. sndbug e rcvbuf pode ser usado na ordem.
wait ou nowait.wait indica que o daemon é de encadeamento único e outro pedido não será submetido a manutenção até que o primeiro seja concluído. Se nowait for especificado, o INETD emitirá uma aceitação quando um pedido de conexão for recebido no soquete de fluxo. Se a espera for especificada, será responsabilidade do servidor emitir a aceitação, se este for um soquete de fluxo.
max é o número máximo de usuários permitidos para solicitar manutenção em um intervalo de 60 segundos. O padrão é 40. Se for excedido, a porta do serviço será encerrada.
userid é o ID do usuário em que o daemon bifurcado deve ser executado. Esse ID do usuário pode ser diferente do ID do usuário do INETD. As permissões designadas a este ID do usuário depenem das necessidades do serviço. O ID do usuário do INETD precisa da permissão BPX.DAEMON para alternar o processo bifurcado para este ID do usuário.
O valor group opcional, separado do ID do usuário por um ponto (.), permite que o servidor seja executado com um ID de grupo diferente do padrão para este ID do usuário.
O INETD utiliza ETC.SERVICES para mapear números de porta e protocolos para os serviços que deve suportar. Ele pode ser um conjunto de dados MVS ou um arquivo z/OS UNIX. Uma amostra é fornecida em SEZAINST(SERVICES), que também está disponível como /usr/lpp/tcpip/samples/services. A ordem de procura para ETC.SERVICES depende do método de inicialização do INETD; z/OS UNIX ou MVS nativo.
As seguintes regras de sintaxe se aplicam à especificação de informações de serviços:
Cada entrada consiste de quatro campos posicionais correspondendo ao formato:
service_name port_number/protocol aliases
A ordem de procura usada para acessar ETC.SERVICES no z/OS UNIX é a seguinte. A procura termina quando o primeiro arquivo é localizado:
userid é o ID do usuário usado para iniciar INETD
.hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
A ordem de procura usada para acessar ETC.SERVICES no MVS nativo é a seguinte. A procura termina quando o primeiro conjunto de dados é localizado:
O conjunto de dados alocado para a instrução DD SERVICES é usado
userid é o ID do usuário usado para iniciar INETD
.jobname é o nome especificado na instrução JOB JCL para tarefas em lote ou o nome do procedimento para um procedimento iniciado
hlq representa o valor da instrução DATASETPREFIX especificada no arquivo de base da configuração do resolvedor (se localizado); caso contrário, hlq é TCPIP por padrão.
Não confunda as definições PORT (ou PORTRANGE) em PROFILE.TCPIP com as portas definidas em ETC.SERVICES, pois essas definições têm finalidades diferentes. As portas definidas em PROFILE.TCPIP são usadas pelo TCPIP para ver se a porta está reservada para um determinado serviço. ETC.SERVICES é usado pelo INETD para mapear uma porta para um serviço.
Quando o INETD recebe um pedido em uma porta monitorada, bifurca um processo-filho (com o serviço solicitado) chamado inetdx, em que inetd é o nome da tarefa do INETD (depende do método de inicialização) e x é um número de dígito único.
Isso complica a reserva de porta, portanto, se uma porta monitorada do INETD for reservada em PROFILE.TCPIP, é aconselhável usar o nome do procedimento JCL iniciado para o Espaço de Endereço de Kernel do z/OS UNIX para permitir que quase todos os processos sejam ligados à porta. Normalmente, esse nome é OMVS, a menos que um nome diferente seja especificado explicitamente no parâmetro STARTUP_PROC do membro BPXPRMxx parmlib.
A lista a seguir explica como determinar o nome da tarefa, de acordo com o ambiente em que o aplicativo é executado:
O processo do INETD cria um arquivo temporário, /etc/inetd.pid, que contém o PID (ID do processo) do daemon INETD em execução no momento. Esse valor de PID é usado para identificar registros syslog originados do processo INETD e para fornecer o valor PID para comandos que requerem um, como kill. Também é usado como um mecanismo de bloqueio para impedir que mais de um 1 processo INETD esteja ativo.
A implementação de INETD do z/OS UNIX está localizada por padrão em /usr/sbin/inetd e suporta dois parâmetros de inicialização opcionais não-posicionais:
/usr/sbin/inetd [-d] [inetd.conf]
Você deve iniciar o INETD no momento do IPL. A forma mais comum de fazer isso é iniciá-lo no /etc/rc ou /etc/inittab (z/OS 1.8 e posterior apenas). Pode ser iniciado de uma tarefa ou uma tarefa iniciada utilizando BPXBATCH ou de uma sessão de shell de um usuário com autoridade apropriada.
Quando iniciado a partir do script do shell de inicialização do z/OS UNIX, /etc/rc, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Um arquivo /etc/rc de amostra é fornecido como /samples/rc. Os seguintes comandos de amostra podem ser usados para iniciar o INETD:
# Start INETD _BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf & sleep 5
O z/OS 1.8 e superior oferecem um método alternativo, /etc/inittab, para emissão de comandos durante a inicialização do z/OS UNIX. /etc/inittab permite a definição do parâmetro respawn, que reinicia o processo automaticamente quando ele é encerrado (um WTOR é enviado ao operador para um segundo reinício, em 15 minutos). Quando iniciado a partir de /etc/inittab, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. Um /etc/inittab de amostra é fornecido como /samples/inittab. O seguinte comando de amostra pode ser usado para iniciar o INETD:
# Start INETD inetd::respfrk:/usr/sbin/inetd /etc/inetd.conf
O método de inicialização BPXBATCH funciona para tarefas iniciadas e tarefas do usuário. Observe que o INETD é um processo em segundo plano, portanto a etapa BPXBATCH iniciando o INETD será encerrada em segundos após a inicialização. Quando iniciado pelo BPXBATCH, o INETD utiliza a ordem de procura do z/OS UNIX para localizar ETC.SERVICES. A JCL listada na seguinte amostra de código é um procedimento de amostra para iniciar INETD (a etapa KILL remove um processo INETD ativo, se houver algum):
//INETD PROC PRM= //* //KILL EXEC PGM=BPXBATCH,REGION=0M, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD SYSOUT=* //* STDIN, STDOUT e STDENV são padronizados como /dev/null //*
// PARM='PGM /usr/sbin/inetd //''SYS1.TCPPARMS(INETCONF)'' &PRM'
Quando iniciado a partir de uma sessão shell, o INETD utiliza a procura do z/OS UNIX para localizar ETC.SERVICES. Os seguintes comandos de amostra podem ser usados (por uma pessoa com autoridade suficiente) para parar e iniciar o INETD (# é o prompt do z/OS UNIX):
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd &
O INETD é um processo do z/OS UNIX e, portanto, requer definições OMVS válidas no software de segurança para o ID do usuário associado ao INETD. UID, HOME e PROGRAM devem ser configurados para o ID do usuário, junto com o GID para o grupo padrão do usuário. Se o INETD for iniciado pelo /etc/rc ou pelo /etc/inittab, o ID do usuário será herdado do kernel z/OS UNIX, padrão OMVSKERN.
ADDGROUP OMVSGRP OMVS(GID(1)) ADDUSER OMVSKERN DFLTGRP(OMVSGRP) NOPASSWORD + OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
INETD é um daemon que exige acesso a funções como setuid(). Portanto, o ID do usuário usado para iniciar o INETD requer acesso READ ao perfil BPX.DAEMON na classe FACILITY. Se esse perfil não estiver definido, UID 0 será obrigatório.
PERMIT BPX.DAEMON CLASS(FACILITY) ACCESS(READ) ID(OMVSKERN)
O ID do usuário do INETD requer permissão EXECUTE para o programa inetd (/usr/sbin/inetd), acesso READ para os arquivos inetd.conf e ETC.SERVICES e acesso WRITE para /etc/inetd.pid. Se você deseja executar o INETD sem o UID 0, pode conceder acesso CONTROL ao perfil SUPERUSER.FILESYS na classe UNIXPRIV para fornecer as permissões necessárias para os arquivos z/OS UNIX.
Os programas que requerem autoridade de daemon devem ser controlados por programa, se BPX.DAEMON estiver definido na classe FACILITY. Isso já é feito para o programa INETD padrão (/usr/sbin/inetd), mas deve ser definido manualmente se você utilizar uma cópia ou uma versão customizada. Use o comando extattr +p para tornar um arquivo z/OS UNIX controlado por programa. Use a classe RACF PROGRAM para tornar um módulo de carregamento MVS controlado por programa.
Os programadores de sistema que precisam reiniciar o INETD em sua sessão de shell iniciarão o INETD utilizando suas permissões. Portanto, devem ter a mesma lista de permissões que o ID do usuário do INETD regular. Além disso, também precisam de permissões para listar e parar o processo do INETD. Isso pode ser feito de várias maneiras.
Isso não é recomendado para IDs de usuário "humanos", pois não há restrições relacionadas ao z/OS UNIX.
Permite que o usuário se torne o UID 0 por meio do comando su. Essa é a configuração recomendada.
Consulte UNIX System Services Command Reference (SA22-7802) para saber mais sobre os comandos extattr e su. Consulte UNIX System Services Planning (GA22-7800) para saber mais sobre a classe UNIXPRIV e perfis BPX.* na classe FACILITY. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre as definições de segmento OMVS e a classe PROGRAM.
O Developer para System z depende do INETD para gerenciar REXEC e/ou SSH. Ele também pode impor requisitos adicionais para a configuração do INETD descrita acima.
REXEC (ou SSH) é usado para os dois seguintes propósitos, conforme descrito em (Opcional) Usando REXEC (ou SSH).
As ações remotas em subprojetos z/OS UNIX não requerem configurações especiais. O método de inicialização RSE alternativo, no entanto, requer configurações especiais.
As configurações ambientais do INETD, informadas ao iniciar um processo, e as permissões para o ID do usuário do INETD, devem ser definidas adequadamente para que o INETD inicie o servidor RSE.
O daemon REXEC (ou SSH) que é iniciado pelo INETD quando um cliente se conecta à porta 512 (ou 22, respectivamente) é usado para fazer autenticação, iniciar o servidor RSE e retornar o número da porta para favorecer a comunicação com o cliente. Para isso, o ID do usuário designado ao daemon do REXEC (ou SSH) (em inetd.conf) requer as seguintes permissões:
Este apêndice é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar ao configurar o APPC (Advanced Program-to-Program Communication) ou durante a verificação e a modificação de uma configuração existente.
Consulte MVS Planning: APPC/MVS Management (SA22-7599) e MVS Initialization and Tuning Reference (SA22-7592) para obter informações adicionais sobre o gerenciamento de APPC e sobre os membros parmlib discutidos abaixo.
Observe que isso não abrange uma configuração completa do APPC, apenas destaca alguns aspectos principais que podem ser aplicáveis a seu site.
O membro SYS1.SAMPLIB(ATBALL) contém uma lista e descrições de todos os membros relacionados ao APPC (amostra) em SYS1.SAMPLIB.
APPC/MVS armazena seus dados de configuração nos seguintes membros SYS1.PARMLIB e dois conjuntos de dados VSAM:
Um TP é um programa aplicativo que utiliza o APPC para se comunicar com um TP no mesmo sistema, ou em outro, para acessar recursos. A configuração do APPC para o Developer para System z ativa um novo TP chamado FEKFRSRV, mencionado como o serviço TSO Commands.
A tarefa a seguir é uma concatenação dos membros de amostra SYS1.SAMPLIB(ATBTPVSM) e SYS1.SAMPLIB(ATBSIVSM), e pode ser usada para definir os VSAMs do APPC.
//APPCVSAM JOB <parâmetros da tarefa> //* //* CUIDADO: Isso não é um procedimento JCL nem uma tarefa completa. //* Antes de usar esta amostra, você deverá fazer as seguintes //* modificações: //* 1. Altere os parâmetros da tarefa de acordo com os requisitos do sistema. //* 2. Altere ****** para o volume que conterá os VSAMs do APPC. //* //TP EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCTP) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(3824 7024) - KEYS(112 0) - RECORDS(300 150)) - DATA (NAME(SYS1.APPCTP.DATA)) - INDEX (NAME(SYS1.APPCTP.INDEX)) //* //SI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCSI) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(248 248) - KEYS(112 0) - RECORDS(50 25)) - DATA (NAME(SYS1.APPCSI.DATA)) - INDEX (NAME(SYS1.APPCSI.INDEX)) //*
O APPC é uma implementação do protocolo SNA (Systems Network Architecture) LU 6.2. O SNA oferece formatos e protocolos que definem uma variedade de componentes SNA físicos e lógicos, como a Unidade Lógica (LU). A LU 6.2 é um tipo de unidade lógica desenvolvida especificamente para controlar a comunicação entre os programas aplicativos.
Para utilizar SNA no MVS, você precisa instalar e configurar o VTAM (Virtual Telecommunications Access Method). O VTAM deve estar ativo antes que as tarefas do sistema APPC possam ser usadas.
A parte específica do APPC da configuração VTAM consiste em três etapas:
O ACBNAME de MVSLU01 usado no membro de amostra SYS1.SAMPLIB(ATBAPPL) pode ser usado para corresponder aos padrões do site, mas deve corresponder às definições no membro SYS1.PARMLIB(APPCPMxx).
MVSLU01 APPL ACBNAME=MVSLU01, C APPC=YES, C AUTOSES=0, C DDRAINL=NALLOW, C DLOGMOD=APPCHOST, C DMINWNL=5, C DMINWNR=5, C DRESPL=NALLOW, C DSESLIM=10, C LMDENT=19, C MODETAB=LOGMODES, C PARSESS=YES, C SECACPT=CONV, C SRBEXIT=YES, C VPACING=1
Consulte Communications Server IP SNA Network Implementation Guide (SC31-8777) para obter informações adicionais sobre a configuração de VTAM.
Para ativar e suportar o fluxo de comunicação entre os sistemas, os sites devem definir Unidades Lógicas (LUs) entre as sessões que podem ser ligadas. Um site precisa definir, pelo menos, uma LU antes que o processamento de APPC/MVS possa ocorrer, mesmo quando o processamento APPC permanecer em um sistema único. As LUs são algumas das definições realizadas em SYS1.PARMLIB(APPCPMxx).
O serviço TSO Commands requer que o APPC seja configurado para ter uma LU de base que possa manipular pedidos de entrada e saída.
A definição da LU deve ser incluída no membro SYS1.PARMLIB(APPCPMxx) e precisa incluir os parâmetros BASE e SCHED(ASCH). O membro APPCPMxx também especifica quais conjuntos de dados VSAM de TP e de SI VSAM serão usados.
A amostra de código a seguir é um membro SYS1.PARMLIB(APPCPMxx) que pode ser usado para o serviço TSO Commands.
LUADD ACBNAME(MVSLU01) BASE SCHED(ASCH) TPDATA(SYS1.APPCTP) SIDEINFO DATASET(SYS1.APPCSI)
Quando um sistema possui vários nomes de LU, pode ser necessário fazer alterações, dependendo de qual LU o sistema seleciona como LU BASE. A LU BASE para o sistema é determinada da seguinte forma:
Se seu sistema possui uma LU com parâmetros BASE e NOSCHED, esta LU seria usada como a LU BASE mas o serviço TSO Commands não funcionará porque esta LU não possui um planejador de transações para manipular pedidos para a transação FEKFRSRV. Se esta LU não puder ser alterada para remoção do parâmetro NOSCHED, a variável de ambiente rsed.envvars (_FEKFSCMD_PARTNER_LU) pode ser configurada para a LU que possui BASE e SCHED(ASCH), tal como:
_FEKFSCMD_PARTNER_LU=MVSLU01
Consulte Arquivo de Configuração do RSE rsed.envvars para obter informações adicionais sobre rsed.envvars.
O planejador de transações APPC/MVS (nome padrão é ASCH) inicia e planeja programas de transações em resposta aos pedidos de entrada para conversões. O membro SYS1.PARMLIB(ASCHPMxx) controla seu funcionamento, por exemplo, com definições de classe da transação.
A classe de transação APPC usada para o serviço TSO Commands deve ter iniciadores APPC suficientes para permitir um iniciador para cada usuário do Developer para System z.
O serviço TSO Commands também precisa das especificações padrão para ser especificado nas seções OPTIONS e TPDEFAULT.
A amostra de código a seguir é um membro SYS1.PARMLIB(ASCHPMxx) que pode ser usado para o serviço TSO Commands.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200) OPTIONS DEFAULT(A) TPDEFAULT REGION(2M) TIME(5) MSGLEVEL(1,1) OUTCLASS(X)
As alterações na configuração documentadas nas etapas acima agora podem ser ativadas. Isso pode ser feito de diversas maneiras, dependendo das circunstâncias:
Inclua esses comandos em SYS1.PARMLIB(COMMNDxx) para iniciá-los na inicialização do sistema.
Os comandos de console D APPC e D ASCH podem ser usados para verificar a configuração do APPC. Consulte MVS System Commands (GC28-1781) para obter informações adicionais sobre os comandos do console mencionados.
Quando o APPC/MVS está ativo, o serviço TSO Commands do Developer para System z pode ser definido, conforme descrito em (Opcional) Transação APPC para o Serviço de Comandos TSO.
A maneira documentada para definir a transação do APPC é customizar e enviar a FEK.#CUST.JCL(FEKAPPCC).
A transação APPC também pode ser definida interativamente por meio da interface ISPF do APPC, documentada em um white paper. Esse White Paper descreve também como configurar a transação APPC para coletar informações de contabilidade específicas ao usuário.
O White Paper do APPC e do WebSphere Developer para System z (SC23-5885-00) está disponível na biblioteca da Internet em Developer para System z, http://www-306.ibm.com/software/awdtools/rdz/library/.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
O Developer para System z suporta opções de configuração APPC e VTAM alternativas, sendo que algumas estão documentadas nesta seção.
O nome da transação padrão para o serviço TSO Commands é FEKFRSRV, conforme descrito em (Opcional) Transação APPC para o Serviço de Comandos TSO. Conforme descrito na mesma seção, esse nome pode ser alterado ao definir a transação para APPC.
Observe que a alteração do nome da transação no APPC significa que o novo nome deverá ser designado a _FEKFSCMD_TP_NAME_ em rsed.envvars, conforme descrito em Arquivo de Configuração do RSE rsed.envvars.
APPC é um protocolo de comunicação que permite que um programa (o nó parceiro) interaja com um programa no host (o nó local). Com o Developer para System z, o nó parceiro (servidor TSO Commands) e o nó local (servidor RSE) ficam ativos no mesmo sistema z/OS. Por padrão, ambos usam a mesma definição de LU (BASE) para estabelecer comunicação.
Você pode especificar um nome de LU parceira alternativo para o serviço TSO Commands na diretiva _FEKFSCMD_PARTNER_LU_ de rsed.envvars, conforme descrito em Arquivo de Configuração do RSE rsed.envvars. Observe que não é possível alterar a LU local, que deve ser sempre uma LU BASE válida (com as palavras-chave BASE e SCHED).
O VTAM suporta uma configuração de APPC segura, na qual a comunicação entre a LU parceira e a local deve ser definida para o software de segurança.
Ele é ativado ao incluir VERIFY=REQUIRED na definição do VTAM da LU (BASE) local. As definições de segurança devem ser feitas na classe APPCLU, conforme descrito em MVS Planning: APPC/MVS Management (SA22-7599).
Observe que se essa configuração estiver ativa no VTAM e a configuração de seu software de segurança não estiver concluída, a comunicação com o serviço TSO Commands falhará na inicialização sem qualquer mensagem no log do sistema indicando que o VTAM recusou a configuração da conexão. O teste IVP do APPC (fekfivpa) falhará com a mensagem "Return code 1 - Allocate Failure no retry".
Este apêndice lista os pré-requisitos e correquisitos do host para esta versão do Developer para System z.
Consulte Rational Developer para System z Prerequisites (SC23-7659) na biblioteca on-line do Developer para System z em http://www-01.ibm.com/software/awdtools/rdz/library/ para obter uma lista atualizada de requisitos obrigatórios e opcionais.
Os produtos listados nesta seção estão todos disponíveis no momento da publicação deste manual. Consulte o Web site do IBM Software Support Lifecycle http://www.ibm.com/software/support/lifecycle/, para ver se um produto selecionado ainda está disponível no momento em que você desejar usar a função relacionada do Developer para System z.
O uso do Developer para System z exige que você tenha o seguinte ambiente com os pré-requisitos apropriados:
Um dos seguintes níveis deve estar instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5694-A01 | z/OS v 1.11 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS v 1.10 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS v 1.9 |
ISPF:
TCP/IP:
|
5694-A01 | z/OS v 1.8 |
ISPF:
TCP/IP:
|
O Web site do produto relacionado é:
Para instalar o Developer para System z, um dos seguintes níveis deve ser instalado:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-G44 | IBM System Modification Program Extended (SMP/E) para z/OS v 3.5 | Nenhum PTF ou Nível de Serviço necessário |
5655-G44 | IBM System Modification Program Extended (SMP/E) para z/OS v 3.4 | Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
Para suportar aplicativos que usam o Remote Systems Explorer (RSE), um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-R32 | IBM 64-bit SDK para z/OS, Java 2 Technology Edition, v 6.0 | release de serviço 7 |
5655-R31 | IBM 31-bit SDK para z/OS, Java 2 Technology Edition, v 6.0 | release de serviço 7 |
5655-N99 | IBM 64-bit SDK para z/OS, Java 2 Technology Edition, v 5.0 | release de serviço 11 |
5655-N98 | IBM 31-bit SDK para z/OS, Java 2 Technology Edition, v 5.0 | release de serviço 11 |
O Web site do produto relacionado é:
Os produtos listados nesta seção e outros softwares declarados são necessários para suportar recursos específicos do Developer para System z. O cliente da estação de trabalho do Developer para System z pode ser instalado com êxito sem esses requisitos. Porém, um requisito do host estabelecido deve estar instalado e em funcionamento no tempo de execução para que o recurso correspondente funcione conforme projetado.
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5694-A01 | z/OS v 1.11 |
HLASM Nenhum PTF ou Nível de Serviço necessário
XL C/C++ Nenhum PTF ou Nível de Serviço necessário
SCLM Nenhum PTF ou Nível de Serviço necessário
LE (PL/I) Nenhum PTF ou Nível de Serviço necessário
TN3270 Nenhum PTF ou Nível de Serviço necessário |
5694-A01 | z/OS v 1.10 |
HLASM Nenhum PTF ou Nível de Serviço necessário
XL C/C++ Nenhum PTF ou Nível de Serviço necessário
SCLM Nenhum PTF ou Nível de Serviço necessário
LE (PL/I) Nenhum PTF ou Nível de Serviço necessário
TN3270 Nenhum PTF ou Nível de Serviço necessário |
5694-A01 | z/OS v 1.9 |
HLASM Nenhum PTF ou Nível de Serviço necessário
XL C/C++ Nenhum PTF ou Nível de Serviço necessário
SCLM
LE (PL/I) Nenhum PTF ou Nível de Serviço necessário
TN3270 Nenhum PTF ou Nível de Serviço necessário |
5694-A01 | z/OS v 1.8 |
HLASM Nenhum PTF ou Nível de Serviço necessário
XL C/C++ Nenhum PTF ou Nível de Serviço necessário
SCLM
LE (PL/I)
TN3270 Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
O Web site do produto relacionado é:
O Web site do produto relacionado é:
O Web site do produto relacionado é:
O Web site do produto relacionado é:
O Web site do produto relacionado é:
Para compilar programas COBOL desenvolvidos ou editados no Developer para System z, um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-S71 | IBM Enterprise COBOL para z/OS v 4.2 | Nenhum PTF ou Nível de Serviço necessário |
5655-S71 | IBM Enterprise COBOL para z/OS v 4.1 | Nenhum PTF ou Nível de Serviço necessário |
5535-G53 | IBM Enterprise COBOL para z/OS v 3.4 | Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
Para compilar programas PL/I desenvolvidos ou editados no Developer para System z, um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-H31 | IBM Enterprise PL/I para z/OS v 3.9 | Nenhum PTF ou Nível de Serviço necessário |
5655-H31 | IBM Enterprise PL/I para z/OS v 3.8 | Nenhum PTF ou Nível de Serviço necessário |
5655-H31 | IBM Enterprise PL/I para z/OS v 3.7 | Nenhum PTF ou Nível de Serviço necessário |
5655-H31 | IBM Enterprise PL/I para z/OS v 3.6 | Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
Para suportar depuração remota do Developer para System z, um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | Linguagem de Programação | Níveis de APARs, PTFs ou Serviço Necessários |
---|---|---|---|
5655-V50 | IBM Debug Tool para z/OS V10.1 | COBOL, PL/I, C/C++, assembler e recursos adicionais | todas as manutenções disponíveis |
5655-U27 | IBM Debug Tool para z/OS V9.1 | COBOL, PL/I, C/C++, assembler e recursos adicionais | todas as manutenções disponíveis |
5655-S16 | IBM Debug Tool Utilities and Advanced Functions para z/OS V8.1.0 | COBOL, PL/I, C/C++, assembler e recursos adicionais | todas as manutenções disponíveis |
5655-S17 | IBM Debug Tool para z/OS V8.1.0 | COBOL, PL/I, Assembler e C/C++ | todas as manutenções disponíveis |
O Web site do produto relacionado é:
Começando com a versão 9, o Debug Tool para z/OS e os Utilitários e as Funções Avançadas da Ferramenta de Depuração foram mesclados em uma única oferta.
Para suportar aplicativos com instruções integradas do CICS, um dos seguintes níveis deve ser instalado:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-S97 | IBM CICS Transaction Server para z/OS v 4.1 | Nenhum PTF ou Nível de Serviço necessário |
5697-E93 | IBM CICS Transaction Server para z/OS v 3.2 | UK34221 |
5697-E93 | IBM CICS Transaction Server para z/OS v 3.1 | UK15767, UK15764, UK11782, UK11294, UK12233, UK12521, UK15261, UK15271, UK34221, UK34078 |
O Web site do produto relacionado é:
Para obter a lista completa de especificações sobre requisitos de tempo de execução, consulte a documentação do Enterprise Service Tools no Centro de Informações do IBM Rational Developer para System z em http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/.
Para suportar aplicativos que usam banco de dados IMS e comunicações de dados, um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5635-A02 | IBM IMS v 11.1 | Nenhum PTF ou Nível de Serviço necessário |
5635-A01 | IBM IMS v 10.1 | Nenhum PTF ou Nível de Serviço necessário |
5655-J38 | IBM IMS v 9.1 | Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
Para suportar o DB2, um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5635-DB2 | IBM DB2 para z/OS v 9.1 | Nenhum PTF ou Nível de Serviço necessário |
5625-DB2 | IBM DB2 Universal Database para z/OS v 8.1 | Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
Para controle de origem baseado no Jazz que usa projetos remotos do Developer para System z, o seguinte nível deve ser instalado.
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5724-V82 | Rational Team Concert para System z Server v 2.0 |
FMID HAHA200 - Servidor de Time
FMID HAHB200 - Kit de ferramentas
FMID HAHC200 - Monitor de Tarefa
FMID HAHD200 - Agente BuildForge
|
O Web site do produto relacionado é:
Para suportar a integração do File Manager, um dos seguintes níveis deve ser instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-U29 | IBM File Manager para z/OS v 10.1 |
|
O Web site do produto relacionado é:
Para suportar a integração do Fault Analyzer, os seguintes níveis devem estar instalados no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5655-V51 | IBM Fault Analyzer v 10.1 | Nenhum PTF ou Nível de Serviço necessário |
5655-U28 | IBM Fault Analyzer v 9.1 | Nenhum PTF ou Nível de Serviço necessário |
5655-S15 | IBM Fault Analyzer v 8.1 | Nenhum PTF ou Nível de Serviço necessário |
O Web site do produto relacionado é:
Para usar o SCLM Developer Toolkit, um dos seguintes níveis deve estar instalado no host:
Número do Programa | Nome do Produto | PTFs ou Níveis de Serviço Necessários |
---|---|---|
5695-014 | IBM Library para REXX no zSeries v 1.4 | Nenhum PTF ou Nível de Serviço necessário |
5695-014 | IBM Library para REXX no zSeries Alternate Library v 1.4.0 (FMIDs HWJ9143, JWJ9144) | Nenhum PTF ou Nível de Serviço necessário |
Uma versão do REXX/370 Alternate Library está disponível no Web site do produto:
O IBM Ported Tools para z/OS deve ser instalado (no z/OS UNIX) para utilizar o sftp ou scp para realizar uma implementação segura no SCLM Developer Toolkit.
Uma versão do IBM Ported Tools para z/OS está disponível no Web site do produto:
O Apache Ant deve ser instalado (no z/OS UNIX) para executar construções JAVA/J2EE no SCLM Developer Toolkit.
O Apache Ant é uma ferramenta de construção de software livre, baseada em Java, que você pode transferir por download no Web site do produto:
O CA Endevor® Software Change Manager Release 12 deve ser instalado para o uso da Interface do Developer para System z para CA Endevor® SCM.
CA Endevor® SCM é um produto do CA. O Web site do produto relacionado é:
http://www.ca.com/us/products/product.aspx?ID=259
As publicações a seguir são referenciadas neste documento:
Título da publicação | Número do pedido | Referência | Web site de referência |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Guia do Usuário do Java SDK and Runtime Environment | / | Java 5.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Program Directory for IBM Rational Developer for System z | GI11-8298 | Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Pré-requisitos do Rational Developer para System z | S517-9092 | Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Iniciação Rápida da Configuração do Host do Rational Developer para System z | GI11-9201 | Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Host Planning Guide | GI11-8296 | Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
SCLM Developer Toolkit: Guia do Administrador | SC23-9801 | Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
APPC and WebSphere Developer for System z | SC23-5885 | Whitepaper | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using Data Sets | SC26-7410 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Customização de TSO/E | SA22-7783 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Utilizando os Serviços de Sistemas REXX e z/OS UNIX | SA22-7806 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Resource Definition Guide | SC34-6430 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-6454 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Referência de Linguagem | SC27-1408 | Enterprise COBOL para z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Os Web sites a seguir são referidos neste documento:
Descrição | Web site de referência |
---|---|
Centro de Informações do Developer para System z | http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp |
Suporte do Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/support/ |
Biblioteca do Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Página Inicial do Developer para System z | http://www-306.ibm.com/software/awdtools/rdz/ |
Serviço recomendado para o Developer para System z | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Pedido de aprimoramento para o Developer para System z | https://www.ibm.com/developerworks/support/rational/rfe/ |
Biblioteca do z/OS na Internet | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Centro de Informações do CICSTS | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
Download do Apache Ant | http://ant.apache.org/ |
Documentação do keytool Java | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Página inicial de suporte de CA | https://support.ca.com/ |
As publicações a seguir podem ser úteis para você compreender os problemas de configuração para os componentes do host necessários:
Título da publicação | Número do pedido | Referência | Web site de referência |
---|---|---|---|
ABCs do z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
Guia do Programador de Sistema' para: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
Implementação do TCPIP Volume 1: Funções Base, Conectividade e Roteamento | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation - 2010
Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.
Para pedidos de licenças com relação a informações sobre DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO, AS GARANTIAS IMPLÍCITAS DE NÃO-INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias explícitas ou implícitas em determinadas transações; portanto, esta disposição pode não se aplicar ao Cliente.
Essas informações podem conter imprecisões técnicas ou erros tipográficos. São feitas alterações periódicas nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação a qualquer momento sem aviso prévio.
Referências nestas informações a Web sites que não sejam da IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a estes Web sites. Os materiais contidos nesses Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é de inteira responsabilidade do Cliente.
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.
Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em alguns casos o pagamento de uma taxa.
O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato de Licença de Programa Internacional IBM ou de qualquer outro contrato equivalente.
Quaisquer dados de desempenho contidos aqui foram determinados em ambientes controlados. Portanto, os resultados obtidos em outros ambientes operacionais poderão variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em nível de desenvolvimento e não há garantia de que estas medidas serão as mesmas em sistemas disponíveis em geral. Além disso, algumas medidas podem ter sido estimadas através de extrapolação. Os resultados reais podem ser diferentes. Os usuários deste documento devem verificar os dados aplicáveis para o ambiente específico.
As informações relativas a produtos não-IBM foram obtidas junto aos fornecedores dos respectivos produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos de produtos não-IBM devem ser encaminhadas diretamente a seus fornecedores.
Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aviso prévio e representam apenas metas e objetivos.
Estas informações contêm exemplos de dados e relatórios usados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança a esses nomes e endereços usados por uma empresa comercial real é mera coincidência.
Essas informações contêm programas de exemplos aplicativos na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram completamente testados em todas as condições. Portanto, a IBM não pode garantir ou implicar confiabilidade, manutenção, ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de qualquer tipo. A IBM não será responsabilizada por qualquer dano decorrente do uso dos programas de amostra.
IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corp., registradas em várias jurisdições no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual das marcas registradas da IBM está disponível na Web em www.ibm.com/legal/copytrade.shtml.
Rational é uma marca registrada da International Business Machines Corporation e da Rational Software Corporation nos Estados Unidos e/ou em outros países.
Intel® e Pentium® são marcas registradas da Intel Corporation nos Estados Unidos e/ou em outros países.
Microsoft®, Windows® e o logotipo Windows são marcas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.
Java e todas as marcas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e em outros países.
UNIX é uma marca registrada da The Open Group nos Estados Unidos e/ou em outros países.