ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ API SupportAMI Limitations

Post new topicReply to topic
AMI Limitations View previous topic :: View next topic
Author Message
stapod
PostPosted: Wed Jun 27, 2001 6:39 am Post subject: Reply with quote

Newbie

Joined: 25 Jun 2001
Posts: 1

I understand that AMI has certain restrictions in flexibility compared to
the MQI. Where are these limitations documented ?
I noticed when using the AMI Administration Tool (part of SupportPac MAOG) that there is no scope in the policy to define the ReplyToQ. Is this a limitation of AMI or can you create a new DTD and XML file to include a tag for ReplyTOQ or any other MQMD field ?

David Stapleton
_________________


[ This Message was edited by: stapod on 2001-06-27 07:41 ]
Back to top
View user's profile Send private message Visit poster's website
RichArnfield
PostPosted: Thu Jun 28, 2001 3:18 am Post subject: Reply with quote

Newbie

Joined: 24 May 2001
Posts: 4
Location: Currently London, soon Frankfurt

Hi David,

The way to do this requires a number of steps.

- If you are requesting a system generated response (eg. COD,COA) ensure that the policy you are using has the 'sender' section set to request whichever reply you are looking for.

- Set up a receiver service referring to the queue you wish to be the reply to queue

- Specify the 'ReplyTo' receiver service from the last step in the Send call.

I don't know which language you are programming in, but in the C Object Interface the amSndSend call allows you to specify the handle of a receiver service to use as the reply to queue. I should imagine the concept is similar for the other languages.

If your application is not requesting a system generated response, but is expecting the receiving app. to send a response, the receiving app can get the handle of the sender service to which it should place its reply from the amRcvReceive call - again in the C Object Interface.

HTH

Rich

_________________
Rich Arnfield, Castlemay Ltd.
Certified MQSeries Solutions Expert
Back to top
View user's profile Send private message Send e-mail
NWoodcock
PostPosted: Fri Sep 21, 2001 8:18 am Post subject: Reply with quote

Newbie

Joined: 20 Sep 2001
Posts: 3

I need to choose whether to use the AMI API or one of the lower level APIs (MQI etc). I am attracted to the API, but perceive the following limitations:
1. Cannot pass MQMD context info (UserIdentifier, PutApplName, ApplOriginData) with a message put using amSendMsg. Security implications?
2. Not possible to specify one policy when initialising a session, but one or more different policies when doing subsequent message puts. (Strange, since both amInitialize and amSendMsg allow you to specify a policy name, but the latter seems to have no effect). Therefore all messages to a queue are subject to same policy: cannot overide default queue priority for example.
3. I can find little help on how to use policy handlers - sample code etc.

Can anyone confirm whether these are genuine limitations, or just down to my ignorance? If the latter, can anyone explain how to deal with these issues?
Many thanks - Neil
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ API SupportAMI Limitations
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.