How to get “saveqmgr -s” function using “dmpmqcfg”

Question

I am used to dumping objects from a queue manager without system objects.

But now I have to use dmpmqcfg and I cant find a flag to remove those system objects from output.

MQ version is 7.5.0.1

Command I use now : dmpmqcfg -m SMQ -t all -x object

Possible flags :     c:\>  dmpmqcfg -h

Usage: dmpmqcfg [-m QMgrName] [-n ObjName] [-t ObjType]
               [-x ExportType] [-o Format] [-a] [-z]
               [-s MsgSeqNo] [-q RplQName] [-r RmtQMgrName]
               [-c default|-c DEFINE CHANNEL..]

 -m   Queue manager name.
 -n   Object name or a generic object name.
 -t   Object type:
        all, authinfo, channel, clntconn, comminfo, listener,
        namelist, process, queue, qmgr, service, topic.
 -x   Export type:
        all, object, authrec, chlauth, sub.
 -o   Format: mqsc, 1line, setmqaut, grtmqmaut.
 -a   Dump all attributes.
 -z   Suppress warnings.
 -s   Reset channel message sequence number
 -q   Reply to queue name, default SYSTEM.DEFAULT.MODEL.QUEUE
 -r   Remote queue manager name (queued mode)
 -c   Client connection:
        default, DEFINE CHANNEL(chlname) CHLTYPE(CLNTCONN) ...

Answer 1

The saveqmgr command was a SupportPac that was maintained outside of the MQ Development lab and with close interaction with the MQ User community through MQSeries.net and the Vienna MQ List Server. Though it was for many years the only way to get a full backup of the queue manger's configuration files, it was never a supported component of the product.

The dmpmqcfg command is a fully supported method of backing up the full configuration of the queue manager, maintained out of the MQ Dev lab. It's requirements were developed in close communication with the customers participating in the Early Access Program (effectively MQ's Beta program). Though there is some overlap with saveqmgr it was not intended to be a direct replacement for that program. Specifically, since it is primarily intended to create a complete backup it lacks the ability to omit the SYSTEM.* objects.

You can simulate the same thing by using the -o 1line option and filtering out the SYSTEM.* objects.

Windows:

dmpmqcfg -m [qmgr] -o 1line | findstr /V "('SYSTEM"

UNIX/Linux:

dmpmqcfg -m [qmgr] -o 1line | grep -v "('SYSTEM"

Note that this filters out any line containing ('SYSTEM, even if that string is in a description or other field. If you wanted to be completely sure you got only objects named SYSTEM.* you would need to be more explicit and use multiple filters like so:

dmpmqcfg -m [qmgr] -o 1line | grep -v " CHANNEL('SYSTEM" | grep -v " QLOCAL('SYSTEM" | grep -v " QALIAS('SYSTEM"...

I leave it as an exercise to the reader to add all the possible object types to filter onto the end of that command pipeline.

Note that you do not want to filter out AUTHREC definitions that contain PROFILE('SYSTEM because these are needed to control access to model queues, the command queue, etc.

It is unfortunate that the MQ Dev team does not work as closely with the MQ Community as the SupportPac authors, however there is good reason for this. Note that SupportPacs are not always kept up to date and their maintenance and bug-fix are performed on an as-available basis. While in general the SupportPac authors are very good at keeping up they have no enforced deadline.

Contrast this with the MQ Dev Lab's process for creating a new component like dmpmqcfg. Their use of the Early Access Program (EAP) formalizes the requirements and tracks them to ensure that the component is released on time with the rest of the product, translated into many languages, documented in the manual, etc. The issue isn't so much that the dev lab isn't listening to our requirements as much as it is getting companies to join the EAP, and then once there to dedicate time to testing and providing feedback in a timely manner.

However, as Jon stated, submitting a requirement on a released component is possible through the Request For Enhancement (RFE) process. What Jon's answer left out is that in order to be considered and prioritized, the RFE must either have a really compelling business case, or else receive some votes and/or comments. There are some strategies to help get the RFE passed:

• Don't split votes between RFEs. Before submitting one, search (browse really because the RFE search functionality sucks) for similar ones. If you find one that is close, comment on it to clarify your requirement rather than submitting a new one, and vote it up.
• Discuss your proposal with the communities at the Listserv and/or MQSeries.net. If someone has an RFE that you missed, you'll hear about it here. You will also get an idea of how much support you might get for an RFE, or if the thing you want is an anti-pattern (looks GREAT until you do it, at which point it becomes dangerous in unanticipated ways - for example using DNS names in CHLAUTH records).
• If you do submit an RFE post a note to the Listserv and/or to MQSeries.net to let the community know that you have submitted it and ask them to comment and vote it up.
• If you find an existing RFE or submit your own, update your question or add a comment to it to track progress. Stack Overflow is supposed to evolve over time and if the problem you face is solved, capturing that here will help others. And some of us here on SO will vote for it if we find the link in your follow-up.

Hope that helps. My requirement for dmpmqcfg was always that it duplicated the functionality of saveqmgr, plus a few more things. I'd vote for this.