Re: Relation of currdepth to disk space
So I guess this means that you still have to bounce the QMGR before cleaning
up the logs because the message for reductiopn of the log files will not
show the true status of the logs after the rcdmqimg???
bb
From: Rick Tsujimoto <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Relation of currdepth to disk space
Date: Mon, 4 Nov 2002 09:15:40 -0500
Emile,
rcdmqimg has nothing to do with checkpoints.
Here's an exchange I saved on this topic:
To: Richard Tsujimoto/CHASE@CHASE
cc:
From: [EMAIL PROTECTED]
Date: 08/09/99 08:04:10 PM GMT
Subject:Re: pmr 25681,999 ATTN: TJ
I am sorry.
I checked and the answer to question two is NO.
Thanks,
T. J.
[EMAIL PROTECTED] on 08/09/99 11:51:52 AM
To: TJ Elkanick/Raleigh/IBM@IBMUS
cc:
Subject: Re: pmr 25681,999 ATTN: TJ
TJ,
Level 2 only answered question 1, but didn't respond to question 2.
[EMAIL PROTECTED] on 08/09/99 10:49:47 AM
To: Richard Tsujimoto/CHASE@CHASE
cc:
Subject: Re: pmr 25681,999 ATTN: TJ
Richard,
Below is response to your question:
*
Rcdmqimg command does not force a checkpoint. So AMQ7468 message does not
get issued as a result of rcdmqimg. It is only issued at the end of a
checkpoint. There is no direct relationship between recording a media
image and taking a checkpoint.
*
Thanks,
T. J.
MQSeries Level 2 Support
[EMAIL PROTECTED]
When sending mail to MQSERIES, please add the Problem Number and the Level
2
rep's name in the Subject line.
Example: PMR# 12345,678 Jane - Trace.Log file info
[EMAIL PROTECTED] on 08/06/99 02:29:27 PM
To: mqseries/Raleigh/IBM@IBMUS
cc:
Subject: pmr 25681,999 ATTN: TJ
I see messages AMQ7467 and AMQ7468 always entered in the AMQERR0x.LOG
together,
at about the same time. Our shop issues rcdmqimg everyday at 6:00am but we
never see AMQ7468 issued when the command completes.
I have two questions:
1. Does AMQ7468 only appear when a checkpoint is done?
2. Does each occurrence of AMQ7468 in the error log reflect the last time
rcdmqimg was issued (which was at 6:00am in our case)?
Thanks.
Emile Kearns
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
UTURES.COM> cc:
Sent by: MQSeries List Subject: Re:
Relation of currdepth to disk space
<[EMAIL PROTECTED]>
11/04/2002 01:45 AM
Please respond to MQSeries
List
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]
Mcc:
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 ex
Re: Relation of currdepth to disk space
Emile, rcdmqimg has nothing to do with checkpoints. Here's an exchange I saved on this topic: To: Richard Tsujimoto/CHASE@CHASE cc: From: [EMAIL PROTECTED] Date: 08/09/99 08:04:10 PM GMT Subject:Re: pmr 25681,999 ATTN: TJ I am sorry. I checked and the answer to question two is NO. Thanks, T. J. [EMAIL PROTECTED] on 08/09/99 11:51:52 AM To: TJ Elkanick/Raleigh/IBM@IBMUS cc: Subject: Re: pmr 25681,999 ATTN: TJ TJ, Level 2 only answered question 1, but didn't respond to question 2. [EMAIL PROTECTED] on 08/09/99 10:49:47 AM To: Richard Tsujimoto/CHASE@CHASE cc: Subject: Re: pmr 25681,999 ATTN: TJ Richard, Below is response to your question: * Rcdmqimg command does not force a checkpoint. So AMQ7468 message does not get issued as a result of rcdmqimg. It is only issued at the end of a checkpoint. There is no direct relationship between recording a media image and taking a checkpoint. * Thanks, T. J. MQSeries Level 2 Support [EMAIL PROTECTED] When sending mail to MQSERIES, please add the Problem Number and the Level 2 rep's name in the Subject line. Example: PMR# 12345,678 Jane - Trace.Log file info [EMAIL PROTECTED] on 08/06/99 02:29:27 PM To: mqseries/Raleigh/IBM@IBMUS cc: Subject: pmr 25681,999 ATTN: TJ I see messages AMQ7467 and AMQ7468 always entered in the AMQERR0x.LOG together, at about the same time. Our shop issues rcdmqimg everyday at 6:00am but we never see AMQ7468 issued when the command completes. I have two questions: 1. Does AMQ7468 only appear when a checkpoint is done? 2. Does each occurrence of AMQ7468 in the error log reflect the last time rcdmqimg was issued (which was at 6:00am in our case)? Thanks. Emile Kearns <[EMAIL PROTECTED] To: [EMAIL PROTECTED] UTURES.COM> cc: Sent by: MQSeries List Subject: Re: Relation of currdepth to disk space <[EMAIL PROTECTED]> 11/04/2002 01:45 AM Please respond to MQSeries List 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] Mcc: 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 n > 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 forc
Re: Relation of currdepth to disk space
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] Mcc: 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 n > 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
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] Mcc: 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 n > 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
Re: Relation of currdepth to disk space
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 n > 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
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 n 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
Re: Relation of currdepth to disk space
... well one way is to use the parameter -x n 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
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- From: Paul Clarke [mailto:paulg_clarke@;UK.IBM.COM] Sent: Thursday, October 31, 2002 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Relation of currdepth to disk space >The space will not get freed up until either a) you delete and redefine the >queue, or b) the QMGR is stopped and restarted. This is not quite true, we do indeed release disk space at these times but these aren't the only times... The others are :- 1) At a checkpoint If checkpoint sees the same queue empty multiple times and the queue is using a significant amount of disk space then the queue is truncated. 2) When the queue is unloaded When a queue isn't open by any application (including internal MQ 'applications' e.g. MCA) then it is scheduled for unload. The queue will be unloaded the second time a checkpoint sees the queue scheduled for unload. 3) When we take a media image of the queue We compact a local queue prior to taking a media image. I imagine the apparent arbitrary nature that was referred to in the earlier append is just the moment when the queue became unused or when a checkpoint was taken. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Rochester,MN 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
Re: Relation of currdepth to disk space
>The space will not get freed up until either a) you delete and redefine the >queue, or b) the QMGR is stopped and restarted. This is not quite true, we do indeed release disk space at these times but these aren't the only times... The others are :- 1) At a checkpoint If checkpoint sees the same queue empty multiple times and the queue is using a significant amount of disk space then the queue is truncated. 2) When the queue is unloaded When a queue isn't open by any application (including internal MQ 'applications' e.g. MCA) then it is scheduled for unload. The queue will be unloaded the second time a checkpoint sees the queue scheduled for unload. 3) When we take a media image of the queue We compact a local queue prior to taking a media image. I imagine the apparent arbitrary nature that was referred to in the earlier append is just the moment when the queue became unused or when a checkpoint was taken. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Rochester,MN 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
Re: Relation of currdepth to disk space
The space will not get freed up until either a) you delete and redefine the queue, or b) the QMGR is stopped and restarte. Windy Senior Technician ISOS TST Middleware Standard Life 120 Dundas Street Edinburgh EH3 5DQ +44(0)131 245 3525 Tel. +44(0)131 245 3510 Fax. For more information on Standard Life, visit our website http://www.standardlife.com/ The Standard Life Assurance Company, Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH, is registered in Scotland (No. SZ4) and regulated by the Financial Services Authority. Tel: 0131 225 2552 - calls may be recorded or monitored. This confidential e-mail is for the addressee only. If received in error, do not retain/copy/disclose it without our consent and please return it to us. We virus scan and monitor all e-mails but are not responsible for any damage caused by a virus or alteration by a third party after it is sent. 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
