1 Reply Latest reply on Jan 26, 2004 11:16 AM by 102063

    How to configure MQ Adapter msgType (to MQSTR)

      We have conversion problems sending msgs from Interconnect on Wintel platform to MQ Series on AS/400
      (ASCII to EBCDIC conversion) dequeue by non JMS application.

      We try to do the converting on msg GET, but this requires a string format (format MQSTR). How do I configure the adapter (who interacts through a MQ Client installation on the same platform) to use msgType MQSTR in stead of MQHRF2?

      We have also tried to set up a MQ installation on Win2000 platform, configure Interconnect to put messages on this queue manager, and reroute to AS/400. In this scenario we configured a conversion on the channel level (Data conversion = Yes). Here the envelope format was converted (msg format was MQHRF2 , but then the format definition internally in the dataset was missing (blank). This format should be MQSTS (string format).

      By implementing this directly in Java/JMS we don't have converting problems at all as long as we use javax.jms.TextMessage and configure targetClient=1 (not JMS).
        • 1. Re: How to configure MQ Adapter msgType (to MQSTR)
          The OAI 9.0.2 MQ Series adapter is implemented based on IBM's JMS API, i.e.
          a message sent or received from a MQ Series destination (queue/topic) is
          internally stored as a JMS message, before being converted to/from an OAI
          message. Some native (C) MQ Series clients might not be prepared to
          deal with (ignore) the JMS message header, which gets written by the JMS
          In addtion to this, the MQ Series adapter always either writes (enqueues)
          TextMessage's or BytesMessage's depending on the operational mode of the
          adapter. When the adapter operates in XML mode (ota.type=XML), it always
          sends a TextMessage, while it always sends a BytesMessage when operating in
          D3L mode (ota.type=D3L) as the output from a D3L translation is always
          considered a byte stream.
          To loosen up both of these constraints, a new adapter.ini configuration
          property has been introduced:
          If this variable is assigned any value, then the sender destination
          is assumed to be non-JMS compliant and hence the adapter will force the JMS
          API not to write the JMS headers.
          If the value of this configuration property is "MQFMT_STRING" (not incl.
          the double quotes), then the adapter will always write (enqueue) the
          message as a TextMessage, even though e.g. the result of a D3L translation
          contains non-printable bytes.
          For other values of this variable, check Chapter 10. MQMD - Message
          descriptor in the MQ Series Application Programming Reference guide.
          Normally this value would specify an application/user defined format,
          (not starting with the letters "MQ") which typically at the receiving end
          mandates a data-conversion exit program (see Chapter 11 of MQ Series
          Application Programming Guide).
          Note: Data-conversion exits are not supported on MQSeries for Windows or