Lessons learnt

I hit a few challenges yesterday which I thought I'd share: -

• Make sure you have sufficient memory before loading a WebSphere Portal Express v6 fixpack - I was trying to apply 6.0.1.2 to a Red Hat VMware image, but it was failing with a fairly meaningless message - after a bit of thought, I realized that I'd only allocated 1.5 GB to the VM, which wasn't enough - once I increased that to 2 GB, all was well.
  
  
• On a related note, ensure that you remember to start DB2 UDB before you (a) attempt to start Portal or (b) apply the fixpack ( which will attempt to start Portal ). Again, this bit me yesterday - but I was able to recover without any major pain.
  
  Caveat: I'm using DB2 UDB as my underlying RDBMS because I'm using WebSphere Portal Express - DB2 is an automatic installation/configuration task. However, the point remains true whether you're using another RDBMS e.g. Cloudscape, SQL Server, Oracle as the DB needs to be started.
  
  
• Many WebSphere tasks require you to run the setupCmdLine script. This sets a number of WebSphere-related environment variables, path statements etc. I couldn't work out why this wasn't working in my Red Hat environment - after much faffing about, I realized that I was executing the wrong script; I was executing it from /opt/WebSphere/AppServer/bin rather than /opt/WebSphere/AppServer/profiles/wp_profile/bin.
  
  There was a clue; the setupCmdLine.sh script in the former path didn't have the X bit set so it wasn't an executable script; the one in the latter path did.
  
  On my Windows installations, the profiles directory is normally in a separate directory tree e.g. e:\ibm\WebSphere\profiles\wp_profile whereas, on Unix, it's in a more consistent location.
  
  Bear in mind that I'm currently using v6.0 - in v6.1, there's even more consistency.

Hope this helps someone somewhere. Now if I can only remember this stuff ...........