| Author |
Message
|
| serpota |
 Posted: Wed Mar 25, 2015 10:50 pm Post subject: dmpmqcfg without system objects |
 |
|
Voyager
Joined: 26 May 2006
Posts: 85
|
In good old "saveqmgr" we had "-s" flag to supress listing of object that begin with "SYSTEM", in fact removing system objects from output.
I am trying to do the same with "dmpmqcfg", but I am not able to find a similar flag.
Am I blind or there has been an improvement that I dont understand ?
If so, can you explain me the reason for such change ?
Thanks you. |
|
| Back to top |
|
 |
| umatharani |
| Posted: Sat Mar 28, 2015 3:10 am Post subject: |
|
|
Apprentice
Joined: 23 Oct 2008
Posts: 39
|
Hi,
I agree with your concern. However the saveqmgr is supportpac and dmpmqcfg is tool is shipped with the product itself. I think options on the product is chosen based on the requirements. I suggest raising a MQ requirement.
Thanks,
mahesh |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Mar 28, 2015 3:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Surely the implied requirement was to provide the same function as "saveqmgr"?
In fact -why didn't they just take the same source code and rename it?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Mar 28, 2015 1:10 pm Post subject: Re: dmpmqcfg without system objects |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| serpota wrote: |
In good old "saveqmgr" we had "-s" flag to supress listing of object that begin with "SYSTEM", in fact removing system objects from output.
I am trying to do the same with "dmpmqcfg", but I am not able to find a similar flag.
Am I blind or there has been an improvement that I dont understand ?
If so, can you explain me the reason for such change ?
Thanks you. |
Just my 2 cents... I believe you have no more "no system output" flag because on the general (all) you now also get authority records and channel authority records. Would you care to miss those in your output because they start with SYSTEM. ? I don't think so....
Raise an RFE ... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Mar 28, 2015 2:41 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Some admins have modified SYSTEM. channels to include MCAUSER(NOACCESS) (or some such equivalent) to ensure that new channels don't get access by default.
_________________
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 |
|
|
| gbaddeley |
| Posted: Sun Mar 29, 2015 10:08 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
SYSTEM.DEFAULT objects may also have site modifications to preset customer standards (eg. maxmsgl, maxdepth), so their definitions should be saved in backups.
_________________
Glenn |
|
| Back to top |
|
|
| serpota |
| Posted: Sun Mar 29, 2015 11:44 pm Post subject: |
|
|
Voyager
Joined: 26 May 2006
Posts: 85
|
I know the SYSTEM objects have to be saved (sometimes) as they may be modified.
Of course I can write some shell or Rexx to remove them.
But the flag was there, so some utility was suposed
But I am talking about the ability to have them or to have them not.
Ok, I asked for a reason for such improvement.
Thanks. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Mar 30, 2015 2:51 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| zpat wrote: |
| In fact -why didn't they just take the same source code and rename it? |
There are probably a number of reasons for this, I'm sure I haven't got all of them here, but here are a few I remember:-- The saveqmgr source was written using external interfaces and required an update every new release to capture all new object types and changes. By hooking it into internal code which was updated for new object types and attributes, we don't have to make a special extra effort to update it too, it happens automatically.
- This was the one chance to have a blank slate. saveqmgr had been around for a long time and some of it's flags were really no longer needed. So we took a base set of function and will update based on raised RFEs as required. if we'd taken everything, we'd have had no chance to get rid of stuff that really wasn't needed anymore.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 30, 2015 5:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
All of that said, and despite my interests in making it much easier to update all external tools when something changes...
dmpmqcfg does have the oneline and twoline options, so you can use those with a grep -v to generate the output you want that doesn't have SYSTEM objects. |
|
| Back to top |
|
|
| serpota |
| Posted: Mon Mar 30, 2015 7:01 am Post subject: |
|
|
Voyager
Joined: 26 May 2006
Posts: 85
|
I have to agree I have not looked into those two flags until now, must I say "unappropiatelly", jejeje. Thanks, Jeff.
Again, I am using Rexx to filter objects I dont want, and some other more complicated things.
TJ Robb teached me to compare today's "saveqmgr" output with yesterday's, to verify no changes have been introduced.
Maybe now I have to adapt my tools (here, Rexx code) to "dmpmqcfg", yes. |
|
| Back to top |
|
|
| serpota |
| Posted: Mon Mar 30, 2015 7:06 am Post subject: |
|
|
Voyager
Joined: 26 May 2006
Posts: 85
|
Mrs Hughson - saying "something is not needed anymore" sounds to me quite prepotent, dont you agree ? How do you know it is not needed ?
I am in the field, where problems arise, customers complain, nerves are on the phone.
I need to migrate or update a configuration and your tool provides me hundreds of lines I dont need.
So, I have to remove them by hand. 10 Minutes per file, maybe more. Maybe some mistake introduces more delay. Now repeat it for 5 queue managers, 11 pm in the night.
Thanks you so much to tell me the flag I used so many times is "not needed anymore". |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Mar 30, 2015 7:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| serpota wrote: |
I need to migrate or update a configuration and your tool provides me hundreds of lines I dont need.
|
Don't you have access to the scripts that created the QMGR in the first place?
Lets try to turn your post on its head.
Part of the job I do is to keep my scripts uptodate so that in the even of disaster I can recreate the QMGR from first principles in a matter of minutes.
Dumping the QMGR objects with dmpmqcfg (in 1 line mode) and comparing the output with the output from a test QMGR is all part of keeping track of any changes in the QMGR and keeping the scripts accurate.
The presence of the scripts (which are human readable) also means I can easily build an identical QMGR to that running at the customers for support work.
Work proactively not reactively. The stress levels are considerably lower IMHO.
finally, there is nothing to stop you from writing your own version of dmpmqcfg/saveqmgr that dumps only the objects that you want and in the format that you want. PCF is there for just this purpose.
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Mar 30, 2015 7:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| Dumping the QMGR objects with dmpmqcfg (in 1 line mode) and comparing the output with the output from a test QMGR is all part of keeping track of any changes in the QMGR and keeping the scripts accurate. |
Tracking changes is then a matter of either using something as simple as diff, or even just the normal change detection processes of your version control system.
And reformatting the one line output into a more human readable is pretty easy, too. Just add \n\t after every )... |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 30, 2015 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| serpota wrote: |
| Thanks you so much to tell me the flag I used so many times is "not needed anymore". |
Probably not a wise choice to base such needed functionality on a support pac then.
| serpota wrote: |
| So, I have to remove them by hand. |
Or with REXX. Or some other utility. Also if you're firmly wedded to the "reverse engineering" method of generating script rather than the other method suggested of building from script (which I personally favour) then I would absolutely have generated my own utility to do this rather than relying on a support pac.
Even if the support pac in question was feature rich and maintained by experts. It's still only a support pac and something like this could have happened to that even if it hadn't been moved into the base product.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 30, 2015 9:16 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
serpota,
I don't know what all the fuss is about, just follow Jeff's and Vitor's comments.
Many years ago, I implemented your solution at various customer sites. All you need to do is substitute MS03 with dmpmqcfg and install a version control system. At midnight, you run a script to do the following:
- run dmpmqcfg outputting the objects in 1 line
- run a REXX script to exclude 'SYSTEM.' objects
- check the resulting file into the version control system
I had a REXX script that separated the objects by type. i.e. QMGR, QLOCAL, QMODEL, etc.. I used the file name format of {QMgr}.{ObjectType}.mqsc and these files are what was checked into the version control system.
I'm a developer, so I always looked at the MQSC files as code and runmqsc as the run-time compiler.  So, checking the MQSC files into a version control system just made logically sense.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
