Not posted for a while, apologies for that, but I thought since I’m currently keeping documents with lots of lists of commands I’ve been using it would be useful to post them here also.

So today is about backing up and restoring db2 database. Pretty easy, but tricky to get the command correct unless you know the syntax.

Backup

db2 backup db DB_NAME to /home/db2inst1/backup/

Restore

db2 restore db DB_NAME from /home/db2inst1/backup/ into DB_NAME

(typically I’ll have created an empty database already for this)

I’ve been trying out the latest version of WebSphere Commerce (version 7), and one of the first tasks I’m working through is enabling WCS to use MQ as an inbound / outbound transport adapter.

The instructions for this are fairly clear in the Info Centre, apart from the point where; if you are using the Developer Edition of commerce, you require to enable the MQ Listener in WCS.

This used to be carried out by changing the config file wc-server.xml; by searching for the line “Listener for WebSphere MQ (TransportAdapter)” and setting the enable variable to “true”. The issue I found is that this file has moved between v6 and v7.

In v6, this file is listed as being in this location: WCDE_installdir/xml/onfig/wc-server.xml

I’ve found in v7 this file has been moved to: WCDE_installdir/workspace/WC/xml/config/wc-server.xml (e.g C:\WebSphere\WCToolkit\workspace\WC\xml\config\wc-server.xml on my system)



I’ve encountered this issue twice now, whilst trying to call Web Serices via a SOAP or HTTP node, that are served up via WebSphere Application Server (WAS).

The error in the WAS SystemOut.log reads a little like this, upon invokation of the Web Service:

[28/09/09 22:29:35:328 BST] 00000029 InternalExcep E com.ibm.ws.webservices.engine.InternalException <init> WSWS3227E:  Error: Exception:
 java.lang.Exception: WSWS3710E: Internal Error: Attempt to change encoding on WebServicesInputSource from utf-8 to ibm-437.
 at com.ibm.ws.webservices.engine.InternalException.<init>(InternalException.java:124)
 .....
.....
[28/09/09 22:29:35:546 BST] 00000029 PivotHandlerW E com.ibm.ws.webservices.engine.PivotHandlerWrapper bindExceptionToResponse WSWS3400I: Info: unexpected exception.
 com.ibm.ws.webservices.engine.InternalException: java.lang.Exception: WSWS3710E: Internal Error: Attempt to change encoding on WebServicesInputSource from utf-8 to ibm-437.
 at com.ibm.ws.webservices.utils.WebServicesInputSource.setEncoding(WebServicesInputSource.java:197)
 .....
.....

[28/09/09 22:29:35:546 BST] 00000029 UserException E   WSWS3228E: Error: Exception: WebServicesFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
 faultString: WSWS3400I: Info: unexpected exception.
 faultActor: null
 faultDetail: 

WSWS3400I: Info: unexpected exception.
 at com.ibm.ws.webservices.engine.PivotHandlerWrapper.bindExceptionToResponse(PivotHandlerWrapper.java:414)
 .....
.....

This error had me scratching my head for a while, mainly as I’m a bit of a novice with WebSphere Message Broker. After encountering it a second time, I came across a point to a fix where I need to force the CodedCharSetID from the default of 437 to 1208 (utf-8).  Not sure why this is, but I suspect it might be something to do with me using a GB local on WAS, but the WMB toolkit using US Ascii by default?

I achieved this by creating an ESQL compute node and placing it before the SOAP / HTTP node. The ESQL code is as follows:

CREATE COMPUTE MODULE PriceChange_Flow_Change_CodedCharSetID
 CREATE FUNCTION Main() RETURNS BOOLEAN
 BEGIN
 CALL CopyMessageHeaders();
 CALL CopyEntireMessage();

 SET OutputRoot.MQMD.CodedCharSetId = '1208';

 RETURN TRUE;
 END;

I’m far too used to being spoilt with using MQ Explorer,  so when I received a demo VMware off of a partner, without Explorer installed, it was time to dust off the manual for the runmqsc commands.

To interact with MQ using mqsc, you first need to get into the MQ bin directory in a DOS box, and run the command runmqsc.exe

So for instance:

cd C:\Program Files\IBM\MQ\bin
runmqsc.exe

Upon running this, you’ll be into the MQ Series command environment. If you type ? you’ll get a list of available commands that are over and above this post.

What I needed to do was look for the listener port details, without knowing if a listener existed. It turns out the way to do this is to type:

DISPLAY LISTENER(*) ALL

which should then give you a detailed listing of all MQ Listeners running on your Queue Manager.

Today I’ve mostly been making a few modifications to WebSphere Commerce, in particular, adding some new business logic into the Madisons 2 starter store as part of a demo.

This is generally fairly easy to do, as long as you follow the tutorial in the WCS Info Centre here.

Sooo, I’d got all the way through to setting the access control policy on the new command, and was merrily in my DOS box, about to run the acpload command on my XML file. However, upon running this command I ended up with the following in the acpload.log:

Running XMLTransform... 
Running Id Resolver... 
java.util.MissingResourceException: Can't find bundle for base name Trace, locale en_US
    at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:825)
    at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:794)
    at java.util.ResourceBundle.getBundle(ResourceBundle.java:532)
    at com.ibm.wca.IdResGen.Logging.Logger.run(Logger.java:144)

Not avery helpful error message I’m sure you’ll agree… And Google hadn’t a clue either on this one with regards to WebSphere Commerce.

I quickly managed to track down the source of this. When examining the acpload command I had entered I noticed that I had put in the wrong password for the database user. A quick change of the password, and re-run of the command and everything executed perfectly!

Shame about the cryptic error message!

One of the current VMware images I’m working on contains WebSphere Business Services Fabric, where I’ve been encountering the curse of the db2syscs.exe running at 100% as I’ve blogged about a few times. As I’ve mentioned in my other post, upgrading to Fix Pack 3 in DB2 9.5 seems like a good option, so I decided to apply it.

First thing to do was take a quick VMware snapshot, and then off I toddled. The upgraded was fairly seamless for DB2, but upon re-starting WebSphere Process Server I was seeing lots of errors with XAER_RMFAIL errors in the logs. The errors related both to the DB2 connection and also seemingly to the JMS Managed Connection.

A quick Google search and then dig about in the WAS admin console made me suspect that the DB2 drivers could perhaps be the culprit, with the WebSphere Variables for the DB2 drivers pointing to a directory under WPS, rather than in DB2 (my exact path was D:\WPS\universalDriver.wpbs\lib). Sure enough when searching this directory, I found 3 jar files; db2jcc.jar, db2jcc_license_cisuz.jar and db2jcc_license_cu.jar.

Somewhat guessing, I stopped all WID / WPS / WAS processes, backed up these jar files and then copied into this directory the new jar files from DB2 (in my install, this path was D:\DB2\java). I didn’t have the db2jcc_license_cisuz.jar but you needn’t worry about this file normally, it’s the license file for using DB2 on z/OS or iSeries I believe after reading this link.

A re-start and test later, and everything seems to be working ok so far….

So this problem is still raising it’s ugly head from time to time, and I encountered it again today, this time running a Windows 2003 Server image in VMware.

It seems the common thread to this problem (for me anyway) is Windows and VMware, and after a quick google search I found my blog posting was the no.1 listing on Google… No help there then!

So I headed over to the IBM DB2 support page and searched with the terms “VMware CPU” and came up with this little nugget :

LI73285: IN A WINDOWS AND VMWARE ENVIRONMENT USING DB2 V9.5,DATABASE CONNECTIONS OR SQL QUERIES MAY APPEAR TO HANG OR TAKE A LONG TIME

The text of the problem certainly makes sense, so I’m going to apply FixPack 3 to each of the machines that has been exhibiting the problems and see if it makes a difference.

So I’m installing WebSphere Community Edition (WAS CE) and DB2 Express-C today for the first time to try out IBM’s ‘free’ runtimes. You can download both of these tools from IBM developerWorks Kickstart page.

First thing I’ve come across after installing WAS CE is that it has a default username and password set. After a quick search I’ve found that these are username: system and password: manager. Completly different to the grown up WebSphere users / password but I guess that reflects it’s different code base…

ok, so I ran into this problem once again today….

this time, I had a chat with a different colleague, who is a bit of a guru around WebSphere Performance tuning. Using the DB2 Command Line Processor (db2clp from a DOS prompt) I first connected to the offending database, and then executed the following command:

db2 reorgchk update statistics

I then re-started DB2, and the application that had previously taken 10 minutes trying to start, took 10 seconds!!

Note: I’ve now posted an update to this here

I’ve know for a while that I was going to have to re-size one of the linux VMware’s I run a demo on. It’s that sinking feeling, as you slowly start to see it fill up and run out of space, until that day that something doesn’t start and you find out your at 100% disk use!

I’ve resized VMware disks under Windows before, and found the experience pretty simply, especially having access to a copy of PowerQuest Boot Magic. However, I was thinking Linux might be a bit trickier.

That said, I came across this blog post today, which is very easy to follow and has fixed my problem without having to break a sweat! Nice one beerpla.net!!