| Author |
Message
|
| MartyD |
 Posted: Mon Nov 11, 2002 12:32 pm Post subject: EBCDIC to ASCII Conversion Problem |
 |
|
Newbie
Joined: 21 Aug 2002
Posts: 7
|
| Is anyone else having a problem converting from EBCDIC to ASCII using this assembly? I've verified that the incoming message format is set to MQFMT_STRING ("MQSTR ") and my GMO is set to MQGMO_CONVERT but the message is not converted. I'm out of ideas and about ready to write a convert class. Any other ideas? Thanks in advance. |
|
| Back to top |
|
 |
| DanielEWalls |
| Posted: Tue Nov 12, 2002 6:19 am Post subject: |
|
|
Newbie
Joined: 17 Oct 2002
Posts: 3
|
Yes I am have the same issue. I can put and get messages off the queues using .NET classes and read the data. However if I actually do a complete cycle of put, and then a get after the host done its work I cannot read the message after the 1st several characters.
The same puts and gets work using VB6 wrappers and also the MQ java classes, but not these .NET classes. Can even put messages on the queue with the java and VB6 and get them off and read them with the .NET classes, but again when a complete cycle is done cannot read the message.
Have tried many combinations of the options, but with no luck. then onyl thing I see that is different is that the VB6 and Java seem to have a base configuration for MQ that then can be overidden by setting different options. Maybe there is something in the .NET classes that is not being set in the base configuration? |
|
| Back to top |
|
|
| pound23 |
| Posted: Thu Mar 06, 2003 8:34 am Post subject: Explicit connection/channel ????? |
|
|
Newbie
Joined: 06 Mar 2003
Posts: 1
|
All this strikes me as relatively useless until support for explicit channels/connections is supported.
Does the library support this?
If not when will it?
From the docs:
There are two ways to connect to an MQSeries server as a client.
The first is to specify an explicit channel and connName. In this case, an explicit connection will be formed to the named queue manager.
The second mechanism is to specify null as the channel or connName. In this instance, either the MQSERVER environment variable or the AMQCHLTAB will be used. Currently, the explicit specification of a connName and channel are not supported. This will be remedied in a subsequent release. |
|
| Back to top |
|
|
| donavon |
| Posted: Tue Mar 11, 2003 10:23 am Post subject: missing MQMessage Properties |
|
|
Newbie
Joined: 11 Mar 2003
Posts: 2
|
I know someone asked this a while ago, but I have not seen a reply as of yet. Are there plans to impliment some of the missing MQMessage properties? My application needs access to UserIdentifier, AccountingToken, PutApplName and GroupId.
Other than that I LOVE IT!
Thanks Neil!
Also, is there ANY activity with MQSeries.NET? I read that IBM was watching. What is the scoop there? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Mar 11, 2003 10:19 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| thaco |
| Posted: Wed Mar 12, 2003 5:57 am Post subject: Re: EBCDIC to ASCII Conversion Problem |
|
|
Newbie
Joined: 12 Mar 2003
Posts: 6
|
| MartyD wrote: |
| Is anyone else having a problem converting from EBCDIC to ASCII using this assembly? I've verified that the incoming message format is set to MQFMT_STRING ("MQSTR ") and my GMO is set to MQGMO_CONVERT but the message is not converted. I'm out of ideas and about ready to write a convert class. Any other ideas? Thanks in advance. |
I have experienced the same, but have concluded that the problem is not due to converting issues. To me it seems like the MQ .NET uses 7-bit ASCII, and thus strips off your 8-bit. You can verify this by looking at the caracters that seems not converted in your result message. Try to take its ASCII value, add by 128, and look up the resulting character...
Can anyone confirm this, that the MQ .NET only supports 7-bit characterset?
/thaco |
|
| Back to top |
|
|
| donavon |
| Posted: Wed Mar 12, 2003 6:47 am Post subject: |
|
|
Newbie
Joined: 11 Mar 2003
Posts: 2
|
Roger,
I saw this in another thread after I posted. I've already converted my code to use the new classes. Everything seems to be working fine so far. 
Thanks for the reply.
Donavon |
|
| Back to top |
|
|
| LovenDOTNET |
| Posted: Wed Mar 26, 2003 6:13 am Post subject: Living the MQ .NET Dream |
|
|
Newbie
Joined: 26 Mar 2003
Posts: 2
Location: Raleigh NC - USA
|
I would like to thank all the persons who have made the final download of ma7p.msi possible.
I have been working with Dot NET since the Microsoft PDC in OCT of 2000. The addition of Dot NET support will greatly expand the developer base for MQ Series. Reason? The object model – If a developer understand the DotNET framework - the MQ Series object model is (1)easy to understand and (2) easy to use. Sounds like IBM marketing needs to “show the flag” at Microsoft’s DotNET development event(s). Since Microsoft DotNET developers only code for the Windows platform – any Message Queuing development should be using IBM’s MQ Series. 3 cheers for all the great work accomplished. – (Now back to writing code… )
_________________
Brent Morris
MQ Series Admin
Raleigh NC - USA |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Mar 27, 2003 1:14 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Yes, we definitely need to thank Neil for all his hard work. And not just for writing the code; I know he spent a lot of time and energy convincing IBM that this was a valuable tool which should be released as a support pac. And now we finally have it!
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| hhoang |
| Posted: Thu Mar 27, 2003 8:52 am Post subject: |
|
|
Novice
Joined: 14 Nov 2002
Posts: 21
|
Hi,
Do you have any sample code for the MQQueueManager class?
MQQueueManager queueManager = new MQQueueManager(queueMgrName, channelName, connName);
I've hard time connecting to the remote MQ Series server but I don't know what wrong. I've no problems connecting it locally. I suspect that either format of connName or channelName is wrong.
Thanks,
Hai Hoang |
|
| Back to top |
|
|
| Shep |
| Posted: Mon Mar 31, 2003 11:37 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2002
Posts: 6
Location: Massachusetts
|
Hai,
What error are you getting? What environment are you running in?
I'm using the code snip below. Note the constructor I use is different...I only supply the QMName. This is running inside a windows service.
On my dev machine, this runs using the MQClient. Make sure your MQSERVER environment variable is defined correctly. This also builds and runs on the server without the MQClient. Hope this helps!
Shep
Dim oMQQueueManager As MQQueueManager '* MQQueueManager
Dim oMQQueue As MQQueue '* MQQueue instance
'Set up MQSeries objects
Try
oMQQueueManager = New MQQueueManager(Me.m_sQMName)
'open queue for output but not if MQM stopping
oMQQueue = oMQQueueManager.AccessQueue(Me.m_sOBQueueName, _ MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING)
Catch mqe As MQException
Dim oAddlInfo As New Collections.Specialized.NameValueCollection
oAddlInfo.Add("MQSeriesError", mqe.Message)
ExceptionManager.Publish(mqe)
Throw mqe
Catch ex As Exception
ExceptionManager.Publish(ex)
Throw ex
End Try |
|
| Back to top |
|
|
| dialog-it_dme |
| Posted: Fri Apr 11, 2003 12:20 am Post subject: Connect to remote QM |
|
|
Newbie
Joined: 27 Nov 2002
Posts: 8
Location: Germany
|
Hello!
First, thanx Neil for createing this assembly!
I´m quite new to MQSeries and VB.NET programming, but I´m playing around and testing a bit with your assembly.
I have MQ server 5.2 on my w2k machine and all works fine with that, but now it comes to the point whe I need to connect to a remote queue-manager.
My application should be able to run on a machine with the MQ client installed only, and connect to a remote queue manager by useing IP address and TCP/IP port-number.
Is this possible until now? I´m a little bit irritated, because I´ve read about explicitly specifying a connName is not supported in the actual version.
Any ideas or maybe sample-code?
Or hints where to look further?
Many thanx in advance,
_________________
Danyel Meyer
-------------------------------------
dialog-it GmbH
www.dialog-it.de |
|
| Back to top |
|
|
| Gallagher |
| Posted: Tue Apr 15, 2003 4:28 pm Post subject: IBM MQ.NET class samples (MA7P) won't run (Reason 2173) |
|
|
Newbie
Joined: 15 Apr 2003
Posts: 5
Location: Seattle
|
I've downloaded IBM's Websphere MQ support pack MA7P (.NET classes) from http://www-3.ibm.com/software/integration/support/supportpacs/individual/ma7p.html but after building and running the samples I get a reason 2173 code (which says the PMO structure is invalid). I'm assuming this is a version issue, meaning it is defaulting the MQPMO_CURRENT_VERSION to 2.
I have the MQ 5.3 client on WinXP and Win2K Server along with the Microsoft .Net framework sp2, and am trying to talk to a test queue that is connected to an OS/390 queue manager (v1.3).
Anyone have any ideas how to change the version? 
(I don't see anything exposed in the class properties)
_________________
-Gallagher |
|
| Back to top |
|
|
| smeyer1 |
| Posted: Wed Apr 16, 2003 12:25 pm Post subject: |
|
|
Newbie
Joined: 20 Nov 2002
Posts: 4
Location: Dallas, Texas
|
| I have the same configuration except i am getting a 2139 error. If i supply Null for channel name and connection all is well... Really would like to take advantage of the dynamic queue instead of changing environment variables and rebooting since the application runs as a service. |
|
| Back to top |
|
|
| Gallagher |
| Posted: Thu Apr 17, 2003 10:32 am Post subject: |
|
|
Newbie
Joined: 15 Apr 2003
Posts: 5
Location: Seattle
|
A reason code 2139 is similiar to the 2173 reason code that I got, in that they both refer to bad versions or structid's. In the case of 2173 this applies to the MQPMO (Put Message Options), while the 2139 applies to the MQCNO (Connect Options).
IBM's documentation has this recommendation for 2139:
-------------------------------------------------------------------
This reason code occurs in the following environments: AIX, HP-UX, Linux, z/OS, OS/2,OS/400, Solaris, Windows, plus WebSphere MQ clients connected to these systems.
Corrective action: Correct the definition of the MQCNO structure. Ensure that required input
fields are set correctly.
Unfortunately, I'm not sure how to set these fields with the MA7P .NET Classes. 
_________________
-Gallagher |
|
| Back to top |
|
|
|
|
