Correct me if I am wrong, but does the Record Image (rcdmqimg) not force a check Point?
Emile Kearns -----Original Message----- From: [EMAIL PROTECTED] [mailto:philip.distefano@;JPMCHASE.COM] Sent: 02 November 2002 12:21 To: [EMAIL PROTECTED] Subject: Re: Relation of currdepth to disk space The max uncommitted messages parameter has to do with the maximum number of uncommitted messages within a unit of work that an application can have before it must issue an MQCMIT. [EMAIL PROTECTED] To: [EMAIL PROTECTED] M cc: Sent by: Subject: Re: Relation of currdepth to disk space MQSERIES@akh-wie n.ac.at 11/01/2002 03:09 PM Please respond to MQSERIES I don't believe this would have the affect that I'm interested in, though I admit I might be mistaken in my beliefs. The changing of the value for max uncommitted messages will affect the size/number necessary for log space, but, I don't know that it would affect the checkpoint processing. Per Paul's note regarding when queue space is cleaned up, it basically takes two checkpoint's after a queue has been emptied to clean up the space on disk. What I'm interested in doing is forcing those checkpoints to come more frequently than the default of 10,000 (per the documentation) operations between checkpoints. I don't know that max uncommitted would have any affect on that processing. I was hoping for an entry in say the qm.ini file that would tell MQ to take these checkpoints more frequently, say every 1,000 operations. Obviously there would be a performance affect by lowering this number too far, but, I'm more interested in disk space at this time. -- Tim -----Original Message----- From: Evelyn Millions [mailto:evelyn@;MILLIONS.CA] Sent: Friday, November 01, 2002 9:39 AM To: [EMAIL PROTECTED] Subject: Re: Relation of currdepth to disk space Or for an existing qmgr use runmqsc and alter the qmgr. alter qmgr maxumsgs(2000) - Evelyn Hornby, Derek wrote: > ... well one way is to use the parameter > -x nnnnn > as part of the crtmqm command > > -----Original Message----- > From: Halbur, Tim [mailto:HALBURT@;APTEA.COM] > Sent: Friday, November 01, 2002 8:22 AM > To: [EMAIL PROTECTED] > Subject: Re: Relation of currdepth to disk space > > Is there a way to force MQ on the distributed platform to take a checkpoint > rather than waiting for 10,000 operations to occur, which is when > checkpoints are normally taken? Or, can this value be tuned to a lower > number than 10,000? > > Thanks - > > Tim > > -----Original Message----- > > 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 -- Evelyn Millions Millions Consulting Limited office (403) 686-4840 fax (403) 686-4854 [EMAIL PROTECTED] "I wish I could be as sure of anything as some people are of everything." 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 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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 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