i would suggest you do this step by step on a test server first and then move to the production setup, and while doing the test instances watch for methods/steps that allow you to back out and return to the original install with certainty. That sinking feeling when things don’t quite work and when you don’t have a route back is not something I want to experience (again).

Thanks a lot for detailed step by step instructions along with test steps.

I have successfully installed 1.6.3 on my server as first step. My goal is to upgrade the 1.4.5 that I have on my server to 1.6.3.

I read it on http://subversion.tigris.org/svn_1.6_releasenotes.html. It states that “To upgrade an existing installation, just install the newest libraries and binaries on top of the older ones.”

Could you please let me know whether it means that I need to copy the latest apr, apr-util etc libs and binaries along with the ones of SVN 1.6.3 over 1.4.5?

If so, to what all dirs?

Thanks,

Stuart

Thanks for the information.

Compliments

How about this for checking queue depth…


# Isolate the CURDEPTH element to a line, then strip the attribute so Perl gets only the value
my $curdepth = `echo "display queue ('${QUEUE}')" | $MQSC $QMGRNAME | tr ')' '\n' | tr ' ' '\n' | grep CURDEPTH | tr '(' '\n' | grep -v CURDEPTH`;



if ($curdepth == '0') {
# Look for literal '0'
} elsif ($curdepth > 0) {
# Check against $WARN and $CRIT
} else {
# runmqsc command failed. QMgr down?
}


Note that I added the QMgr name to the runmqsc command to handle cases where the QMgr is not set as the default or there is more than one. I also added logic to catch the case where WMQ is down.

In the case of process monitoring, amqzmuc0 is the log formatter and I don’t think it runs in all cases. A better choice might be amqzxma0 which is the execution controller.

– T.Rob