Thanks very much to all who have responded thus far (Ruzi, Richard and Neil),
A few other things to add for anyone who is following this....
- I had done as Neil suggested, and run things without the exit, and in this case the size of the MSTR does NOT grow. So I know for sure it s caused by the exit .specifically the MQPUT or MQPUT1.
- I also have tried to just let things be after processing is complete and the MSTR storage increases .just to see if after x period the storage is released by the MSTR .but it does not .well not in 12+ hours.
- After pushing the messages (1000 in each direction) through the SDR and the RCVR, I then go and clear all the messages of the queues. Just wanted to see if this had any bearing, and once again nothing, the MSTR sits with that storage.
- Also tried to manually stop / restart the channels, this also had no bearing on things.
- The default persistence of the queue s is N .
- You guys (Ruzi and Neil) are both correct, but in different cases, about the commit processing. In my case, I cannot use MQCMIT. This is an exert from the Intercommunication Guide :
" All MQI calls except MQCMIT/CSQBCMT and MQBACK/CSQBBAK are allowed. They must be contained after MQCONN (with a blank queue manager name). If these calls are used, the exit must be link-edited with the stub CSQXSTUB. The exception to this rule is that security channel exits may issue commit and backout MQI calls. To do this, code the verbs CSQXCMT and CSQXBAK in place of MQCMIT/CSQBCMT and MQBACK/CSQBBAK."
Thanks very much .Dax.
_________________________________________________________________ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
