MQSeries.net :: View topic

hugh-delacy · Posted: Fri May 28, 2004 5:40 am Post subject:

I stumbled across this one by chance and thought i should relate our experiences.

Its seems that now there are two issues when considering the upgrade process from MQSI 2.1 to WBI 5.0

1) Development platform

2) reliability/inherent stability/recovery

There is no doubt that the new eclipse interface is a much better development tool than the old one. But in many respects this goes against the grain of what MQSI was supposed to be all about. MQSI is and was exciting and revolutionary because it supplied 'primitives' that were suppossed to do away with the need for large amounts of coding.

Now i dread newcomers overlooking the functionality of certain primitives and thinking they have to write large amounts of esql.

For example . We recently took on 3 new developers. The interview process involved building a simple workflow with some functionality as required by the test. The task could be completed simply by linking 3 primitives together (Using their functions) and doing one simple line of esql code within a compute node. Of the 20 whom took the test, only the 3 we took on used the simple method of passing this test and used the 3 primitives. All those candidates whom were now using eclipse starting writing loads of esql and completely overlooking the most obvious way of achieving the task. Using the 3 'primitives' ... When shown the correct answer they were quite shocked and realised they had started to develop 'blinkers' and were looking at mqsi in a to narrow and focused way.

Thus it was decided to take on only the candidate.s whom made strong use of the primitives. Also in future we will try and take on staff whom have mainly developed with the MQSI platform rather than the exclipse platform.

2) reliability/inherent stability/recovery

I work for one of the main Suisse Banks. We were one of the first reference sites for MQSI. and experienced many problems. We actually were the ones to reject the product as "not production ready" Which i see someone else has already commented upon.
IBM came back to us 6 months later with a much more reliable product and we have been very satisfied with MQSI for two years now. We rarely if ever have any problems and were happy to stick with MQSI 2.1

Under pressure from IBM we have implemented the new wbi5 eclipse version in out test environment. It has been a total disaster with many workflows not working. Also despite IBM saying they would, many off our third party adapters do not work with this product. i.e we have a connector which takes the mq message and passes it to sap. IBM have now informed us will would have to buy there crossworlds connector (Oh how conveniant for them).

But this is not our main disapointment. Our environment makes much use of items such as Neon links and R3 link and various adaptors. Also CICS. We have various platforms including NT/AIX/AS400/zOS(MVS)

In our environment a message can be in many different areas at once undergoing many different process,s such as transformation. Keeping things reliable and in sync is very important to us. We achieved this important stability when the queue managers in use with MQSI did indeed become 'repository' queue managers as one of the previous commenters pointed out

We learnt that the config manager was not going to be a repostory queue manger and knowing the difference this made between the earliest releases of MQSI we were worried. Heavy testing and stress testing has shown that if we implement this in production we would be bringing back all the old problems we faced in 2001. Such as sequence problems /loss of data etc. We too have opened a pmr with IBM and have requested a discussion with MQSI development labs at Hursley in order to voice our fears and concerns.

Thus too conclude, we will stick with MQSI v2.1

Hope this helps