Definitely. I must have misunderstood the issue (as I did not read the whole thing carefully). Thanks for correcting, David...
Ruzi --- "David C. Partridge" <[EMAIL PROTECTED]> wrote: > I beg to differ! > > A commit takes place under the scope of a connection > handle. When a channel > exit connects to the queue manager, it will get back > an HCONN, but the > reason code will be MQRC_ALREADY_CONNECTED and the > HCONN it gets is the same > one the MCA is using, so any commits issues by the > exit *will* interfere > with the commits issued by the MCA. > > David > -----Original Message----- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Ruzi R > Sent: 03 September 2003 12:15 > To: [EMAIL PROTECTED] > Subject: Re: MVS msg exit (MQPUT) processing causes > increase in MSTR > region size. > > > > be careful with the suggestion from Ruzi. > > > > The message exit runs inside the unit of work for > > the MCA. If you commit, > > then you are committing the channel's work as > well. > > Not true. The application's commit is separate from > Channel's commit. Channel's commit depends on > BATCHSZ/BATCHINT attributes. > > Ruzi > > --- Neil Casey <[EMAIL PROTECTED]> wrote: > > Hi Dax (are you a DS9 fan?) > > > > be careful with the suggestion from Ruzi. > > > > The message exit runs inside the unit of work for > > the MCA. If you commit, > > then you are committing the channel's work as > well. > > > > You shouldn't have to worry about not committing > in > > your exit as the MCA > > will issue a commit for every batch. > > > > I have no idea why your real storage usage is > rising > > only when your exit is > > run, but to test it out, try running your programs > > without any exits, and > > at the same time run a local program which inserts > > the same message load as > > the exit would do. Look at the memory usage after > > this test and compare > > with running your exit to determine if your exit > is > > behaving badly. I would > > also suggest checking the virtual usage as well as > > real. If the virtual > > usage is unchanged, then what you are seeing is > not > > a leek, but a change in > > the working set in an unconstrained system. This > > would represent normal > > behaviour. Your system is clearly unconstrained > > because your paging rate is > > 0. > > > > Regards, > > > > Neil Casey. > > > > > > |---------+----------------------------> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | n.AC.AT> | > > | | | > > | | | > > | | 03/09/2003 02:29 | > > | | Please respond to| > > | | MQSeries List | > > | | | > > |---------+----------------------------> > > > > > >--------------------------------------------------------------------------- > -----------------------------------| > > | > > > > | > > | To: [EMAIL PROTECTED] > > > > | > > | cc: > > > > | > > | Subject: Re: MVS msg exit (MQPUT) > > processing causes increase in MSTR > > region | > > | size. > > > > | > > > > > >--------------------------------------------------------------------------- > -----------------------------------| > > > > > > > > > > The first thing that came to my mind (without > > reading > > all the deatils carefully-- not that I could > > understand the code all that much) is that, it > might > > be caused by a delayed "commit"??? From your code, > I > > think you are using the default MQPMO. On the > > mainframe the Syncpoint is the default ( > > Syncpoint=yes). Looks like you are not commiting > > each > > message after each PUT (or after so many > messages). > > When you diconnect without the explicit commit, an > > implicit commit occurs committing all the 1000 > > messages. In the meantime, the 1000 messages > > (depending on on their size probably) may be > causing > > the space to expand. Since you are experimenting, > I > > suggest you try using a commit after every (or say > > 10 > > messages) and see whether you get the some > problem. > > > > I don"t know if the above is causing your problem, > > but > > I thought I would share my opinion with you > anyway. > > > > Best regards, > > > > Ruzi > > > > --- d a <[EMAIL PROTECTED]> wrote: > > > To the MVS people on the list.... > > > > > > I have been playing around with the following > > > message exit code it all > > > works fine BUT, I have just noticed that the > MSTR > > > address spaces for the 2 > > > queue mgrs I am testing on expands considerably > > not > > > a good thing !!!! > > > > > > Here is the setup, I have 2 queue mgrs QMG1 and > > > QMG2, and a set of SDR/RCVR > > > channels between them, all with the exit defined > > as > > > a message exit on them. > > > I then send through 1000 messages in both > > directions > > > to drive the exit > > > defined on the RCVR and SDR channels. > > > > > > The result Note the Real storage frames: > > > > > > Before processing: > > > ----------------- > > > JOBNAME ,StepName,ProcStep,JobID ,Owner > > > ,C,Pos,DP,Real,Paging, SIO > > > QMG1MSTR QMG1MSTR PROCSTEP STC05201 QMG1MSTR > NS > > > FE 8084 0.00 0.00 > > > QMG1CHIN QMG1CHIN PROCSTEP STC05203 QMG1CHIN > IN > > > FB 2897 0.00 0.00 > > > > > > JOBNAME ,StepName,ProcStep,JobID ,Owner > > > ,C,Pos,DP,Real,Paging, SIO > > > QMG2MSTR QMG2MSTR PROCSTEP STC05202 QMG2MSTR > NS > > > FE 8056 0.00 0.00 > > > QMG2CHIN QMG2CHIN PROCSTEP STC05204 QMG2CHIN > IN > > > FB 2970 0.00 0.00 > > > > > > > > > After processing: > === message truncated === 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
