IZ36145: UA'S HANDLING OF THE //SETSOURCENAME=XXXX RECORD WHICH IS CAUSING THE INCORRECT SYSTEM NAME (MSN) TO BE REGISTERED

APAR status

• Closed as program error.

Error description

• Daniel Biskar (from Universal Agent Development) has analyzed
  the logs received from customer including the tracesrequested
  in the previous update..
  From the analysis is highlighted a defect in UA's handling of
  the //SETSOURCENAME=xxxx record which is causingthe incorrect
  managed system name (MSN) to be registered.
  An APAR will be needed. Please, send this pmr to the right queue
  for opening it.
  
  FOR L3 UA engineers:
  To have more details I paste the Daniel's analysis received via
  e-mail:
  .
  What's happening is that the second "//SETSOURCENAME=TWSCﾇrﾇn"
  record isbeing received by UA along with hundreds of bytes of
  input data.
  Some of the data contains non-ASCII NLS characters.
  There is a check done in UA's SETSOURCENAME logic to prevent
  non-ASCIIcharacters from being registered in a MSN because the
  TEMS doesnotsupport non-English names in its node tables.
  When UA scans the received buffer, beginning with
  "//SETSOURCENAME=TWSCﾇrﾇn", and finds non-ASCII
  characters later in the buffer, UA rejects the
  SETSOURCENAME=TWSC record as invalid and reverts back to default
  behavior, which is to use the connecting system's hostname,
  twsplx00, in the first part of the registered MSN.
  
  The first "//SETSOURCENAME=TWSCﾇrﾇn" record is read by itself in
  a small buffer without any subsequent input data, and because
  there are no non-ASCII characters in that small buffer, the
  //SETSOURCENAME=TWSCﾇrﾇn record is processed correctly and the
  right MSN is registered.
  The UA APAR fix will need to stop its scan for non-ASCII
  characters past the ﾇrﾇn characters in the
  "//SETSOURCENAME=TWSCﾇrﾇn" record..
  Anyway, in the meanwhile that the fix on UA side is ready for
  our customer, we could be able to provide a circumvention
  for this problem.
  As Daniel's suggestion we could build (just for this issue) an
  USERMOD adding 2-3 second sleep between those two socket sends,
  that should force TCP to separate the two sets of data into two
  separate buffers, and then the non-ASCII checking logic can be
  avoided.
  

Local fix

Problem summary

• When using Socket data provider with //SETSOURCENAME option and
  record receieved contains
  '//SETSOURCENAME=myFavoriteNameCRLFmore data that is non-ASCII
  NLS characters'
  UA's SETSOURCENAME logic prevent non-ASCIIcharacters from being
  registered as a MSN because TEMS does not support non-English
  names in its node tables.
  
  UA scans the received buffer, beginning with
  '//SETSOURCENAME=myFavoriteNameCRLFmore data..." and finds
  non-ASCII data in the buffer UA rejects the
  //SETSOURCENAME record as invalid and reverts back to default
  behavior, which is to use the connecting system's hostname, in
  the first part of the registered MSN.
  

Problem conclusion

• Logic was added to scan data received from socket client for
  embedded CRLF following '/SETSOURCENAME=yourFavoriteNameCRLFmore
  data appears in data buffer ...'
  and note that CRLF as end of value for //SETSOURCENAME.
  
  The fix for this APAR will be included in the following
  maintenance vehicle:
      | interim fix | 6.1.0.7-TIV-ITM-IF0004
  
  Note: Search the IBM Technical support web site for maintenance
  package availability
  

Temporary fix

Comments

APAR Information

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

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

Fix information

• Fixed component name

  UNIVERSAL AGENT

• Fixed component ID

  5724K1000

Applicable component levels

• R610 PSY

     UP