IBM Rational Developer for z Systems Versão 9.5.1

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

SC43-2907-00

Conteúdo

Nota: Antes de usar estas informações, certifique-se de ler as informações gerais em Avisos.

Décima edição (setembro de 2015)

Início da mudançaEsta edição aplica-se a IBM® Rational Developer for z Systems Versão 9.5 (número de programa 5724-T07 ou parte do número de programa 5697-CDT) e a todas as liberações e modificações subsequentes, até que seja indicado de outra forma em novas edições.Fim da mudança

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

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

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

IBM Brasil - Centro de Traduções
Rodovia SP 101 Km 09
Building 501 P.O. Box 12195
CEP 13185-900
Hortolândia, SP

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

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

© Copyright IBM Corporation 2000, 2015

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

Sobre este Documento

Este documento fornece informações de segundo plano para diversas tarefas de configuração do próprio IBM Rational Developer for z Systems e outros componentes e produtos z/OS (como WLM e TCP/IP).

De agora em diante, os seguintes nomes serão usados neste manual:
  • Início da mudançaO IBM Explorer for z/OS é chamado de z/OS Explorer.Fim da mudança
  • IBM Rational Developer for z Systems é chamado Developer for z Systems.
  • IBM Rational Developer for z Systems Integrated Debugger é chamado Integrated Debugger.
  • Common Access Repository Manager é abreviado para CARMA.
  • Software Configuration and Library Manager Developer Toolkit é chamado SCLM Developer Toolkit, abreviado como SCLMDT.
  • O z/OS UNIX System Services é chamado de z/OS UNIX.
  • O Customer Information Control System Transaction Server é chamado de CICSTS, abreviado para CICS.
Este documento faz parte de um conjunto de documentos que descrevem a configuração do host do Developer for z Systems. 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 z Systems.
  • O Guia de Configuração do Host IBM Rational Developer for z Systems (SC27-8577) descreve em detalhes todas as tarefas de planejamento, tarefas de configuração e opções (incluindo as opcionais) e fornece cenários alternativos.
  • A Referência de Configuração do Host (SC27-8578) do IBM Rational Developer for z Systems descreve o design do Developer for z Systems e fornece informações de segundo plano para diversas tarefas de configuração dos componentes do Developer for z Systems, z/OS e outros produtos (como WLM e TCP/IP) relacionados ao Developer for z Systems.
  • Guia de Iniciação Rápida de Configuração de Host do IBM Rational Developer for z Systems (G517-9391) descreve uma configuração mínima do Developer for z Systems.

As informações deste documento aplicam-se a todos os pacotes do IBM Rational Developer for z Systems Versão 9.5.1.

Para obter as versões mais atualizadas deste documento, consulte o Guia Referência de Configuração do Host (SC27-8578) do IBM Rational Developer for z Systems disponível em http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SC27-8578.

Para obter as versões mais atualizadas da documentação completa, incluindo instruções de instalação, White Papers, podcasts e tutoriais, consulte a página da biblioteca do IBM Rational Developer for z Systems website (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/).

Quem Deve Usar este Documento

Este documento destina-se a configuração e ajuste de programadores de sistemas do IBM Rational Developer for z Systems Versão 9.5.1.

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

Resumo das Mudanças

Início da mudançaEsta seção resume as mudanças da Referência de Configuração do Host, SC43-2907-00 do IBM Rational Developer for z Systems Versão 9.5.1 (atualizado em dezembro de 2015).Fim da mudança

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

Início da mudançaNovas informações:Fim da mudança

Início da mudança
  • Use novos nomes do conjunto de dados dos caminhos do MVS e do z/OS UNIX
Fim da mudança

Início da mudançaInformações removidas:Fim da mudança

Início da mudançaNa versão 9.5.1, as funções relacionadas ao Monitor de Tarefas RSE e JES movidas do IBM Rational Developer for z Systems para um outro produto, o IBM Explorer for z/OS. Esta movimentação inclui a documentação relacionada.Fim da mudança

Início da mudança
  • Os dados RSE específicos serão removidos de todos os capítulos
  • Os dados do Monitor de Tarefas JES específicos serão removidos de todos os capítulos
  • Os dados do serviço de comandos TSO específicos serão removidos de todos os capítulos
  • Os dados de direcionamento ao cliente para o gerenciamento de configuração e versão serão removidos de todos os capítulos
  • A documentação sobre como configurar o TCP/IP será removida
Fim da mudança

Início da mudançaEste documento contém informações apresentadas anteriormente na Referência de Configuração do Host, SC14-7290-09 do IBM Rational Developer for z Systems Versão 9.5..Fim da mudança

Início da mudançaNovas informações:Início da mudançaFim da mudança Fim da mudança
Início da mudançaInformações removidas:Início da mudança
  • O Application Deployment Manager não é mais fornecido, portanto, todas as informações sobre ele foram removidas.
Fim da mudança Fim da mudança

Início da mudançaEste documento contém informações anteriormente apresentadas na Referência de Configuração do Host, SC14-7290-08 do IBM Rational Developer for System z Versão 9.1.1 .Fim da mudança

Novas informações:

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

Novas informações:

Esse documento contém informações apresentadas anteriormente na Referência de Configuração de Host do IBM Rational Developer for System z Versão 9.0.1, SC14-7290-06.

Novas informações:

Esse documento contém informações apresentadas anteriormente na Referência de Configuração de Host do IBM Rational Developer for System z Versão 9.0.1, SC14-7290-05.

Novas informações:

  • Incluídas informações sobre os nomes de arquivos de log com registro de data e hora. Consulte Arquivos de log.
  • Incluídas informações sobre novos eventos auditáveis. ConsulteDados de auditoria.
Este documento contém informações anteriormente apresentadas na Referência de Configuração de Host do IBM Rational Developer for System z Versão 9.0, 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:

Descrição do Conteúdo do Documento

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

Entendendo o Developer for z Systems

O host do Developer for z Systems 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.

Considerações de segurança

Início da mudançaO Developer for z Systems interage com outros componentes de host, que tem implicações de segurança.Fim da mudança

Considerações de TCP/IP

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

Considerações WLM

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

Considerações de Push-to-client

Início da mudançaO Developer for z Systems amplia o direcionamento ao cliente do z/OS Explorer, ou controle de cliente baseado em host, com suporte para definições de projetos.Fim da mudança

considerações CICSTS

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

Início da mudança

Configurando o AT-TLS

Início da mudançaEssa seção é fornecida para ajudá-lo com alguns problemas comuns que podem ser encontrados durante a configuração da Segurança da Camada de Transporte Transparente do Aplicativo (AT-TLS) ou durante a verificação ou modificação de uma configuração existente. Fim da mudança

Fim da mudança

Entendendo o Developer for z Systems

O host do Developer for z Systems 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.

Início da mudançaO Developer for z Systems é compilado na parte superior do IBM Explorer for z/OS . Para obter informações relacionadas ao z/OS Explorer, consulte “Considerações sobre Segurança” na Referência de Configuração do Host (SC27-8438) do IBM Explorer for z/OS .Fim da mudança

Visão geral do componente

Figura 1. Visão geral do componente
Visão geral do componente
O Figura 1 mostra uma visão geral generalizada do layout combinado do z/OS Explorer e do Developer for z Systems em seu sistema host. Início da mudança
  • O Remote Systems Explorer (RSE) fornece os serviços principais, como conectar o cliente ao host e iniciar outros servidores para serviços específicos. O RSE consiste em duas entidades lógicas:
    • O daemon RSE (RSED), que gerencia a configuração de conexão. O daemon RSE também é responsável pela execução em modo de servidor único. Para fazer isso, o daemon RSE cria um ou mais processos-filho conhecidos como conjuntos de encadeamento do RSE (RSEDx).
    • Servidor RSE, que manipula pedidos individuais do cliente. Um servidor RSE é ativado como um encadeamento dentro de um conjunto de encadeamento do RSE.
  • O Debug Manager (DBGMGR) coordena a atividade do Integrated Debugger.
  • O Serviço de Comandos TSO (TSO cmd) (z/OS Explorer) fornece interface semelhante a um lote para comandos TSO e ISPF.
  • O Monitor de Tarefas JES (JMON) (z/OS Explorer) fornece todos os serviços relacionados ao JES.
  • O Common Access Repository Manager (CARMA) fornece uma interface para interagir com Software Configuration Managers (SCMs), como o CA Endevor.
  • Mais serviços estão disponíveis, que podem ser fornecidos pelo próprio Developer for z Systems ou o software de correquisito.
Fim da mudança

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.

Início da mudançaPara 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 rse.env e na quantidade de conexões reais de clientes, diversos espaços de endereços do conjunto de encadeamentos podem ser iniciados pelo daemon.Fim da mudança

donos das tarefas

Figura 2. donos das tarefas
donos das tarefas

Início da mudançaO Figura 2 mostra uma visão geral básica do proprietário das credenciais de segurança usadas para diversas tarefas do z/OS Explorer e do Developer for z Systems. Fim da mudança

Início da mudançaA 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.Fim da mudança

O Figura 2 mostra as tarefas iniciadas do z/OS Explorer e Developer for z Systems (DBGMGR, JMON e RSED), e tarefas iniciadas de amostra e serviços do sistema com quem o Developer for z Systems se comunica. 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, z/OS UNIX REXEC ou SSH são envolvidos quando iniciam 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 2 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.

Depurador Integrado

 

Figura 3. Depurador Integrado
Depurador Integrado

 

 

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

CARMA

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

Arquivos de Configuração CARMA

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

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

CRASTART

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

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

Envio em Lote

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

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

Estrutura de diretório do z/OS UNIX

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

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

Início da mudança
  • /usr/lpp/ibm/rdz/ é o caminho raiz para o código do produto do Developer for z Systems. O local real é especificado no arquivo de configuração rdz.env (variável RDZ_HOME). Os arquivos contidos serão mantidos por SMP/E.
  • O Developer for z Systems coloca arquivos no /usr/lpp/ibm/zexpl/bin, o diretório de binários do z/OS Explorer. O local real é especificado na configuração do z/OS Explorer. Os arquivos contidos serão mantidos por SMP/E.
  • O /etc/zexpl/ mantém os arquivos de configuração do z/OS Explorer e do Developer for z Systems. O local real é especificado na tarefa iniciada RSED (variável CNFG). Os arquivos contidos são mantidos pelo programador de sistema.
  • O /tmp/ é usado pelo Legacy ISPF Gateway para armazenar dados temporários. Alguns IVPs armazenam sua saída aqui. Os arquivos contidos são mantidos pelo ISPF e os IVPs. O local pode ser customizado com a variável TMPDIR no rse.env. Ele também é o local padrão para os arquivos de dump do Java™, que podem ser customizados com a variável _CEE_DUMPTARG no rse.env.
    Nota: /tmp/ exige a máscara de bit de permissão 777 para permitir que cada cliente crie arquivos temporários.
  • O /var/zexpl/WORKAREA/ é usado pelo Legacy ISPF Gateway e pelo SCLMDT para transferir dados entre os espaços de endereços de base do z/OS UNIX e do MVS. O local real é especificado no rse.env (variável CGI_ISPWORK). Os arquivos contidos são mantidos pelo ISPF e SCLMDT.
    Nota: O /var/zexpl/WORKAREA/ requer a máscara de bit de permissão 777 para permitir que cada cliente crie arquivos temporários.
    O Developer for z Systems grava mensagens de logs nos arquivos de logs do z/OS Explorer localizados em /var/zexpl/zexpl/logs/$LOGNAME. O local real é especificado na configuração do z/OS Explorer. Os arquivos contidos são mantidos pelo código do produto do z/OS Explorer e do Developer for z Systems.
  • /var/rdz/sclmdt/CONFIG/ mantém os arquivos de configuração gerais do SCLMDT. O local real é especificado no rdz.env (variável SCLMDT_CONF_HOME). Os arquivos contidos são mantidos pelo administrador do SCLM.
  • /var/rdz/sclmdt/CONFIG/PROJECT/ mantém os arquivos de configuração do projeto SCLMDT. O local real é especificado no rdz.env (variável SCLMDT_CONF_HOME). Os arquivos contidos são mantidos pelo administrador do SCLM.
  • /var/rdz/sclmdt/CONFIG/script/ mantém os scripts relacionados ao SCLMDT que podem ser usados por outros produtos. O local real não é especificado em lugar algum. Os arquivos contidos são mantidos pelo administrador do SCLM.
  • /var/rdz/pushtoclient/ contém arquivos de configuração de cliente, informações de atualização de produto de cliente e informações de projeto baseado em host, as quais são enviadas ao cliente na conexão com o host. O local real é especificado em pushtoclient.properties (variável pushtoclient.folder). Os arquivos contidos são mantidos por um administrador cliente do Developer for z Systems.
  • /var/rdz/pushtoclient/projects/ mantém os arquivos de definição do projeto baseados em host. O local real é especificado em /var/rdz/pushtoclient/keymapping.xml, que é criado e mantido por um administrador de cliente do Developer for z Systems. Os arquivos contidos são mantidos por um gerenciador de projetos ou pelo desenvolvedor principal.
Fim da mudança

Considerações de segurança

Início da mudançaO Developer for z Systems amplia o z/OS Explorer oferecendo funções adicionais, algumas das quais interagem com outros componentes do sistema e produtos, como um Software Configuration Manager (SCM). As definições de segurança específicas do Developer for z Systems são usadas para assegurar as funções fornecidas.Fim da mudança

Os mecanismos de segurança usados pelos servidores e serviços do Developer for z Systems 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.

Início da mudançaO Developer for z Systems é compilado na parte superior do IBM Explorer for z/OS . Para obter informações relacionadas ao z/OS Explorer, consulte “Considerações sobre Segurança” na Referência de Configuração do Host (SC27-8438) do IBM Explorer for z/OS .Fim da mudança

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

Início da mudançaFim da mudança

Métodos de autenticação

Início da mudança

Autenticação do CARMA

A autenticação de cliente é feita pelo daemon RSE, como parte da solicitação de conexão do cliente. O CARMA é iniciado a partir de um encadeamento específico de usuário, e herda o ambiente de segurança do usuário, efetuando bypass da necessidade de autenticação adicional.

Autenticação do SCLM Developer Toolkit

A autenticação de cliente é feita pelo daemon RSE, como parte da solicitação de conexão do cliente. O CARMA é iniciado a partir de um encadeamento específico de usuário, e herda o ambiente de segurança do usuário, efetuando bypass da necessidade de autenticação adicional.

Fim da mudança

Autenticação do Debug Manager

Início da mudançaA autenticação de cliente é feita pelo daemon RSE, como parte da solicitação 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.Fim da mudança

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 FEL.SFEKAUTH, deve ser autorizado pelo APF.

Quando um Mecanismo de Depuração baseado em cliente se conecta ao Gerenciador de Depuração, ele deve apresentar um token de segurança válido para autenticação.

Segurança de conexão

Início da mudança

A maioria das comunicações entre o cliente e o host do Developer for z Systems vem pelo RSE, utilizando assim a segurança de conexão fornecida pelo z/OS Explorer.

Início da mudançaAlguns serviços do Developer for z Systems usam um caminho de comunicação externo (cliente-host) separado:
  • O Mecanismo de Depurador Integrado no cliente conecta o Gerenciador de Depuração no host. Os detalhes de criptografia são controlados pela política Application Transparent Transport Layer Security (AT-TLS).
  • 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.
Fim da mudança
Fim da mudança

Comunicação Criptografada pelo Depurador Integrado

Início da mudançaA comunicação externa (host do cliente) com o Debug Manager opcional também pode ser criptografada. Para ativar a criptografia, crie uma política Application Transparent TLS (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 6. Veja Configurando o AT-TLS para obter detalhes sobre como configurar o AT-TLS.
Figura 6. Política AT-TLS para Debug Manager
 TTLSRule                      RDz_Debug_Manager
{
 LocalPortRange           5335
 Direction                Inbound
 TTLSGroupActionRef       grp_Production
 TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction         RDz_Debug_Manager
{
 HandshakeRole Server
 TTLSKeyRingParms
 {
  Keyring dbgmgr.racf     # Keyring must be owned by the Debug Manager
 }
}
TTLSGroupAction               grp_Production
{
 TTLSEnabled              On
 Trace                    2
}
Fim da mudança
Nota: O método de comunicação usado pelo Mecanismo de Depuração no cliente Developer for z Systems para falar com o Debug Manager no host é por padrão ligado ao método de comunicação usado pelo cliente Developer for z Systems para conversar com o daemon do RSE. Isso implica que se a criptografia estiver ativada para RSE, supõe-se que ela será ativada para o Debug Manager. No entanto, existem cenários alternativos disponíveis para outras instalações.

Segurança de Depuração

O Integrated Debugger opcional requer que usuários tenham permissões de acesso suficiente para perfis de segurança especificados. Se o usuário não tiver a permissão necessária, a sessão de depuração não será iniciada.

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

Tabela 1. Informações de SAF para Funções de Depuração
Perfil FACILITY Acesso Necessário Resultado
AQE.AUTHDEBUG.STDPGM READ Usuário é capaz de depurar aplicativos de estado de problema
AQE.AUTHDEBUG.AUTHPGM READ Usuário é capaz de depurar aplicativos de estado de problema e autorizados
Nota:
  • O Developer for z Systems presume que um usuário não tenha autorização de acesso quando o software de segurança indica que ele não pode determinar se um usuário tem ou não autorização de acesso a um perfil. Um exemplo disso é quando o perfil não está definido.
  • As versões do Developer for z Systems anteriores à versão 9.1.1 verificavam a permissão UPDATE para o perfil AQE.AUTHDEBUG.WRITEBUFFER para permitir a depuração de transações CICS somente leitura. Este perfil não é mais usado e pode ser removido se o seu sistema host tiver somente Developer for z Systems versão 9.1.1 ou superior.
As seguintes definições de segurança de amostra permitem que todos os usuários em grupo RDZDEBUG depurem aplicativos de estado de problema:
 RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
  UACC(NONE) DATA('RATIONAL DEVELOPER FOR Z SYSTEMS – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
  ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

segurança do CICSTS

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

Segurança de SCLM

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

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

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

Definições de segurança

Início da mudançaCustomize e envie a tarefa FELRACF de amostra, que tem comandos RACF de amostra para criar as definições básicas de segurança para o Developer for z Systems. Customize e envie a tarefa AQERACF de amostra, que tem os comandos RACF de amostra para criar as definições de segurança para o Integrated Debugger.Fim da mudança

Início da mudançaO FELRACF e AQERACF estão localizados no FEL.#CUST.JCL, a menos que tenha especificado um local diferente ao customizar e enviar a tarefa FEL.SFELSAMP(FELSETUP). Consulte "Configuração de customização" no Guia de Configuração de Host do Rational Developer for z Systems para obter mais detalhes.Fim da mudança

Consulte a Referência de Idioma de Comandos RACF (SA22–7687), para obter mais informações sobre comandos RACF.

Requisitos e Lista de Verificação

Para concluir a configuração de segurança, o administrador de segurança deve conhecer os valores que estão listados em Tabela 2. Esses valores foram definidos durante etapas anteriores da instalação e customização do Rational Developer for z Systems.
Tabela 2. Variáveis de configuração de segurança
Descrição
  • Valor-padrão
  • Onde encontrar a resposta
Valor
Developer for z Systems qualificador de alto nível do produto
  • Início da mudançaFELFim da mudança
  • Instalação SMP/E
 
Developer for z Systems qualificador de alto nível de customização
  • FEL.#CUST
  • FEL.SFELSAMP(FELSETUP), conforme descrito em "Configuração de customização" no Guia de Configuração do Host do Rational Developer for z Systems.
 
dNome da Tarefa Iniciada pelo Depurador Integrado
  • DBGMGR
  • FEL.#CUST.PROCLIB(DBGMGR), conforme descrito em "mudanças em PROCLIB" no Guia de Configuração de Host do Rational Developer for z Systems
 
Início da mudançaA 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 z Systems. 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. Início da mudançaFim da mudança Fim da mudança

Ativar Configurações de Segurança e Classes

Developer for z Systems 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:
  • Exibir configurações atuais
    • SETROPTS LIST
  • Ativar classe de instalação para Integrated Debugger
    • SETROPTS GENERIC(FACILITY)
    • SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
  • Ativar definições de tarefas iniciadas para o Integrated Debugger
    • SETROPTS GENERIC(STARTED)
    • RDEFINE STARTED ** STDATA(USER(=MEMBER) GROUP(STCGROUP) TRACE(YES))
    • SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
  • Ativar controle de programa para o Integrated Debugger
    • RDEFINE PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK) UACC(READ)
    • SETROPTS WHEN(PROGRAM)
      Nota: Não crie o perfil ** se você já tiver um perfil * na classe PROGRAM. Ele obscurece e complica o caminho da procura usado pelo software de segurança. Nesse caso, você deve mesclar as definições * existentes com a ** nova. Use o perfile **, conforme documentado em Security Server RACF Security Administrator's Guide (SA22-7683).
      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.

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

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

Definir as Tarefas Iniciadas do Developer for z Systems

Início da mudançaOs seguintes comandos RACF de amostra criam a tarefa iniciada DBGMGR, com o ID de usuário protegido (STCDBM) e o grupo STCGROUP designado para ele.Fim da mudança

Início da mudança
  • ADDGROUP STCGROUP OMVS(AUTOGID)
    DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
  • ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('DEBUG MANAGER')
    OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
    DATA('Rational Developer for z Systems') 
  •  RDEFINE STARTED DBGMGR.* DATA('DEBUG MANAGER')
    STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
  • SETROPTS RACLIST(STARTED) REFRESH
Fim da mudança
Nota: Início da mudança
  • Assegure-se de que os IDs de usuário das tarefas iniciadas sejam protegidos especificando-se a palavra-chave NOPASSWORD.
  • A tarefa iniciada do Debug Manager (DBGMGR) é usada somente pelo recurso do Integrated Debugger.
Fim da mudança

Definir o Debug Manager como um Servidor z/OS UNIX Seguro

Início da mudançaO Depurador Integrado requer acesso UPDATE ao perfil BPX.SERVER para criar ou excluir o ambiente de segurança para o encadeamento de depuração. Observe que usar UID(0) para efetuar bypass desse requisito não é suportado. Esta permissão é necessária apenas quando o recurso Depurador Integrado opcional é usado.Fim da mudança

Início da mudança
  • RDEFINE FACILITY BPX.SERVER UACC(NONE)
  • PERMIT BPX.SERVER CLASS(FACILITY) ACCESS(UPDATE) ID(STCDBM)
  • SETROPTS RACLIST(FACILITY) REFRESH
Fim da mudança
Atenção: Definir o perfil BPX.SERVER torna o z/OS UNIX um comutador completo da segurança de nível UNIX para a segurança de nível z/OS UNIX, que é mais segura. Esse comutador pode afetar outros aplicativos e operações z/OS UNIX. Teste a segurança antes de ativá-la em um sistema de produção. Para obter mais informações sobre os diferentes níveis de segurança, consulte UNIX System Services Planning (GA22-7800).

Definir as Bibliotecas Controladas do Programa do MVS para o Debug Manager

Início da mudançaServidores com autoridade para BPX.SERVER devem executar em um ambiente limpo e controlado por programa. Este requisito implica que todos os programas chamados pelo Debug Manager devem também ser controlados por programa. Para as bibliotecas de carregamento do MVS, o controle de programa é gerenciado pelo seu software de segurança. Fim da mudança

Início da mudançaO Debug Manager usa bibliotecas do sistema, o tempo de execução do Ambiente de Linguagem e o Desenvolvedor para a biblioteca de carregamento do z Systems’ (ISP.SISPLOAD).
  • RALTER PROGRAM ** UACC(READ) ADDMEM('SYS1.LINKLIB'//NOPADCHK)
  • RALTER PROGRAM ** UACC(READ) ADDMEM('SYS1.CSSLIB'//NOPADCHK)
  • RALTER PROGRAM ** UACC(READ) ADDMEM('CEE.SCEERUN'//NOPADCHK)
  • RALTER PROGRAM ** UACC(READ) ADDMEM('CEE.SCEERUN2'//NOPADCHK)
  • Início da mudançaRALTER PROGRAM ** UACC(READ) ADDMEM('FEL.SFELAUTH'//NOPADCHK)Fim da mudança
  • SETROPTS WHEN(PROGRAM) REFRESH
Fim da mudança
Nota: Não utilize o perfil ** se já tiver um perfil * na classe PROGRAM. O perfil obscurece e complica o caminho da procura usado por seu software de segurança. Nesse caso, você deve mesclar as definições * existentes com a ** nova. Use o perfil **, conforme documentado em Security Server RACF Security Administrator's Guide (SA22-7683).

Início da mudançaAs 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 específicos a um produto com quem o Developer for z Systems interage, como IBM Explorer for z/OS.Fim da mudança

Início da mudança
  • Alterne a biblioteca de tempo de execução do REXX, para o SCLM Developer Toolkit
    • REXX.*.SEAGALT
Fim da mudança
Nota: As bibliotecas que são projetadas para colocação de LPA também requerem autorizações de controle de programa se forem acessadas por meio de LINKLIST ou STEPLIB. Esta publicação documenta o uso das seguintes bibliotecas LPA: Início da mudança
  • Biblioteca de tempo de execução REXX, para SCLM Developer Toolkit
    • REXX.*.SEAGLPA
  • Developer for z Systems, para CARMA
    • FEL.SFELLPA
Fim da mudança

Definir Suporte de PassTicket para RSE

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

Os PassTickets são senhas geradas pelo sistema com um tempo de vida de aproximadamente 10 minutos. Os PassTickets gerados são baseados em uma chave secreta. Esta chave é um número de 64 bits (16 caracteres hexadecimais). Nos comandos de amostra RACF a seguir, substitua o marcador key16 por uma sequência hexadecimal de 16 caracteres fornecida pelo usuário que tenha os caracteres de 0 a 9 e A a F.
  •  RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16)) 
    APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE') 
    DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
  •  RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE) 
    DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
  •  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" no rdz.env para ativar isto, conforme documentado em "Definindo parâmetros extras de inicialização Java com _RSE_JAVAOPTS" no Guia de Configuração do Host do IBM Rational Developer for z Systems. As definições de classe PTKTDATA devem corresponder ao ID do aplicativo real usado pelo RSE.

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

Defina a permissão de acesso do arquivo z/OS UNIX para RSE

O comando do operador MODIFY LOGS usa o ID do usuário da tarefa iniciada do RSED para coletar logs de host e informações de configuração. E por padrão, os arquivos de log do usuário, são criados com permissões de acesso do arquivo de segurança (apenas o proprietário tem acesso). Para ser capaz de coletar arquivos de log de usuários seguros, o ID do usuário da tarefa iniciada do RSED deve ter permissão para lê-los.

O argumento OWNER do comando do operador MODIFY LOGS resulta no ID do usuário especificado se tornar o proprietário dos dados coletados. A fim de alterar a propriedade, ao ID do usuário da tarefa inicial do RSED deve ser permitido usar o serviço CHOWN z/OS UNIX.

  • RDEFINE UNIXPRIV SUPERUSER.FILESYS UACC(NONE) DATA('OVERRIDE UNIX FILE ACCESS RESTRICTIONS')
  • RDEFINE UNIXPRIV SUPERUSER.FILESYS.CHOWN UACC(NONE) DATA('OVERRIDE UNIX CHANGE OWNER RESTRICTIONS')
  • PERMIT SUPERUSER.FILESYS CLASS(UNIXPRIV) ACCESS(READ) ID(STCRSE)
  • PERMIT SUPERUSER.FILESYS.CHOWN CLASS(UNIXPRIV) ACCESS(READ) ID(STCRSE)
  • SETROPTS RACLIST(UNIXPRIV) REFRESH

Observe que quando perfil do SUPERUSER.FILESYS.ACLOVERRIDE for definido, as permissões de acesso definidas no ACL (Lista de Controle de Acesso) têm precedência sobre as permissões concedidas por meio do SUPERUSER.FILESYS. O ID do usuário da tarefa iniciada do RSED precisará da permissão de acesso do READ para o perfil do SUPERUSER.FILESYS.ACLOVERRIDE para efetuar bypass das definições de ACL.

Definir a Proteção do Aplicativo para RSE

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

  •  RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
  •  SETROPTS RACLIST(APPL) REFRESH
Nota:
  • Conforme descrito em mais detalhes em Definir Suporte de PassTicket para RSE, o RSE suporta o uso de um ID do aplicativo que não FEKAPPL. A definição de classe do APPL deve corresponder ao ID do aplicativo real usado pelo RSE.
  • A solicitação de conexão do cliente é bem-sucedida se o ID do aplicativo não estiver definido na classe APPL.
  • A solicitação de conexão do cliente falhará somente se o ID do aplicativo estiver definido e o usuário não tiver acesso de LEITURA ao perfil.

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

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

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

Definir a Segurança de Comando JES

O JES Job Monitor emite todos os comandos do operador JES solicitados por um usuário por meio de um console MCS (EMCS) estendido, cujo nome é controlado com a diretiva CONSOLE_NAME, conforme documentado em "FEJJCNFG, JES Job Monitor configuration file" no Rational Developer for z Systems Host Configuration Guide.

A amostra a seguir de comandos RACF dá aos usuários do Developer for z Systems 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 Z SYSTEMS')
  •  RDEFINE OPERCMDS JES%.** UACC(NONE)
  •  PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
  •  SETROPTS RACLIST(OPERCMDS) REFRESH
Nota:
  • O uso do console é permitido se nenhum perfil MVS.MCSOPER.#console for definido.
  • A classe CONSOLE deverá estar ativa para que WHEN(CONSOLE(JMON)) funcione, mas não há registro de entrada real de perfil na classe CONSOLE para consoles EMCS.
  • Não substitua JMON pelo nome real do console na cláusula WHEN(CONSOLE(JMON)). A palavra-chave JMON representa o aplicativo de ponto de entrada, não o nome do console.
Atenção: Definir os comandos JES com o acesso universal NONE no software de segurança pode afetar outros aplicativos e operações. Teste a segurança antes de ativá-la em um sistema de produção.

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

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

with x = {J, S or T}

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

with x = {J, S or T}

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

with x = {J, S or T}

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

with x = {J, S or T}

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

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

Definir acesso ao depurador integrado

Usuários requerem acesso READ para um dos seguintes perfis AQE.AUTHDEBUG.* listados para conseguirem usar o Integrated Debugger para depurar programas de estado de problemas. Usuários permitidos para o perfil AQE.AUTHDEBUG.AUTHPGM também são permitidos para depurar programas APF autorizados. Substitua o item temporário #apf por IDs de usuário válidos ou nomes de grupos RACF para os usuários que têm permissão para depurar programas autorizados.

  •  RDEFINE FACILITY AQE.AUTHDEBUG.STDPGM UACC(NONE)        
  •  PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) ACCESS(READ) ID(*)
  •  RDEFINE FACILITY AQE.AUTHDEBUG.AUTHPGM UACC(NONE)
  •  PERMIT AQE.AUTHDEBUG.AUTHPGM CLASS(FACILITY) ACCESS(READ) ID(#apf)        
  •  SETROPTS RACLIST(FACILITY) REFRESH                       
Nota: Versões do IBM Rational Developer for System z anteriores à versão 9.1.1 usavam outro perfil de classe FACILITY, AQE.AUTHDEBUG.WRITEBUFFER, que não está mais em uso. Ela poderá ser removida se seu sistema host tiver apenas o IBM Rational Developer for System z versão 9.1.1 ou superior.

Definir Perfis de Conjuntos de Dados

O acesso READ para usuários e ALTER para programadores de sistema é suficiente para a maioria dos conjuntos de dados do Developer for z Systems. 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 padrão de alto nível usado durante instalação e FEL.#CUST é o qualificador padrão de alto nível para conjuntos de dados criados durante o processo de customização.

  • Início da mudança
    ADDGROUP (FEL) OWNER(IBMUSER) SUPGROUP(SYS1)
    DATA('IBM Rational Developer for z Systems - HLQ STUB')
                           
    Fim da mudança
  • Início da mudança
    ADDSD  'FEL.*.**' UACC(READ)
    DATA('IBM Rational Developer for z Systems')
    Fim da mudança
  • Início da mudança
    PERMIT 'FEL.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
    Fim da mudança
  •  SETROPTS GENERIC(DATASET) REFRESH
Nota:
  • Início da mudançaProteja o FEL.SFELAUTH contra atualizações, pois este conjunto de dados está autorizado por APF. Fim da mudança
  • Os comandos de amostra nesta publicação e na tarefa FELRACF assumem que o Enhanced Generic Naming (EGN) está ativo. Quando o EGN estiver ativo, o qualificador ** poderá ser usado para representar qualquer número de qualificadores na classe DATASET. Substitua ** por * se a EGN não estiver ativa em seu sistema. Para obter mais informações sobre EGN, consulte Security Server RACF Security Administrator's Guide (SA22-7683).
Início da mudançaAlguns dos componentes do Developer for z Systems requerem perfis de conjuntos de dados se segurança adicionais. Substitua os itens temporários #sysprog e #ram-developer pelos IDs de usuários válidos ou pelos nomes do grupo RACF:
  • Se a conversão do nome curto/longo do SCLM Developer Toolkit for usada, os usuários irão requerer o acesso UPDATE para o mapeamento VSAM, FEL.#CUST.LSTRANS.FILE.
    • Início da mudança
      ADDSD  'FEL.#CUST.LSTRANS.*.**' UACC(UPDATE)
       DATA('IBM Rational Developer for z Systems - SCLMDT')
                   
      Fim da mudança
    •  PERMIT 'FEL.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
    •  SETROPTS GENERIC(DATASET) REFRESH
  • Os desenvolvedores do CARMA RAM (Gerenciador de Acesso do Repositório) requerem acesso UPDATE aos CARMA VSAMs, FEL.#CUST.CRA*.
    •  ADDSD  'FEL.#CUST.CRA*.**' UACC(READ)
      DATA('IBM Rational Developer for z Systems - CARMA')
                              
    •  PERMIT 'FEL.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
    •  PERMIT 'FEL.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
    •  SETROPTS GENERIC(DATASET) REFRESH
Fim da mudança

Verifique as Configurações de Segurança

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

Início da mudança
  • Configurações e classes de segurança
    • SETROPTS LIST
  • Tarefas iniciadas
    • LISTGRP STCGROUP OMVS
    • LISTUSER STCDBM OMVS
    • RLIST STARTED DBGMGR.* ALL STDATA
  • O Debug Manager é um servidor seguro do z/OS UNIX
    • RLIST FACILITY BPX.SERVER ALL
  • Bibliotecas controladas do programa MVS para o Debug Manager
    • RLIST PROGRAM ** ALL
  • Acesso integrado ao Depurador
    • RLIST FACILITY AQE.** ALL
  • Perfis do conjunto de dados
    • LISTGRP FEL
    • LISTDSD PREFIX(FEL) ALL
Fim da mudança

Considerações de TCP/IP

O Developer for z Systems 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.

Os seguintes tópicos são abordados neste capítulo: Início da mudançaFim da mudança

Início da mudançaO Developer for z Systems é compilado na parte superior do IBM Explorer for z/OS . Para obter informações relacionadas ao z/OS Explorer, consulte “Considerações sobre o TCP/IP” na Referência de Configuração do Host (SC27-8438) do IBM Explorer for z/OS .Fim da mudança

Portas TCP/IP

Figura 7. Portas TCP/IP
Portas TCP/IP

Início da mudançaO Figura 7 mostra as portas TCP/IP que podem ser usadas pelo z/OS Explorer e pelo Developer for z Systems. As setas mostram qual parte não liga (lado de ponta da seta) e qual se conecta.Fim da mudança

Comunicação Externa

Defina as seguintes portas para seu firewall protegendo o host do z/OS, uma vez que são usadas para a comunicação de cliente-host (utilizando o protocolo tcp): Início da mudança
  • Início da mudançaO daemon RSE (z/OS Explorer) para a configuração de comunicação de host do cliente, a porta padrão 4035. A porta pode ser configurada no arquivo de configuração rse.env. A comunicação nessa porta pode ser criptografada.Fim da mudança
  • Início da mudançaO servidor RSE (z/OS Explorer) para comunicação do host do cliente. Por padrão, qualquer porta disponível é usada, mas isso pode estar limitado a um intervalo especificado com a definição do _RSE_PORTRANGE no rse.env. O intervalo de portas para _RSE_PORTRANGE é 8108-8118 (11 portas). A comunicação nessa porta pode ser criptografada.Fim da mudança
  • Início da mudançaO Debug Manager para serviços do Integrated Debugger, porta padrão 5335. A porta pode ser configurada no JCL de tarefa iniciada por DBGMGR. A comunicação nessa porta pode ser criptografada.Fim da mudança
  • Qualquer serviço INETD para ações remotas (baseadas em host) nos subprojetos do z/OS UNIX:
    • REXEC (versão z/OS UNIX), porta padrão 512.
    • Início da mudançaSSH (versão z/OS UNIX), porta padrão 22. A comunicação nessa porta é criptografada.Fim da mudança
  • Início da mudançaO serviço Telnet TN3270 (z/OS Explorer) para o Host Connect Emulator, porta padrão 23. A comunicação pode ser criptografada (porta padrão 992). A porta padrão designada ao serviço Telnet TN3270 depende de o usuário escolher ou não o uso de criptografia.Fim da mudança
  • Início da mudançaA cobertura de código baseada em host pode ser instruída para se conectar com o Integrated Debugger Engine de um cliente do Developer for z Systems. A comunicação nessa porta pode ser criptografada. Observe que neste cenário, o coletor de cobertura de código baseado em z/OS é um cliente para TCP/IP e o Mecanismo de Depurador Integrado no computador pessoal do usuário é um servidor para TCP/IP. O padrão é trabalhar com a Ferramenta de Depuração IBM no mesmo host.Fim da mudança
Fim da mudança
Nota: Normalmente, o cliente especifica qual endereço TCP/IP é usado para se conectar ao host. No entanto, para assegurar que as sessões de depuração se comuniquem com o host remoto, o Debug Manager dita ao cliente qual endereço TCP/IP deve ser usado.

Comunicação interna

Vários serviços do host do Developer for z Systems executam em encadeamentos ou espaços de endereços separados e estão usando soquetes TCP/IP como mecanismo de comunicação , usando os endereços de loopback de seu sistema. 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:
  • JES Job Monitor para serviços relacionados ao JES, porta padrão 6715. A porta pode ser configurada no membro de configuração FEJJCNFG e é repetida no arquivo de configuração rse.env.
  • (opcional) A comunicação CARMA usa por padrão uma porta efêmera, mas um intervalo de portas pode ser configurado no arquivo de configuração CRASRV.properties.
  • (opcional) Gerenciador de Depuração para serviços relacionados à depuração, porta padrão 5336. A porta pode ser configurada no JCL de tarefa iniciada por DBGMGR.
  • A cobertura de código baseado em host, que é uma tarefa em lote, aloca uma porta efêmera para permitir que o IBM Debug Tool for z/OS se comunique com ela e entregue os dados necessários para o relatório de cobertura de código.

Reserva de Porta TCP/IP

Início da mudançaSe você usar a instrução PORT ou PORTRANGE no PROFILE.TCPIP para reservar as portas usadas pelo z/OS Explorer e o Developer for z Systems, 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.Fim da mudança

Início da mudança
PORT      4035     TCP RSED   ; z/OS Explorer  – RSE daemon
PORT      6715     TCP JMON   ; z/OS Explorer  – JES job monitor
PORT      5335     TCP DBGMGR ;  Developer for z Systems  – Integrated debugger
PORT      5336     TCP DBGMGR ;  Developer for x Systems  – Integrated debugger
PORTRange 8108 11  TCP RSED*  ;  z/OS Explorer  – RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ;  Developer for z Systems  - CARMA
Fim da mudança

CARMA e TCP/IP

portas do CARMA e TCP/IP

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

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

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

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

 PORTRange 5227 100 RSED*          ; DEVELOPER FOR Z SYSTEMS - CARMA
Nota: O CARMA IVP, fekfivpc, falhará se as portas do CARMA forem reservadas para uso pelos espaços de endereço do RSE. Isto é para ser esperado por que o IVP executa no espaço de endereço da pessoa que está executando o IVP, e não no espaço de endereço do RSE, e o TCP/IP falhará a solicitação de ligação.

O CARMA e a Afinidade de Pilha

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

Início da mudançaSemelhante às tarefas iniciadas do z/OS Explorer e Developer for z Systems, a afinidade de pilha para um servidor CARMA está configurada com a variável _BPXK_SETIBMOPT_TRANSPORT, que deve ser passada para AL (Ambiente de Linguagem). Isso pode ser feito ajustando o comando de inicialização no arquivo de configuração crastart*.conf ou CRASUB*. Fim da mudança

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

crastart*.conf

Substitua esta parte:
 ... PARM(&CRAPRM1. &CRAPRM2.)
por esta (em que TCPIP representa a pilha TCP/IP desejada):
 ... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
Nota: CRASTART não suporta continuações de linha, mas não há nenhum limite quanto ao comprimento de linha aceito.

CRASUB*

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

Considerações WLM

Ao contrário dos aplicativos tradicionais do z/OS, o Rational Developer for z Systems não é um aplicativo monolítico que pode ser identificado facilmente para Workload Manager (WLM). O Developer for z Systems consiste de vários componentes que interagem para fornecer ao cliente acesso para os serviços e dados do host. Como descrito em Entendendo o Developer for z Systems, 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:

Início da mudançaO Developer for z Systems é compilado na parte superior do IBM Explorer for z/OS . Para obter informações relacionadas ao z/OS Explorer, consulte “Considerações sobre WLM” na Referência de Configuração do Host (SC27-8438) do IBM Explorer for z/OS.Fim da mudança

Classificação de Carga de Trabalho

Figura 8. classificação WLM
classificação WLM

Início da mudançaO Figura 8 mostra uma visão geral básica dos subsistemas por meio do qual as cargas de trabalho do z/OS Explorer e do Developer for z Systems são apresentadas ao WLM.Fim da mudança

Início da mudançaO daemon RSE (RSED), o Debug Manager (DBGMGR) e o Monitor de Tarefas JES (JMON) são as tarefas iniciadas do z/OS Explorer e do Developer for z Systems (ou tarefas em lote de longa execução), cada uma com seu espaço de endereço individual. Fim da mudança

Início da mudançaO daemon RSE executa o spawn de um processo-filho para cada servidor do 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.Fim da mudança

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 z Systems 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 8 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.

Início da mudançaEspaços de endereço adicionais são criados por outros serviços que o Developer for z Systems usa, como z/OS UNIX REXEC (compilação USS).Fim da mudança

Regras de Classificação

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

Tabela 5. Subsistemas de Ponto de Entrada do WLM
Tipos de subsistemas Descrição do trabalho
ASCH Os pedidos de trabalho incluem todos os programas de transação APPC planejados pelo planejador de transação da IBM-supplied APPC/MVS, ASCH.
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 6 lista qualificadores adicionais que podem ser usados para designar uma carga de trabalho a uma classe de serviço específica. Consulte MVS Planejamento: Gerenciamento de Carga de Trabalho (SA22-7602) para obter detalhes adicionais sobre os qualificadores de trabalho listados.

Tabela 6. qualificadores de trabalho WLM
    ASCH JES OMVS STC
AI Dados da Conta x x x x
LU Nome LU (*)        
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    
SPM Parâmetro de Subsistema       x
PX Nome Sysplex 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
UI ID do usuário (*) x x x x
Nota: Para os qualificadores marcados com (*), é possível especificar os grupos de classificação ao incluir um G na abreviação do tipo. Por exemplo, um grupo de nome de transação seria TNG.

Configurando Objetivos

Como documentado em Classificação de Carga de Trabalho, o Developer for z Systems 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 z Systems é recomendável que as tarefas sejam colocadas em classes de serviço de alto desempenho ou em classes de serviço de desempenho moderado com uma alta prioridade.

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

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

O Tabela 7 lista os espaços de endereços usados pelo z/OS Explorer e pelo Developer for z Systems. O z/OS UNIX substituirá "x" na coluna "Nome da Tarefa" por um número de 1 dígito aleatório.

Início da mudança
Tabela 7. cargas de trabalho WLM
Descrição Nome da tarefa Carga de trabalho
Debug Manager DBGMGR STC
Monitor de Tarefas JES (z/OS Explorer) JMON STC
Daemon RSE (z/OS Explorer) RSED STC
Conjunto de encadeamentos RSE (z/OS Explorer) RSEDx OMVS
Início da mudança(ISPF) Interactive ISPF Gateway (Serviço de Comandos TSO)Fim da mudança Início da mudança<userid>Fim da mudança Início da mudançaJESFim da mudança
Início da mudança(ISPF) Legacy ISPF Gateway (Serviço de Comandos TSO e SCLMDT)Fim da mudança <userid>x OMVS
Serviço de Comandos TSO (APPC) (z/OS Explorer) 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
Fim da mudança

Considerações para Seleção de Objetivos

As seguintes considerações gerais do WLM podem ajudar a definir apropriadamente as definições de objetivos corretas para Developer for z Systems:
  • É recomendável que você baseie os objetivos no que é realmente possível ser atingido e não no que você deseja que aconteça. Se estabelecer objetivos mais altos do que o necessário, o WLM moverá recursos de trabalho de importância menor para trabalho de importância mais alta, que pode não necessariamente precisar de recursos.
  • Limite a quantia de trabalho designada para classes de serviços SYSTEM e SYSSTC porque essas classes possuem uma prioridade de despacho mais alta que qualquer classe WLM gerenciada. Use estas classes para trabalho que seja de importância alta, mas que use pouco CPU.
  • O trabalho que é desaprovado pelas regras de classificação acaba na classe SYSOTHER, que possui um objetivo discricionário. Um objetivo discricionário diz ao WLM para apenas fazer o seu melhor, quando o sistema possuir recursos sobressalentes.
Quando usar os objetivos de tempo de resposta:
  • Deve haver uma taxa de chegada de tarefas fixa (pelo menos 10 tarefas em 20 minutos) para que o WLM gerencie apropriadamente um objetivo de tempo de resposta.
  • Use objetivos de tempo médio de resposta somente para cargas de trabalho bem controladas, porque uma única transação longa possui um grande impacto sobre o tempo médio de resposta e pode fazer com que o WLM reaja exageradamente.
Quando usar objetivos de velocidade:
  • Normalmente, não é possível atingir uma meta de velocidade acima de 90% por várias razões. Por exemplo, todos os espaços de endereços SYSTEM e SYSSTC possuem uma prioridade de despacho mais alto que o objetivo de tipo de velocidade.
  • O WLM usa um número mínimo de (uso e atraso) amostras nas quais baseia suas decisões sobre objetivo de velocidade. Assim quando menor for a execução de trabalho em uma classe de serviço, maior será o tempo para coletar o número requerido de amostras e ajustar a política de despacho.
  • Reavalie os objetivos de velocidade quando alterar o seu hardware. Em particular, mover para processadores mais rápidos e menores requer mudanças nos objetivos de velocidade.

STC

Início da mudançaTodas as tarefas iniciadas do Developer for z Systems estão atendendo a solicitações do cliente em tempo real.Fim da mudança

Início da mudança
Tabela 8. cargas de trabalho WLM STC
Descrição Nome da tarefa Carga de trabalho
Debug Manager DBGMGR STC
Fim da mudança
Início da mudança
  • Debug Manager

    O Debug Manager fornece serviços para conectar programas que estão sendo depurados para clientes que os estão depurando. É 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.

Fim da mudança

OMVS

Início da mudançaTodas as cargas de trabalho usam o ID do usuário cliente como base para o nome de 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.Fim da mudança

Início da mudançaTodas as cargas de trabalho terminarão na mesma classe de serviço, devido a uma convenção comum de nomenclatura de espaço de endereço. É 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.Fim da mudança

Tabela 9. Cargas de trabalho WLM OMVS
Descrição Nome da tarefa Carga de trabalho
Início da mudançaGateway ISPF Anterior (serviço TSO Commands e SCLMDT)Fim da mudança <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
Início da mudança
  • Início da mudançaGateway ISPF Anterior

    Início da mudançaO Gateway ISPF Anterior é um serviço ISPF chamado pelo Developer for z Systems para executar comandos TSO e ISPF não interativos. Isso inclui comandos explícitos emitidos pelo cliente, bem como comandos implícitos emitidos pelo componente SCLMDT do Developer for z Systems. 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.Fim da mudança

    Fim da mudança
  • CARMA

    O CARMA é um servidor Developer for z Systems opcional usado para interagir com Software Configuration Managers (SCMs), baseados em host, tais como o CA Endevor® SCM. O Developer for z Systems 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.

  • Build z/OS UNIX

    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.

  • Shell do z/OS UNIX

    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.

Fim da mudança

JES

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

Início da mudança
Tabela 10. Carga de trabalhos WLM JES
Descrição Nome da tarefa Carga de trabalho
CARMA (batch) CRA<port> JES
Build MVS (tarefa em lote) * JES
Fim da mudança
Início da mudança
  • CARMA

    CARMA é um servidor do Developer for z Systems que é usado para interagir com o Software Configuration Managers (SCMs) baseado em host, como CA Endevor® SCM. O Developer for z Systems 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.

  • Build MVS
    Quando o cliente inicia uma construção para um projeto MVS, Developer for z Systems 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.
    • Você poderia especificar um objetivo de período múltiplo com um período de tempo de resposta percentil e um período de velocidade de final. Neste caso, seus desenvolvedores deveriam estar usando principalmente o mesmo procedimento de construção e arquivos de entrada de tamanho similar para criar tarefas com tempos de resposta uniformes. Também deve haver uma taxa de chegada de tarefas fixa (pelo menos 10 tarefas em 20 minutos) para que o WLM gerencie apropriadamente o objetivo de tempo de resposta.
    • Um objetivo de velocidade é mais adequado para a maioria de tarefas em lote porque este objetivo pode lidar com taxas de chegada e tempos de execução altamente variáveis.
Fim da mudança

Considerações de Push-to-client

Push-to-client, ou controle de cliente baseado em host, suporta gerenciamento central das seguintes coisas:
  • Arquivos de configuração do cliente
  • Versão de produto do cliente
  • Definições de projeto
Os seguintes tópicos são abordados neste capítulo:Início da mudançaFim da mudança

Início da mudançaO Developer for z Systems é compilado na parte superior do IBM Explorer for z/OS . Para obter informações relacionadas ao z/OS Explorer, consulte “Considerações sobre direcionamento ao cliente” na Referência de Configuração do Host (SC27-8438) do IBM Explorer for z/OS.Fim da mudança

Introdução

Início da mudançaOs clientes Developer for z Systems podem puxar os arquivos de configuração do cliente e informações de atualização do produto a partir do host quando eles se conectam, assegurando que todos os clientes tenham configurações comuns e estejam atualizados. Fim da mudança

Início da mudançaO administrador de cliente pode criar diversos conjuntos de configuração de cliente e diversos cenários de atualização de cliente para ajustar às 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. Fim da mudanç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.

Um gerente de projeto de desenvolvimento define um projeto e designa desenvolvedores individuais a ele.

Consulte o Developer for z Systems IBM Knowledge Center para obter detalhes sobre como o gerenciador do projeto de desenvolvimento pode executar as tarefas designadas a ele.

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:
  • Um administrador LDAP mantém as definições do grupo que coloca cada desenvolvedor em nenhum, um ou mais grupos LDAP FEL.PTC.*.
  • Um administrador de segurança mantém listas de acessos para perfis de segurança FEL.PTC.*. Um desenvolvedor pode ser autorizado para nenhum, um ou mais perfis.

Projetos baseados no host

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

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

Para configurar projetos baseados em host, o gerente de projeto ou o desenvolvedor líder precisa definir os seguintes tipos de arquivos de configuração. Todos os arquivos são XML codificados para UTF-8.
  • Os arquivos de instância de projeto são específicos de um único ID do usuário e apontam para arquivos de definição de projeto reutilizáveis. Cada usuário que trabalha com projetos baseados em host precisa de um subdiretório, /var/zexpl/pushtoclient/projects/<userid>/, contendo um arquivo de instância do projeto (*.hbpin) para cada projeto a ser transferido por download.
  • Os arquivos de definição de projeto definem a estrutura e o conteúdo do projeto e podem ser reutilizados por diversos usuários. Os arquivos de definição de projeto (*.hbppd) listam os subprojetos contidos pelo projeto e estão localizados no diretório de definição de projeto raiz ou em um de seus subdiretórios.
  • Os arquivos de definição de subprojeto definem a estrutura e o conteúdo do subprojeto e podem ser reutilizados por diversos usuários. Os arquivos de definição de subprojeto (*.hbpsd) definem o conjunto de recursos requeridos para construir um único módulo de carregamento e estão localizados no diretório definição de projeto raiz ou em um de seus subdiretórios.
  • Os arquivos de propriedades de subprojeto são arquivos de propriedades com suporte a substituição de variável e podem ser reutilizados por diversos subprojetos. Os arquivos de propriedade de subprojeto (*.hbppr) suportam substituição de variável para permitir compartilhamento de arquivos de propriedade entre diversos usuários e estão localizados no diretório de definição de projeto raiz ou em um de seus subdiretórios.

Início da mudançaOs projetos baseados em host também são elegíveis para participar na configuração de grupos múltiplos. Essa elegibilidade significa que os projetos baseados em host podem ser definidos também em /var/rdz/pushtoclient/grouping/<devgroup>/projects/.Fim da mudança

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.

considerações CICSTS

Início da mudançaEste capítulo agrupa referências a componentes do Developer for z Systems que podem funcionar em regiões CICSTS. Fim da mudança

Início da mudança

Suporte à linguagem bidirecional

Início da mudança

Para obter mais informações sobre suporte à linguagem Bidirecional, consulte a seção "suporte à linguagem bidirecional do CICS" no capítulo "Outras tarefas de customização" do Guia de Configuração do Host (SC27-8577) do Rational Developer for z Systems.

Fim da mudança
Fim da mudança
Início da mudança

Mensagens de IRZ de diagnóstico para Ferramentas de Serviço Corporativo

Início da mudança

Para obter mais informações sobre mensagens de diagnósticos IRZ para o Enterprise Service Tools, consulte a seção "Mensagens de Diagnósticos IRZ para Enterprise Service Tools" no capítulo "Outras tarefas de customização" do Guia de Configuração do Host (SC27-8577) do Rational Developer for z Systems.

Fim da mudança
Fim da mudança

Depuração de Transação do CICS

Início da mudançaPara obter informações adicionais sobre depuração de transação do CICS, veja a seção "Atualizações do CICS do Depurador Integrado" no capítulo "(Opcional) Depurador Integrado" do IBM Rational Developer for z Systems: Guia de configuração de host (S517-9094).Fim da mudança

Configurando o AT-TLS

Essa seção é fornecida para ajudá-lo com alguns problemas comuns que podem ser encontrados durante a configuração da Segurança da Camada de Transporte Transparente do Aplicativo (AT-TLS) ou durante a verificação ou modificação de uma configuração existente.

O protocolo do Transport Layer Security (TLS) definido em RFC 2246 fornece privacidade de comunicações pela Internet. Semelhante ao seu predecessor Secure Socket Layer (SSL), o protocolo permite que aplicativos cliente e servidor se comuniquem de uma forma projetada para evitar escuta de terceiros, violação e falsificação de mensagens. O Application Transparent Transport Layer Security (AT-TLS) consolida a implementação de TLS para aplicativos baseados em z/OS em um local, permitindo que todos os aplicativos suportem a criptografia baseada em TLS sem o conhecimento do protocolo TLS. Veja o Communications Server IP Configuration Guide (SC31-8775) para obter informações adicionais sobre AT-TLS.

O Depurador Integrado do Developer for z Systems conta com o AT-TLS para comunicação criptografada com o cliente, porque os dados para a sessão de depuração não fluem pelo mesmo canal que outras comunicações do cliente com o host do Developer for z Systems.

As ações necessárias para configurar o AT-TLS variarão de acordo com o site, dependendo das necessidades exatas e dependendo do que já está disponível no site.

As informações desta seção mostram como configurar o Agente de Diretiva de TCP/IP que gerencia o AT-TLS e define uma política para o uso pelo Depurador Integrado do Developer for z Systems em um sistema z/OS 1.13, com suporte para TLS v1.2.
  1. Configurando syslogd
  2. Configuração do AT-TLS no PROFILE.TCPIP
  3. Tarefa Iniciada do Policy Agent
  4. Configuração do Policy Agent
  5. Política AT-TLS
  6. Atualizações de Segurança do AT-TLS
  7. Ativação da Política AT-TLS
Ao longo desta seção, uma convenção de nomenclatura uniforme é utilizada:
  • Porta do Debug Manager para comunicação externa: 5335
  • ID do usuário do Debug Manager: stcdbm
  • ID do usuário do Policy Agent: pagent
  • Certificado: dbgmgr
  • Armazenamento de chaves e certificados: dbgmgr.racf

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 oedit para editar arquivos no z/OS UNIX. Use o comando exit para retornar ao TSO.

Configurando syslogd

A documentação do TCP/IP recomenda escrever as mensagens do Policy Agent no syslog do z/OS UNIX em vez de usar o arquivo de log padrão. AT-TLS sempre gravará as mensagens no syslog do z/OS UNIX.

Para fazer isso, o daemon do syslog do z/OS UNIX, syslogd, deve estar configurado e ativo. Também será necessário um mecanismo para controlar o tamanho dos arquivos de log criados pelo syslogd.

As atualizações de arquivo de configuração de amostra a seguir podem ser usadas para configurar e iniciar syslogd, com um mecanismo de gerenciamento de arquivos de log simples (apague os logs existentes quando z/OS UNIX iniciar e crie novos na inicialização de syslogd).
  • /etc/services
     syslog          514/udp
  • /etc/syslog.conf
     # /etc/syslog.conf - control output of syslogd
    #  1. all files with will be printed to /tmp/syslog.auth.log
    auth.*           /tmp/syslog.auth.log
    #  2. all error messages printed to /tmp/syslog.error.log
    *.err            /tmp/syslog.error.log
    #  3. all debug and above messages printed to /tmp/syslog.debug.log
    *.debug          /tmp/syslog.debug.log
    # Os nomes de arquivos devem existir antes de o daemon syslog ser iniciado,
    # a menos que a opção de inicialização -c seja usada
  • /etc/rc
     # Inicie o daemon SYSLOGD para a criação de log
    # (limpe os logs antigos)
    sed -n '/^#/!s/.* \(.*\)/\1/p' /etc/syslog.conf | xargs -i rm {}
    # (crie novos logs e inclua o ID do usuário do emissor da mensagem)
    _BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -cuf /etc/syslog.conf &
    sleep 5

Configuração do AT-TLS no PROFILE.TCPIP

O suporte do AT-TLS é ativado pelo parâmetro TTLS na instrução TCPCONFIG no conjunto de dados PROFILE.TCPIP. AT-TLS é gerenciado pelo Policy Agent, que deve estar ativo para permitir impingir a política AT-TLS. Como o Policy Agent deve aguardar que o TCP/IP esteja ativo, a instrução AUTOSTART em PROFILE.TCPIP é um bom local para acionar a inicialização deste servidor.

Esses requisitos resultam nas mudanças a seguir para PROFILE.TCPIP, muitas vezes denominado TCPIP.TCPPARMS(TCPPROF).
 TCPCONFIG TTLS         ; Requerido para AT-TLS
AUTOLOG
  PAGENT               ; POLICY AGENT, requerido para AT-TLS
ENDAUTOLOG

Tarefa Iniciada do Policy Agent

Como mencionado anteriormente, AT-TLS é gerenciado pelo Policy Agent, que pode ser iniciado como uma tarefa iniciada. Use o JCL a seguir para criar SYS1.PROCLIB(PAGENT), usando o arquivo de configuração padrão e o local de log recomendado (SYSLOGD). As definições necessárias no software de segurança são discutidas posteriormente.
 //PAGENT   PROC PRM='-L SYSLOGD'                     * '' or '-L SYSLOGD'
//*
//* TCP/IP POLICY AGENT
//*                                        (PARM) (envar)
//* default cfg file: /etc/pagent.conf     (-C)   (PAGENT_CONFIG_FILE)
//* default log file: /tmp/pagent.log      (-L)   (PAGENT_LOG_FILE)
//* default log size: 300,3 (3x 300KB files) (PAGENT_LOG_FILE_CONTROL)
//*
//PAGENT   EXEC PGM=PAGENT,REGION=0M,TIME=NOLIMIT,
//            PARM='ENVAR("TZ=EST5DST")/&PRM' 
//SYSPRINT DD SYSOUT=* 
//SYSOUT   DD SYSOUT=* 
//*

Configuração do Policy Agent

O Policy Agent impinge as políticas relacionadas a TCP/IP, criadas pelo administrador de TCP/IP. Ele gerencia políticas para o AT-TLS, chamadas TTLS, mas também para outros serviços, como o IPSec. O Policy Agent usa um arquivo de configuração para saber quais políticas devem ser impingidas e onde elas podem ser localizadas. O arquivo de configuração padrão é /etc/pagent.conf, mas um local diferente pode ser especificado no JCL da tarefa iniciada do Policy Agent.
 #
# Informações de configuração do TCP/IP Policy Agent.
#
TTLSConfig /etc/pagent.ttls.conf
# Especifica o caminho de um arquivo de políticas TTLS que possui instruções específicas de
# pilha.
#
#TcpImage TCPIP /etc/pagent.conf
# Se nenhuma instrução TcpImage for especificada, todas as políticas serão instaladas
# à pilha TCP/IP padrão.
#
#LogLevel 31
# A soma dos valores a seguir que representam os níveis de log:
#  LOGL_SYSERR     1
#  LOGL_OBJERR     2
#  LOGL_PROTERR    4
#  LOGL_WARNING    8
#  LOGL_EVENT     16
#  LOGL_ACTION    32
#  LOGL_INFO      64
#  LOGL_ACNTING  128
#  LOGL_TRACE    256
# Nível de Log 31 é o nível de log padrão.
#
#Codepage IBM-1047
# Especifique a página de códigos EBCDIC a ser usada para a leitura de todos os arquivos de
# configuração e arquivos de definição de política. IBM-1047 é a página de códigos padrão.

Esse arquivo de configuração de amostra especifica onde o Policy Agent pode localizar a política de TTLS. Ele usa os valores padrão do Policy Agent para outras instruções.

Política AT-TLS

Uma política TTLS descreve as regras desejadas de AT-TLS. Como definido no arquivo de configuração do Policy Agent, a política do TTLS está localizada em /etc/pagent.ttls.conf. As definições necessárias no software de segurança são discutidas posteriormente.

Início da mudançaEste exemplo mostra uma política razoavelmente simples de duas regras que desativa o SSL v3 e ativa o suporte ao TLS v1, TLS v1.1 e TLS v1.2 para ambos os caminhos de comunicação suportados pelo Depurador Integrado, Debug Manager e Probe-Client do Developer for z Systems. Como definido no arquivo de configuração do Policy Agent, a política do TTLS está localizada em /etc/pagent.ttls.conf.
 ##
## Informações de configuração do TCP/IP Policy Agent AT-TLS.
##
##-----------------------------
TTLSRule                      RDz_Debug_Manager
{
 LocalPortRange           5335
 Direction                Inbound
 TTLSGroupActionRef       grp_Production
 TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction         act_RDz_Debug_Manager
{
 HandshakeRole Server
 TTLSKeyRingParms
 {
  Keyring dbgmgr.racf     # Keyring must be owned by the Debug Manager
 }
 TTLSEnvironmentAdvancedParms
 {
## TLSV1.2 apenas para z/OS 2.1 e superior
Início da mudança# TLSV1.2 On               # TLSv1 & TLSv1.1 are on by default
  SSLV3 Off                # disable SSLv3Fim da mudança }
}
##-----------------------------
TTLSRule                      RDz_Debug_Probe-Client
{
 RemotePortRange          8001
 Direção                  Saída
 TTLSGroupActionRef       grp_Production
 TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction         act_RDz_Debug_Probe-Client
{
 HandshakeRole            Cliente
 TTLSKeyRingParms
 {
  Keyring *AUTH*/*         # conjunto de chaves virtuais que possuem certificados de CA
 }
 TTLSEnvironmentAdvancedParms
 {
## TLSV1.2 apenas para z/OS 2.1 e superior
Início da mudança# TLSV1.2 On               # TLSv1 & TLSv1.1 are on by defaultFim da mudança
 }
}
##-----------------------------
TTLSGroupAction               grp_Production
{
 TTLSEnabled              On
## TLSv1.2zOS1.13 apenas para z/OS 1.13
 TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
 Trace                     3     # Registrar Erros para syslogd & IP joblog
#Trace                            254  # Registrar tudo para syslogd
}
##-----------------------------
TTLSGroupAdvancedParms        TLSv1.2zOS1.13
{
 Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}
Fim da mudança

Uma política TTLS permite um intervalo amplo de filtros para especificar quando uma regra é aplicada.

O Debug Manager é um servidor que recebe conexões de entrada do Mecanismo de Depuração na porta 5335. Essas informações são capturadas na regra RDz_Debug_Manager.

Como a comunicação criptografada requer o uso de um certificado do servidor, você especifica que o Policy Manager deve usar os certificados no conjunto de chaves dbgmgr.racf, que pertence ao ID do usuário da tarefa iniciada do Debug Manager. Por padrão, o suporte de TLS v1.2 está desativado, então essa política o ativa explicitamente. O SSLv3.0 é desativado explicitamente devido a vulnerabilidades conhecidas nesse protocolo.

Quando a Análise de Depuração é iniciada com a opção Ambiente de Linguagem (LE) TEST(,,,TCPIP&&ipaddress%8001:*), é indicado que não se use o Debug Manager, mas entre em contato diretamente com o cliente do Developer for z Systems na porta 8001. Isso implica, de uma perspectiva do TCP/IP, que a Análise de Depuração baseada no host é um cliente contatando um servidor(a UI de Depuração) no cliente do Developer for z Systems. Essas informações são capturadas na regra RDz_Debug_Probe-Client.

Com o host sendo um cliente TCP/IP, o Policy Manager precisará de uma maneira de validar o certificado do servidor apresentado pela UI de Depuração. Em vez de usar um conjunto de chaves uniformemente nomeado para todos os usuários que podem requerer uma sessão de depuração criptografada, estamos usando o conjunto de chaves virtual CERTAUTH do RACF (*AUTH*/*). Esse conjunto de chaves virtuais contém os certificados públicos das Autoridades de Certificação (CAs) e podem ser usados se a UI de Depuração apresentar um certificado do servidor assinado por uma das CAs confiáveis.

Observe que, para políticas mais complexas, você deve usar o IBM Configuration Assistant para z/OS Communications Server. Essa é uma ferramenta baseada em GUI que fornece uma interface guiada para a configuração das funções de rede baseadas em políticas de TCP/IP e está disponível como uma tarefa em IBM z/OS Management Facility (z/OSMF), e como um aplicativo de estação de trabalho independente.

Considerações sobre o TLS v1.2

O suporte de TLS v1.2 tornou-se disponível no z/OS 2.1, e está desativado por padrão. Essa política mostra o comando (TLSV1.2 On) para ativá-lo explicitamente, mas a linha está comentada visto que o sistema de destino está usando o z/OS 1.13.

Ao aplicar os dois APARs a seguir, o suporte de TLS v1.2 é incluído ao z/OS 1.13:
  • System SSL APAR OA39422
  • Communications Server (AT-TLS) APAR PM62905
O z/OS 1.13 System SSL, que é usado pelo AT-TLS para implementar a comunicação criptografada, requer alguns parâmetros adicionais para o suporte do TLS v1.2. Estes são fornecidos por meio da política AT-TLS usando um arquivo com variáveis de ambiente do System SSL, /etc/pagent.ttls.TLS1.2zOS1.13.env.
 #
# Inclua o suporte de TLSv1.2 para AT-TLS
# requer z/OS 1.13 com OA39422 e PM62905
#
 GSK_RENEGOTIATION=ALL
 GSK_PROTOCOL_TLSV1_2=ON

Atualizações de Segurança do AT-TLS

Há várias atualizações necessárias para sua configuração de segurança para AT-TLS funcionar apropriadamente. Esta seção possui os comandos RACF de amostra para executar a configuração necessária.

Como mencionado em Tarefa Iniciada do Policy Agent, você usa uma tarefa iniciada para executar o Policy Agent. Isso requer a definição de um ID do usuário de tarefa iniciada e um perfil na classe STARTED.
 #  defina o ID do usuário da tarefa iniciada
#  a permissão BPX.DAEMON é necessária para o UID não zero
 ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
   NAME('TCP/IP POLICY AGENT') NOPASSWORD

#  defina a tarefa iniciada
 RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
   DATA('TCP/IP POLICY AGENT')

#  atualize para tornar as mudanças visíveis
 SETROPTS RACLIST(STARTED) REFRESH
Defina um perfil denominado MVS.SERVMGR.PAGENT na classe OPERCMDS e forneça o acesso PAGENT CONTROL do ID do usuário para ele. O perfil restringe quem pode iniciar o Policy Agent. Se o perfil não estiver definido e o acesso a ele for evitado através de um perfil genérico, PAGENT não poderá iniciar o Policy Agent, o que evitará a inicialização de pilha TCP/IP.
 #  restrinja a inicialização do policy agent
 RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
   DATA('restrict startup of policy agent')
 PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)

#  atualize para tornar as mudanças visíveis 
SETROPTS RACLIST(OPERCMDS) REFRESH 
Como mencionado em Configuração do AT-TLS no PROFILE.TCPIP, o Policy Agent é iniciado após a inicialização do TCP/IP. Isso significa que há uma (pequena) janela em que os aplicativos podem usar a pilha TCP/IP sem impingir a política de TTLS. Defina o perfil EZB.INITSTACK.** na classe SERVAUTH para evitar o acesso à pilha durante esse período de tempo, exceto para aplicativos com acesso READ ao perfil. Deve-se permitir um conjunto limitado de aplicativos administrativos para o perfil para assegurar inicialização completa da pilha, conforme documentado em “TCP/IP stack initialization access control” no Communications Server IP Configuration Guide (SC31-8775).
Nota: Início da mudançaO Agente de diretiva emitirá a mensagem EZD1586I quando todas as políticas estiverem ativas. Fim da mudança
 #  bloqueie o acesso de pilha entre a pilha e a disponibilidade de AT-TLS
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
 RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
#  Policy Agent
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
#  OMPROUTE daemon
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
#  agente e sub-agentes SNMP
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
#  daemon NAME
 PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)

#  atualize para tornar as mudanças visíveis
 SETROPTS RACLIST(SERVAUTH) REFRESH
(Opcional) O comando pasearch do z/OS UNIX exibe as definições de políticas ativas. Defina o perfil EZB.PAGENT.** na classe SERVAUTH para restringir o acesso ao comando pasearch.
 #  restrinja o acesso ao comando pasearch
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) + 
#   DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)

#  atualize para tornar as mudanças visíveis
# SETROPTS RACLIST(SERVAUTH) REFRESH
Início da mudançaConforme mencionado em Política AT-TLS, o Debug Manager precisa de um certificado para que o AT-TLS possa configurar a comunicação criptografada em nome do Debug Manager. Esses comandos de amostra criam um novo certificado denominado dbgmgr, armazenado em um conjunto de chaves RACF denominado dbgmgr.racf. Ambos o certificado e o conjunto de chaves são de propriedade do STCDBM, o ID do usuário da tarefa iniciada do Debug Manager.
 #  permita que o Debug Manager acesse os certificados
#RDEFINE FACILITY IRR.DIGTCERT.LIST     UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
 PERMIT IRR.DIGTCERT.LIST     CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
 PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)

#  atualize para tornar as mudanças visíveis
 SETROPTS RACLIST(FACILITY) REFRESH

#  crie certificado autoassinado
 RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
   OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
   NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')

#  (opcional) etapas adicionais necessárias para usar um certificado assinado
#  1. crie uma solicitação de assinatura para o certificado autoassinado
 RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
#  2. envie a solicitação de assinatura para a CA de sua escolha
#  3. verifique se as credenciais de CA (também um certificado) já são conhecidas
 RACDCERT CERTAUTH LIST
#  4. marque o certificado de CA como confiável
 RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
#     ou inclua o certificado de CA no banco de dados
 RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
#  5. inclua o certificado assinado no banco de dados;
#     isso substituirá o autoassinado
 RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
#     NÃO exclua o certificado autoassinado antes de substituí-lo.
#     Se você fizer isso, perderá a chave privada fornecida com o certificado,
#     o que torna o certificado inútil.

#  crie o conjunto de chaves
 RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)

#  inclua o certificado ao conjunto de chaves
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
   RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)

#  etapa adicional necessária para usar um certificado assinado
#  6. inclua o certificado de autoridade de certificação ao conjunto de chaves
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
   RING(dbgmgr.racf))

#  atualize para tornar as mudanças visíveis
 SETROPTS RACLIST(DIGTCERT) REFRESH
Fim da mudança
A política AT-TLS também documenta o uso do conjunto de chaves virtuais CERTAUTH para validação do certificado do servidor apresentado pela UI de Depuração no cenário Cliente de Análise. Isso implica que o certificado CA usado pelo Debug UI é confiável por seu host z/OS.
 #  verifique se as credenciais de CA (também um certificado) já são conhecidas
 RACDCERT CERTAUTH LIST
#  marque o certificado de CA como confiável
 RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
#     ou inclua o certificado de CA no banco de dados
 RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST

#  atualize para tornar as mudanças visíveis
 SETROPTS RACLIST(DIGTCERT) REFRESH
Use os comandos a seguir para verificar sua configuração:
 #  verifique a configuração da tarefa iniciada
 LISTGRP SYS1 OMVS
 LISTUSER PAGENT OMVS
 RLIST STARTED PAGENT.* ALL STDATA

#  verifique a permissão de inicialização do Policy Agent
 RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL

#  verifique a proteção initstack
 RLIST SERVAUTH EZB.INITSTACK.** ALL

#  verifique a proteção pasearch
 RLIST SERVAUTH EZB.PAGENT.** ALL

#  verifique a configuração do certificado
 RACDCERT CERTAUTH   LIST(LABEL('CA cert'))
 RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
 RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)

Ativação da Política AT-TLS

A configuração de AT-TLS está concluída e a política será ativada no próximo carregamento inicial de programas do sistema. Siga estas etapas para iniciar o uso da política sem um carregamento inicial de programas:
  1. Ative o suporte de AT-TLS na pilha TCP/IP.
    Crie um arquivo obey TCP/IP, por exemplo, TCPIP.TCPPARMS(OBEY), com o conteúdo a seguir:
     TCPCONFIG TTLS
    Ative-o com este comando do operador:
     V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
    Verifique o resultado verificando esta mensagem do console:
     EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
  2. Inicie o Policy Agent.
    Emita o comando do operador:
     S PAGENT
    Verifique o resultado verificando a mensagem do console:
     EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
  3. Reinicie o Debug Manager para interromper todas as sessões ativas não criptografadas.
    Emita os comandos do operador:
     P DBGMGR
    S DBBMGR

Publicações Referenciadas

As publicações a seguir são referenciadas neste documento:

Tabela 11. Publicações Referenciadas
Título da publicação Número da ordem Referência Web site de referência
Diretório do Programa para IBM Rational Developer for z Systems GI11-8298 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Program Directory for IBM Rational Developer for z Systems Host Utilities GI13-2864 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
       
Guia de Configuração de Host do IBM Rational Developer for z Systems SC27-8577 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
IBM Rational Developer for z SystemsReferência de Configuração do Host SC27-8578 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
IBM Rational Developer for z Systems Common Access Repository Manager Developer's Guide SC23-7660 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
SCLM Developer Toolkit: Guia do Administrador SC23-9801 Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
IBM Explorer for z/OS Host Configuration Guide SC27-8437 z/OS Explorer  
Referência de Configuração de Host do IBM Explorer for z/OS SC27-8438 z/OS Explorer  
Início da mudançaCommunications Server IP CICS Sockets GuideFim da mudança Início da mudançaSC31-8807Fim da mudança Início da mudançaz/OS 1.13Fim da mudança Início da mudançahttp://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/Fim da mudança
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/
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 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/
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/
Os Web sites a seguir são referidos neste documento:
Tabela 12. Web Sites Referidos
Descrição Web site de referência
Developer for z Systems IBM Knowledge Center http://www-01.ibm.com/support/knowledgecenter/SSQ2R2/rdz_welcome.html
Biblioteca do Developer for z Systems http://www-01.ibm.com/support/docview.wss?uid=swg27038517
Developer for z Systems: Página Inicial http://www-03.ibm.com/software/products/en/developerforsystemz/
Serviço recomendado do Developer for z Systems http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335
Solicitação de aprimoramento de Developer for z Systems https://www.ibm.com/developerworks/support/rational/rfe/
Download do Apache Ant http://ant.apache.org/

Publicações Informativas

As publicações a seguir podem ser úteis para você compreender os problemas de configuração dos componentes do sistema host necessários:
Tabela 13. Publicações Informativas
Título da publicação Número da ordem Referência Website de referência
ABCs do z/OS System Programming Volume 9 (z/OS UNIX) SG24-6989 Redbook http://www.redbooks.ibm.com/
Guia do Programador de Sistema’ para: Workload Manager SG24-6472 Redbook http://www.redbooks.ibm.com/
Implementação do TCPIP Volume 1: Funções Base, Conectividade e Roteamento SG24-7532 Redbook http://www.redbooks.ibm.com/
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance SG24-7534 Redbook http://www.redbooks.ibm.com/
TCP/IP Implementation Volume 4: Security and Policy-Based Networking SG24-7535 Redbook http://www.redbooks.ibm.com/
Tivoli Directory Server para z/OS SG24-7849 Redbook http://www.redbooks.ibm.com/

Glossário

Ação de Bloqueio
Bloqueia um membro.
Application Server
  1. Um programa que manipula todas as operações do aplicativo entre computadores baseados em navegador e aplicativos ou bancos de dados de negócios de back-end da organização. Essa é uma classe especial de servidores de aplicativos baseados em Java que seguem o padrão Java EE. O código do Java EE pode ser facilmente colocado entre esses servidores de aplicativos. Pode suportar JSPs e servlets para conteúdo da Web dinâmico e EJBs para transações e acesso ao banco de dados.
  2. O destino de um pedido de um aplicativo remoto. No ambiente do DB2, a função de servidor de aplicativos é fornecida pelo recurso de dados distribuídos e é utilizada para acessar os dados do DB2 a partir de aplicativos remotos.
  3. Um programa do servidor em uma rede distribuída que fornece o ambiente de execução para um programa aplicativo.
  4. O destino de um pedido de um solicitador de aplicativo. O sistema de gerenciamento de banco de dados (DBMS) no site do servidor de aplicativos fornece os dados solicitados.
  5. Software que manipula a comunicação com o cliente que está solicitando um recurso e consultas do Content Manager.
Atributo Bidirecional
Tipo de Texto, Orientação de Texto, Troca Numérica e Troca Simétrica.
Arquivo de Resposta
  1. Um arquivo que contém um conjunto de respostas predefinidas para perguntas feitas por um programa e que é usado para que não seja necessário digitar esses valores um a um.
  2. Um arquivo ASCII que pode ser customizado com os dados de definição e de configuração e que automatiza uma instalação. Os dados de definição e de configuração seriam digitados durante uma instalação interativa, mas com um arquivo de resposta a instalação pode prosseguir sem nenhuma intervenção.
Banco de Dados
Um conjunto de itens de dados inter-relacionados ou independentes que são armazenados para servir um ou mais aplicativos.
Biblioteca de Carregamento
Uma biblioteca que contém módulos de carregamento.
Bidirecional (bi-di)
Pertencente a scripts, como Árabe e Hebraico, que geralmente são executados da direita para a esquerda, exceto números, que são executados da esquerda para a direita. Essa definição é do Glossário LISA (Localization Industry Standards Association).
Buffer de Erro
Uma parte do armazenamento utilizada para conter temporariamente informações de saída de erro.
Compilar
  1. Em linguagens ILE (Integrated Language Environment), para converter instruções de origem em módulos que, então, podem ser ligados a programas ou programas de serviços.
  2. Para traduzir todo o programa ou parte dele, expresso em um idioma de alto nível em um programa de computador expresso em uma linguagem intermediária, uma linguagem Assembly ou uma linguagem da máquina.
Contêiner
  1. No CoOperative Development Environment/400, um objeto de sistema que contém e organiza arquivos de origem. Uma biblioteca i5/OS ou um conjunto de dados particionado por MVS são exemplos e um contêiner.
  2. No Java EE, uma entidade que fornece serviços de gerenciamento de ciclo de vida, segurança, implementação e tempo de execução para componentes. (Sun) Cada tipo de contêiner (EJB, Web, JSP, servlet, applet e cliente aplicativo) também fornece serviços específicos ao componente
  3. Em Serviços de Recuperação e Mídia de Backup, o objeto físico usado para armazenar e mover mídia, como uma caixa, um estojo ou um rack.
  4. Em um servidor de fita virtual (VTS), um receptáculo em que um ou mais volumes lógicos exportados (LVOLs) podem ser armazenados. Um volume temporário que contém um ou mais LVOLs e reside fora de uma biblioteca de VTS é considerado o contêiner para esses volumes.
  5. Uma localização do armazenamento físico dos dados. Por exemplo, um arquivo, um diretório ou um dispositivo.
  6. Uma coluna ou uma linha que é usada para organizar o layout de um portlet ou outro contêiner em uma página.
  7. Um elemento da interface com o usuário que contém objetos. No gerenciador de pastas, um objeto que pode conter outras pastas ou documentos.
Conjunto de Dados
A principal unidade de armazenamento e recuperação de dados, que consiste em um conjunto de dados em uma das muitas organizações prescritas e descritas pelas informações de controle às quais o sistema tem acesso.
Depurar
Para detectar, diagnosticar e eliminar erros em programas.
Desinstalação Silenciosa
Um processo de desinstalação que não envia mensagens para o console, mas armazena mensagens e erros em arquivos de log depois que o comando de desinstalação é invocado.
Gateway
  1. Um componente de middleware que faz uma ponte entre a Internet e os ambientes de intranet durante chamadas de serviço da Web.
  2. Software que fornece serviços entre os nós de extremidades e o restante do ambiente Tivoli.
  3. Um componente de um VoIP (Voice over Internet Protocol) que fornece uma ponte entre o VoIP e ambientes alternados em circuito.
  4. Um dispositivo ou um programa usado para conectar redes ou sistemas com diferentes arquiteturas de rede. Os sistemas podem ter diferentes características, como protocolos de comunicação diferentes, arquitetura da rede diferente ou políticas de segurança diferentes; nesse caso, o gateway desempenha a função de tradução e também de conexão.
ID da Ação
Um identificador numérico para uma ação entre 0 e 999
Interactive System Productivity Facility (ISPF)
Um programa licenciado IBM que serve como um editor de tela inteira e um gerenciador de diálogos. Utilizado para gravar programas aplicativos, permite gerar painéis de tela padrão e diálogos interativos entre o programador do aplicativo e o usuário terminal. O ISPF consiste em quatro componentes principais: o DM, o PDF, o SCLM e o C/S. O componente DM é o Dialog Manager, que fornece serviços para diálogos e usuários finais. O componente PDF é o Program Development Facility, que fornece serviços para auxiliar o diálogo ou o desenvolvedor de aplicativos. O componente SCLM é o Software Configuration Library Manager, que fornece serviços para que desenvolvedores de aplicativos gerenciem suas bibliotecas de desenvolvimento de aplicativos. O componente C/S é o Client/Server, que permite executar o ISPF em uma estação de trabalho programável, para exibir os painéis que usam a função de exibição do sistema operacional da estação de trabalho e para integrar ferramentas e dados da estação de trabalho a ferramentas e dados do host.
Intérprete
Um programa que traduz e executa cada instrução de uma linguagem de programação de alto nível antes de traduzir e executar a próxima instrução.
Instalação Silenciosa
Uma instalação que não envia mensagens para o console, mas armazena mensagens e erros em arquivos de log. Além disso, uma instalação silenciosa pode utilizar arquivos de resposta para entrada de dados.
Instância do Repositório
Um projeto ou um componente que existe em um SCM.
Isomórfico
Cada elemento composto (em outras palavras, um elemento contendo outros elementos) do documento da instância XML iniciando a partir da raiz tem um, e apenas um, item do grupo COBOL correspondente cuja profundidade de aninhamento é idêntica à profundidade de aninhamento de seu equivalente XML. Cada elemento não-composto (em outras palavras, um elemento que não contém outros elementos) do documento da instância XML iniciando a partir da parte superior tem um e apenas um item elementar COBOL correspondente cuja profundidade de aninhamento é idêntica ao nível de aninhamento de seu equivalente XML e cujo endereço de memória no tempo de execução pode ser exclusivamente identificado.
Lista de Tarefas
Uma lista de procedimentos que podem ser executados por um único fluxo de controle.
Não isomórfico
Um mapeamento simples de itens COBOL e elementos XML pertencentes a documentos XML e grupos COBOL que não têm formas idênticas (não-isomórfico). O mapeamento não-isomórfico também pode ser criado entre elementos não-isomórficos de estruturas isomórficas.
Nome da Shell
O nome da interface shell.
Perspectiva
Um grupo de visualizações que mostram vários aspectos dos recursos do ambiente de trabalho. O usuário do ambiente de trabalho pode alternar perspectivas, dependendo da tarefa disponível, e customizar o layout de visualizações e editores na perspectiva.
Perspectiva Sistemas Remotos
Fornece uma interface para gerenciar sistemas remotos utilizando convenções semelhantes a ISPF.
RAM
Repository Access Manager
Repositório
  1. Uma área de armazenamento de dados. Cada repositório tem um nome e um tipo de item de negócios associado. Por padrão, o nome será igual ao nome do item de negócios. Por exemplo, um repositório para faturas será chamado Faturas. Há dois tipos de repositórios de informações: local (específico ao processo) e global (reutilizável).
  2. Um conjunto de dados VSAM em que os estados de processos BTS são armazenados. Quando um processo não está sendo executado sob o controle do BTS, seu estado (e os estados de suas atividades constituintes) é preservado com a gravação em um conjunto de dados do repositório. Os estados de todos os processos de um tipo de processo específico (e de suas instâncias de atividade) são armazenados no mesmo conjunto de dados do repositório. Registros de vários tipos de processo podem ser gravados no mesmo repositório.
  3. Uma área de armazenamento persistente para código de origem e outros recursos de aplicativo. Em um ambiente de programação em equipe, um repositório compartilhado permite o acesso de multiusuários aos recursos de aplicativo.
  4. Um conjunto de informações sobre os gerenciadores de filas que são membros de um cluster. Essas informações incluem nomes de gerenciadores de filas, seus locais, seus canais, quais filas eles hospedam, etc.
Seção de Ligação
A seção da divisão de dados de uma unidade ativada (um programa chamado ou um método invocado) que descreve itens de dados disponíveis da unidade de ativação (um programa ou um método). Esses itens de dados podem ser usados como referência tanto pela unidade ativada quanto pela unidade de ativação.
Sessão de Depuração
As atividades de depuração que ocorrem entre o momento em que o desenvolvedor inicia um depurador e o momento em que ele sai dali.
Shell
Uma interface de software entre usuários e o sistema operacional que interpreta comandos e interações com o usuário e comunica-os ao sistema operacional. Um computador pode ter várias camadas de shells para diversos níveis de interação com o usuário.
Script da Shell
Um arquivo que contém comandos que podem ser interpretados pelo shell. O usuário digita o nome do arquivo de script no prompt do comando shell para fazer com que a shell execute os comandos do script.
Sidedeck
Uma biblioteca que publica as funções de um programa DLL. Os nomes de entrada e de módulo são armazenados na biblioteca após a compilação do código de origem.
Sistema de Arquivo Remoto
Um sistema de arquivo que reside em um servidor ou sistema operacional separado.
Sistema Remoto
Qualquer outro sistema na rede com o qual o sistema possa se comunicar.
Solicitação de Construção
Um pedido do cliente para executar uma transação de construção.
Transação de Construção
Uma tarefa iniciada no MVS para executar construções após um pedido de construção ser recebido do cliente.
Visualização Definição de Dados
Contém uma representação local de bancos de dados e seus objetos e fornece recursos para manipular esses objetos e exportá-los para um banco de dados remoto
Visualização Navegador
Fornece uma visualização hierárquica dos recursos do Ambiente de Trabalho.
Visualização Console de Saída
Exibe a saída de um processo e permite fornecer entrada do teclado a um processo.
Visualização Saída
Exibe mensagens, parâmetros e resultados relacionados aos objetos com os quais você trabalha
Visualização Repositórios
Exibe os locais de repositório CVS que foram incluídos no Ambiente de Trabalho.
Visualização Servidores
Exibe uma lista de todos os servidores e as configurações associadas a eles.
URL
Uniform Resource Locator

Avisos

Estas informações foram desenvolvidas para produtos e serviços oferecidos nos EUA. Este material pode estar disponível na IBM em ouros idiomas. No entanto, pode ser necessário possuir uma cópia do produto ou da versão do produto nesse idioma a fim de acessá-lo.

É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos nesta publicação em outros países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM poderá ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não IBM são de responsabilidade do cliente.

A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta publicação. O fornecimento desta publicação não lhe garante direito algum sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:

Gerência de Relações Comerciais e Industriais da IBM Brasil
IBM Brasil - Centro de Traduções
Botafogo
Rio de Janeiro, RJ
BR

Para consultas sobre licença relacionadas 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 consultas, por escrito, para:

Intellectual Property Licensing
Legal and Intellectual Property Law
2-31 Roppongi 3-chome, Minato-ku
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan

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. Periodicamente, são feitas alterações 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.

Quaisquer referências nestas informações a websites não IBM são fornecidas apenas por conveniência e não servem de maneira alguma como 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 usar ou distribuir todas as informações fornecidas da forma que julgar apropriada, sem incorrer em qualquer obrigação para o Cliente.

Portadores de Licenças deste programa que desejarem ter informações sobre ele com a finalidade de: (i) troca de informações entre programas criados de forma independente de outros programas (inclusive este) e (ii) o uso mútuo de informações trocadas, deverão entrar em contato com:

Gerência de Relações Comerciais e Industriais da IBM Brasil
IBM Brasil - Centro de Traduções
Botafogo
Rio de Janeiro, RJ
BR

Estas informações podem estar disponíveis, sujeitas a termos e condições apropriados, 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.

Os exemplos de clientes e dados de desempenho citados são apresentados com propósitos meramente ilustrativos. Os resultados de desempenho reais podem variar, dependendo de configurações e condições operacionais específicas.

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 esses produtos e não pode confirmar a precisão de desempenho, compatibilidade ou qualquer outra solicitação relacionada a produtos não IBM. Dúvidas sobre os recursos de produtos não IBM deverão ser direcionadas para os fornecedores desses produtos.

As instruções relacionadas aos objetivos e direções futuras da IBM estão sujeitas a mudanças ou cancelamento sem aviso prévio e representam apenas metas e objetivo.

Estas informações contêm exemplos de dados e relatórios utilizados em operações de negócios diárias. Para ilustrá-los da forma mais completa possível, os exemplos incluem nomes de pessoas, empresas, marcas e produtos. Todos esses nomes são fictícios e qualquer semelhança com pessoas ou empresas reais é mera coincidência.

LICENÇA DE DIREITOS AUTORAIS:

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 minuciosamente testados sob 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 se responsabiliza por nenhum dano decorrente do uso dos programas de amostra.

Informações da interface de programação

Marcas Registradas

IBM, o logotipo IBM e ibm.com são marcas comerciais 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 comerciais da IBM está disponível na web em "Informações de marca comercial e copyright" em www.ibm.com/legal/copytrade.shtml.

Termos e condições para a documentação do produto

Permissões para o uso destas publicações são concedidas sujeitas aos termos e condições a seguir.

Aplicação

Esses termos e condições adicionam-se a quaisquer termos de uso para o website da IBM.

Uso pessoal

É possível reproduzir essas publicações para uso pessoal não comercial, desde que todos os avisos do proprietário sejam preservados. O Cliente não pode distribuir, exibir ou fazer trabalho derivado destas publicações, ou qualquer parte delas, sem o consentimento expresso da IBM.

Uso Comercial

O cliente pode reproduzir, distribuir e exibir essas publicações unicamente dentro de sua empresa, contanto que todos os avisos do proprietário sejam preservados. O Cliente não pode fazer trabalhos derivados destas publicações ou reproduzir, distribuir ou exibir estas publicações, ou qualquer parte delas, fora de sua empresa, sem o consentimento expresso da IBM.

Direitos

Exceto quando concedido expressamente nesta permissão, nenhuma outra permissão, licença ou direito será concedida, seja de maneira expressa ou implícita, para as publicações ou quaisquer informações, dados ou software ou outra propriedade intelectual nela contida.

A IBM reserva-se o direito de retirar as permissões concedidas aqui sempre que, a seu critério, o uso das publicações for prejudicial ao seu interesse ou, conforme determinado pela IBM, as instruções anteriores não estiverem sendo seguidas adequadamente.

O Cliente não pode fazer download, exportar ou reexportar estas informações, exceto em conformidade total com todas as leis e regulamentações aplicáveis, incluindo todas as leis e regulamentações de exportação nos Estados Unidos.

A IBM NÃO FORNECE GARANTIA QUANTO AO CONTEÚDO DESTAS PUBLICAÇÕES. AS PUBLICAÇÕES SÃO FORNECIDAS "NO ESTADO EM QUE SE ENCONTRAM" E SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS A ELAS NÃO SE LIMITANDO, AS GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO, NÃO INFRAÇÃO E ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.

Licença de Copyright

Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicas de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes programas de exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra são fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não é responsável por nenhum dano decorrente do uso dos programas de amostra.

Reconhecimentos de Marca Registrada

IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines Corp., registradas em vários países no mundo todo. Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM está disponível na Web em www.ibm.com/legal/copytrade.shtml.

Adobe e PostScript são marcas comerciais da Adobe Systems Incorporated.

Cell Broadband Engine - Sony Computer Entertainment Inc.

Rational é uma marca comercial da International Business Machines Corporation e do Rational Software Corporation, nos Estados Unidos, em outros países ou em ambos.

Intel, Intel Centrino, Intel SpeedStep, Intel Xeon, Celeron, Itanium, e Pentium são marcas comerciais da Intel Corporation nos Estados Unidos, em outros países ou em ambos.

IT Infrastructure Library é uma marca comercial da Central Computer and Telecommunications Agency

ITIL é uma marca comercial do The Minister for the Cabinet Office

Linear Tape-Open, LTO e Ultrium são marcas comerciais de HP, IBM Corp. e Quantum

Linux são marcas comerciais do Linus Torvalds

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.