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

    How to configure MQ Adapter msgType (to MQSTR)

    102063
      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)
          102063
          ~~~~~~~~~~~
          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
          implementation.
          .
          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:
          .
          mq.default.sender.mqfmt=
          .
          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
          VSE/ESA.