Friday, April 2, 2010

How to set a custom property on a channel?

Use wsadminlib's method setChannelCustomProperty().

Before we start, here is an example of channel custom properties in the admin console: Click Application Servers-> server1-> Web container settings-> Web container transport chains-> WCInboundDefault-> Web container inbound channel (WCC2)-> Custom properties. I have no idea what a channel is, but I can show you how to set a custom property on one...

Method setChannelCustomProperty() allows us to specify the channel either by an end point name or the channel name. Take a look at the method in wsadminlib, where there is actually good pydoc to explain the parameters.

The first five parameters are required, in the specified sequence. The last two, endPointName and channelName, are optional and have defaults. You must specify exactly one of them.

So let's add a hypothetical custom property, enablePlayaDust=true, by specifying the channel name. Create a python script file named

Wednesday, March 31, 2010

How to set a server's listening port number?

Use wsadminlib's method setServerPort(). Here's an example of setting the web container's default port:

nodename = 'node1'
servername = 'server1'
endPointName = 'WC_defaulthost'
port = 9083
setServerPort(nodename, servername, endPointName, port)

Note that the name arguments are python strings, but the port is a number. Here is a screenshot:

Tuesday, March 30, 2010

How to save my changes?

Use wsadminlib's method save(). This method saves your changes and pushes them out to all the nodes immediately (if you are running in a cell environment). It also displays all the changes, for debug purposes.

Here is a screenshot from the end of an exercise where I created a new server:

[2010-0301-1150-2400] save: AdminConfig.queryChanges()
[2010-0301-1150-2400] save: WASX7146I: The following configuration files contain unsaved changes:
[2010-0301-1150-2400] save: cells/ndcell/nodes/node1/servers/server1/server.xml
[2010-0301-1150-2400] save: AdminConfig.hasChanges()
[2010-0301-1150-2400] save: AdminConfig.getSaveMode()
[2010-0301-1150-2400] save: rollbackOnConflict
[2010-0301-1150-2400] save:
[2010-0301-1150-2400] save: Save complete!
[2010-0301-1150-2500] wsadminlib.syncall Start
[2010-0301-1150-2500] wsadminlib.syncall Sync config to node node1
[2010-0301-1150-2600] wsadminlib.syncall Done

Monday, March 29, 2010

How to set the trace spec on a server?

Use wsadminlib's method setServerTrace(). Here is a simple example:

nodename = 'node1'
servername = 'server1'
tracespec = '**=all'
setServerTrace(nodename, servername, tracespec)

And a screen capture:

root@ding6: /opt/WAS70/bin/ -lang jython -host ding6 -port 8879
WASX7209I: Connected to process "dmgr" on node dmgr using SOAP connector; The type of process is: DeploymentManager
WASX7031I: For help, enter: "print"
$Id: 50 2009-01-14 14:42:11Z ding $
[2010-0301-1149-3100] enableDebugMessages Verbose trace messages are now enabled; future debug messages will now be printed.
wsadmin>nodename = 'node1'
wsadmin>servername = 'server1'
wsadmin>tracespec = '**=all'
wsadmin>setServerTrace(nodename, servername, tracespec)
[2010-0301-1150-0800] setServerTrace: Setting tracing on server node1/server1 to **=all

Be sure to take a look at the method in It has defaults which you can override for the number and size of backup log files. And on z/OS, it automatically stores the log files in the same location as they appear on non-Z platforms.

Sunday, March 28, 2010

What is this method sop()? has a rudimentary trace/logging facility in method sop(). The name is a snarky acronym taken from Java's System.out.println() command.

Input: Method sop() takes two strings as parameters, the name of the calling method, and the message.

Output: Method sop() prints these to the console, along with a terse, internationally-understandable timestamp: [YYYY-MMDD-hhmm-ss00]

You can turn these messages on and off dynamically by calling these toggle methods:
- enableDebugMessages()
- disableDebugMessages()
sop() messages are disabled by default. I like verbose messages, so all of my scripts call enableDebugMessages() right at the start.

Note that wsadminlib contains many calls to sop() which are commented-out. These are usually very verbose messages which were written by the original method developer, but not needed since. However, we left them in intentionally. If you are having trouble making a specific method work, or you want to see the gory details for use in your own method, try uncommenting some of these messages for extra hints.

Oh, and one more thing. You can call method sop() from your own script files as well. That way, your messages will have the same fancy timestamp as wsadminlib's, and your messages will look consistent with wsadminlib's too (which I find makes everything easier to read).