Appendix A: Command-Line Utilities


Overview

WebSphere offers a number of command-line utilities for use with the standalone server, and with a networked deployment manager for managing the WebSphere runtime.

Application Server Commands

The application server command-line utilities are located in the \bin directory of the installation root for the WebSphere Application Server and include the following commands:

  • addNode

  • removeNode

  • startNode

  • stopNode

  • syncNode

  • startServer

  • stopServer

  • serverStatus

  • backupConfig

  • restoreConfig

  • versionInfo

addNode

The addNode command is used to register the current node into a federated cell. The addNode command has the following syntax:

addNode <cell_host> [<cell_port>] [-conntype <type>] [-includeapps]                     [-startingport <portnumber>] [-noagent] [-quiet] [-nowait]                      [-logfile <filename>] [-replacelog] [-trace] [-newtracefile]                     [-timeout <seconds>] [-username <uid>] [-password <pwd>]                      [-help]

The cell_host is the IP address or host name of the computer hosting the deployment manager representing the cell. You will only have to specify the cell_port if you have changed the default port value of the targeted deployment manager. If global security has been enabled at the deployment manager, you will have to specify a valid user ID and password for an administrator with authority to change the configuration of the system in the username and password parameters.

You can use the startingport as a hint to what port values you want the addNode command to use in creating port values for the endpoints in the node agent. Port values will be generated starting at the startingport value.

removeNode

The removeNode command is used to de-register the node from the cell. The removeNode has the following syntax:

removeNode [-force] [-quiet] [-nowait] [-logfile <filename>]            [-replacelog] [-trace] [-timeout <seconds>]             [-statusport <portnumber>] [-conntype <type>]            [-username <uid>] [-password <pwd>] [-help]

The node agent knows the cell that it is currently part of so that does not have to specified as a parameter. As with the addNode, if security is enabled at the deployment manager you have to specify the username and password parameters for a legitimate administrator with authority to make configuration changes.

The force parameter forces the node configuration to be cleaned up locally, even if the deployment manager can't be contacted.

startNode

The startNode command is used to start the node agent. You will only have to do this if you have federated the node into a cell, and the node agent is not automatically started as a service. It is generally better to register the node agent as a service of the operating system. In that way, the operating system will ensure the node agent is always running – re-starting it automatically in the event that it is inadvertently stopped. The syntax for startNode is:

startNode [-nowait] [-quiet] [-logfile <filename>] [-replacelog]            [-trace] [-script [<script filename>]] [-timeout <seconds>]            [-statusport <portnumber> ] [-username <name>] [-password <password>]           [-J-<javaoption>] [-help]

If you specify the script parameter, the startNode command will generate a script file representing the startNode command. This is a convenient way of capturing the command and its arguments for later batch processing.

stopNode

The stopNode operation stops the node agent on the local host. The syntax for the stopNode command is:

stopNode [-nowait] [-quiet] [-logfile <filename>] [-replacelog]          [-trace] [-timeout <seconds>] [-statusport <portnumber>]          [-conntype <connector type>] [-port <portnumber>]          [-username <name>] [-password <password>] [-help]

The nowait switch can be specified to instruct the stopNode command to return immediately – leaving the stop operation to execute and complete in the background.

The port parameter can be used to specify the port number of the node agent if you know it. This saves the stopNode command from having to look the port number up in the configuration documents, thus making the command operate more efficiently.

syncNode

The syncNode command can be used to force the node agent to synchronize the node repository with the cell repository. You should use this command if you suspect the repositories have become out of sync. The syncNode command has the following syntax:

syncNode <cell_host> [<cell_port>] [-conntype <type>] [-stopservers]                      [-restart] [-quiet] [-nowait] [-logfile <filename>]                       [-replacelog] [-trace] [-timeout <seconds>]                       [-statusport <portnumber>][-username <uid>] [-password <pwd>]                       [-help]

The stopservers switch instructs the syncNode command to stop all of the application servers on this node before synchronizing. The servers will then be automatically restarted if the restart switch is specified.

startServer

The startServer command will start an individual application server on the node. The syntax of the command is:

startServer <server> [-nowait] [-quiet] [-logfile <filename>] [-replacelog]                      [-trace]  [-timeout <seconds>]                      [-statusport <portnumber>] [-J-<javaoption>]                      [-username <name>] [-password <password>] [-help]

The server parameter is the name of the server you want to start as specified in the configuration for that server.

stopServer

The stopServer command can be used to stop a given server on the node. The syntax of the stopServer command is:

stopServer <server> [-nowait] [-quiet] [-logfile <filename>] [-replacelog]                     [-trace] [-timeout <seconds>] [-statusport <portnumber>]                      [-conntype <type>] [-port <portnumber>]                      [-username <name>] [-password <password>] [-help]

The logfile parameter can be used to specify where you want information about the stop server command written. If you specify the replacelog switch, the log file will be overwritten. Otherwise, the log information is appended to the end of the file.

serverStatus

The serverStatus command is used to get information about the status of the servers on this node. The syntax of the command is:

serverStatus {<server_name> | -all} [-logfile <filename>] [-replacelog]                                     [quiet] [-trace] [-username <uid>]                                      [-password <pwd>] [-help]

You can either request the status of a given server, specified by server_name, or get the status of all of the servers on the node, using the all switch.

backupConfig

The backupConfig command is used to back up the node configuration repository and saves it to a zip file. The syntax of the backupConfig command is:

backupConfig [<backup_file>] [-nostop] [-quiet]              [-logfile <filename>] [-replacelog] [-trace]               [-username <uid>] [-password <pwd>] [-help]

You can specify the name of the zip file you want the backup written to in the backup_file parameter. Otherwise, the backupConfig command will generate a backup file name for you – usually something that involves a constant and the current date plus an additional suffix to help differentiate it from other backups that may have occurred on this date.

If you invoke this command from the bin directory of your application server install root, unless the –nostop switch is specified, any running servers on the node will be stopped by this command prior to saving the configuration. This ensures that the configuration documents are not locked by the application server(s), and will not attempt to change the configuration while it is being backed-up. You will have to restart the servers after the backup is complete. If you specify –nostop, the servers will not be stopped beforehand.

If you have network deployment installed, and if you invoke this command from the bin directory of the network deployment installation root, then only the deployment manager will be stopped during the backup – the application servers will continue to operate with their local configuration repository.

The backupConfig command does not capture anything outside the repository. It does not, for example, capture your application binaries if they are stored outside the repository. Nor does it capture application data stored elsewhere. As such, the backupConfig command is not a substitute for a comprehensive system backup facility.

restoreConfig

The restoreConfig will restore the configuration captured in a previous backupConfig command. The syntax of the command is:

restoreConfig <backup_file> [-nostop] [-quiet]                             [-logfile <filename>] [-replacelog] [-trace]                              [-username <uid>] [-password <pwd>] [-help]

You must specify a backup zip file that was created from a prior backupConfig command in the backup_file parameter. If the restoreConfig command is invoked from the base application server installation root it will stop all running application servers before restoring the configuration repository. This ensures there are no sharing or read conflicts between the application servers and the restore processing. If the command is invoked from the deployment manager installation root, it will only stop the deployment manager – leaving the application servers to operate from their local configuration repositories.

versionInfo

The versionInfo command is used to get information about the current version of WebSphere installed on the local computer. The syntax of the command is:

versionInfo [-format {text | html}] [-file <output file>] [-long]              [-efixes] [-efixDetail] [-ptf] [-ptfDetail] [-components]              [-componentDetail][-help]

You will get basic information about the version of the application server installation from this command. By default, this information will be presented in text format. If you want the information formatted as an HTML document you can use the format html parameter. If you want the output placed in a file, you can use the file parameter and specify the file that you want used. If you want verbose information you can use the long switch. If you want details about the individual components of WebSphere, specify the components switch. Using the componentDetail switch will give you detailed information about the components. Using the efixes or ptf switches will get you information about any eFixes or PTFs that have been installed, respectively. Likewise, the efixDetail and ptfDetail switches will get you detailed information about and eFixes or PTFs that have been installed, respectively.

Deployment Manager Commands

The deployment manager commands are located in the \bin directory of the Network Deployment installation root. The deployment manager commands include:

  • startManager

  • stopManager

  • cleanupNode

In addition to the server-level commands that are applicable to the deployment manager: backupConfig, restoreConfig, serverStatus, startServer, stopServer, and versionInfo.

startManager

The startManager starts the deployment manager. The syntax of this command is:

startManager [-nowait] [-quiet] [-logfile <filename>] [-replacelog]              [-trace] [-script [<script filename>]] [-timeout <seconds>]              [-statusport <portnumber>] [-J-<javaoption>]              [-username <name>] [-password <password>] [-help]

If you want to specify any other JVM options you can do so with the J parameter.

stopManager

The stopManager stops the deployment manager. The syntax of the stopManager command is:

stopManager [-nowait] [-quiet] [-logfile <filename>] [-replacelog]             [-trace] [-timeout <seconds>] [-statusport <portnumber>]             [-conntype <type>] [-port <portnumber>]             [-username <name>] [-password <password>] [-help]

The quiet switch can be used to suppress normal messages from being presented on the console.

cleanupNode

The cleanupNode command can be used to clear out any information about a node for the configuration repository. The syntax is:

cleanupNode <node_name> [cell_host] [cell_port] [-quiet] [-nowait]                         [-logfile <filename>] [-replacelog] [-trace]                          [-username <uid>] [-password <pwd>] [-help]

The cleanupNode can be useful if you've simply removed a computer from you network. It can also be used if you use the force switch with the removeNode command to force a node to be de-registered when communication could not be achieved between the node agent and the deployment manager.

Other Commands

Beyond that, there are a sundry other command line commands available to both the base app server and the deployment manager that are worth noting. These include:

  • assembly

  • collector

  • dumpNameSpace

  • EARexpander

  • ejbdeploy

  • genPluginCfg

  • ikeyman

  • JspBatchCompiler

  • showlog

  • waslogbr

assembly

The assembly command starts the application assembly tool. The assembly command takes no arguments.

collector

The collector command starts the collector tool. The collector tool will collect a variety of information about your configuration and execution environment that can be used to help diagnose a problem you might have with your system. You should run this tool and provide the resulting JAR file to IBM when opening a service request.

The collector command takes no arguments:

collector [-help]

This command cannot be invoked from any directory under the installation root for WebSphere. You should create a new temporary directory in your file system and run this command from there:

C:\>mkdir temp C:\>cd temp C:\temp>"c:\Program Files\WebSphere\AppServer\bin\collector"

This will create a collection JAR called something like rhighlt1-BASE-WASenv.jar.

dumpNameSpace

The dumpNameSpace command can be used to dump out the JNDI name space – listing the names and their bindings, recursively for each sub-context of the root. The syntax of this command is:

dumpNameSpace [-host <bootstrapHost>] [-port <bootstrapPort>]               [factory <factoryClass>] [-root <rootLocation>]                [-url <resourceLocation>] [startAt <startingContext>]                [-format <formatStyle>] [-report <reportLength>]                [-traceString <traceFilterString>]

Where:

  • bootstrapHost is the host that you want to bootstrap from. Every WebSphere server – including application servers, node agents, and deployment managers host a bootstrap service. You can point this command utility to any host containing a valid WebSphere process – or any other (non-WebSphere) server containing a valid CORBA bootstrap service. Of course, the bootstrap service must be started before issuing this command. This will default to the localhost.

  • portNumber is the port number of your bootstrap service. By default this is 9810 for application servers, 9809 for the deployment manager, or 2809for the node agent, however; you can set this to whatever port number has been configured for your bootstrap service. You can find bootstrap port values under the BOOTSTRAP_ADDRESS of the endpoints page of whichever server you want to target – using the admin UI, for example.

  • factoryClass is the Java class name of the JNDI InitialContext factory. By default this is com.ibm.websphere.naming.WsnInitialContextFactory. You should not have to change this – if you do, be sure that the context factory is compatible with the name space that you want to view.

  • rootLocation is the root of the name space that you want to view. This can be one of "cell", "server", "node", "host", "legacy", "tree", or "default". These keys have slightly different uses for different versions of WebSphere, and only "default" is applicable to non-WebSphere namespaces.

  • startingContext is the starting sub-context (from the rootLocation) that you want to start. Do not specify this as an absolute context – in other words, there should not be a leading slash (/) in the starting context name. For example: -startContext servers/nodeagent is valid, but –startContext /servers/nodeagent will cause a problem.

  • resourceLocation is a URL for the name service. This should take on the URL form defined by the CORBA bootstrapping service – for example:

    corbaloc::rhighlt1:9810/NameServiceServerRoot

    If you use the –url parameter, you would not specify the –host or –port parameters as these are inferred by the URL. The port you use here will depend on the bootstrap port configured for the source of your bootstrapping service.

  • formatStyle indicates how you want names formed in the report. This can be either "jndi" or "ins". If you select a form style of JNDI (the default), compound names (those containing an ID and type field) are composed as a single string. If you select an INS, the compound name will be concatenated with an intervening period (.) – per the CORBA Interoperable Naming Service (INS) rules.

  • reportLength indicates whether you want summary or detailed information for each binding. This can be "short" (summary information; the default), or "long" (detailed information).

  • traceFilterString is a trace filter string that will affect what gets traced during the execution of this command.

EARExpander

The EARExpander utility can be used to expand an EAR file – un-zipping its contents in a directory structure in the file system. The syntax of this command is:

EARExpander –ear <earFile> -operationDir <targetDirectory>              -operation {expand | collapse} [-expansionFlags {all | war}]

Specify the EAR file that you want to work with in the earFile parameter. This should be path-qualified to refer to the absolute or relative location of the EAR file. The targetDirectory should specify the target directory for your expanded EAR. The operation parameter tells the utility to either expand the EAR file to the target directory, or collapse the target directory to the specified EAR.

ejbdeploy

The ejbdeploy utility will generate the schema mappings and bindings for your enterprise application. This is a necessary step before you can use your application in the application server. There are a variety of ways in which you can initiate the deployment of your application – including in the WebSphere Studio Application Developer tool, as an Ant task, and during application installation. This command-line utility enables you to do deployment as a manual activity from the commandline.

The syntax of this command is:

ejbdeploy <inputJar> <workingDirectory> <outputJar>            [-keep] [-cp <classpath>] [-codegen] [-dbname <database>]            [-dbschema <databaseSchema>] [-dbvendor <databaseVendor>] [-35] [-sqlj]           [-debug] [-rmic <rmicOptions>] [-ignoreErrors] [-quiet] [-nowarn]            [-noinform] [-trace]

The inputJar is the JAR or EAR file (including qualified path name) that you want to deploy. The workingDirectory is a temporary directory that the ejbdeploy utility can use to hold temporary and intermediate files that it generates. If the keep switch is specified, then this directory will be kept after the utility is done – otherwise, it may remove the files that it generates in this directory. The outputJar is the name of the JAR or EAR file that you want produced from this deployment process. If you specify a JAR in the inputJar parameter, then you must specify a JAR in the outputJar parameter. Likewise, if you specify an EAR in the inputJar, then you must specify an EAR in the outputJar.

You can specify any additional classpath that you need during deployment in the cp parameter. If you specify the codegen switch, the ejbdeploy utility will only generate code during this process – it will not compile that code or run the RMIC compiler to produce the stubs and ties for the EJBs in your application.

If you will be following a top-down pattern, you should specify the database parameter for the database you want created, the databaseSchema for the schema you want created, and the databaseVendor to specify the type and version of relational database product that you want to target in your application. Valid databaseVendor values include: SQL92, SQL99, DB2UDBWIN_V71, DB2UDBWIN_V72, DB2UDBOS390_V6, DB2UDBOS390_V7, DB2UDBISERIES, ORACLE_V8, ORACLE_V9I, INFORMIX_V73, INFORMIX_V92, INFORMIX_V93, SYBASE_V1192, SYBASE_V1200, SYBASE_V1250, MSSQLSERVER_V7, MSSQLSERVER_2000, and CLOUDSCAPE_V50.

If you want the utility to generate mappings in the manner used for WebSphere version 3.5, you can specify the 35 switch. The default mappings are much improved so you should only use this switch if you're having a particular problem with compatibility.

You can direct the utility to generate to SQLJ instead of JDBC by specifying the sqlj switch. There may be some performance advantages to using SQLJ in some cases.

Specifying the debug switch instructs the deploy utility to generate debug information in the deployed application.

The rmic parameter can be used to pass in options to the RMIC compiler. These options should be enclosed in quotes to keep them together, and separate them from other parameters and switches recognized by this command utility.

The ignoreErrors switch instructs the utility to proceed with the deployment even if errors are encountered. Otherwise, the utility will stop deployment if it encounters any errors. The quiet switch instructs the utility to suppress warning and informational messages during the deployment process. Likewise, the nowarn and noinform switches suppress warning and information messages, respectively. The trace switch will cause this utility to generate trace messages.

GenPluginCfg

The GenPluginCfg command utility can be used to generate the web server plug-in configuration documents. The syntax of this command is:

GenPluginCfg [-config.root <configrootDirectory>] [-cell.name <cellName>]               [-node.name <nodeName>] [-server.name <serverName>]               [-output.file.name <targetFile>] [-debug <enableDebug>]

Note that this command, unlike other commands, use a dotted-name convention for switch names.

Where:

  • configrootDirectory is the root directory of the configuration repository.

  • cellName is the name of your cell. Use this parameter if you're generating a plug-in configuration for a network deployment installation – will generate the plug-in for the entire cell.

  • nodeName is the name of your node. Use this parameter if you want to generate a configuration for only one node in a network deployment installation.

  • serverName is the name of your application server. Use this parameter only for a single-server installation.

  • targetFile is the name of the configuration file (and directory location) you want to generate. If you don't specify this parameter, the utility will generate the configuration in the plugin-cfg.xml file under the configuration root.

  • enableDebug is either "yes" or "no" indicating whether you want debugging enabled.

ikeyman

The ikeyman command starts the IBM Key Management utility. Use this utility for creating or managing X.509 certificate key-files – both for creating initial certificate and private-key pairs. The syntax of this command is:

ikeyman

This command accepts no arguments.

JspBatchCompiler

The JspBatchCompiler command utility can be used to pre-compile JSPs of an installed application. The syntax of this command is:

JspBatchCompiler –enterpriseapp.name <appName>                  [-webmodule.name <warName>][-cell.name <cellName>]                  [-node.name <nodeName>] [-server.name <serverName>]                  [-filename <jspName>] [-keepgenerated <enableKeepGenerated>]                  [-verbose <enableVerbose>]                  [-deprecation <enableDeprecation>]

This command must be used with enterprise applications that you've already installed. You specify the enterprise application containing the JSP pages that you want compiled in the appName parameter. If your application contains multiple WARs, and if you want the JSP pages of only a specific WAR file compiled then you can specify that WAR file in the warName parameter. Otherwise, the JSP pages in all of the WARs in the EARs will be compiled.

You usually have to supply the cellName, nodeName, and serverName on which your application is installed. These parameters will default, but the default values are usually insufficient to find your application.

If you only want to compile a specific JSP specify the jspName parameter. Otherwise, all of the JSP pages will be compiled.

The enableKeepGenerated parameter is either "true" or "false" indicating whether you want to keep the generated intermediate (servlet source) files produced by this compilation process.

If you want the servlet compiler to generated deprecation warnings then specify "true" for the enableDeprecation parameter.

Specify the verbose switch if you want detailed information messages produced during this command processing.

showlog

The showlog command utility will convert the (binary) contents of a specified log into a text format that can be used in an editor or other text processor. The syntax of this command is:

showlog <binaryFilename> [<outputFilename>]

The binaryFilename parameter should be the name of the activity.log, in the \logs subdirectory of the WebSphere installation location. Alternately, you can supply a fully qualified file and path name to the log that you want converted.

The outputFilename parameter should be specified if you want the output of the conversion written to a specific file. Otherwise, the converted text will be written to the standard out stream.

waslogbr

The waslogbr command starts the log browser. The syntax of this command is:

waslogbr [<logfile>]

The logfile parameter is optional, and should specify the fully qualified name of the log file that you want to browse. If this is not specified then the browser will start by opening the activity.log in the \logs sub-directory of the WebSphere installation root.




Professional IBM WebSphere 5. 0 Applicationa Server
Professional IBM WebSphere 5. 0 Applicationa Server
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net