WebSphere variables
Because applications cannot directly access WebSphere variables, if you define a WebSphere variable inside of an application, an error message, such as "Unknown variable," is returned. To reference a WebSphere variable from within an application, include the following method in the application to expand the string that uses the WebSphere variable. Note that expanding WebSphere variables requires you to have administrative privileges.
private String expandVariable(String s) throws javax.management.JMException { com.ibm.websphere.management.AdminService as = com.ibm.websphere.management.AdminServiceFactory.getAdminService(); String server = as.getProcessName(); java.util.Set result = as.queryNames(new javax.management.ObjectName("*:*,type=AdminOperations,process=" + server), null); return (String)as.invoke((javax.management.ObjectName) result.iterator().next(),"expandVariable",new Object[] {"${"+s+"}"}, new String[] {"java.lang.String"});Similarly, we can include the following lines of code in a script file to use a script command to expand WebSphere variables.
- Jacl:
set mbean [$AdminControl completeObjectName WebSphere:*,type=AdminOperations] $AdminControl invoke $mbean expandVariable {{"${APP_INSTALL_ROOT}"}}
- Jython:
AdminOperations = AdminControl.completeObjectName('WebSphere:*,type=AdminOperations') print AdminControl.invoke(AdminOperations, 'expandVariable', '${APP_INSTALL_ROOT}')
WebSphere variables are usually used to specify file paths. The "Variable settings" topic supplies further details about specifying variables and highlights further details about product components that use them.
WebSphere variables are also used to configure:
- Product path names, such as JAVA_HOME, and APP_INSTALL_ROOT.
- Configure certain cell-wide or cluster-wide customization values.
- (zos) The location service.
- (zos) Environment variables.
The variable scoping mechanism for WebSphere variables enables you to define a variable at the node, cluster, or cell level, as well as at the server level. This mechanism enables you to specify a setting for all of the servers in a node, cluster, or cell, instead of individually specifying the setting for each server.
To define a new variable, change the value of an existing variable, or delete an existing variable complete the following steps, as appropriate.
- Click Environment > WebSphere variables in the console
- Select the scope of the variable from the list of available scopes.
If we create a new variable, it will be created at the selected scope. If we define the same variable at multiple levels, the more granular definition overrides the higher level setting. For example, if specified the same variable on a cell level and at a node level, the node level setting overrides the cell level setting.
Scoping variables is particularly important if you are testing data source objects. Variable scoping can cause a data source to fail the test connection, but to succeed at run time, or to pass the test connection, but fail at run time.
- Create a new variable.
- Click New.
- Specify a name, a value, and, optionally, a description for the variable.
(zos) The application server uses WebSphere Application Server internal variables for its own purposes. The prefixes that indicate that a variable is internal are WAS_DAEMON_<server custom property>, WAS_DAEMON_ONLY_<server custom property>, and WAS_SERVER_ONLY_<server custom property>. Any variables with these tags are not intended for the use. They are reserved exclusively for use by the server run time. Modifying these variables can cause unexpected errors.
(zos) We can use WebSphere variables to modify the daemon configuration. By appending a server custom property onto a daemon tag, we can designate that variable specifically for that daemon. Enter DAEMON_<server custom property> in the Name field. For example, if you enter DAEMON_ras_trace_outputlocation in the Name field and SYSOUT in the Value field, we can direct that particular daemon's trace output to SYSPRINT.
We can create WebSphere variables that support substitution. For example, if you enter ${<variable name>} in the Name field, the value of <variable name> becomes the name of the new WebSphere variable. For example if you enter ${JAVA_HOME} as the name of the variable, the name of the WebSphere variable created is the Java home directory.
- Click OK.
- Click Environment > WebSphere variables in the console navigation, and verify that the variable is displayed in the list of variables for the selected scope.
The console does not pick up typing errors. The variable is ignored if it is referred to incorrectly.
- Modify the setting for an existing variable.
- Click on the name of the variable to change.
- Modify the content of the Values field.
The Values field for some of the variables that are already defined when you install the product are read-only because changing the values specified for those variables might cause product processing errors.
- Click OK.
- Delete an existing variable.
- Select the variable to delete.
- Click Delete.
- Click OK.
- Verify that this variable was removed from the list of variables for the selected scope.
- Save the configuration.
- Stop the affected servers and start those servers again to put the variable configuration change into effect.
If the change you made affects a node, stop and restart all of the servers on that node. Similarly if the change you made affects a cell, stop and restart all of the servers in that cell.
Subtopics
- WebSphere variables collection
Use this page to view and change the defined product variables with their values. We can also use this page to create a new variable, or delete an existing variable. These variables are name and value pairs used to provide the settings for the string data type configuration attributes contained in one of the XML formatted configuration files that reside in the product repository.
- Introduction: Variables
Variables come in many varieties. They are used to control settings and properties relating to the server environment. The three main types of variables that you should understand are environment variables, WebSphere variables, and custom properties.
- WebSphere variables
WebSphere variables are name and value pairs used to provide settings for any of the string data type attributes used to configure the product. After a variable is defined, the symbolic name specified for that variable can be specified in the Value field of any other configuration field for the product that accepts a string value.
- Configure the IBM Toolbox for Java
The IBM Toolbox for Java is a library of Java classes that are optimized for accessing IBM i data and resources. We can use the IBM Toolbox for Java JDBC driver to access local or remote DB2 UDB for IBM i databases from server-side and client Java applications that run on any platform that supports Java.
- (zos)(dist) Repository service custom properties
Use this page to add custom properties for the repository service.
- (zos) Application server custom properties for z/OS
Some of the application server custom properties provided with the product can only be used with z/OS . This topic describes how to use these properties.
Related concepts
Test connection service
Related tasks
(zos) Change the values of variables referenced in BBOM0001I messages
Configure transport chains
WebSphere variables settings Session management custom properties