OA32873: DISTRIBUTED REQUEST CONNECTIVTY ISSUES WITH MIRROR

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Environment:
  
    This is a TEMS issue that can occur on all platforms when the
    FTO environment is used.  This issue has been around since at
    least ITM 6.1.
  
  Problem Description:
  
    In an FTO environment, distributed requests may not be
    successfully routed to an RTEMS when the RTEMS uses ephemeral
    addresses or when multiple NICs are used at the RTEMS.  Any
    other configuration where address translation is used may also
    have this problem.
  
    The problem occurs because KDC on the RTEMs will register to
    the first address in GLBSITE.TXT that it successfully connects
    to.  This may not be the acting HUB in an FTO environment, but
    instead may be the MIRROR TEMS.  Thus the necessary addressing
    information for the RTEMS may not exist in the GLB at the
    acting HUB.  This can prevent distributed requests from being
    routed to the RTEMS.
  
    FTO previously implemented code to in an attempt to ensure the
    a addressing information existed in the acting HUB's GLB.
    When FTO sees node status record for an RTEMS attached to the
    acting HUB, it will update the GLB registration based on the
    addressing information contained in the node status record.
    When address translation is being used in the network, the
    translated addresses do not appear in the node status record
    and are removed from the GLB. This causes the current problem
    preventing distributed requests from being routed to the
    RTEMS.
  
    The solution to this problem will most likely involve several
    components.  Some of these components are very delicate. Minor
    changes in these components can have large ramifications, so
    extreme care will be used to resolve this issue.  This
    solution is expected to be very large and require a large
    amount of time to complete.
  
  To identify this issue:
  
    - The trace on the acting HUB will show a trace message from
      kqmsnos processARMSNOS::processRecs indicating a node status
      record has been received from the RTEMS on the "local".
  
    ..?kqmsnos.cpp,331,"processARMSNOS::processRecs") Received
      <felder> <tvt6060> <<IP.PIPE>#192.168.1.1[1918]</IP.PIPE>>
      <> <Y> at <1090924151503001> locflag <> <1090924151803999>
      <00000000800000000000000000000000020000468f0> <local>
  
  - This will be followed by another trace message in kqmsnos
    processARMSNOS::processRecs stating that the node is being
    registered.  The message will contain the node name and
    address information that is going to be used in registration.
    It should be noted that the address infomation does not
    contain the address to contact the RTEMS.
  
    ..?kqmsnos.cpp,704,"processARMSNOS::processRecs")
      Registering <felder> <<IP.PIPE>#192.168.1.1[1918]</IP.PIPE>>
  
  - processARMSNOS::updateCMSRegistration in kqmsnos is then
    called.
  
    ..?kqmsnos.cpp,850,"processARMSNOS::updateCMSRegistration")
      Entry
  
  - SocketDef::cleanUpAndRegister in kqmdc is then called.
  
    ..?kqmdc.cpp,927,"SocketDef::cleanUpAndRegister") node
      <felder> type <Regular> entries <1>
  
  - You may then see various trace messages from kdc kqmdc.
  
  - These will be followed by a call to SocketDef::Unregister
    which will unregister the address used to send distributed
    requests to the RTEMS.
  
    ..?kqmdc.cpp,456,"SocketDef::Unregister") Unregistering loc
       <Both>
    ?..kqmdc.cpp,877,"SocketDef::printSelf") addr........<18C19B8>
    ...kqmdc.cpp,878,"SocketDef::printSelf") node........<felder>
    ..?kqmdc.cpp,879,"SocketDef::printSelf") type........<Regular>
    ..?kqmdc.cpp,883,"SocketDef::printSelf")
      socket.......<ip.pipe:#0.0.0.5[1918]>           <---------
    ..?kqmdc.cpp,889,"SocketDef::printSelf") lb
      obj.......<5e3d67a8d345.02.81.00.e7.48.00.00.00>
    ..?kqmdc.cpp,892,"SocketDef::printSelf") lb
      type......<000000000000.00.00.00.00.00.00.00.00>
    ..?kqmdc.cpp,895,"SocketDef::printSelf") lb
     intrfc....<684152a852f9.02.c6.d2.2d.fd.00.00.00>
    ..?kqmdc.cpp,897,"SocketDef::printSelf") lb annot.....<felder>
    ...kqmdc.cpp,898,"SocketDef::printSelf") lb flags.....<0>
  
  Detailed Recreation Procedure:
  
    To recreate:
  
  - Put the address for a primary and secondary HUB in the RTEMS
    GLBSITE.TXT file.  Order does not really matter.
  
  - Start the primary and secondary HUB's, Again, order does not
    really matter.
  
  - Ensure the RTEMS will use ephemeral addressing.
  
  - Start the RTEMS.
  
  - After things have settled, issue a distributed request to the
    RTEMS.  It will fail to make it to the RTEMS.
  
  Related Files and Output:
  
    Traces can be found on ECUREP.  Use the following traces:
  
    (UNIT:ko4ib ALL)(UNIT:ko4mh ALL)(UNIT:kqm ALL)
    (UNIT:kdshub1 ALL)(UNIT:kdsncsrv ALL)(UNIT:kdsnccom ALL)
    (UNIT:kdssqprs INP OUT)
  
    Also use KDC_DEBUG=Y
  
  Approver:        RB
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All TEMS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: UNABLE TO SEND DISTRIBUTED REQUESTS TO  *
  *                      REMOTES WHEN THE REMOTE IS USING        *
  *                      EPHEMERAL ADDRESSES IN AN FTO           *
  *                      ENVIRONMENT.                            *
  ****************************************************************
  * RECOMMENDATION: Apply the PTF.                               *
  ****************************************************************
  Primary Tivoli Enterprise Management Server is unable to
  send distributed requests to remote Tivoli Enterprise
  Management Server when the remote is using ephemeral
  addresses in an FTO environment. When this occurs, the
  remote Tivoli Enterprise Management Server and any agents
  attached to the remote will appear online and events will
  appear correctly. However, distributed requests for
  information from the remote or agents attached to it will
  fail to be sent from the Primary Tivoli Enterprise
  Management Server to the Remote Tivoli Enterprise Management
  Server.
  
  A review of the Global Lookup Broker at the Primary Tivoli
  Enterprise Management Server will show that the ephemeral
  address needed to contact the Remote Tivoli Enterprise
  Management Server is missing.
  

Problem conclusion

• Code in the Remote Tivoli Enterprise Management Server was
  updated to ensure it always registers to the Global Lookup
  Broker at the acting HUB. FTO code was updated to ensure it
  does not remove addresses from the Global Lookup Broker.
  This should ensure that the address needed to contact the
  remote is always available in the Global Lookup Broker.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  IZ62639

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• KDSMAIN
  

Fix information

• Fixed component name

  MGMT SERVER DS

• Fixed component ID

  5608A2800

Applicable component levels

• R622 PSY UA54006

     UP10/05/26 P F005

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.