|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
SAVEQMGR does not save ... API Exit configuration |
« View previous topic :: View next topic » |
Author |
Message
|
sebastia |
Posted: Sun Jan 11, 2009 10:31 am Post subject: SAVEQMGR does not save ... API Exit configuration |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Good evening.
I was very happy playing with an API Exit (mirrorq)
then an idea came to my mind ...
i did run SAVEQMGR and all I found was a Namelist ...
DEFINE NAMELIST ('mirrorq') REPLACE +
DESCR('Define source and target queues for MIRRORQ') +
NAMES('QL2 ', +
'QC2 ', +
'QM2 ')
saying ... "on queue manager QM2, copy to QC2 all messages
that are written into QL2"
But I think this is not enough to re-stablish the queue manager,
in the case we lose the QM2 configuration, and I run
runmqsc QM2 < QM2.MQS
Am I right ? (and I think I am)
How is it possible ??
Sebastian. |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Jan 11, 2009 10:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Saveqmgr does not currently save qm.ini settings, no.
Is that what you're asking about?
It should save every object that is visible through PCF commands, though. |
|
Back to top |
|
 |
sebastia |
Posted: Sun Jan 11, 2009 10:40 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Jeff - I dont know what SaveQmgr saves and what it does not.
I was using this tool to save a queue manager configuration,
just in case the machine went broken,
I would run the RUNMQSC command with that file,
and I expected to have the VERY SAME queue manager running.
Now, it seems to me it is NOT exactly the same queue manager,
whech is quite a surprise to me.
Are you suggesting to save QM.INI in an AIX environment,
plus SAVEQMGR ?
And what about Windows ???
Seb. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sun Jan 11, 2009 1:01 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
MQ saves a lot of a QM's properties outside of what can be set accessed with runmqsc / PCF commands. On Unix these are held in the qm.ini files. On Windows its the registry.
The MS03 Support Pack only saves things it can access via PCF commands, which is the same set of things that runmqsc can set. Meaning that an MS03 file for your QM is a good thing to have to rebuild a QM from scratch, but not enough by itself. You have to have that other info as well.
The output of MS03 is simply a set of runmqsc commands. runmqsc commands can only be submitted to an existing QM. But some things need to set when the QM is built (log file size for example), so a runmqsc command does not apply, therefore MS03 does not apply.
There should be a PCF command / runmqsc command to at least be able to display what all these settings are. It would be nice to have all that info in an MS03 backup file, in a commented out section for reference only. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jan 11, 2009 2:11 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sebastia wrote: |
Are you suggesting to save QM.INI in an AIX environment,
plus SAVEQMGR ?
And what about Windows ???
|
SAVEQMGR is a great tool for recording, preserving and backing up a queue manager. It's never been claimed that it's all you need, and doesn't replace a solid environment document describing your set up (mount points, log sizes and so forth). SAVEQMGR also fails to explain why you have the queues and channels you do.
<plug>Though the output can be converted via a certain software product and incorporated in such a document</plug>
The advantage of a document describing your queue manager set up is it's as platform neutral as the script produced by SAVEQMGR. Much easier when you move from Windows to Unix (Windows registry backups tend to migrate poorly!) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sun Jan 11, 2009 2:35 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
PeterPotkay wrote: |
There should be a PCF command / runmqsc command to at least be able to display what all these settings are. It would be nice to have all that info in an MS03 backup file, in a commented out section for reference only. |
Kinda along the lines what MS03 already does when backing up a z/OS Queue Manager's definitions. At the end (see example below from one of my test z/OS QMs), it captures some additional stuff and includes it as comments. Would be great if Windows / Unix QMs allowed this info to be queried via PCF commands and MS03 then took advantage.
Code: |
******** Log related definitions ********
*(zparm) CSQ6LOGP DEALLCT=0,
*(zparm) MAXARCH=25,
*(zparm) MAXRTU=2,
*(zparm) INBUFF=60,
*(zparm) OUTBUFF=4000,
*(zparm) WRTHRSH=20,
*(zparm) OFFLOAD=YES,
*(zparm) TWOACTV=YES,
*(zparm) TWOARCH=YES,
*(zparm) TWOBSDS=YES
*(cr) DEFINE LOG('TTST2.MQT1.LOGCOPY3.DS01') +
*(cr) COPY(1)
*(cr) DEFINE LOG('TTST2.MQT1.LOGCOPY3.DS02') +
*(cr) COPY(2)
******** Archive related definitions ********
*(zparm) CSQ6ARVP ALCUNIT=BLK,
*(zparm) ARCRETN=10,
*(zparm) BLKSIZE=28672,
*(zparm) PRIQTY=4320,
*(zparm) QUIESCE=5,
*(zparm) SECQTY=540,
*(zparm) CATALOG=YES,
*(zparm) COMPACT=NO,
*(zparm) PROTECT=NO,
*(zparm) ARCWTOR=YES,
*(zparm) UNIT=C,
*(zparm) UNIT2=C,
*(zparm) ARCPFX1=TTST2.MQT1.ARLOG1,
*(zparm) ARCPFX2=TTST2.MQT1.ARLOG2,
*(zparm) ARCWRTC=(1,3,4),
*(zparm) TSTAMP=YES
******** Usage related definitions ********
*(1cr) DEFINE PSID(0) +
*(1cr) BUFFPOOL(0) +
*(1cr) EXPAND(USER)
*(1cr) DEFINE PSID(1) +
*(1cr) BUFFPOOL(1) +
*(1cr) EXPAND(USER)
*(1cr) DEFINE PSID(2) +
*(1cr) BUFFPOOL(2) +
*(1cr) EXPAND(USER)
*(1cr) DEFINE PSID(3) +
*(1cr) BUFFPOOL(3) +
*(1cr) EXPAND(USER)
*(1cr) DEFINE PSID(4) +
*(1cr) BUFFPOOL(2) +
*(1cr) EXPAND(USER)
*(1cr) DEFINE PSID(5) +
*(1cr) BUFFPOOL(3) +
*(1cr) EXPAND(USER)
*(1) DEFINE BUFFPOOL(0) +
*(1) BUFFERS(50000)
*(1) DEFINE BUFFPOOL(1) +
*(1) BUFFERS(20000)
*(1) DEFINE BUFFPOOL(2) +
*(1) BUFFERS(75000)
*(1) DEFINE BUFFPOOL(3) +
*(1) BUFFERS(75000)
******** System related definitions ********
*(zparm) CSQ6SYSP LOGLOAD=500000,
*(zparm) QMCCSID=0,
*(zparm) EXITLIM=30,
*(zparm) EXITTCB=8,
*(zparm) CTHREAD=300,
*(zparm) IDBACK=20,
*(zparm) IDFORE=100,
*(zparm) STATIME=30,
*(zparm) TRACTBL=99,
*(zparm) WLMTIME=30,
*(zparm) SERVICE=,
*(zparm) CMDUSER=CSQOPR,
*(zparm) QSGDATA=(,,4)
*(zparm) OTMACON=(IMSOTMA,MQT1,DFSYDRU0,2147483647,CSQ)
*(zparm) ROUTCDE=(1),
*(zparm) TRACSTR=YES,
*(zparm) WLMTIMU=MINS,
*(zparm) QINDXBLD=WAIT,
*(zparm) RESAUDIT=YES,
*(zparm) SMFACCT=YES,
*(zparm) SMFSTAT=YES,
*(zparm) CLCACHE=STATIC |
_________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Jan 11, 2009 3:27 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
There are various kinds of suggestions that I'm taking quite seriously from different places to extend the functionality of saveqmgr to cover a wider range of what it saves.
One of the difficulties, however, is maintaining things across a wide variety of platforms and scripting environments.
If, for example, ms03 would create a script that would do nice things like rerun crtmqm, restore qm.ini, restore the mqsc objects... would you all trust that script? Would your unix admins be comfortable with you running it? Would you be comfortable with something that saved a configuration on Windows - and that configuration could only be "restored" on Windows?
I'd really like to hear more feedback, perhaps even in http://www.mqseries.net/phpBB2/viewtopic.php?t=43184 |
|
Back to top |
|
 |
sebastia |
Posted: Sun Jan 11, 2009 4:03 pm Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Thanks a lot to you all, as always, for giving me some (more) light.
I pretend to include my request whenever possible,
but once I know SAVEQMGR is not complete,
I would like to hear this sentence very loud,
saying ...
"MQ administrator : when you use SAVEQMGR,
you are saving the queue manager objects,
but not the QM.INI settings, as the LOG size,
the mount points, etc etc etc
(very large and explicit sentence, if possible)
Remember to save those values by using some other script".
That would be a very nice "ending" of MS03 on-line help or docu ...
It has been quite an unexpected surprise for me ... I have to admit.
Let's hope for a better 2009 ! |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Jan 11, 2009 4:35 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Yes I think this can be very easily done.
But it is stated
Quote: |
This SupportPac interrogates the attributes of all the objects defined to a
queue manager (either local or remote) and saves them to a file or files.
Queue manager objects (such as queue, process, namelist, topic, etc definitions) are
saved to a file in a format suitable for use with runmqsc. |
And, later,
Quote: |
This program does NOT save other qmgr information such as is contained in qm.ini or the Windows registry. |
I can move that to the front section. |
|
Back to top |
|
 |
Michael Dag |
Posted: Sun Jan 11, 2009 4:40 pm Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
interesting discussion! let me add my 2 cents
the MQDocument "local" install and run command (that does not rely on PCF or the Command Server)
already has 2 additional switches -version and -log for recording version and log information of the installed QMgrs.
Tags (sample values used) recorded in the XML/MQSC file are
ProductName="WebSphere MQ"
ProductVersion="6.0.0.0"
ProductCMVCLevel="p000-L050519"
ProductBuildType="IKAP - (Production)"
LogPrimaryFiles="100"
LogSecondaryFiles="100"
LogFilePages="256"
LogType="CIRCULAR"
LogBufferPages="0"
LogPath="C:\WMQ\log\QMGRA\"
LogWriteIntegrity="TripleWrite"
Since you can record the tags with their actual values, recreating the proper commands can done in a number of ways...
quickest would be to amend one of the provided sample reports (zip file):
mqd-sum.xsl - general summary
mqd-secsum.xsl - security summary
mqd-version.xsl - version summary
mqd-logset.xsl - log setting summary
mqd-maxdepth.xsl - maxdepth summary
mqd-maxmsgl.xsl - maxmsgl summary
mqd-conname.xsl - conname summary
mqd-port.xsl - port summary _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
sebastia |
Posted: Mon Jan 12, 2009 12:34 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Good morning. Let's tru to finish this ...
Jeff - IMHO, putting the "it does not" line in the front is ok,
but a bit not enough.
I would like to know more or less exactly
WHAT THIS TOOL DOES NOT SAVE and I can need in a "restore" situation.
mr Dag helps to complete the list :
*) QM.INI contents
*) product version and Fix Pack level
*) install directory
*) LOG specs (type and size)
My (last) question is :
? anything else is missing ?
Thank you very much. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jan 12, 2009 3:26 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Well it does not say that you have to modify the output from a zOS qmgr if you want to set it up as a distributed one as the queue properties are not all the same... but I thought that was just common sense...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bbburson |
Posted: Mon Jan 12, 2009 10:40 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004 Posts: 378 Location: Nowhere near a queue manager
|
sebastia wrote: |
My (last) question is :
? anything else is missing ?
|
Several other things come to mind:
-- the key database files from the qmgr's ssl directory
-- trigger monitors
-- perhaps channel initiators and listeners if you have very old style setups |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|