Preparando o Resource Recovery Services (RRS)

O WebSphere Application Server for z/OS usa o Resource Recovery Services (RRS) para oferecer suporte à confirmação de transação de duas fases.

Sobre Esta Tarefa

Nota: O RRS deve estar ativo e em execução antes de os servidores WebSphere Application Server for z/OS serem iniciados. Consulte z/OS MVS Programming: Resource Recovery (SA22-7616) para obter mais informações.

Normalmente, todos os sistemas em um sysplex compartilham um conjunto comum de logs RRS para processamento de ponto de sincronização. Se desejar associar sistemas específicos em um sysplex para processamento de ponto de sincronização, será possível especificar um nome do grupo de logs quando iniciar o RRS. O nome do grupo de logs padrão é o nome do sysplex. Se você especificar um nome de grupo de logs diferente quando iniciar o RRS, ele coordenará o processamento de syncpoint com todos os sistemas no sysplex que utilizam o mesmo nome do grupo de logs do RRS.

O RRS utiliza cinco fluxos de log que são compartilhados pelos sistemas no grupo de logs. Cada imagem do MVS que executa o RRS precisa de acesso ao recurso de acoplamento e o DASD no qual os fluxos de log do criador de logs do sistema estão definidos para seu grupo de logs.
Nota: É possível definir fluxos de log de RRS como fluxos de log do recurso de acoplamento ou como fluxos de log apenas do DASD.

Se estiver utilizando fluxos de log do recurso de acoplamento, as imagens do RRS em sistemas diferentes em um sysplex serão executadas de maneira independente, mas compartilharão fluxos de log para monitorar o trabalho. Se um sistema falhar, uma instância de RRS em um sistema diferente no sysplex poderá utilizar os logs compartilhados para assumir o controle do trabalho do sistema que falhou.

Utilize fluxos de log apenas do DASD somente em sysplexes de sistema único com uma imagem do RRS ou um sysplex no qual as informações não devem ser compartilhadas entre imagens do RRS.

A lista a seguir resume os logs de RRS. Na lista, lgname é o nome do grupo de logs. O nome do grupo de logs padrão é o nome do sysplex.
ATR.lgname.ARCHIVE
Informações sobre URs (Units of Recovery) concluídas. Este fluxo de log é recomendado, mas é opcional.
ATR.lgname.RM.DATA
Informações sobre os gerenciadores de recursos que utilizam serviços RRS.
ATR.lgname.MAIN.UR
O estado de URs ativos. O RRS move periodicamente estas informações para o log de estado do UR retardado do RRS quando a conclusão do UR é retardada.
ATR.lgname.DELAYED.UR
O estado de URs ativos quando a conclusão do UR é retardada.
ATR.lgname.RESTART
Informações sobre URs não concluídos necessários durante o reinício. Estas informações permitem que uma instância de RRS em funcionamento assuma o controle do trabalho não concluído deixado por uma instância de RRS que falhou.

Em um sysplex de vários sistemas, os fluxos de log de RRS normalmente devem residir em um recurso de acoplamento.

Todos os registros de transações do RRS para o WebSphere Application Server for z/OS ocorrerão unicamente no fluxo de log DELAYED.UR. Ainda é possível configurar o fluxo de log MAIN.UR para que ele possa lidar com uma carga de trabalho de produção, caso você implemente um novo contêiner ou a infraestrutura do WebSphere Application Server for z/OS seja alterada. O WebSphere Application Server for z/OS não tem impacto significativo nos logs RM.DATA ou RESTART.

Utilize as seguintes etapas para configurar o RRS.

Procedimento

  1. Copie o procedimento catalogado do RRS, ATRRRS, de SYS1.SAMPLIB para SYS1.PROCLIB (ou outro proclib na concatenação MSTJCLxx) e renomeie-o como RRS.

    Se desejar, será possível configurar o nome do grupo de registros (GNAME) no procedimento catalogado de RRS para um valor específico. No entanto, se você for compartilhar o proc ATRRRS entre vários sistemas, talvez prefira definir o nome do grupo de logs na inicialização do RRS ou utilizar uma variável do sistema em IEASYMxx para definir cada nome do grupo de logs de RRS do sistema.

  2. Estabeleça a prioridade de dispatch do espaço de endereço de RRS.

    A melhor maneira de controlar a prioridade de dispatch de RRS é utilizando o WLM (Workload Manager). A IBM® recomenda que você coloque o RRS na classe de serviço SYSSTC. A classe de serviço escolhida deve fornecer ao RRS uma prioridade de dispatch maior ou igual à prioridade de dispatch de aplicativos e gerenciadores de recursos que utilizam o RRS. SYSSTC geralmente fará isso. Para obter informações sobre as classes de serviço fornecidas pelo sistema, consulte z/OS MVS Planning: Workload Management (SA22-7602).

  3. Defina o RRS como um subsistema.
    Coloque a seguinte instrução em um membro IEFSSNxx parmlib ativo:
    SUBSYS SUBNAME(RRS)
    Coloque esta instrução após a instrução que define o subsistema principal. O nome do subsistema (RRS) deve corresponder ao nome do procedimento catalogado do RRS. Para obter informações adicionais sobre o IEFSSNxx, consulte z/OS MVS Initialization and Tuning Reference (SA22-7592).
    Nota: O RRS não suporta a definição de subsistema dinâmico, portanto, não é possível utilizar o comando SETSSI ADD,SUBNAME=RRS para definir o RRS como um subsistema. Mesmo que este comando pareça ser bem-sucedido, as tentativas subsequentes de iniciar o RRS falharão.
  4. Configure os fluxos de log do RRS.
  5. Inicie o RRS.
    • Para iniciar o RRS com um nome de grupo de logs específico, "lgname", insira o seguinte comando de console do MVS:
      START RRS,GNAME=lgname
    • Para parar o RRS, insira o seguinte comando de console do MVS:
      SETRRS CANCEL
      Nota: Não pare o RRS enquanto os servidores WebSphere Application Server for z/OS estiverem em execução.

O que Fazer Depois

Para obter informações adicionais sobre como configurar e executar o RRS, consulte z/OS MVS Programming: Resource Recovery (SA22-7616).

Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tins_preprrs
Nome do arquivo: tins_preprrs.html