Network Deployment (Distributed operating systems), v8.0 > Reference > Jython script library


Server settings configuration scripts

The scripting library provides multiple script procedures to automate the application server configurations. Use the application server scripts to configure class loaders, Java Virtual Machine (JVM) settings, EJB containers, performance monitoring, dynamic cache, and so on. We can run each script individually, or combine procedures to create custom automation scripts for the environment.

All server management script procedures are located in the WAS_HOME/scriptLibraries/servers/V70 directory.

Use the following script procedures to administer the application server:

Use the following script procedures to configure your application server runtime environment:

Use the following script procedures to configure web containers for the application server:

Use the following script procedures to configure logs and monitor performance for the application server:



configureAdminService

Configure settings for the AdminService interface. The AdminService interface is the server-side interface to the application server administration functions.

configureAdminService argument descriptions. Run the script with the node name, server name, local connection protocol, and remote connection protocol.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
localAdminProtocol Type of connector to use to connect the AdminService interface to the application server for local connection.
remoteAdminProtocol Type of connector to use to connect the AdminService interface to the application server for remote connection.
otherAttributeList Optionally specifies additional attributes in the following format: [["enabled", "true"], ["pluginConfigService", "(cells/timmieNode02Cell/nodes/timmieNode01/servers/server1|server.xml#PluginConfigService_1183122130078)"]]

Syntax 

AdminServerManagement.configureAdminService(nodeName, serverName, localAdminProtocol, remoteAdminProtocol, otherAttributeList)

Example usage 

AdminServerManagement.configureAdminService("myNode", "myServer", "IPC", "SOAP",     [["enabled", "true"], ["pluginConfigService",
       "(cells/timmieNode02Cell/nodes/timmieNode01/servers/server1|server.xml#PluginConfigService_1183122130078)"]])


configureApplicationServerClassloader

Configure a class loader for the application server. Class loaders enable applications that are deployed on the application server to access repositories of available classes and resources.

configureApplicationServerClassloader argument descriptions. Run the script with the node name, server name, policy, mode, and library name arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
policy Application class loader policy as SINGLE or MULTIPLE. Specify the SINGLE value to prevent the isolation applications, and to configure the application server to use a single application class loader to load all of the EJB modules, shared libraries, and dependency JAR files in the system. Specify the MULTIPLE value to isolate applications and provide each application with its own class loader to load EJB modules, shared libraries, and dependency JAR files.
mode Class loader mode as PARENT_FIRST or APPLICATION_FIRST. The PARENT_FIRST option causes the class loader to delegate the loading of classes to its parent class loader before attempting to load the class from its local class path. The APPLICATION_FIRST option causes the class loader to attempt to load classes from its local class path before delegating the class loading to its parent. Using this policy, an application class loader can override and provide its own version of a class that exists in the parent class loader.
libraryName Name of the shared library of interest.

Syntax 

AdminServerManagement.configureApplicationServerClassloader(nodeName, serverName,  policy, mode, libraryName)

Example usage 

AdminServerManagement.configureApplicationServerClassloader("myNode", "MULTIPLE", "PARENT_FIRST",
"myLibraryReference")


configureDynamicCache

Configure the dynamic cache service in your server configuration. The dynamic cache service works within an application server JVM, intercepting calls to cacheable objects. For example, the dynamic cache service intercepts calls through a servlet service method or a command execute method, and either stores the output of the object to the cache or serves the content of the object from the dynamic cache.

configureDynamicCache argument descriptions. Run the script with the node name, server name, default priority, cache size, external cache group name, and external cache group type arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
defaultPriority Default priority for cache entries, determining how long an entry stays in a full cache. Specify an integer between 1 and 255.
cacheSize Positive integer as the value for the maximum number of entries that the cache holds. Enter a cache size value in this field that is between the range of 100 through 200000.
externalCacheGroupName The external cache group name needs to match the ExternalCache property as defined in the servlet or JSP file cachespec.xml file. When external caching is enabled, the cache matches pages with its Universal Resource Identifiers (URI) and pushes matching pages to the external cache. The entries can then be served from the external cache, instead of from the application server.
externalCacheGroupType External cache group type.
otherAttributeList Optionally specifies additional configuration options for the dynamic cache service in the following format: [["cacheProvider", "myProvider"], ["diskCacheCleanupFrequency", 2], ["flushToDiskOnStop", "true"]]

Syntax 

AdminServerManagement.configureDynamicCache(nodeName, serverName, defaultPriority,
    cacheSize, externalCacheGroupName, externalCacheGroupType,     otherAttributeList)

Example usage 

AdminServerManagement.configureDynamicCache("myNode", "myServer", 2, 5000, "EsiInvalidator",    "SHARED", [["cacheProvider", "myProvider"], ["diskCacheCleanupFrequency", 2], ["flushToDiskOnStop","true"]])


configureEJBContainer

Configure an EJB container in your server configuration. An EJB container provides a run-time environment for enterprise beans within the application server. The container handles all aspects of an enterprise bean's operation within the application server and acts as an intermediary between the user-written business logic within the bean and the rest of the application server environment.

configureEJBContainer argument descriptions. Run the script with the node name, server name, passivation directory, and default datasource JNDI name arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
passivationDirectory Directory into which the container saves the persistent state of passivated stateful session beans. This directory must already exist. It is not automatically created.
defaultDatasourceJNDIName JNDI name of a data source to use if no data source is specified during application deployment. This setting is not applicable for EJB 2.x-compliant container-managed persistence beans.

Syntax 

AdminServerManagement.configureEJBContainer(nodeName, serverName,
passivationDir, defaultDatasourceJNDIName)

Example usage

(Windows) 

AdminServerManagement.configureEJBContainer("myNode", "myServer", "C:\temp\myDir", "jndi1")
(AIX) (Solaris) 
AdminServerManagement.configureEJBContainer("myNode", "myServer", "/temp/myDir", "jndi1")


configureFileTransferService

Configure the file transfer service for the application server. The file transfer service transfers files from the dmgr to individual remote nodes.

configureFileTransferService argument descriptions. Run the script with the node name, server name, number of times to retry the file transfer, and the time to wait before retrying the file transfer.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
retriesCount Number of times you want the file transfer service to retry sending or receiving a file after a communication failure occurs. The default value is 3.
retryWaitTime Number of seconds that the file transfer service waits before it retries a failed file transfer. The default value is 10.
otherAttributeList Optionally specifies additional attributes in the following format: [["enable", "true"]]

Syntax 

AdminServerManagement.configureFileTransferService(nodeName, serverName, retriesCount, retryWaitTime, otherAttributeList)

Example usage 

AdminServerManagement.configureFileTransferService("myNode", "myServer", 5, 600, [["enable", "true"]])


configureListenerPortForMessageListenerService

Configure the listener port for the message listener service in your server configuration. The message listener service is an extension to the JMS functions of the JMS provider. It provides a listener manager that controls and monitors one or more JMS listeners, which each monitor a JMS destination on behalf of a deployed message-driven bean.

configureListenerPortForMessageListenerService argument descriptions. Run the script with the node name, server name, listener port name, connection factory JNDI name, destination JNDI name, maximum number of messages, maximum number of retries, and the maximum session arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
listenerPortName The name by which the listener port is known for administrative purposes.
connectionFactoryJNDIName The JNDI name for the JMS connection factory to be used by the listener port; for example, jms/connFactory1.
destinationJNDIName The JNDI name for the destination to be used by the listener port; for example, jms/destn1
maxMessages The maximum number of messages that the listener can process in one transaction. If the queue is empty, the listener processes each message when it arrives. Each message is processed within a separate transaction.
maxRetries The maximum number of times that the listener tries to deliver a message before the listener is stopped, in the range 0 through 2147483647. The maximum number of times that the listener tries to deliver a message to a message-driven bean instance before the listener is stopped.
maxSession Maximum number of concurrent sessions that a listener can have with the JMS server to process messages. Each session corresponds to a separate listener thread and therefore controls the number of concurrently processed messages. Adjust this parameter when the server does not fully use the available capacity of the machine and if you do not need to process messages in a specific message order.

Syntax 

AdminServerManagement.configureListenerPortForMessageListener(nodeName, serverName,  listenerPortName, connectionFactoryJNDIName,      destinationJNDIName, maxMessages, maxRetries, maxSession)

Example usage 

AdminServerManagement.configureListenerPortForMessageListener("myNode", "myServer", "myListenerPort",  "connJNDI", "destJNDI", 5, 2, 3)


configureMessageListenerService

Configure the message listener service in your server configuration. The message listener service is an extension to the Java Messaging Service (JMS) functions of the JMS provider. It provides a listener manager that controls and monitors one or more JMS listeners, which each monitor a JMS destination on behalf of a deployed message-driven bean.

configureMessageListenerService argument descriptions. Run the script with the node name, server name, maximum number of message listener retries, listener recovery interval, pooling threshold, and pooling timeout arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
maxListenerRetry Maximum number of times that a listener port managed by this service tries to recover from a failure before giving up and stopping. When stopped the associated listener port is changed to the stop state.
listenerRecoveryInterval Time in seconds between retry attempts by a listener port to recover from a failure.
poolingThreshold Maximum number of unused connections in the pool. The default value is 10.
poolingTimeout Number of milliseconds after which a connection in the pool is destroyed if it has not been used. An MQSimpleConnectionManager allocates connections on a most-recently-used basis, and destroys connections on a least-recently-used basis. By default, a connection is destroyed if it has not been used for five minutes.
otherAttributeList Optionally specifies additional message listener attributes in the following format: [["description", "test message listener"], ["isGrowable", "true"], ["maximumSize", 100], ["minimumSize", 5]]

Syntax 

AdminServerManagement.configureMessageListenerService(nodeName, serverName,  maxListenerRetry, listenerRecoveryInterval,      poolingThreshold, poolingTimeout, otherAttributeList)

Example usage 

AdminServerManagement.configureMessageListenerService("myNode", "myServer", 5, 120,  20, 600000, "myProp", "myValue",       [["description", "test message listener"], ["isGrowable", "true"], ["maximumSize", 100], ["minimumSize", 5]])


configureStateManageable

Configure the initial state of the application server. The initial state refers to the desired state of the component when the server process starts.

configureStateManageable argument descriptions. Run the script with the node name, server name, parent type, and initial state arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
parentType Type of component to modify.
initialState Desired state of the component when the server process starts. Valid values are START and STOP.

Syntax 

AdminServerManagement.configureStateManageable(nodeName, serverName,  parentType, initialState)

Example usage 

AdminServerManagement.configureStateManageable("myNode", "myServer", "Server", "START")


configureCustomProperty

Configure custom properties in the application server configuration. We can use custom properties for configuring internal system properties which some components use, for example, to pass information to a web container.

configureCustomProperty argument descriptions. Run the script with the node name, server name, parent type, property name, and property value arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
parentType Type of component to configure.
propertyName Custom property to configure.
propertyValue Value of the custom property to configure.
otherAttributeList Optionally specifies additional attributes in the following format: [["commTraceEnabled", "true"], ["enable", "true"]]

Syntax 

AdminServerManagement.configureCustomProperty(nodeName, serverName, parentType, propertyName, propertyValue, otherAttributeList)

Example usage 

AdminServerManagement.configureCustomProperty("myNode", "myServer", "ThreadPool", "myProp1", "myPropValue",     [["description", "my property test"], ["required", "false"]])


configureCustomService

Configure a custom service in the application server configuration. Each custom services defines a class that is loaded and initialized whenever the server starts and shuts down. Each of these classes must implement the com.ibm.websphere.runtime.CustomService interface. After you create a custom service, use the admin console to configure that custom service for the application servers.

Table 10. configureCustomService argument descriptions. Run the script with the node name, server name, and preferred connector type.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
classname Class name of the service implementation. This class must implement the Custom Service interface.
displayname Name of the service.
classpath Class path used to locate the classes and JAR files for this service.
otherAttributeList Optionally specifies additional attributes in the following format: [["description", "test custom service"], ["enable", "true"]]

Syntax 

AdminServerManagement.configureCustomService(nodeName, serverName, classname, displayname, classpath, otherAttributeList)

Example usage

(Windows) 

AdminServerManagement.configureCustomService("myNode", "myServer", "myClass", "myName", "C:\temp\boo.jar",      [["description", "test custom service"], ["enable", "true"]])
(AIX) (Solaris) 
AdminServerManagement.configureCustomService("myNode", "myServer", "myClass", "myName", "/temp/boo.jar",      [["description", "test custom service"], ["enable", "true"]])


configureEndPointsHost

Table 11. configureEndPointsHost argument descriptions. Run the script to configure the host name of the server endpoints. Specify the node name, server name, and host name arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
hostName Name of the host of interest.

Syntax 

AdminServerManagement.configureEndPointsHost(nodeName, serverName, hostName)

Example usage 

AdminServerManagement.configureEndPointsHost("myNode", "AppServer01", "myHostname")


configureJavaVirtualMachine

Configure a JVM. The application server, being a Java process, requires a JVM in order to run, and to support the Java applications running on it.

Table 12. configureJavaVirtualMachine argument descriptions. Run the script with the configuration ID of the JVM of interest, whether to enable debug mode, and additional debug arguments.

Argument Description
javaVirtualMachineConfigID Configuration ID of the JVM to make changes.
debugMode Whether to run the JVM in debug mode. The default is not to enable debug mode support. If you set the debugMode argument to true, then specify debug arguments.
debugArgs Specifies debug arguments to pass to the JVM code that starts the application server process. If you enable debugging on multiple application servers on the same node, make sure that the servers are using different address arguments, which define the port for debugging. For example, if you enable debugging on two servers and leave the default debug port for each server as address=7777, the servers could fail to start properly.
otherAttributeList Optionally specifies additional attributes using the following name and value pair format: [["internalClassAccessMode", "RESTRICT""], ["disableJIT", "false"], ["verboseModeJNI", "false"]]

Syntax 

AdminServerManagement.configureJavaVirtualMachine(javaVirtualMachineConfigID,  debugMode, debugArgs, otherAttributeList)

Example usage 

AdminServerManagement.configureJavaVirtualMachine
   ("(cells/WAS00Network/nodes/ndnode1/servers/server1|server.xml#JavaVirtualMachine_1208188803955)", "true",    "mydebug", [["internalClassAccessMode", "RESTRICT"], ["disableJIT", "false"], ["verboseModeJNI", "false"]])


configureORBService

Configure an ORB service in your server configuration. An ORB manages the interaction between clients and servers, using the Internet InterORB Protocol (IIOP). It enables clients to make requests and receive responses from servers in a network-distributed environment.

Table 13. configureORBService argument descriptions. Run the script with the node name, server name, request timeout, request retry count, request retry delay, maximum connection cache, minimum connection cache, and locate request timeout arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
requestTimeout Number of seconds to wait before timing out on a request message.
requestRetriesCount Number of times that the ORB attempts to send a request if a server fails. Retrying sometimes enables recovery from transient network failures. This field is ignored on the z/OS platform.
requestRetriesDelay Number of milliseconds between request retries. This field is ignored on the z/OS platform.
connectionCacheMax Maximum number of entries that can occupy the ORB connection cache before the ORB starts to remove inactive connections from the cache. This field is ignored on the z/OS platform. It is possible that the number of active connections in the cache will temporarily exceed this threshold value. If necessary, the ORB will continue to add connections as long as resources are available.
connectionCacheMin Minimum number of entries in the ORB connection cache. This field is ignored on the z/OS platform. The ORB will not remove inactive connections when the number of entries is below this value.
locateRequestTimeout Number of seconds to wait before timing out on a LocateRequest message. This field is ignored on the z/OS platform.
otherAttributeList Optionally specifies additional attributes in the following format: [["commTraceEnabled", "true"], ["enable", "true"]]

Syntax 

AdminServerManagement.configureORBService(nodeName, serverName, requestTimeout, requestRetriesCount, requestRetriesDelay,    connectionCacheMax, connectionCacheMin, locateRequestTimeout, otherAttributeList)

Example usage 

AdminServerManagement.configureMessageListenerService("myNode", "myServer", 5, 120, 20, 600000, 20, 300,
[["commTraceEnabled", "true"], ["enable", "true"]])


configureProcessDefinition

Configure the server process definition. Enhance the operation of an application server by defining command-line information for starting or initializing the application server process. Process definition settings define runtime properties such as the program to run, arguments to run the program, and the working directory.

To run the script, specify the node name and server name arguments, as defined in the following table:

Table 14. configureProcessDefinition argument descriptions. Run the script with the node name, server name and, as needed, additional parameters.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
otherParamList Specifies additional parameters for the process definition configuration in the following format: [["executableName", "value1"], ["executableArguments", "value2"], ["workingDirectory", "value3"]]

Syntax 

AdminServerManagement.configureProcessDefintion(nodeName, serverName, otherParamList)

Example usage 

AdminServerManagement.configureProcessDefinition("myNode", "myServer",    [["executableName", "value1"],["executableArguments"."value2"],["workingDirectory","value3"]])


configureRuntimeTransactionService

Configure the transaction service for your server configuration. The transaction service is a server runtime component that coordinates updates to multiple resource managers to ensure atomic updates of data. Transactions are started and ended by applications or the container in which the applications are deployed.

Table 15. configureRuntimeTransactionService argument descriptions. Run the script with the node name, server name, total transaction lifetime timeout, and client inactivity timeout arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
totalTranLifetimeTimeout Default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. Any transaction that does not begin completion processing before this timeout occurs is rolled back.
clientInactivityTimeout Maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server. If you set this value to 0, there is no timeout limit.

Syntax 

AdminServerManagement.configureRuntimeTransactionService(nodeName, serverName,  totalTranLifetimeTimeout, clientInactivityTimeout)

Example usage 

AdminServerManagement.configureRuntimeTransactionService("myNode", "myServer", 600, 600)


configureThreadPool

Configure thread pools in your server configuration. A thread pool enables components of the server to reuse threads, which eliminates the need to create new threads at run time. Creating new threads expends time and resources.

Table 16. configureThreadPool argument descriptions. Run the script with the node name, server name, parent type, thread pool name, maximum size, minimum size, and the amount of time before timeout occurs.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
parentType Type of component to configure.
threadPoolName Name of the thread pool of interest.
maximumSize Maximum number of threads to maintain in the default thread pool. If your Tivoli Performance Viewer shows the Percent Maxed metric to remain consistently in the double digits, consider increasing the Maximum size. The Percent Maxed metric indicates the amount of time that the configured threads are used.
minimumSize Minimum number of threads to allow in the pool. When an application server starts, no threads are initially assigned to the thread pool. Threads are added to the thread pool as the workload assigned to the application server requires them, until the number of threads in the pool equals the number specified in the Minimum size field. After this point in time, additional threads are added and removed as the workload changes. However the number of threads in the pool never decreases below the number specified in the Minimum size field, even if some of the threads are idle.
inactivityTimeout Number of milliseconds of inactivity that should elapse before a thread is reclaimed. A value of 0 indicates not to wait and a negative value (less than 0) means to wait forever.
otherAttributeList Specifies additional configuration attributes in the following format: [["description", "testing thread pool"], ["isGrowable", "true"], ["name", "myThreadPool"]]

Syntax 

AdminServerManagement.configureThreadPool(nodeName, serverName,  parentType, threadPoolName, maximumSize,  minimumSize, inactivityTimeout, otherAttributeList)

Example usage 

AdminServerManagement.configureThreadPool
   ("acmeNode2", "server1", "ThreadPoolManager", "WebContainer", 15, 25, 60)


configureTransactionService

Configure the transaction service for the application server. We can use transactions with the applications to coordinate multiple updates to resources as atomic units (as indivisible units of work) such that all or none of the updates are made permanent.

Table 17. configureTransactionService argument descriptions. Run the script with the node name, server name, total transaction lifetime timeout, client inactivity timeout, maximum transaction timeout, heuristic retry limit, heuristic retry wait, propogate or BMT transaction lifetime timeout, and asynchronous response timeout arguments.

Argument Description
nodeName Name of the node of interest.
serverName Server name of the of interest.
totalTranLifetimeTimeout Default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. Any transaction that does not begin completion processing before this timeout occurs is rolled back. This timeout is used only if the application component does not set its own transaction timeout.

Only the total transaction lifetime timeout and the maximum transaction timeout have grace periods. We can disable the grace periods using the DISABLE_TRANSACTION_TIMEOUT_GRACE_PERIOD custom property.

clientInactivityTimeout Maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server. If you set this value to 0, there is no timeout limit.
maximumTransactionTimeout Upper limit of the transaction timeout, in seconds, for transactions that run in this server. This value should be greater than or equal to the total transaction timeout. This timeout constrains the upper limit of all other transaction timeouts.
heuristicRetryLimit Number of times that the application server retries a completion signal, such as commit or rollback. Retries occur after a transient exception from a resource manager or remote partner, or if the configured asynchronous response timeout expires before all Web Services Atomic Transaction (WS-AT) partners have responded.
heuristicRetryWait Number of seconds that the application server waits before retrying a completion signal, such as commit or rollback, after a transient exception from a resource manager or remote partner.
propogateOrBMTTranLifetimeTimeout Number of seconds that a transaction remains inactive before it is rolled back.
asyncResponseTimeout Amount of time, in seconds, that the server waits for an inbound Web Services Atomic Transaction (WS-AT) protocol response before resending the previous WS-AT protocol message.
otherAttributeList Optionally specifies additional attributes in the following format: [["LPSHeuristicCompletion", "ROLLBACK"], ["WSTransactionSpecificationLevel", "WSTX_10"], ["enable", "true"]]

Syntax 

AdminServerManagement.configureTransactionService(nodeName, serverName,
totalTranLifetimeTimeout, clientInactivityTimeout,    maximumTransactionTimeout, heuristicRetryLimit, heuristicRetryWait,
   propogateOrBMTTranLifetimeTimeout, asyncResponseTimeout, otherAttributeList)

Example usage 

AdminServerManagement.configureTransactionService("myNode", "myServer",
    120, 60, 5, 2, 5, 300, 30,
    [["LPSHeuristicCompletion", "ROLLBACK"], ["WSTransactionSpecificationLevel", "WSTX_10"], ["enable", "true"]])


setJVMProperties

This script sets additional properties for your JVM configuration.

Table 18. setJVMProperties argument descriptions. Run the script with the node name, server name, classpath, boot class path, initial heap size, maximum heap size, whether to enable debug mode, and debug arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
classPath Optionally specifies the standard class path in which the JVM code looks for classes.
bootClasspath Optionally specifies bootstrap classes and resources for JVM code. This option is only available for JVM instructions that support bootstrap classes and resources.
initialHeapSize Optionally specifies the initial heap size available to the JVM code, in megabytes. Increasing the minimum heap size can improve startup. The number of garbage collection occurrences are reduced and a 10% gain in performance is realized. Increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory, in general. After the heap begins swapping to disk, Java performance suffers drastically.
maxHeapSize Optionally specifies the maximum heap size available to the JVM code, in megabytes. Increasing the heap size can improve startup. By increasing heap size, you can reduce the number of garbage collection occurrences with a 10% gain in performance.
debugMode Optionally specifies whether to run the JVM in debug mode. The default is not to enable debug mode support. If you set the debugMode argument to true, then you must specify debug arguments.
debugArgs Optionally specifies debug arguments to pass to the JVM code that starts the application server process. If you enable debugging on multiple application servers on the same node, make sure that the servers are using different address arguments, which define the port for debugging. For example, if you enable debugging on two servers and leave the default debug port for each server as address=7777, the servers could fail to start properly.

Syntax 

AdminServerManagement.setJVMProperties(nodeName, serverName,
classPath, bootClasspath, initialHeapSize,
maxHeapSize, debugMode, debugArgs)

Example usage

(Windows) 

AdminServerManagement.setJVMProperties("myNode", "myServer", "c:\a.jar", "", "”, "", "", "")
(AIX) (Solaris) 
AdminServerManagement.setJVMProperties("myNode", "myServer", "/a.jar", "", "”, "", "", "")


setTraceSpecification

This script sets the trace specification for the configuration.

Table 19. setTraceSpecification argument descriptions. Run the script with the node name, server name, and trace specification arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
traceSpecification Optionally specifies debug arguments to pass to the JVM code that starts the application server process. If you enable debugging on multiple application servers on the same node, make sure that the servers are using different address arguments, which define the port for debugging. For example, if you enable debugging on two servers and leave the default debug port for each server as address=7777, the servers could fail to start properly.

Syntax 

AdminServerManagement.setJVMProperties(nodeName, serverName, traceSpecification)

Example usage 

AdminServerManagement.setTraceSpecification("myNode", "myServer", "com.ibm.ws.management.*=all")


configureCookieForServer

Configure cookies in the application server configuration. Configure cookies to track sessions.

Table 20. configureCookieForServer argument descriptions. Run the script with the node name, server name, cookie name, domain, maximum cookie age, and whether to secure the cookie.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
cookieName Unique name for the session management cookie. The servlet specification requires the name JSESSIONID. However, for flexibility this value can be configured.
domain Domain field of a session tracking cookie. This value controls whether or not a browser sends a cookie to particular servers. For example, if you specify a particular domain, session cookies are sent to hosts in that domain. The default domain is the server.
maximumAge Amount of time that the cookie lives on the client browser. Specify that the cookie lives only as long as the current browser session, or to a maximum age. If you choose the maximum age option, specify the age in seconds. This value corresponds to the Time to Live (TTL) value described in the Cookie specification. Default is the current browser session which is equivalent to setting the value to -1.
secure Specifies that the session cookies include the secure field. Enabling the feature restricts the exchange of cookies to HTTPS sessions only.
otherAttributeList Optionally specifies additional attributes in the following format: [["path", "C:/temp/mycookie"]]

Syntax 

AdminServerManagement.configureCookieForServer(nodeName, serverName, cookieName, domain, maximumAge, secure, otherAttributeList)

Example usage 

AdminServerManagement.configureCookieForServer("myNode", "myServer", "myCookie", "uk.kingdom.com", -1, "true", [["path", "C:/temp/mycookie"]])


configureHTTPTransportForWebContainer

Configure HTTP transports for a web container. Transports provide request queues between application server plug-ins for Web servers and web containers in which the web modules of applications reside. When you request an application in a web browser, the request is passed to the web server, then along the transport to the web container.

Table 21. configureHTTPTransportForWebContainer argument descriptions. Run the script with the node name, server name, whether to adjust the port, whether external, the Secure Socket Layer (SSL) configuration to use, and whether to enable SSL.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
adjustPort Whether to automatically adjust the port for the web container of interest.
external Whether to set the HTTP Transport for the web container to external.
sslConfig Specifies the SSL settings type for connections between the WAS plug-in and application server. The options include one or more SSL settings defined in the Security Center; for example, DefaultSSLSettings, ORBSSLSettings, or LDAPSSLSettings.
sslEnabled Whether to protect connections between the WAS plug-in and application server with SSL. The default is not to use SSL.

Syntax 

AdminServerManagement.configureHTTPTransportForWebContainer(nodeName, serverName,  adjustPort, external, sslConfig, sslEnabled)

Example usage 

AdminServerManagement.configureHTTPTransportForWebContainer("myNode", "myServer", "true", "true", "mySSLConfig", "true")


configureSessionManagerForServer

Configure the session manager for the application server. Sessions allow applications running in a web container to keep track of individual users.

Table 22. configureSessionManagerForServer argument descriptions. Run the script with the node name, server name, and session persistence mode.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
sessionPersistenceMode Session persistence mode. Valid values include DATABASE, DATA_REPLICATION, and NONE.
otherAttributeList Optionally specifies additional attributes in the following format: [["accessSessionOnTimeout", "true"], ["enabled", "true"]]

Syntax 

AdminServerManagement.configureSessionManagerForServer(nodeName, serverName,
sessionPersistenceMode, otherAttributeList)

Example usage 

AdminServerManagement.configureSessionManagerForServer("myNode", "myServer", "DATABASE",
[["accessSessionOnTimeout", "true"], ["enabled", "true"]])


configureWebContainer

Configure web containers in the application server configuration. A web container handles requests for servlets, JSP files, and other types of files that include server-side code. The web container creates servlet instances, loads and unloads servlets, creates and manages request and response objects, and performs other servlet management tasks.

Table 23. configureWebContainer argument descriptions. Run the script with the node name, server name, default virtual host name, and whether to enable servlet cache.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
webContainerName Name of the web container of interest.
defaultVirtualHostName Specifies a virtual host that enables a single host machine to resemble multiple host machines. Resources associated with one virtual host cannot share data with resources associated with another virtual host, even if the virtual hosts share the same physical machine. Valid values include:

default_host

The product provides a default virtual host with some common aliases such as the machine IP address, short host name, and fully qualified host name. The alias comprises the first part of the path for accessing a resource such as a servlet. For example, it is localhost:9080 in the http://localhost:9080/myServlet.

admin_host

This is another name for the application server; also known as server1 in the base installation. This process supports the use of the admin console.

proxy_host

The virtual host called proxy_host, includes default port definitions, port 80 and 443, which are typically initialized as part of the proxy server initialization. Use this proxy host as appropriate with routing rules associated with the proxy server.
enableServletCaching Specifies that if a servlet is invoked once and it generates output to be cached, a cache entry is created containing not only the output, but also side effects of the invocation. These side effects can include calls to other servlets or JSP files, as well as metadata about the entry, including timeout and entry priority information.

Portlet fragment caching requires that servlet caching is enabled. Therefore, enabling portlet fragment caching automatically enables servlet caching. Disabling servlet caching automatically disables portlet fragment caching.

otherAttributeList Optionally specifies additional attributes in the following format: [["allowAsyncRequestDispatching", "true"], ["disablePooling", "true"], ["sessionAffinityTimeout", 20]]

Syntax 

AdminServerManagement.configureWebContainer(nodeName, serverName,
defaultVirtualHostName, enableServletCaching, otherAttributeList)

Example usage 

AdminServerManagement.configureWebContainer("myNode", "myServer", "myVH.uk.kingdom.com",  true,
   [["allowAsyncRequestDispatching", "true"], ["disablePooling", "true"], ["sessionAffinityTimeout", 20]])


configureJavaProcessLogs

Configure Java process logs for the application server. The system creates the JVM logs by redirecting the and System.err streams of the JVM to independent log files.

Table 24. configureJavaProcessLogs argument descriptions. Run the script with the Java process definition of interest and root directory for the process logs.

Argument Description
javaProcessDefConfigID Configuration ID of the Java Process Definition of interest.
processLogRoot Root directory for the process logs.
otherAttributeList Optionally specifies additional attributes using the following name and value pair format: [["stdinFilename", "/temp/mystdin.log"]]

Syntax 

AdminServerManagement.configureJavaProcessLogs(javaProcessDefConfigID, processLogRoot,  otherAttributeList)

Example usage

(Windows) 

AdminServerManagement.configureJavaProcessLogs
   ("(cells/WAS00Network/nodes/ndnode1/servers/server1|server.xml#JavaProcessDef_1184194176408)",    "C:\temp\myJavaLog", [["stdinFilename", "c:\temp\mystdin.log"]])
(AIX) (Solaris) 
AdminServerManagement.configureJavaProcessLogs
   ("(cells/WAS00Network/nodes/ndnode1/servers/server1|server.xml#JavaProcessDef_1184194176408)",
    "/temp/myJavaLog", [["stdinFilename", "/temp/mystdin.log"]])


configurePerformanceMonitoringService

Configure performance monitoring infrastructure (PMI) in your configuration. PMI enables the server to collect performance data from various product components. PMI provides information about average system resource usage statistics, with no correlation between the data across different components.

Table 25. configurePerformanceMonitoringService argument descriptions. Run the script with the node name, server name, whether to enable PMI, and the initial specification level arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
enable Whether the application server attempts to enable Performance Monitoring Infrastructure (PMI). If an application server is started when the PMI is disabled, we have to restart the server in order to enable it.
initialSpecLevel Pre-defined set of Performance Monitoring Infrastructure (PMI) statistics for all components in the server.

None

All statistics are disabled.

Basic

Provides basic monitoring for application server resources and applications. This includes Java EE (Java EE) components, HTTP session information, CPU usage information, and the top 38 statistics. This is the default setting.

Extended

Provides extended monitoring, including the basic level of monitoring plus workload monitor, performance advisor, and Tivoli resource models. Extended provides key statistics from frequently used WAS components.

All

Enables all statistics.

Custom

Provides fine-grained control with the ability to enable and disable individual statistics.
otherAttributeList Optionally specifies additional attributes using the following name and value pair format: [["statisticSet", "test statistic set"], ["synchronizedUpdate", "true"]]

Syntax 

AdminServerManagement.configurePerformanceMonitoringService(nodeName, serverName,
enable, initialSpecLevel, otherAttributeList)

Example usage 

AdminServerManagement.configurePerformanceMonitoringService("myNode", "myServer", "true", "Basic",
[["statisticSet", "test statistic set"], ["synchronizedUpdate", "true"]])


configurePMIRequestMetrics

Configure PMI request metrics in the configuration. Request metrics provide data about each transaction, correlating this information across the various product components to provide an end-to-end picture of the transaction.

Table 26. configurePMIRequestMetrics argument descriptions. Run the script and specify whether to enable request metrics and the trace level.

Argument Description
enable Whether to turn on the request metrics feature. When disabled, the request metrics function is disabled.
traceLevel Specifies how much trace data to accumulate for a given transaction. Note that trace level and components to be instrumented work together to control whether or not a request will be instrumented.

NONE

No instrumentation.

HOPS

Generates instrumentation information on process boundaries only (for example, a servlet request coming from a browser or a web server and a JDBC request going to a database).

PERFORMANCE_DEBUG

Generates the data at Hops level and the first level of the intra-process servlet and EJB call (for example, when an inbound servlet forwards to a servlet and an inbound EJB calls another EJB). Other intra-process calls like naming and service integration bus (SIB) are not enabled at this level.

DEBUG

Provides detailed instrumentation data, including response times for all intra-process calls. Requests to servlet filters will only be instrumented at this level.
otherAttributeList Optionally specifies additional attributes using the following name and value pair format: [["armType", "TIVOLI_ARM"], ["enableARM", "true"]]

Syntax 

AdminServerManagement.configurePMIRequestMetrics(enable, traceLevel, otherAttributeList)

Example usage 

AdminServerManagement.configurePMIRequestMetrics("true", "DEBUG",
   [["armType", "TIVOLI_ARM"], ["enableARM", "true"]])


configureServerLogs

Configure server logs for the application server of interest.

Table 27. configureServerLogs argument descriptions. Run the script with the node name, server name, and root directory for the server logs.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
serverLogRoot Root directory for the server logs.
otherAttributeList Optionally specifies additional attributes using the following name and value pair format: [["formatWrites", "true"], ["messageFormatKind", "BASIC"], ["rolloverType", "BOTH"]]

Syntax 

AdminServerManagement.configureServerLogs(nodeName, serverName,
serverLogRoot, otherAttributeList)

Example usage

(Windows) 

AdminServerManagement.configureServerLogs("myNode", "myServer", "C:\temp\mylog",
   [["formatWrites", "true"], ["messageFormatKind", "BASIC"], ["rolloverType", "BOTH"]])
(AIX) (Solaris) 
AdminServerManagement.configureServerLogs("myNode", "myServer", "/temp/mylog",
   [["formatWrites", "true"], ["messageFormatKind", "BASIC"], ["rolloverType", "BOTH"]])


configureTraceService

Configure trace settings for the application server. Configure trace to obtain detailed information about running the application server.

Table 28. configureTraceService argument descriptions. Run the script with the node name, server name, trace specification, and output type arguments.

Argument Description
nodeName Name of the node of interest.
serverName Name of the server of interest.
startupTraceSpecification Trace specification to enable for the component of interest. For example, the com.ibm.ws.webservices.trace.MessageTrace=all trace specification traces the contents of a SOAP message, including the binary attachment data.
traceOutputType Specifies where trace output should be written. The trace output can be written directly to an output file, or stored in memory.
otherAttributeList Optionally specifies additional attributes for the trace service using the following name and value pair format: [["enable", "true"], ["traceFormat", "LOG_ANALYZER"]]

Syntax 

AdminServerManagement.configureTraceService(nodeName, serverName,
traceString, outputType, otherAttributeList)

Example usage 

AdminServerManagement.configureTraceService("myNode", "myServer", "com.ibm.ws.management.*=all=enabled",
   "SPECIFIED_FILE", [["enable", "true"], ["traceFormat", "LOG_ANALYZER"]])

Use the script library to automate the application serving environment using wsadmin.sh
Automate application configuration


Related


Server query scripts
Server configuration scripts

+

Search Tips   |   Advanced Search