ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportHow do you know if dmpmqcfg produces a complete backup file?

Post new topicReply to topic Goto page 1, 2, 3, 4  Next
How do you know if dmpmqcfg produces a complete backup file? View previous topic :: View next topic
Author Message
PeterPotkay
PostPosted: Mon Nov 09, 2015 5:20 am Post subject: How do you know if dmpmqcfg produces a complete backup file? Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7359

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
View user's profile Send private message
smdavies99
PostPosted: Mon Nov 09, 2015 5:45 am Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Mon Nov 09, 2015 5:54 am Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7359

smdavies99 wrote:
wc -l


OK, and compare it to what to know that it worked 100%?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Nov 09, 2015 6:06 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17269

PeterPotkay wrote:
smdavies99 wrote:
wc -l


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... ?
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
smdavies99
PostPosted: Mon Nov 09, 2015 6:51 am Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

mqjeff wrote:
PeterPotkay wrote:
smdavies99 wrote:
wc -l


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
View user's profile Send private message
bruce2359
PostPosted: Mon Nov 09, 2015 6:52 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7784
Location: US: west coast, almost. Otherwise, enroute.

PeterPotkay wrote:
smdavies99 wrote:
wc -l


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 didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
tczielke
PostPosted: Mon Nov 09, 2015 7:20 am Post subject: Reply with quote

Yatiri

Joined: 08 Jul 2010
Posts: 626
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

_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Nov 09, 2015 7:22 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17269

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.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
tczielke
PostPosted: Mon Nov 09, 2015 7:29 am Post subject: Reply with quote

Yatiri

Joined: 08 Jul 2010
Posts: 626
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.
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Nov 09, 2015 7:33 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17269

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.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Nov 09, 2015 8:10 am Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7359

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
View user's profile Send private message
mqjeff
PostPosted: Mon Nov 09, 2015 8:14 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17269

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.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Nov 09, 2015 8:43 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7784
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 didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Nov 09, 2015 8:57 am Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7359

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
View user's profile Send private message
smdavies99
PostPosted: Mon Nov 09, 2015 8:57 am Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2, 3, 4  Next Page 1 of 4

MQSeries.net Forum IndexGeneral IBM MQ SupportHow do you know if dmpmqcfg produces a complete backup file?
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.