IBM Tivoli Software IBM Tivoli Software

[ Bottom of Page | Previous Page | Next Page | Contents ]


For the runtime server

APAR IY46975
The values of the updateAgentEnabled parameter in the system.properties file are limited to "no" and "yes", but the documentation of those values in the Tivoli License Manager System Administration Guide reports them as "No" and "Yes". Supplying the incorrect values can mean that some product functions do not work correctly, as the parameter value is not recognized by the product. For example, a scheduled scan might not be performed on the agents belonging to that division. The following error messages are reported in the traceagt.log if you use "Yes" instead of "yes":
ERROR - Bad update enable string 'Yes'
ERROR - No parameters downloaded

After installing the fix the parameter values can be written in any of the following ways: "YES", "Yes", "yes", "NO", "No", "no".

APAR IY49281
If an agent has an operating system name longer than 40 characters, the agent plugin fails. The runtime server log file shows the following error:
errors.com.ibm.it.rome.slm.runtime.data.AgentHandler
ERROR  COM.ibm.db2.jdbc.DB2Exception: IBM CLI Driver DB2/6000 
SQL0433N  Value "Windows NT 5.0 - Service Pack 4, RC 4.66" is too long.
SQLSTATE=22001
This is because in the runtime server database, the AGENT table field for the operating system was too small.

After applying the fix the database table field (AGENT.OS_VERSION) is increased to 60 characters, and the problem does not occur.

Stopped runtime server or HTTP server
Every thread that runs in the runtime server locks the resource it is processing. If another request arrives, the server thread waits for the resource to become available. If many requests arrive in a short space of time, or if a thread needs to keep the resource locked for a long time, either the runtime server or the HTTP server, or both, may stop, or go into an endless loop.

After you have installed the fix, the runtime server will allow a thread to wait for a maximum of 60 seconds for a requested resource to be made available. If the request cannot be satisifed within this period, an event of type "internal error" is sent to the agent. The agent has processes for handling such an event, and the load on the runtime server and HTTP server is lightened.

Java(TM) exception handling
If an HTTP request arrives without a body, the Java exception is not correctly managed by the runtime server. This error is particularly evident when the server receives many requests from agents in a short space of time. In this case, the error log contains the following error:
10-03-10.55.29 {Communication#142} com.ibm.it.rome.slm.scp.ServiceHandler 
[ERROR] java.lang.NumberFormatException: null 
   at java.lang.Long.parseLong(Long.java(Compiled Code)) 
   at java.lang.Long.parseLong(Long.java(Compiled Code)

After installing the patch these Java exceptions are handled correctly.

Runtime service scheduling
It is not possible to customize a start time for certain services which the runtime server runs to perform some internal activities, and certain services which make requests to the administration server. By default, these services are started at midnight, GMT, regardless of the timezone of the runtime server. The affected services all have customizable frequencies, but without a customizable start time you cannot ensure that the running of these services avoids times of the day when the runtime server is busy communicating with its agents.

After installing this fix you will be able to choose the time of day when all these services start. The installation of the fix will add a new parameter: runtimeBaseTime to the system.properties file on the runtime server. The default value of this parameter is 23:00 (11 pm), according to the clock of the runtime server. After you have installed the fix, the service requests will be made according to this parameter, and each will be satisfied in turn. The existing individual frequency parameters will then determine when the service is next run. Thus, for example, if the frequency interval of a service is 1440 minutes (24 hours), and you leave the runtimeBaseTime at its default value, the service will start at 23:00 (11 pm) every day. The server uses the runtimeBaseTime parameter only immediately after it has started; from that point on it will determine the next service start by adding the appropriate frequency to the time of the previous service start.

Note:
There is no particular advantage in staggering the frequency interval of the services, as if they all have the same frequency they will be started in a pre-determined sequence, and each service request will be satisfied in turn. However, you should schedule them to take place at a time when the workload of the runtime server is low.

In conjunction with this, after installing the fix, the following parameters in the system.properties file on the runtime server have new default values, different from those documented in the IBM Tivoli License Manager: System Administrator's Guide:

# Time interval for internal inventory update (minutes)
inventoryUpdatePeriod=1440
# Time interval for internal cache update (minutes)
cacheUpdatePeriod=1440
# Time interval for data transfer (download) with admin server (minutes)
adminDownloadPeriod=1440
# Time interval for data transfer (upload) with admin server (minutes)
adminUploadPeriod=1440
# Time interval for license cleanup checking (minutes)
licenseCleanupPeriod=1440
# Time interval for usage data resynch with admin server (minutes)
usageSnapshotPeriod=1440
Note:
During the fix installation, if you have modified any of these values from the original defaults, the changed values will not be changed to the new ones.

[ Top of Page | Previous Page | Next Page | Contents ]