Attachment Layout for Websphere MQ and MSMQ

Attachments are made up of multiple physical messages. The beginning of an attachment is recognized by possessing a message type of 100000. To identify this message, it will be referred to as the attachment header.

Layout of an attachment header message:

Note: All character strings are null terminated.

   byte[24] - header correlid (correlationid of this header 
                 message)
   long     - original msg type (msg type provided by the 
                 sending application)
   byte[24] - original msg correlid (msg correlationid 
                 provided by the sending application)
   byte[24] - message correlid (generated correlationid for 
                 the msg)
   int      - number of attachments
   --------------------------------------------------------
   int      - attachment type
          1 - SAS Dataset
          2 - External text file
          3 - External binary file
   byte[24] - attachment correlid (correlationid associated 
                 with this attachment)
   int      - length of qualifier 1
   char[]   - qualifier 1
              external files: designates the sending file 
                 specification "FILENAME" or "FILEREF"
              dataset: designates the sending library name
   int      - length of qualifier 2
   char[]   - qualifier 2
              external files: designates the sending 
                 filename or fileref
              dataset: designates the sending member name
   int      - length of attachment description
   char[]   - attachment description
   int      - user specified minor version number
   int      - user specified major version number
   --------------------------------------------------------
   .
   .
   . repeat for each attachment in the list

Other physical messages are also needed to make up a complete attachment. These messages will be called subordinated messages and they all possess a message type of 100001.

The subordinate message that usually follows after the attachment header message is the application message. It can be filtered using the message correlid located in the attachment header message. It contains the actual application generated message.

The attachment (external file or SAS data set) subordinate messages follow next. They contain the necessary information to recreate the file or data set.

To locate the subordinate message that contains the number of physical messages associated with this attachment, filter it by using the attachment correlid located in the attachment header message. The content of this message is a single numeric integer that corresponds to the number of messages associated with this attachment excluding this message. To filter the rest of the messages associated with this attachment, you will use the same attachment correlid located in the attachment header message (16 bytes) with a sequence number (4 bytes) added to the end of it. For instance, if the attachment correlid was 000102030405060708090A0B0C0D0E0F, you would filter this message to find out how many more messages are associated with this attachment. For example purposes let's say that three more messages make up this attachment. You can then locate these messages by filtering a correlid of 000102030405060708090A0B0C0D0E0F00000001, 000102030405060708090A0B0C0D0E0F00000002, and 000102030405060708090A0B0C0D0E0F00000003, respectively. The sequenced attachment correlid messages are actually sent to the queue before the non-sequenced attachment correlid message so that if you are able to receive the non-sequenced attachment correlid message (iethat ismessage that tells you how many messages make up this attachment), you can be rest assured that the complete attachment has been queued.

At this point, attachment processing differs depending on the attachment type.

For external files, the first sequenced attachment correlid message (attachment_correlid+00000001) contains two numeric integers that correspond to the file's logical record length and size, respectively. The rest of the attachment correlid messages make up the file itself. The contents of these messages are as follows:

   --------------------------------
   long    - size of logical record
   char[]  - actual record
   --------------------------------
   .
   .
   . repeat until the end of file or 32K limit is reached

These messages are limited to 32K so if a file is too large to fit, it will have to span multiple physical messages.

Here is an example of an external file attachment residing on a queue.:

   msg type   msg correlid                              msg contents
   --------   ------------                              ------------
   100000     1111111111111111111111111111111100000000  1111111111111111111111111111111100000000
                                                        00000001
                                                        0000000000000000000000000000000000000000
                                                        2222222222222222222222222222222200000000
                                                        00000001
                                                        00000003
                                                        3333333333333333333333333333333300000000
                                                        00000008
                                                        "FILENAME"
                                                        0000000D
                                                        "d:\mytext.txt"
                                                        0000000C
                                                        "Text file..."
                                                        00000000
                                                        00000000
   100001     2222222222222222222222222222222200000000  "This is the actual application message."
   100001     3333333333333333333333333333333300000001  lrecl|filesize
   100001     3333333333333333333333333333333300000002  len|record|len|record|len|record...
   100001     3333333333333333333333333333333300000003  len|record|len|record|len|record...
   100001     3333333333333333333333333333333300000000  00000003

For data sets, the sequenced attachment correlid messages begin with a type identifier. This identifier signifies the type of information that is in this message. A type identifier of one signifies data set definitions. A type identifier of two signifies variable definitions. A type identifier of three signifies actual observations. Type identifiers four (indexes) and five (integrity constraints) will probably have no use so they can be ignored.

   Note: All character strings are null terminated.

   Layout of a dataset definition  message:

   int     - type (dataset definition=1)
   int     - version (future)
   long    - dataset type length
   char[]  - dataset type
   long    - dataset label length
   char[]  - dataset label
   long    - number of observations
   long    - number of variables
   long    - observation length
   long    - length of compress
   char[]  - compress
   char    - reuse
   long    - length of encrypt
   char[]  - encrypt
   long    - number of variables in sort key
   long    - length of sort collating sequence
   char[]  - sort collating sequence
   short   - sort flags
   int     - read password flag
   byte[4] - read password (encrypted)
   int     - write password flag
   byte[4] - write password (encrypted)
   int     - alter password flag
   byte[4] - alter password (encrypted)


   Layout of a variable definition message:

   int     - type (variable definition=2)
   -----------------------------------
   long    - length of variable name
   char[]  - variable name
   long    - length of format name
   char[]  - format name
   long    - length of informat name
   char[]  - informat name
   long    - variable label length
   char[]  - variable label
   char    - variable type  (1=double, otherwise character)
   long    - variable length
   long    - format field length
   long    - format decimal
   long    - informat field length
   long    - informat decimal
   char    - nsort
   -----------------------------------
   .
   .
   . repeat for each variable


   Note: Variable definitions may span multiple physical 
      messages if definitions are larger than 32K.


   Layout of an observation message:

   int     - type (observation=3)
   data    - the layout of data is defined by the variable 
                definition above


   Note: Observations may span multiple physical messages 
      if they are larger than 32K.


   Layout of an index message:

   int     - type (index=4)
   -----------------------------------
   long    - upercmx
   long    - length of index/key name
   char[]  - index/key name
   long    - flags
   long    - number of variables in the index/key
   long    - variable lengths added together
   char[]  - all variables null terminated
   -----------------------------------
   .
   .
   . repeat for each index