IBM Support

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

Technote (troubleshooting)


Problem(Abstract)

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

Cause

Documentation

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.

In Maximo 7.1 and later, a new parameter can be passed to the JVM at start up to give a unique name to the JVM. In WebSphere, this parameter is passed in the JVM Process definition Generic JVM parameters field. In Oracle 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:

-Dmxe.name=<servername>

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

IBM recommends that, for clarity, this parameter match the application server name used in the console. For example, an Application server name or cluster member is named MAXIMOUI1. The parameter –Dmxe.name=MAXIMOUI1 should be added to the list of generic parameters. This will also 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 MAXIMOUI1, MAXIMOUI2, MAXIMOCRON, MAXIMOIF, and MAXIMOREPORT instead of MXServer, MXServerc1, Mxserverc2, MXServerc3, MXServerc4, MXServerc5.

Note: If this parameter is not used, each physical server will have its 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 RMI Registry (rmireg.war):

Deploying the RMI Registry (rmireg.war) in WebSphere 6.0 and 6.1
Deploying the RMI Registry (rmireg.war) in WebSphere 7.0, 8.0 and 8.5
Deploying the RMI Registry (rmireg.war) in WebLogic 8.1
Deploying the RMI Registry (rmireg.war) in WebLogic 9.2, 10, 11 and 12


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
Systems and Asset Management Control Desk
Systems and Asset Management Maximo Asset Management
Systems and Asset Management Maximo Asset Management Essentials

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, 7.6

Operating system(s): Platform Independent

Reference #: 1446387

Modified date: 2016-05-28