Take Control of JVM Names for Instance, Cron and Log Names Using -Dmxe.name

Technote (troubleshooting)


Using the JVM parameter –Dmxe.name, application administrators can have more control over how JVM’s are named.



Resolving the problem

By default, the system properties mxe.name parameter is set to ‘MXServer’. When a JVM starts, this parameter is read from the database and JVM is registered in the RMI registry. Once registered, the registry returns the name registered and this becomes the server name.

In clustered environments, the first JVM to start on any given physical server will be MXServer and the second JVM to start will be named MXServerC1, then MXServerC2, etc. The process of dynamically naming JVM means:

The order that JVM’s start determines the name
Assigning cron tasks to specific JVMs can fail
Tying logs to JVMs to determine where something occurred can be difficult
Instance management is more challenging.

With the release of version 7, there is a new parameter that can be passed to the JVM at start up to name the JVM. In WebSphere, this parameter is passed in the process definition generic JVM parameters field. In WebLogic, this parameter is passed as part of the command line that starts the JVM (either in the cmd file or the cmdLine parameter of the registry entry). The parameter is:


This parameter supersedes the database property mxe.name and/or the maximo.properties file.

It is recommended that this parameter match the application server name used in the console for clarity. If the application server name or cluster member is named MAXIMOUI1 then the parameter –Dmxe.name=MAXIMOUI1 should be passed as the generic parameter. This will cause the default naming for Maximo appender logs to be named including this name. It will also be clear which JVM instance is being edited when managing instance properties.

In this way, the resulting JVM names will be:


Instead of MXServer, MXServerc1, Mxserverc2, MXServerc3, MXServerc4, MXServerc5
NOTE: If this parameter is not used, each physical server will have it’s own unique names so the result can be multiple servers named MXServer and MXServerc1 etc. This method should be used in conjunction with the deployment of the RMIREG.WAR file according to following documents if external tools like MS Project or Primavera are used to access the Maximo objects:



Cross reference information
Segment Product Component Platform Version Edition
Systems and Asset Management Tivoli Asset Management for IT
Systems and Asset Management Tivoli Change and Configuration Management Database
Systems and Asset Management Tivoli Service Request Manager

Document information

More support for:

Maximo Asset Management
System Related

Software version:

7.1, 7.1.1, 7.1.2, 7.2, 7.2.1, 7.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:


Modified date:


Translate my page

Content navigation