Antes de usar estas informações, certifique-se de ler as informações gerais em Avisos sobre a Documentação para o IBM Rational Developer for System z.
Esta edição se aplica ao IBM Rational Developer for System z Versão 9.0.1 (programa número 5724-T07) e a todas as liberações e modificações subsequentes, até que seja indicado de outra forma em novas edições.
Solicite as publicações pelo telefone ou fax. O IBM Software Manufacturing Solutions recebe os pedidos de publicações entre 8h30 e 19h, horário padrão na costa leste dos Estados Unidos. O número de telefone é (800) 879-2755. O número de fax é (800) 445-9269. O fax deve ser enviado para: Publications, 3rd floor.
Você também pode solicitar as publicações por meio de um representante IBM ou da filial da IBM que atende em sua região. As publicações não são guardadas no endereço a seguir.
A IBM agradece pelo seu comentário. Você pode enviar os comentários por correio ao seguinte endereço:
É possível enviar um fax com os seus comentários para: 1-800-227-5088 (Estados Unidos e Canadá)
Ao enviar informações à IBM, você concede à IBM o direito não-exclusivo de utilizar ou distribuir as informações da forma que julgar apropriada, sem incorrer em qualquer obrigação para com o Cliente.
Nota para Usuários do Governo dos Estados Unidos - Uso, duplicação ou divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.
Este documento oferece informações de segundo plano para várias tarefas de configuração do próprio IBM® Rational Developer for System z e outros componentes e produtos do z/OS (como WLM e CICS).
De agora em diante, os seguintes nomes serão usados neste manual:
Este documento faz parte de um conjunto de documentos que descrevem a configuração do host do Developer for System z. Cada um desses documentos tem um público alvo específico. Você não precisa ler todos os documentos para concluir a configuração do Developer for System z.
As informações neste documento aplicam-se a todos os pacotes do IBM Rational Developer for System z Versão 9.0.
Este documento é destinado a programadores de sistema que configuram e ajustam o IBM Rational Developer for System z Versão 9.0.1.
Enquanto as etapas de configuração reais são descritas em outra publicação, esta publicação lista em detalhes vários assuntos relacionados, como ajuste, configuração de segurança, entre outros. Para usar este documento, você deve estar familiarizado com os sistemas host z/OS UNIX System Services e MVS.
Esta seção resume as mudanças no IBM Rational Developer for System z Versão 9.0 Referência de Configuração do Host, S517-9857-06 (atualizado em dezembro de 2013).
Mudanças técnicas e adições ao texto e ilustrações são indicadas por uma linha vertical à esquerda da mudança.
Novas informações:
Este documento contém informações anteriormente apresentadas no IBM Rational Developer for System z Versão 9.0 Referência de Configuração do Host, SC14-7290-04.
Novas informações:
Este documento contém informações apresentadas anteriormente no IBM Rational Developer for System z Versão 8.5.1: Referência de Configuração de Host, S517-9857-03.
Novas informações:
Este documento contém informações anteriormente presentes na Referência de Configuração de Host do IBM Rational Developer for System z Versão 8.5, S517-9857-02.
Novas informações:
Este documento contém informações apresentadas anteriormente no IBM Rational Developer for System z Versão 8.0.3: Referência de Configuração de Host, S517-9857-01.
Novas informações:
Este documento contém informações apresentadas anteriormente no IBM Rational Developer for System z Versão 8.0.1 Referência de Configuração de Host , S517-9857-00.
Novas informações:
Informações removidas:
Esta seção resume as informações apresentadas neste documento.
O host do Developer for System z consiste em vários componentes que interagem para oferecer acesso ao cliente para os serviços e dados do host. Entender o design desses componentes pode ajudá-lo a tomar as decisões corretas de configuração.
O Developer for System z fornece acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. A validação dos pedidos de conexão, o fornecimento de comunicação segura entre o host e a estação de trabalho, e a atividade de autorização e auditoria são aspectos importantes da configuração do produto.
O Developer for System z usa TCP/IP para fornecer acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. Ele também usa TCP/IP para comunicação entre vários componentes e outros produtos.
Ao contrário dos aplicativos tradicionais do z/OS, o Developer for System z não é um aplicativo monolítico que pode ser identificado facilmente para Workload Manager (WLM). O Developer for System z consiste de vários componentes que interagem para fornecer ao cliente acesso para os serviços e dados do host. Alguns destes serviços estão ativos em diferentes espaços de endereço, resultando em diferentes classificações de WLM.
O RSE (Explorador de Sistema Remoto) é o núcleo do Developer for System z. Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon age como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamentos processam as cargas de trabalho do cliente.
Isso torna o RSE um alvo principal para o ajuste da configuração do Developer for System z. Entretanto, a manutenção de centenas de usuários, cada um usando 17 ou mais encadeamentos, uma determinada quantidade de armazenamento e possivelmente um ou mais espaços de endereço exige configuração adequada do Developer for System z e do z/OS.
O z/OS é um sistema operacional altamente customizável, e (algumas vezes pequenas) alterações no sistema podem ter um grande impacto sobre o desempenho geral. Este capítulo destaca algumas das alterações que podem ser feitas para melhorar o desempenho do Developer for System z.
Push-to-client, ou controle de cliente baseado em host, suporta gerenciamento central dos seguintes itens:
Este capítulo contém informações úteis para um administrador do CICS Transaction Server.
Esse capítulo o ajuda a aprimorar o Developer for System z ao gravar as rotinas de saída.
Este capítulo ajuda você a imitar um procedimento de logon do TSO incluindo instruções DD e conjuntos de dados no ambiente do TSO no Developer for System z.
Há situações em que você deseja várias instâncias do Developer for System z ativas no mesmo sistema, por exemplo, durante o teste de um upgrade. Entretanto, alguns recursos, como portas TCP/IP, não podem ser compartilhadas, portanto os padrões nem sempre são aplicáveis. Use as informações neste capítulo para planejar a coexistência de diferentes instâncias do Developer for System z; depois é possível usar este guia de configurações para customizá-las.
Este capítulo é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar durante a configuração do seu Developer for System z, e possui as seções a seguir:
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.
O host do Developer for System z consiste em diversos componentes que interagem para dar ao cliente acesso aos dados e serviços do host. Entender o design desses componentes pode ajudá-lo a tomar as decisões corretas de configuração.
Os seguintes tópicos são abordados neste capítulo:
Figura 1 mostra uma visão geral do layout do Developer for System z em seu sistema host.
A descrição no parágrafo e a lista mostram a função central designada ao RSE. Com algumas exceções, toda a comunicação do cliente passa pelo RSE. Isso é permitido para uma configuração fácil da rede relacionada à segurança, uma vez que apenas um conjunto limitado de portas é usado para a comunicação entre o cliente e o host.
Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon age como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamentos processam as cargas de trabalho do cliente. Com base nos valores definidos no arquivo de configuração rsed.envvars e na quantidade real de conexões do cliente, vários espaços de endereço do conjunto de encadeamento podem ser iniciados pelo daemon.
A Figura 2 mostra uma visualização básica do uso de recursos (processos e armazenamento) pelo RSE.
O RSE é um aplicativo Java™, que significa que ele está ativo no ambiente z/OS UNIX. Isso é permitido para facilitar o porting em diferentes plataformas host e comunicação direta com o cliente do Developer for System z, que é também um aplicativo Java (baseado na estrutura do Eclipse). Portanto, o conhecimento básico de como z/OS UNIX e Java funcionam é muito útil quando você tenta compreender o Developer for System z.
No z/OS UNIX, um programa é executada em um processo, que é identificado por um PID (ID do Processo). Cada programa é ativado em seu próprio processo, portanto invocar outro programa criará um novo processo. O processo que iniciou um processo é referenciado com um PPID (PID Pai), o novo processo é chamado de processo-filho. O processo-filho pode ser executado no mesmo espaço de endereço ou pode ser gerado (criado) em um novo espaço de endereço. Um novo processo que é executado no mesmo espaço de endereço pode ser comparado a executar um comando em TSO, enquanto aquele gerado em um novo espaço de endereço é semelhante a enviar uma tarefa em lote.
Observe que um processo pode ser único ou multiencadeado. Em um aplicativo multiencadeado (como o RSE), os diferentes encadeamentos competem por recursos do sistema como se eles fossem espaços de endereço separados (com menos gasto adicional).
Mapeando essas informações de processo para a amostra RSE na Figura 2, obtivemos o seguinte fluxo:
O RSE é capaz de executar em modo de endereçamento de 31 bits ou 64 bits, resultando em diferentes limites de armazenamento. No modo de 31 bits, o armazenamento disponível está limitado a 2 GB, enquanto que no modo de 64 bits, não há limite, a menos que especificado no SYS1.PARMLIB.
Aplicativos Java, como o RSE, não alocam armazenamento diretamente, mas usam serviços de gerenciamento de memória Java. Esses serviços, como alocação de armazenamento, liberação de armazenamento e coleta de lixo, funcionam dentro dos limites do heap Java. Os tamanhos mínimo e máximo do heap é definido (implicitamente ou explicitamente) durante a inicialização de Java. Ao executar em modo de 64 bits, o Java tentará alocar o heap acima de 2 GB de barramento, liberando espaço abaixo do barramento.
Isso significa que a obtenção da maioria do tamanho de espaço de endereço disponível é um ato de equilíbrio da definição de um tamanho grande de heap, enquanto deixa espaço suficiente para o z/OS armazenar uma quantidade variável de blocos de controle do sistema (dependendo do número de encadeamentos ativos).
Figura 3 mostra uma visão geral básica do proprietário das credenciais de segurança usadas para várias tarefas do Developer for System z.
A propriedade de uma tarefa pode ser dividida em duas seções. As tarefas iniciadas são propriedades do ID do usuário que é designado para a tarefa iniciada em seu software de segurança. Todos as outras tarefas, com os conjuntos de encadeamentos (RSEDx) como exceção, são propriedades do ID de usuário cliente.
Figura 3 mostra as tarefas iniciadas do Developer for System z (JMON e RSED) e tarefas iniciadas de amostra e serviços do sistema com os quais Developer for System z se comunica. O Application Deployment Manager (ADM) fica ativo dentro de uma região CICS. A tag USS REXEC representa o serviço do z/OS UNIX REXEC (ou SSH).
O daemon RSE (RSED) cria um ou mais espaços de endereço do conjunto de encadeamentos (RSEDx) para processar os pedidos dos clientes. Cada conjunto de encadeamentos RSE suporta múltiplos clientes e é propriedade do mesmo usuário como um daemon RSE. Cada cliente possui seus próprios encadeamentos dentro de um conjunto de encadeamentos, e estes encadeamentos são propriedades do ID de usuário cliente.
Dependendo das ações concluídas pelo cliente, um ou mais espaços de endereço adicionais podem ser iniciados, todos propriedades do ID de usuário cliente, para executar uma ação solicitada. Esses espaços de endereço podem ser uma tarefa em lote MVS, uma transação APPC ou um processo-filho z/OS UNIX. Observe que um processo-filho z/OS UNIX está ativo em um inicializador z/OS UNIX (BPXAS) e o processo-filho aparece com uma tarefa iniciada no JES.
A criação destes espaços de endereços é mais frequentemente acionada por um encadeamento do usuário em um conjunto de encadeamentos, diretamente ou usando serviços do sistema como ISPF. Mas o espaço de endereço também poderia ser criado por um terceiro. Por exemplo, o Gerenciador de Arquivos iniciará um novo espaço de endereço para cada conjunto de dados (ou membro) que ele tenha que processar em nome do Developer for System z. z/OS UNIX REXEC ou SSH são envolvidos ao iniciar as construções no z/OS UNIX.
Os espaços de endereços do usuário terminam com a conclusão da tarefa ou quando um cronômetro de inatividade vence. As tarefas iniciadas permanecem ativas. Os espaços de endereços listados em Figura 3 permanecem no sistema tempo suficiente para serem visíveis. No entanto, é recomendável estar ciente que, devido à maneira com que o z/OS UNIX é projetado, há também vários espaços de endereço temporários de curta duração.
Figura 4 mostra uma visão geral esquemática de como o cliente conecta-se ao host usando Developer for System z. Ele também explica brevemente como os PassTickets são usados.
A descrição anterior mostra o design orientado a encadeamento do RSE. Em vez de iniciar um espaço de endereço por usuário, vários usuários são atendidos por um espaço de endereço de um único conjunto de encadeamento. No conjunto de encadeamentos, cada extrator (um serviço específico do usuário) fica ativo em seu próprio encadeamento com o contexto de segurança do usuário designado a ele, garantindo uma configuração segura. Esse design acomoda um grande número de usuários com uso de recursos limitado, mas não significa que cada cliente usará vários encadeamentos (17 ou mais, dependendo das tarefas executadas).
Do ponto de vista da rede, o Developer para System z atua de forma semelhante ao FTP no modo passivo. O cliente se conecta a um ponto focal (daemon RSE) e, em seguida, elimina a conexão e reconecta ao número de porta fornecido pelo ponto focal. A seguinte lógica controla a seleção da porta que é usada na segunda conexão:
O uso de PassTickets para todos os serviços z/OS que requerem a autenticação permite que o Developer for System z chame esses serviços à vontade, sem armazenar a senha ou constantemente solicitá-la ao usuário. O uso de PassTickets para todos os serviços z/OS permite também métodos de autenticação alternativos durante o logon, como senhas únicas e certificados X.509.
O Depurador Integrado é usado para depurar vários aplicativos. A figura 5 mostra uma visão geral esquemática de como um cliente do Developer for System z pode depurar um aplicativo.
O CARMA (Common Access Repository Manager) é usado para acessar um host baseado em Software Configuration Manager (SCM), por exemplo, o CA Endevor® SCM. A Figura 6 mostra uma visão geral esquemática de como um cliente Developer for System z pode acessar qualquer Software Configuration Manager (SCM) baseado em host suportado.
O Developer for System z suporta vários métodos para iniciar um servidor CARMA. Cada método tem vantagens e desvantagens. O Developer for System z também fornece vários Repository Access Managers (RAMs), os quais podem ser divididos em dois grupos, RAMs de produção e RAMs de amostra. Várias combinações de RAMs e métodos de inicialização do servidor estão disponíveis como uma configuração pré-configurada.
Todos os métodos de inicialização do servidor compartilham um arquivo de configuração comum, CRASRV.properties, o qual (junto com outras coisas) especifica qual método de inicialização será usado.
O método "CRASTART" inicia o servidor CARMA como uma subtarefa dentro do RSE. Ele fornece uma configuração bastante flexível utilizando um arquivo de configuração separado, que define alocações de conjuntos de dados, e chamadas de programas necessárias para iniciar um servidor CARMA. Esse método fornece o melhor desempenho e utiliza o mínimo de recursos, mas requer que o módulo CRASTART esteja localizado no LPA.
O RSE chama o módulo de carregamento CRASTART, o qual usa as definições em crastart*.conf para criar um ambiente válido para executar comandos ISPF e TSO em lote. O Developer for System z usa este ambiente para executar o servidor CARMA, CRASERV. O Developer for System z fornece vários arquivos crastart*.conf, cada um deles pré-configurado para um RAM específico.
O método "envio em lote" inicia o servidor CARMA enviando uma tarefa. Esse é o método padrão utilizado nos arquivos de configuração de amostra fornecidos. O benefício desse método é que os logs do CARMA são facilmente acessados na saída de tarefas. Ele também permite o uso de JCL de servidor customizado para cada desenvolvedor, que é mantido pelo próprio desenvolvedor. Entretanto, esse método utiliza um iniciador de JES por desenvolvedor que iniciar um servidor CARMA.
O RSE chama o CLIST CRASUB*, o qual por sua vez envia um JCL embutido para criar um ambiente válido para executar os comandos ISPF e TSO em lote. O Developer for System z usa este ambiente para executar o servidor CARMA, CRASERV. O Developer for System z fornece vários membros CRASUB*, cada um deles pré-configurado para um RAM específico.
Figura 7 mostra uma visão geral esquemática de como o daemon RSE determina qual cliente Developer for System z possui um bloqueio de conjunto de dados.
Com a configuração do servidor único do Developer for System z, em que diversos usuários são designados a um único espaço de endereço de encadeamento, o z/OS perdeu a capacidade de rastrear quem possui um bloqueio em um conjunto de dados ou membro com o comando do operador DISPLAY GRS,RES=(*,dataset*). Os comandos do sistema param no nível de espaço de endereço, que é o conjunto de encadeamento.
Para abordar este problema, o Developer for System z fornece o comando do operador MODIFY rsed APPL=DISPLAY OWNER,DATASET=dataset, conforme descrito em "Comandos de operador" em Guia de Configuração do Host (S517-9094). O comando do operador pode resolver todos os conjuntos de dados e bloqueios de membro feitos por usuários RSE, bem como bloqueios feitos por outros produtos, como ISPF.
Sob circunstâncias normais, um conjunto de dados ou um membro fica bloqueado quando o cliente o abrir no modo de edição, e liberado quando o cliente fechar a sessão de edição.
Determinadas condições de erro podem evitar que esse mecanismo funcione como designado. Nesse caso, o usuário que mantém o bloqueio pode ser cancelado usando o comando do operador modify cancel do RSE, como descrito em "Comandos do operador" no Guia de Configuração do Host (SC23-7658). Os bloqueios do conjunto de dados ativo que pertencem a esse usuário são liberados durante o processo.
Figura 8 mostra uma visão geral dos diretórios do z/OS UNIX usados pelo Developer for System z. A lista a seguir descreve cada diretório tocado pelo Developer for System z, como o local pode ser alterado e que mantém os dados dentro dele.
Os dados em /var/rdz/pushtoclient/ são mantidos por não administradores de sistema, como gerentes de produto, que podem não ter muitos privilégios de atualização no z/OS UNIX. Portanto, é importante entender como o z/OS UNIX configura as permissões de acesso durante a criação de arquivos para assegurar que você tenha uma configuração viável e segura.
Os padrões do UNIX determinam que permissões podem ser configuradas para os três tipos de usuários: proprietário, de grupo e outros. Permissões de leitura, gravação e execução podem ser configuradas para cada tipo individualmente.
O z/OS UNIX configura os UID (user ID) e GID (group ID) para os seguintes valores quando um arquivo é criado:
Cada site pode configurar sua própria máscara padrão de permissões de acesso, mas uma máscara comum concede permissão de leitura e de gravação para o proprietário e permissão de leitura para grupos e outros.
Os dados no /var/rdz/pushtoclient/ são criados usando a máscara de permissões de acesso definida na diretiva file.permission do pushtoclient.properties. O valor padrão concede permissão de leitura e gravação para o proprietário e grupos e permissão de leitura para outros. Todos têm permissão de execução. As permissões de acesso final devem permitir acesso de leitura e execução a todos, e acesso de gravação aos administradores do cliente do Developer for System z que mantêm os dados.
Os dados em /var/rdz/pushtoclient/projects/ são criados sem usar nenhuma máscara de permissão de acesso específica. As permissões de acesso final devem conceder permissão de leitura para todos e permissão de gravação para os gerentes de projeto que mantêm os dados.
Para assegurar que um grupo de gerentes de projeto ou administradores de cliente do Developer for System z possam gerenciar os dados nesses diretórios, seu administrador de segurança pode ter de criar um grupo com um segmento OMVS válido para eles. Esse grupo é preferivelmente o grupo padrão dos IDs de usuário envolvidos. Consulte Security Server RACF Command Language Reference (SA22-7687) para obter mais informações sobre a seguinte amostra de comandos RACF:
ADDGROUP RDZPROJ OMVS(GID(1200))
CONNECT IBMUSER GROUP(RDZPROJ)
ALTUSER IBMUSER DFLTGRP(RDZPROJ)
Consulte a UNIX System Services Command Reference (SA22-7802) para obter mais informações sobre os seguintes comandos de amostra do z/OS UNIX:
ls -lR /var/rdz/pushtoclient/
chown -R IBMUSER /var/rdz/pushtoclient/
chgrp -R RDZPROJ /var/rdz/pushtoclient/
chmod -R 775 /var/rdz/pushtoclient/
No cenário a seguir, todos os gerentes de projeto de desenvolvimento, uma equipe de três, serão incumbidos de desempenhar tarefas de um administrador cliente do Developer for System z.
O administrador de segurança já designou para a equipe um grupo padrão (RDZPROJ) com um ID de grupo exclusivo (1200). Seus IDs de usuário não possuem privilégios especiais (como UID 0) no z/OS UNIX. O administrador de segurança não definiu o perfil FILE.GROUPOWNER.SETGID. Sendo assim, o z/OS UNIX usará o ID de grupo do diretório ao criar novos arquivos. O ID do usuário IBMUSER (com o UID 0 e o grupo padrão SYS1) foi usado pelo programador de sistemas para criar o diretório /var/rdz/pushtoclient.
# chmod 775 /var/rdz/pushtoclient
# ls -ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER SYS1
/var/rdz/pushtoclient
# chgrp RDZPROJ /var/rdz/pushtoclient
# ls -ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER RDZPROJ
/var/rdz/pushtoclient
Isso conclui a configuração necessária para limitar as permissões de gravação de /var/rdz/pushtoclient ao programador de sistemas (IBMUSER) e aos gerentes de projeto (RDZPROJ).
O Developer for System z fornece acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. A validação dos pedidos de conexão, o fornecimento de comunicação segura entre o host e a estação de trabalho, e a atividade de autorização e auditoria são aspectos importantes da configuração do produto.
Os mecanismos de segurança usados pelos servidores e serviços do Developer for System z dependem dos conjuntos de dados e sistemas de arquivos no qual ele reside sejam seguros. Isto indica que apenas administradores confiáveis de sistema podem ser capazes de atualizar as bibliotecas de programa e os arquivos de configuração.
Os seguintes tópicos são abordados neste capítulo:
Consulte Capítulo 1. Entendendo o Developer for System z para saber sobre conceitos de design do Developer for System z básicos.
O Developer for System z suporta diversas formas de autenticar um ID do usuário fornecido por um cliente mediante a conexã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.
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:
A autenticação do cliente é realizada pelo daemon do RSE (ou REXEC/SSH) como parte do pedido de conexão do cliente. Depois de o usuário ser autenticado, os PassTickets gerados automaticamente são usados para todas as solicitações de autenticação futuras, incluindo o logon automático no Debug Manager.
Para que o Debug Manager valide o ID do usuário e o PassTicket apresentados pelo RSE, o Debug Manager deve ter permissão para avaliar o PassTicket. Isso implica que o módulo de carregamento AQEZPCM, por padrão localizado na biblioteca de carregamento FEK.SFEKAUTH, deve ser autorizado pelo APF.
Diferentes níveis de segurança de comunicação são suportados por RSE, o qual controla a comunicação entre o cliente e a maioria dos serviços do Developer for System z:
Alguns serviços Developer for System z opcionais usam um caminho de comunicação externo (cliente-host) separado:
O Developer for System z conta com produtos de terceiros, tal como o servidor TN3270, para fornecer alguns serviços. Consulte a documentação do produto relacionada para obter opções de segurança de conexão.
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 do Developer for System z externos que passam pelo RSE podem ser criptografados usando Secure Socket Layer (SSL) ou Segurança da Camada de Transporte (TLS). O uso de comunicação criptografada é controlado pelas configurações no arquivo de configuração ssl.properties, conforme descrito em Comunicação Criptografada de SSL/TLS. A variável DSTORE_SSL_ALGORITHM na diretiva _RSE_JAVAOPTS de rsed.envvars permite escolher entre SSL e seu TLS sucessor como o método de criptografia, conforme documentado em "Definindo Parâmetros de Inicialização Java Extras com _RSE_JAVAOPTS" no Guia de Configuração de Host (SC23-7658).
O Depurador Integrado Engine no cliente se conecta ao gerenciador de depuração no host. O uso de SSL ou TLS é controlado por uma política Application Transparent TLS (AT-TLS).
O Emulador de Conexão do Host no cliente se conecta a um servidor TN3270 no host. O uso de SSL ou TLS é controlado por TN3270, conforme documentado no Guia de Configurações de IP do Servidor de Comunicação (SC31-8775).
Ações remotas (baseadas em host) em subprojetos do z/OS UNIX usam um servidor REXEC ou SSH no host. A comunicação SSH é sempre criptografada usando SSL.
O cliente Application Deployment Manager usa o Serviço da Web CICS TS ou a interface RESTful para chamar os serviços de host do Application Deployment Manager. O uso de SSL é controlado pelo CICS TS, conforme documentado no RACF Security Guide for CICS TS .
O Developer for System z suporta a verificação de Port Of Entry (POE), que permite que o host acesse apenas os endereços TCP/IP confiáveis. O uso de POE é controlado pela definição de perfis específicos em seu software de segurança e a diretiva enable.port.of.entry em rsed.envvars, conforme descrito em Verificação de Port Of Entry (POE).
Observe que a ativação de POE afetará outros aplicativos TCPIP que suportam a verificação de POE, como o INETD.
Após o logon, os PassTickets são usados para estabelecer segurança de encadeamento no servidor RSE. Esse recurso não pode ser desativado. Os PassTickets são senhas geradas pelo sistema com um lifespan de aproximadamente 10 minutos. Os PassTickets gerados baseiam-se no algoritmo de criptografia DES, no ID do usuário, no ID do aplicativo, em um registro de data e hora e em uma chave secreta. Essa chave secreta é um número de 64 bits (16 caracteres hexadecimais) que deve ser definido para seu software de segurança. Para segurança adicional, o software de segurança do z/OS trata os PassTickets por padrão como senhas de uso único.
Para ajudá-lo a compreender o uso de PassTicket, a seguir há uma breve descrição do processo de segurança do RSE:
A senha real do cliente não é mais necessária após a autenticação inicial, pois os produtos de segurança compatíveis com SAF podem avaliar as senhas PassTickets e comuns. O servidor RSE gera e utiliza um PassTicket cada vez que uma senha é solicitada, resultando em uma senha válida (temporária) para o cliente.
O uso de PassTickets permite que o RSE configure um ambiente de segurança específico do usuário à vontade, sem a necessidade de armazenar todos os IDs de usuário e senhas em uma tabela, o que poderia ser comprometido. Ele também permite métodos de autenticação de cliente que não usam senhas reutilizáveis, como certificados X.509.
Os perfis de segurança nas classesAPPL e PTKTDATA são necessários para que se possa usar os PassTickets. Esses perfis são específicos do aplicativo e, portanto, não afetam a configuração atual do sistema.
Os PassTickets sendo específicos do aplicativo implicam em o RSE e o JES Job Monitor usarem o mesmo ID de aplicativo (APPLID). Por padrão, ambos os servidores usam FEKAPPL como APPLID, mas isso pode ser alterado pela diretiva APPLID em rsed.envvars para o RSE e em FEJJCNFG para o JES Job Monitor.
Não é recomendável usar OMVSAPPL como ID do aplicativo porque ele abrirá a chave secreta para a maioria dos aplicativos do z/OS UNIX. Também não é recomendável usar o ID do aplicativo padrão MVS, que é MVS seguido pelo ID do sistema SMF, porque isto abrirá uma chave secreta para a maioria dos aplicativos MVS (incluindo as tarefa em lote do usuário).
A menor unidade de um registro de data e hora de PassTicket é de 1 segundo. Isso significa que todos os PassTickets gerados em um único segundo pelo mesmo aplicativo para o mesmo ID de usuário serão idênticos. Isso, combinado com o PassTickets de manipulação de software de segurança z/OS, causa um problema para o Developer for System z durante o logon, pois diversos PassTickets serão necessários em um segundo. Portanto, o Developer for System z requer a configuração de um sinalizador nas definições do PassTicket que permitem que os PassTickets gerados sejam reutilizados.
Atenção: O pedido de conexão do cliente
falhará se os PassTickets não estiverem configurados corretamente. |
O Developer for System z suporta a criação de log de auditoria das ações que são gerenciadas pelo daemon RSE. Os logs de auditoria são armazenados como arquivos de texto no diretório de log do daemon, utilizando o formato CSV (Comma Separated Value).
Várias opções no rsed.envvars influenciam a função de auditoria, como documentado em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
O comando do operador modify switch pode ser usado para alternar manualmente para um novo arquivo de log de auditoria, conforme documentado em "Comandos do operador" no Guia de Configuração do Host (SC23-7658).
Uma mensagem de aviso é enviada para o console quando o sistema de arquivos que contém os arquivos de log de auditoria estiver em execução com pouco espaço livre. Essa mensagem do console (FEK103E) é repetida regularmente até que o problema de pouco espaço seja resolvido. Consulte "Mensagens do console" no Guia de Configuração do Host (SC23-7658) para obter uma lista de mensagens do console geradas pelo RSE.
Um novo arquivo de log de auditoria é iniciado após um momento predeterminado ou quando o comando do operador modify switch é emitido. O arquivo de log antigo é salvo como audit.log.yyyymmdd.hhmmss, em que yyyymmdd.hhmmss é a data/registro de data e hora no qual o log foi fechado. A data/registro de data e hora do sistema designados ao arquivo indicam a criação do arquivo de log. A combinação das duas datas mostra o período de tempo abrangido por esse arquivo de log de auditoria.
As diretivas audit.action* em rsed.envvars permitem que você especifique uma saída de usuário (shell script do z/OS UNIX, z/OS UNIX REXX ou programa do z/OS UNIX) que será chamada pelo RSE quando um log de auditoria for fechado. Essa saída de usuário pode então processar os dados contidos no log de auditoria.
Os arquivos de log de auditoria terão a máscara de bit de permissão (-rw-r-----), se não for alterada pela diretiva audit.log.mode em rsed.envvars. Isso significa que o proprietário (UID do z/OS UNIX do daemon RSE) tem acesso de leitura e gravação, enquanto o grupo do proprietário (padrão) tem acesso de leitura. Todas as outras tentativas de acesso serão negadas, a menos que isso seja feito por um superusuário (UID 0) ou alguém com permissão suficiente para o perfil SUPERUSER.FILESYS na classe de segurança UNIXPRIV.
As seguintes ações são registradas:
Cada ação registrada é armazenada (com uma data/registro de data e hora) utilizando o formato Comma Separated Value (CSV), que pode ser lido por uma ferramenta de automação ou de análise de dados. Por exemplo:
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name[,returncode]
[,additional_information]]
Estatísticas de conjunto de dados e de membro também são registradas quando o arquivo é aberto. Elas são anexadas à linha que documenta a conclusão da ação READ e os campos são delimitados com %n. Por exemplo:
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name,returncode,create%nmodify%n...
Os seguintes atributos são registrados, na ordem listada:
O Developer for System z permite acesso do cliente ao spool do JES através do JES Job Monitor. O servidor fornece limitações de acesso básico, que podem ser estendidas com os recursos de proteção padrão do arquivo de spool de seu produto de segurança. As ações do operador (Suspender, Liberar, Cancelar e Limpar) nos arquivos de spool são feitas através do console EMCS, para o qual é necessário configurar permissões condicionais.
O JES Job Monitor não fornece aos usuários do Developer for System z acesso total de operador ao spool do JES. Apenas os comandos Suspender, Liberar, Cancelar e Limpar estão disponíveis e, por padrão, somente para arquivos em spool que pertencem ao usuário. Os comandos são emitidos selecionando a opção apropriada na estrutura de menus do cliente (sem prompt de comandos). O escopo dos comandos pode ser ampliado, utilizando perfis de segurança para definir para quais tarefas os comandos estão disponíveis.
Semelhante ao caractere de ação SDSF SJ, o JES Job Monitor também suporta o comando Mostrar JCL para recuperar a JCL que criou a saída de tarefa selecionada e o mostra em uma janela de editor. O JES Job Monitor recupera a JCL do JES, tornando-o uma função útil para situações em que o membro JCL original não é facilmente localizado.
Ações | JES2 | JES3 |
---|---|---|
Suspender | $Hx(jobid)
with x = {J, S or T} |
*F,J=jobid,H |
Liberar | $Ax(jobid)
with x = {J, S or T} |
*F,J=jobid,R |
Cancelar | $Cx(jobid)
with x = {J, S or T} |
*F,J=jobid,C |
Limpar | $Cx(jobid),P
with x = {J, S or T} |
*F,J=jobid,C |
Mostrar JCL | não-aplicável | não-aplicável |
Os comandos JES disponíveis listados na Tabela 1 são limitados por padrão às tarefas que pertencem ao usuário. Isto pode ser alterado com a diretiva LIMIT_COMMANDS, conforme documentado em "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658).
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 |
---|---|---|
Suspender | nodeid.userid.jobname.jobid | ALTER |
Liberar | nodeid.userid.jobname.jobid | ALTER |
Cancelar | nodeid.userid.jobname.jobid | ALTER |
Limpar | nodeid.userid.jobname.jobid | ALTER |
Mostrar JCL | nodeid.userid.jobname.jobid.JCL | READ |
Use as seguintes substituições na tabela anterior:
nodeid | O ID do nó NJE do subsistema JES de destino |
userid | ID do usuário local do proprietário da tarefa |
jobname | Nome da tarefa |
jobid | ID da tarefa do JES |
Se a classe JESSPOOL não estiver ativa, existe um comportamento diferente para o valor LIMITED e NOLIMIT de LIMIT_COMMANDS, conforme descrito no "Tabela de matriz de permissão do comando LIMIT_COMMANDS" em "FEJJCNFG, arquivo de Configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658). O comportamento é idêntico quando JESSPOOL está ativo, já que a classe, por padrão, nega a permissão se um perfil não estiver definido.
A segunda fase da segurança de comando em spool do JES, depois de especificar os destinos permitidos, inclui as permissões necessárias para realmente executar o comando do operador. Essa autorização de execução é aplicada pelas verificações de segurança do z/OS e do JES.
Observe que Mostrar JCL não é um comando do operador, como os outros comandos JES Job Monitor (Suspender, Liberar, Cancelar e Limpar), de modo que as limitações na próxima lista não se aplicam porque não há nenhuma verificação de segurança adicional.
O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário através de um console MCS (EMCS) estendido, cujo nome é controlado com o diretiva CONSOLE_NAME, conforme documentado em "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658).
O JES Job Monitor permite que você defina quanta autoridade é concedida ao console EMCS com a diretiva LIMIT_CONSOLE, conforme o documento no "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (S517-9094).
LIMIT_CONSOLE | Perfil ativo na classe OPERCMDS | Não há perfil ativo na classe OPERCMDS |
---|---|---|
LIMITED (padrão) | Permitido, se houver permissão do perfil de segurança | Não permitido |
NOLIMIT | Permitido, se houver permissão do perfil de segurança | Permitido |
Essa configuração permite que o administrador de segurança defina permissões granulares de execução de comandos usando as classes OPERCMDS e CONSOLE.
Supondo que a identidade do servidor JES Job Monitor, criando um console JMON a partir de uma sessão do TSO, seja impedida por seu software de segurança. Embora o console possa ser criado, o ponto de entrada é diferente (JES Job Monitor versus TSO). Os comandos JES emitidos a partir desse console falharão na verificação de segurança se a segurança estiver configurada conforme documentado nesta publicação e o usuário não tiver autoridade para comandos JES por outros meios.
Observe que o JES Job Monitor não poderá criar o console quando um comando tiver que ser executado se o nome do console já estiver sendo usado. Para evitar isso, o programador de sistema pode configurar a diretiva GEN_CONSOLE_NAME=ON no arquivo de configuração do JES Job Monitor ou o administrador de segurança pode definir perfis de segurança para que os usuários do TSO parem de criar um console. Os comandos de amostra do RACF a seguir impedem que qualquer indivíduo (exceto aqueles permitidos) crie um console TSO ou SDSF:
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" no Guia de Configuração do Host (SC23-7658).
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) usando RSE pode ser criptografada usando SSL (Secure Socket Layer) ou Transport Layer Security (TLS). Esse recurso é desativado por padrão e é controlado pelas configurações no ssl.properties. Consulte "(Opcional) ssl.properties, criptografia RSE SSL" no Guia de Configuração do Host (SC23-7658).
O daemon RSE e o servidor RSE suportam diferentes mecanismos para armazenar certificados devido a diferenças de arquitetura entre eles. Isso implica que as definições e os certificados SSL são necessários para o daemon RSE e para o servidor RSE. Um certificado compartilhado poderá ser usado se o daemon RSE e o servidor RSE usarem o mesmo método de gerenciamento de certificado.
Armazenamento de certificado | Criado e gerenciado por | Daemon RSE | Servidor RSE |
---|---|---|---|
conjunto de chaves | produto de segurança compatível com SAF | suportados | suportados |
banco de dados de chaves | gskkyman do z/OS UNIX | suportados | / |
keystore | keytool do Java | / | suportados |
Os conjuntos de chaves compatíveis com SAF podem armazenar a chave privada do certificado no banco de dados de segurança ou usando ICSF (Integrated Cryptographic Service Facility), a interface para o hardware de criptografia do System z.
ICSF é recomendado para o armazenamento de chaves privadas associadas a certificados digitais, porque é uma solução mais segura do que o gerenciamento de chaves privadas não-ICSF. O ICSF garante que as chaves privadas sejam criptografadas na chave mestra do ICSF e que o acesso a elas seja controlado por recursos gerais das classes de segurança CSFKEYS e CSFSERV. Além disso, o desempenho operacional é aprimorado, pois o ICSF utiliza o Coprocessador Criptográfico de hardware. Consulte o Cryptographic Services ICSF Administrator's Guide (SA22-7521) para obter mais detalhes sobre o ICSF e sobre como controlar quem pode usar chaves e serviços criptográficos.
O daemon RSE utiliza funções SSL do Sistema para gerenciar as comunicações criptografadas por SSL. Isso implica que SYS1.SIEALNKE deve ser controlado pelo programa pelo software de segurança e estar disponível para o RSE por meio de LINKLIST ou da diretiva STEPLIB em rsed.envvars.
O ID do usuário do RSE (stcrse nos comandos de amostra a seguir) precisa de autorização para acessar esse conjunto de chaves e os certificados relacionados quando os conjuntos de chaves compatíveis com SAF são usados para o daemon RSE ou o servidor RSE.
A variável DSTORE_SSL_ALGORITHM na diretiva _RSE_JAVAOPTS de rsed.envvars permite escolher entre SSL e seu TLS sucessor como método de criptografia, conforme documentado em "Definindo Parâmetros de Inicialização Java Extras com _RSE_JAVAOPTS" no Guia de Configuração de Host (SC23-7658).
Consulte Capítulo 13. Configurando o SSL e a Autenticação X.509 para obter mais detalhes sobre como ativar o SSL para Developer for System z.
A comunicação externa (cliente-host) com o Debug Manager opcional também pode ser criptografada usando SSL ou TLS. Para fazer a criptografia dessa maneira, crie uma política AT-TLS para a porta usada pelo Debug Manager para comunicação externa, por padrão 5335. Uma política de amostra é fornecida em Figura 9. Consulte Communications Server IP Configuration Guide (SC31-8775) para obter detalhes sobre a configuração AT-TLS (Application Transparent TLS).
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
}
TTLSGroupAction grp_Production
{
TTLSEnabled On
Trace 2
}
O daemon RSE suporta que os próprios usuários se autentiquem com um certificado X.509. Usar a comunicação criptografada SSL é um pré-requisito para essa função, uma vez que é uma extensão para a autenticação de host com um certificado usado no SSL.
O daemon RSE inicia o processo de autenticação de cliente pela validação do certificado de cliente. Alguns aspectos chave que são verificados são as datas de validade do certificado e a fidelidade da Autoridade de Certificação (CA) usada para assinar o certificado. Opcionalmente, também é possível consultar uma Lista de Revogação de Certificado (CRL) (terceiros).
Depois que o daemon RSE valida o certificado, ele é processado para autenticação. O certificado é transmitido a seu produto de segurança para autenticação, a menos que a diretiva rsed.envvars enable.certificate.mapping esteja configurada como false, quando o daemon RSE fará a autenticação.
Se bem-sucedido, o processo de autenticação determinará o ID do usuário a ser usado para esta sessão, que é, então, testado pelo daemon do RSE para assegurar que seja útil no sistema host onde o daemon do RSE está em execução.
A última verificação (que é feita para cada mecanismo de autenticação, não apenas certificados X.509) verifica se o ID do usuário tem permissão para usar o Developer for System z.
Se você estiver familiarizado com as classificações de segurança do SSL usadas por TCP/IP, a combinação dessas etapas de validação corresponderão às especificações de "Autenticação de Cliente Nível 3" (a mais alta disponível).
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 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 mais informações sobre certificados X.509, como são gerenciados pelo RACF e como definir filtros de nome de certificado. Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter informações adicionais sobre o comando RACDCERT.
Developer for System z podem fazer autenticação de certificado X.509 básica sem contar com seu produto de segurança. A autenticação realizada pelo daemon do RSE requer que um ID do usuário e nome do host sejam definidos em uma extensão de certificado e está ativa somente se a diretiva enable.certificate.mapping em rsed.envvars estiver configurada para FALSE.
Essa função deverá ser usada se o seu produto de segurança não suportar autenticação de um usuário com base em um certificado X.509 ou se o seu certificado for causar falha no(s) teste(s) feito(s) por seu produto de segurança (por exemplo, o certificado possui um identificador falho para a extensão HostIdMappings e não há nenhum filtro ou definição em DIGTCERT).
O cliente consultará o usuário pelo identificador da extensão (OID) a ser usado, que é, por padrão, o OID de HostIdMappings, {1 3 18 0 2 18 1}.
O daemon do RSE extrairá o ID do usuário e o nome do host do mesmo usando o formato da extensão HostIdMappings. Esse formato está descrito em Autenticação por Software de Segurança.
O par ID do usuário e nome do host é válido se todas estas condições forem verdadeiras:
Atenção: Depende do administrador de segurança
assegurar que todas as CAs conhecidas do daemon RSE sejam altamente confiáveis, já que
o daemon RSE não pode verificar se aquele que assinou o certificado de cliente
é altamente confiável ou apenas confiável. Consulte Validação da Autoridade de Certificação (CA) para obter informações adicionais sobre certificados de
CA acessíveis. |
O Developer for System z suporta a verificação de Port Of Entry (POE), que permite que o host acesse apenas os endereços TCP/IP confiáveis. Esse recurso fica desativado por padrão e requer a definição do perfil de segurança BPX.POE, conforme mostrado nos seguintes comandos RACF de amostra:
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.
Clientes do Developer for System z versão 8.5.1 e mais recente podem verificar a autorização de acesso aos perfis de segurança do SAF, e baseado no resultado, ativar ou desativar a função relacionada para o usuário.
Developer for System z verifica permissões de acesso aos perfis listados em Tabela 7 para determinar quais opções devem ser ativadas ou desativadas para o usuário.
Perfil FACILITY | Compri
mento fixo |
Acesso Necessário | Resultado |
---|---|---|---|
FEK.USR.OFF.REMOTECOPY.MVS.sysname | 27 | READ | O cliente desativa funções de copiar e relacionadas para conjuntos de dados do MVS |
O valor sysname corresponde ao nome do sistema de destino.
A coluna "Comprimento fixo" documenta o comprimento da parte fixa do perfil de segurança relacionado.
Por padrão, o Developer for System z espera os perfis FEK.* estarem na classe de segurança FACILITY. Observe que os perfis na classe FACILITY estão limitados a 39 caracteres. Se a soma do comprimento da parte do perfil fixo (FEK.USR.<key>) e o comprimento da parte do perfil específica do site (sysname) exceder este número, é possível posicionar os perfis em outra classe e instrui o Developer for System z a usar esta classe no lugar. Para fazer isso, remova o comentário da linha _RSE_FEK_SAF_CLASS em rsed.envvars e forneça o nome de classe desejado.
As seguintes definições de segurança de amostra permitem a ação REMOTECOPY.MVS para todos os usuários no CDFMVS08, exceto aqueles no grupo RESTRICT:
RDEFINE FACILITY (FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT CONTROL')
PERMIT FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08 CLASS(FACILITY) -
ID(RESTRICT) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Quando os usuários tiverem acesso de LEITURA ao perfil FEK.USR.OFF.REMOTECOPY.MVS.sysname, então seus clientes do Developer for System z versão 8.5.1 e mais recente desativarão as ações arrastar, copiar, salvar como e trabalhar offline para os conjuntos de dados MVS. O resultado é que os usuários podem acessar os conjuntos de dados nesse sistema, mas os usuários não podem criar uma cópia local de um conjunto de dados em sua estação de trabalho. Isso ajuda a evitar a exposição de informações confidenciais se a estação de trabalho local for perdida ou roubada.
Os clientes do Developer for System z versão 8.0.1 e superior podem extrair arquivos de configuração de cliente e informações de upgrade do host quando se conectam, assegurando que todos os clientes tenham configurações comuns e estejam atualizados.
Desde a versão 8.0.3, o administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar as necessidades de diferentes grupos de desenvolvedores. Isso permite que os usuários recebam uma configuração customizada, com base em critérios como associação de um grupo LDAP ou permissão para um perfil de segurança.
Ao usar as definições do banco de dados de segurança como mecanismo de seleção (o valor SAF é especificado para diretivas em pushtoclient.properties), o Developer for System z verifica as permissões de acesso aos perfis listados na Tabela 8 para determinar a quais grupos de desenvolvedores o usuário pertence, e se um usuário tem permissão para rejeitar atualizações.
Perfil FACILITY | Compri
mento fixo |
Acesso Neces
sário |
Resultado |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. sysname.devgroup |
23 | READ | O cliente aceita atualizações de configuração para o grupo especificado |
FEK.PTC.PRODUCT. ENABLED.sysname.devgroup |
24 | READ | O cliente aceita atualizações de produto para o grupo especificado |
FEK.PTC.REJECT.CONFIG. UPDATES.sysname |
30 | READ | O usuário pode rejeitar atualizações de configuração |
FEK.PTC.REJECT.PRODUCT. UPDATES.sysname |
31 | READ | O usuário pode rejeitar atualizações de produto |
O valor devgroup corresponde ao nome do grupo designado a um grupo específico de desenvolvedores. Observe que o nome do grupo é visível nos clientes do Developer for System z.
O valor sysname corresponde ao nome do sistema de destino.
A coluna "Comprimento fixo" documenta o comprimento da parte fixa do perfil de segurança relacionado.
Por padrão, o Developer for System z espera os perfis FEK.* estarem na classe de segurança FACILITY. Observe que os perfis na classe FACILITY estão limitados a 39 caracteres. Se a soma do comprimento da parte de perfil fixo (FEK.PTC.<key>) e o comprimento da parte de perfil específico do site (sysname ou sysname.devgroup)exceder esse número, você poderá colocar os perfis em outra classe e instruir o Developer for System z a usar essa classe no lugar. Para fazer isso, remova o comentário da linha _RSE_FEK_SAF_CLASS em rsed.envvars e forneça o nome de classe desejado.
Observe que o administrador de cliente deve estar na lista de acesso dos perfis FEK.PTC.*.ENABLED.* para definir e gerenciar os metadados de push-to-client relacionados. Isso significa que os perfis devem ser definidos com (pelo menos) o administrador de cliente na lista de acesso para que o push-to-client com suporte de grupo possa ser implementado.
Consulte "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094) para obter mais informações sobre como ativar o suporte a diversos grupos. Consulte Capítulo 7. Considerações de Push-to-client para obter mais informações sobre conceitos e implementação de push-to-client.
O Depurador Integrado opcional é capaz de depurar transações CICS carregadas na memória de leitura. Quando usado para depurar uma transação no estado de problema (não autorizado), o Depurador Integrado validará se o usuário que possui a sessão de depuração tem permissão para fazer isso.
O Developer for System z verifica o acesso aos perfis listados em Tabela 9 para determinar quais permissões de depuração foram concedidas.
Perfil FACILITY | Acesso Necessário | Resultado |
---|---|---|
AQE.AUTHDEBUG.WRITEBUFFER | UPDATE | O usuário está apto a depurar transações CICS somente leitura |
As definições de segurança de amostra a seguir permitem a ação AUTHDEBUG.WRITEBUFFER para todos os usuários no grupo RDZDEBUG:
RDEFINE FACILITY (AQE.AUTHDEBUG.WRITEBUFFER) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - DEBUG CICS READ-ONLY')
PERMIT AQE.AUTHDEBUG.WRITEBUFFER CLASS(FACILITY) -
ID(RDZDEBUG) ACCESS(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH
O Depurador Integrado opcional é capaz de depurar transações CICS. Consulte Depuração de Transação do CICS para obter mais detalhes.
O Developer for System z permite, através do Application Deployment Manager, que administradores do CICS controlem quais definições de recurso do CICS podem ser editadas pelo desenvolvedor, seus valores-padrão e a exibição de uma definição de recurso do CICS por meio de um servidor CICS Resource Definition (CRD). Consulte Capítulo 8. considerações CICSTS para obter informações adicionais sobre as definições de segurança necessárias do CICS TS.
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 for System z fornece várias transações que são usadas pelo servidor CRD durante a definição e a consulta de recursos do CICS. Quando a transação é conectada, a verificação de segurança de recurso do CICS, se ativada, garante que o ID do usuário esteja autorizado para executar o ID de transação.
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 .
A primeira vez que um espaço de endereço instrui o RACF a acessar uma classe de recurso que não é RACLISTed (armazenada na memória), como a classe DATASET, o RACF recuperará e armazenará todos os perfis genéricos no espaço de endereço do usuário, em uma lista conhecida como GATE (Generic Anchor Table Entry). Até o z/OS 1.12, RACF mantém quatro âncoras genéricas para cada espaço de endereço e quatro para cada MVS TCB que tem seu próprio ACEE. Quando todos os quatro forem usados, RACF substituirá o menos recentemente mencionado quando um novo entrar.
Se seus usuários acessam frequentemente mais de quatro qualificadores de alto nível de conjunto de dados, os conjuntos de encadeamentos RSE (que atendem a diversos usuários usando encadeamentos com ACEEs específicos ao usuário) poderão passar pela lixeira GATE pois RACF tem de rotear novas entradas por meio dos slots de âncora disponíveis.
Em z/OS 1.12, RACF introduziu a opção GENERICANCHOR do comando SET, que permite aumentar o tamanho da tabela. Isso pode ser configurado em todo o sistema para cada nome de tarefa.
O Developer for System z usa os serviços kernel do z/OS UNIX, como pthread_security_np() e __passwd(), que usam o serviço de segurança InitACEE, resultando em blocos de controle de segurança "ACEE gerenciado". Um ACEE (Elemento de Ambiente do Acessador) gerenciado é armazenado em cache pelo produto de segurança, e o produto de segurança ignorará determinadas mudanças (como mudanças de senha fora do Developer for System z) até que o cache atinja o tempo limite. (O esgotamento do tempo limite pode levar vários minutos.)
Atualize o cache do ACEE gerenciado após as mudanças de segurança para garantir que os novos dados sejam usados pelo Developer for System z.
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 for System z cujas diretivas impactam a segurança e a configuração de auditoria. Com base nas informações deste capítulo, o administrador de segurança e o programador de sistemas podem decidir quais devem ser as configurações para as diretivas a seguir.
Definir em relação a quais ações as tarefas podem ser realizadas (excluindo navegação e envio). Para obter mais informações, consulte Ações nas Tarefas - Limitações de Destino.
Defina o nível de autoridade do console EMCS usado para executar as ações. Para obter mais informações, consulte Ações nas Tarefas - Limitações de Destino.
Definir quais arquivos de spool podem ser navegados. Para obter mais informações, consulte Acesso aos Arquivos de Spool.
Defina se o JES Job Monitor pode ser acessado fora do sistema z/OS. Para obter mais informações, consulte a seção Arquivo de configuração FEJJCNFG, JES Job Monitor no capítulo Customização básica do Guia de Configuração de Host (S517-9094).
ID do aplicativo usado para criação/validação do PassTicket. Para obter informações adicionais, consulte Usando os PassTickets.
Perfis FEK.** de participação da classe de segurança. Para obter mais informações, consulte Grupos de Desenvolvedores de Push-to-client e Alterando Funções de Cliente.
Nega aos usuários o salvamento de sua senha do host no cliente. Para obter informações adicionais, consulte "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
Cronômetro para desconectar clientes inativos. Para obter informações adicionais, consulte "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
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).
Selecione SSL ou TLS como o método de criptografia de comunicação. Para obter informações adicionais, consulte Comunicação Criptografada de SSL/TLS.
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.
GSK_LDAP_SERVER=*
GSK_LDAP_PORT={389 | *}
GSK_LDAP_USER=*
GSK_LDAP_PASSWORD=*
Verificações de segurança adicional para autenticação do X.509. Para obter informações adicionais, consulte (Opcional) Consulte uma Certificate Revocation List (CRL).
Local dos arquivos de log de auditoria. Para obter informações adicionais, consulte Criação de Log de Auditoria.
Máscara de permissões de acesso dos arquivos de log de auditoria. Para obter informações adicionais, consulte Criação de Log de Auditoria.
(_RSE_JAVAOPTS) -Daudit.action.id=<userid>
Saída de usuário baseada em z/OS UNIX que processa logs 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 de SSL/TLS.
Nome do certificado do daemon RSE. Para obter informações adicionais, consulte Comunicação Criptografada de SSL/TLS.
Local do certificado do servidor RSE. Para obter informações adicionais, consulte Comunicação Criptografada de SSL/TLS.
Nome do certificado do servidor RSE. Para obter informações adicionais, consulte Comunicação Criptografada de SSL/TLS.
Tipo de armazenamento de chaves usado (armazenamento de chaves Java ou conjunto de chaves SAF). Para obter informações adicionais, consulte Comunicação Criptografada de SSL/TLS.
reject.config.updates={true | false | SAF | LDAP}
Controle baseado em host de arquivos de configuração do cliente do Developer for System z. Para obter informações adicionais, consulte Capítulo 7. Considerações de Push-to-client.
reject.product.updates={true | false | SAF | LDAP}
Controle baseado em host de atualizações do produto do cliente do Developer for System z. Para obter informações adicionais, consulte Capítulo 7. Considerações de Push-to-client.
Customize e envie o membro de amostra FEKRACF, que tem comandos RACF e z/OS UNIX de amostra para criar as definições de segurança básicas para o Developer for System z.
FEKRACF está localizado em FEK.#CUST.JCL, a menos que tenha especificado um local quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de Customização" no Guia de Configuração do Host do IBM Rational Developer for System z para obter mais detalhes.
Consulte RACF Command Language Reference (SA22-7687), para obter mais informações sobre comandos RACF.
As seções a seguir descrevem as etapas necessárias, configuração opcional e possíveis alternativas.
Para concluir a configuração de segurança, o administrador de segurança deve conhecer os valores que estão listados em Tabela 10. Esses valores foram definidos durante as etapas anteriores da instalação e da customização do Developer for System z.
Descrição |
|
Valor |
---|---|---|
Developer for System z qualificador de alto nível do produto |
|
|
Developer for System z qualificador de alto nível de customização |
|
|
dNome da Tarefa Iniciada pelo Depurador Integrado |
|
|
Nome da tarefa iniciada do JES Job Monitor |
|
|
Nome da tarefa iniciada do daemon RSE |
|
|
ID do aplicativo |
|
A lista a seguir é uma visão geral das ações que são necessárias para concluir a configuração de segurança básica do Developer for System z. Conforme documentado nas seções a seguir, métodos diferentes podem ser usados para preencher esses requisitos, dependendo do nível de segurança necessário. Para obter informações sobre a configuração de segurança dos serviços opcionais do Developer for System z, consulte as seções anteriores.
Developer for System z usa uma variedade de mecanismos de segurança para assegurar um ambiente de sistema host seguro e controlado para o cliente. Para fazer isto, várias classes e configurações de segurança devem estar ativas, conforme mostrado com os seguintes comandos RACF de amostra:
Atenção: Alguns produtos, como o FTP, precisarão ser controlados pelo programa se "WHEN PROGRAM" estiver ativo. Teste este controle de programa antes de ativá-lo em um sistema de produção. |
Um segmento OMVS do RACF ou equivalente que especifica um ID do usuário z/OS UNIX (UID) não zero válido, diretório inicial e comando shell deve ser definido para cada usuário do Developer for System z. Seu grupo padrão também requer um segmento OMVS com um ID de grupo.
Ao usar o Depurador Integrado, o ID do usuário sob o qual o aplicativo sendo depurado está ativo e seu grupo padrão também requer um segmento RACF OMVS válido ou equivalente.
Nos comandos de amostra do RACF a seguir, substitua os marcadores #userid, #user-identifier, #group-name e #group-identifier por valores reais:
ALTUSER #userid
OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
ALTGROUP #group-name OMVS(GID(#group-identifier))
Os comandos RACF de amostra a seguir criam as tarefas iniciadas de DBGMGR, JMON e RSED, com IDs do usuário protegidos ( STCDBGM, STCJMON e STCRSE) e o grupo STCGROUP designado a elas. Substitua os marcadores #group-id e #user-id-* pelos IDs de OMVS válidos.
ADDGROUP STCGROUP OMVS(GID(#group-id))
DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD
NAME('RDZ - DEBUG MANAGER')
OMVS(UID(#user-id-debug) HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCJMON DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR')
OMVS(UID(#user-id-jmon) HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON')
OMVS(UID(#user-id-rse) HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647)
)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED DBGMGR.* DATA('RDZ - DEBUG MANAGER')
STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
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))
SETROPTS RACLIST(STARTED) REFRESH
Considere tornar o ID do usuário STCRSE restrito. Usuários com o atributo RESTRICTED não podem acessar recurso protegidos (MVS) que não estão especificamente autorizados a acessar.
ALTUSER STCRSE RESTRICTED
Para assegurar que os usuários restritos não obtenham acesso a recursos do sistema de arquivos z/OS UNIX por meio de "outras" permissões de bits, defina o perfil RESTRICTED.FILESYS.ACCESS na classe UNIXPRIV com UACC(NONE). Para obter mais informações sobre restringir IDs de usuário, consulte Security Server RACF Security Administrator's Guide (SA22-7683).
Atenção: Se usar IDs de usuário restritos, inclua explicitamente o acesso a um recursos usando os comandos de TSO PERMIT ou z/OS UNIX setfacl.
Os recursos incluem esses recursos em que a documentação do Developer
for System z usa UACC, como o perfil ** na classe PROGRAM ou em que conta com convenções comuns do z/OS UNIX, como qualquer pessoa tendo permissão de leitura e execução para bibliotecas Java.
Teste o acesso antes de ativá-lo em um sistema de produção. |
RSE requer acesso UPDATE ao perfil BPX.SERVER para criar ou excluir o ambiente de segurança para o encadeamento do cliente. Se esse perfil não estiver definido, UID(0) será necessário para o RSE. Essa etapa é necessária para que os clientes possam se conectar.
O Depurador Integrado requer acesso UPDATE ao perfil BPX.SERVER para criar ou excluir o ambiente de segurança para o encadeamento de depuração. Se este perfil não estiver definido, o UID(0) será necessário para o ID do usuário da tarefa iniciada de STCDBM. Esta permissão é necessária apenas quando o recurso Depurador Integrado opcional é usado.
Atenção: Definir o perfil BPX.SERVER
torna o z/OS UNIX um comutador completo da segurança de nível UNIX para a segurança de nível z/OS UNIX,
que é mais segura. Esse comutador pode afetar outros aplicativos e operações z/OS
UNIX. Teste a segurança antes de ativá-la em um sistema de produção. Para obter mais informações sobre os diferentes níveis de segurança, consulte UNIX System Services
Planning (GA22-7800). |
Servidores com autoridade para BPX.SERVER devem executar em um ambiente limpo e controlado por programa. Este requisito implica que todos os programas chamados pelo RSE também devem ser controlados por programa. Para as bibliotecas de carregamento do MVS, o controle de programa é gerenciado pelo seu software de segurança. Essa etapa é necessária para que os clientes possam se conectar.
O RSE usa o tempo de execução do sistema (SYS1.LINKLIB), Language Environment’ (CEE.SCEERUN*) e a biblioteca de carregamento do ISPF’ TSO/ISPF Client Gateway (ISP.SISPLOAD).
As bibliotecas de pré-requisito adicionais a seguir devem ser tornadas controladas por programa para suportar o uso de serviços opcionais. Esta lista não inclui conjuntos de dados que são específicos para um produto com o qual o Developer for System z interage, tal como o IBM File Manager.
A senha do cliente ou outro meio de identificação, como o certificado X.509 é usada somente para verificar a identidade mediante a conexão. Depois disso, os PassTickets são usados para manter a segurança do encadeamento. Essa etapa é necessária para que os clientes possam se conectar.
Os PassTickets são senhas geradas pelo sistema com um tempo de vida de aproximadamente 10 minutos. Os PassTickets gerados são baseados em uma chave secreta. Esta chave é um número de 64 bits (16 caracteres hexadecimais). Nos comandos de amostra RACF a seguir, substitua o marcador key16 por uma sequência hexadecimal de 16 caracteres fornecida pelo usuário que tenha os caracteres de 0 a 9 e A a F.
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 que não FEKAPPL. Remova o comentário e customize a opção "APPLID=FEKAPPL" em rsed.envvars para ativar isso, conforme documentado em "Defining extra Java startup parameters with _RSE_JAVAOPTS" no IBM Rational Developer for System z Host Configuration Guide. As definições de classe PTKTDATA devem corresponder ao ID do aplicativo real usado pelo RSE.
Não é recomendável usar OMVSAPPL como ID do aplicativo porque ele abrirá a chave secreta para a maioria dos aplicativos do z/OS UNIX. Também não é recomendável usar o ID do aplicativo padrão MVS, que é seguido do MVS pelo ID SMF do sistema, pois isso abrirá a chave secreta para a maioria dos aplicativos MVS, incluindo tarefas em lote do usuário.
Atenção: O pedido de conexão do cliente falhará se os PassTickets não estiverem
configurados corretamente. |
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
O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário por meio de um console MCS estendido (EMCS), cujo nome é controlado com a diretiva CONSOLE_NAME, conforme documentado em "FEJJCNFG, Arquivo de Configuração do JES Job Monitor" no Guia de Configuração do Host do IBM Rational Developer for System z.
A amostra a seguir de comandos RACF dá aos usuários do Developer for System z a acesso condicional a um conjunto limitado de comandos JES, que são Manter, Liberar, Cancelar e Limpar. Os usuários só terão permissão de execução se emitirem os comandos por meio do JES Job Monitor. Substitua o marcador #console pelo nome real do console.
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 a segurança antes de ativá-la em um sistema de produção. |
A Tabela 11 e a Tabela 12 mostram os comandos do operador emitidos para JES2 e JES3 e os perfis de segurança distintos que podem ser usados para protegê-los.
Ações | Comando | Perfil OPERCMDS | Acesso Necessário |
---|---|---|---|
Suspen
der |
$Hx(jobid)
with x = {J, S or T} |
|
UPDATE |
Liberar | $Ax(jobid)
with x = {J, S or T} |
|
UPDATE |
Cancelar | $Cx(jobid)
with x = {J, S or T} |
|
UPDATE |
Limpar | $Cx(jobid),P
with x = {J, S or T} |
|
UPDATE |
Ações | Comando | Perfil OPERCMDS | Acesso Necessário |
---|---|---|---|
Suspen
der |
*F,J=jobid,H |
|
UPDATE |
Liberar | *F,J=jobid,R |
|
UPDATE |
Cancelar | *F,J=jobid,C |
|
UPDATE |
Limpar | *F,J=jobid,C |
|
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. Mesmo que o console possa ser criado, o ponto de entrada é diferente; por exemplo, JES Job Monitor versus TSO. Os comandos JES emitidos deste console falharão na verificação de segurança se sua segurança estiver configurada conforme documentado nesta publicação e o usuário não tiver autoridade aos comandos JES por outros meios.
O acesso READ para usuários e ALTER para programadores de sistema é suficiente para a maioria dos conjuntos de dados do Developer for System z. Substitua o marcador #sysprog por IDs de usuário válidos ou nomes de grupos do RACF. Além disso, solicite ao programador de sistema que instalou e configurou o produto, os nomes de conjunto de dados corretos. FEK é o qualificador de alto nível padrão usado durante a instalação e FEK.#CUST é o qualificador de alto nível padrão para conjuntos de dados criados durante o processo de customização.
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 for System z exigem perfis adicionais do conjunto de dados de segurança. Substitua os marcadores #sysprog, #ram-developer e #cicsadmin por um ID de usuário válido ou nomes de grupos RACF:
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.SFEKLMOD' 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.SQL' 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.SFEKLMOD 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.SQL 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.#CUST.SQL' 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.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#ims)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#batch)
SETROPTS GENERIC(DATASET) REFRESH
Ao controlar o acesso READ para conjuntos de dados do sistema, você deve fornecer aos servidores Developer for System z e usuários a permissão READ para os seguintes conjuntos de dados:
Servidores com autoridade para BPX.SERVER devem executar em um ambiente limpo e controlado por programa. Este requisito implica que todos os programas chamados pelo RSE também devem ser controlados por programa. Para arquivos z/OS UNIX, o controle de programa é gerenciado pelo comando extattr. Para executar esse comando, você precisa de acesso READ para o BPX.FILEATTR.PROGCTL na classe FACILITY ou ser UID(0).
O servidor RSE usa a biblioteca compartilhada Java do RACF (/usr/lib/libIRRRacf*.so).
$ ls -Eog /usr/lib/libIRRRacf*.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf64.so
Use os seguintes comandos de amostra para exibir os resultados de suas customizações relacionadas à segurança.
Opcionalmente, perfis que direcionam o comportamento do Developer for System z para um usuário específico podem existir. Esses perfis correspondem o filtro FEK.** e são localizados por padrão na classe FACILITY. Consulte a diretiva _RSE_FEK_SAF_CLASS em rsed.envvars. É possível usar o comando SEARCH para listar os nomes de perfil. Use o comando RLIST para mostrar os detalhes para um perfil.
O Developer for System z usa TCP/IP para fornecer acesso ao mainframe para usuários de uma estação de trabalho sem mainframe. Ele também usa TCP/IP para comunicação entre vários componentes e outros produtos.
Observe que a maioria das funções do Developer for System z são baseadas em z/OS UNIX e, assim, o TCP/IP usará a ordem de procura do z/OS UNIX para localizar seus arquivos de configuração. Consulte Capítulo 14. Configurando o TCP/IP para obter informações adicionais.
Os seguintes tópicos são abordados neste capítulo:
Figura 10 mostra as portas TCP/IP que podem ser usadas pelo Developer for System z. As setas mostram qual parte não liga (lado de ponta da seta) e qual se conecta.
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 for System z são executados em encadeamentos ou espaços de endereço separados e utilizam soquetes TCP/IP como mecanismo de comunicação. Todos esses serviços usam o RSE para comunicação com o cliente, tornando seu fluxo de dados confinado apenas ao host. Para alguns serviços, será usada qualquer porta disponível, para outros, o programador de sistema poderá escolher a porta ou o intervalo de portas que será usado:
Se usar a instrução PORT ou PORTRANGE em PROFILE.TCPIP para reservar as portas usadas pelo Developer for System z, observe que muitas ligações são feitas por encadeamentos ativos em um conjunto de encadeamentos RSE. O nome da tarefa do conjunto de encadeamentos do RSE é RSEDx, em que RSED é o nome da tarefa iniciada do RSE e x é um número aleatório de um dígito; assim, curingas são obrigatórios na definição.
PORT 4035 TCP RSED ; Developer para System z - RSE daemon
PORT 6715 TCP JMON ; Developer para System z - JES job monitor
PORT 5335 TCP DBGMGR ; Developer for System z - Integrated
debugger
PORT 5336 TCP DBGMGR ; Developer for System z - Integrated
debugger
PORTRange 8108 11 TCP RSED* ; Developer para System z - _RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer para System z - CARMA
O CARMA (Common Access Repository Manager) é usado para acessar um host baseado em Software Configuration Manager (SCM), por exemplo, o CA Endevor® SCM. Na maioria dos casos, como no daemon RSE, um servidor se conecta a uma porta e atende a pedidos de conexão. O CARMA, no entanto, usa uma abordagem diferente, uma vez que o servidor CARMA não está ativo ainda quando o cliente inicia o pedido de conexão.
Quando o cliente envia uma solicitação de conexão, o minerador CARMA, que está ativo como um encadeamento de usuários em um conjunto de encadeamentos RSE, solicitará uma porta efêmera ou localizará uma porta livre no intervalo especificado no arquivo de configuração CRASRV.properties e ligará a ele. O extrator inicia então o servidor CARMA e transmite o número da porta, para que o servidor saiba a que porta se conectar. Quando o servidor estiver conectado, o cliente poderá enviar solicitações ao servidor e receber os resultados.
A partir de uma perspectiva TCP/IP, o RSE (por meio do minerador CARMA) é o servidor que liga a porta e o servidor CARMA é o cliente que se conecta a ela.
Se usar a instrução PORT ou PORTRANGE em PROFILE.TCPIP para reservar o intervalo de porta usado pelo CARMA, observe que o minerador CARMA está ativo em um conjunto de encadeamentos RSE. O nome da tarefa do conjunto de encadeamentos do RSE é RSEDx, em que RSED é o nome da tarefa iniciada RSE e x é um número aleatório de um dígito, assim são necessários caracteres curinga na definição.
PORTRange 5227 100 RSED* ; Developer para System z - CARMA
O servidor RSE pode ser configurado para consultar um ou mais servidores LDAP para vários serviços do Developer for System z:
Observe que medidas de segurança de TCP/IP, como firewalls, podem fazer com que o servidor RSE (baseado em host) pare de entrar em contato com o servidor LDAP. Use as informações a seguir para assegurar que o servidor LDAP possa ser atingido:
O ACK atrasado atrasa o reconhecimento (ACK) do recebimento de um pacote TCP em até 200 ms. Esse atraso aumenta a chance de que o ACK possa ser enviado com a resposta ao pacote recebido, reduzindo o tráfego de rede. Entretanto, se o remetente ficar aguardando o ACK antes de enviar um novo pacote (por exemplo, devido à implementação do algoritmo de Nagle) e não houver resposta ao pacote que acabou de ser enviado (por exemplo, porque ele faz parte de uma transferência de arquivo), a comunicação é atrasada desnecessariamente.
O Developer for System z permite que você desative a função de ACK atrasado. No host, isso é feito com a diretiva DSTORE_TCP_NO_DELAY em rsed.envvars, conforme documentado no Guia de Configuração do Host (S517-9094).
O z/OS Communication Server permite que você tenha diversas pilhas TCP/IP simultaneamente ativas em um único sistema. Isso é chamado configuração CINET.
Se Developer for System z não estiver ativo na pilha padrão, as funções selecionadas do Developer for System z podem falhar. A afinidade de pilha é um modo seguro para resolver isso. Ela instrui o Developer for System z a usar apenas determinada pilha TCP/IP (em vez de cada pilha TCP/IP disponível, que é o padrão para tarefas iniciadas).
A afinidade de pilha é configurada para as tarefas iniciadas de RSED removendo o comentário e customizando a diretiva _BPXK_SETIBMOPT_TRANSPORT no arquivo de configuração rsed.envvars. . Consulte a seção relacionada no "Capítulo 2 Customização Básica" do Guia de Configuração do Host (SC23-7658) para obter mais detalhes sobre como customizar este arquivo de configuração.
O CARMA (Common Access Repository Manager) é usado para acessar um host baseado em Software Configuration Manager (SCM), por exemplo, o CA Endevor® SCM. Para fazer isso, o CARMA inicia um servidor específico do usuário, que necessita de configuração adicional para impor a afinidade de pilha.
Semelhante às tarefas iniciadas do Developer for System z, a afinidade de pilha de um servidor CARMA é configurada com a variável _BPXK_SETIBMOPT_TRANSPORT, que deve ser passada para o LE (Language Environment). Isso pode ser feito ajustando o comando de inicialização no arquivo de configuração crastart*.conf ou CRASUB*.
Substitua esta parte:
... PARM(&CRAPRM1. &CRAPRM2.)
por esta (em que TCPIP representa a pilha TCP/IP desejada):
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
Substitua esta parte:
... PARM(&PORT &TIMEOUT)
por esta (em que TCPIP representa a pilha TCP/IP desejada):
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
O DVIPA (Dynamic Virtual IP Addressing) distribuído permite que você execute simultaneamente configurações Developer for System z idênticas em diferentes sistemas em seu sysplex e faça com que o TCP/IP, opcionalmente com a ajuda de WLM, distribua as conexões do cliente entre esses sistemas.
Há várias maneiras de se configurar um DVIPA distribuído, mas o Developer for System z impõe algumas restrições nessas opções.
Portanto, o Developer for System z requer a definição de SYSPLEXPORTS na instrução VIPADISTRIBUTE para assegurar que as portas usadas pelos encadeamentos do servidor RSE sejam exclusivas no sysplex.
Existem também algumas restrições no Developer for System z ao usar DVIPA distribuído:
JES Job Monitor, CARMA e outros servidores do Developer for System z somente interagem com o RSE local e, portanto, não requerem uma configuração DVIPA.
O Depurador Integrado interage com o RSE local e, portanto, não requer uma configuração de DVIPA. Para assegurar que as sessões de depuração se comuniquem com o host correto, o gerenciador de depuração informa ao cliente qual endereço TCP/IP deve ser usado e, dessa forma, não requer uma configuração de DVIPA.
Os DVIPAs distribuídos são definidos pelas palavras-chave VIPADEFine e VIPABackup do bloco VIPADynamic em seu perfil TCP/IP. A palavra-chave VIPADISTribute inclui as definições necessárias do Sysplex Distributor. O DVIPA distribuído requer que todas as pilhas participantes estejam de acordo com o sysplex, o que é feito por meio das palavras-chave SYSPLEXRouting e DYNAMICXCF do bloco IPCONFIG em seu perfil TCP/IP. Consulte Communications Server: IP Configuration Reference (SC31-8776) para obter detalhes adicionais sobre essas diretivas.
Consulte MVS Setting Up a Sysplex (SA22-7625) e Communication Server: SNA Network Implementation Guide (SC31-8777) para obter mais informações sobre a configuração da estrutura EZBEPORTS em seu recurso de acoplamento.
O uso de SYSPLEXPORTS implica em que o TCP/IP irá selecionar uma porta efêmera para a conexão secundária. Uma porta efêmera é qualquer porta que esteja livre e não reservada de nenhuma forma. O uso de uma porta efêmera conflita com a melhor prática de firewall de limitar as portas que estão abertas para comunicação, porque não se sabe qual porta será usada.
É possível contornar esse problema forçando o Developer for System z a usar portas conhecidas para a conexão secundária definindo um _RSE_PORTRANGE exclusivo por sistema e assegurando que os intervalos de portas usados sejam reservados para uso do Developer for System z em todos os sistemas. Observe que essa solução requer o APAR de TCP/IP PM63379.
Para assegurar que o TCP/IP irá rotear a conexão secundária para o sistema correto, o Developer for System z deve usar um intervalo de portas exclusivo em cada sistema. Isso implica em que não é possível usar uma configuração idêntica compartilhada para os sistemas, pois _RSE_PORTRANGE em rsed.envvars deve ser exclusivo. Consulte Arquivos de Configuração Diferentes de Níveis de Software Idênticos em Capítulo 11. Executando várias instâncias para obter informações sobre como configurar diversos servidores com diferentes arquivos de configuração usando o mesmo código. Você deve usar uma cópia principal de rsed.envvars e um script para ajustar e copiar em uma configuração específica ao sistema para assegurar que o arquivo permaneça idêntico em diferentes sistemas.
$ oedit /etc/rdz/rsed.envvars
-> add the following at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/update.sh
$ chmod 755 /etc/rdz/update.sh
#! /bin/sh
# Materiais Licenciados - Propriedade da IBM
# 5724-T07 Copyright IBM Corp. 2012
# clone rsed.envvars e configure PORTRANGE para uso com RDz & DDVIPA
file=rsed.envvars #; echo file $file
sys=${1:-$(sysvar SYSNAME)} #; echo sys $sys
dir=$(dirname $0) #; echo dir $dir
# se sysname tiver um caractere especial, preceda-o com \ (ex. SYS\$1)
case "$sys" in # #### CUSTOMIZE ESTA SEÇÃO ####
"SYS1") range=8108-8118;;
"SYS2") range=8119-8129;;
esac #; echo range $range
echo "configurando o intervalo de portas $range para $sys usando $dir/$file"
if test ! $range ; then
echo ERROR: nenhum intervalo de portas definido para $sys ; exit 12 ; fi
if test ! -e $dir/$file ; then
echo ERROR: o arquivo $dir/$file não existe ; exit 12 ; fi
if test ! -d $dir/$sys ; then
echo ERROR: o diretório $dir/$sys não existe ; exit 12 ; fi
mv $dir/$sys/$file $dir/$sys/prev.$file 2>/dev/null
sed="/_RSE_PORTRANGE/s/.*/_RSE_PORTRANGE=$range/"
sed "$sed" $dir/$file > $dir/$sys/$file
if test ! -s $dir/$sys/$file ; then
echo ERRO ao criar $dir/$sys/$file, restaurando o backup
mv $dir/$sys/prev.$file $dir/$sys/$file ; exit 8 ; fi
$ mkdir /etc/rdz/SYS1 /etc/rdz/SYS2
$ /etc/rdz/update.sh SYS1
configurando o intervalo de portas 8108-8118 para SYS1 usando
/etc/rdz/rsed.envvars
$ /etc/rdz/update.sh SYS2
configurando o intervalo de portas 8119-8129 para SYS2 usando
/etc/rdz/rsed.envvars
// CNFG='/etc/rdz/&SYSNAME.'
Em seguida, você deve assegurar-se de que os intervalos de portas definidos sejam reservados para o Developer for System z em todos os sistemas no sysplex para garantir que o número da porta permaneça exclusivo dentro do sysplex. Use a instrução PORT ou PORTRANGE em PROFILE.TCPIP para reservar todos os intervalos em todos os sistemas. O nome da tarefa do conjunto de encadeamentos do RSE é RSEDx, em que RSED é o nome da tarefa iniciada do RSE e x é um número aleatório de um dígito; assim, curingas são obrigatórios na definição.
PORTRange 8108 22 RSED* ; 8108-8129 - Developer para System z
; - conexão secundária
Conforme documentado em Fluxo de conexão, o intervalo de portas em _RSE_PORTRANGE pode ser pequeno. O servidor RSE não precisa da porta exclusivamente pela duração da conexão do cliente. Ela só é necessária no momento da expansão entre (servidor) a ligação e (cliente) a conexão que nenhum outro servidor RSE pode se conectar à porta. Isso significa que a maioria das conexões estará usando a primeira porta no intervalo, com o restante do intervalo sendo um buffer no caso de diversos logons simultâneos.
Na configuração de amostra a seguir existem dois sistemas z/OS, SYS1 e SYS2, que fazem parte de um sysplex. O System SYS1 é definido como o sistema que normalmente hospeda o Sysplex Distributor para o DVIPA distribuído Developer for System z.
Depois de definir o DVIPA distribuído, o Developer for System z pode ser iniciado nos sistemas para permitir as conexões do cliente do balanceamento de carga em todos os sistemas. O JES Job Monitor apenas interage com o RSE local e, portanto, não requer uma configuração DVIPA. Os clientes se conectarão à porta 4035 no endereço IP 10.10.10.1.
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING é necessário, pois esta pilha precisa da comunicação sysplex
DYNAMICXCF 9.9.9.1 255.255.255.0 1
; DYNAMICXCF define o dispositivo/link com o endereço home 9.9.9.1 conforme necessário
IGNORERedirect
VIPADYNAMIC
VIPADEFINE 255.255.255.0 10.10.10.1
; VIPADEFINE define 10.10.10.1 como DVIPA principal no SYS1 para RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE torna 10.10.10.1 um DVIPA distribuído, deve corresponder ao SYS2
SYSPLEXPORTS ; RDz prereq
DISTMETHOD BASEWLM ; BASEWLM or ROUNDROBIN
10.10.10.1 ; endereço DVIPA usado por clientes RDz
PORT 4035 ; porta usada por clientes RDz
DESTIP 9.9.9.1 9.9.9.2 ; RDz ativo em SYS1 e SYS2
ENDVIPADYNAMIC
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING é necessário, pois esta pilha precisa da comunicação sysplex
DYNAMICXCF 9.9.9.2 255.255.255.0 1
; DYNAMICXCF define o dispositivo/link com o endereço home 9.9.9.2 conforme necessário
IGNORERedirect
VIPADYNAMIC
VIPABACKUP 255.255.255.0 10.10.10.1
; VIPABACKUP define 10.10.10.1 como um DVIPA de backp em SYS2 para RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE torna 10.10.10.1 um DVIPA distribuído, deve corresponder a SYS1
SYSPLEXPORTS ; RDz prereq
DISTMETHOD BASEWLM ; BASEWLM or ROUNDROBIN
10.10.10.1 ; endereço DVIPA usado por clientes RDz
PORT 4035 ; porta usada por clientes RDz
DESTIP 9.9.9.1 9.9.9.2 ; RDz ativo em SYS1 e SYS2
ENDVIPADYNAMIC
Ao contrário dos aplicativos tradicionais do z/OS, o Developer for System z não é um aplicativo monolítico que pode ser identificado facilmente para Workload Manager (WLM). O Developer for System z consiste de vários componentes que interagem para fornecer ao cliente acesso para os serviços e dados do host. Como descrito em Capítulo 1. Entendendo o Developer for System z, alguns destes serviços estão ativos em espaços de endereços diferentes, resultando em classificações WLM diferentes.
Os seguintes tópicos são abordados neste capítulo:
O Figura 13 mostra uma visão geral básica dos subsistemas por meio dos quais as cargas de trabalho do Developer for System z são apresentadas ao WLM.
O Application Deployment Manager (ADM) está ativo dentro de uma região CICS e, portanto, seguirá as regras de classificação do CICS no WLM.
RSE daemon (RSED) e JES Job Monitor (JMON) são tarefas iniciadas do Developer for System z (ou tarefas em lote de longa execução), cada um com espaço de endereço individual.
Como documentado em RSE como um aplicativo Java, o daemon RSE gera um processo-filho para cada servidor de conjunto de encadeamentos RSE (que suporta um número variável de clientes). Cada conjunto de encadeamentos está ativo em um espaço de endereço separado (usando um iniciador z/OS UNIX, BPXAS). Porque estes são processos gerados, eles são classificados usando as regras de classificação WLM OMVS, e não as regras de classificação de tarefa iniciada.
Os clientes que estão ativos em um conjunto de encadeamentos podem criar uma infinidade de outros espaços de endereços, dependendo das ações realizadas pelos usuários. Dependendo da configuração de Developer for System z algumas cargas de trabalho, como o serviço TSO Commands (TSO cmd) ou CARMA, podem executar em subsistemas diferentes.
Os espaços de endereços listados em Figura 13 permanecem no sistema o tempo suficiente para serem visíveis, mas você deve estar ciente que devido à maneira como o z/OS UNIX é projetado, há também vários espaços de endereços temporários de curta duração. Estes espaços de endereços temporários estão ativos nos subsistemas OMVS.
Note que enquanto os conjuntos de encadeamento RSE usam o mesmo ID do usuário e um nome de tarefa similar como o daemon RSE, todos os espaços de endereços iniciados por um conjunto de encadeamento são de propriedade do ID do usuário do cliente solicitando a ação. O ID de usuário cliente também é usado como (parte de) o nome da tarefa para todos os espaços de endereço baseados em OMVS iniciados pelo conjunto de encadeamentos.
Mais espaços de endereços são criados por outros serviços que o Developer for System z usa, como o File Manager (FMNCAS) ou o z/OS UNIX REXEC (construção USS).
O WLM usa regras de classificações para mapear o trabalho entrando no sistema para uma classe de serviço. Esta classificação é baseada nos qualificadores de trabalho. O primeiro qualificador (obrigatório) é um tipo de subsistema que recebe o pedido de trabalho. O Tabela 13 lista os tipos de subsistema que podem receber cargas de trabalho Developer for System z.
Tipos de subsistemas | Descrição do trabalho |
---|---|
ASCH | Os pedidos de trabalho incluem todos os programas de transação APPC planejados pelo planejador de transação da IBM-supplied APPC/MVS, ASCH. |
CICS | Os pedidos de trabalho incluem todas as transações processadas pelo CICS. |
JES | Os pedidos de trabalho incluem todos os trabalhos que o JES2 ou JES3 iniciam. |
OMVS | Os pedidos de trabalho incluem o trabalho processado nos espaços de endereços filhos bifurcados no z/OS UNIX System Services. |
STC | Os pedidos de trabalho incluem todo o trabalho iniciado pelos comandos START e MOUNT. O STC também inclui os espaços de endereços do componente do sistema. |
A Tabela 14 lista qualificadores adicionais que podem ser usados para designar uma carga de trabalho a uma classe de serviço específica. Consulte MVS Planejamento: Gerenciamento de Carga de Trabalho (SA22-7602) para obter detalhes adicionais sobre os qualificadores de trabalho listados.
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 for System z cria tipos diferentes de cargas de trabalho no seu sistema. Estas diferentes tarefas comunicam-se entre si, o que implica que o tempo decorrido real tornar-se importante para evitar problemas de tempo limite para as conexões entre as tarefas. Como resultado, Developer for System z é recomendável que as tarefas sejam colocadas em classes de serviço de alto desempenho ou em classes de serviço de desempenho moderado com uma alta prioridade.
Uma revisão, e possivelmente uma atualização, dos seus objetivos WLM atuais é, por essa razão, aconselhado. Isto é especialmente verdadeiro para empresas tradicionais MVS novas no que diz respeito às cargas de trabalho OMVS de tempo crítico.
O Tabela 15 lista os espaços de endereços que são usados pelo Developer for System z. O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
JES Job Monitor | JMON | STC |
Daemon RSE | RSED | STC |
Conjunto de encadeamento do RSE | RSEDx | OMVS |
ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid>x | OMVS |
Serviço do TSO Commands (APPC) | FEKFRSRV | ASCH |
CARMA (batch) | CRA<port> | JES |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF Client Gateway) | <userid> e <userid>x | OMVS |
Build MVS (tarefa em lote) | * | JES |
Build z/OS UNIX (comandos do shell) | <userid>x | OMVS |
Shell do z/OS UNIX | <userid> | OMVS |
Tarefa do File Manager | <userid>x | OMVS |
Gerenciador de Implementação de Aplicativo | CICSTS | CICS |
As seguintes considerações gerais do WLM podem ajudar a definir apropriadamente as definições de objetivos corretas para Developer for System z:
Quando usar os objetivos de tempo de resposta:
Quando usar objetivos de velocidade:
Todas as tarefas iniciadas do Developer for System z, daemons RSE e JES Job Monitor, estão atendendo solicitações de cliente em tempo real.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
JES Job Monitor | JMON | STC |
Daemon RSE | RSED | STC |
O JES Job Monitor fornece todos os serviços relacionados a JES, como enviar tarefas, navegar arquivos de spool e executar comandos de 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 RSE trata da criação do logon e autenticação do cliente e gerencia os diferentes conjuntos de encadeamentos RSE. É 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. 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á "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
Conjunto de encadeamento do RSE | RSEDx | OMVS |
ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid>x | OMVS |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF Client Gateway) | <userid> e <userid>x | OMVS |
Build z/OS UNIX (comandos do shell) | <userid>x | OMVS |
Shell do z/OS UNIX | <userid> | OMVS |
Tarefa do File Manager | <userid>x | OMVS |
Um conjunto de encadeamentos RSE é como o coração e o cérebro do Developer for 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 for System z. É 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 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 for System z para executar 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 for 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 for System z opcional usado para interagir com Software Configuration Managers (SCMs), baseados em host, tais como o CA Endevor® SCM. O Developer for 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 shell do 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 shell do z/OS UNIX que são emitidos pelo cliente. 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.
Embora não sejam espaços de endereços Developer for System z, os processos-filho do File Manager gerados são listados aqui porque eles podem ser iniciados por pedido de um cliente Developer for System z e estas tarefas usam a mesma convenção de nomenclatura como tarefas Developer for 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 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.
Os processos em lote do JES gerenciado são usados de várias maneiras pelo Developer for System z. O uso mais comum é para construções MVS, onde uma tarefa é submetida e monitorada para determinar quando ela termina. Mas o Developer for System z também poderia iniciar um servidor CARMA em lote e comunicar-se com ele usando TCP/IP.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
CARMA (batch) | CRA<port> | JES |
Build MVS (tarefa em lote) | * | JES |
O CARMA é um servidor Developer for System z opcional usado para interagir com Software Configuration Managers (SCMs), baseados em host, tais como o CA Endevor® SCM. O Developer for 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 for 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 for System z, o ISPF Client Gateway é usado para executar comandos TSO e ISPF não interativos. Devido a razões históricas, o Developer for System z também suporta executar estes comandos por meio de uma transação APPC. Você deve observar que o método APPC é reprovado.
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 for 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 for 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 de 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 Developer for System z opcional que está ativo dentro de uma região do CICS Transaction Server.
Descrição | Nome da tarefa | Carga de trabalho |
---|---|---|
Gerenciador de Implementação de Aplicativo | 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 de 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 a ser usado depende das outras transações ativas nesta região CICS e, portanto, não é discutido em detalhes.
O WLM suporta vários tipos de gerenciamento que você pode usar para CICS:
O objetivo é configurado para uma classe de serviço que gerencia os espaços de endereços 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ção JES ou STC para os espaços de endereços e as regras de classificação do subsistema CICS para transações.
Conforme explicado em Capítulo 1. Entendendo o Developer for System z, o RSE (Explorador de Sistema Remoto) é o núcleo do Developer for System z. Para gerenciar as conexões e as cargas de trabalho a partir dos clientes, o RSE é formado por um espaço de endereço do daemon, que controla os espaços de endereços do conjunto de encadeamento. O daemon age como um ponto focal para fins de conexão e gerenciamento, enquanto os conjuntos de encadeamentos processam as cargas de trabalho do cliente.
Isso torna o RSE um alvo principal para o ajuste da configuração do Developer for System z. Entretanto, manter centenas de usuários, cada um usando 17 ou mais encadeamentos, uma certa quantia de armazenamento, e possivelmente 1 ou mais espaços de endereços requer uma configuração adequada de ambos Developer for System z e z/OS.
Os seguintes tópicos são abordados neste capítulo:
Use as informações nesta seção para estimar o uso normal e máximo de recursos pelo Developer for System z, para que possa planejar sua configuração do sistema de acordo.
Ao usar os números e as fórmula apresentados nesta seção para definir os valores dos limites do sistema, lembre-se de que você está trabalhando com estimativas bastante precisas. Deixe margem suficiente ao configurar os limites do sistema para permitir o uso de recursos por tarefas temporárias e outras tarefas, ou por usuários que se conectam várias vezes ao host simultaneamente. (Por exemplo, por meio de RSE e de TN3270).
As tabelas a seguir dão uma visão geral do número de espaços de endereços, processos e encadeamentos usados pelo Developer for System z. Mais detalhes sobre os números apresentados aqui podem ser localizados nas seções de texto:
Tabela 21 dá uma visão geral dos principais recursos usados pelas tarefas iniciadas do Developer for System z. Esses recursos são alocados apenas uma vez. Eles são compartilhados entre clientes do Developer for System z.
Tarefa iniciada | Espaços de endereço | Processos | Encadeamentos |
---|---|---|---|
JMON | 1 | 1 | 3 |
RSED | 1 | 3 | 11 |
RSEDx | 1 + 1 (a) | 1 + 2 | 1 + 10 |
A Tabela 22 fornece uma visão geral dos recursos principais usados pelo software obrigatório. Esses recursos são alocados para cada cliente do Developer for System z que chama a função relacionada.
Software obrigatório | Espaços de endereço | Processos | Encadeamentos |
---|---|---|---|
ISPF Client Gateway | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
Tabela 23 dá uma visão geral dos principais recursos por cada cliente do Developer for System z ao executar a função especificada. Valores não-numéricos, como ISPF, são uma referência ao valor correspondente na Tabela 22.
Ação do usuário
|
Espaços de endereço
ID do
usuário |
Processos
ID do
usuário |
Encadeamentos ID do usuário RSEDx JMON |
||
---|---|---|---|---|---|
Logon | - | - | - | 17 | 1 |
Cronômetro para tempo limite inativo | - | - | - | 1 | - |
Procurar | - | - | - | 1 | - |
Expandir PDS(E) | ISPF | ISPF | ISPF | - | - |
Abrir conjunto de dados | ISPF | ISPF | ISPF | 1 | - |
Comando TSO | ISPF | ISPF | ISPF | - | - |
Shell do z/OS UNIX | 1 | 1 | 1 | 6 | - |
Build MVS | 1 | - | - | - | - |
Build z/OS UNIX | 3 | 3 | 3 | - | - |
CARMA (batch) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 4 | - |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
Tabela 24 lista os espaços de endereços que são usados pelo Developer for System z, em que "u" na coluna "Count" indica que a quantia deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função. O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.
Contador | Descrição | Nome da tarefa | Comparti
lhado |
Termina após |
---|---|---|---|---|
1 | JES Job Monitor | JMON | Sim | Nunca |
1 | Daemon RSE | RSED | Sim | Nunca |
1 | RSE APF autorizado | RSEDx | Sim | Nunca |
(a) | Conjunto de encadeamento do RSE | RSEDx | Sim | Nunca |
lu | ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid>x | Não | 15 minutos ou no logoff do usuário |
lu | Serviço do TSO Commands (APPC) | FEKFRSRV | Não | 60 minutos ou efetuar logoff do usuário |
lu | CARMA (batch) | CRA<port> | Não | 7 minutos ou no logoff do usuário |
lu | CARMA (crastart) | <userid>x | Não | 7 minutos ou no logoff do usuário |
4u | CARMA (ispf, descontinuado) | (1)<userid> ou (3)<userid>x | Não | 7 minutos ou no logoff do usuário |
(b) | Uso simultâneo do ISPF Client Gateway por 1 usuário | <userid>x | Não | Conclusão da tarefa |
1u | Build MVS (tarefa em lote) | * | Não | Conclusão da tarefa |
3u | Build z/OS UNIX (comandos do shell) | <userid>x | Não | Conclusão da tarefa |
1u | Shell do z/OS UNIX | <userid> | Não | Logoff do usuário |
Use a fórmula em Figura 14 para estimar o número máximo de espaços de endereços usados pelo Developer for System z.
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, descontinuado) |
Use a fórmula em Figura 15 para estimar o número máximo de espaços de endereços usados por um cliente Developer for System z (não contando os espaços de endereços temporários não documentados).
Em que,
As definições na Tabela 25 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) |
Tabela 26 lista o número de processos por espaço de endereço que é usado pelo Developer for System z. "u" na coluna "Address Spaces" indica que a quantia deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função.
Processos | Espaços de endereço | Descrição | ID do usuário |
---|---|---|---|
1 | 1 | JES Job Monitor | STCJMON |
3 | 1 | Daemon RSE | STCRSE |
1 | 1 | Autorizado pelo APF RSE | STCRSE |
2 | (a) | Conjunto de encadeamento do RSE | STCRSE |
2 | (b) | ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) | <userid> |
1 | 1u | Serviço do TSO Commands (APPC) | <userid> |
1 | 1u | CARMA (batch) | <userid> |
1 | 1u | CARMA (crastart) | <userid> |
1 | 1u | CARMA (ispf, descontinuado) | <userid> |
1 | 3u | Build z/OS UNIX (comandos do shell) | <userid> |
1 | 1u | Shell do z/OS UNIX | <userid> |
(5) | (u) | SCLM Developer Toolkit | <userid> |
Use a fórmula em Figura 16 para estimar o número máximo de processos usados pelo Developer for 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, descontinuado) |
Use a fórmula em Figura 17 para estimar o número máximo de processos usados pelo STCRSE, o RSED iniciou o ID do usuário da tarefa (não contando os processos temporários não documentados).
Em que,
Use a fórmula em Figura 18 para estimar o número máximo de processos usados por um cliente Developer for System z (não contando os processos temporários não documentados).
Em que,
As definições na Tabela 27 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:
Tabela 28 lista o número de encadeamentos usados pelas funções selecionadas do Developer for System z. "u" nas colunas "Encadeamentos" indica que a quantidade deve ser multiplicada pelo número de usuários ativos simultaneamente usando a função. A contagem de encadeamento é listada por processo, à medida que os limites são definidos neste nível.
Encadeamentos |
ID do usuário | Descrição | ||
---|---|---|---|---|
RSEDx | Ativado | Autoinicialização | ||
- | 3 + 1u | - | STCJMON | JES Job Monitor |
- | 15 | 2 | STCRSE | Daemon RSE |
- | 1 | - | STCRSE | RSE APF autorizado |
10 (a) + 17u | - | 1 (a) | STCRSE | Conjunto de encadeamento do RSE |
- | 4u (b) | 1u (b) | <userid> | ISPF Client Gateway (Serviço do TSO Commands e do SCLMDT) |
- | 2u | - | <userid> | Serviço do TSO Commands (APPC) |
1u | 2u | - | STCRSE e <userid> | CARMA (batch) |
4u | 2u | - | STCRSE e <userid> | CARMA (crastart) |
5u | 4u | 3u | STCRSE e <userid> | CARMA (ispf, descontinuado) |
- | 1u (c) | 2u | <userid> | Build z/OS UNIX (comandos do shell) |
6u | 1u | - | STCRSE e <userid> | Shell do z/OS UNIX |
1 (d) | - | - | STCRSE | Fazer Download |
1 (e) | - | - | STCRSE | Procurar |
- | (5) | - | <userid> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Cronômetro para tempo limite inativo |
Use a fórmula em Figura 19 para estimar o número máximo de encadeamentos usados por um conjunto de encadeamentos RSE. Use a fórmula da Figura 20 para avaliar o número máximo de encadeamentos usados pelo JES Job Monitor.
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, descontinuado) |
As definições na Tabela 29 podem limitar o número real de encadeamentos em um processo, o que é da maior importância para os conjuntos de encadeamentos do RSE.
Local | Limite | Recursos afetados |
---|---|---|
BPXPRMxx | MAXTHREADS | Limita o número de encadeamentos em um processo. |
BPXPRMxx | MAXTHREADTASKS | Limita o número de tarefas MVS em um processo. |
BPXPRMxx | MAXASSIZE | Limita o tamanho de espaço de endereço e, portanto, o armazenamento disponível para blocos de controle relacionados a encadeamento. |
rsed.envvars | Xmx | Define o tamanho máximo do heap Java. Este armazenamento é reservado e, portanto, não está mais disponível para blocos de controle relacionados a encadeamento. |
rsed.envvars | maximum.clients | Limita o número de clientes (e, portanto, seus encadeamentos) em um conjunto de encadeamento do RSE. |
rsed.envvars | maximum.threads | Limita o número de encadeamentos de cliente em um conjunto de encadeamentos RSE. |
FEJJCNFG | MAX_THREADS | Limita o número de encadeamentos no JES Job Monitor. |
O uso de recurso documentado nas seções anteriores é permanente para o tempo de vida do Developer for System z ou semipermanente para certas tarefas específicas do usuário.
Entretanto, o Developer for System z usará temporariamente os recursos adicionais para tarefas de manutenção e atender às solicitações a seguir:
RSE é um aplicativo Java, que implica que o planejamento de uso de armazenamento (memória) para Developer for System z deve levar dois limites de alocação de armazenamento em consideração, tamanho de heap Java e tamanho de Espaço de Endereço.
Java oferece vários serviços para facilitar os esforços de codificação para aplicativos Java. Um desses serviços é o gerenciamento de armazenamento.
O gerenciamento de armazenamento Java aloca grandes blocos de armazenamento e os usa para pedidos de armazenamento pelo aplicativo. Esse armazenamento gerenciado por Java é chamado de heap Java. A coleta de lixo periódica (desfragmentação) reclama o espaço não utilizado no heap e reduz o seu tamanho. Note que, para salvar ciclos de CPU, a coleta de lixo tende a aguardar até que o armazenamento ocupado seja realmente necessário, deixando, assim, o armazenamento que não é mais usado alocado (e se tornando paginado) por um período maior de tempo do que o absolutamente necessário.
O tamanho de heap máximo Java é definido em rsed.envvars com a diretiva Xmx. Se esta diretiva não for especificada, o Java usará um tamanho padrão de 512 MB. Você deve especificar um valor de 256 MB ou mais alto. Ao executar em modo de 64 bits, o Java tentará alocar o heap acima de 2 GB de barramento, liberando espaço abaixo do barramento.
Cada conjunto de armazenamento do RSE (que atende às ações do cliente) é um aplicativo Java separado e, portanto, tem um heap Java pessoal. Observe que todos os conjuntos de encadeamento usam o mesmo arquivo de configuração rsed.envvars e, portanto, têm o mesmo limite de tamanho de heap Java.
O uso do conjunto de encadeamento do heap Java depende muito das ações executadas pelos clientes conectados. O monitoramento regular do uso de heap é necessário para definir o limite de tamanho de heap ideal. Use o comando do operador modificar processo de exibição para monitorar o uso de heap Java por conjuntos de encadeamento do RSE.
Todos os aplicativos z/OS, incluindo aplicativos Java, estão ative dentro de um espaço de endereço, e estão, portanto, ligados pelas limitações de tamanho do espaço de endereço.
O tamanho do espaço de endereço desejado é especificado durante a inicialização, por exemplo, com o parâmetro REGION em JCL. Entretanto, as configurações do sistema podem limitar o tamanho do espaço de endereço real. Consulte Tamanho do espaço de endereço para saber mais sobre esses limites.
Os conjuntos de encadeamento do RSE herdam os limites de tamanho do espaço de endereço do daemon RSE. O tamanho do espaço de endereço deve ser suficiente para abrigar o heap Java, o próprio Java, as áreas de armazenamento comuns e todos os blocos de controle que o sistema cria para suportar a atividade do conjunto de encadeamento, como um TCB (Bloco de Controle de Tarefa) por encadeamento. Observe que algum desse uso de armazenamento está abaixo da linha de 16 MB. Ao executar em modo de 64 bits, o Java tentará alocar o heap acima de 2 GB de barramento, liberando espaço abaixo do barramento.
Você deve monitorar o tamanho do espaço de endereço real antes de alterar quaisquer configurações que o influenciem, como alterar o tamanho do heap Java ou a quantidade de usuários suportada por um único conjunto de encadeamento. Use o software de monitoramento regular do sistema para controlar o uso de armazenamento real pelo Developer for system z. Se você não tiver uma ferramenta de monitoramento dedicada, então informações básicas podem ser reunidas com ferramentas como a visualização SDSF DA ou TASID (uma ferramenta de informações do sistema como elas estão armazenadas no banco de dados disponível por meio da página da Web "Support and downloads" do ISPF).
Conforme mencionado antes, o uso de armazenamento real pelo Developer para System z é altamente influenciado pela atividade do usuário. Algumas ações usam uma quantidade fixa de armazenamento (por exemplo, logon), enquanto outras são variáveis (por exemplo, listando conjuntos de dados com um qualificador de alto nível especificado).
Observe que o RSE exibe o heap Java atual e o limite de tamanho de espaço de endereço durante a inicialização na mensagem do console FEK004I.
Use um dos seguintes cenários se o monitoramento mostrar que o tamanho de heap Java atual é insuficiente para a carga de trabalho real:
Como referência, oTabela 30 mostra valores usados por clientes reais do Developer for System z para configurações de chave rsed.envvars que têm impacto no uso de armazenamento.
xmx (heap java máximo) | maximum.clients | Tipo de desenvolvimento primário |
---|---|---|
512M | 30 | PL/I |
512M | 10 | COBOL |
384M | 12 | COBOL |
800M (64 bits) | 20 | Não especificado |
As exibições nas figuras a seguir mostram alguns números de uso de recurso de amostra para uma configuração padrão do Developer for System z com essas modificações.
Tamanho Máx Heap=10 MB e privado AS Tamanho=1,959 MB
inicialização
BPXM023I (STCRSE)
ID do Processo(268 ) Uso de Memória(7%) Clientes(0)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,01 2740 72
RSED 4,47 32,8 M 15910
RSED8 1,15 27,4 M 12612
logon 1
BPXM023I (STCRSE)
ID do Processo(268 ) Uso de Memória(13%) Clientes(1)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,01 2864 81
RSED 4,55 32,8 M 15980
RSED8 3,72 55,9 M 24128
logon 2
BPXM023I (STCRSE)
ID do Processo(268 ) Uso de Memória(23%) Clientes(2)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,02 2944 86
RSED 4,58 32,9 M 16027
RSED8 4,20 57,8 M 25205
logon 3
BPXM023I (STCRSE)
ID do Processo(268 ) Uso de Memória(37%) Clientes(3)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,02 3020 91
RSED 4,60 32,9 M 16076
RSED8 4,51 59,6 M 26327
logon 4
BPXM023I (STCRSE)
ID do Processo(268 ) Uso de Memória(41%) Clientes(4)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,02 3108 96
RSED 4,61 32,9 M 16125
RSED8 4,77 62,3 M 27404
logon 5
BPXM023I (STCRSE)
ID do Processo(268 ) Uso de Memória(41%) Clientes(4)
ID do Processo(33554706) Uso de Memória(13%) Clientes(1)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,03 3184 101
RSED 4,64 32,9 M 16229
RSED8 4,78 62,4 M 27413
RSED9 4,60 56,6 M 24065
A Figura 21 e a Figura 22 mostram um cenário em que 5 clientes efetuam logon em um daemon RSE com um heap Java de 10 MB.
Tamanho Máx Heap=10 MB e privado AS Tamanho=1,959 MB
inicialização
BPXM023I (STCRSE)
ID do Processo(212 ) Uso de Memória(7%) Clientes(0)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,01 2736 71
RSED 4,35 32,9 M 15117
RSED8 1,43 27,4 M 12609
logon
BPXM023I (STCRSE)
ID do Processo(212 ) Uso de Memória(13%) Clientes(1)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,01 2864 80
RSED 4,48 33,0 M 15187
RSED8 3,53 53,9 M 24125
expandir árvore MVS grande (195 conjuntos de dados)
BPXM023I (STCRSE)
ID do Processo(212 ) Uso de Memória(13%) Clientes(1)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0,01 2864 80
RSED 4,58 33,1 M 16094
RSED8 4,28 56,1 M 24740
expandir PDS pequeno (21 membros)
BPXM023I (STCRSE)
ID do Processo(212 ) Uso de Memória(13%) Clientes(1)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
IBMUSER2 0,22 2644 870
JMON 0,01 2864 80
RSED 4,61 33,1 M 16108
RSED8 4,40 56,2 M 24937
abrir membro de tamanho médio (86 linhas)
BPXM023I (STCRSE)
ID do Processo(212 ) Uso de Memória(13%) Clientes(1)
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
IBMUSER2 0,22 2644 870
JMON 0,01 2864 80
RSED 4,61 33,1 M 16108
RSED8 8,12 62,7 M 27044
A Figura 23 mostra um cenário em que 1 cliente efetua logon em um daemon RSE com um heap Java de 10 MB e edita um membro PDS.
A maioria dos dados relacionados ao Developer for System z que não estão gravados em uma instrução DD terminam em um arquivo z/OS UNIX. O programador de sistema tem controle sobre os dados que são gravados e para onde eles vão. Entretanto, não há controle sobre a quantidade de dados gravada.
Os dados podem ser agrupados nas seguintes categorias:
Conforme documentado em Capítulo 12. Resolução de problemas de configuração, o Developer for System z grava os logs de host relacionados a RSE nos seguintes diretórios z/OS UNIX:
Por padrão, apenas as mensagens de erro e de aviso são gravadas nos logs. Portanto, se tudo correr conforme o planejado, esses diretórios devem manter apenas os arquivos vazios ou quase vazios(sem contar os logs de auditoria).
Você pode ativar a criação de log de mensagens informativas, preferivelmente na direção do centro de suporte IBM, o que aumenta perceptivelmente o tamanho dos arquivos de log.
inicialização
$ ls -l /var/rdz/logs
total 144
-rw-rw-rw- 1 STCRSE STCGRP 33642 Jul 10 12:10 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 1442 Jul 10 12:10 rseserver.log
logon
$ ls -l /var/rdz/logs
total 144
drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER
-rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 160
-rw-rw-rw- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw-rw-rw- 1 IBMUSER SYS1 303 Jul 10 12:11 lock.log
-rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar
-rw-rw-rw- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stdout.log
logoff
$ ls -l /var/rdz/logs
total 80
drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER
-rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 296
-rw-rw-rw- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw-rw-rw- 1 IBMUSER SYS1 609 Jul 10 12:11 lock.log
-rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar
-rw-rw-rw- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log
-rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log
-rw-rw-rw- 1 IBMUSER SYS1 176 Jul 10 12:11 stdout.log
parar
$ ls -l /var/rdz/logs
total 80
drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER
-rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
A Figura 24 mostra o uso mínimo do espaço do sistema de arquivos z/OS UNIX ao usar o nível de depuração 2 (mensagens informativas).
Exceto para logs de auditoria, os arquivos de log são sobrescritos em cada reinício (para a tarefa iniciada do RSE) ou logon (de um cliente), mantendo o tamanho total em verificação. A diretiva keep.last.log em rsed.envvars altera isso ligeiramente, uma vez que ela pode instruir o RSE a manter uma cópia dos logs anteriores. As cópias mais antigas são sempre removidas.
Uma mensagem de aviso é enviada ao console quando o sistema de arquivos que contém os arquivos de log de auditoria estiver em execução com pouco espaço livre e a auditoria estiver ativa. Essa mensagem do console (FEK103E) é repetida regularmente até que o problema de pouco espaço seja resolvido. Consulte "Mensagens do console" no Guia de Configuração do Host (SC23-7658) para obter uma lista de mensagens do console geradas pelo RSE.
As definições na Tabela 31 controlam os dados que são gravados nos diretórios de log e onde os diretórios estão localizados.
Local | Diretriz | Funções |
---|---|---|
resecomm.properties | debug_level | Definir o nível de detalhes do log padrão. |
rsed.envvars | keep.last.log | Manter uma cópia dos logs anteriores antes da inicialização/logon. |
rsed.envvars | enable.audit.log | Manter um rastreio de auditoria de ações do cliente. |
rsed.envvars | enable.standard.log | Gravar os fluxos stdout e stderr do conjunto (ou conjuntos) de encadeamento em um arquivo de log. |
rsed.envvars | DSTORE_TRACING_ON | Ativar a criação de log de ações do DataStore. |
rsed.envvars | DSTORE_MEMLOGGING_ON | Ativar a criação de log do uso de memória do DataStore. |
Comando do operador | modify rsecommlog <level> | Altera dinamicamente o nível de detalhes do log de rsecomm.log |
Comando do operador | modify rsedaemonlog <level> | Altera dinamicamente o nível de detalhes do log de rsedaemon.log |
Comando do operador | modify rseserverlog <level> | Altera dinamicamente o nível de detalhe do log de rseserver.log |
Comando do operador | modificar rsestandardlog {on|off} | Altera dinamicamente a atualização de std*.*.log |
rsed.envvars | daemon.log | Caminho inicial para a tarefa iniciada do RSE e os logs de auditoria. |
rsed.envvars | user.log | Caminho inicial para logs do usuário. |
rsed.envvars | CGI_ISPWORK | Caminho inicial dos logs do ISPF Client Gateway |
rsed.envvars | TMPDIR | Diretório de logs do IVP |
rsed.envvars | _CEE_DMPTARG | Diretório de dumps Java |
Developer for System z, junto com o software de requisito, como o ISPF Client Gateway, também grava dados temporários no /tmp e /var/rdz/WORKAREA. A quantidade de dados gravada aqui como resultado de ações do usuário é imprevisível, portanto você deve ter um amplo espaço livre nos sistemas de arquivos que mantêm esses diretórios.
O Developer for System z sempre tenta limpar estes arquivos temporários, mas a limpeza manual, conforme documentado em "(Opcional) Limpeza de WORKAREA e /tmp" em Guia de Configuração do Host (SC23-7658), pode ser executada virtualmente a qualquer momento.
As definições na Tabela 32 controlam onde os diretórios de dados temporários estão localizados.
Local | Diretriz | Funções |
---|---|---|
rsed.envvars | CGI_ISPWORK | Caminho inicial dos dados temporários. |
rsed.envvars | TMPDIR | Diretório dos dados temporários. |
As variáveis de ambiente definidas em rsed.envvars são usadas por RSE, Java e z/OS UNIX. O arquivo de amostra que vem com o Developer for System z é destinado a instalações de pequeno e médio porte que não exigem os componentes opcionais do Developer for System z. "rsed.envvars, arquivo de configuração RSE" no Guia de Configuração do Host (SC23-7658) descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis necessitam de atenção especial:
O RSE é um aplicativo Java, que significa que ele está ativo no ambiente z/OS UNIX. Isso promove o BPXPRMxx a se tornar um membro parmlib crucial, uma vez que ele contém os parâmetros que controlam o ambiente e os sistemas de arquivos do z/OS UNIX. O BPXPRMxx é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer for System z:
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.
As definições a seguir são recomendadas a serem incluídas na placa EXEC no JCL dos servidores Developer for 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 for System z destina-se a instalações de porte médio e pequeno. "FEJJCNFG, arquivo de configuração do JES Job Monitor" no Guia de Configuração do Host (SC23-7658) descreve cada variável definida no arquivo de amostra, em que as seguintes variáveis necessitam de atenção especial:
IEASYSxx mantém parâmetros do sistema e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As diretivas a seguir são conhecidas por impactar o Developer for System z:
IVTPRMxx configura parâmetros para o Communication Storage Manager (CSM), e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As seguintes diretivas são conhecidas por impactar o Developer for System z:
Um membro parmlib ASCHPMxx contém informações de planejamento para o planejador de transação ASCH e é descrito no MVS Initialization and Tuning Reference (SA22-7592). As diretivas a seguir são conhecidas por impactar o Developer for System z:
Como as cargas de trabalho do usuário podem alterar a necessidade de recursos do sistema, o sistema deve ser monitorado regularmente para medir o uso de recursos de modo que o Rational Developer for System z e as configurações do sistema possam ser ajustadas em resposta aos requisitos do usuário. Os comandos a seguir podem ser usados para ajudar nesse processo de monitoramento.
Os conjuntos de encadeamentos RSE são o ponto focal para a atividade do usuário no Developer for System z e, assim, exigem monitoramento para o uso ideal. O daemon RSE pode ser consultado sobre informações que não podem ser reunidas com as ferramentas de monitoramento comuns do sistema.
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 30
MAXFILEPROC 83 103 64000
MAXPROCUSER 97 99 200
MAXTHREADS 9 14 1500
MAXTHREADTASKS 9 14 1500
A opção de CPU do comando de modificação DISPLAY PROCESS mostrará o uso acumulado de CPU (em milissegundos) de cada encadeamento em um conjunto de encadeamentos:
f rsed,appl=d p,cpu
BPXM023I (STCRSE)
ID do processo(33555087) ASId(002E) Nome da Tarefa (RSED8) Ordem(1)
USERID THREAD-ID TCB@ ACC_TIME TAG
STCRSE 0EDE540000000000 005E6B60 822 1/ThreadPoolProcess
STCRSE 0EDE870000000001 005E69C8 001
STCRSE 0EDE980000000002 005E6518 1814
STCRSE 0EDEBA0000000003 005E66B0 2305
STCRSE 0EDECB0000000004 005E62F8 001
STCRSE 0EDEDC0000000005 005E60D8 001
STCRSE 0EDF860000000006 005C2BF8 628 6/ThreadPoolMonitor$Memory
UsageMonitor
STCRSE 0EDF970000000007 005C2D90 003 7/ThreadPoolMonitor
IBMUSER 0EE2C70000000024 005C08B0 050 38/JESMiner
IBMUSER 0EE2B60000000026 005C0690 004 40/FAMiner
IBMUSER 0EE30B0000000027 005C0250 002 41/LuceneMiner
IBMUSER 0EE31C0000000028 005C0030 002 42/CDTParserMiner
IBMUSER 0EE32D0000000029 005BDE00 002 43/MVSLuceneMiner
IBMUSER 0EE33E000000002A 005BDBE0 002 44/CDTMVSParserMiner
A maioria dos limites z/OS UNIX que é do interesse do Developer for System z pode ser exibida usando comandos do operador. Alguns comandos mostram ainda o uso atual e a limite máximo de um limite específico. Consulte MVS System Commands (SA22-7627) para obter informações adicionais sobre esses comandos.
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 se conectando ao host, não só o Developer for System z, mas também sua infraestrutura de rede deve poder manipular a carga de trabalho. O gerenciamento de redes é um assunto amplo e bem documentado que sai do escopo da documentação do Developer for System z. Portanto, apenas os seguintes ponteiros são fornecidos.
Developer for System z usa sistemas de arquivo z/OS UNIX para armazenar vários tipos de dados, como arquivos de logs e temporários. Use o comando z/OS UNIX df para verificar quantos descritores de arquivo ainda estão disponíveis e quanto espaço livre foi deixado antes que a próxima extensão do conjunto de dados subjacente HFS ou zFS seja criada.
$ df
Mounted on Filesystem Avail/Total Files Status
/tmp (OMVS.TMP) 1393432/1396800 4294967248 Available
/u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Available
/usr/lpp/rdz (OMVS.LPP.FEK) 3062/43200 4294967147 Available
/var (OMVS.VAR) 27264/31680 4294967054 Available
A configuração de amostra a seguir mostra a configuração necessária para suportar estes requisitos:
Por padrão, o Developer for System z tenta incluir 30 usuários em um conjunto de encadeamento único. Entretanto, nossos requisitos indicam que o tempo limite de inatividade estará ativo. A Tabela 28 mostra que isso incluirá 1 encadeamento por cliente conectado. Esse encadeamento é um encadeamento de cronômetro e portanto ativo constantemente. Isso evitará que o RSE coloque 30 usuários em um único conjunto de encadeamentos, como 10+30*(17+1)=550, e maximum.threads é configurado para 520 por padrão.
Poderíamos aumentar maximum.threads, mas devido ao requisito ter uma média de 20 MB de heap Java por usuário, optamos por diminuir o maximum.clients para 25 (10+25*18 = 460). Isso nos mantém dentro do tamanho máximo padrão de heap Java de 512 MB (20*25 = 500).
Com 25 clientes por conjunto de encadeamentos e a necessidade de suportar 500 conexões, sabemos agora que precisaremos de 20 espaços de endereço de conjunto de encadeamentos.
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 + 20 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1030
x + y + z
1 + 1 + 1 = 3
5 + 2*A + N*(x + y + z) + (10 + N*0.05)
5 + 2*20 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1570
4 + 2*A
4 + 2*20 = 44
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
10 + N*(17 + x + y + z) + (20 + N*0.1)
10 + 25*(17 + 1 + 4 + 0) + (20 + 25*0.1) = 583
3 + N
3 + 500 = 503
500 + 2 = 502
Os 2 IDs do usuário extra são para STCJMON e STCRSE, os IDs do usuário de tarefa iniciada do Developer for 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 conforme documentado em Definindo Limites, podemos começar a monitorar o uso do recurso pelo Developer for System z para ver se o ajuste de algumas variáveis é necessário. O Figura 25 mostra o uso de recurso após 499 usuários terem efetuado logon. (O exemplo na figura apenas mostra a criação do logon. Nenhuma ação do usuário é indicada no exemplo).
F RSED,APPL=D P
BPXM023I (STCRSE)
ProcessId(83886168) Memory Usage(17%) Clients(25) Order(1)
ProcessId(91 ) Memory Usage(17%) Clients(25) Order(2)
ProcessId(122 ) Memory Usage(17%) Clients(25) Order(3)
ProcessId(16777348) Memory Usage(17%) Clients(25) Order(4)
ProcessId(16777358) Memory Usage(17%) Clients(25) Order(5)
ProcessId(16777368) Memory Usage(17%) Clients(25) Order(6)
ProcessId(16777378) Memory Usage(17%) Clients(25) Order(7)
ProcessId(16777388) Memory Usage(17%) Clients(25) Order(8)
ProcessId(16777398) Memory Usage(17%) Clients(25) Order(9)
ProcessId(33554622) Memory Usage(17%) Clients(25) Order(10)
ProcessId(16777416) Memory Usage(17%) Clients(25) Order(11)
ProcessId(16777426) Memory Usage(17%) Clients(25) Order(12)
ProcessId(16777436) Memory Usage(9%) Clients(25) Order(13)
ProcessId(16777446) Memory Usage(17%) Clients(25) Order(14)
ProcessId(16777456) Memory Usage(17%) Clients(25) Order(15)
ProcessId(16777466) Memory Usage(17%) Clients(25) Order(16)
ProcessId(16777476) Memory Usage(17%) Clients(25) Order(17)
ProcessId(16777487) Memory Usage(17%) Clients(25) Order(18)
ProcessId(16777497) Memory Usage(17%) Clients(25) Order(19)
ProcessId(16777507) Memory Usage(16%) Clients(24) Order(20)
F RSED,APPL=D P,D
BPXM023I (STCRSE)
ProcessId(83886168) ASId(0022) JobName(RSED857 ) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 17 17 100
CLIENTS 25 25 25
MAXFILEPROC 365 366 64000
MAXPROCUSER 44 44 80
MAXTHREADS 310 311 1500
MAXTHREADTASKS 311 311 1500
TASID
Nome Tarefa Tempo de CPU Armazen. EXCP
-------- ----------- ------- ----------
JMON 0.00 1780 73
RSED 5.88 95.2M 41958
RSED1 8.26 190.1M 58669
RSED1 8.17 187.0M 58605
RSED2 8.06 185.3M 58653
RSED2 8.19 183.1M 60209
RSED3 8.12 189.1M 58650
RSED3 8.03 186.7M 58590
RSED4 8.15 188.2M 58646
RSED4 5.50 182.5M 58585
RSED5 7.72 184.4M 58631
RSED5 7.82 184.1M 58576
RSED6 7.14 184.1M 58622
RSED6 6.27 186.9M 58583
RSED7 5.17 185.1M 58804
RSED7 6.57 185.2M 58621
RSED7 5.86 182.8M 58565
RSED8 0.36 1560 2459
RSED8 7.94 184.1M 58615
RSED8 7.45 181.8M 58548
RSED9 8.16 190.6M 58802
RSED9 7.62 183.8M 58610
RSED9 7.36 177.7M 57478
O z/OS é um sistema operacional altamente customizável, e (algumas vezes pequenas) alterações no sistema podem ter um grande impacto sobre o desempenho geral. Este capítulo destaca algumas alterações que podem ser feitas para aprimorar o desempenho do Developer for System z.
Consulte MVS Initialization and Tuning Guide (SA22-7591) e UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre o ajuste do sistema.
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 for System z possui um padrão de arquivo de configuração STEPLIB=NONE codificado em rsed.envvars, conforme descrito em rsed.envvars. Pelas razões mencionadas anteriormente, não altere essa diretiva e coloque os conjuntos de dados de destino em LINKLIST ou LPA (Link Pack Area).
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.
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 anteriores são amostras de possíveis candidatos de LPA, mas as necessidades no seu site podem variar. Consulte Language Environment Customization (SA22-7564) para obter informações sobre a colocação de outros módulos de carregamento do LE na LPA dinâmica. Consulte UNIX System Services Planning (GA22-7800) para obter informações adicionais sobre a colocação de módulos de carregamento do compilador C/C++ em um LPA dinâmico.
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 for System z pode ser equilibrado pela configuração das metas corretas para os processos. Algumas diretrizes gerais são listadas abaixo:
Consulte o MVS Planning Workload Management (SA22-7602) para obter mais informações sobre esse assunto.
Com um heap de tamanho fixo, nenhuma expansão ou contração de heap ocorre e isso pode ocasionar significantes ganhos de desempenho em algumas situações. No entanto, a utilização de um heap de tamanho fixo geralmente não é uma boa ideia, porque atrasa o início de uma coleta de lixo até que o heap esteja cheio, momento em que será uma tarefa principal. Também aumenta o risco de fragmentação, o que requer uma compactação de heap. Portanto, utilize heaps de tamanho fixo só depois de desempenhar teste adequado ou quando orientado pelo IBM Support Center. Consulte Java Diagnostics Guide (SC34-6650) para obter informações adicionais sobre tamanhos de heap e coleta de lixo.
O tamanho de heap inicial e máximo de um z/OS Java Virtual Machine (JVM) pode ser configurado com as opções da linha de comandos Java, -Xms (inicial) e -Xmx (máximo).
No Developer for System z, as opções de linha de comandos Java são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars, conforme descrito em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
A opção -Xquickstart pode ser usada para melhorar o tempo de inicialização de alguns aplicativos Java. -Xquickstart faz com que o compilador Just In Time (JIT) seja executado com um subconjunto de otimizações, ou seja, uma compilação rápida. Essa compilação rápida permite melhorar o tempo de inicialização.
A opção -Xquickstart é apropriada para aplicativos de execução mais curta, principalmente aqueles em que o tempo de execução não está concentrado em um número pequeno de métodos. -Xquickstart pode prejudicar o desempenho ser for usada em aplicativos de longa execução que contêm métodos ativos.
Para ativar a opção -Xquickstart para o servidor RSE, inclua a seguinte diretiva no final de rsed.envvars:
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
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. Alguns deles são mostrados no exemplo a seguir ($ é o prompt do z/OS UNIX). Consulte o Java SDK and Runtime Environment User Guide para obter uma visão geral completa das opções de linha de comandos suportadas.
$ java -Xshareclasses:listAllCaches
Shared Cache OS shmid in use Last detach time
RSE 401412 0 Mon Jun 18 17:23:16 2007
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,printStats
Current statistics for cache "RSE":
base address = 0x0F300058
end address = 0x0F8FFFF8
allocation pointer = 0x0F4D2E28
cache size = 6291368
free bytes = 4355696
ROMClass bytes = 1912272
Metadata bytes = 23400
Metadata % used = 1%
# ROMClasses = 475
# Classpaths = 4
# URLs = 0
# Tokens = 0
# Stale classes = 0
% Stale classes = 0%
Cache is 30% full
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,destroy
JVMSHRC010I Shared Cache "RSE" is destroyed
Could not create the Java virtual machine.
Push-to-client, ou controle de cliente baseado em host, suporta gerenciamento central das seguintes coisas:
Os seguintes tópicos são abordados neste capítulo:
Os clientes do Developer for System z versão 8.0.1 e superior podem extrair arquivos de configuração do cliente e informações de atualização do produto do host quando eles se conectam, assegurando que todos os clientes tenham configurações comuns e estejam atualizados.
Desde a versão 8.0.3, o administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar as necessidades de diferentes grupos de desenvolvedores. Isso permite que os usuários recebam uma configuração customizada, com base em critérios como associação de um grupo LDAP ou permissão para um perfil de segurança.
Os projetos do z/OS podem ser definidos individualmente por meio da perspectiva Projetos do z/OS no cliente, ou podem ser definidos centralmente no host e propagados para o cliente em uma base por usuário individual. Esses "projetos baseados em host" se parecem e funcionam exatamente como projetos definidos no cliente, exceto que sua estrutura, seus membros e suas propriedades não podem ser modificados pelo cliente e só podem ser acessados quando conectados ao host.
pushtoclient.properties informa ao cliente se essas funções estão ativadas e onde os dados relacionados são armazenados. Consulte "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094) para obter mais informações.
Normalmente, os sistemas z/OS, as estações de trabalho do desenvolvedor e os projetos de desenvolvimento são gerenciados por diferentes grupos de pessoas. O design push-to-client segue esse princípio e designa responsabilidades específicas a cada grupo:
Consulte o Centro de Informações do Developer for System z (http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp) para obter detalhes sobre como o administrador de cliente e o gerente de projeto de desenvolvimento podem executar as tarefas designadas a eles.
Ao ativar o suporte de configuração ou controle de versão para diversos grupos de desenvolvedor, uma equipe adicional será envolvida no gerenciamento de push-to-client. Qual é essa equipe depende da opção escolhida para identificar os grupos aos quais um desenvolvedor pertence:
O push-to-client é designado para armazenar dados específicos do sistema por sistema, enquanto mantém dados comuns (globais) em um único sistema (o sistema primário) para reduzir o esforço de gerenciamento. O sistema primário é identificado pela diretiva primary.system em pushtoclient.properties. O padrão é false.
Certifique-se de ter um, e apenas um, sistema definido como primário. Os administradores de cliente do Developer for System z não podem exportar dados de configuração globais, a menos que o sistema de destino seja um sistema primário. Os clientes do Developer for System z podem mostrar comportamento incorreto ao conectar-se a diversos sistemas primários com configurações fora de sincronização.
A regra somente um não se aplica quando diversos sistemas compartilham a configuração (/etc/rdz) e os metadados push-to-client (/var/rdz/pushtoclient) do Developer for System z. Como a configuração é compartilhada, todos os sistemas envolvidos são identificados como sistema primário. Mas, desde que todos os sistemas também compartilhem os metadados, essa duplicação não é um problema.
A diretiva pushtoclient.folder em pushtoclient.properties identifica o diretório base no qual os metadados push-to-client são armazenados. O padrão é /var/rdz/pushtoclient.
O diretório base contém o arquivo de configuração push-to-client raiz, keymapping.xml. Todos os demais metadados estão em subdiretórios.
Em sua maioria, os subdiretórios são criados dinamicamente quando o administrador de cliente exporta a configuração da área de trabalho push-to-client. Esses subdiretórios agrupam os metadados por assunto, como mapeamentos e referências. Quanto mais componentes do cliente do Developer for System z se tornam elegíveis para serem gerenciados por push-to-client, mais subdiretórios são criados dinamicamente. Consulte o assistente de exportação no cliente do Developer for System z (Arquivo > Exportar... > Rational Developer for System z > Arquivos de Configuração) para saber o que é armazenado nesses subdiretórios.
Alguns subdiretórios são criados durante a customização do host inicial. Esses subdiretórios contêm dados que são mantidos manualmente pelo administrador de cliente ou pelo gerente de projeto de desenvolvimento.
Consulte "Configuração de Customização" no capítulo "Customização Básica" do Guia de Configuração do Host (S517-9094) para obter mais informações sobre como a criação desses subdiretórios.
Por padrão (consulte a diretiva file.permission em pushtoclient.properties), todos os arquivos e diretórios criados no diretório base recebem a máscara de bits de permissão 775 (rwxrwxr-x), que permite ao proprietário e ao grupo padrão do proprietário acesso de leitura e gravação à estrutura de diretório e aos arquivos contidos nela. Qualquer outra pessoa só tem acesso de leitura à estrutura de diretório e aos arquivos contidos nela.
É importante que o UID (ID do usuário) e o GID (ID do grupo) corretos do proprietário sejam configurados para esses diretórios antes de iniciar a configuração push-to-client.
Os seguintes comandos de amostra do RACF criam um novo grupo (RDZADMIN), designa a ele um GID exclusivo (2) e o torna o grupo padrão para o ID de usuário RDZADM1, que também recebe um UID exclusivo (6).
ADDGROUP RDZADMIN OWNER(IBMUSER) SUPGROUP(SYS1) -
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT ADMIN')
ALTGROUP RDZADMIN OMVS(GID(2))
CONNECT RDZADM1 GROUP(RDZADMIN) AUTH(USE)
ALTUSER RDZADM1 DFLTGRP(RDZADMIN) OMVS(UID(6))
O seguinte comando chown de amostra do z/OS UNIX altera o proprietário e o grupo de /var/rdz/pushtoclient e de tudo que ele contém para RDZADM1 e RDZADMIN, respectivamente. O comando deve ser executado por um superusuário (UID 0) para evitar problemas de permissão.
chown -R rdzadm1:rdzadmin /var/rdz/pushtoclient
O seguinte comando chmod de amostra do z/OS UNIX altera a máscara de bits de permissão de /var/rdz/pushtoclient e de tudo que ela contém para 775. Execute-o para assegurar-se de que toda adição manual ao diretório siga a lógica usada pelo Developer for System z. O comando deve ser executado por um superusuário (UID 0) para evitar problemas de permissão.
chmod -R 775 /var/rdz/pushtoclient
Consulte o Security Server RACF Command Language Reference (SA22-7687) para obter mais informações sobre os comandos de amostra do RACF. Consulte o UNIX System Services Command Reference (SA22-7802) para obter mais informações sobre os comandos de amostra do z/OS UNIX. Consulte a seção Estrutura de diretório do z/OS UNIX para obter mais informações.
Os metadados push-to-client usam uma quantidade razoavelmente pequena de espaço em disco no z/OS UNIX, porque a grande massa dos metadados são arquivos XML codificados para UTF-8. Observe que o código do produto usado nos cenários de atualização de cliente podem ser armazenados em qualquer lugar da rede; não é necessário armazenar no z/OS UNIX, porque os metadados push-to-client relacionados (chamados arquivos de resposta) apontam o cliente para o local correto.
Quando um cliente do Developer for System z (versão 8.0.1 e superior) se conecta ao host, ele lê as definições em pushtoclient.properties. Se a diretiva config.enabled estiver ativada, o cliente comparará sua configuração atual com as definições nos metadados push-to-client. Se forem encontradas diferenças, o cliente iniciará um assistente que extrai os dados necessários e ativa a configuração conforme indicado pelo push-to-client.
A diretiva reject.config.updates em pushtoclient.properties controla se um usuário tem permissão para rejeitar as atualizações de configuração que o push-to-client está prestes a entregar.
Um cliente do Developer for System z (versão 8.0.1 e superior) tem um assistente, a ser usado pelo administrador de cliente, que pode exportar a configuração atual, que por sua vez é importada por todos os clientes do Developer for System z através do push-to-client. Observe que essa função está disponível em todos os clientes; por isso, você deve assegurar que apenas os administradores de cliente tenham permissão de gravação nos diretórios do z/OS UNIX que contêm metadados push-to-client (/var/rdz/pushtoclient).
A versão 8.0.3 ou superior é necessária ao cliente e ao host para ativar o suporte de grupo, conforme documentado em Diversos Grupos de Desenvolvedores.
Quando um cliente do Developer for System z (versão 8.0.1 e superior) se conecta ao host, ele lê as definições em pushtoclient.properties. Se a diretiva product.enabled estiver ativada, o cliente comparará sua versão de produto atual com as definições nos metadados push-to-client. Se forem encontradas diferenças, o cliente iniciará um assistente que extrai os dados necessários e ativa a configuração conforme indicado pelo push-to-client.
A diretiva reject.product.updates em pushtoclient.properties controla se um usuário tem permissão para rejeitar atualizações de produto que o push-to-client está prestes a entregar.
A versão 8.0.3 ou superior é necessária ao cliente e ao host para ativar o suporte de grupo, conforme documentado em Diversos Grupos de Desenvolvedores.
Desde a versão 8.0.3, o administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar as necessidades de diferentes grupos de desenvolvedores. Isso permite que os usuários recebam uma configuração customizada, com base em critérios como associação de um grupo LDAP ou permissão para um perfil de segurança.
O suporte para diversos grupos de desenvolvedores, cada um com seus próprios requisitos de configuração e atualização do cliente, é ativado ao designar o valor desejado às diretivas relacionadas (config.enabled e product.enabled) em pushtoclient.properties, conforme mostrado na Tabela 33.
Valor *.enabled | Função ativada | Diversos grupos suportados |
---|---|---|
False | Não | Não |
True | Sim | Não |
LDAP | Sim | Sim, com base na associação de grupos LDAP FEK.PTC.*.ENABLED.sysname.devgroup |
SAF | Sim | Sim, com base na permissão para perfis de segurança FEK.PTC.*.ENABLED.sysname.devgroup |
Observe que quando a função está ativada (isso inclui o valor TRUE), os desenvolvedores sempre fazem parte de um grupo padrão. Um desenvolvedor pode fazer parte de nenhum, um ou vários grupos adicionais.
A rejeição das atualizações também pode ser feita condicionalmente, conforme mostrado na Tabela 34.
Valor reject.*.updates | Função ativada |
---|---|
False | Não |
True | Sim |
LDAP | Depende da associação do grupo LDAP FEK.PTC.REJECT.*.UPDATES.sysname |
SAF | Depende da permissão para o perfil de segurança FEK.PTC.REJECT.*.UPDATES.sysname |
Observe que as diretivas em pushtoclient.properties funcionam independentemente umas das outras. Você pode designar qualquer valor suportado a qualquer diretiva. Não há requisito para manter as configurações semelhantes.
Consulte Seleção de Grupo Baseada em LDAP e Seleção de Grupo Baseada em SAF para obter detalhes sobre a configuração necessária para a respectiva função. Consulte "(Opcional) pushtoclient.properties, Controle de Cliente Baseado em Host" no Guia de Configuração do Host (S517-9094) para obter mais informações sobre como ativar o suporte a diversos grupos.
Quando a função *.enabled está ativada (isso inclui o valor TRUE) em pushtoclient.properties, os desenvolvedores sempre fazem parte de um grupo padrão para a função relacionada. Um desenvolvedor pode fazer parte de nenhum, um ou vários grupos adicionais.
Para limitar a complexidade de aplicar mudanças definidas em vários grupos, o Developer for System z limita as definições que serão usadas, como base em uma seleção feita pelo usuário.
Grupos adicionais | Definições usadas |
---|---|
Nenhum | Padrão |
Um | Padrão ou (padrão + grupo) |
Diversos | Padrão ou (padrão + 1 grupo) |
O Developer for System z usa a seguinte lógica ao construir e aplicar o conjunto de mudanças:
Embora um desenvolvedor possa fazer parte de diversos grupos simultaneamente, a área de trabalho ativa do desenvolvedor não pode. A área de trabalho ativa deve estar ligada a um grupo específico (que pode ser o grupo padrão) para receber atualizações de configuração ou do produto. Uma vez feita a ligação, ela não pode ser desfeita. Uma nova área de trabalho deverá ser criada se uma nova ligação de grupo for necessária.
Quando uma área de trabalho que não tem ligação de grupo se conecta ao host, e config.enabled (ou product.enabled) indica que a função de push-to-client está ativa, o Developer for System z consulta todos os grupos para determinar a quais grupos o usuário pertence e solicita que o usuário selecione um grupo para a função relacionada. Nas conexões sucessivas, somente o grupo selecionado é consultado para ver se a associação ao grupo ainda é válida.
As diretivas reject.*.updates não funcionam com diversos grupos; por isso, a configuração deles é mais simples e não requer ligação da área de trabalho. Quando uma atualização está presente, o Developer for System z determina se o usuário tem permissão para rejeitar a atualização, e age apropriadamente.
Conforme documentado em Local de Metadados, todos os metadados push-to-client são armazenados em uma estrutura de diretório na parte superior de /var/rdz/pushtoclient/ ao usar uma configuração sem o suporte de grupo. O mesmo layout de dados é mantido quando o suporte de grupo é ativado, mas com uma pequena diferença de interpretação, do diretório base, /var/rdz/pushtoclient/:
A customização do produto inicial cria o diretório grouping/ em /var/rdz/pushtoclient/. O administrador de cliente é responsável por incluir os diretórios <devgroup>/ em /var/rdz/pushtoclient/grouping/.
Observe que durante a customização inicial do produto, os diretórios projects/, install/ e install/responsefiles/ são criados em /var/rdz/pushtoclient/. O administrador do cliente deverá repetir essas ações make-directory em /var/rdz/pushtoclient/grouping/<devgroup>/ se houver necessidade de cenários de upgrade de produto de grupo específico ou projetos baseados em host de grupo específico.
A seguinte sequência de comandos de amostra do z/OS UNIX cria os subdiretórios com a máscara de bits de permissão correta. Os comandos devem ser executados pelo administrador de cliente para evitar problemas de propriedade.
saved_umask=$(umask)
umask 0000
cd /var/rdz/pushtoclient/grouping/
mkdir -m775 <devgroup>
cd <devgroup>
mkdir -m775 install
mkdir -m775 install/responsefiles
mkdir -m775 projects
umask $saved_umask
Consulte o UNIX System Services Command Reference (SA22-7802) para obter mais informações sobre os comandos de amostra do z/OS UNIX.
A configuração do suporte para diversos grupos de desenvolvedores requer uma coordenação entre o programador de sistema do z/OS, o administrador de cliente e o administrador que gerencia os critérios de seleção (o administrador de LDAP ou segurança). Na seguinte descrição do fluxo de trabalho, o administrador de segurança gerencia os critérios de seleção:
/var/rdz/pushtoclient/grouping/<devgroup>
para cada grupo push-to-client.
Embora o protocolo LDAP seja o nome de um protocolo baseado em TCP/IP, ele é comumente usado para descrever um conjunto de serviços de diretório distribuídos. Como um banco de dados, um diretório é uma coleção estruturada de registros. O Developer for System z pode usar um servidor LDAP como um banco de dados hierárquico simples, no qual os grupos contêm um ou mais membros.
Ao usar definições no servidor LDAP como mecanismo de seleção (o valor LDAP é especificado para diretivas em pushtoclient.properties), o Developer for System z verifica a associação dos nomes de grupo listados na Tabela 36 para determinar a quais grupos de desenvolvedores o usuário pertence, e se um usuário tem permissão para rejeitar atualizações.
Nome do grupo (cn=) | Resultado |
---|---|
FEK.PTC.CONFIG.ENABLED.sysname.devgroup | O cliente aceita atualizações de configuração para o grupo especificado |
FEK.PTC.PRODUCT.ENABLED.sysname.devgroup | O cliente aceita atualizações de produto para o grupo especificado |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname | O usuário pode rejeitar atualizações de configuração |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname | O usuário pode rejeitar atualizações de produto |
O valor devgroup corresponde ao nome do grupo designado a um grupo específico de desenvolvedores. Observe que o nome do grupo é visível nos clientes do Developer for System z.
O valor sysname corresponde ao nome do sistema de destino.
O esquema LDAP deve satisfazer às seguintes regras:
A Figura 26 é uma definição LDAP de amostra para um grupo e usuário, expressa em formato LDIF.
# Group Definition
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA,o=PTC,c=DeveloperForZ
objectClass: groupOfUniqueNames
objectClass: top
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA
description: Project A
uniqueMember: uid=mborn,ou=Users,dc=example,dc=com
# User Definition
dn: uid=mborn,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: top
cn: May Born
sn: Born
uid: mborn
facsimiletelephonenumber: +1 800 982 6883
givenname: May
mail: mborn@example.com
ou: Users
Há uma ampla seleção de servidores LDAP comerciais e grátis disponíveis. Um exemplo é o IBM Tivoli Directory Server (http://www-01.ibm.com/software/tivoli/products/directory-server/). Há também um ampla seleção de ferramentas de linha de comandos e baseadas na GUI para gerenciar um servidor LDAP.
Conforme mencionado em Esquema LDAP, cada usuário deve ser definido para o servidor LDAP. Para reduzir o esforço de gerenciamento, é melhor colocar o esquema push-to-client em um servidor LDAP que já tenha acesso a todas as definições de usuário. Por exemplo, você pode usar o IBM Tivoli Directory Server ativo no z/OS usando um banco de dados SDBM (que é um wrapper para seu banco de dados de segurança).
Dependendo das políticas do site, o esquema push-to-client no servidor LDAP pode ser gerenciado pelo administrador de cliente. Esse acordo reduz as necessidades de colaboração, bem como possíveis atrasos e erros de comunicação.
Um argumento em favor do gerenciamento LDAP pelo administrador de cliente é que o esquema push-to-client não contém nada que seja confidencial ou esteja relacionado a segurança. Quando definições de usuário estão disponíveis ao servidor LDAP através de outros esquemas, os objetos LDAP do Developer for System z apenas determinam quais opções um desenvolvedor tem na seleção de um layout de área de trabalho e upgrades automáticos de produtos do cliente do Developer for System z.
Qualquer servidor de banco de dados que suporte o protocolo LDAP pode ser usado para hospedar o esquema push-to-client do Developer for System z. Portanto, o Developer for System z permite que você especifique as informações necessárias para conectar-se ao servidor LDAP. Também é possível especificar o sufixo que torna o banco de dados exclusivo no servidor LDAP.
rsed.envvars directive | Padrão |
---|---|
_RSE_LDAP_SERVER | Sistema de host local |
_RSE_LDAP_PORT | 389 |
_RSE_LDAP_PTC_GROUP_SUFFIX | "O=PTC,C=DeveloperForZ" |
Observe que medidas de segurança de TCP/IP, como firewalls, podem fazer com que o servidor RSE (baseado em host) pare de entrar em contato com o servidor LDAP. Para assegurar-se de que o servidor LDAP possa ser atingido, entre em contato com o administrador de TCP/IP com as seguintes informações:
Suponha que uma empresa tenha o Developer for System z ativo no sistema CDFMVS08. O IBM Tivoli Directory Server, também ativo no CDFMVS08, é usado como servidor LDAP. O servidor LDAP é configurado conforme descrito em Incluindo Backend push-to-client no LDAP.
Os seguintes usuários utilizam o Developer for System z:
Cada grupo de desenvolvedores requer arquivos de configuração de cliente específicos, e todos os desenvolvedores estão sujeitos ao mesmo controle de versão de cliente. Ao contrário dos administradores de cliente, os desenvolvedores não têm permissão para rejeitar nenhuma mudança que o push-to-client apresente.
Os administradores de cliente e de LDAP concordam em usar os nomes de grupo BANKING e INSURANCE para atualizações de configuração.
Neste exemplo, são feitas atualizações no IBM Tivoli Directory Server no z/OS, atualmente usando apenas um banco de dados SDBM (wrapper de banco de dados de segurança), incluindo um banco de dados LDBM (arquivos do z/OS UNIX) para hospedar o esquema push-to-client.
# filename ds.conf
# restart GLDSRV started task to pick up changes
# global section
adminDN "cn=LDAP admin"
adminPW password
listen ldap://:389
schemaPath /etc/ldap
# SDBM back-end section (RACF)
database SDBM GLDBSD31/GLDBSD64
suffix "cn=RACF,o=IBM,c=US"
# LDBM back-end section (z/OS UNIX files)
database LDBM GLDBLD31/GLDBLD64 LDBM-RDZ
suffix "o=PTC,c=DeveloperForZ"
databaseDirectory /var/ldap/ldbm/rdz
mkdir -p /var/ldap/ldbm/rdz
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.user.ldif
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.IBM.ldif
ldapadd -D "cn=LDAP admin" -w password -f
/u/ibmuser/ptc_root.ldif
em que /u/ibmuser/ptc_root.ldif
contém o seguinte:
dn: o=PTC,c=DeveloperForZ
objectclass: top
objectclass: organization
o: PTC
Inclua os diferentes objetos de grupo LDAP no esquema e torne o administrador de cliente parte de cada um deles. A definição de usuário para o ID do usuário RDZADM1 é extraída do esquema RACF.
ldapadd -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_setup.ldif
em que /u/ibmuser/ptc_setup.ldif contém o seguinte:
# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject configuration updates
dn: cn=FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject product updates
dn: cn=FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
Inclua os desenvolvedores nos objetos de grupos LDAP. As definições do usuário para IDs de usuário são obtidas do esquema RACF.
ldapmodify -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_add.ldif
em que /u/ibmuser/ptc_add.ldif retém o seguinte:
# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=BNK010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK014,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=INS010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS014,profileType=user,cn=RACF,o=IBM,c=US
# BANKING e INSURANCE têm necessidades de configuração diferentes
config.enabled=LDAP
# todos recebem atualizações do produto
product.enabled=TRUE
# somente RDZADMIN pode rejeitar atualizações de configuração
reject.config.updates=LDAP
# somente RDZADMIN pode rejeitar atualizações de produto
reject.product.updates=LDAP
Nenhuma atualização é necessária porque os padrões são usados:
Ao exportar a configuração da área de trabalho para os grupos BANKING e INSURANCE, o assistente de exportação cria os diretórios /var/rdz/pushtoclient/grouping/<devgroup>/, bem como a estrutura de diretório por trás dele.
Como não há cenários de upgrade de produto individualizado, o administrador de cliente não precisa criar ou atualizar os subdiretórios install/ e install/responsefiles/ no /var/rdz/pushtoclient/grouping/<devgroup>.
O administrador de cliente deve criar os arquivos de resposta necessários para atualizações do produto no diretório de grupo padrão, /var/rdz/pushtoclient/install/responsefiles/.
SAF (Security Access Facility) é uma interface para acessar qualquer produto de segurança do z/OS. O Developer for System z pode usar essa interface para consultar o produto de segurança e recuperar informações relacionadas a push-to-client.
Ao usar as definições do banco de dados de segurança como mecanismo de seleção (o valor SAF é especificado para diretivas em pushtoclient.properties), o Developer for System z verifica as permissões de acesso aos perfis listados na Tabela 37 para determinar a quais grupos de desenvolvedores o usuário pertence, e se um usuário tem permissão para rejeitar atualizações.
Perfil FACILITY | Compri
mento fixo |
Acesso Neces
sário |
Resultado |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. sysname.devgroup |
23 | READ | O cliente aceita atualizações de configuração para o grupo especificado |
FEK.PTC.PRODUCT.ENABLED. sysname.devgroup |
24 | READ | O cliente aceita atualizações de produto para o grupo especificado |
FEK.PTC.REJECT.CONFIG. UPDATES.sysname |
30 | READ | O usuário pode rejeitar atualizações de configuração |
FEK.PTC.REJECT.PRODUCT. UPDATES.sysname |
31 | READ | O usuário pode rejeitar atualizações de produto |
O valor devgroup corresponde ao nome do grupo designado a um grupo específico de desenvolvedores. Observe que o nome do grupo é visível nos clientes do Developer for System z.
O valor sysname corresponde ao nome do sistema de destino.
A coluna "Comprimento fixo" documenta o comprimento da parte fixa do perfil de segurança relacionado.
Por padrão, o Desenvolvedor para System z espera que os perfis FEK.* estejam na classe de segurança FACILITY. Observe que os perfis na classe FACILITY estão limitados a 39 caracteres. Se a soma do comprimento da parte de perfil fixo (FEK.PTC.<key>.) e o comprimento da parte de perfil específico do site (sysname ou sysname.devgroup) exceder esse número, você poderá colocar os perfis em outra classe e instruir o Developer for System z a usar essa classe no lugar. Para fazer isso, remova o comentário da linha _RSE_FEK_SAF_CLASS em rsed.envvars e forneça o nome de classe desejado.
Suponha que uma empresa tenha o Developer for System z ativo no sistema CDFMVS08. O banco de dados de segurança RACF é compartilhado entre diversos sistemas e os grupos a seguir são definidos no banco de dados de segurança:
Cada grupo de desenvolvedores requer arquivos de configuração de cliente específicos, e todos os desenvolvedores estão sujeitos ao mesmo controle de versão de cliente. Ao contrário dos administradores de cliente, os desenvolvedores não têm permissão para rejeitar nenhuma mudança que o push-to-client apresente. A regra de rejeição é válida para todos os sistemas, em preparação para expansão futura.
Os administradores de cliente e de segurança concordam em usar os nomes de grupo de push-to-client, BANKING e INSURANCE, para atualizações de configuração.
# permitir que RDZADMIN e DEVBANK selecionem o grupo de push-to-client BANKING
RDEFINE FACILITY (FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING CLASS(FACILITY) -
ID(RDZADMIN DEVBANK) ACCESS(READ)
# permitir que RDZADMIN e DEVINSUR selecione o grupo de push-to-client INSURANCE
RDEFINE FACILITY (FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE CLASS(FACILITY) -
ID(RDZADMIN DEVINSUR) ACCESS(READ)
# RDZADMIN pode rejeitar atualizações de configuração em qualquer sistema
RDEFINE FACILITY (FEK.PTC.REJECT.CONFIG.UPDATES.*) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.* CLASS(FACILITY) -
ID(RDZADMIN) ACCESS(READ)
# RDZADMIN pode rejeitar atualizações de produto em qualquer sistema
RDEFINE FACILITY (FEK.PTC.REJECT.PRODUCT.UPDATES.*) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.* CLASS(FACILITY) -
ID(RDZADMIN) ACCESS(READ)
# ativar mudanças
SETROPTS RACLIST(FACILITY) REFRESH
# BANKING e INSURANCE têm necessidades de configuração diferentes
config.enabled=SAF
# todos recebem atualizações do produto
product.enabled=TRUE
# somente RDZADMIN pode rejeitar atualizações de configuração
reject.config.updates=SAF
# somente RDZADMIN pode rejeitar atualizações de produto
reject.product.updates=SAF
Nenhuma atualização é necessária porque os padrões são usados:
_RSE_FEK_SAF_CLASS=FACILITY
Ao exportar a configuração da área de trabalho para os grupos BANKING e INSURANCE, o assistente de exportação cria os diretórios /var/rdz/pushtoclient/grouping/<devgroup>/, bem como a estrutura de diretório por trás dele.
Como não há cenários de upgrade de produto individualizado, o administrador de cliente não precisa criar ou atualizar os subdiretórios install/ e install/responsefiles/ no /var/rdz/pushtoclient/grouping/<devgroup>/.
O administrador de cliente deve criar os arquivos de resposta necessários para atualizações do produto no diretório de grupo padrão, /var/rdz/pushtoclient/install/responsefiles/.
Suponha que enquanto a configuração de amostra está ativa, um fix pack do Developer for System z com correções importantes se torne disponível, mas o cronograma de um projeto financeiro faz com que vários desenvolvedores estejam muito ocupados para alterar qualquer coisa em suas estações de trabalho imediatamente.
Para resolver o problema, o administrador de segurança pode conceder a todos os desenvolvedores DEVBANK um período de carência durante o qual eles podem optar por adiar (rejeitar) a atualização.
Configurar o período de carência é um processo muito simples:
# start of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.* CLASS(FACILITY) -
ID(DEVBANK) ACCESS(READ)
# ativar mudanças
SETROPTS RACLIST(FACILITY) REFRESH
Ao final do período de carência, a autoridade adicional pode ser removida novamente:
# end of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.* CLASS(FACILITY) -
ID(DEVBANK) DELETE
# ativar mudanças
SETROPTS RACLIST(FACILITY) REFRESH
Os projetos do z/OS podem ser definidos individualmente por meio da perspectiva Projetos do z/OS no cliente, ou podem ser definidos centralmente no host e propagados para o cliente em uma base por usuário individual. Esses "projetos baseados em host" se parecem e funcionam exatamente como os projetos definidos no cliente, exceto que sua estrutura, seus membros e suas propriedades não podem ser modificados pelo cliente e só podem ser acessados quando conectados ao host.
O diretório base para projetos baseados em host é definido (pelo administrador do cliente) em /var/rdz/pushtoclient/keymapping.xml, e é /var/rdz/pushtoclient/projects por padrão.
Para configurar projetos baseados em host, o gerente de projeto ou o desenvolvedor líder precisa definir os seguintes tipos de arquivos de configuração. Todos os arquivos são XML codificados para UTF-8.
Os projetos baseados em host também são elegíveis para participar da configuração de diversos grupos discutida em Diversos Grupos de Desenvolvedores. Essa elegibilidade significa que os projetos baseados em host podem ser definidos também em /var/rdz/pushtoclient/grouping/<devgroup>/projects/.
Quando uma área de trabalho está ligada a um grupo específico, e há definições de projeto para um usuário nesse grupo e no grupo padrão, o usuário recebe as definições do projeto dos grupos padrão e específico.
Tradicionalmente, a função de definição de recursos para o CICS tem sido o domínio do administrador do CICS. Há uma resistência em permitir que o desenvolvedor de aplicativos defina recursos do CICS por vários motivos:
Developer for System z aborda esses problemas permitindo que os administradores do CICS controlem padrões de definição de recurso do CICS e controlem as propriedades de exibição de um parâmetro de definição de recurso do CICS por meio do servidor CICS Resource Definition (CRD), que é parte do Application Deployment Manager.
Por exemplo, o administrador do CICS pode fornecer certos parâmetros de definição de recurso do CICS que podem não ser atualizados pelo desenvolvedor de aplicativos. Outros parâmetros de definição de recurso do CICS podem ser atualizados, com ou sem os padrões fornecidos, ou o parâmetro de definição de recurso do CICS pode ser ocultado para evitar uma complexidade desnecessária.
Quando o desenvolvedor de aplicativos estiver satisfeito com as definições de recursos do CICS, elas poderão ser instaladas imediatamente no ambiente de teste do CICS em execução, ou poderão ser exportadas em um manifesto para edição e aprovação adicionais por um administrador do CICS. O administrador do CICS pode utilizar o administrative utility (utilitário em lote) ou a ferramenta Processamento de Manifesto para implementar as alterações de definição de recurso.
Consulte "(Opcional) Gerenciador de Implementação do Aplicativo" no Guia de Configuração do Host (SC23-7658) para obter mais informações sobre as tarefas necessárias para configurar o Application Deployment Manager em seu sistema host.
Customizar o Application Deployment Manager inclui os serviços a seguir no Developer for System z:
O servidor CICS Resource Definition (CRD) do Application Deployment Manager consiste no próprio servidor CRD, um repositório CRD, definições do recurso CICS associadas e, ao usar a interface de Serviço da Web, arquivos de ligação de Serviço da Web e um manipulador de mensagens do pipeline de amostra. O servidor CRD deve executar em uma Web Owning Region (WOR), que é mencionada na documentação do Developer for System z como a região de conexão primária do CICS.
Consulte o Centro de Informações do Developer for System z (http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp) para aprender mais sobre os serviços do Aplication Deployment Manager disponíveis na liberação atual do Developer for System z.
O CICS Transaction Server fornece na versão 4.1 e posterior suporte para uma interface HTTP projetada usando princípios do Representational State Transfer (RESTful). Essa interface RESTful é agora a interface CICSTS estratégica para uso por aplicativos clientes. A interface de Serviço da Web mais antiga foi estabilizada e os aprimoramentos serão apenas para a interface RESTful.
O Application Deployment Manager segue essa instrução de direção e exige o servidor RESTful CRD para todos os serviços que são novos no Developer for System versão 7.6 ou superior.
O RESTful e as interfaces de Serviço da Web podem ser ativados simultaneamente em uma única região CICS, se desejado. Nesse caso, haverá dois servidores CRD ativos na região. Os dois servidores compartilharão o mesmo repositório CRD. Observe que o CICS emitirá alguns avisos sobre definições duplicadas quando a segunda interface for definida para a região.
Um ambiente de teste do CICS pode consistir de várias regiões Multi-Region Option (MRO) conectadas. Com o tempo, foram utilizadas designações não oficiais para classificar essas regiões. As designações típicas são Terminal Owning Region (TOR), Web Owning Region (WOR), Application Owning Region (AOR) e Data Owning Region (DOR).
Uma Web Owning Region é usada para implementar suporte aos Serviços da Web do CICS e o servidor CICS Resource Definition (CRD) do Application Deployment Manager deve ser executado nessa região. Esta região é conhecida no Gerenciador de Implementação do Aplicativo como a região de conexão primária do CICS. O cliente do CRD implementa uma conexão de serviço da Web na região de conexão primária do CICS.
As regiões de conexão não-primárias do CICS são todas as outras regiões que o servidor CRD pode atender. Esse serviço inclui visualizar recursos utilizando IBM CICS Explorer e definir recursos utilizando o editor de definição de recurso do CICS.
Se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recurso do CICS da região de conexão primária do CICS, todas as outras regiões do CICS gerenciadas pelo BAS poderão ser atendidas pelo servidor CRD.
As regiões do CICS não gerenciadas pelo BAS requerem alterações adicionais para poderem ser atendidas pelo servidor CRD.
As ações feitas pelo servidor CRD em relação aos recursos do CICS são registradas na fila do CICS CSDL TD, que normalmente aponta para a DD MSGUSR de sua região do CICS.
Se o CICSPlex SM Business Application Services (BAS) for usado para gerenciar as definições de recursos do CICS, a diretiva CICSPlex SM EYUPARM BASLOGMSG deverá ser configurada como (YES) para que o log seja criado.
O conjunto de dados de VSAM do repositório do servidor CRD contém todas as definições de recurso padrão e deve, portanto, ser protegido contra atualizações, mas os desenvolvedores devem ter permissão para ler os valores armazenados aqui. Consulte Definir Perfis de Conjuntos de Dados para obter comandos RACF de amostra para proteger o repositório do CRD.
Quando uma mensagem SOAP for recebida pelo CICS por meio da interface de Serviço da Web, ela será processada por um pipeline. Um pipeline é um conjunto de manipuladores de mensagens que são executados em sequência. O CICS lê o arquivo de configuração do pipeline para determinar quais manipuladores de mensagens devem ser chamados no pipeline. Um manipulador de mensagem é um programa no qual você pode executar processamento especial de pedidos e respostas de serviço da Web.
O Application Deployment Manager fornece um arquivo de configuração de pipeline de amostra que especifica a chamada de um manipulador de mensagens e um programa de processamento de cabeçalho SOAP.
O manipulador de mensagens do pipeline (ADNTMSGH) é usado para segurança através do processamento do ID do usuário e da senha no cabeçalho SOAP. ADNTMSGH é referido pelo arquivo de configuração de pipeline de amostra e, portanto, deve ser colocado na concatenação RPL do CICS.
CPIH é o ID da transação padrão que um aplicativo chamado por um pipeline executará. Geralmente, o CPIH é configurado para um nível mínimo de autorização.
O Developer for System z fornece várias transações que são usadas pelo servidor CRD durante a definição e a consulta de recursos do CICS. Esses IDs de transação são configurados pelo servidor CRD, dependendo da operação solicitada. Consulte "(Opcional) Gerenciador de Implementação do Aplicativo" no Guia de Configuração do Host (SC23-7658) para obter mais informações sobre como customizar os IDs de transação.
Transação | Descrição |
---|---|
ADMS | Para solicitações da ferramenta Processamento de Manifesto para alterar recursos do CICS. Geralmente, isso é destinado aos administradores do CICS. Essa transação requer um alto nível de autorização. |
ADMI | Para pedidos que definam, instalem ou desinstalem recursos do CICS. Essa transação pode requerer um nível médio de autorização, dependendo das políticas do site. |
ADMR | Para todos os outros pedidos que recuperam as informações de ambiente e de recurso do CICS. Essa transação pode requerer um nível mínimo de autorização, dependendo das políticas do site. |
Alguns ou todos esses pedidos de definição de recurso feitos pelas transações do servidor CRD devem ser protegidos. No mínimo, os comandos de atualização (parâmetros de atualização padrão do serviço da Web, parâmetros padrão do descritor e o nome de arquivo para ligação do nome do conjunto de dados) devem ser protegidos para impedir que todos, exceto os administradores do CICS, emitam esses comandos usados para configurar padrões de recurso global.
Quando a transação é conectada, a verificação de segurança de recurso do CICS, se ativada, garante que o ID do usuário esteja autorizado para executar o ID de transação.
A verificação de recursos é controlada pela opção RESSEC na transação que está executando o parâmetro de inicialização do sistema RESSEC e, para o servidor do CRD, o parâmetro de inicialização do sistema XPCT.
A verificação de recursos ocorre apenas se o parâmetro de inicialização do sistema XPCT tiver um valor diferente de NO e a opção RESSEC da definição TRANSACTION for YES ou o parâmetro de inicialização do sistema RESSEC for ALWAYS.
Os seguintes comandos RACF mostram como as transações do servidor CRD podem ser protegidas. Consulte o RACF Security Guide for CICSTS para obter informações adicionais sobre a definição da segurança do CICS.
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 o log do CICS para obter mensagens como a seguir e execute as ações corretivas, conforme documentado em RACF Security Guide para CICSTS.
DFHXS1111 %date %time %applid %tranid Security violation by user
%userid at netname %portname for resource %resource in class
%classname. SAF codes are (X'safresp',X'safreas'). ESM codes are
(X'esmresp',X'esmreas').
O Developer for System z fornece o utilitário administrativo para permitir que administradores do CICS forneçam os valores-padrão para as definições de recurso do CICS. Esses padrões podem ser somente de leitura ou podem ser editados pelo desenvolvedor de aplicativos.
O administrative utility fornece as seguintes funções:
O administrative utility é chamado pela tarefa de amostra ADNJSPAU no conjunto de dados FEK.#CUST.JCL. O uso desse utilitário requer acesso UPDATE ao repositório do CRD.
ADNJSPAU está localizado em FEK.#CUST.JCL, a menos que o programador do sistema z/OS tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de customização" no Guia de Configuração do Host (SC23-7658) para obter mais detalhes.
As instruções de controle de entrada são usadas para atualizar o repositório do CRD de um ambiente de teste do CICS, para o qual as regras gerais de sintaxe a seguir se aplicam:
As definições de amostra a seguir seguem a estrutura dos comandos DFHCSDUP, conforme definido no CICS Resource Definition Guide para CICSTS. A única diferença é a inserção das seguintes palavras-chave de permissão de exibição usadas para agrupar valores de atributo em três conjuntos de permissões:
UPDATE | Os atributos que seguem essa palavra-chave serão atualizados por um desenvolvedor de aplicativos utilizando Developer for System z. Esse também é o padrão para atributos omitidos. |
PROTECT | Os atributos que seguem essa palavra-chave serão exibidos, mas estarão protegidos contra atualizações por um desenvolvedor de aplicativos utilizando Developer for System z. |
HIDDEN | Os atributos que seguem essa palavra-chave não serão exibidos e estarão protegidos contra atualizações por um desenvolvedor de aplicativos utilizando Developer for System z. |
Consulte a seguinte amostra de código ADNJSPAU.
//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 for System z versão 7.6.1 incluiu suporte URIMAP no Administrative utility. Para poder usar o suporte URIMAP, o conjunto de dados VSAM do repositório CRD deve estar alocado com um tamanho de registro máximo de 3000. Até a Developer for System z versão 7.6.1, as tarefas de alocação do repositório CRD da amostra usam um tamanho de registro máximo de 2000.
Siga estas etapas para ativar o suporte URIMAP se você estiver ’ usando um repositório CRD mais antigo:
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.
Para depurar transações do CICS, o Depurador Integrado requer as seguintes atualizações do CICS:
Defina o depurador para uma região do CICS, conforme documentado na tarefa de atualização do CSD de amostra AQECSD. AQECSD está localizada em FEK.#CUST.JCL, a menos que o programador de sistema z/OS tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de Customização" no Guia de Configuração de Host (SC23-7658) para obter mais detalhes.
Para depurar transações do CICS carregadas na memória de leitura, o Depurador Integrado requer as seguintes atualizações do sistema:
Observe que somente um depurador baseado no ambiente de linguagem (LE) pode estar ativo em uma determinada região do CICS. Uma indicação clara de um depurador baseado em LE é que ele fornece um módulo de carregamento CEEEVDBG ou alias que deve estar disponível no aplicativo.
Esse capítulo o ajuda a aprimorar o Developer for System z ao gravar as rotinas de saída.
O Developer for System z fornece pontos de saída para selecionar os eventos do Developer for System z. Um ponto de saída é um ponto específico em um processamento de função no qual a função chama uma rotina de saída, se houver. É possível gravar uma rotina de saída para executar o processamento adicional.
Note que, ao contrário da maioria dos pontos de saída tradicionais, os pontos de saída do Developer for System z não permitem que você altere o comportamento da função. A rotina de saída, se houver, é chamada de forma assíncrona, após a função ser concluída. O processamento do Developer for System z não espera a rotina de saída terminar, nem verifica o status de conclusão.
As saídas de usuário são ativadas com as variáveis _RSE_JAVAOPTS <exit_point>.action no rsed.envvars, em que <exit_point> representa uma palavra-chave que identifica um ponto de saída específico, conforme documentado em Pontos de Saída Disponíveis.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action=<user_exit>"
Por padrão, todos os pontos de saída ficam desativados. Remova o comentário e especifique o nome do caminho completo da rotina de saída do usuário para ativar o ponto de saída.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action.id=<userid>"
Por padrão, o ID do usuário designado para o daemon RSE é usado para executar a rotina de saída fornecida. Remova o comentário e especifique um ID do usuário para usar o ID especificado para executar a saída de usuário. Não há necessidade de especificar uma senha porque o RSE gerará um PassTicket para ser usado como senha quando ele alternar para o ID do usuário especificado.
As rotinas de saída do usuário são chamadas como um comando shell z/OS UNIX com possivelmente um ou mais argumentos. Isso significa que a rotina de saída desenvolvida deve ser executável na linha de comandos do z/OS UNIX. As técnicas de codificação comuns incluem o shell script do z/OS UNIX e o REXX exec do z/OS UNIX, mas o código compilado como C/C++ também é possível.
Consulte o Guia do Usuário do UNIX System Services (SA22-7801) para saber mais sobre os shell scripts do z/OS UNIX. Consulte Usando REXX e z/OS UNIX System Services (SA22-7806) para saber mais sobre as extensões específicas do z/OS UNIX para a linguagem REXX.
A rotina de saída provavelmente será executada por um ID do usuário com permissões especiais (como o ID do usuário de tarefa iniciada do RSE, que é permitido para gerar os PassTickets). Portanto, é importante que você limite a autoridade de atualização para a rotina de saída para evitar abuso. Os limites de comandos de amostra a seguir do z/OS UNIX gravam a autoridade somente para o proprietário, embora todos possam ler e executar o script.
$ chmod 755 process_logon.sh
$ ls -l process_logon.sh
-rwxr-xr-x 1 IBMUSER SYS1 2228 Feb 28 23:44 process_logon.sh
As definições no rsed.envvars estão disponíveis para a rotina de saída do usuário como variáveis de ambiente.
O RSE chama a rotina de saída do usuário com uma sequência de argumentos única. A sequência de argumentos pode ser um valor único ou uma sequência única que retém diversas palavras-chave e valores delimitados em branco. Consulte Pontos de Saída Disponíveis para obter mais detalhes.
O Developer for System z usa o ID de mensagem do console FEK910I para exibir os dados relacionados às saídas de usuário.
A chamada da rotina de saída é marcada com a mensagem do console a seguir:
FEK910I <EXIT_POINT> EXIT: invoking <exit_point> processing exit
in thread <thread_id>
Todos os dados gravados no stdout (comando echo em um shell script, comando say em um REXX exec) serão enviados ao console:
FEK910I <EXIT_POINT> EXIT: <message>
A terminação da rotina de saída é marcada com a mensagem do console a seguir:
FEK910I <EXIT_POINT> EXIT: completed <exit_point> processing exit
in thread <thread_id>
O Developer for System z permite executar uma rotina de saída com o ID do usuário de tarefa iniciada ou com um ID do usuário especificado. Entretanto, talvez você queira executar algumas ações na rotina de saída usando outro ID do usuário, como o ID de usuário cliente na rotina de saída do logon. Isso pode ser realizado com o uso dos serviços padrão do z/OS UNIX, conforme mostrado nas amostras a seguir.
Conforme documentado na Referência de Comando do UNIX System Services (SA22-7802), o z/OS UNIX oferece o comando su para usar os privilégios de um superusuário ou outro usuário. Há algumas coisas a serem lembradas ao usar o comando su.
#! /bin/sh
myID=ibmuser
echo a $(id)
echo 'echo b $(id)' | su -s $myID
echo "echo c \$(id)" | su -s $myID
cat /u/ibmuser/iefbr14
echo "submit /u/ibmuser/iefbr14" | su -s $myID
Essa saída de logon de amostra, executada pelo ID do usuário de tarefa iniciada, resultará nas mensagens de console a seguir:
+FEK910I LOGON EXIT: invoking logon processing exit in thread 411
+FEK910I LOGON EXIT: a uid=8(STCRSE) gid=1(STCGROUP)
+FEK910I LOGON EXIT: b uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: c uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: //IEFBR14 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
+FEK910I LOGON EXIT: //IEFBR14 EXEC PGM=IEFBR14
$HASP100 IEFBR14 ON INTRDR FROM STC03919
IBMUSER
IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
+FEK910I LOGON EXIT: JOB JOB03926 submitted from path '/u/ibmuser/iefbr14'
ICH70001I IBMUSER LAST ACCESS AT 00:46:13 ON MONDAY, MARCH 19, 2012
$HASP373 IEFBR14 STARTED - INIT 2 - CLASS A - SYS CD08
IEF403I IEFBR14 - STARTED - TIME=00.46.14
+FEK910I LOGON EXIT: completed logon processing exit in thread 411
IEFBR14 IEFBR14 IEFBR14 0000
IEF404I IEFBR14 - ENDED - TIME=00.46.14
$HASP395 IEFBR14 ENDED
$HASP309 INIT 2 INACTIVE ******** C=BA
Conforme documentado em Usando REXX e z/OS UNIX System Services (SA22-7806), o z/OS UNIX oferece o comando seteuid SYSCALL para configurar o UID efetivo do processo atual. Há algumas coisas a serem lembradas ao usar o comando seteuid.
/* rexx */
myID='ibmuser'
say userid()
address SYSCALL 'getpwnam' myID 'pw.'
say pw.1 pw.2 pw.3 pw.4 pw.5
address SYSCALL 'seteuid' pw.2 /* PW_UID = 2 */
say retval errno errnojr
say userid()
Essa saída de logon de amostra, executada pelo ID do usuário de tarefa iniciada, resultará nas mensagens de console a seguir:
+FEK910I LOGON EXIT: invoking logon processing exit in thread 515
+FEK910I LOGON EXIT: STCRSE
+FEK910I LOGON EXIT: IBMUSER 1 0 / /bin/sh
+FEK910I LOGON EXIT: 0 0 0
+FEK910I LOGON EXIT: IBMUSER
+FEK910I LOGON EXIT: completed logon processing exit in thread 515
Os pontos de saída a seguir são fornecidos pelo Developer for System z:
A saída de usuário de auditoria é chamada quando o arquivo de log de auditoria ativo é fechado. (A auditoria continua como RSE alternada para um novo arquivo de log de auditoria.)
/usr/lpp/rdz/samples/process_audit.rex
Essa amostra z/OS UNIX REXX exec constrói uma tarefa em lote que processará o log de auditoria que foi encerrado.
A saída de usuário do logon é chamada quando um usuário tiver concluído o processo de logon.
/usr/lpp/rdz/samples/process_logon.sh
Esse shell script do z/OS UNIX de amostra grava uma mensagem de logon no console.
Este capítulo é fornecido para auxiliar a imitar um procedimento de logon de TSO incluindo instruções DD e conjuntos d dados no ambiente do TSO em Developer for System z.
O serviço TSO Commands é o componente Developer for System z que executa comandos TSO e ISPF (em lote) e retorna o resultado para o cliente solicitante. Esses comandos podem ser solicitados implicitamente pelo produto ou explicitamente pelo usuário.
Os membros de amostra fornecidos com o Developer for System z criam um ambiente mínimo do TSO/ISPF. Se os desenvolvedores em sua loja precisarem de acesso a bibliotecas customizadas ou de terceiros, o programador de sistema z/OS deve incluir as instruções DD e as bibliotecas necessárias para o ambiente de serviço TSO Commands. Embora a implementação seja diferente no Developer for System z, a lógica por trás disso é idêntica ao procedimento de logon do TSO.
A partir da versão 7.1, o Developer for 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 for System z. Existe apenas um arquivo de configuração ISPF.conf ativo, que é usado por todos os usuários do Developer for System z.
A seção principal do arquivo de configuração define os nomes DD e as concatenações relacionadas do conjunto de dados, como no seguinte exemplo:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
myDD=HLQ1.LLQ1,HLQ2.LLQ2
Por padrão, o TSO/ISPF Client Gateway cria um perfil temporário do ISPF para o serviço TSO Commands. Entretanto, você pode instruir o TSO/ISPF Client Gateway z a utilizar uma cópia de um perfil existente do ISPF. A chave aqui é a instrução _RSE_ISPF_OPTS em rsed.envvars.
#_RSE_ISPF_OPTS="$_RSE_ISPF_OPTS&ISPPROF=&SYSUID..ISPPROF"
Remova o comentário da instrução (remova o sinal de sustenido (#) inicial) e forneça o nome completo do conjunto de dados do perfil existente do ISPF para utilizar esse recurso.
As seguintes variáveis podem ser usadas no nome do conjunto de dados:
A instrução allocjob no ISPF.conf (que está assinalada como comentário por padrão) aponta um exec que pode ser usado para fornecer alocações adicionais do conjunto de dados por ID do usuário.
*allocjob = ISP.SISPSAMP(ISPZISP2)
Remova o comentário da instrução (remova o caractere de asterisco (*) inicial) e forneça a referência completa para o exec de alocação para utilizar esse recurso.
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 de exec de alocação descritos nas seções anteriores não puderem tratar de suas necessidades específicas, você poderá criar instâncias diferentes do servidor de comunicação RSE do Developer for System z, cada uma delas usando seu próprio arquivo ISPF.conf. A desvantagem principal do método descrito a seguir é que os usuários do Developer for System z devem conectar-se a servidores diferentes no mesmo host para obter o ambiente TSO desejado.
$ cd /etc/rdz
$ mkdir /etc/rdz/tso2
$ cp rsed.envvars /etc/rdz/tso2
$ cp ISPF.conf /etc/rdz/tso2
$ ls /etc/rdz/tso2
ISPF.conf rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
-> change: _RSE_RSED_PORT=4037
-> change: CGI_ISPCONF=/etc/rdz/tso2
-> change: -Ddaemon.log=/var/rdz/logs/tso2
-> change: -Duser.log=/var/rdz/logs/tso2
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/tso2/ISPF.conf
-> change: change as needed
Os comandos no exemplo anterior copiam os arquivos de configuração do Developer for System z que exigem alterações no diretório tso2 recém-criado. A variável CGI_ISPCONF em rsed.envvars deve ser atualizada para definir o novo diretório inicial ISPF.conf, e daemon.log e user.log devem ser atualizados para definir um novo local de log (que é criado automaticamente se não existir). A atualização _RSE_RSED_PORT assegura que o daemon do RSE existente e novo usarão números de porta exclusivos. A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para tso2. O arquivo ISPF.conf em si pode ser atualizado para atender às suas necessidades. Observe que a área de trabalho do ISPF (variável CGI_ISPWORK em rsed.envvars) pode ser compartilhada entre ambas as instâncias.
Agora resta apenas criar uma nova tarefa iniciada para o RSE que utiliza um novo número de porta e os novos arquivos de configuração /etc/rdz/tso2. Observe que se _RSE_RSED_PORT não for alterado em rsed.envvars, a nova tarefa iniciada deverá especificar uma nova porta como argumento de inicialização.
Consulte o Guia de Configuração de Host do IBM Rational Developer for System z (S517-9094) para obter mais informações sobre as ações mostradas anteriormente nesta seção.
Há situações em que você deseja várias instâncias do Developer for System z ativas no mesmo sistema, por exemplo, durante o teste de um upgrade. Entretanto, alguns recursos, como portas TCP/IP, não podem ser compartilhadas, portanto os padrões nem sempre são aplicáveis. Use as informações neste apêndice para planejar a coexistência de instâncias diferentes do Developer for System z, após as quais você pode utilizar este guia de configuração para customizá-las.
Embora seja possível compartilhar certas partes do Developer for System z entre duas (ou mais) instâncias, isso NÃO é recomendado, a menos que seus níveis de software sejam idênticos e as únicas alterações sejam nos membros de configuração. O Developer for System z deixa espaço de customização suficiente para criar várias instâncias que não se sobrepõem, e recomendamos a utilização destes recursos.
Consulte UNIX System Services Command Reference (SA22-7802) para obter informações adicionais sobre os seguintes comandos de amostra para arquivar e restaurar o diretório de instalação do Developer for System z.
Os arquivos de configuração do Developer for System z (e código) podem ser compartilhados entre diferentes sistemas em um sysplex, com cada sistema executando sua própria cópia idêntica do Developer for System z, se algumas diretrizes forem obedecidas. Observe que estas informações destinam-se a instâncias do Developer for System z independentes. Regras adicionais para a configuração do TCP/IP são aplicadas usando o Distributed Dynamic VIPA para agrupar diversos servidores (cada qual em um sistema separado) em um servidor virtual, conforme documentado em Distributed Dynamic VIPA.
Em algum conjunto limitado de circunstâncias, é possível compartilhar tudo, menos (algumas das) as partes customizáveis. Um exemplo é fornecer acesso não-SSL para uso no site e comunicação codificada por SSL para uso externo.
Atenção: A configuração compartilhada NÃO PODE ser usada com segurança para
manutenção de teste, visualização técnica ou novo release. |
Para configurar outra instância de uma instalação ativa do Developer for System z, refaça as etapas de customização das partes que são diferentes, usando conjuntos de dados, diretórios e portas diferentes para evitar sobreposição da configuração atual.
Na amostra de SSL mencionada anteriormente, a configuração do daemon RSE atual pode ser fechada e depois a configuração clonada pode ser atualizada. Em seguida, a JCL de inicialização do daemon RSE pode ser clonada e customizada com uma nova porta TCP/IP e o local dos arquivos de configuração atualizado. As customizações MVS (JES Job Monitor, entre outras) podem ser compartilhadas entre instâncias SSL e não-SSL. Isso resultaria nas seguintes ações:
$ cd /etc/rdz
$ mkdir /etc/rdz/ssl
$ cp rsed.envvars /etc/rdz/ssl
$ cp ssl.properties /etc/rdz/ssl
$ ls /etc/rdz/ssl/
rsed.envvars ssl.properties
$ oedit /etc/rdz/ssl/rsed.envvars
-> change: _RSE_RSED_PORT=4047
-> change: -Ddaemon.log=/var/rdz/logs/ssl
-> change: -Duser.log=/var/rdz/logs/ssl
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/ssl/ssl.properties
-> change: change as needed
Os comandos no exemplo anterior copiam os arquivos de configuração do Developer for System z que requerem mudanças em um diretório recém-criado ssl. As variáveis daemon.log e user.log em rsed.envvars devem ser atualizadas para definir um novo local de log (o qual será criado automaticamente se ainda não existir). A atualização de CLASSPATH assegura que o RSE possa localizar os arquivos de configuração que não foram copiados para ssl. O próprio arquivo ssl.properties pode ser atualizado para corresponder às suas necessidades.
Agora resta criar uma nova tarefa iniciada para o RSE que usa um novo número de porta e os novos arquivos de configuração /etc/rdz/ssl.
Consulte as seções relacionadas no Guia de Configuração do Host IBM Rational Developer for System z (S517-9094) para obter mais informações sobre as ações mostradas anteriormente nesta seção.
Na amostra de SSL mencionada anteriormente, as mudanças entre o daemon RSE ativado por SSL e não SSL são mínimas, o que permite automatizar o processo de manter seus arquivos rsed.envvars sincronizados. Isso simplifica o lançamento de serviço porque apenas um arquivo rsed.envvars deve ser mantido.
O exemplo a seguir inclui um número da porta RSED nos nomes do diretório de log e atualiza o CLASSPATH para que os clones localizem o restante dos arquivos de configuração. Em seguida, o exemplo melhora a tarefa JCL iniciada do daemon RSE ativado por SSL para clonar o rsed.envvars do daemon RSE não SSL na inicialização, atualizando o número da porta no processo. Como o número da porta é integrado no nome do diretório de log, ele será automaticamente diferente entre os dois daemons.
$ oedit /etc/rdz/rsed.envvars
-> change: -Ddaemon.log=/var/rdz/logs/$RSE_RSED_PORT
-> change: -Duser.log=/var/rdz/logs/$RSE_RSED_PORT
-> add at the END:
# -- NEEDED BY CLONES TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ mkdir /etc/rdz/ssl
$ cp /etc/rdz/ssl.properties /etc/rdz/etc/rdz/ssl
$ oedit /etc/rdz/ssl/ssl.properties
-> change: change as needed
//*
//* RSE DAEMON - SSL
//*
//RSED PROC IVP=, * 'IVP' to do an IVP test
// HOME='/usr/lpp/rdz',
// CNFG='/etc/rdz/ssl'
//*
// SET SED='"/RSED_PORT/s/4035/4034/"'
// SET FILE='rsed.envvars'
//*
//* copy /etc/rdz/rsed.envvars to /etc/rdz/ssl/rsed.envvars
//* and alter RSED_PORT
//*
//CLONE EXEC PGM=BPXBATCH,REGION=0M,COND=(4,LT),
// PARM='SH cd &CNFG;sed &SED ../&FILE>&FILE'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
//* start RSED with the newly created rsed.envvars
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,COND=(4,LT),
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
Quando alterações de código estiverem envolvidas (manutenção, visualizações técnicas, novo release), ou suas alterações forem razoavelmente complexas, é aconselhável fazer outra instalação do Developer for System z. Esta seção descreve os possíveis pontos de conflito entre as diferentes instalações.
A lista a seguir é uma breve visão geral dos itens que devem ser ou são altamente aconselhados a serem diferentes entre as instâncias do Developer for System z:
Uma visão geral mais detalhada é listada a seguir:
//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;
//
Este capítulo é fornecido para ajudá-lo com alguns problemas comuns que você pode encontrar durante a configuração do seu Developer for System z, e possui as seções a seguir:
A publicação Developer for System z Messages and Codes (SC14-7497) documenta mensagens e códigos de retorno gerados por componentes do Developer for System z. Developer for System z Answers to common host configuration and maintenance issues (SC14-7373) descreve vários cenários de problemas e sua resolução.
Mais informações estão disponíveis na seção Suporte do website do Developer for System z (http://www-03.ibm.com/software/products/us/en/developerforsystemz/), onde é possível localizar as Notas Técnicas que trazem as informações mais recentes de nossa equipe de suporte.
Na seção Biblioteca do website (http://www-01.ibm.com/support/docview.wss?uid=swg27038517), também é possível localizar a versão mais recente da documentação do Developer for System z, incluindo White Papers.
O Centro de Informações do Developer for System z (http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp) documenta o cliente do Developer for System z e como ele interage com o host (em uma perspectiva do cliente).
Informações sobre valor também podem ser localizadas na biblioteca do z/OS na Internet, disponível em http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
Notifique-nos se pensar que o Developer for System z não tem uma certa função. Você pode abrir uma Solicitação para Aprimoramento (RFE) em
https://www.ibm.com/developerworks/support/rational/rfe/
Developer for System z fornece uma tarefa de amostra, FEKLOGS, que reúne todos os arquivos de log do z/OS UNIX bem como as informações de instalação e configuração do Developer for System z.
A tarefa de amostra FEKLOGS está localizada em FEK.#CUST.JCL, a menos que você tenha especificado um local diferente quando customizou e enviou a tarefa FEK.SFEKSAMP(FEKSETUP). Consulte "Configuração de customização" no Guia de Configuração do Host (SC23-7658) para obter mais detalhes.
A customização de FEKLOGS é descrita dentro da JCL. A customização inclui a provisão de algumas variáveis principais.
O Developer for System z cria arquivos de log que podem auxiliar você e o centro de suporte da IBM na identificação e solução de problemas. A lista a seguir é uma visão geral de arquivos de log que podem ser criados no sistema host do z/OS. Ao lado desses logs específicos do produto, assegure-se de marcar o SYSLOG de todas as mensagens relacionadas.
Os logs baseados no MVS podem ser localizados na instrução DD apropriada. Arquivos de log baseados no z/OS UNIX estão localizados nos seguintes diretórios:
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.
Arquivos de log específicos de IVP (Installation Verification Program) estão localizados no diretório mencionado pelo TMPDIR, se esta variável for definida em rsed.envvars. Se a variável não for definida, os arquivos serão criados no /tmp.
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 detalhes adicionais.
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 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 DD da tarefa do servidor conterá a criação de log do CARMA, se o CARMALOG da instrução DD não estiver definido.
O SYSTSPRT DD da tarefa do servidor mantém as mensagens do sistema (TSO) da inicialização do servidor CARMA.
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.
O comando fekfivpc (teste do IVP relacionado ao CARMA) criará o arquivo fekfivpc.log para documentar a comunicação entre o RSE e o CARMA. O log será criado no diretório conhecido por TMPDIR, se esta variável for definida no rsed.envvars. Se a variável não for definida, o arquivo será criado no /tmp.
Saída do comando fekfivpi -file (teste do IVP relacionado ao TSO/ISPF Client Gateway). O log será criado no diretório conhecido por TMPDIR, se esta variável for definida no rsed.envvars. Se a variável não for definida, o arquivo será criado no /tmp.
Saída do comando fekfivps -file (teste do IVP relacionado ao SCLMDT). O log será criado no diretório conhecido por TMPDIR, se esta variável for definida no rsed.envvars. Se a variável não for definida, o arquivo será criado no /tmp.
O SYSTSPRT DD da etapa que chama o procedimento de revisão de código retém as mensagens do frontend que conduz o processo de análise de código.
O WORKSPCE DD da etapa que chama o procedimento de revisão de código retém as mensagens de log da área de trabalho do Eclipse do processo de análise de código.
O ERRMSGS DD da etapa que chama o procedimento de revisão de código retém a saída stderr do processo de análise de código.
O SYSTSPRT DD da etapa que chama o procedimento de revisão de código retém as mensagens do front-end que conduz o processo de análise de código.
O WORKSPCE DD da etapa que chama o procedimento de revisão de código retém as mensagens de log da área de trabalho do Eclipse do processo de análise de código.
O ERRMSGS DD da etapa que chama o procedimento de revisão de código retém a saída stderr do processo de análise de código.
Quando um produto é finalizado de forma anormal, um dump de armazenamento é criado para auxiliar na determinação do problema. A disponibilidade e o local desses dumps dependem quase que totalmente das configurações específicas do site. Os dumps podem não ser criados, ou podem ser criados em locais diferentes daqueles mencionados nas seções a seguir.
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 for System z é controlada pela Java Virtual Machine (JVM).
A JVM cria um conjunto de agentes de dump por padrão, durante a inicialização (SYSTDUMP e JAVADUMP). Você pode sobrepor este conjunto de agentes de dump utilizando a variável de ambiente JAVA_DUMP_OPTS e sobrepor o conjunto pelo uso de -Xdump na linha de comandos. As opções da linha de comandos JVM são definidas na diretiva _RSE_JAVAOPTS de rsed.envvars. Não altere nenhuma configuração de dump, a menos que tenha sido solicitado pelo IBM Support Center.
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.
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 de 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 de Dump do z/OS UNIX.
Note que o Developer for System z fornece um comando do operador para acionar este dump. Consulte o capítulo "Comandos do Operador" no Guia de Configurações do Host (SC23-7658) para obter mais detalhes.
O dump é gravado em um arquivo z/OS UNIX chamado JAVADUMP.aaaammdd.hhmmss.pid.TXT, em que aaaammdd é igual à data atual, hhmmss é a hora atual e pid é o ID do processo atual. Os locais possíveis deste arquivo são descritos em Locais de Dump do z/OS UNIX.
Note que o Developer for System z fornece um comando do operador para acionar este dump. Consulte o capítulo "Comandos do Operador" no Guia de Configurações do Host (SC23-7658) para obter mais detalhes.
Consulte o Java Diagnostic Guide (SC34-6358) para obter informações adicionais sobre dumps de JVM e o Language Environment Debugging Guide (GA22-7560) para obter informações específicas de LE.
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 em "Comandos do operador" no Guia de Configuração do Host (SC23-7658).
Há vários arquivos de log criados pelos componentes relacionados ao RSE. A maioria está localizada em userlog/$LOGNAME/, em que userlog é o valor combinado das diretivas user.log eDSTORE_LOG_DIRECTORY em rsed.envvars, e $LOGNAME é o ID do usuário de logon (em maiúsculas). Se a diretiva user.log for comentada ou não estiver presente, o caminho inicial do usuário será usado. O caminho inicial é definido no segmento de segurança OMVS do ID de usuário. Se a diretiva DSTORE_LOG_DIRECTORY for comentada ou não estiver presente, então .eclipse/RSE/ será anexado ao valor user.log.
A quantidade de dados gravados em ffs*.log, lock.log e rsecomm.log é controlada pelo comando do operador modify rsecommlog ou pela configuração de debug_level in rsecomm.properties. Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) e "(Opcional) Rastreio RSE" no Guia de Configuração do Host (SC23-7658) para obter detalhes adicionais.
A criação dos arquivos de log .dstore* é controlada pelas opções de inicialização -DDSTORE_* Java, conforme descrito em "Definindo parâmetros de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host (SC23-7658).
Os arquivos de log específicos do daemon RSE e do conjunto de encadeamentos do RSE estão localizados em daemon-home, em que daemon-home é o valor da diretiva daemon.log em rsed.envvars. Se a diretiva daemon.log for comentada ou não estiver presente, o diretório inicial do ID do usuário designado à tarefa iniciada RSED será usado. O diretório inicial é definido no segmento de segurança OMVS do ID do usuário.
A quantidade de dados gravada em rsedaemon.log e em rseserver.log é controlada pelos comandos do operador modify rsedaemonlog e modify rseserverlog ou configurando debug_level em rsecomm.properties . Consulte "Comandos do operador" no Guia de Configuração do Host (SC23-7658) e "(Opcional) Rastreio RSE" no Guia de Configuração do Host (SC23-7658) para obter detalhes adicionais.
serverlogs.count, stderr.*.log e stdout.*.log são criados apenas se a diretiva enable.standard.log em rsed.envvars estiver ativa, ou se a função for dinamicamente ativada com o comando do operador modify rsestandardlog on.
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 for 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 for System z requer que o sistema de arquivo z/OS UNIX e alguns arquivos z/OS UNIX tenham certos bits de permissão configurados.
O Explorador de Sistema Remoto (RSE) é o componente do Developer for System z que fornece serviços principais, como conectar o cliente ao host. Ele deve ter permissão para executar tarefas como criar o ambiente de segurança do usuário.
O sistema de arquivos (HFS ou zFS) em que o Developer for System z está instalado deve ser montado com o bit de permissão SETUID ativado (este é o padrão do sistema). A montagem do sistema de arquivo com o parâmetro NOSETUID impedirá o Developer for System z de criar o ambiente de segurança do usuário e falhará no pedido de conexão. Outros indicadores para este problema de configuração são:
Erros semelhantes (tais como as mensagens BPXP014I e BPXP015I) podem ser esperados se os sistemas de arquivos que hospedam binários de Java ou z/OS UNIX são montados com o parâmetro NOSETUID.
Use o comando TSO ISHELL para listar o status atual do bit SETUID. No painel ISHELL, selecione Sistemas_de_arquivos > 1. Montar tabela... para listar os sistemas de arquivos montados. O comando da linha a mostrará os atributos para o sistema de arquivos selecionado, em que o campo "Ignorar SETUID" deve ser 0.
O Explorador de Sistema Remoto (RSE) é o componente do Developer for System z que fornece serviços principais, como conectar o cliente ao host. Ele deve executar o programa controlado para realizar tarefas como a comutação para o ID do usuário do cliente.
O bit de controle de programa do z/OS UNIX é configurado durante a instalação do SMP/E onde necessário, exceto para a interface Java para seu produto de segurança, conforme documentado no Capítulo 2. Considerações de segurança. Este bit de permissão pode se perder caso você não o tenha preservado durante uma cópia manual dos diretórios Developer for System z.
Os seguintes arquivos do Developer for System z devem ser controlados pelo programa:
Use o comando do z/OS UNIX, ls -E, para listar os atributos estendidos, em que o bit de controle de programa é marcado com a letra p, conforme exibido na amostra a seguir ($ é o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
Use o comando extattr +p do z/OS UNIX para configurar o bit de controle de programa manualmente, conforme exibido na seguinte amostra ($ e # são o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz
$ su
# extattr +p lib/fekf*
# exit
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
O Explorador de Sistema Remoto (RSE) é o componente do Developer for System z que fornece serviços principais, como conectar o cliente ao host. Ele deve executar autorizado pelo APF a fim de executar tarefas como exibir uso de recurso de processo detalhado.
O bit APF z/OS UNIX é definido durante a instalação do SMP/E onde necessário. Este bit de permissão pode se perder caso você não o tenha preservado durante uma cópia manual dos diretórios Developer for System z.
Os arquivos do Developer for System z a seguir devem ser autorizados pelo APF:
Use o comando do z/OS UNIX, ls -E, para listar os atributos estendidos, em que o bit APF é marcado com a letra a, conforme exibido na amostra a seguir ($ é o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Use o comando extattr +a do z/OS UNIX para configurar o bit APF manualmente, conforme exibido na amostra a seguir ($ e # são os prompts do z/OS UNIX):
$ cd /usr/lpp/rdz
$ su
# extattr +a bin/fekfrivp
# exit
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Alguns dos serviços opcionais do Developer for System z requerem que os módulos de carregamento do MVS estejam disponíveis para o z/OS UNIX. Isso é feito ao criar um stub (um arquivo fictício) no z/OS UNIX com o bit "sticky" ativado. Quando o stub é executado, o z/OS UNIX procurará um módulo de carregamento MVS com o mesmo nome e executará o módulo de carregamento em vez disso.
O sticky bit do z/OS UNIX é configurado durante a instalação do SMP/E onde necessário. Esses bits de permissão podem ser perdidos se você não os preservou durante uma cópia manual dos diretórios do Developer for System z.
Os arquivos do Developer for System z a seguir devem ter o sticky bit em:
Use o comando ls -l do z/OS UNIX para listar as permissões, em que o sticky bit é marcado com a letra t, conforme exibido na seguinte amostra ($ é o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Utilize o comando chmod +p do z/OS UNIX para configurar o sticky bit manualmente, conforme exibido na seguinte amostra ($ e # é o prompt do z/OS UNIX):
$ cd /usr/lpp/rdz
$ su
# chmod +t bin/CRA*
# exit
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Com o comando netstat (TSO ou z/OS UNIX), você pode obter uma visão geral das portas atualmente em uso. A saída desse comando será semelhante ao exemplo a seguir. As portas usadas são o último número (atrás de "..") na coluna "Soquete Local". Como estas portas já estão em uso, elas não podem ser usadas para a configuração do Developer for System z.
IPv4
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 16:36:42
User Id Conn Local Socket Foreign Socket State
------- ---- ------------ -------------- -----
BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Listen
INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Listen
RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen
JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Listen
IPv6
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 12:46:25
User Id Conn State
------- ---- -----
BPXOINIT 00000018 Listen
Local Socket: 0.0.0.0..10007
Foreign Socket: 0.0.0.0..0
INETD4 00000046 Listen
Local Socket: 0.0.0.0..512
Foreign Socket: 0.0.0.0..0
RSED 0000004B Listen
Local Socket: 0.0.0.0..4035
Foreign Socket: 0.0.0.0..0
JMON 00000037 Listen
Local Socket: 0.0.0.0..6715
Foreign Socket: 0.0.0.0..0
Outra limitação que pode existir são as portas TCP/IP reservadas. Há os dois lugares comuns a seguir para reservar as portas TCP/IP:
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 não for desejado, será possível configurar o limite também apenas para o Developer for System z em seu software de segurança.
Esse valor pode ser verificado e configurado dinamicamente (até o próximo IPL) com os seguintes comandos de console, conforme descrito em MVS System Commands (GC28-1781):
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 no z/OS 1.10 para 2G, permitindo que as tarefas de 64 bits usem até 4GB (os 2GB abaixo da barra e os 2GB acima da barra concedidos por MEMLIMIT).
Os valores SYS1.PARMLIB(SMFPRMxx) podem ser verificados e ativados com os seguintes comandos do console, conforme descrito em MVS System Commands (GC28-1781):
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.
Quando um usuário seleciona o feedback de erro durante uma ação de compilação, vários conjuntos de dados temporários são criados pelo Developer for System z. Quando um desses conjuntos de dados tem falta de espaço, as tarefas de compilação terminam com um encerramento anormal por falta de espaço B37-04.
Ajuste a alocação de espaço em FEK.SFEKPROC(FEKFERRF) quando os usuários tiverem esse problema. O valor padrão é SPACE(200,40) TRACKS.
SYS1.PARMLIB(BPXPRMxx) define muitas limitações relacionadas ao z/OS UNIX, que pode ser acessado quando muitos clientes do Developer for System z estão ativos. A maioria dos valores de BPXPRMxx pode ser alterada dinamicamente com os comandos do console SETOMVS e SET OMVS.
Use o comando do console SETOMVS LIMMSG=ALL para que o z/OS UNIX exiba mensagens do console (BPXI040I) quando qualquer dos limites BPXPRMxx estiver prestes a ser atingido.
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.
Um conjunto de encadeamentos do RSE pode falhar com uma mensagem OutOfMemoryError sendo registrada. Esse erro está relacionado ao tamanho do heap Java e pode ocorrer se os usuários ativos deste conjunto de encadeamentos usarem mais recursos do que o esperado. As causas comuns desse erro são as seguintes:
Para resolver esse problema, é possível fazer o seguinte:
Este apêndice é fornecido para ajudar você com alguns dos problemas comuns que você pode encontrar ao configurar Secure Socket Layer (SSL) ou durante a verificação ou modificação de uma configuração existente. Este apêndice também fornece uma configuração de amostra para dar suporte aos usuários se autenticando com um certificado X.509.
Comunicação segura significa garantir que seu parceiro de comunicação seja o que alega ser e transmitir informações de forma que dificulte a interceptação e leitura dos dados por terceiros. O SSL fornece essa capacidade em uma rede TCP/IP. Funciona utilizando certificados digitais para se identificar e um protocolo de chave pública para criptografar a comunicação. Consulte Security Server RACF Security Administrator's Guide (SA22-7683) para obter informações adicionais sobre certificados digitais e o protocolo de chave pública usados pelo SSL.
As ações necessárias para configurar as comunicações SSL para o Developer for System z variam de site para site, dependendo das necessidades exatas, do método de comunicação RSE usado e do que já está disponível no site.
Neste apêndice, clonaremos as definições de RSE atuais para que tenhamos uma 2a conexão do daemon RSE que utilizará SSL. Também criaremos nossos próprios certificados de segurança a serem usados pelas diferentes partes da conexão RSE.
Todo este apêndice apresenta uma convenção de nomenclatura uniforme:
Algumas tarefas descritas nas seções a seguir esperam que você esteja ativo no z/OS UNIX. Isso pode ser feito emitindo o comando do TSO OMVS. Use o comando exit para retornar ao TSO.
A variável DSTORE_SSL_ALGORITHM na diretiva _RSE_JAVAOPTS de rsed.envvars permite escolher entre o SSL e sua Segurança da Camada de Transporte (TLS) sucessora como o método de criptografia, conforme documentado em "Definindo Parâmetros de Inicialização Java Extra com o _RSE_JAVAOPTS" no Guia de Configuração do Host (S517-9094).
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 do Java | / | suportados |
Para conectar por meio de SSL, é necessário o keystore e o banco de dados principal, como um arquivo z/OS UNIX ou um conjunto de chaves compatível com SAF:
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 anterior inicia criando os perfis necessários e permitindo que o ID de usuário STCRSE acesse os conjuntos de chaves e os certificados pertencentes a esse ID de usuário. O ID do usuário usado deve corresponder ao ID do usuário usado para executar o daemon do RSE SSL. A próxima etapa é criar um novo certificado auto-assinado com rótulo rdzrse. Não é necessária senha. Esse certificado é incluído em um anel de chaves recém-criado (rdzssl.racf). Assim como com o certificado, não é necessária senha para o anel de chave.
O resultado pode ser verificado com a seguinte opção list:
RACDCERT ID(stcrse) LIST
Informações do certificado digital para o usuário STCRSE:
Rótulo: rdzrse
ID do Certificado: 2QjW1OXi0sXZ1aaEqZmihUBA
Status: TRUST
Data de Início: 24/05/2007 0h
Data de Encerramento: 21/05/2017 23h59min59s
Número de Série:
>00<
Nome do Emissor:
>CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Nome do Assunto:
>CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Tipo de Chave Privada: Não-ICSF
Tamanho da Chave Privada: 1024
Associações de Anel:
Proprietário do Anel: STCRSE
Anel:
>rdzssl.racf<
Os certificados podem ser auto-assinados ou assinados por uma Autoridade de Certificação (CA). Um certificado assinado por uma CA significa que a CA garante que o proprietário do certificado é quem afirma ser. O processo de assinatura inclui as credenciais de CA (também um certificado) no certificado, tornando-o uma cadeia de certificados com vários elementos.
Ao usar um certificado assinado por uma CA, você pode evitar perguntas sobre validação confiável pelo cliente do Developer for System z, se o cliente já confiar na CA.
Siga estas etapas para criar e utilizar um certificado assinado pela CA:
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))
Observe que o certificado CA usado para assinar seu certificado pode, por sua vez, também ser assinado por outro certificado CA, de nível mais alto. Se isso acontecer, o certificado CA de nível mais alto também deverá ser incluído no conjunto de chaves. Esse processo se repete até que o certificado CA de nível mais alto seja um certificado CA raiz, que é sempre um certificado autoassinado.
Nesta etapa, uma nova instância dos arquivos de configuração do RSE é criada, para que a configuração SSL possa ser executada paralelamente com a(s) existente(s). Os comandos de amostra a seguir esperam que os arquivos de configuração estejam em /etc/rdz/, que é o local padrão usado em "Configuração de customização" no Guia de Configuração do Host (SC23-7658).
$ cd /etc/rdz
$ mkdir ssl
$ cp rsed.envvars ssl
$ cp ssl.properties ssl
$ ls ssl
rsed.envvars ssl.properties
Os comandos do z/OS UNIX listados no exemplo anterior criam um subdiretório chamado ssl e o preenchem com os arquivos de configuração que precisam de mudanças. Podemos compartilhar os outros arquivos de configuração, o diretório de instalação e os componentes do MVS, porque não são específicos do SSL.
Ao reutilizar a maioria dos arquivos de configuração existentes, podemos nos concentrar nas alterações realmente necessárias para configurar o SSL e evitar fazer a configuração completa do RSE novamente. (Por exemplo, podemos evitar a definição de um novo local para ISPF.conf.)
Até agora, as definições são uma cópia exata da configuração atual, o que implica que os logs do novo daemon RSE sobreporão os arquivos de log atuais do servidor. O RSE também precisa saber onde localizar os arquivos de configuração que não foram copiados para o diretório ssl. Os dois problemas podem ser tratados por mudanças secundárias em rsed.envvars.
$ oedit /etc/rdz/ssl/rsed.envvars
-> change: _RSE_RSED_PORT=4047
-> change: -Ddaemon.log=/var/rdz/logs/ssl
-> change: -Duser.log=/var/rdz/logs/ssl
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
As mudanças no exemplo anterior definem um novo local de log (que será criado pelo daemon RSE se o local do log não existir). As mudanças também atualizam o CLASSPATH para que os processos RSE do SSL procurem arquivos de configuração primeiramente no diretório atual (/etc/rdz/ssl) e, em seguida, procurem no diretório original (/etc/rdz).
Atualizando ssl.properties, o RSE é orientado a iniciar o uso da comunicação criptografada por SSL.
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.racf
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.racf
-> uncomment and change: server_keystore_label=rdzrse
-> uncomment and change: server_keystore_type=JCERACFKS
As mudanças no exemplo anterior ativam o SSL e informam ao daemon RSE e ao servidor RSE que o certificado (compartilhado) deles está armazenado com o rótulo de rdzrse no conjunto de chaves rdzssl.racf. A palavra-chave JCERACFKS informa ao servidor RSE que um conjunto de chaves compatível com SAF é usado como keystore.
Observe que o SSL do Sistema (usado pelo daemon) sempre usa o ICSF, a interface com o hardware criptográfico System z, quando disponível. Para poder compartilhar as definições de daemon com o servidor usando o ICSF, especifique server_keystore_type JCECCARACFKS. Aqui, um conjunto de chaves compatível com SAF também é usado como armazenamento de chaves públicas, mas a chave privada é armazenada no ICSF. Conforme documentado no Cryptographic Services ICSF Administrator's Guide (SA22-7521), o ICSF usa perfis nas classes de segurança CSFKEYS e CSFSERV para controlar quem pode usar chaves e serviços criptográficos.
Conforme já mencionado, criaremos uma segunda conexão que utilizará SSL, o que significa a criação de um novo daemon do RSE. O daemon do RSE pode ser uma tarefa iniciada ou uma tarefa do usuário. O método de tarefa do usuário para configuração (teste) inicial será usado. s instruções a seguir esperam que a JCL de amostra esteja em FEK.#CUST.PROCLIB(RSED), que é o local padrão usado em "Configuração de customização" no Guia de Configuração do Host (SC23-7658):
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE
//*
//* RSE DAEMON - SSL
//*
//RSED PROC TMPDIR=,
// PORT=,
// IVP=, * 'IVP' to do an IVP test
// CNFG='/etc/rdz/ssl',
// HOME='/usr/lpp/rdz'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG -P&PORT -T&TMPDIR'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
//RSED EXEC RSED
//*
A configuração do host SSL é completa e o daemon RSE para SSL pode ser iniciado ao enviar a tarefa FEK.#CUST.PROCLIB(RSEDSSL) criada anteriormente.
A nova configuração pode agora ser testada conectando-se com o cliente Developer for System z. Como criamos uma nova configuração para ser usada pelo SSL (clonando uma existente), uma nova conexão deverá ser definida no cliente utilizando-se a porta 4047 para o daemon RSE.
Na conexão, o host e o cliente começarão com alguma troca para configurar um caminho seguro. Parte dessa troca é o intercâmbio de certificados. Se o cliente Developer for System z não reconhecer o certificado do host ou a CA que o assinou, o cliente Developer for System z perguntará ao usuário se é possível confiar nesse certificado.
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 logs do 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 anterior inicia criando um banco de dados de chaves chamado rdzssl.kdb com a senha rsessl. Quando o banco de dados existir, ele será preenchido por meio da criação de um novo certificado auto-assinado, válido durante 10 anos (sem contar os dias extras). O certificado é armazenado com o rótulo rdzrse e com a mesma senha (rsessl) usada para o banco de dados de chaves (esse é um requisito do RSE).
gskkyman aloca o banco de dados de chaves com uma máscara de bits de permissão 600 (muito segura) (só o proprietário tem acesso). A menos que o daemon utilize o mesmo ID do usuário que o criador do banco de dados de chaves, as permissões devem ser configuradas menos restritivas. 644 (o proprietário tem leitura/gravação, todos têm leitura) é uma máscara útil para o comando chmod.
O resultado pode ser verificado ao selecionar a opção Mostrar Informações do Certificado no submenu Gerenciar Chaves e Certificados, como a seguir:
$ gskkyman
Menu do Banco de Dados
2 - Abrir banco de dados
Digite o número da opção: 2
Digite o nome do banco de dados de chaves (pressione ENTER para retornar ao menu): rdzssl.kdb
Digite a senha do banco de dados (pressione ENTER para retornar ao menu): rsessl
Menu do Key Management
1 - Gerenciar chaves e certificados
Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1
Lista de Chaves e Certificados
1 - rdzrse
Digite o número do rótulo (ENTER para retornar ao menu de seleção, p para lista anterior: 1
Menu Chave e Certificado
1 - Mostrar informações do certificado
Digite o número da opção (pressione ENTER para retornar ao menu anterior): 1
Informações do Certificado
Rótulo: rdzrse
ID do Registro: 14
ID do Registro do Emissor: 14
Confiável: Sim
Versão: 3
Número serial: 45356379000ac997
Nome do emissor: rdz rse ssl
rdz
IBM
Raleigh
NC
Nome do assunto: rdz rse ssl
rdz
IBM
Raleigh
NC
Data de efetivação: 24/05/2007
Data de expiração: 21/05/2017
Algoritmo de chave pública: rsaEncryption
Tamanho da chave pública: 1024
Algoritmo de assinatura: sha1WithRsaEncryption
ID exclusivo do emissor: Nenhum
ID exclusivo do assunto: Nenhum
Número de extensões: 3
Digite 1 para exibir extensões, 0 para retornar ao menu: 0
Menu Chave e Certificado
0 - Sair do programa
Digite o número da opção (pressione ENTER para retornar ao menu anterior): 0
A amostra ssl.properties a seguir mostra que as diretivas daemon_* são diferentes da amostra do conjunto de chaves SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.kdb
-> uncomment and change: daemon_keydb_password=rsessl
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.racf
-> uncomment and change: server_keystore_label=rdzrse
-> uncomment and change: server_keystore_type=JCERACFKS
As mudanças anteriores ativam o SSL e informam ao daemon RSE que o certificado está armazenado com o rótulo rdzrse no banco de dados de chaves rdzssl.kdb com a senha rsessl. O servidor RSE ainda está usando um conjunto de chaves compatível com SAF.
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 autoassinado criado no exemplo anterior é válido durante aproximadamente 10 anos (não contando o dia 29 de fevereiro). Ele é armazenado em /etc/rdz/ssl/rdzssl.jks utilizando o alias rdzrse. Sua senha (rsessl) é idêntica à senha do armazenamento de chaves, que é um requisito para o RSE.
O resultado pode ser verificado com a opção -list, como a seguir:
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v
Nome do alias: rdzrse
Data de criação: 24 de maio de 2007
Tipo de entrada: keyEntry
Comprimento da cadeia de certificados: 1
Certificado 1¨:
Proprietário: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Emissor: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Número serial: 46562b2b
Válido de: 24/5/07 14h17 até: 21/5/17 14h17
Impressões digitais do certificado:
MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80
SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
A amostra ssl.properties a seguir mostra que as diretivas server_* são diferentes da amostra do conjunto de chaves SAF anterior.
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.racf
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.jks
-> uncomment and change: server_keystore_password=rsessl
-> uncomment and change: server_keystore_label=rdzrse
-> optionally uncomment and change: server_keystore_type=JKS
As mudanças anteriores ativam o SSL e informam ao servidor RSE que o certificado está armazenado com o rótulo rdzrse no armazenamento de chaves rdzssl.jks com a senha rsessl. O daemon RSE ainda está usando um conjunto de chaves compatível com SAF.
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 for System z depende de o TCP/IP ter o nome do host correto quando for inicializado. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.
Você pode testar sua configuração TCP/IP com o Installation Verification Program (IVP) do fekfivpt. O comando deve retornar uma saída como nesta amostra ($ é o prompt do z/OS UNIX):
$ fekfivpt
Quarta-feira, 2 de julho de 2008, 13h11min54s EDT
uid=1(USERID) gid=0(GROUP)
utilizando /etc/rdz/rsed.envvars
-------------------------------------------------------------
Configuração do resolvedor TCP/IP (ordem de procura do z/OS UNIX):
-------------------------------------------------------------
Inicialização de Rastreio do Resolvedor Concluída -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
(L) DataSetPrefix = TCPIP
(L) HostName = CDFMVS08
(L) TcpIpJobName = TCPIP
(L) DomainOrigin = RALEIGH.IBM.COM
(L) NameServer = 9.42.206.2
9.42.206.3
(L) NsPortAddr = 53 (L) ResolverTimeout = 10
(L) ResolveVia = UDP (L) ResolverUdpRetries = 1
(*) Options NDots = 1
(*) SockNoTestStor
(*) AlwaysWto = NO (L) MessageCase = MIXED
(*) LookUp = DNS LOCAL
res_init Succeeded
res_init Started: 2008/07/02 13:11:54.755363
res_init Ended: 2008/07/02 13:11:54.755371
************************************************************************
MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54
Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled
-------------------------------------------------------------
endereço IP do host:
-------------------------------------------------------------
hostName=CDFMVS08
hostAddr=9.42.112.75
bindAddr=9.42.112.75
localAddr=9.42.112.75
Êxito, os endereços correspondem
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 for System z depende de o TCP/IP ter o nome de host correto quando inicializado, ao utilizar APPC. Isto significa que o TCP/IP diferente e os arquivos de configuração do Resolver devem ser configurados corretamente.
O exemplo a seguir tem como foco algumas tarefas de configuração para o TCP/IP e o Resolvedor. Observe que isso não abrange uma configuração completa do TCP/IP ou do Resolver, ela destaca alguns aspectos principais que podem ser aplicáveis no seu site:
//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), você poderá ver que /etc/resolv.conf está em sincronismo com SYS1.TCPPARMS(TCPDATA) . Não há definições DNS, portanto a consulta à tabela de sites será usada.
# Resolver /etc/hosts file cdfmvs08
9.42.112.75 cdfmvs08 # CDFMVS08 Host
9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host
127.0.0.1 localhost
O conteúdo mínimo deste arquivo é a informação sobre o sistema atual. Na amostra anterior, cdfmvs08 e cdfmvs08.raleigh.ibm.com são definidos como um nome válido para o endereço IP do sistema z/OS.
Se você estivesse usando servidor de nomes de domínio (DNS), o DNS conteria as informações de /etc/hosts, e /etc/resolv.conf e SYS1.TCPPARMS(TCPDATA) teriam instruções que identificariam o DNS para o sistema.
Para evitar confusão, e aconselhável manter os arquivos de configuração do TCP/IP e do Resolver em sincronismo um com o outro.
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 IVP de TCP/IP, fekfivpt, conforme descrito em "Verificação da instalação" no Guia de Configuração do Host (SC23-7658). A seção de configuração do resolvedor da saída será semelhante à seguinte amostra:
Inicialização de Rastreio do Resolvedor Concluída -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
Certifique-se de que as definições no arquivo (ou conjunto de dados) referido pelo "Local Tcp/Ip Dataset" estejam corretas.
Esse campo ficará em branco se você não utilizar um nome padrão para o arquivo resolvedor de IP (utilizando a ordem de procura do z/OS UNIX). Nesse caso, inclua a seguinte instrução em rsed.envvars, em que <arquivo do resolvedor> ou <dados do resolvedor> representa o nome do arquivo do resolvedor de IP:
RESOLVER_CONFIG=<arquivo do resolvedor>
ou
RESOLVER_CONFIG=’<conjunto de dados do resolvedor>’
As publicações a seguir são referenciadas neste documento:
Título da publicação | Número da ordem | Referência | Web site de referência |
---|---|---|---|
Diretório do Programa para IBM Rational Developer for System z | GI11-8298 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Program Directory for IBM Rational Developer for System z Host Utilities | GI13-2864 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System zPré-requisitos | S517-9092 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System z Host Configuration Quick Start | GI11-9201 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System zGuia de Configuração do Host | S517-9094 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System zReferência de Configuração do Host | S517-9857 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System z Guia do Utilitário de Configuração do Host | SC14-7282 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System z Messages and Codes | SC14-7497 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System zRespostas a problemas comuns de manutenção e configuração de host | SC14-7373 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Rational Developer for System zPré-requisitos | S517-9092 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
Rational Developer for System z Host Configuration Quick Start | GI11-9201 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
SCLM Developer Toolkit: Guia do Administrador | SC23-9801 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Usando APPC para fornecer serviços de comando TSO | SC14-7291 | White Paper | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Usando Gateway do Cliente ISPF para fornecer serviços CARMA | SC14-7292 | White Paper | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using Data Sets | SC26-7410 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Diagnóstico do MVS: Ferramentas e Auxílio de Serviço | GA22-7589 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Customização de TSO/E | SA22-7783 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Utilizando os Serviços de Sistemas REXX e z/OS UNIX | SA22-7806 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Java™ Diagnostic Guide | SC34-6650 | Java 6.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Guia do Usuário do Java SDK and Runtime Environment | / | Java 6.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Resource Definition Guide | SC34-6430 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Resource Definition Guide | SC34-7181 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/ v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/ library/library_html.html |
RACF Security Guide | SC34-6454 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-7179 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Referência de Linguagem | SC27-1408 | Enterprise COBOL para z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Os Web sites a seguir são referidos neste documento:
Descrição | Web site de referência |
---|---|
Developer for System z: Centro de Informações | http://pic.dhe.ibm.com/infocenter/ratdevz/v9r0/index.jsp |
Developer for System z Biblioteca | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Developer for System z: Página Inicial | http://www-03.ibm.com/software/products/us/en/developerforsystemz/ |
Serviço recomendado do Developer for System z | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Solicitação de aprimoramento de Developer for System z | https://www.ibm.com/developerworks/support/rational/rfe/ |
Biblioteca do z/OS na Internet | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Centro de Informações do CICSTS | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
IBM Tivoli Directory Server | http://www-01.ibm.com/software/tivoli/products/directory-server/ |
Plug-ins de Ferramentas de Determinação de Problemas | http://www-01.ibm.com/software/awdtools/deployment/pdtplugins/ |
Download do Apache Ant | http://ant.apache.org/ |
Documentação do keytool Java | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Página inicial de suporte de CA | https://support.ca.com/ |
As publicações a seguir podem ser úteis para você compreender os problemas de configuração dos componentes do sistema host necessários:
Título da publicação | Número da ordem | Referência | Website de referência |
---|---|---|---|
ABCs do z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
Guia do Programador de Sistema’ para: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
Implementação do TCPIP Volume 1: Funções Base, Conectividade e Roteamento | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
Tivoli Directory Server para z/OS | SG24-7849 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation 2009, 2013.
Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação ou divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos.
É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos nesta publicação em outros países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não IBM são de responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não lhe garante direito algum sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:
Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA", SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS A ELAS NÃO SE LIMITANDO, AS GARANTIAS IMPLÍCITAS DE NÃO INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, essa disposição pode não se aplicar ao Cliente.
Essas informações podem conter imprecisões técnicas ou erros tipográficos. São feitas alterações periódicas nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aviso prévio.
Referências nestas informações a websites não IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a esses websites. Os materiais contidos nesses websites não fazem parte dos materiais desse produto IBM e a utilização desses websites é de inteira responsabilidade do Cliente.
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.
Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em alguns casos o pagamento de uma taxa.
O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato Internacional de Licença do Programa IBM ou de qualquer outro contrato equivalente.
Todos os dados de desempenho aqui contidos foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem variar significativamente. Algumas medidas podem ter sido tomadas em sistemas em nível de desenvolvimento e não há garantia de que estas medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas medidas podem ter sido estimadas por extrapolação. Os resultados reais podem variar. Os usuários deste documento devem verificar os dados aplicáveis para seu ambiente específico.
As informações relativas a produtos não IBM foram obtidas junto aos fornecedores dos respectivos produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não IBM. Dúvidas sobre os recursos de produtos não IBM devem ser encaminhadas diretamente a seus fornecedores.
Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aviso prévio e representam apenas metas e objetivos.
Estas informações foram projetadas apenas com o propósito de planejamento. As informações aqui contidas estão sujeitas a alterações antes que os produtos descritos estejam disponíveis.
Estas informações contêm exemplos de dados e relatórios utilizados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos incluem nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança com os nomes e endereços utilizados por uma empresa real é mera coincidência.
Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de amostra sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de amostra são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não é responsável por nenhum dano decorrente do uso dos programas de amostra.
Cada cópia ou parte destes programas de amostra ou qualquer trabalho derivado deve incluir um aviso de copyright com os dizeres:
© (nome da empresa) (ano). Partes deste código são derivadas dos Programas de Amostras da IBM Corp. © Copyright IBM Corp. 2009, 2013.
Se estas informações estiverem sendo exibidas em cópia eletrônica, as fotografias e ilustrações coloridas podem não aparecer.
IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corp., registradas em vários países no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM está disponível na web em www.ibm.com/legal/copytrade.shtml.
Adobe, o logotipo Adobe, PostScript e o logotipo PostScript são marcas ou marcas registradas da Adobe Systems Incorporated nos Estados Unidos e/ou em outros países.
Linux é uma marca registrada de Linus Torvalds nos Estados Unidos e/ou em outros países.
Windows é uma marca registrada da Microsoft Corporation nos Estados Unidos e/ou em outros países.
UNIX é uma marca registrada do The Open Group nos Estados Unidos e em outros países.
Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Oracle e/ou de suas afiliadas.
Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas.
Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não é responsável por nenhum dano decorrente do uso dos programas de amostra.
IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corp., registradas em vários países no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM está disponível na Web em www.ibm.com/legal/copytrade.shtml.
CA Endevor é uma marca registrada da CA Technologies.
Rational é uma marca registrada da International Business Machines Corporation e da Rational Software Corporation nos Estados Unidos e/ou em outros países.
Intel e Pentium são marcas registradas da Intel Corporation nos Estados Unidos e/ou em outros países.
Microsoft, Windows e o logotipo Windows são marcas ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.
Java e todas as marcas registradas e logotipos baseados em Java são marcas ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e em outros países.
UNIX é uma marca registrada do The Open Group nos Estados Unidos e em outros países.