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]
                      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

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

_________________________________________________________________
Get faster connections -- switch to MSN Internet Access!
http://resourcecenter.msn.com/access/plans/default.asp

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

Reply via email to