IBM Support

IT15971: MQ V8.0 MANAGED FILE TRANSFER AGENTS PUBLISH XML STATUS MESSAGESWITH NO FORMAT WHICH APPEAR TO JMS APPLICATIONS AS BYTESMESSAGES

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

APAR status

  • Closed as program error.

Error description

  • WebSphere MQ File Transfer Edition V7.0.x and WebSphere MQ
    Managed File Transfer V7.5 agents published XML status messages
    under the /SYSTEM.FTE topic tree with an MQMD.Format value of
    "MQSTR   ".  These messages appeared as TextMessages to JMS
    applications consuming the publications.  However, the same
    messages published by IBM MQ Managed File Transfer V8.0 or V9.0
    agents have an empty MQMD.Format value of "        " and appear
    to JMS applications as BytesMessages instead.
    

Local fix

  •   The XML messages generated by FTE and MFT are created in UTF-8
    (also known as CCSID 1208).  A JMS application which receives a
    BytesMessage from this topic tree can interpret the byte array
    from the message by passing the bytes to the String constructor
    with a charsetName argument of "UTF-8".  This tells the Java VM
    to interpret the contents of the message as a series of one- to
    four-byte UTF-8 characters.  For example, a JMS application
    could call:  String msgbody = new String(msgbytes, "UTF-8");
    .
      http://docs.oracle.com/javase/6/docs/api/java/lang/String.html
    #String(byteݨ,%20java.lang.String)
    .
    .
      Passing the byte array to the single-argument String
    constructor is incorrect, as this interprets the bytes based on
    the default Charset of the Java VM.  If the default Charset is
    "ISO-8859-1", for example, then each byte will be decoded into a
    separate character.  Two- to four-byte UTF-8 characters will be
    incorrectly interpreted as multiple characters, e.g. the bytes
    0xC3 0xA7 for 'lower-case c with cedilla' will be interpreted
    as 'capital a with tilde' followed by 'section sign' instead.
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects all the users of the:
    
     - IBM MQ Managed File Transfer (MFT) V8 component
     - IBM MQ Managed File Transfer (MFT) V9 component
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    In MQ MFT V7.5 and earlier the MFT Agents published XML Status
    messages to the SYSTEM.FTE topic in a string format
    (MQFMT_STRING).
    
    In MQ MFT V8 this was changed so that the messages were
    published with no format (MQFMT_NONE). The only exception to
    this was messages published to SYSTEM.FTE topic using the topic
    string /LOG, which were still published as String format. This
    could cause issues for applications which were processing the
    publications and were expecting messages published in String
    format. Now they are receiving messages with no format which
    meant the application wasn't able to process them.
    

Problem conclusion

  • To resolve this issue a new property has been added to the
    installation.properties file which allows users to specify the
    message publication format used by MFT agents for their status
    XML messages.
    
    The property is called "messagePublicationFormat" and it can be
    set to the following values:
    messagePublicationFormat=mixed     		- this is on by
    default and maintains the v8 behaviour (messages are published
    with no format, except those published to the SYSTEM.FTE topic
    using the topic string /LOG which will have a format of String).
    messagePublicationFormat=MQFMT_NONE		           -
    MQMD.FORMAT will be set to MQFMT_NONE
    messagePublicationFormat=MQFMT_STRING             - MQMD.FORMAT
    will be set to MQFMT_STRING
    
    Applications that previously used MQ MFT V7.5 will need to be
    updated to process messages in the new format. If it is not
    possible to change the applications, set the property to
    'string'. This will make the MQ V8 MFT (and later) component
    behave in the same way as V7.5.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v8.0       8.0.0.7
    v9.0 CD    9.0.0.2
    v9.0 LTS   9.0.0.2
    
    The latest available FTE maintenance can be obtained from
    'Fix List for WebSphere MQ File Transfer Edition 7.0'
    http://www-01.ibm.com/support/docview.wss?uid=swg27015313
    
    The latest available MQ maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
    
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT15971

  • Reported component name

    WMQ MFT V8.0

  • Reported component ID

    5724H7252

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-07-01

  • Closed date

    2017-02-10

  • Last modified date

    2017-02-10

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    WMQ MFT V8.0

  • Fixed component ID

    5724H7252

Applicable component levels

  • R800 PSY

       UP



Document information

More support for: WebSphere MQ

Software version: 8.0

Reference #: IT15971

Modified date: 10 February 2017