Example wscp commands, procedures, and scripts

This file contains example wscp commands, Tcl procedures, and Tcl scripts. You can use these examples as provided, or customize them to develop procedures and scripts suited to your application. Many of the procedures and scripts are available as stand-alone files in Tcl sample scripts .

Note that not all wscp commands are represented in these examples. The examples are intended to demonstrate only the more frequently used commands (such as commands for creating and installing enterprise beans or displaying the attributes of an object). The examples include several custom procedures, a "batch mode" script for creating the default Advanced Application Server configuration, and other files that offer guidance in developing your own scripts and procedures.

Consult the wscp command-line help for a complete list of operations for each object type.

The following list contains a description of the administrative task that each example performs; states whether the example is a stand-alone wscp command, a Tcl procedure, or a Tcl script; and includes the name of the Tcl procedure or script.

Note:Many of the example scripts and procedures require that the file init.tcl be loaded prior to running. This file initializes several variables used elsewhere and contains useful Tcl procedures for accessing attributes, obtaining error status information, and other tasks. See Initialization and general-purpose procedures for a description of the contents of this file.

Initialization and general-purpose procedures

The init.tcl script initializes variables used elsewhere in the examples. Note that init.tcl was used for a specific test suite, but it contains several procedures that can be generally useful. If you are writing scripts that must accept some common command-line arguments, you can use or add to the predefined variables as needed. The contents of init.tcl are as follows:

The init.tcl script uses the global variable VERBOSE to echo the wscp commands as they are being executed. To set this variable to true, specify 1 as the value of the -verbose option when running wscp.bat.

C:\> wscp -verbose 1

The init.tcl script is available in Tcl sample scripts .


Configuring objects

The following examples demonstrate how to create and modify objects using the wscp interface.

Creating an object

The wscp create operation creates an object instance. The syntax is as follows:

object_type create object_name -attribute attr_list 

The arguments are as follows:

The following interactive wscp command creates an application server. The object_type argument (ApplicationServer) specifies that an application server object is to be operated on. The operation argument (create) specifies that an object is to be created. The object_name argument (/Node:dev-pc/ApplicationServer:myServer/) is the name of the server object to be created.

wscp> ApplicationServer create /Node:dev-pc/ApplicationServer:myServer/

The following wscp command creates a DataSource object named ds1. The attributes DatabaseName and JDBCDriver are required to create data source objects.

wscp> DataSource create /DataSource:ds1/  -attribute {  \
{DatabaseName WAS}{JDBCDriver driver1}}

Modifying the default values of attributes

An object type's attributes can have default values. When you create an object instance, the instance inherits any default values (unless you explicit set them in the create operation). The attributes of an object type can be thought of as falling into these categories:

The defaults operation is used to view or modify the default values for attributes. (All object types support the defaults operation with the exception of the Model object type.) The syntax is as follows:

<object_type> defaults  [-all] [-set] [-attribute <attribute list>]

If you do not specify any options, the defaults operation displays the default values for attributes of the specified object type. The following examples display the default values for attributes of the DataSource and EnterpriseBean object types. Note that, while other attributes exist for these object types, the defaults operation displays only those attributes that have default values.

wscp> DataSource defaults
{ConnTimeout 120000} {IdleTimeout 180000} {MaxPoolSize 10} 
{MinPoolSize 1} {OrphanTimeout 80}
wscp> EnterpriseBean defaults
{CreateDbTable True} {DbPassword {}} {DbUserId {}} 
{FindForUpdate False} {MaxPoolSize 100} {MinPoolSize 2}

The -all option displays all attributes (those that have default values as well as those that are not set). The following examples display all attributes of the DataSource and EnterpriseBean object types. Even though unset attributes do not have an initial setting, they are displayed as having the string value AttributeNotSet.

wscp> DataSource defaults -all
{FullName AttributeNotSet} {Name AttributeNotSet} {ConnTimeout 120000} 
{DatabaseName AttributeNotSet} {IdleTimeout 180000} {JDBCDriver AttributeNotSet} 
{MaxPoolSize 10} {MinPoolSize 1} {OrphanTimeout 80}
wscp> EnterpriseBean defaults -all
{FullName AttributeNotSet} {Name AttributeNotSet} {CurrentState AttributeNotSet} 
{DesiredState AttributeNotSet} {StartTime AttributeNotSet} {CreateDbTable True} 
{CreateDbTableActive AttributeNotSet} {DataSource AttributeNotSet} 
{DataSourceActive AttributeNotSet} {DbExclusiveAccess AttributeNotSet} 
{DbExclusiveAccessActive AttributeNotSet} {DbPassword {}} 
{DbPasswordActive AttributeNotSet} {DbUserId {}} {DbUserIdActive AttributeNotSet} 
{DeploymentDescriptor AttributeNotSet} {DeploymentDescriptorActive AttributeNotSet} 
{FindForUpdate False} {FindForUpdateActive AttributeNotSet} {Home AttributeNotSet} 
{JarFile AttributeNotSet} {JarFileActive AttributeNotSet} {MaxPoolSize 100} 
{MaxPoolSizeActive AttributeNotSet} {MinPoolSize 2} {MinPoolSizeActive AttributeNotSet} 
{PrimaryKeyCheck AttributeNotSet} {PrimaryKeyCheckActive AttributeNotSet}

The -attribute option is used to display the default value for one or more specified attributes. Its argument must be a Tcl list. If the specified attribute has a default value, the value is displayed. The following example displays the default values of the MinPoolSize and MaxPoolSize attributes of DataSource objects:

wscp> DataSource defaults -attribute {MaxPoolSize MinPoolSize}
{MaxPoolSize 10} {MinPoolSize 1}

The -set and -attribute options are used together to change the default value of one or more attributes. Any object instances that are subsequently created inherit the new default values. The following example sets the default value for the OrphanTimeout attribute of DataSource objects:

wscp> DataSource defaults -set -attribute {{OrphanTimeout 120}}
wscp> DataSource defaults
{ConnTimeout 120000} {IdleTimeout 180000} {MaxPoolSize 10} 
{MinPoolSize 1} {OrphanTimeout 120}
Note:Use caution when changing the default values of attributes. If you change the value of an attribute that is initially not set--that is, one that does not have a default value--you cannot revert the attribute to its original unset state. You can only change its value to a different value.

You cannot set a default value for a required attribute. Attempting to do so results in an error.

Modifying an object

The wscp modify operation sets the value of one or more attributes. If a value already exists for an attribute, that value is replaced. The syntax is as follows:

object_type modify  object_name -attribute  attr_list 

The arguments are as follows:

The following example shows how to modify the value of the PingInterval attribute of an application server:

wscp> ApplicationServer show /Node:dev-pc/ApplicationServer:myServer/  \
-attribute PingInterval
 
{PingInterval 60}
wscp> ApplicationServer modify /Node:dev-pc/ApplicationServer:myServer/ \
-attribute {{PingInterval 120}}
wscp> ApplicationServer show /Node:dev-pc/ApplicationServer:myServer/  \
-attribute PingInterval
{PingInterval 120}
 

Modifying an Environment attribute (modEnv procedure)

The following Tcl procedure, modEnv, can be used to modify the Environment attribute of one or more application servers in a domain. The legal value of the Environment attribute is a list of strings of the form name=value. This procedure modifies a specified element of the list (or adds the element if it is not present) and retains the values of the other elements. The procedure takes three arguments: a server name, an environment variable name, and the value to which the variable is to be set.

The procedure does the following:

#
# modEnv - procedure for modifying the Environment attribute of one or
# more application servers in a domain.  The specified environment variable
# is modified (or added if it is not present), and the values of other 
# variables are retained.
#
# Arguments:
#
# server - the fully qualified name of the application server whose
# Environment attribute is to be modified.
#
# variable - the name of the environment variable to modify.
#
# value - the new value of the environment variable.
#
# To modify the Environment attribute of multiple servers, use
# the Tcl foreach command, for example
# wscp> foreach server [ApplicationServer list] {modEnv $server TEST_VARIABLE 3.5}
#
# The file init.tcl must be loaded prior to using this procedure.
 
 
proc modEnv {server variable value} {
    set oldEnv {}
    getAttrs $server attr Environment
    if {[info exists attr(Environment)]} {set oldEnv $attr(Environment)}
    # append to environment if not found; replace if it is found
    set i [lsearch -regexp $oldEnv ^$variable=]
    if {$i == -1} {
 set newEnv [lappend oldEnv "$variable=$value"]
    } else {
 set newEnv [lreplace $oldEnv $i $i "$variable=$value"]
    }
    set attr(Environment) $newEnv
    setAttrs $server attr
}
 
 
 

The following example shows the use of modEnv to modify the value of the PATH variable in two application servers in a domain (or to add the PATH variable if it does not exist). The existing value of the Environment attribute of each server is as follows:

wscp> ApplicationServer show $serv1 -attribute {Environment}
{Environment PATH=/myPath}
wscp> ApplicationServer show $serv2 -attribute {Environment}
{Environment {{OTHERVARIABLE=word1 word2}}}

The following calls to modEnv modify each Environment attribute. The resulting change is shown for the two example servers:

wscp> modEnv $serv1 PATH /revisedPath
wscp> ApplicationServer show $serv1 -attribute {Environment}
{Environment PATH=/revisedPath}
wscp> modEnv $serv2 PATH /revisedPath
wscp> ApplicationServer show $serv2 -attribute {Environment}
{Environment {{OTHERVARIABLE=word1 word2} PATH=/revisedPath}}

The modEnv procedure can be used to change the Environment attribute of multiple servers of the same type. In the following example, the Tcl foreach command is used to call the modEnv procedure on each ApplicationServer instance in a domain. The value TEST_VARIABLE=3.5 is added (or appended) to the attribute as needed.

wscp> foreach server [ApplicationServer list] {modEnv $server TEST_VARIABLE 3.5}

Creating and installing drivers and data sources

The following example wscp commands create and install a JDBC driver and data source. The script init.tcl must be loaded prior to using these commands (init.tcl initializes NODE, DB2_HOME, and other variables used here). For the JDBC Driver, substitute different values for the implementation class, URL prefix, and JAR file as needed.

wscp> set jdbc "/JDBCDriver:DB2Driver/"
 
# Create a JDBCDriver object
    
wscp> JDBCDriver create $jdbc -attribute \
{{ImplClass com.ibm.db2.jdbc.app.DB2Driver}{JTAEnabled true}{UrlPrefix jdbc:db2}}
 
# Create a DataSource object
 
wscp> set data "/DataSource:testDataSource/"
 
wscp> set attrs "{DatabaseName WAS}{JDBCDriver $jdbc}"
 
wscp> DataSource create $data -attribute $attrs
 
# Install the JDBCDriver object
 
wscp> JDBCDriver install $jdbc -node $NODE \
 -jarFile ${DB2_HOME}${FILE_SEPARATOR}java${FILE_SEPARATOR}db2java.zip
 
 

The following example commands uninstall the JDBCDriver object and remove the DataSource object:

# Uninstall the JDBCDriver object
    
wscp> JDBCDriver uninstall $jdbc -node $NODE
    
# Remove the DataSource object just created
    
wscp> DataSource remove $data
    
# Remove the JDBCDriver object just created
    
wscp> JDBCDriver remove $jdbc
    

The file datsrc.tcl in Tcl sample scripts contains an example script for working with DataSource and JDBCDriver objects. It includes the following custom procedure for creating a DataSource object:

proc create_DataSrc { {name testDataSource} {jdbcDriver DB2Driver} \
	{DBname WAS}} {
    global VERBOSE
    set data "/DataSource:${name}/"
    set jdbc "/JDBCDriver:${jdbcDriver}/"
    # Create a DataSource object
    set attrs "{DatabaseName $DBname}{JDBCDriver $jdbc}"
    set cmd {DataSource create $data -attribute $attrs}
    if {$VERBOSE} {puts [subst "# $cmd"]}
    eval $cmd
}

See Administering database connections for more information.


Installing and running enterprise beans

The following steps outline the procedure for developing and deploying enterprise beans. The procedure is generally the same for both the console and wscp. However, some differences exist. In particular, deploying and installing a bean in an application server is done in two separate steps with wscp and in one step with the console. Other differences are noted as necessary. Details on the wscp commands referenced in the procedure follow the steps.

  1. Develop (write and compile) components of the enterprise bean, which include the bean class, the home and remote interfaces, and (for entity beans) the primary key class and finderHelper interface. You can use VisualAge for Java or do this manually.

  2. Create the deployment descriptor and package the bean components into an EJB JAR file. The EJB JAR file consists of the bean .class files, the deployment descriptor, and the manifest file. You can use the jetace tool or VisualAge for Java.

  3. For entity beans with bean-managed persistence (BMP), generate the database tables by using the database administration tools provided by your database vendor.

    For entity beans with container-managed persistence (CMP), generate the database tables by using either VisualAge for Java or wscp. The EnterpriseBean object's CreateDbTable attribute is set to true by default. If you do not want the table automatically created for you, modify this value when the object is defined (created).

  4. Deploy the JAR file and install the enterprise beans in an application server. One or more JAR files can be installed in a single container. The deployed JAR file consists of the EJBHome and EJBObject classes, persistor and finder classes, and stub and skeleton files. Use one of the following methods:

  5. The wscp interface automatically appends the enterprise bean's JAR file to the appropriate classpaths. However, if the bean references other classes, those classes must be identified in the DependentClasspath attribute of the Node object.

  6. Start the enterprise bean.

Consider the following when installing enterprise beans:

The wscp interface provides the following operations related to deploying and running enterprise beans:

The EnterpriseBean deploy operation generates a deployed JAR file (that is, it generates the associated classes and constructs the JAR file). You must then create (install) the bean by using the EnterpriseBean create operation. The syntax is as follows:

EnterpriseBean deploy jar_file[/serialized_deployment_descriptor] 
 -node node_name [-trace] [-WLMize]

The arguments and options are as follows:

The EnterpriseBean create operation installs an already-deployed JAR file in an application server. The syntax is as follows:

EnterpriseBean create  object_name [-attribute attribute list]

The required attributes of an enterprise bean include the DeploymentDescriptor and JarFile attributes. The DeploymentDescriptor attribute is a string that includes the remote interface name, a JAR file, and the node name, each separated by the @ symbol. The syntax is as follows:

bean_remote_interface[ @jar_file ] @node_name ] ]

where bean_remote_interface is the name of the bean's remote home interface, jar_file is the full pathname of the JAR file on the node for which the enterprise bean is being defined, and node is the name of the node where the enterprise bean is being created. The JAR file and the node name are optional, and are automatically supplied if they are not specified. The value for jar_file is taken from the value of the JarFile attribute. The value for node name is extracted from the fully-qualified name of the enterprise bean.

The .ser file is retrieved by using this bean name. If the enterprise bean is a CMP entity bean, the DataSource attribute is also required. Note that, by default, the createDbTable attribute is set to true. If a table already exists for the CMP entity bean (for example, for a legacy application), or if you plan to use database vendor tools to create the table, set the createDbTable attribute to false.

The EnterpriseBean serializeDD operation creates a serialized deployment descriptor (.ser) file from a properties (.dd) file. Because wscp does not support modification of the serialized deployment descriptor (as does the console), you can modify the .dd file by using any text editor. Then use the serializeDD operation to generate a new serialized deployment descriptor file. The syntax is as follows:

EnterpriseBean serializeDD  file_name [-output file_name]

The arguments and options are as follows:

The property names and values for a .dd file are as follows. The properties are organized by the Java class with which they are associated. The property names are derived from the setter methods for the associated class, with the Control Descriptor names taking an optional method_name. prefix. This prefix indicates to which method the ControlDescriptor applies. If no method is specified, the ControlDescriptor applies to all methods of the bean.

Note:Currently, there is no support for AccessControlEntry.
DeploymentDescriptor
  AssociatedBeans=<string>[,<string>]...
  BeanHomeName=<string>
  EnterpriseBeanClassName=<string>
  EnvironmentProperties=<filename>
  HomeInterfaceClassName=<string>
  RemoteInterfaceClassName=<string>
  ControlDescriptor
    [<methodName>.]IsolationLevel=(TRANSACTION_READ_COMMITTED |
       TRANSACTION_READ_UNCOMMITTED |
       TRANSACTION_REPEATABLE_READ |
       TRANSACTION_SERIALIZABLE)
    [<methodName>.]RunAsMode=(CLIENT_IDENTITY | SPECIFIED_IDENTITY |
         SYSTEM_IDENTITY)
    [<methodName>.]TransactionAttribute=(TX_BEAN_MANAGED | TX_MANDATORY |
      TX_NOT_SUPPORTED | TX_REQUIRED |
      TX_REQUIRES_NEW | TX_SUPPORTS)
    <methodName>.ReadOnlyAttribute=true
SessionDescriptor
  SessionTimeout=<int>
  StateManagementType=(STATEFUL_SESSION | STATELESS_SESSION)
EntityDescriptor
  ContainerManagedFields=<string>[,<string>]...
  IsReentrant=(false | true)
  PrimaryKeyClassName=<string>

The EnterpriseBean start operation starts an enterprise bean. The syntax is as follows:

EnterpriseBean start  object_name

The file ebean.tcl in Tcl sample scripts contains an example script for deploying and creating (installing) a container-managed persistence (CMP) entity bean. It includes the following custom procedure for generating a deployed JAR file from an undeployed EJB JAR file:

 
proc deploy_bean {jarFileName deployment_descriptor {useWLM 0}} {
    global WAS_HOME FILE_SEPARATOR VERBOSE NODE
    set jar "${WAS_HOME}${FILE_SEPARATOR}deployableEJBs${FILE_SEPARATOR}"
    append jar "${jarFileName}"
    if { [file exists $jar] == 0 } {
	puts "File not found: $jar"
	return 0
    }
    set dd "${jar}/${deployment_descriptor}"
    set cmd {EnterpriseBean deploy $dd -node $NODE -trace}
    if {$useWLM} {
	append cmd " -WLMize"
    }
    if {$VERBOSE} {puts [subst "# $cmd"]}
    eval $cmd
    return 1
}
  

See Administering enterprise beans for additional information.

Re-creating the default installation

The Tcl script defcfg.tcl can be used to re-create the default installation, which consists of the default objects automatically created in the repository when the install.initial.config property is set to true in the admin.config file. Prior to running the script, you must load the file init.tcl. Both scripts are included in Tcl sample scripts .

Creating an enterprise application

An enterprise application is a heterogeneous collection of resources, such as a user application containing multiple enterprise beans, or a combination of enterprise bean servers, enterprise beans, servlets, and other Web resources. Resources are added to and removed from enterprise applications by using the addRelation and removeRelation operations of EnterpriseApplication objects. The following commands create an enterprise application that consists of an enterprise bean, a Web application, and a Web resource. The sequence of commands assumes that the variables $bean, $webapp, and $uri have been set to an existing enterprise bean, Web application, and Web resource, respectively.

wscp> set appl "/EnterpriseApplication:testAppl/"
wscp> EnterpriseApplication create $appl
 
wscp> EnterpriseApplication addRelation $appl -relationName $bean
wscp> EnterpriseApplication addRelation $appl -relationName $webapp
wscp> EnterpriseApplication addRelation $appl -relationName $uri

The following command removes the enterprise bean from the enterprise application:

wscp> EnterpriseApplication removeRelation $appl -relationName $bean

Starting and stopping live repository objects

The wscp interface can be used to start and stop any live repository object. Live repository objects include application servers, containers, generic servers, enterprise beans, models, nodes, servlets, servlet engines, Web applications, servlet redirectors, and session managers. The syntax for the start and stop operations is as follows:

object_type start  object_name 
object_type stop  object_name

The following example starts the application server named myServer:

wscp> ApplicationServer start /Node:dev-pc/ApplicationServer:myServer/

Displaying information about objects

The following examples include wscp operations and custom Tcl procedures for displaying information about objects.

Listing objects

The wscp list operation lists all instances of an object type or, optionally, only those instances that meet the specified criteria. The syntax is as follows:

object_type list  [-constraint attr_list]  [-recursive] 

The arguments are as follows:

The following example command lists all instances of the ApplicationServer object type in the domain:

wscp> ApplicationServer list
{/Node:dev-pc/ApplicationServer:Default Server/} {/Node:dev-pc/ApplicationServer:AcctServer1/} 
{/Node:dev-pc/ApplicationServer:Model AppServer1/} {/Node:dev-pc/ApplicationServer:Model AppServer2/} 
{/Node:dev-pc/ApplicationServer:CustServer1/}

The -recursive option lists all instances of any object type that belongs to the containment hierarchy of the specified type. That is, for an ApplicationServer object type, the -recursive option lists all instances of EJBContainer, EnterpriseBean, ServletEngine, WebApplication, UserProfile, and SessionManager.

wscp> ApplicationServer list -recursive
 . . .
output too long to include
. . .

The following example lists only those application servers whose PingInterval attribute has 60 as its value:

wscp> ApplicationServer list -constraint {{PingInterval 60}}
 
{/Node:dev-pc/ApplicationServer:AcctServer1/} {/Node:dev-pc/ApplicationServer:CustServer1/} 
{/Node:dev-pc/ApplicationServer:Model AppServer2/}

Querying (displaying) attributes

The wscp show operation displays the values of all attributes or a specified subset of attributes for an object instance. The syntax is as follows:

object_type show object_name [-all] [-attribute attr_list]

The arguments are as follows:

The following show operation displays all attributes of an enterprise bean named myCardBean. (The variable $bean is set to the fully qualified name of the enterprise bean.)

wscp> EnterpriseBean show $bean -all
{FullName 
{/Node:dev-pc/ApplicationServer:AcctServer1/EJBContainer:AcctServer1 EJB Container/ \
EnterpriseBean:myCardBean/}} 
{Name myCardBean} {CurrentState Running} {DesiredState Running} 
{StartTime 955043839566} {CreateDbTable True} {CreateDbTableActive False} 
{DataSource /DataSource:testDataSource/} {DataSourceActive /DataSource:testDataSource/}
{DbExclusiveAccess False} {DbExclusiveAccessActive False} 
{DbPassword {}} {DbPasswordActive {}} {DbUserId {}} {DbUserIdActive {}} 
{DeploymentDescriptor com.abc.systest.ejs.debitCard.Card} 
{DeploymentDescriptorActive com.abc.systest.ejs.debitCard.Card} 
{FindForUpdate False} {FindForUpdateActive False} {Home AttributeNotSet} 
{JarFile {e:\websphere\appserver\deployedEJBs\DeployedCard.jar}} 
{JarFileActive {e:\websphere\appserver\deployedEJBs\DeployedCard.jar}}
{MaxPoolSize 100} {MaxPoolSizeActive 100} {MinPoolSize 2} {MinPoolSizeActive 2} 
{PrimaryKeyCheck False} {PrimaryKeyCheckActive False}

The following show operation displays the values of specific attributes (the Name and CurrentState attributes) of an application server:

wscp> ApplicationServer show /Node:dev-pc/ApplicationServer:myServer/ \
-attribute {Name CurrentState}
{Name myServer} {CurrentState running}

Note the difference between the show and showAttrs operations. All object types have a show operation for displaying attributes. Model objects have, in addition to the show operation, the showAttrs operation. For model objects, the show operation displays the attributes associated with the model--for example, the CloneInterfaceClass, IfStarted, and StartTime attributes. The showAttrs operation displays the clone attributes associated with the model. (These attributes match the properties for the resource type of the model, such as a servlet or application server.)

The following examples illustrate output for a show and showAttrs operation. The object testModel2 is a model object for an application server:

wscp> Model show /Model:testModel2/
{FullName /Model:testModel2/} {Name testModel2} {Attributes EditorNotDefinedForThisProperty} 
{CloneInterfaceClass com.ibm.ejs.sm.beans.EJBServer} {ConfigNo 2} 
{IfStarted False} {StartTime 0}
wscp> Model showAttrs /Model:testModel2/
{CurrentState Stopped} {DesiredState Stopped} {StartTime 0} 
{CommandLineArgs {{} {}}} {CommandLineArgsActive {{} {}}} 
{Environment {}} {EnvironmentActive {}} {Executable java} 
{ExecutableActive java} {GroupId {}} {GroupIdActive {}}
{MaxStartupAttempts 5} {PingInitialTimeout 300} {PingInterval 60} 
{PingTimeout 200} {ProcessId 0} {ProcessPriority 20} 
{ProcessPriorityActive 20} {SelectionPolicy roundrobinpreferlocal} 
{Stderr {e:\websphere\appserver\logs\default_server_stderr.log}} 
{StderrActive {e:\websphere\appserver\logs\default_server_stderr.log}} 
{Stdin {}} {StdinActive {}} {Stdout {e:\websphere\appserver\logs\default_server_stdout.log}} 
{StdoutActive {e:\websphere\appserver\logs\default_server_stdout.log}}
{Umask 18} {UmaskActive 18} {UserId {}} {UserIdActive {}} 
{WorkingDirectory {}} {WorkingDirectoryActive {}} 
{AdminAgentIOR {}} {DebugEnabled False} {DebugEnabledActive False} 
{EpmSpec {}} {LogFileSpec {}} {LogFileSpecActive {}} 
{OLTEnabled False} {OLTEnabledActive False} {OLTServerHost {}} 
{OLTServerHostActive {}} {OLTServerPort -1} {OLTServerPortActive -1}
{SecurityEnabled False} {SecurityEnabledActive False} 
{SourcePathActive {}} {SystemProperties {}} {SystemPropertiesActive {}}
{ThreadPoolSize 5} {TraceOutput {}} {TraceOutputActive {}} 
{TraceSpec *=all=disabled} {TraceSpecActive *=all=disabled} 
{TranInactivityTimeout 60000} {TranTimeout 120}

The following custom procedure, display, displays the output of the show operation in a readable format--one attribute per line. The procedure's arguments are an object type and the name of an object instance.

#
# display - a procedure for displaying attributes in a readable format.
#
# Arguments:
#
# type - the object type whose attributes are to be displayed.
# 
# name - the fully-qualified name of the object instance whose attributes 
# are to be displayed.
#
 
proc display {type name} {
    
    set attrs [$type show $name]
    foreach attr $attrs {
	puts $attr
    }
}

The following example demonstrates output from the display procedure. The procedure is used display the attributes of a DataSource object named testDataSource:

wscp> display DataSource /DataSource:testDataSource/
FullName /DataSource:testDataSource/
Name testDataSource
ConnTimeout 120000
DatabaseName WAS
IdleTimeout 18000
JDBCDriver /JDBCDriver:DB2Driver/
MaxPoolSize 30
MinPoolSize 1
OrphanTimeout 900

This procedure is available in Tcl sample scripts .

Printing an object's attributes

The custom Tcl procedure printAttributes uses the attributes operation to print all or a subset of attributes for one or more object types.

#
# printAttributes - prints the attributes for any objects specified or 
# for all objects if no objects are specified.
#
# Arguments:
# 
# options - a list of options to control the types of attributes printed. 
# Every option in the list of option names must be a valid option to the 
# wscp attributes command (for example, -required or -cloneOnly)
# AND the option name must begin with a "-".
#
# objects - a list of objects whose attributes are to be printed.
# 
# The file init.tcl must be loaded prior to using this procedure.
#
 
proc printAttributes {{options all} {objects all} args} {
    global OBJECTS
    if {[string first "-" $options] != 0} {
	set objects $options
	set options ""
    }
    if {[string compare $objects "all"] == 0} {set objects $OBJECTS}
    if {$args != ""} {
	foreach arg $args {
	    lappend objects $arg
	}
    }
 
    foreach o $objects { 
	set cmd [concat $o attributes $options]
	puts "# $cmd"
	set result [eval $cmd]
	puts $result
	
    }
}

The following example commands demonstrate the use of the printAttributes procedure. The first example prints only the attributes associated with clones of ApplicationServer objects.

wscp> printAttributes -cloneOnly ApplicationServer
# ApplicationServer attributes -cloneOnly
FullName Name ServerId ServerInstance

The following command prints all required attributes for all object types:

wscp> printAttributes -required
# SessionManager attributes -required
Name
# Servlet attributes -required
Name Code URIPaths
# JDBCDriver attributes -required
Name ImplClass
# WebResource attributes -required
Name PathName RootURI
# GenericServer attributes -required
Name Executable
# ServletEngine attributes -required
Name Enabled
# VirtualHost attributes -required
Name
# UserProfile attributes -required
Name
# EJBContainer attributes -required
Name
# EnterpriseApplication attributes -required
Name
# EnterpriseBean attributes -required
Name DeploymentDescriptor JarFile
# WebApplication attributes -required
Name Classpath DocRoot URIPath
# ApplicationServer attributes -required
Name
# Model attributes -required
Name CloneInterfaceClass
# ServletRedirector attributes -required
Name
# Node attributes -required
Name
# DataSource attributes -required
Name DatabaseName JDBCDriver

The following command prints, for ApplicationServer and ServletEngine objects, only those attributes that are required and that are associated with clones of those objects:

wscp> printAttributes {-required -cloneOnly} {ApplicationServer ServletEngine}
# ApplicationServer attributes -required -cloneOnly
FullName Name ServerId ServerInstance
# ServletEngine attributes -required -cloneOnly
FullName Name Enabled

This procedure is available in Tcl sample scripts .

Viewing the containment hierarchy

The custom procedure printContainment can be used to display the containment hierarchy of a single object type or the entire object type hierarchy. The procedure takes zero or more arguments. Arguments are object types. If no arguments are supplied, the procedure prints the containment hierarchy for all object types. If one or more arguments are supplied, the procedure prints the containment hierarchy for the specified object types only. Prior to using the procedure, you must also load the init.tcl file.

#
# printContainment - a procedure that prints the containment hierarchy for 
# one or more object types. 
# 
# The script init.tcl must be loaded prior to using this procedure.
#
# Arguments:
#
# objects - one or more object types whose containment hierarchies are to be printed.
#
# The init.tcl file must be loaded prior to using this procedure.
#
 
proc printContainment {{objects all} args} {
    global OBJECTS
    if {$objects == "all"} {set objects $OBJECTS}
    
    if {"$args" != "" } {
	foreach elem $args {
	    lappend objects $elem
	}   
    }
 
    foreach o $objects { 
	set cmd [concat $o containment]
	puts "# $cmd"
	set result [eval $cmd]
	puts $result
    }
}

The following example commands demonstrate the use of the printContainment procedure:

wscp> printContainment
# SessionManager containment
Node ApplicationServer ServletEngine SessionManager
# Servlet containment
Node ApplicationServer ServletEngine WebApplication
Servlet
# JDBCDriver containment
JDBCDriver
# WebResource containment
VirtualHost WebResource
# GenericServer containment
Node GenericServer
# ServletEngine containment
Node ApplicationServer ServletEngine
# VirtualHost containment
VirtualHost
# UserProfile containment
Node ApplicationServer ServletEngine UserProfile
# EJBContainer containment
Node ApplicationServer EJBContainer
# EnterpriseApplication containment
EnterpriseApplication
# EnterpriseBean containment
Node ApplicationServer EJBContainer EnterpriseBean
# WebApplication containment
Node ApplicationServer ServletEngine WebApplication
# ApplicationServer containment
Node ApplicationServer
# Model containment
Model
# ServletRedirector containment
Node ServletRedirector
# Node containment
Node
# DataSource containment
DataSource
wscp> printContainment ServletEngine
# ServletEngine containment
Node ApplicationServer ServletEngine
wscp> printContainment UserProfile EnterpriseBean
# UserProfile containment
Node ApplicationServer ServletEngine UserProfile
# EnterpriseBean containment
Node ApplicationServer EJBContainer EnterpriseBean

The printContainment procedure is available in Tcl sample scripts .

Displaying select attributes

The following custom procedure, showServerStatus, displays the status (the value of the CurrentState attribute) of all application servers in a domain. The procedure can be customized to display additional attributes or attributes of other objects.

#
# showServerStatus - a procedure for displaying the value of the
# Name and CurrentState attribute of all application servers 
# in a domain.
#
 
proc showServerStatus {} {
	
	puts "\nStatus of servers in the domain:\n"
	
	foreach ejbserver [ApplicationServer list] {
	puts [ApplicationServer show $ejbserver -attribute {Name CurrentState}]
	}
}

The following example demonstrates output of the showServerStatus procedure:

wscp> showServerStatus
Status of servers in the domain:
{Name {Default Server}} {CurrentState {Initialization Failed}}
{Name {Appl Server1}} {CurrentState Running}
{Name {Model Server1}} {CurrentState Stopped}
{Name {Model Server2}} {CurrentState Stopped}
{Name {Appl Server2}} {CurrentState Running}
{Name {My Server}} {CurrentState Stopped}
{Name {Test Server}} {CurrentState Stopped}

The display procedure is available in Tcl sample scripts .


Removing objects and applications

The wscp remove operation removes objects (and all references to those objects) from the domain. A live repository object must be stopped before being removed. The syntax of the remove operation is as follows:

object_type remove  object_name  [-recursive] 

If the object to be removed contains other objects, removal fails unless you use the -recursive option. The -recursive option removes all instances of any object type that belongs to the containment hierarchy of the object instance being removed. For example, if an EnterpriseApplication instance is removed recursively, any object instance belonging to the containment hierarchy of the EnterpriseApplication object is also removed (all enterprise beans, servlets, Web applications, application servers, and so on). The recursion takes place in a downward direction (removal of object instances below the specified object in the hierarchy).

The following example command recursively removes components of an enterprise application named StockApp:

wscp> Application remove /Node:dev-pc/Application:StockApp/ -recursive

Importing and exporting a configuration by using XMLConfig

The XML Configuration Management Tool (XMLConfig) can be invoked from within wscp. The syntax is as follows:

wscp> XMLConfig export <file_name> [-partial <file_name>] 
wscp> XMLConfig import <file_name> [-substitute <list>]

For an export, specify the name of an XML output file for the file_name argument. Specify the name of an XML data file for the -partial option. For an import, specify the name of an XML data file for the file_name argument. Specify a list of variable-value pairs for the -substitute option as follows:

{{variable1 value1}{variable2 value2}}

If a value string contains spaces, it must also be enclosed in braces.



Copyright IBM Corporation 1999, 2000. All Rights Reserved