Pavel, MQ is it's own platform-independent data mover! Last time I did a migration such as you describe, I just set up channels between the two boxes and wrote a script to copy the contents of the queues across the channel. Once the messages were confirmed good on the new QMgr, I deleted the originals on the old QMgr and then the channels.
The saveqmgr program is great for your MQ object definitions but you will need to get the authorities as well. A colleague of mine has experimented with moving the contents of the SYSTEM.AUTH.DATA.QUEUE with some success but I'm a purist and prefer to use amqoamd -s to dump the auths to a script file. Do not forget to capture configuration data from mqs.ini, qm.ini and anything in /var/mqm/exits. Sorry, I don't know of any utility that captures all of this in one easy step. -- T.Rob -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Thursday, November 04, 2004 10:19 AM To: [EMAIL PROTECTED] Subject: Migration QM data from Solaris to Linux Hello all, I need to migrate user's queue manager from one platform to another (Solaris to Linux to be precise). Is there some utility or support pac that can help in migrating queue data? For example some utility that can gather all data on one platform to some platform-independent file that can be ftp-ed and easily restored on the other platform (assuming that all queues are already recreated). Another related question: Is saveqmgr the right tool for moving queue manager definition between platforms or should anything be tweaked in the file before restoring from it? Thank you in advance, Pavel "David C. Partridge" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RIMEUR.COM> Subject: Re: Creating report messages ends with reason 2035 Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 09/22/2004 04:03 AM Please respond to MQSeries List When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report, except in the following cases: Exception reports generated by a receiving MCA are put with whatever authority the MCA used when it tried to put the message causing the report. The PutAuthority channel attribute determines the user identifier used. COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA's user identifier, the queue manager puts the COA report using the MCA's user identifier. Applications generating reports should normally use the same authority as they would have used to generate a reply; this should normally be the authority of the user identifier in the original message. So, if this is a remote QM to the originator, then this should be being PUT with the authority of the MCA the originally put it onto the input Q. Whether this authority is enough to write to the TQ to go back depends on the platform and what user was running the MCA. For distributed platforms the user running the MCA will almost always be mqm or equivalent so it should work, but for the 390 system, the authority is defined by the RACF permissions and the value of the setting of PUTAUT on the receiver channel. This is discussed in chapter 15 and 17 of the z/OS System Setup Guide. So my guess is that the receiving system is 390 and that you are running your receiver channels with ALTMCA and that the CHIN is writing OK to the output Q, but when the getter gets the message the only authority left is the ALT part of ALTMCA. Perhaps someone with more experience of 390 access control for MQ can comment it this is a 390 system. Dave -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: 22 September 2004 08:14 To: [EMAIL PROTECTED] Subject: Creating report messages ends with reason 2035 MQ-Guys, I have the following situation: 1. An application "APP1" on qmgr "MQ1", running as a user "mqusr1", creates a message and sends it to a qmgr "MQ2". "APP1" sets the report options to "MQRO_COD" + "MQRO_EXCEPTION" + "MQRO_PASS_MSG_ID" + "MQRO_PASS_CORREL_ID" (I think, relevant in my case is only "MQRO_COD" ). 2. Application "APP2" on qmgr "MQ2", running as a user "mqusr2", reads the message successfully. But when "APP2" tries to put the report message, it fails with the reason code 2035 and the message is put to the local DLQ. 3. The user "mqusr1" does not exist on system 2, but the MD contains the user "mqusr1" in the field "UserIdentifier". 4. When I create the user "mqusr1" on system 2 with appropriate permissions, the report message is delivered successfully. Now the question: How can I enable the user "mqusr1" to write to a queue on system 2 without creating this account. Nevertheless the field "UserIdentifier" has to contain this user, so that the system 1accepts the message? In fact, it is not only one user on system 1, which may send a message and I do not want at all create a dozen or more users, just to enable the report messages. Thanks in advance. Mit freundlichen Grüßen / With kind regards Hubert Kleinmanns (N-Tuition Business Solutions AG) im Auftrag von / on behalf of AGIS Allianz Dresdner Informationssysteme GmbH GB2 Engineering AG2HDB02 - Host-DC-Systeme und Middleware (Bank) Windmühlstraße 14 / F 2.417 D-60627 Frankfurt / Main Telefon: +49-69-263-53262 Telefax: +49-69-263-11375 E-Mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
