Re: Context Security on OS/390
Hi Again Stefan, I just realised that you wanted the commands here they are :- TSO RDEFINE MQADMIN .CONTEXT TSO RDEFINE MQQUEUE .B* TSO PERMIT MQADMIN .CONTEXT CLASS(MQADMIN) ID(MSTR) ACCESS(CONTROL) TSO PERMIT MQQUEUE .B* CLASS(MQQUEUE) ID(MSTR) ACCESS(UPDATE) The documentation is in the System Setup Guide for MQSeries for OS/390, Chapter 13. Profiles used to control access to MQSeries resources. Cheers, Tim Clarke, MQSupport Pty. Ltd., Australia. -Original Message- From: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Sent: Tuesday, October 29, 2002 11:50 PM Subject: AW: Context Security on OS/390 Hello, i do not understand this (sorry, i am not a racf specialist). the job has definitly granted access (alter) to the ressource profile of the queue. and it is also not a matter of "refresh security" i would like to try the hint with the MQADMIN class, but i do not know how to grant alter access to the MQADMIN Class. i can only grant access to a ressource defined in MQADMIN class, but which one? i checked application programmers guide / reference, security documentation etc. that comes with mq but no much information about context security in that case. any other hints or pointers to documentation? regards stefan __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ 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
Re: Context Security on OS/390
Hi Stefan, For MQPMO_SET_ALL_CONTEXT you will need to have CONTROL access to the MQADMIN profile ".CONTEXT" and UPDATE access to the MQQUEUE profile ".B*" Is it possible for you to do show us the results of the following commands :- TSO RLIST MQADMIN .CONTEXT AUTHUSER TSO RLIST MQQUEUE .B* AUTHUSER Hope this helps, Tim Clarke, MQSupport Pty. Ltd., Australia. -Original Message- From: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Sent: Tuesday, October 29, 2002 11:50 PM Subject: AW: Context Security on OS/390 Hello, i do not understand this (sorry, i am not a racf specialist). the job has definitly granted access (alter) to the ressource profile of the queue. and it is also not a matter of "refresh security" i would like to try the hint with the MQADMIN class, but i do not know how to grant alter access to the MQADMIN Class. i can only grant access to a ressource defined in MQADMIN class, but which one? i checked application programmers guide / reference, security documentation etc. that comes with mq but no much information about context security in that case. any other hints or pointers to documentation? regards stefan -Urspr|ngliche Nachricht- Von: Miller, Dennis [mailto:DMiller@;SNOPUD.COM] Gesendet: Montag, 28. Oktober 2002 16:53 An: [EMAIL PROTECTED] Betreff: Re: Context Security on OS/390 According to the error message you posted, that's not the case: > ICH408I,JOB(MSTR) STEP(MSTR) >.B.EXPIRY CL(MQQUEUE ) >INSUFFICIENT ACCESS AUTHORITY >FROM .B* (G) > ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) means that you need UPDATE access, but have NO access. I'm guessing that you have granted ALTER access in the ADMIN class. You also need to grant UPDATE in the MQQUEUE class. > -Original Message- > From: Raabe, Stefan [SMTP:[EMAIL PROTECTED]] > Sent: Monday, October 28, 2002 3:45 AM > To: [EMAIL PROTECTED] > Subject: AW: Context Security on OS/390 > > Dennis, > > thanks for the anser. > > the stc (the user) has ALTER to MQF1.B* profile. > > any other ideas? > > regards > stefan > > > -Ursprungliche Nachricht- > Von: Miller, Dennis [mailto:DMiller@;SNOPUD.COM] > Gesendet: Donnerstag, 24. Oktober 2002 21:55 > An: [EMAIL PROTECTED] > Betreff: Re: Context Security on OS/390 > > > Context security exists in both the MQADMIN and MQQUEUE classes. The > MQADMIN > class controls whether you're allowed to save/set/pass the context > information and applies across all queues. The MQQUEUE class is > queue-specific and controls what context options are allowed on the open. > > PMO-SET-ALL-CONTEXT is subject the the MQQUEUE class, therefore, I do not > believe you can turn it off with sssi.NO.CONTEXT.CHECKS. > > In your case, I believe the error occurs when the qmgr attempts to open > the > replytoq for the expiry report message. It wants to pass context to the > report message. > > I think your stc needs update authority to MQF1.B* profile in the MQQUEUE > class > > > > -Original Message- > > From: Raabe, Stefan [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, October 24, 2002 5:40 AM > > To: [EMAIL PROTECTED] > > Subject: Context Security on OS/390 > > > > Hello Group, > > > > I only have very little experience with context security, > > so I hope someone of you can put some light on this one. > > > > Here is the saga: > > > > There is an application that puts messages to a queue > > with these options: > > > > MQRO-EXPIRATION-WITH-FULL-DATA in MQMD-REPORT > > MQFMT-STRING in MQMD-FORMAT > > 10 in MQMD-EXPIRY > > "B.EXPIRY" in MQMD-REPLYTOQ > > "qmgrname" in MQMD-REPLYTOQMGR > > MQPMO-SET-ALL-CONTEXT > > > > Messages are put to Queue A, and if they expire and are > > removed during get/browse operation a report message with full > > data will be put to queue B.EXPIRY. Queues A and B.EXPIRY > > reside on the same Queuemanager. > > > > This works fine on a queuemanager with "NO.SUBSYS.SECURITY" > > profile defined. > > > > It does not work on a queuemanager that has queue security ON and > > context security OFF even though the queuemanager (the stc userid) > > has proper security defined to put messages on queue B.EXPIRY. > > The MSTR joblog shows this error: > > > > ICH408I,JOB(MSTR) STEP(MSTR) > >.B.EXPIRY CL(MQQUEUE ) > >INSUFFICIENT ACCESS AUTHORITY > >FROM .B* (G) > > ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) > > > > and messages are put to the DLQ with reason 2035. > > > > The RACF group the MSTR user is assigned to > > has ALTER access to MQF1.B* profile. > > The userid is equal to the jobname (MSTR). > > > > If I remove the PMO-SET-ALL-CONTEXT within the application program > > and try again, it works. > > > > So I think it is a matter of the context information in the message, > > but context security is OFF for this queuemanager. So I would > > expect it to work anyway. > > > > what am I missing here? > > What security definitions do I need to ma
Transmission queue name resolution in CICS DPL Bridge setup
Hi, We have MQ running in AS400 sending request message to MQ OS390 to trigger the CICS DPL bridge task to run CICS program and data are returned back to AS400 via a replyQ specified in the AS400 MQ application. The reply message is always sent via the xmitq named as the AS400 qmgr name. I understand that if I want to use a different xmitq, one way is not to specify qmgr name in the MQOD but how can I do that if I using CICS DPL bridge. Thanks Geok Hoon Warning : Privileged/confidential information may be contained in this message. If you are not the intended addressee, you must not copy, distribute or take any action in reliance thereon. Communication of any information in this email to any unauthorised person is an offence under the Official Secrets Act (Cap 213). If you receive this message in error, please notify the sender immediately and delete the same. Visit the eCitizen Housing Town at Http://www.ecitizen.gov.sg/ 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
Re: IT Employment Survey - Correct Attachment
At times of need or at times of need to reduce your budget??? It is all good - Management will get theirs as managements pay is directly proportional to the salary of the people they manage... reduce the salary of your people and you are only kidding yourself if you believe that it ot just a matter of time before that comes home to roost. The end. Stefan Sievert <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 04:10:50 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment Oh well, somebody must have hired them (including myself) in the first place, correct!? Probably at times of need, correct!? Hmmm.. >From: Randy J Clark <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: IT Employment Survey - Correct Attachment >Date: Wed, 30 Oct 2002 15:46:07 -0800 > >I think he sent it to the right places as they are all here on H1B's so he >is okay... >From what I can tell India must be a good place to be FROM! > > > > >Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 03:38:27 >PM > >Please respond to MQSeries List <[EMAIL PROTECTED]> > >Sent by:MQSeries List <[EMAIL PROTECTED]> > > >To:[EMAIL PROTECTED] >cc: >Subject:Re: IT Employment Survey - Correct Attachment > > > > >You may want to send this survey to IT people in other countries since that >is where most of all our jobs are going. > > > > > >Do you Yahoo!? >Y! Web Hosting - Let the expert host your web site > > >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 _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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
Re: IT Employment Survey - Correct Attachment
Oh well, somebody must have hired them (including myself) in the first place, correct!? Probably at times of need, correct!? Hmmm.. From: Randy J Clark <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: IT Employment Survey - Correct Attachment Date: Wed, 30 Oct 2002 15:46:07 -0800 I think he sent it to the right places as they are all here on H1B's so he is okay... From what I can tell India must be a good place to be FROM! Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 03:38:27 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment You may want to send this survey to IT people in other countries since that is where most of all our jobs are going. Do you Yahoo!? Y! Web Hosting - Let the expert host your web site 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 _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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
Re: IT Employment Survey - Correct Attachment
I think he sent it to the right places as they are all here on H1B's so he is okay... >From what I can tell India must be a good place to be FROM! Ken Russo <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/30/2002 03:38:27 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: IT Employment Survey - Correct Attachment You may want to send this survey to IT people in other countries since that is where most of all our jobs are going. Do you Yahoo!? Y! Web Hosting - Let the expert host your web site 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
Re: IT Employment Survey - Correct Attachment
You may want to send this survey to IT people in other countries since that is where most of all our jobs are going. Do you Yahoo!? Y! Web Hosting - Let the expert host your web site
Re: DISPLAY QSTATUS
Darry, I work on a very large account, and as such do not do the daily administration of the various MQ systems. My groupd is usually called after something has gone wrong and thus its a bit too late to install all the various utilities and support pacs I'd like to use :( Regards Tim A "Gorse, Darry" cc: Sent by: MQSeries Subject: Re: DISPLAY QSTATUS List 31/10/2002 02:44 Please respond to MQSeries List Dan, Have you downloaded the latest version of MO71? You might want to check out all the new features. ( Hint ! ) Cheers, Darry -Original Message- From: Boger, Dan [mailto:DBoger@;MFS.COM] Sent: Wednesday, October 30, 2002 7:56 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS I use MO71 as well, and love it - one odd omission I noticed though: there's no way to put messages to queues through it? there must be, and I must have missed it. Does anyone know of any such a function? Dan -Original Message- From: Gorse, Darry [mailto:darry.e.gorse@;CITIGROUP.COM] Sent: Wednesday, October 30, 2002 7:45 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Importance: Low Tim, That's the flexibility of MO71, you can use it to monitor/administrate a host of different platforms. I used it recently to connect to OS/390, Solaris, windows. Paul even included a MQSC window. ( Any way I always like to talk up Paul's support Pac. ) Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Tuesday, October 29, 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Darry, Yes that was where I first came across it. However we run a whole host of different platforms where I work and so I tend to use runmqsc as the common denominator. Regards Tim A "Gorse, Darry" cc: Sent by: MQSeries Subject: Re: DISPLAY QSTATUS List 30/10/2002 00:41 Please respond to MQSeries List Tim, Have a look at Paul Clarke's MO71 for V530. Paul's support Pac gives you a real crisp view of all this information in a windows format. See the attached file. Way to go Paul... Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Monday, October 28, 2002 11:14 PM To: [EMAIL PROTECTED] Subject: DISPLAY QSTATUS Came across the DISPLAY QSTATUS command recently. Availability seems to be V5.2 for MVS and V5.3 for distributed platforms, could be very handy for problem determination. An example from MQ 5.3 on Windows 2000 is shown below dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG 5 : dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG AMQ8450: Display queue status details. QUEUE(PING) PID(2772) APPLTAG(C:\mqecho.exe) TID(1) Regards Tim A 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 Queue_Usage.doc has been removed from this note on October 30 2002 by Tim Armstrong 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 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 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
Relation of currdepth to disk space
I have a question regarding how disk space gets freed in relation to messages on the q. We have an issue of running out of disk space on our test q mgr (MQ v 5.2; AIX v 4.3) when trying to run high volume message movement. The non-persistent messages are all put to a q (currdepth = 100,000) and then removed and processed via a series of mqgets. The behavior I've been seeing is that when the currdepth for the q drops down to 0, the q file located in the /mqm/qmgrs/qm1/queues/q1/ directory is still sitting at 200mb or so. It will stay that way until some point in the future (have yet to pinpoint exactly when) where it will drop down to the 900 or so bytes for an empty q. My question is does anyone know if this behavior is configurable, can I force MQ to clear the disk space more frequently or instantaneously, I assume at the expense of performance? Any help is appreciated. Thanks, Mike 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
Apology
My apologies everyone Accidently replied to the group with that survey... Michael D. Denning Systems Programmer NC Department of Justice Information Technology Division 919-716-1062 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
Re: put with logical order
Glad to here group-id will be supported in OS390 MQS 5.3 - but if you do not want to wait, you can code the logic yourself and still send valid messages to a platform which supports group-id. Below is some sample COBOL code. Be aware that the channel definition must have CONVERT BY SENDER equal to N and the receiving application will have to use CONVERT on the GET options. Your application program will have to handle increasing the MSGSEQNUMBER too. *$$BATCH,(OR AS400 UNIX WINDOWS VMS *IF P826AZ-CODEDCHARSETID = 0 *PERFORM BF710-INQ-QMGR ---this code pulls the value of the CCDID from the queue manager information. *END-IF. *$$END *$$CICS *MOVE 37 TO P826AZ-CODEDCHARSETID. *$$END *$$BATCH (OR AS400 CICS UNIX WINDOWS *MOVE P826AZ-CODEDCHARSETID TO MQMDE-CODEDCHARSETID. *MOVE MQMD-FORMAT TO MQMDE-FORMAT. *MOVE MQFMT-MD-EXTENSION TO MQMD-FORMAT. *MOVE P826AZ-GROUPID TO MQMDE-GROUPID. *MOVE P826AZ-MSGSEQNUMBER TO MQMDE-MSGSEQNUMBER. *IF P826AZ-ACTION = 'LAST' *MOVE MQMF-LAST-MSG-IN-GROUP TO MQMDE-MSGFLAGS *ELSE *MOVE MQMF-MSG-IN-GROUP TO MQMDE-MSGFLAGS *END-IF. *ADD MQMDE-STRUCLENGTH TO WM3-BUFFLEN. *STRING MQMDE P826AZ-DATA *DELIMITED BY SIZE INTO WM-MOVE-DATA. *MOVE WM-MOVE-DATA TO P826AZ-DATA. *$$END -Original Message- From: Graham Lekota [mailto:graham.lekota@;LIBERTY.CO.ZA] Sent: Monday, October 28, 2002 6:17 AM To: [EMAIL PROTECTED] Subject: put with logical order MQSeries on OS/390 does not support version 2 of the MQPMO Structure which allows for grouping of messages. If i want to group messages from OS/390 to solaris will it be possible to do this using MQSI? Any ideas will be appreciated. Thanks Graham Lekota Liberty Group +27 83 327 3619 http://www.liberty.co.za *** This message may contain information which is confidential and subject to legal privilege. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. *** 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 message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company ** 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
Re: IMS transaction with mq no_syncpoint
As I'm sure you're aware, the working storage of a dynamically called program is not preserved across calls. Is it possible you are losing the PMO option between calls? > -Original Message- > From: Flothmann, Eleonore [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, October 30, 2002 6:36 AM > To: [EMAIL PROTECTED] > Subject: AW: IMS transaction with mq no_syncpoint > > When I checked the program, the option MQPMO_NO_SYNCPOINT is set for the > MQPUT operation. We even compared this IMS program with a second one, that > works as expected. The only difference between the two programs is: > > the program which works:the main program is linked together with > the subroutine doing the MQ work > the program which doesn't: the main program fetches dynamically the > subroutine doing the MQ work > > Up till now we couldn't find basic differences. > > Eleonore > 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
Re: IT Employment Survey
Will you publish your finding here ? This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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
IT Employment Survey - Correct Attachment
My previous posting had the wrong attachment -Original Message- From: De Seve, David [mailto:David.DeSeve@;MARRIOTT.COM] Sent: Wednesday, October 30, 2002 12:03 PM To: [EMAIL PROTECTED] Subject: IT Employment Survey MQSeries User Group: In addition to working fulltime with MQ and WebSphere I am doing graduate research for American University in Washington DC on IT employment issues. Part of that research is a survey. Since most people that use this user group are IT professionals I though some of you might be willing to participate in the survey which is attached (or can be requested by sending an e-mail to [EMAIL PROTECTED]). Anyone who completes the attached survey and returns it before November 8 will be entered into a random drawing for $100 dollars U.S. Thanks Dave De Seve Middleware Systems Support - 52/997.33 MQSeries Certified Specialist Marriott International - Information Resources Direct Phone: 301-380-8279 Cell: 240-372-4848 Fax: 301-380-2922 IT_Employment_Survey.doc Description: MS-Word document
IT Employment Survey
MQSeries User Group: In addition to working fulltime with MQ and WebSphere I am doing graduate research for American University in Washington DC on IT employment issues. Part of that research is a survey. Since most people that use this user group are IT professionals I though some of you might be willing to participate in the survey which is attached (or can be requested by sending an e-mail to [EMAIL PROTECTED]). Anyone who completes the attached survey and returns it before November 8 will be entered into a random drawing for $100 dollars U.S. Thanks Dave De Seve Middleware Systems Support - 52/997.33 MQSeries Certified Specialist Marriott International - Information Resources Direct Phone: 301-380-8279 Cell: 240-372-4848 Fax: 301-380-2922 <> IT_Employment_Survey.doc Description: MS-Word document
Re: Queue Name Resolution and Cluster Channel selection
This makes sense from what I am seeing. But does not make sense from an implementation standpoint for allowing multiple channels between queue managers. If it is going to look at the cluster information to see if this is a cluster queue manager, why not look at the queue name to determine the cluster channel to use? The cluster manual says you can have multiple clusters between platforms to allow work to be balanced between the channels. And this is what I have attempted to do for our file transfers. I need the data and the trigger messages to both use the same cluster channel to make sure the trigger message arrives after all the data is sent. So far, I have not had any cases where the trigger arrived before all the data. I will try your suggestion about the queue manager alias and see if I can get it to select the proper channel. Andrea -Original Message- From: Raabe, Stefan [mailto:Stefan.Raabe@;DREGIS.COM] Sent: Wednesday, October 30, 2002 9:18 AM To: [EMAIL PROTECTED] Subject: AW: Queue Name Resolution and Cluster Channel selection Hello, I think your problem is not primarily related to clustering. In Section "4" you wrote: "OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue." If a queue is opened with queuename and queuemanagername specified in the object descriptor and the local queuemanagername is not equal to the queuemanagername specified in the object descriptor then the queuename is ignored and mqseries looks for "something" that has the same name as the queuemanager specified in the object descriptor. This could be an xmitq, a qmgr alias, and if mq does not find any of these it will look whether this queuemanager is known as a cluster queuemanager. Check with "Name Resolution" in Chapter "opening and closing objects" in Application Programming Guide. In your enviromnent the OS390 application - when putting to the reply queue - uses the queuemanager name, so the queuename is ignored. i assume, there is no xmitq nor a qmgr alias that has the same name as the replytoqmgr field, so mq on os/390 checks the cluster and recognises that the replytoqmgr is known as a cluster queuemanager. any cluster is fine in this situation because the queuename is ignored (and only the queuename holds the cluster CNTRRN that you try to use). its just random (or maybe "first-found" which cluster is picked and in your case a cluster with "convert no" in the proper cluster sender channel is picked. mhhh... how to solve this - the application on os/390 may stop to use the queuemanagername when putting the reply message. then the cluster queue is found during name resolution and the proper cluster channel should be selected. but this should only be used if all reply messages should be routed to the same destination (a matter of your applicaiton design) - use "normal" channels and make sure, that the xmitq name matches the replytoqmgr name and that the putting application uses the replytoqmgr when opening the reply queue - use a "virtual" replytoqmgr and define a qmgr alias in the proper cluster on the hpux machine so this virtual queuemanager is only found in a specific cluster. resolve the queuemanageralias to the local queuemanager on the hpux machine. maybe other thinks will work too, but i once read that - when there are multiple connections (channels) defined between two queuemanagers - it is sometimes not predictable which route a message will take. but i do not remember the exact context for this except that clustering was also a part of it. hope that helps, please let us know how you solved this issue. regards stefan -Ursprüngliche Nachricht- Von: Dorsey, Andrea L. [mailto:dorsey@;TIMKEN.COM] Gesendet: Dienstag, 29. Oktober 2002 23:55 An: [EMAIL PROTECTED] Betreff: Queue Name Resolution and Cluster Channel selection Background: 1) We are running MQS 2.1 on OS390 and MQS 5.2 on HP-UX. Between these two queue managers, we have defined multiple clusters, each with cluster channel-pairs. This is done to separate work - we use MQSeries for many file transfer functions and for request/reply and do not want the data intermixed or one channel pair overloaded. 2) Queue REQUEST is defined as local on OS390 in cluster CANTONRR. Queue REPLY is defined as local on HP-UX in cluster CANTONRRN. Cluster channel TO.HPUX.CNTRRN is the cluster sender for cluster CANTONRRN and had CONVERT BY SENDER equal to N. 3) OS390 program to send the REPLY message includes logic to build the MQMDE, including moving the MQMD Format to the MQMDE Format and setting the MQMD Format to indicate MQFMT_MD_EXTENSION. Because MQMDE is not supported by OS390 MQSeries Channel Init, message must be sent on a channel with CONVERT BY SENDER equal to N. 4) OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue. This should resolve the queue definition to the cluster queue and u
Recall: IT Employment Survey
De Seve, David would like to recall the message, "IT Employment Survey". 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
Re: WebSphere MQ on OS/390 & MQSeries 5.2
Dan, Rick is exactly right. The V5.3 ERLY code is downward compatible w/ the V5.2 systems you are running. (In fact, the IPL you perform to install the V5.3 ERLY code is last one you'll need to accomplish this. From this release forward, IBM has made this task a simple "MODIFY" command to make the MQ systems 'aware' of new ERLY code). As for the differences in the loadlibs, I assume you are STEPLIBing to the V5.3 code for the new system. This works just fine. OS/390 (z/os) is great in this respectyou can run more than 1 release level of the product on the same box. The non-mainframe systems do not support this 'flexibility'. Good Luck! Regards, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified Specialist / Solutions Expert - MQSeries (804) 697-3889 [EMAIL PROTECTED] Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 10/30/02 01:34 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Websphere MQ on OS/390 & MQSeries 5.2 I would check with the Support Center, but usually the higher level is downward compatible. I would think you could install the 5.3 early code without impacting the 5.2 queue managers. "Kinlen, Dan" AIN.COM> cc: Sent by: Subject: Websphere MQ on OS/390 & MQSeries 5.2 MQSeries List en.AC.AT> 10/30/2002 12:59 PM Please respond to MQSeries List This is a simple question: I am running 4 QMGR STC on my current image as 5.2, I need to Start a new QMGR on 5.3 on the same image for testing. When I enter my CPF command for the new QMGR I get the following: CSQY010E +CSQ1 CSQYASCP LOAD MODULE CSQ3EPX IS NOT AT THE CORRECT RELEASE LEVEL I am not sure how I can accomplish the 5.3 on the same image without affecting the other 4 QMGR. If the CPF is taken from LNKLST at IPL time, how do you load the New from a non-LNKLST loadlib? Daniel J. Kinlen RBC Dain Rauscher [EMAIL PROTECTED] (612) 547-4480 MQSeries Certified Specialist 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
Re: MQSeries 5.x and Solaris 9.0
Hi Darry, Thanks a lot for the info. Bill C. -Original Message- From: Gorse, Darry [mailto:darry.e.gorse@;CITIGROUP.COM] Sent: Tuesday, October 29, 2002 10:44 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries 5.x and Solaris 9.0 Bill, Try this web page: http://www-3.ibm.com/software/ts/mqseries/platforms/supported.html Cheers, Darry -Original Message- From: Conklin, William [mailto:WConklin@;GLHEC.ORG] Sent: Tuesday, October 29, 2002 8:36 AM To: [EMAIL PROTECTED] Subject: MQSeries 5.x and Solaris 9.0 Hi There, Do any of you know if MQSeries 5.x is "officially" supported on Solaris 9.0 Thanks a MILLION in advance. Bill C. 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 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
Re: DISPLAY QSTATUS
>I added the ability to put a test message in MO71 5.3 which is the >latest version. 5.3 also added quite a lot of other stuff so it's well > worth having. The put message function is via the Action->Put Message > menu. It's fairly basic though. It will let you give a string message > and say how many of them you want to put, whether it's persistent or > not and whether the whole thing should be done under a transaction. It > will then tell you how fast it was in msg/second. Right! I knew I saw it at some point. I spend almost all my time in the network view, so I missed it (since it's not in the action menu there). Thanks again for a great tool! Dan 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
Re: Websphere MQ on OS/390 & MQSeries 5.2
I would check with the Support Center, but usually the higher level is downward compatible. I would think you could install the 5.3 early code without impacting the 5.2 queue managers. "Kinlen, Dan" cc: Sent by: Subject: Websphere MQ on OS/390 & MQSeries 5.2 MQSeries List 10/30/2002 12:59 PM Please respond to MQSeries List This is a simple question: I am running 4 QMGR STC on my current image as 5.2, I need to Start a new QMGR on 5.3 on the same image for testing. When I enter my CPF command for the new QMGR I get the following: CSQY010E +CSQ1CSQYASCP LOAD MODULE CSQ3EPX IS NOT AT THE CORRECT RELEASE LEVEL I am not sure how I can accomplish the 5.3 on the same image without affecting the other 4 QMGR. If the CPF is taken from LNKLST at IPL time, how do you load the New from a non-LNKLST loadlib? Daniel J. Kinlen RBC Dain Rauscher [EMAIL PROTECTED] (612) 547-4480 MQSeries Certified Specialist 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
Websphere MQ on OS/390 & MQSeries 5.2
This is a simple question: I am running 4 QMGR STC on my current image as 5.2, I need to Start a new QMGR on 5.3 on the same image for testing. When I enter my CPF command for the new QMGR I get the following: CSQY010E +CSQ1CSQYASCP LOAD MODULE CSQ3EPX IS NOT AT THE CORRECT RELEASE LEVEL I am not sure how I can accomplish the 5.3 on the same image without affecting the other 4 QMGR. If the CPF is taken from LNKLST at IPL time, how do you load the New from a non-LNKLST loadlib? Daniel J. Kinlen RBC Dain Rauscher [EMAIL PROTECTED] (612) 547-4480 MQSeries Certified Specialist 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
IT Employment Survey
MQSeries User Group: In addition to working fulltime with MQ and WebSphere I am doing graduate research for American University in Washington DC on IT employment issues. Part of that research is a survey. Since most people that use this user group are IT professionals I though some of you might be willing to participate in the survey which is attached (or can be requested by sending an e-mail to [EMAIL PROTECTED]). Anyone who completes the attached survey and returns it before November 8 will be entered into a random drawing for $100 dollars U.S. Thanks Dave De Seve Middleware Systems Support - 52/997.33 MQSeries Certified Specialist Marriott International - Information Resources Direct Phone: 301-380-8279 Cell: 240-372-4848 Fax: 301-380-2922 <> Issues in Information Systems.doc Description: MS-Word document
Re: DISPLAY QSTATUS
>I use MO71 as well, and love it - one odd omission I noticed though: >there's no way to put messages to queues through it? there must be, and I >must have missed it. Does anyone know of any such a function? >Dan I added the ability to put a test message in MO71 5.3 which is the latest version. 5.3 also added quite a lot of other stuff so it's well worth having. The put message function is via the Action->Put Message menu. It's fairly basic though. It will let you give a string message and say how many of them you want to put, whether it's persistent or not and whether the whole thing should be done under a transaction. It will then tell you how fast it was in msg/second. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Rochester,MN 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
Re: CSQC101D can't open the init queue
Are you using the same initq in another CICS region? moshe moran cc: Sent by: Subject: CSQC101D can't open the init queue MQSeries List 10/30/2002 10:07 AM Please respond to MQSeries List Hi, when I am trying to initiate mq via plt in cics I got the message +CSQC101D SQA4025A CSQCTASK Cannot open the initiation queue. MQCC=2 MQRC=2042 +CSQC110I SQA4025A CSQCTASK Queue name = CICS02.INITQ My question is: Is there any mqm command that can show me which applid(connection-id) opened this queue. I tried DIS Q(CICS02.INITQ) and DIS THREADS(*) but I can;t get the answer to my question. It Moist Moran 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
Re: DISPLAY QSTATUS
Dan, Have you downloaded the latest version of MO71? You might want to check out all the new features. ( Hint ! ) Cheers, Darry -Original Message- From: Boger, Dan [mailto:DBoger@;MFS.COM] Sent: Wednesday, October 30, 2002 7:56 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS I use MO71 as well, and love it - one odd omission I noticed though: there's no way to put messages to queues through it? there must be, and I must have missed it. Does anyone know of any such a function? Dan -Original Message- From: Gorse, Darry [mailto:darry.e.gorse@;CITIGROUP.COM] Sent: Wednesday, October 30, 2002 7:45 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Importance: Low Tim, That's the flexibility of MO71, you can use it to monitor/administrate a host of different platforms. I used it recently to connect to OS/390, Solaris, windows. Paul even included a MQSC window. ( Any way I always like to talk up Paul's support Pac. ) Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Tuesday, October 29, 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Darry, Yes that was where I first came across it. However we run a whole host of different platforms where I work and so I tend to use runmqsc as the common denominator. Regards Tim A "Gorse, Darry" cc: Sent by: MQSeries Subject: Re: DISPLAY QSTATUS List 30/10/2002 00:41 Please respond to MQSeries List Tim, Have a look at Paul Clarke's MO71 for V530. Paul's support Pac gives you a real crisp view of all this information in a windows format. See the attached file. Way to go Paul... Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Monday, October 28, 2002 11:14 PM To: [EMAIL PROTECTED] Subject: DISPLAY QSTATUS Came across the DISPLAY QSTATUS command recently. Availability seems to be V5.2 for MVS and V5.3 for distributed platforms, could be very handy for problem determination. An example from MQ 5.3 on Windows 2000 is shown below dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG 5 : dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG AMQ8450: Display queue status details. QUEUE(PING) PID(2772) APPLTAG(C:\mqecho.exe) TID(1) Regards Tim A 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 Queue_Usage.doc has been removed from this note on October 30 2002 by Tim Armstrong 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 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
Re: SYSTEM.CHANNEL.SYNCQ
Bahman wrote: >Thanks Rebecca, I'll go through your suggested path and delete the messages >that belong to non-existing channels. But, while I am not adding any new >channel, >I see this queue is growing. Any idea why? Rebecca wrote: >Sorry, no. Perhaps Morag H. would care to comment. -- Rebecca Morag is away as a UK User conference for a day or two so let me answer in her place. The SYSTEM.CHANNEL.SYNCQ contains essentially two types of messages, both to do with storing channel status. 1/ There is a message (possibly two) for each instance of channel that has run and transferred a persistent message to a remote partner. These messages maintain the synchronisation state between the two ends of the channels. If you delete these messages your channel will forget where it got to. This will almost certainly lead to sequence number problems since the channel will start at 1 again and you will have to issue RESET CHANNEL. In the worst case, if the channel was indoubt, you may may also cause messages to be duplicated. 2/ There may also be a message recording the status of the channel. In other words, whether the channel is STOPPED, RETRYING etc etc. If you delete these messages the worsed that will happen is that when you recycle your Queue Manager a channel will come up inactive rather than STOPPED or RETRYING. Now there were a few problems with the initial implementation of the type 2 messages. You could find that even a channel retrying would add a few more of these messages. I would ensure that you are on the latest service level for whatever release you are running. In the general case though don't be fooled into thinking that you've got a problem with the queue just because you have more messages on there that you have channels. Since you have a Type 1 message for each *partner* you must consider how many locations you are talking to. So a single RCVR channel which receives connections from 100 other Queue Managers will, quite rightly, be responsible for 100 messages on this queue. Hope this helps, P. Paul G Clarke WebSphere MQ Development IBM Rochester,MN 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
AW: CSQC101D can't open the init queue
Hi, have a look at the "display qstatus" command (version 5.2 or higher ?!?) regards Stefam -Ursprüngliche Nachricht-Von: moshe moran [mailto:[EMAIL PROTECTED]]Gesendet: Mittwoch, 30. Oktober 2002 16:07An: [EMAIL PROTECTED]Betreff: CSQC101D can't open the init queue Hi, when I am trying to initiate mq via plt in cics I got the message +CSQC101D SQA4025A CSQCTASK Cannot open the initiation queue. MQCC=2 MQRC=2042+CSQC110I SQA4025A CSQCTASK Queue name = CICS02.INITQ My question is: Is there any mqm command that can show me which applid(connection-id) opened this queue. I tried DIS Q(CICS02.INITQ) and DIS THREADS(*) but I can;t get the answer to my question. It Moist Moran
Peter Henningsen/Australia/IBM is out of the office.
I will be out of the office starting October 31, 2002 and will not return until November 4, 2002. I have a couple of days leave - try mobile 0412.729.961 if urgent ... 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
Re: CSQC101D can't open the init queue
Hi Moshe, if you are on V5.2 you can use the DISPLAY QSTATUS command to get the information you are looking for (just learned that a couple of threads ago from Dave on this list ;-) ). Looks like you try to start the CICS trigger monitor CKTI more than once (it opens the INITQ in exclusive mode). HTH, Stefan From: moshe moran <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: CSQC101D can't open the init queue Date: Wed, 30 Oct 2002 16:07:08 +0100 Hi, when I am trying to initiate mq via plt in cics I got the message +CSQC101D SQA4025A CSQCTASK Cannot open the initiation queue. MQCC=2 MQRC=2042 +CSQC110I SQA4025A CSQCTASK Queue name = CICS02.INITQ My question is: Is there any mqm command that can show me which applid(connection-id) opened this queue. I tried DIS Q(CICS02.INITQ) and DIS THREADS(*) but I can;t get the answer to my question. It Moist Moran _ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp 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
AW: IMS transaction with mq no_syncpoint
Title: IMS transaction with mq no_syncpoint When I checked the program, the option MQPMO_NO_SYNCPOINT is set for the MQPUT operation. We even compared this IMS program with a second one, that works as expected. The only difference between the two programs is: the program which works: the main program is linked together with the subroutine doing the MQ work the program which doesn't: the main program fetches dynamically the subroutine doing the MQ work Up till now we couldn't find basic differences. Eleonore
Re: DISPLAY QSTATUS
Dan, that's likely because Paul wrote a separate SupportPac for that; it's MA01. Another very nice SupportPac for this kind of thing is MS0H. I believe that IH03 will also do that, despite the Integrator in the name (I think works fine for nonMQSI, although I don't think I've ever used it) Rebecca -Original Message- From: Boger, Dan [mailto:DBoger@;MFS.COM] Sent: Wednesday, October 30, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS I use MO71 as well, and love it - one odd omission I noticed though: there's no way to put messages to queues through it? there must be, and I must have missed it. Does anyone know of any such a function? Dan -Original Message- From: Gorse, Darry [mailto:darry.e.gorse@;CITIGROUP.COM] Sent: Wednesday, October 30, 2002 7:45 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Importance: Low Tim, That's the flexibility of MO71, you can use it to monitor/administrate a host of different platforms. I used it recently to connect to OS/390, Solaris, windows. Paul even included a MQSC window. ( Any way I always like to talk up Paul's support Pac. ) Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Tuesday, October 29, 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Darry, Yes that was where I first came across it. However we run a whole host of different platforms where I work and so I tend to use runmqsc as the common denominator. Regards Tim A "Gorse, Darry" cc: Sent by: MQSeries Subject: Re: DISPLAY QSTATUS List 30/10/2002 00:41 Please respond to MQSeries List Tim, Have a look at Paul Clarke's MO71 for V530. Paul's support Pac gives you a real crisp view of all this information in a windows format. See the attached file. Way to go Paul... Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Monday, October 28, 2002 11:14 PM To: [EMAIL PROTECTED] Subject: DISPLAY QSTATUS Came across the DISPLAY QSTATUS command recently. Availability seems to be V5.2 for MVS and V5.3 for distributed platforms, could be very handy for problem determination. An example from MQ 5.3 on Windows 2000 is shown below dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG 5 : dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG AMQ8450: Display queue status details. QUEUE(PING) PID(2772) APPLTAG(C:\mqecho.exe) TID(1) Regards Tim A 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 Queue_Usage.doc has been removed from this note on October 30 2002 by Tim Armstrong 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 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 and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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
Re: Queue Name Resolution and Cluster Channel selection
By any chance do you have an xmitq on OS/390 with the same name as the queue manager on HP-UX? CICS doesn't do any special. It's user of MQSeries services, just like a TSO user, or a batch job. "Dorsey, Andrea L." To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: OM> Subject: Queue Name Resolution and Cluster Channel Sent by: selection MQSeries List 10/29/2002 05:55 PM Please respond to MQSeries List Background: 1) We are running MQS 2.1 on OS390 and MQS 5.2 on HP-UX. Between these two queue managers, we have defined multiple clusters, each with cluster channel-pairs. This is done to separate work - we use MQSeries for many file transfer functions and for request/reply and do not want the data intermixed or one channel pair overloaded. 2) Queue REQUEST is defined as local on OS390 in cluster CANTONRR. Queue REPLY is defined as local on HP-UX in cluster CANTONRRN. Cluster channel TO.HPUX.CNTRRN is the cluster sender for cluster CANTONRRN and had CONVERT BY SENDER equal to N. 3) OS390 program to send the REPLY message includes logic to build the MQMDE, including moving the MQMD Format to the MQMDE Format and setting the MQMD Format to indicate MQFMT_MD_EXTENSION. Because MQMDE is not supported by OS390 MQSeries Channel Init, message must be sent on a channel with CONVERT BY SENDER equal to N. 4) OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue. This should resolve the queue definition to the cluster queue and use cluster CANTONRRN. For some reason, the REPLY message is trying to be sent using one of the other cluster sender channels to the HP-UX server. Since they have CONVERT BY SENDER = Y, Channel Init is sending the message to the local dead letter queue on OS390 for error code MQRC_FORMAT_ERROR. Why would the message not be sent using the cluster queue definition and related cluster channel? Is there any buffering of MQSeries information by the CICS regions which would prevent it from picking up changes made to the queue definition - even when I converted the REPLY queue to a remote definition on OS390, with related sender channel, MQSeries Channel Init still tried to use one of the cluster channels. Any ideas or explanations would be greatly appreciated, Andrea Dorsey MQSeries Support ** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company ** 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
Re: Changing passwords on an MQSI broker machine
Hi, Our message flows do use another database and we have played around with the settings for this as well and still have problems. The error messages below that something is still not quite right with the MQSi broker database. Has anyone ever managed to change the password for the MQSI user on a Windows NT server successfully? If so, what did you do and what versions of the software are you using? Thanks, Kulbir. "Benjamin Zhou" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 29-Oct-2002 17:14 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Changing passwords on an MQSI broker machine Kulbir, Most likely, your msgflow contain code accessing databases other than the broker database to do the work. So you must also have the same user/password defined on all databases your msgflows need to access. cheers, -Original Message- From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 10:45 AM To: [EMAIL PROTECTED] Subject: Re: Changing passwords on an MQSI broker machine Hi, We tried the following sequence: Changed the account password Updated the Services Start Up settings to ensure any service (DB2, etc) using this user account, uses the new password Stopped the MQSI broker service Used the mqsichangebroker command: mqsichangebroker brokername -p new password Rebooted the machine We now get the following errors in the Event Viewer: ** 29-10-02 2:28:30 PM MQSIv202 Error None 2048 N/A BRESXGAINDBR1 ( XBRE_NTX_BD1 ) An exception was caught while issuing database SQL command connect. The broker's database could not be accessed and an exception was generated. Ensure that the database is running. ** ** 29-10-02 2:28:30 PM MQSIv202 Error None 2321 N/A BRESXGAINDBR1 ( XBRE_NTX_BD1 ) Database error: ODBC return code '-1'. The message broker encountered an error whilst executing a database operation. The ODBC return code was '-1'. See the following messages for information obtained from the database pertaining to this error. Use the following messages to determine the cause of the error. This is likely to be such things as incorrect datasource or table names. Then correct either the database or message broker configuration. ** ** 29-10-02 2:28:30 PM MQSIv202 Error None 2322 N/A BRESXGAINDBR1 ( XBRE_NTX_BD1 ) Database error: SQL State 'HY000'; Native Error Code '-1402'; Error Text '[IBM][CLI Driver] SQL1402N Unable to authenticate user due to unexpected system error. '. The error has the following diagnostic information: SQL State 'HY000' SQL Native Error Code '-1402' SQL Error Text '[IBM][CLI Driver] SQL1402N Unable to authenticate user due to unexpected system error. '. This message may be accompanied by other messages describing the effect on the message broker itself. Use the reason identified in this message with the accompanying messages to determine the cause of the error. ** ** 29-10-02 2:28:30 PM MQSIv202 Error None 2053 N/A BRESXGAINDBR1 ( XBRE_NTX_BD1 ) The broker made an unsuccessful attempt to access its database MQSIBKDB with userid mqsiv2. The broker's database could not be accessed using the userid and password supplied. Ensure that the database is running and that the userid and password are correct. ** ** 29-10-02 2:28:30 PM MQSIv202 Error None 2088 N/A BRESXGAINDBR1 ( XBRE_NTX_BD1 ) An unexpected exception 'unknown' was caught. The broker caught an unexpected exception. Use the information in this message and previous messages to determine the cause of the problem, correct the error. A redeploy will be required if this error occurred as a result of a deploy operation. ** Any ideas on what else needs to be done? TIA, Kulbir. "Emile Kearns" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 29-Oct-2002 08:48 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Changing passwords on an MQSI broker machine Use the mqsichangebroker command, remember to stop the broker before issuing the command. -Original Message- From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]] Sent: 29 October 200210:22 To: [EMAIL PROTECTED] Subject: Changing password
CSQC101D can't open the init queue
Hi, when I am trying to initiate mq via plt in cics I got the message +CSQC101D SQA4025A CSQCTASK Cannot open the initiation queue. MQCC=2 MQRC=2042+CSQC110I SQA4025A CSQCTASK Queue name = CICS02.INITQ My question is: Is there any mqm command that can show me which applid(connection-id) opened this queue. I tried DIS Q(CICS02.INITQ) and DIS THREADS(*) but I can;t get the answer to my question. It Moist Moran
AW: Queue Name Resolution and Cluster Channel selection
Hello, I think your problem is not primarily related to clustering. In Section "4" you wrote: "OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue." If a queue is opened with queuename and queuemanagername specified in the object descriptor and the local queuemanagername is not equal to the queuemanagername specified in the object descriptor then the queuename is ignored and mqseries looks for "something" that has the same name as the queuemanager specified in the object descriptor. This could be an xmitq, a qmgr alias, and if mq does not find any of these it will look whether this queuemanager is known as a cluster queuemanager. Check with "Name Resolution" in Chapter "opening and closing objects" in Application Programming Guide. In your enviromnent the OS390 application - when putting to the reply queue - uses the queuemanager name, so the queuename is ignored. i assume, there is no xmitq nor a qmgr alias that has the same name as the replytoqmgr field, so mq on os/390 checks the cluster and recognises that the replytoqmgr is known as a cluster queuemanager. any cluster is fine in this situation because the queuename is ignored (and only the queuename holds the cluster CNTRRN that you try to use). its just random (or maybe "first-found" which cluster is picked and in your case a cluster with "convert no" in the proper cluster sender channel is picked. mhhh... how to solve this - the application on os/390 may stop to use the queuemanagername when putting the reply message. then the cluster queue is found during name resolution and the proper cluster channel should be selected. but this should only be used if all reply messages should be routed to the same destination (a matter of your applicaiton design) - use "normal" channels and make sure, that the xmitq name matches the replytoqmgr name and that the putting application uses the replytoqmgr when opening the reply queue - use a "virtual" replytoqmgr and define a qmgr alias in the proper cluster on the hpux machine so this virtual queuemanager is only found in a specific cluster. resolve the queuemanageralias to the local queuemanager on the hpux machine. maybe other thinks will work too, but i once read that - when there are multiple connections (channels) defined between two queuemanagers - it is sometimes not predictable which route a message will take. but i do not remember the exact context for this except that clustering was also a part of it. hope that helps, please let us know how you solved this issue. regards stefan -Ursprüngliche Nachricht- Von: Dorsey, Andrea L. [mailto:dorsey@;TIMKEN.COM] Gesendet: Dienstag, 29. Oktober 2002 23:55 An: [EMAIL PROTECTED] Betreff: Queue Name Resolution and Cluster Channel selection Background: 1) We are running MQS 2.1 on OS390 and MQS 5.2 on HP-UX. Between these two queue managers, we have defined multiple clusters, each with cluster channel-pairs. This is done to separate work - we use MQSeries for many file transfer functions and for request/reply and do not want the data intermixed or one channel pair overloaded. 2) Queue REQUEST is defined as local on OS390 in cluster CANTONRR. Queue REPLY is defined as local on HP-UX in cluster CANTONRRN. Cluster channel TO.HPUX.CNTRRN is the cluster sender for cluster CANTONRRN and had CONVERT BY SENDER equal to N. 3) OS390 program to send the REPLY message includes logic to build the MQMDE, including moving the MQMD Format to the MQMDE Format and setting the MQMD Format to indicate MQFMT_MD_EXTENSION. Because MQMDE is not supported by OS390 MQSeries Channel Init, message must be sent on a channel with CONVERT BY SENDER equal to N. 4) OS390 program is using the REQUEST message header ReplyToQ and ReplyToQMgr when opening the REPLY queue. This should resolve the queue definition to the cluster queue and use cluster CANTONRRN. For some reason, the REPLY message is trying to be sent using one of the other cluster sender channels to the HP-UX server. Since they have CONVERT BY SENDER = Y, Channel Init is sending the message to the local dead letter queue on OS390 for error code MQRC_FORMAT_ERROR. Why would the message not be sent using the cluster queue definition and related cluster channel? Is there any buffering of MQSeries information by the CICS regions which would prevent it from picking up changes made to the queue definition - even when I converted the REPLY queue to a remote definition on OS390, with related sender channel, MQSeries Channel Init still tried to use one of the cluster channels. Any ideas or explanations would be greatly appreciated, Andrea Dorsey MQSeries Support ** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communi
Re: DISPLAY QSTATUS
I use MO71 as well, and love it - one odd omission I noticed though: there's no way to put messages to queues through it? there must be, and I must have missed it. Does anyone know of any such a function? Dan -Original Message- From: Gorse, Darry [mailto:darry.e.gorse@;CITIGROUP.COM] Sent: Wednesday, October 30, 2002 7:45 AM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Importance: Low Tim, That's the flexibility of MO71, you can use it to monitor/administrate a host of different platforms. I used it recently to connect to OS/390, Solaris, windows. Paul even included a MQSC window. ( Any way I always like to talk up Paul's support Pac. ) Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Tuesday, October 29, 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Darry, Yes that was where I first came across it. However we run a whole host of different platforms where I work and so I tend to use runmqsc as the common denominator. Regards Tim A "Gorse, Darry" cc: Sent by: MQSeries Subject: Re: DISPLAY QSTATUS List 30/10/2002 00:41 Please respond to MQSeries List Tim, Have a look at Paul Clarke's MO71 for V530. Paul's support Pac gives you a real crisp view of all this information in a windows format. See the attached file. Way to go Paul... Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Monday, October 28, 2002 11:14 PM To: [EMAIL PROTECTED] Subject: DISPLAY QSTATUS Came across the DISPLAY QSTATUS command recently. Availability seems to be V5.2 for MVS and V5.3 for distributed platforms, could be very handy for problem determination. An example from MQ 5.3 on Windows 2000 is shown below dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG 5 : dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG AMQ8450: Display queue status details. QUEUE(PING) PID(2772) APPLTAG(C:\mqecho.exe) TID(1) Regards Tim A 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 Queue_Usage.doc has been removed from this note on October 30 2002 by Tim Armstrong 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 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
Re: IMS transaction with mq no_syncpoint
Title: IMS transaction with mq no_syncpoint You must explicitly add the no syncpoint option on the put in IMS, since the default is syncpoint yes (this is different than any of the distributed platforms, where the default is no) Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message-From: Flothmann, Eleonore [mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 30, 2002 6:25 AMTo: [EMAIL PROTECTED]Subject: IMS transaction with mq no_syncpoint Hi in one of our IMS transactions some code was added: it should MQPUT a request to MQ and get the answer using a MQGET Wait from a database server. The MQPUT is done with MQPMO_NO_SYNCPOINT, at least I am quite sure about that. Still the message is commited in MQ only after the IMS transaction is completed and IMS had automatically commited the unit of work. I could confirm this behavior, since the wait interval is set to about 2 min and during this interval the queue depth shows 1 message in the transmission queue to the remote server. Did we do something wrong? Any idea, what we might have forgotten? Regards, Eleonore This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: DISPLAY QSTATUS
Tim, That's the flexibility of MO71, you can use it to monitor/administrate a host of different platforms. I used it recently to connect to OS/390, Solaris, windows. Paul even included a MQSC window. ( Any way I always like to talk up Paul's support Pac. ) Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Tuesday, October 29, 2002 5:29 PM To: [EMAIL PROTECTED] Subject: Re: DISPLAY QSTATUS Darry, Yes that was where I first came across it. However we run a whole host of different platforms where I work and so I tend to use runmqsc as the common denominator. Regards Tim A "Gorse, Darry" cc: Sent by: MQSeries Subject: Re: DISPLAY QSTATUS List 30/10/2002 00:41 Please respond to MQSeries List Tim, Have a look at Paul Clarke's MO71 for V530. Paul's support Pac gives you a real crisp view of all this information in a windows format. See the attached file. Way to go Paul... Cheers, Darry -Original Message- From: Tim Armstrong [mailto:timarm@;AU1.IBM.COM] Sent: Monday, October 28, 2002 11:14 PM To: [EMAIL PROTECTED] Subject: DISPLAY QSTATUS Came across the DISPLAY QSTATUS command recently. Availability seems to be V5.2 for MVS and V5.3 for distributed platforms, could be very handy for problem determination. An example from MQ 5.3 on Windows 2000 is shown below dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG 5 : dis qstatus(PING) type(handle) opentype(all) PID TID APPLTAG AMQ8450: Display queue status details. QUEUE(PING) PID(2772) APPLTAG(C:\mqecho.exe) TID(1) Regards Tim A 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 Queue_Usage.doc has been removed from this note on October 30 2002 by Tim Armstrong 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
IMS transaction with mq no_syncpoint
Title: IMS transaction with mq no_syncpoint Hi in one of our IMS transactions some code was added: it should MQPUT a request to MQ and get the answer using a MQGET Wait from a database server. The MQPUT is done with MQPMO_NO_SYNCPOINT, at least I am quite sure about that. Still the message is commited in MQ only after the IMS transaction is completed and IMS had automatically commited the unit of work. I could confirm this behavior, since the wait interval is set to about 2 min and during this interval the queue depth shows 1 message in the transmission queue to the remote server. Did we do something wrong? Any idea, what we might have forgotten? Regards, Eleonore
Re: Client apps and conversion
If this is character data, you will need to set the format to MQFMT_STRING. Data of MQFMT_NONE (the default) will not be converted. Dave 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
Re: 'SYSTEM.DEF.CLUSSDR NOT FOUND' Error Message
Try starting the QMGR with the following parameter and see if the channel is defined: strmqm -c -Original Message- From: Tony Devitt [mailto:Tony_Devitt@;CGU.COM.AU] Sent: 30 October 2002 12:35 To: [EMAIL PROTECTED] Subject: 'SYSTEM.DEF.CLUSSDR NOT FOUND' Error Message ** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : A customer that I have worked with has an MQ cluster that consists of two HP-UX queue managers (app servers) and two Windows NT queue managers (MQSI brokers), running MQ 5.2. The queue managers run continuously. Recently both NT queue managers started producing the above message in their Errors logs (not at the same time, one started hours or days after the other) .. an attempt to start this channel, the above message, and then a channel abnormal termination message. Currently one has a status of 'CURRENT | RETRYING' and the other has status ' CURRENT | NOT RUNNING'. I am aware that this is the 'model' channel for Clussdr channel definitions and is not used for message transmission. I think that we should be able to stop the channels to stop the generation of error messages and cannot imagine that this would have any effect on the real cluster sender channels which are operating correctly. I have seen this error reported in a couple of forums but have not seen any answers. It does not appear in any of the NT CSD summaries. I would be interested to hear if anyone who has experienced the error discovered what caused it. Although the cluster appears to be functioning correctly the presence of unexplained, seemingly illogical cluster-related error messages is unsettling. : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of CGU Insurance. This message has been scanned for viruses and cleared by MailMarshal. : 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
