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 number
IZ36145
Reported component name
UNIVERSAL AGENT
Reported component ID
5724K1000
Reported release
610
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-10-30
Closed date
2009-03-04
Last modified date
2009-03-04
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
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSSHL9","label":"Tivoli Universal Agent"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"610","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
04 March 2009