The postings on this site solely reflect the personal views of each author and do not necessarily represent the views, positions, strategies or opinions of IBM or IBM management. IBM reserves the right to remove content deemed inappropriate.

It also led to some really interesting observations. In the WMQ07 Wildfire workshop environment, where I normally work, we have limited coupling facility resources, and have to be cautious about making changes because the next workshop is generally only a week or two away. The folks at IBM Redbooks that provided the lab environment for the residency said that we could define several structures and alter them at will!!!! I could test different combinations without fear. It was wonderful.

It also led to some really interesting observations. Including what can happen during capacity tests, and ultimately in a production environment, when there are multiple demands on the system.

In our process we ran the same tests many times to allow the automatic resizing of the coupling facility structures and expansion of the datasets. The first few tests series showed the expected results. These tests were repeatable and I was happy. The next week I started capturing the test results for the publication and, of course, things were not behaving.

After some frantic investigation, the answer became obvious – another residency had started using some of the same resource pools. That team’s DB2 structures were also defined using ALLOWAUTOALT(YES). When they were testing they were grabbing MY storage, and when I was testing I was only using what was fair. Well that is my opinion...

We actually kept those results in the book IBM WebSphere MQ V7.1 and V7.5 Features and Enhancements. It adds to the complete picture of the interaction between subsystems and applications that can change expected (and tested!) behavior. Something else to keep in mind for production.