Using Candle UA from .NET
Title: Using Candle UA from .NET Apologies for the slightly off-topic post. Has anyone successfully used Candle's Universal Agent Data Provider API from a .NET program (C# or VB.NET)? I'm trying to write a service that goes out an periodically pings our queue managers and then report the results up to our Candle hub. I cannot seem to get the dp_FormatBufferData call to work. I'm hoping someone else has work through this and would be will to share their results. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ voice: 206.545.3332 email: [EMAIL PROTECTED]
Re: MQQueue.CurrentDepth with MQSeries Automation Classes for ActiveX
Is the queue you are querying a local or alias queue? I think you would get this error if you inquire on CurrentDepth for a remote queue. - Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of David Kendall Sent: Friday, May 14, 2004 11:05 AM To: [EMAIL PROTECTED] Subject: MQQueue.CurrentDepth with MQSeries Automation Classes for ActiveX I am trying to query the QueueDepth for a local queue. My environment is Visual Basic 6 connecting to MQSeries using MQSeries Automation Classes for ActiveX Here is my code... Dim oSession As MQAX200.MQSession Set oSession = New MQAX200.MQSession Dim oQueueManager As MQAX200.MQQueueManager Set oQueueManager = oSession.AccessQueueManager(strQMgrName) oQueueManager.Connect Dim oQueue As MQAX200.MQQueue Set oQueue = oQueueManager.AccessQueue(strQueueName, MQOO_BROWSE Or MQOO_INQUIRE) Dim lMessageCount As Integer lMessageCount = oQueue.CurrentDepth ... The last line raises the following error MQAX200.MQQueue::GetCurrentDepth CompletionCode = 2, ReasonCode = 2067, ReasonName = MQRC_SELECTOR_ERROR Searching Google with tokens from the error message doesn't seem to result in much information. Can anyone shed any light as to why this is happening? Thanks in advance. 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: CWF to XML
bobbee - Let me ask the obvious question: Did you specify the MessageType in your MQInput node? Even with just one message defined to the Message Set, I think you still need to specify the MessageType, either via the MQInput node or via an RFH2 header on the message. - Steve P.S. I assume the above is still true for V5. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Robert Broderick Sent: Tuesday, April 20, 2004 7:03 PM To: [EMAIL PROTECTED] Subject: CWF to XML I did this a couple of time in 2.1 but 5.0 is giving me headacks. I have a MRM - CWF format coming in. I use the compute node to change the format to XML to output to a queue. The thing keeps complaining about the Messagetype not being part of the message. There is only one message in the SET. What gives? bobbee _ MSN Toolbar provides one-click access to Hotmail from any Web page FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ 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: VB client program preparation?
Gary - A point of clarification. The VB client uses mqic32.dll (not mqic.dll). The mqicstd.dll is from the old VB support pac from the days before VB support was officially added into the product (V5.1 I think). Assuming that you are using a V5.1 or later client, then you will not need (or find) mqicstd.dll. - Steve Gies -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of GDCII Sent: Monday, March 01, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: Re: VB client program preparation? Bill, If you are wanting to create an application which will communicate via MQ Client the mqm.dll is not needed. This is only for Server communication which I assume is not what you are wanting to do. The important dlls for client communication , which are registered during MQClient installation , are mqic.dll and mqicstd.dll which are needed for the client MQ communication. In CMQB you will find the following statements: '* In the Conditional Compilation field *' '* enter (without the quotes):*' '* MqType = 1 for the MQSeries server *' '* MqType = 2 for the MQSeries client *' '* You need MqType = 2 during compilation. Let me know if you have any other questions. Thanks, Gary Chesser -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Heggie, Peter Sent: Thursday, February 26, 2004 5:26 PM To: [EMAIL PROTECTED] Subject: Re: VB client program preparation? Oh yeah! Haven't straight vb mq in a while. I've done the client install and there is no mqm.dll on my workstation. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Kazatsky Sent: Thursday, February 26, 2004 4:58 PM To: [EMAIL PROTECTED] Subject: Re: VB client program preparation? mqax200.dll is used when programming with Active X. This looks like he's tryting to do straight API calls (which gives you mucj more options anyway) which does require the mqm.dll file and cannot be added as a reference. Either way, it does appear as though the installation isn't complete as the .dll should be in the bin directory of the MQ directory. HTH Dave Kazatsky Senior Middleware Administrator W. (908) 575-6947 C. (973) 865-8106 Heggie, Peter [EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM cc: Sent by: Subject: Re: VB client program preparation? MQSeries List [EMAIL PROTECTED] n.AC.AT 02/26/2004 04:41 PM Please respond to MQSeries List Did he run the MQ Client install? Usually its just mqax200.dll that is needed. The client install registers the mqax200.dll, and it is then available in the VB Project References list. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Beinert, William Sent: Thursday, February 26, 2004 4:31 PM To: [EMAIL PROTECTED] Subject: VB client program preparation? I have a developer writing the first VB app to be run as a client. I don't know VB at all, so I handed him the App. Prog. Guide and the Client Guide. So this is what he tells me... Should he have an MQM.DLL? What are we missing? Thanks Bill Hi, I'm now testing my program code. I copied all MQ-related declaration from cmqb.bas module file that MQ Client installation gave me. It references a dll file which I cannot find in my workstation: MQM.DLL, why don't I have this or should I be using another dll? All MQI function calls makes reference to this dll, like: Declare Sub MQCONN Lib MQM.DLL Alias [EMAIL PROTECTED] _ (ByVal QMgrName As String, _ Hconn As Long, _ CompCode As Long, _ Reason As Long) In the data definition file CMQB.bas that came with MQ Client, all MQI functions are contained in MQM.dll file, which I didn't have. Did I miss anything in the installation? Bill Beinert Systems Programming Con Edison When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE 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, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are
Re: VB client program preparation?
Bill -
When using the standard MQI with VB, as opposed to the ActiveX classes,
you must indicate whether you want to compile with the server dll
(mqm.dll) or client dll (mqic32.dll). You do this via a conditional
compilation variable.
Open up the project properties dialog box ( Project | {name} Properties
... }, click the Make tab, set the Conditional Compilation Arguments to
MqType = 2. This will link with the client dll. (To link with the
server dll, use MqType = 1). You do not need to have mqm.dll on your
server (either your development workstation or on the deployed server).
Hope this helps.
- Steve
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of
Beinert, William
Sent: Thursday, February 26, 2004 1:31 PM
To: [EMAIL PROTECTED]
Subject: VB client program preparation?
I have a developer writing the first VB app to be run as a client. I
don't know VB at all, so I handed him the App. Prog. Guide and the
Client Guide. So this is what he tells me... Should he have an MQM.DLL?
What are we missing?
Thanks
Bill
Hi,
I'm now testing my program code. I copied all MQ-related
declaration from cmqb.bas module file that MQ Client installation gave
me. It references a dll file which I cannot find in my workstation:
MQM.DLL, why don't I have this or should I be using another dll? All
MQI function calls makes reference to this dll, like:
Declare Sub MQCONN Lib MQM.DLL Alias [EMAIL PROTECTED] _
(ByVal QMgrName As String, _
Hconn As Long, _
CompCode As Long, _
Reason As Long)
In the data definition file CMQB.bas that came with MQ Client, all MQI
functions are contained in MQM.dll file, which I didn't have. Did I
miss anything in the installation?
Bill Beinert
Systems Programming
Con Edison
When they took the fourth amendment,
I was quiet because I didn't deal drugs!
When they took the sixth amendment,
I was quiet because, I was innocent.
When they took the second amendment,
I was quiet because I didn't own a gun!
Now they've taken the first amendment,
and I can say (or do) nothing about it.
The Second Amendment is in place in case they ignore the others. MODWN
DAbE
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: Problems starting config manager for WMQI v2.1
Title: Message Peter - Is the userid that the ConfigMgr NT Service runs under (mqsiuid in your example) a member of the "administrators" group on the server?I seem to recall getting this error if it is not. - Steve -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Moir, PeterSent: Thursday, February 05, 2004 6:56 AMTo: [EMAIL PROTECTED]Subject: Problems starting config manager for WMQI v2.1 Hi, been running the config. manager for a few days now without problems. Today I had occasion to stop it. When I restarted it I got. "Missing or blank message repository database name" Checked windows registry and then relevant entry is correctly filled out. So I stopped it again and deleted it. Then I created it again with command. mqsicreateconfigmgr -I mqsiuid -a mqsipw -q CM_QMGR -n MQSICMDB -m MQSIRMDB Created ok, no errors. Start the config manager and I get the same error.."Missing or blank message repository database name" But the entry in the registry after the create is fine - shows MQSIRMDB. DB and tables also check out in DB2. Tried this a few times now, no joy. Any ideas? Pete Notice to recipient:The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.
Re: Who is using 5.3?
Joan - For us, we had two main reasons for going to V5.3 (in Windows). The first was the generic security. The second was the Terminal Server support (we went to V5.3 as part of our migration from WinNT to Win2K). - Steve P.S. It has also been more stable (especially with CSD05). -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Joe H. Smith Sent: Tuesday, January 20, 2004 11:14 AM To: [EMAIL PROTECTED] Subject: Who is using 5.3? I am in the process of justifying our upgrade to 5.3 from 5.2 to the higher powers. (I guess better stability isn't enough). 10 iSeries, 7 Windows Servers, 10 clients. We historically do a uninstall and fresh install on the iSeries but we have never had an upgrade on a Windows system. I have been asked to list companies who are using it and what they think. If you have a moment please let me know your experience with the upgrade and what you think of 5.3. Thanks for you time. Joan Hughes Brown Shoe / Famous Footwear Technical Specialist 608-827-3523 * [This message and its contents have been scanned for viruses] * 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: What is supported to run under Windows XP
Jeff - What version of MQ are you running on your XP desktop? If it is not V5.3 CSD01 or greater, then perhaps that is causing your problems. - Steve Gies -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Jeff A Tressler Sent: Friday, January 09, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: What is supported to run under Windows XP Specifically we are trying to execute the MQSeries Integrator Control Center v2.0.1 under Windows XP. The actual broker and configuration manager is running under Window NT so is not a problem but I have been forced to upgrade my desktop from NT to XP and now the Control Center does not work I know we are like three versions behind (2.0.1 - me, 2.0.2, 2.1, 5.0 - latest) but we have not upgraded and will not be able to upgrade for at least two or three months. Jeff Tressler 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: Question on WMQI
Gaurav -
I would suggest using a single Output node with the Destination Mode set
to DestinationList. Then, in a preceding Compute node, determine which
queue and queue manager the message belongs on and set the
DestinationList in the LocalEnvironment as follows:
SET
OutputLocalEnvironment.Destination.MQ.DestinationData.queueManagerName =
{queue manager name};
SET OutputLocalEnvironment.Destination.MQ.DestinationData.queueName =
{queue name};
If you are using locally defined Remote Queue Names, then set this as
the queueName and omit the queueManagerName. Same thing if you are
using cluster, with unique queue names at each store. Set this name for
queueName and omit the queueMangerName as the repository will resolve
this for you.
Hope this helps. If you go this route, you will want to read up on the
details of using DestinationLists in the Working with Messages manual.
- Steve
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of
Mittal, Gaurav
Sent: Wednesday, December 03, 2003 11:24 AM
To: [EMAIL PROTECTED]
Subject: Question on WMQI
I have a couple of questions regarding WMQI message flows:
1. We need to transfer same file to around 1000 stores, so will it be a
good option to use WMQI to message flow with 1000 output nodes, which
put message to remote queue definitions. These remote queues will take
data to the store queue managers via sender-receiver channel pair.
2. We need to transfer each record in file to a different store, based
on a value in the message. We were thinking of using a WMQI message flow
to route the message to different output nodes based on the value of
this field(possibly using route to label). Again there are 1000
different output queues possible, out of which each message will go to
only one queue.
Please let me know if anyone is doing something similar or has a better
idea to achieve the same.
Regards
Gaurav Mittal ___
EAI Consultant
Wipro Technologies
(612)-291-4551 (W)
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: arrival time of last message
I assume you are looking to create some sort of monitoring app that will alert you if queue X has not received a message in N minutes. If this is the case, you might look into the RESET QSTATS command (See the Command Reference for details). If you create a program that sends a RESET QSTATS (queue-name) command every N minutes, it will tell you how many messages have been enqueued and dequeued since the last RESET command was sent. If the enqueued count is 0, you have not received any messages in the interval. Hope this helps. - Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of I Sent: Tuesday, November 18, 2003 5:17 AM To: [EMAIL PROTECTED] Subject: Re: arrival time of last message It's odd that server folk are less vigilant than the mainframe folk. You'd think the maintainers of the less reliable and proven platform would *more* vigilant if anything, but I guess one can never tell. But back to the point... do they have channel triggering configured correctly? I've encountered a few situations where it hasn't been, and channels have timed out, never to be automatically restarted. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Larry Murray Sent: Tuesday, 18 November 2003 10:35 To: [EMAIL PROTECTED] Subject: arrival time of last message Good evening folks.. We are having an issue with some servers that send messages to MQ on the mainframe. MQ, as always, is working perfectlybut evey now and then one of the servers just stops sending messages. The server folks are less vigilant than the mainframe guys. Usually we see that a server is no longer sending messages beause because the CICS transactions triggered as a result of the arrival of a message stops. So..I am looking for a method that I can employ to query MQ as to the last time a message arrived on a queue. The messages are not persistent. When CICS executes the triggered transaction, the message goes away. Is there a time stamp some placein the queue stats that a program can access that will give a dte/time stamp of the last message that hit the queue? Thanks...Larry Larry Murray Putnam Investments Tech Services 1-617-760-3270 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: disable triggering
Bob - I assume that what you are looking for is a way to turn off all IMS or CICS triggering at this time and turn it back on again later. One solution is to turn triggering off on each application via a batch job. The downside of this is that if you've got lots of application queues using triggering, this may be difficult to maintain over time. A better solution might be to put inhibit the initiation queue(s) used by the trigger monitors that you wish to disable. This will prevent new trigger messages from arriving on this queue. When you put enable the queue again, MQ will look at all of the queues that trigger to this queue and create a new trigger message if the depth is greater than zero (assuming you are using triggering on FIRST). The advantage of this approach is that you are far less likely to be adding new trigger monitors and initiation queues that you are to be creating new application queues that use triggering. - Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of bob thomas Sent: Thursday, October 23, 2003 10:11 AM To: [EMAIL PROTECTED] Subject: disable triggering Hi, I was hoping someone already has come up with a solution for this one: We need to disable triggering on a mainframe queue(s) at a specified time, we would like to know if there is way to automate this with either a batch job or an mvs modify command. We would like to do this at a specified time for example 3:30AM (you can see why we want to automate this now). Thanks for any input _ Send instant messages to anyone on your contact list with MSN Messenger 6.0. Try it now FREE! http://msnmessenger-download.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 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: AMQ7227
Darren - Yes. We got this error on a server that hosted multiple, test queue managers. What turned out to be the problem is one of the admin folks wrote a little command file to refresh the security on each queue managers (basically ran a runmqsc command and piped in a file with REFRESH SECURITY as the command). This would cause the RPC server to get overloaded as it tried to re-cache all of the security groups from the domain controllers. If we delayed the command about 20 seconds between queue managers, this allowed enough time to prevent this overload. - Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Walliss, Darren Sent: Monday, October 06, 2003 12:32 AM To: [EMAIL PROTECTED] Subject: AMQ7227 Has anybody seen one of these before? (We're on Win2k SP3, MQ5.3 + CSD03) 06/10/2003 17:15:40 AMQ7227: WebSphere MQ encountered the following network error: The RPC server is unavailable. EXPLANATION: MQ failed to successfully complete a network operation due to the specified error. ACTION: Ensure that your network is functioning correctly. Darren 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
CA Monitoring Agents for MQ
Title: CA Monitoring Agents for MQ We are looking at the possibility of replacing our current MQ monitoring solution with Unicenter Management for MQSeries (on Windows 2000) and SysView E WebSphere MQ Option (on z/OS) feeding into a Unicenter console. The reasoning behind this move is to consolidate much of our enterprise monitoring into Unicenter. Before I get too far down this road, I'm looking for some feedback from folks who have some practical experience with these CA products. Were they easy to install and configure? Were you able to set up all of the alerting that you expected to? Did you encounter any serious roadblocks? Are the agents stable? Anything along this line I welcome any and all comments. If you would prefer to share you comments off list, that is fine as well. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ
Re: Trigger question
Dave - We have found that the NT Client trigger monitor does not properly handle path definitions that contain spaces (i.e. C:\Program Files\My Program Dir\My Program.exe). This has to be specified using the DOS path (i.e. C:\PROGRA~1\MYPROG~1\MYPROG~1.EXE). I'm not sure if the server version of the trigger monitor has the same issue (we don't use it). - Steve -Original Message- From: Williams, Dave (Systems Management) [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: Re: Trigger question I'm less familiar w/NT side, but we see 1) Triggering is on 2) Curr depth gores from 0 to 1 - nothing happens. 3) the .exe specified in the process def path (correct, by the way) when executed empties the queue. Dave W. -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 11:51 AM To: [EMAIL PROTECTED] Subject: Re: Trigger question How do you know it's not triggering? -Original Message- From: Williams, Dave (Systems Management) [SMTP:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 8:43 AM To: [EMAIL PROTECTED] Subject: Trigger question We're experiencing an issue where we have 2 new queues (on an NT QMGR, V5.2) defined as triggered, but it's not triggering - * There ARE queues on this box that ARE triggering. * The path and executable are correct - we can manually drive this and the process works. * These are new, but I think the box has been rebooted SINCE then Any ideas what could be wrong? Thanks, Dave W. 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: Limiting access authority on Windows
Ruzi - I think you are on the right track here. A couple of points: If possible (and this is really desirable) have all queues for a given application start with the same app code. For example, in our shop, all queues start with a three char application code followed by a period. For example: XYZ.THE.QUEUE On each queue manager server, create a local group for that app code. For example: MQXYZ In this group, put the ids for all users and programs (i.e. Service ids, COM+ Application Ids, etc..) that need access to the queue. This can include Global Groups from the domain or a trusted domain if desired. Use setmqaut to grant authorities such that each application group can access it's queues. For example: setmqaut -m QM1 -t queue -n XYZ.** -g MQXYZ +mqiall Note the double asterisk. This indicates that everything is wild at this point. A single asterisk only wildcards one node. (This is probably why your test did not work). One other note. You might find it desirable to create multiple groups with different accesses. For example: MQXYZPmgrs +allmqi (give programmers all access) MQXYZManagers +browse +inq (give managers browse and inquiry access) - Steve -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 7:10 PM To: [EMAIL PROTECTED] Subject: Limiting access authority on Windows Hi all, The platform is MQ 5.3 CSD04 on W2000. In our shop, MQ administrators have been putting in the domain mqm group, anyone who will be involved in any kind of MQ work ( development, testing etc.). Obviously, all these people have full access to all the MQ resources of the company. Some of these people have MQSeries servers on their workstations (I don't know why they were given). Even if they did not know much about MQSeries, it would not take a genius to be able use the MQ Explorer and do some damage inadvertently... I would like to limit the access of these individuals to only the MQI calls on their related MQ objects. They should not be able to do any kind of administrative work in the Integration and User Acceptance environmenta for instance. So, the following is what I thought I should do, in order to give userid1 limited access to objects on QM1 on server1 (W2000): 1- Create a group (say, G1) 2- Remove userid userid1 from the domain mqm 3- Sign on to server1 3- Give authority to G1... issuing: setmqaut -m QM1 -t queue -n HER.QUEUE* -g G1 +mqiall I may have to do a few more setmqauts to give access to qmgr object and prcs... 4- Drop userid1 in group G1 I have never done this before. We have just created a group called G1 and a userid userid1, who is not in domain mqm. I then signed on to server1 and issued the above mentioned setmqaut command against QM1. Of course, it did not work as G1 is not locally recognized; I got an entity missing error. What should I do or tell our security person to do, to get this working? Your help would be very much appreciated. Thanks, and all have a nice weekend. Ruzi 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: Data conversion with MA7P using .NET application
Elena - This is a known bug in the current .NET support pac. What is happening is that by default the MQQueue class attempts to get the message with a 1 byte buffer. This of course fails (unless you just happen to be passing a 1 or 0 byte message!!) with a truncation failure. The class then resizes its internal buffer and retries the MQGET call, and since the buffer is now large enough the message is retrieved. (BTW, the ActiveX classes do the same thing, but they start with a 2K buffer). The problem with the .NET classes is that after the first MQGET call the MQMD-CCSID field has been updated with the value from the message - which is the value from the mainframe queue manager. When the second call is made, this field is not reinitialized. This tells MQ to convert the data into the code page from the mainframe. Since the data is already in this code page, no conversion takes place. One way to work around this problem is to instruct the class to use a bigger default buffer size. You do this on the put method. For example, to use a 5000 byte buffer in VB.NET code the following myQueue.Get(myMsg, myGMO, 5000) This does, however, require you to know what the largest size message will be. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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: Data conversion with MA7P using .NET application
Elena - You would set the default buffer size on the Get method, not the Put method. As to what size to use, that really depends on your application that is putting messages to your queue. - Steve -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:23 PM To: [EMAIL PROTECTED] Subject: Re: Data conversion with MA7P using .NET application Hello Steve, thank you very much for your reply, it is nice to know that we are not alone ... The queues using this support pack are set to 4 Meg max message size. Our developer will test setting larger buffer size on a PUT. What size do you recommend? Thanks again. Elena. GIES, STEVE [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 01:55:38 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Data conversion with MA7P using .NET application Elena - This is a known bug in the current .NET support pac. What is happening is that by default the MQQueue class attempts to get the message with a 1 byte buffer. This of course fails (unless you just happen to be passing a 1 or 0 byte message!!) with a truncation failure. The class then resizes its internal buffer and retries the MQGET call, and since the buffer is now large enough the message is retrieved. (BTW, the ActiveX classes do the same thing, but they start with a 2K buffer). The problem with the .NET classes is that after the first MQGET call the MQMD-CCSID field has been updated with the value from the message - which is the value from the mainframe queue manager. When the second call is made, this field is not reinitialized. This tells MQ to convert the data into the code page from the mainframe. Since the data is already in this code page, no conversion takes place. One way to work around this problem is to instruct the class to use a bigger default buffer size. You do this on the put method. For example, to use a 5000 byte buffer in VB.NET code the following myQueue.Get(myMsg, myGMO, 5000) This does, however, require you to know what the largest size message will be. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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: WMQ V5.3 stability?
Title: Message We got hit by this. We never got hit in dev either (and still haven't) but we've had three incidents in the past 6 weeks were a queue was damaged. Both of the queues involved (1 has been damaged twice) have a high number of abandoned reply messages on them that get cleaned out nightly. Not by CLEARQ, but by a custom job that removes messages over N hours old. The damage always occurred sometime after this nightly job. We just got the fix and are applying it to dev this weekend. If you have any queues that might be susceptible to this, then I would recommend getting the fix. - Steve P.S. Other than this problem WMQ V5.3 CSD01 on W2K servers has been very, very stable and trouble free for us. -Original Message-From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 12:09 PMTo: [EMAIL PROTECTED]Subject: Re: WMQ V5.3 stability? Has anyone else hit this problem? We're putting 5.3 onto production in a few weeks and haven't seen this on the various dev and test environments we've got it on. If there is something particular that causes the symptoms then that would be useful information. Thanks Darren. - Original Message - From: Kulbir S. Thind To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 4:54 PM Subject: Re: WMQ V5.3 stability? Hi, We've just installed it recently and you need to ensure you get the latest media. There was a big problem with the distribution of this release and the numbering used. For example 5.3 went out in June 02 and Oct 02, both releases being different although both being called 5.3. Make sure you get the latest media and then the latest CSD (there may be one on the web site). In addition to this we found a bug where MQSeries objects kept becoming damaged. IBM provided us with an e-fix, this fix is not included in the latest CSD and must be applied. APAR IC35711 is the reference IBM are using for this. Other than the above we've had no problems. Cheers, Kulbir. "Rick Tsujimoto" [EMAIL PROTECTED] Sent by: "MQSeries List" [EMAIL PROTECTED] 06-Mar-2003 14:58 Please respond to "MQSeries List" [EMAIL PROTECTED] To: MQSERIES cc: Subject: WMQ V5.3 stability?I'm probably going to install V5.3 on Windows soon and am interested tohear the experiences of others who have already implemented it inproduction. Any bloody, gory tales?Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Sequence errors after install of 5.3 on W2K
Peter - You need to create the Blocking value using a tool like regedit. It is not created by any of the MQ Admin GUIs or commands. (Although you could use amqmdain to create this value.) We had the same problem as Cynthia report, but only on our 5.2 CSD05 WinNT machines. Adding this registry value also stabilized our environment. We are in the process of migrating to 5.3 on Win2K, and so far we have not had this issue come up. We have not set this registry value on the new machines. - Steve Gies -Original Message- From: Peter Heggie [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 8:40 AM To: [EMAIL PROTECTED] Subject: Re: Sequence errors after install of 5.3 on W2K Thanks - we are going to try using this key on our test machine. We created our queue managers with scripts, for recovery purposes, and there is no parameter for TCP-related information in the crtmqm command, and I'm guessing that is why we do not see a TCP key in the registry. When we go through the MQ Services GUI/console, and update the Queue Manager properties under TCP, then a TCP key is created. But Blocking is not created.. From: Cynthia Wallace [EMAIL PROTECTED] on 01/20/2003 10:40 AM Please respond to MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Sequence errors after install of 5.3 on W2K Does that mean that MQ will default to use blocking, because we are on v5.3 ? Is there a problem or risk in inserting a new key (TCP) and adding a value of Blocking under it? Are there any other names under TCP that have to be included with Blocking? I can try this out on a test machine.. It is my understanding (from IBM) that with 5.2 CSD05 IBM has set the TCP default to use blocking I/O and that there is a problem with the Microsoft code. There was no other requirement for this fix other than ensuring that TCP was set to non-blocking as indicated. The KeepAlive value is under this key also but was not required for this fix. We have seen no problems with this new value and it was the only thing that stabilized our environment. Cynthia Wallace IBM Certified Specialist - MQSeries [EMAIL PROTECTED] (860) 665-5990 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: MUSR_MQADMIN
Lizette - I assume you are using WinNT or Win2000 and MQ v5.2: From a command prompt type DCOMCNFG. In the dialog box that pops up, select IBM MQSeries Services, click the Properties button. In the properties sheet, select the Identity tab. From here you can change the id under which the MQSeries service run. - Steve Gies P.S. The above should work for V5.3, but I also think they give you the option to use a domain userid during the install. -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 9:34 AM To: [EMAIL PROTECTED] Subject: MUSR_MQADMIN Does anyone know how to change the userid MUSR_MQADMIN to another userid? --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. --- 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: Expiry Overhead
Jim - Out of curiosity: Are these persistent messages? Are they relatively large? I would expect that the actual, physical deletion of a persistent, expired message would require the same logging overhead as any normal MQGET of the same persistent message. If you are deleting a large volume of persistent messages this might have a very noticeable impact on the logger. - Steve Gies -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 11:40 AM To: [EMAIL PROTECTED] Subject: Expiry Overhead We've had some performance problems in a synchronous app lately. It's a VB-NT client connected to a Solaris concentrator. Messages are put to a queues that go thru WMQI on Solaris. Flows convert XML to Cobol, and forward them to the mainframe. CICS programs do some DB2 work, and send replies that follow the same path in the opposite direction. We've noticed that these round trips slow way, way down at noon and 4:00 PM on Monday, Thursday and Friday. But we don't see this on Tuesday and Wednesday. After much research, we found a Perl script that runs on the WMQI server every day at noon and 4:00. The script goes through a queue and does GETs for a length of 0. This queue is an output only, archive queue, with messages that expire 3 days after they're put. The purpose of the script is to allow messages older than three days to expire. Our theory is that the overhead of expiration is noticeably slowing down WMQI. The reason Tuesday and Wednesday are OK is because far fewer messages expire on those days (since the only messages eligible to expire were from the previous weekend). We turned this script off, and will know on Friday if this is the problem. Our WMQI server is a dual processor machine loaded with memory. It's very surprising to me this script could hurt throughput this much, but it certainly looks that way. Has anyone seen this? Does IBM have any info as to what sort of overhead is involved in expiring messages? 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: Expiry Overhead
Sorry to disappoint, but I'm fairly certain that this new feature is OS/390 version only. It was implement to clean up shared queues in the coupling facility. I don't think it was implemented in the distributed code base. - Steve Gies -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 3:50 PM To: [EMAIL PROTECTED] Subject: Re: Expiry Overhead I'm on 5.2 now, so you've provided some hope. Stefan Sievert stefansievert@HOTo: [EMAIL PROTECTED] TMAIL.COM cc: Sent by: MQSeriesSubject: Re: Expiry Overhead List MQSERIES@AKH-WIE N.AC.AT 11/26/2002 05:17 PM Please respond to MQSeries List Jim, I think I remember reading in the announcment of MQ V5.3 that you no longer have to write these scavenger routines to get rid of expired messages, but that the queue manager itself will take care of that. Which version of MQ are you currently on? I don't know if my memory serves me well, but if this processing is causing you trouble because of massive log activity you might see some remedy after your next upgrade. Surely doesn't help much right now, though. Can somebody confirm? Cheers, Stefan From: Jim Ford [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Expiry Overhead Date: Tue, 26 Nov 2002 13:39:32 -0600 We've had some performance problems in a synchronous app lately. It's a VB-NT client connected to a Solaris concentrator. Messages are put to a queues that go thru WMQI on Solaris. Flows convert XML to Cobol, and forward them to the mainframe. CICS programs do some DB2 work, and send replies that follow the same path in the opposite direction. We've noticed that these round trips slow way, way down at noon and 4:00 PM on Monday, Thursday and Friday. But we don't see this on Tuesday and Wednesday. After much research, we found a Perl script that runs on the WMQI server every day at noon and 4:00. The script goes through a queue and does GETs for a length of 0. This queue is an output only, archive queue, with messages that expire 3 days after they're put. The purpose of the script is to allow messages older than three days to expire. Our theory is that the overhead of expiration is noticeably slowing down WMQI. The reason Tuesday and Wednesday are OK is because far fewer messages expire on those days (since the only messages eligible to expire were from the previous weekend). We turned this script off, and will know on Friday if this is the problem. Our WMQI server is a dual processor machine loaded with memory. It's very surprising to me this script could hurt throughput this much, but it certainly looks that way. Has anyone seen this? Does IBM have any info as to what sort of overhead is involved in expiring messages? 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 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: Channels out of sync - MQ5.2 OS/390
Title: Channels out of sync - MQ5.2 OS/390 Pieter - This problem may have nothing to do with the SYNCQ. You mentioned distributed QMGR's in your email. We have experience several Msg Sequence errors ever since we upgraded our NT V5.2 servers to CSD05. Apparently the receive socket call was changed from non-blocking to blocking in CSD05. This, according to IBM, has exposed a bug in Microsoft's IP stack where a packet will get lost, hence the sequence error. The channels that go in error are always from MVS to NT. So far we have only had the problem with WinNT servers, not Win2K, but I've only got a couple of lightly used queue managers on Win2K machines, so I can't say for sure it is restricted to WinNT. This is still an open problem record. - Steve SAFECO Insurance -Original Message-From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]]Sent: Monday, November 18, 2002 4:53 AMTo: [EMAIL PROTECTED]Subject: Channels out of sync - MQ5.2 OS/390 I am experiencing problems with channels going out of sync on MVS. We upgraded to version 5.2 a while ago from 1.2 After coming up on the new version I had to bring the QMGR down again and started up on the old version to recover some messages and then we started up again on the new version. It looks as if the SYSTEM.CHANNEL.SYNCQ was populated with entries during this process as if gives the error message "csqx517e channel name repeated" at startup time. Now from time to time I get a message "csqx526e message sequence error" I think the only way to resolve this is to clear the SYSTEM.CHANNEL.SYNCQ on mvs and reset the sequence numbers on the distributed QMGR's. I need to know if I can do this and if anybody agrees that this could be the problem since there are definitely duplicates in the SYSTEM.CHANNEL.SYNCQ Is it save to do this. Any help will be appreciated. Thank you Pieter VogesMQ SupportNedcor Bank LimitedTel: (011) 881 4410Sel: 083 6455 300E-mail: [EMAIL PROTECTED] http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter
Re: Failover Logic to secondary QM in JAVA
Peter - You might want to consider your question from the other angle - what reason codes, returned from the MQCONN call, are acceptable to use the queue manager you are attempting to connect to. The answer, of course, is (MQRC-NONE) and possibly 2002 (MQRC-ALREADY-CONNECTED). In all other cases you will not get back a valid hConn so you cannot use this queue manager. That's the time to try the secondary queue manager. - Steve Gies -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:Peter.Potkay;THEHARTFORD.COM] Sent: Wednesday, October 23, 2002 11:01 AM To: [EMAIL PROTECTED] Subject: Failover Logic to secondary QM in JAVA I am trying to code some logic that will automatically attempt to connect to a secondary server/queue manager should the first become unavailable. The question is, what error codes should this method check for that would indicate a queue manager being unavailable? So far, I think 2009 (MQRC_CONNECTION_ERROR), 2059 (MQRC_Q_MGR_NOT_AVAILABLE), 2161 (MQRC_Q_MGR_QUIESCING), 2162 (MQRC_Q_MGR_STOPPING) will cover it. Am I missing any that should be added to this method? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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. 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: Support Pack IC01
This is another victim of CSD03. I got the following reply from IBM Support: There is a known issue with supportpac IC01 at CSD03; this is being addressed by apar IC34712. The fix for the problem is inclusion of the connector.jar file path in the classpath variable of the following bat files: 1. mqsideploy 2. mqsideletemsgset 3. mqsiimportmsgflows 4. mqsiexportmsgflows 5. mqsiassign - The workaround for all of the above is the same - The remaining bat files (viz mqsifiltermsgflows.bat and mqsicombinemsgf .bat) do not require this fix. -- I added the connector.jar class to the above bat files and it did resolve the problem. - Steve Gies -Original Message- From: Robert Broderick [mailto:robertbroderick;HOTMAIL.COM] Sent: Tuesday, October 22, 2002 5:18 AM To: [EMAIL PROTECTED] Subject: Support Pack IC01 I am trying to execute the MF import utility in IC01 as follows and getting the following error: C:\Program Files\IBM\WebSphere MQ Integrator 2.1\Toolmqsiimportmsgflows.bat Exception in thread main java.lang.NoClassDefFoundError: com/ibm/broker/config /util/ImportMsgFlows As you see I am in the Tools directory and have place the jar file there. I am gettng this now and prior to modifying the Classpath statement to point directly to the files as shown n the following: set IMF_CLASSPATH=.;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\Tool;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\com.ibm.mq.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\jfaceall.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\swingall.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\xml4j.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\broker.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\config.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\argo.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\classes\webdav.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\lib;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\lib\rt.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\lib\math.jar;C:\Program Files\IBM\WebSphere MQ Integrator 2.1\lib\i18n.jar;%classpath% java -cp %IMF_CLASSPATH% com.ibm.broker.config.util.ImportMsgFlows %1 %2 %3 goto end I believe there is something missing frome the CP. Anybody got a suggestion? _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.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 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: ASCII to EBCIDIC Conversion
David - This is correct. The MQMessage class Write* methods provide support for data-conversion while the native MQPUT api call does not. This primarily to support the conversion from Unicode (required by the ActiveX Classes) to the native code page of the queue manager. However, as you've discovered, you can trick the classes into converting the data into whatever codepage you desire simply by overriding the CCSID. Of course the Read* methods provide this same data conversion, over and above the data conversion provide by the MQGET call. Back to your problem, assuming that your mainframe browse utility does not support data conversion (i.e. uses the MQGMO_CONVERT option) then you could always set up a special channel that does has data conversion turned on. The just direct these test messages across the channel with conversion enabled. However, I think a better solution might be to modify your browse utility to support data conversion. - Steve Gies -Original Message- From: David Thomas [mailto:davidthomas;CHUBB.COM] Sent: Tuesday, October 22, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: Re: ASCII to EBCIDIC Conversion The WriteString method ( Msg. Obj. ) supports conversion from Unicode to certain code pages, using conversion tables that come with MQAX. Evidently these tables are not available to the traditional MQI. Miller, Dennis [EMAIL PROTECTED]@AKH-Wien.AC.AT on 10/22/2002 04:14:40 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: ASCII to EBCIDIC Conversion You cannot get data conversion on a put. On a put, md.ccsid simply describes the message. If you use 37, the result is NOT a message in ccsid 37; you are just saying the message is already in code set 37. Since MVS wants it in code set 37, no conversion is necessary and none is performed. So, use the CCSID of the client; usually it's best to simply let it default to the CCSID of the platform. The puzzle to me, is how you got it to work with ActiveX. Perhaps Activex is smart enough to prevent you from making that mistake. -Original Message- From: David Thomas [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, October 22, 2002 12:29 PM To: [EMAIL PROTECTED] Subject: ASCII to EBCIDIC Conversion When I run VB6 with MQAX and the MQSeries 5.1 Client I convert message data via the PUT by simply specifying a format type of MQFMT_STRING and setting the CharacterSet to 37. The QMgr runs on a Mainframe, the VB/MQAX application runs on my PC. However, when I try to run VB6 with regular MQI ( i.e. MQCONN, MQOPEN, MQPUT, etc. ) I am not able to convert the data to EBCIDIC. When I view it on the mainframe it is still in the original ASCII format. I've compared my MessageDescriptor for both kinds of messages ( ActiveX and Regular MQI ) and they have the same Encoding, CCSI, and Format. What am I missing ? 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: Triggered queues on IMS - Many queues to one process definiti on
Hi Peter - Option 3 is your answer. Q1 and Q2 will trigger independent of each other. The fact that they use the same process definition, and therefore trigger the same transaction is immaterial. As far as processing the transaction is concerned, if the tran is defined to multiple message regions, then you can have 2 instances of your tran going at the same time, one for Q1 the other for Q2. Even without multiple regions, you should at least be able to take advantage of quick-reschedule, so the second tran will process without having to unload/reload the PSB in the region. - Steve Gies -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:Peter.Potkay;THEHARTFORD.COM] Sent: Thursday, October 17, 2002 9:56 AM To: [EMAIL PROTECTED] Subject: Triggered queues on IMS - Many queues to one process definition What happens if you have 2 queues (different names) on the same queue manager that both refer to the same process definition? Let's say Q1 starts the day off with the first message and triggers TCODE ABC. Before this TCODE has a chance to process the message and end another message lands on Q2. What happens? This second message will not trigger anything, because the TCODE is already running. -Or- This second message will cause the QM to generate a trigger message to the INIT queue, where it will sit until the TCODE ends, at which point the Trigger monitor will read the INIT queue and create the IMS message to start the TCODE again. -Or- The message landing on Q2 triggers normally (assuming Q2 is closed) regardless of what Q1 may have started. The QM generates the trigger message, the trigger monitor immediately reads it and generates the IMS message to the IMS queue, where IMS will automatically restart the TCODE when it ends from the Q1 trigger. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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. 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: Starting channel as a service on Windows NT/2000
Yes, of course your application folks won't trust the opinions of the MQSeries experts within their own company (or consultants that their company as hired). But strangers off the Internet - they must know what their talking about!!! Big Grin - Steve -Original Message-From: Michael F Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 02, 2002 8:07 PMTo: [EMAIL PROTECTED]Subject: Re: Starting channel as a service on Windows NT/2000Thanks Adi, Nikhil, Steve, T. Rob, I realize all these things but it's good to hear it from other people as reinforcement. It also give me ammunition to show proof that the concept being used is wrong. Many of the people I am dealing with are difficult to convince that there are better ways to do things. We are working to implement BMC Patrol for monitoring but it is a ways off from full implementation so the appl groups are looking for things to monitor. I just need to get them monitoring the right things. Thanks for the help.Mike MurphySr. Middleware ConsultantMQ Solutions, LLChttp://www.mqsolutions.comAdiraju S Rao [EMAIL PROTECTED] wrote: Date Recieved: 10/02/2002 07:02:25 PM To: [EMAIL PROTECTED] cc: Bcc Subject: Re: Starting channel as a service on Windows NT/2000Mike,We had a similar experience in one of our projects saying that they want to usesnap-in to even monitor the channel and even implemented in the testenvironment, but when we had the exact same issue of the snap-in service ofchannel going to "stopped " status, I explained to them indicating that thisstatus will not necessarily mean having a problem and infact I asked theapplication team to send a message and the channel started and the message isprocessed successfully. At this point the channel is running but the snap-inservice shows still "stopped". After showing this they are convinced andagreed to remove that as service.There are lot of monitoring tools out in the market to monitor MQ which can beused and also can send automatic pages, so i guess the right approach would beto educate your sysadmin about the pro's and con's of this implementation, ifthey still want to use this the pages should go to them.Hope this helps.AdiFrom: "Michael F Murphy/AZ/US/MQSolutions" [EMAIL PROTECTED] @AKH-Wien.AC.AT on 10/01/2002 08:01 PM CSTPlease respond to "MQSeries List" [EMAIL PROTECTED]Sent by:"MQSeries List" [EMAIL PROTECTED]To: [EMAIL PROTECTED]cc:Subject:Starting channel as a service on Windows NT/2000I am facing an interesting issue regarding how channels are started and howsystem administrators and application developers perceive MQSeries to be"running." I would like to know of any experience, good or bad, you have hadwith running channels this way and your opinion overall.First - there are a large number of Windows NT and 2000 machines running eitherMQ 5.1 or 5.2. They have sender channels that are triggered with a disconnectinterval of 1200. They process large volumes of data so the channels run mostof the time. The interesting part is the sender channels are also set up torun as a service in the MQSeries Services snap-in. I have actually never seenthis before since triggering of channels is pretty much a best practice andthis sort of thing is not needed. The snap-in has the menu item to add thechannel as a service so it must be supported. However, this seems to only beappropriate if the disconnect interval is set to 0. The way it is set up, thechannel starts as a service initially, but then when the disconnect intervalexpires, the channel goes inactive and the services enters a "stopped" status.Then when the channel gets triggered it starts just fine, but the service stillindicates stopped. I also found that sometimes if I try to start the channelas a service again, amqmsvrn.exe crashes. This is expected behavior, but itconfuses the sys admins.Now the interesting part. The application developers and sys admins believeMQSeries to be channels and so monitoring channels is how they check the healthof MQSeries. The problem is when they see this "service" stopped they believethere is a problem and page support. I have recommended the practice ofstarting the channels as a service be stopped and the services deleted from thequeue managers in the snap-in. This is a real big deal so it must be backed upreally well. This is going to require lots of education too which I am veryhappy to supply. I just need a little more evidence to prove this practice isnot a best practice and should be stopped. If anyone has any advice, I wouldlove to here it.Sorry for not participating so much in the list over the last year.Mike MurphySr. Middleware ConsultantMQ Solutions,
Re: Starting channel as a service on Windows NT/2000
Your thoughts are correct. When the queue manager restarts, MQSeries scans any queues that have message in them (persistent messages of course) and checks to see if the queue is triggered. If it is, then a trigger message is sent to the initiation queue. This is true for all triggered queues (at least queues triggers on FIRST - I'd have to check the manuals to see when EVERY and DEPTH do). So, if your xmit queues are set up with triggering, then the chinit will get the trigger message to start the channel if messages are on the queue. - Steve -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 4:56 AM To: [EMAIL PROTECTED] Subject: Re: Starting channel as a service on Windows NT/2000 I always thought that when a queue manager came back up the triggers were reset when the Trigger Monitors came back up. The Chin being a Trigger monitor I thought that held true for it also. I don't recall running into this situation of channels not starting when messages were left on the transmit queue when the QMGR went down. I thought that was the whole idea behind MQ. Maybe that situation is true if you do not use triggering for your channels. bobbee From: Samadder, Nikhil [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Starting channel as a service on Windows NT/2000 Date: Thu, 3 Oct 2002 09:12:18 +1000 In add to the below reply, the purpose of adding channel in the MQSeries Service panel is not for only start or stop channel. One of the main reason is to start channel automatically at the restart of QMGR when existing trigger settings does not start a channel. For example, if you have a queue with a trigger setup first. Now, for any reason QMGR is bounced with some messages in the queue. When the QMGR is back and running, channel won't start by trigger unless a new message comes in. In such a situation, if the channel is in the service and set to automatic, the channel will start. This channel service should not be monitored for QMGR health check. Regards, Nikhil Samadder Australia Post -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 2 October 2002 2:34 PM Subject: Re: Starting channel as a service on Windows NT/2000 Mike, The whole point of asynchronicity is that the communication can be down without affecting the interface between the app and the QMgr. MQ is supposed to provide reliable messaging over unreliable transport and the mechanisms that allow a channel to quiesce are a large part of how that goal is accomplished. To artificially keep a channel alive as a check of QMgr health actually increases your vulnerability to such things as sequence number errors and in-doubt situations. If the connectivity goes down in the middle of the night during off-hours, you want the channels to be down so you have some assurance that they will start cleanly when connectivity is restored. Furthermore, there are dozens of ways to check that MQ is healthy that are much more accurate and reliable than looking for channel processes. You can check the actual QMgr processes rather than the channel processes if all you need to know is whether the process is alive. If you need to verify QMgr health you can query the command server, you can query runmqsc, you can put and get heartbeat messages in a local queue. If you want, you can even have a central client-based monitoring app do connect/disconnect sequences on all your QMgrs. All of these things exercise the QMgr in some way and thus provide better confirmation of QMgr health than simple existence of a process. Finally, if you are specifically worried about round-trip connectivity, you can test for the presence of messages on the XMitQ, or run a loopback message to the adjacent node and back. These things will give a better idea of what is happening with the channel than you can get by testing for process existence. The ability of channels to quiesce is one of MQ's advantages. People who treat it as a weakness don't get it IMHO. My USD$0.02, for what it's worth. -- T.Rob -Original Message- From: Michael F Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 10:01 PM To: [EMAIL PROTECTED] Subject: Starting channel as a service on Windows NT/2000 I am facing an interesting issue regarding how channels are started and how system administrators and application developers perceive MQSeries to be running. I would like to know of any experience, good or bad, you have had with running channels this way and your opinion overall. First - there are a large number of Windows NT and 2000 machines running either MQ 5.1 or 5.2. They have sender channels that are triggered with a disconnect interval of 1200. They process large volumes of data so the channels run most of the time. The interesting part is the sender channels are also set
Re: Starting channel as a service on Windows NT/2000
Title: Message Mike - We've never added the channels as their own service under the snap-in, just the channel initiator (which of course is added via the install of MQ). All of our channels are triggered via the transmission queue. This works just fine. Inactive channels start when messages arrive. Channels restart automatically after network outages (as provided by the short and long retry intervals). If messages are in a transmit queue when the queue manager is stopped then the channel is started when the queue manager restarts (standard triggering behavior). To monitor the "health" of our channels we actually monitor the transmit queues. If the depth is greater than 0 and the Input Open Count = 0, then we know we have a problem (of course it is almost always with the network not MQ itself!!). Hope this helps to justify changing your system. - Steve Gies SAFECO Insurance -Original Message-From: Michael F Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 7:01 PMTo: [EMAIL PROTECTED]Subject: Starting channel as a service on Windows NT/2000I am facing an interesting issue regarding how channels are started and how system administrators and application developers perceive MQSeries to be "running." I would like to know of any experience, good or bad, you have had with running channels this way and your opinion overall. First - there are a large number of Windows NT and 2000 machines running either MQ 5.1 or 5.2. They have sender channels that are triggered with a disconnect interval of 1200. They process large volumes of data so the channels run most of the time. The interesting part is the sender channels are also set up to run as a service in the MQSeries Services snap-in. I have actually never seen this before since triggering of channels is pretty much a best practice and this sort of thing is not needed. The snap-in has the menu item to add the channel as a service so it must be supported. However, this seems to only be appropriate if the disconnect interval is set to 0. The way it is set up, the channel starts as a service initially, but then when the disconnect interval expires, the channel goes inactive and the services enters a "stopped" status. Then when the channel gets triggered it starts just fine, but the service still indicates stopped. I also found that sometimes if I try to start the channel as a service again, amqmsvrn.exe crashes. This is expected behavior, but it confuses the sys admins. Now the interesting part. The application developers and sys admins believe MQSeries to be channels and so monitoring channels is how they check the health of MQSeries. The problem is when they see this "service" stopped they believe there is a problem and page support. I have recommended the practice of starting the channels as a service be stopped and the services deleted from the queue managers in the snap-in. This is a real big deal so it must be backed up really well. This is going to require lots of education too which I am very happy to supply. I just need a little more evidence to prove this practice is not a best practice and should be stopped. If anyone has any advice, I would love to here it. Sorry for not participating so much in the list over the last year.Mike MurphySr. Middleware ConsultantMQ Solutions, LLChttp://www.mqsolutions.com
Oldest media log not advancing with rcdmqimg
Hello Listers - I've come across a problem this morning that I'm hoping someone can shed some light on. We have a test server that has three queue managers installed that all use linear logging. The server is WinNT V4 SP6a and MQSeries is V5.2 w/ CSD03 installed. Every night we run a job that issues a rcdmqimg against each queue manager and then runs a utility to clean up log files that are no longer needed. The utility makes this determination by looking at what is the oldest log required for media recovery. This morning we started getting alerts that we were running low on disk space on the logging drive. What I discovered is that for one of the queue managers, the oldest log needed for media recovery was from several months ago. I've tried manually running the rcdmqimg command and have checked the output for errors - thinking that we might have some queue that was causing an error - but I could not find anything. Now I'm stumped. Has anyone else run into a similar issue? If so, were you able to resolve it? Steve Gies SAFECO Insurance MQSeries Technical Support 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: C++ Foundation Classes
Title: C++ Foundation Classes Pieter - No, if connectively is lost sometime between the internal MQCONN call and the MQPUT call, you will get back an appropriate error message - 2002? - but the classes will not attempt to redrive the put call. - Steve -Original Message-From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 13, 2002 10:45 PMTo: [EMAIL PROTECTED]Subject: C++ Foundation Classes Hi Everyone I got an interesting question from the development team. It comes down to an application running on a Nt Box written in C++ using the mq-client libraries connecting to a QMGR on a Unix AIX Box. The question is whether or not there are build-in error handling in the C++ Foundation classes to cater for loss of connectivity (either network or the QMGR going down). Example - if you do a put to a queue on a qmgr which the client lost connectivity to, will this be handled automatically or will he keep on trying to put infinitaly regardless of the lost connectivity. (Will the classes try to restore the connectivity and how?) Any info will be appreciated Pieter Voges MQ Support Nedcor Bank Limited -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED]] Sent: 13 August 2002 02:11 To: [EMAIL PROTECTED] Subject: Re: Channel that always stays running Can I add my two cents worth about Heartbeats. There have been one or two slightly misleading comments about them which I think I ought to address. Heartbeats serve at least three purposes. 1/ They maintain contact with the receiver channel even when there are no messages to send. This allows the receiver channel to ask the sender channel to end (for example a STOP CHANNEL MODE(QUIESCE). So, if you issued a normal quiesce stop channel on a receiver and the channel wasn't moving any messages it may take up to the heartbeat interval before the channel actually ended. 2/ Since a heartbeat is only sent in relative inactivity the receiver channel will free its resources when it gets one. For example it will free off any excessive message storage and close its queue cache. 3/ It allows the receiver to predict when data should arrive down the socket. This is most pertinent to the current discussion of network outage. Without heartbeats a receiver channel can not predict when the next message will arrive from the sender since the sender has no clue either. However, with heartbeats enabled the receiver knows that either it will receive a heartbeat or a message within a known interval. Consequently the recveiver can issue a receiver with a timeout. If this receive does time out it means that something has gone seriously wrong. In an ideal world a network outage would cause the TCP/IP recv() call to return a nice return code however, as we all know, TCP/IP is notoriously bad at telling us about outages so this timeout is probably our best defence. I would still recommend that people use KEEPALIVE though since there are some cases, such as SVRCONN channels, where we can't use a timeout. One last point about the timeout. The timeout value used will be if (Heartbeat Value 1 minute) Timeout = Heartbeat * 2 else Timeout = Heartbeat + 1 minute In other words we add a little contingency on the timeout for network latency. Heop this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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: How to detect client connection
Jessie - I had this problem once. The only way that I could think of to find out who was attempting to make the connection was to actually create the server-conn channel with a security exit that logged the attributes from the Channel Descriptor. It also denied the connection. - Steve Gies -Original Message- From: Jessie Yau [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 10:01 AM To: [EMAIL PROTECTED] Subject: How to detect client connection Hi, How to detect which clients are connecting to QM with invalid channel name ? I'm currently getting +CSQX519E +T CSQXRESP Channel CLIENT.TO.MQSP not defined error and no one is admitted to this problem. Is there a way to track down ip address who tried to connect but failed ? Or any idea how to troubleshoot ? Thanks, Jessie Yau The Capital Group Companies, Inc. 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: How to prepare IMS message using c++
Title: Message It appears that you are using the MQSeries C++ Classes as well. There is a class the encapsulates the IIH called ImqIMSBridgeHeader. Since this is derived from the ImqHeader class, which is derived from the ImqItem class, you can use the WriteItem method to add the header to your messages. pseudo-code: ImqMessage putMsg; ImqIMSBridgeHeader imsHeader; ' first add your IMS Var String data to the message buffer and set the format accordingly. putMsg.write( 2, LLvalue ); putMsg.write( 2, ZZvalue ); putMsg.write( len, imsdata ); putMsg.setFormat( MQFMT_IMS_VAR_STRING ); ' next, set the parms in your IIH imsHeader.setLTermOverride( "B12345"); ' now use the writeItem method, this will place the MQIIH structure IN FRONT of the existing ' data, move the existing message format, CCS, and encoding values into the IIH structure, ' and set the MQMD.Format field to MQFMT_IMS. putMsg.writeItem( imsHeader ); - Steve -Original Message-From: jayaprakash reddy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 5:50 AMTo: [EMAIL PROTECTED]Subject: How to prepare IMS message using c++ Hi All, I am trying to prepare a IMS message by setting the message format as MQFMT_IMS. When i set the message format to MQFMT_IMS i have to prepare the MQIIH header and when i set the message length i have to add the MQIIH header length plus transaction code plus actual data length then only i am able to put the message successfully with MQFMT_IMS. Here my question is if i set like this in the queue that message length attribute shows the length as whatever i set(MQIIHJ_transactioncode+ actaul lengtgh) but accorsding to my knowledge it should show only the actaul data length plus the transactioncode. So how do i achieve it? am i going in the correect direction for preparing IMS message? I am pasting my code snippet below I am using c++ as the developement language on WindowsNT MQSeries version is 5.2nb sp; /***/ ImqMsg putMsg; MQIIH l_iihHdr; putMsg.setFormat( MQFMT_IMS ); memcpy(msgBuffer,l_iihHdr,sizeof(l_iihHdr));//copying MQIIH header memcpy(msgBuffer+sizeof(l_iihHdr),"LLZZ",4);//setting transaction code memcpy(msgBuffer+sizeof(l_iihHdr)+4,argv[4],strlen(argv[4]));//setting actual data putMsg.setMessageLength(4+sizeof(l_iihHdr)+strlen(argv[4])); /***/ Thanks in advance J'Prakash. Do You Yahoo!?Sign-up for Video Highlights of 2002 FIFA World Cup
Re: Win/2K QMGR problem
Rick - Actually, you can use the MQ Service snap-in remotely. From the MQ Service MMC console on your PC (or any MMC console) select Console | Add/Remove Snap-In... On the Add/Remove Snap-in dialog box click the Add button and then select the MQSeries Services snap-in from the list. It will prompt you for a server name. Put in the name of the server you wish to administer (or leave it blank if you want a snap-in for the local server). You can now use the snap-in just as if you were logged on locally to the box. This, of course, assumes you have the appropriate permissions. If you admin several MQ servers, you can build a custom MMC console with a snap-in for each server. Save it under a different name and then create a shortcut to the mmc file. When you need to stop or start a queue manager, just pull up this console and go right to the one you want. You can also do this for the MQ Explorer snap-in as well. - Steve Gies -Original Message- From: Rick Tiedemann/Ontario/IBM [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 7:35 AM To: [EMAIL PROTECTED] Subject: Re: Win/2K QMGR problem Reinstalling via an admin id will definitely let you use traditional commands and also use MQ Explorer. I am not sure what results you will have via Terminal Server. I guess you will have to try it out and see. I use PC Anywhere to access these servers remotely but terminal server would be much better if it works. I also use MMC fro my PC and remotely administer queue managers on these servers (e.g. starting stopping channels and administering queues) but you cannot stop and start queue managers in this way. Rick Tiedemann IBM Global Services [EMAIL PROTECTED] (519) 747-7000 x37301 Mabrito, Greg Greg.Mabrito@USATo: [EMAIL PROTECTED] A.COM cc: Sent by: MQSeriesSubject: Re: Win/2K QMGR problem List MQSERIES@AKH-WIE N.AC.AT 06/06/2002 10:11 AM Please respond to MQSeries List I am currently struggling with this now. I did install MQ locally but not with a admin id and I can only access the queue manager via MMC Explorer, this is still not satisfactory I like to run my scripts via runmqsc on the box. When I connect to the queue manager via terminal server I still get the queue manager not available. Rick are you saying that buy me reinstalling using an Admin id that this will run the queue manager in a global namespace and it will work through terminal server ? Greg Mabrito IMS and MQ Software Support (210)913-3985 D-03-E IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. -Original Message- From: Rick Tiedemann/Ontario/IBM [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 8:42 AM To: [EMAIL PROTECTED] Subject: Re: Win/2K QMGR problem Did you install MQ and MMC under an administrator id, did you use Microsoft Terminal Server ?. I originally installed MQSeries using Terminal Server and experienced the same problems. IBM does not support Terminal server so once I re-installed MQ Series from a administrator id everything was fine. Rick Tiedemann IBM Global Services [EMAIL PROTECTED] (519) 747-7000 x37301 Rick Tsujimoto rtsujimoto_consultant@CUSATo: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Win/2K QMGR problem [EMAIL PROTECTED] 06/05/2002 11:35 AM Please respond to MQSeries List I have a strange one here. Installed MQ/Win2K V5.2.1 with CSD4. I can create a qmgr via MQ Explorer and it starts up, turns green, and all the other services, e.g. listener, also start. But, the status of the qmgr is not connected as per the properties report. A normal qmgr would have additional levels to navigate under the qmgr icon, e.g. a plus sign, but not in my case. Any attempt to issue a connect for the qmgr results in message AMQ4043 - MQ Explorer thinks the qmgr is not running. There are no unusal messages in the event viewer, or the MQ error logs. I can create the qmgr via the command line and access it. But, MQ Explorer has a strange view of it, e.g. instead of the green icon, it shows a hatch-like icon and is basically not accessible. I've installed the same software on another Win2K box without any problems. Anyone see anything like this? 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
Re: Win/2K QMGR problem
Rick - It sounds like you are logged onto your Win2K server via Terminal Services. When you do this, you can use the MQ Services MMC as normal, but to use the MQ Explorer MMC you must connect to the queue manager as a client. (Right click Queue Managers, select Show Queue Manager ..., select the Show a remote queue manager option and fill in the appropriate values. Also, when you create the queue manager you need to indicate that you want the ability to administer it remotely. - Steve Gies -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 8:35 AM To: [EMAIL PROTECTED] Subject: Win/2K QMGR problem I have a strange one here. Installed MQ/Win2K V5.2.1 with CSD4. I can create a qmgr via MQ Explorer and it starts up, turns green, and all the other services, e.g. listener, also start. But, the status of the qmgr is not connected as per the properties report. A normal qmgr would have additional levels to navigate under the qmgr icon, e.g. a plus sign, but not in my case. Any attempt to issue a connect for the qmgr results in message AMQ4043 - MQ Explorer thinks the qmgr is not running. There are no unusal messages in the event viewer, or the MQ error logs. I can create the qmgr via the command line and access it. But, MQ Explorer has a strange view of it, e.g. instead of the green icon, it shows a hatch-like icon and is basically not accessible. I've installed the same software on another Win2K box without any problems. Anyone see anything like this? 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: MQSI - Exporting/Importing Message Flows
Tony - Check out support pac IC01. It provides a batch command for exporting and importing message flows in WMQI V2.1. - Steve -Original Message- From: Tony Devitt [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 10:07 PM To: [EMAIL PROTECTED] Subject: MQSI - Exporting/Importing Message Flows I know this question has been raised before but have there been any indications that batch commands to export/import message flows (similar to the message set commands) will eventually be made available for the product? I hoped they might be in V2.1 but see no signs in the Admin manual. Alternatively, has anyone gone to the trouble of developing their own utility to do this? 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: ActiveX Object in VB
Joshi - Couple of things. First, by not setting the mqgmo.Options = MQGMO_BROWSE_NEXT anymore you are doing destructive gets against your queue not browse gets. Secondly, you are checking the CompletionCode of your mqgmo object. I think you want to check the mqq object. This is the object that will contain the CC from the get method. - Steve -Original Message- From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 12:08 PM To: [EMAIL PROTECTED] Subject: Re: ActiveX Object in VB I was getting MQ Error. MQRC_NO_MSG_AVAILABLE. I modified the code to set the MatchOption. Now I do not get error but only first 3 iterations bring in distinct message IDs. From there, I keep getting third message in an infinite loop. Thanks for help. Code Begin Done = False Set mqmsg = Nothing Set mqgmo = Nothing Set mqmsg = New MQMessage Set mqgmo = New MQGetMessageOptions mqgmo.MatchOptions = MQMO_NONE Do mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.MessageId 'lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If mqmsg.MessageId = mqgmo.ClearErrorCodes Loop Until Done == Code End -Original Message- From: Ryan Parmenter [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 3:03 PM To: [EMAIL PROTECTED] Subject: Re: ActiveX Object in VB What error are you getting? Is it a VB error or an MQ error? Ryan [EMAIL PROTECTED] 05/30/02 10:11AM Hi I'm trying to display list of messages with their PutDateTime in a List Box in VB using following code. Code Begin Do If Counter = 0 Then mqgmo.Options = MQGMO_BROWSE_FIRST Else mqgmo.Options = MQGMO_BROWSE_NEXT End If mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If Loop Until Done Code End However, I get error when loop iterates second time. PutDateTime of first message is read correctly. Any ideas? Thanks in Advance == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == 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 == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == 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
