Author |
Message
|
PeterPotkay |
Posted: Mon Nov 09, 2015 5:20 am Post subject: How do you know if dmpmqcfg produces a complete backup file? |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
We are looking to add some logic in our script that calls dmpmqcfg to backup our MQ Queue Manager Object Definitions.
What to check for in an automated script to confirm the output of dmpmqcfg is 100% complete?
Right now all I can think of is to check if the file was produced, and that its bytes are > 0. But there is no end of file marker to check for, and nothing in the header like a checksum to check for.
What do you guys do? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Nov 09, 2015 5:45 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
wc -l _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Nov 09, 2015 5:54 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
OK, and compare it to what to know that it worked 100%? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Nov 09, 2015 6:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
PeterPotkay wrote: |
OK, and compare it to what to know that it worked 100%? |
The script or scripts you keep in change control to create and manage your MQ objects... ? _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Nov 09, 2015 6:51 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
mqjeff wrote: |
PeterPotkay wrote: |
OK, and compare it to what to know that it worked 100%? |
The script or scripts you keep in change control to create and manage your MQ objects... ? |
The dmpmqcfg output that you took when the queue manager was created.... (probably manually) and put into source control.
It is also a good idea to update the generated file whenever changes are applied. Sort of completing the loop. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Nov 09, 2015 6:52 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
PeterPotkay wrote: |
OK, and compare it to what to know that it worked 100%? |
UNIX diff
Presuming you have the dmpmqcfg output (file) from a well-configured qmgr as a template, use diff to compare that one with a more current output. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
tczielke |
Posted: Mon Nov 09, 2015 7:20 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
For Unix scripts, I would think something like this should be sufficient. That would confirm that the dmpmqcfg completed and returned a successful return code.
Code: |
dmpmqcfg -m qmgr -a > file.txt
if [ $? != 0 ];then
# do error reporting here
fi |
_________________ Working with MQ since 2010. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Nov 09, 2015 7:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
tczielke wrote: |
For Unix scripts, I would think something like this should be sufficient. That would confirm that the dmpmqcfg completed and returned a successful return code. |
That guarantees the validity of the execution, but not of the data.
You can't validate the output of dmpmqcfg without having some definition of what it *should* be. This requires prior knowledge of what was set, or what should have been set. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
tczielke |
Posted: Mon Nov 09, 2015 7:29 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
In my mind that is good enough. The dmpmqcfg program was executed and it reported that it completed successfully when it explicitly set the return code to 0. If dmpmqcfg encountered any errors, it should be ruturning a non-zero return code. However, if people want to also try and validate the data that was created, that wouldn't hurt. To me, it is just not necessary. _________________ Working with MQ since 2010. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Nov 09, 2015 7:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Well, I agree that testing the success of dmpmqcfg is sufficient.
But it's hard to open a PMR for mangled data if you can't demonstrate it. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Nov 09, 2015 8:10 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
When I execute dmpmqcfg, I want to know it worked correctly, and gave me a 100% accurate picture of what the queue manager looks like at that time. Whether the QM is correctly configured to begin with is a separate problem, and important problem, but not one I am trying to tackle here at this point in time. I have to walk before I can run with this script.
All I want to know at this stage of the game is that in the middle of the night my script executed dmpmqcfg, and the results of that execution accurately reflect what the QM looks like. In other words, the output of dmpmqcfg is complete and accurate.
When you run dmpmqcfg manually, how do you know it worked? I spot check a couple of objects manually if I run it manually, but that can't be scripted, not that that is a way to know for sure it worked anyway. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Nov 09, 2015 8:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You can't know that the information you get back is correct simply by examining the return code.
You have to have something to compare it with.
There's no way to tell that the MAXMSGL is correct for a specific queue without knowing what it should be.
This has to be a known good configuration, that is up to date with the latest changes that should have been made to the queue manager.
You could use something to extract and transform configuration events into MQSC and compare that.
But that's much more of a PITA than keeping your mqsc scripts in change control and using those to validate your current config. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Nov 09, 2015 8:43 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
PeterPotkay wrote: |
All I want to know at this stage of the game is that in the middle of the night my script executed dmpmqcfg, and the results of that execution accurately reflect what the QM looks like. In other words, the output of dmpmqcfg is complete and accurate. |
Have faith.
As with any application from any vendor, we take the author's word that it performs to the published specification. Further, we have with IBM an opportunity to raise PMRs when we believe that the app is not performing to spec. IBM has been good at fixing the app when errors are brought to their attention.
As for RC=0: it's just a value exported into the shell to notify anyone/anything that might be interested what the app believes the outcome was. RC=0, in other words, is not a guarantee that the app was successful for your usage.
I'd be a bit happier for audit purposes if dmpmqcfg was more chatty at eoj - including counts of things it produced by category, type of object, whatever. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Nov 09, 2015 8:57 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
bruce2359 wrote: |
I'd be a bit happier for audit purposes if dmpmqcfg was more chatty at eoj - including counts of things it produced by category, type of object, whatever. |
This.
Simply having something in the output that told us this is the end of the file would be better than what we have now. When I look at the last object in the output of dmpmqcfg today, I have to assume that is the last object the queue manager wanted to tell me about. It sort of just ends without any fanfare.
I'm running dmpmqcfg in client mode, so I'm particularly interested in knowing that all the output in that file is in fact all the output ejected by the queue manager for that invocation of dmpmqcfg. And not that maybe there are some messages in the reply queue for some additional objects the QM wanted to tell the dmpmqcfg client about, but that never got consumed because the client connection broke before the client dmpmqcfg consumed all the messages.
Or maybe the QM produces all its backup data in a single reply message, and its an all or nothing deal. Even then, would be good to see an EOF entry. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Nov 09, 2015 8:57 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
bruce2359 wrote: |
I'd be a bit happier for audit purposes if dmpmqcfg was more chatty at eoj - including counts of things it produced by category, type of object, whatever. |
RFE time perhaps?
Perhaps even a summary mode which just did that?
It would be nice if the output of subscriptions could be piped straight back into a QMGR without editing the topic string and making it ''. Currently (8.0.0.2) it gets appended to the actual topic string when being used to build a QMGR. I understand the reasons for doing it as it is but it is a bit of a faff to have to edit every subscription.
If we are going to go to town a bit then how about having a template/model so that you could just extract the bits of the config for each type that you wanted. If you are not running in a Cluster then you aren't interested in any of the cluster params
Just a thought.(wishful thinking more like) _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
|