compressed messages as part of a message payload

[Costa, D. (Damian)]

Hi all,
A developer asked me this question and my brain sort of popped trying to work out what MQ would do.
The message payload begins with two ascii fields for routing and identification purposes but then the rest of the payload is compressed.

Here's the question straight form the horse's mouth so to speak:

"The identifier is expected to be ASCII and the actual payload message will be compressed (not sure what type of compression they will use)

From an ETL Perspective it won't be a problem - I thought I will check with you if MQ will moan about getting both compressed and uncompressed forms of messages on it? Or if you would suggest to tweak some MQ Configs to handle such scenarios better."

So would the messages content be preserved across different platforms?
If no, how would one go about accommodating this type of scenario.
Thanks.



********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Paul Clarke]

Damian,

MQ itself doesn't really care where the message data is ASCII or compressed
binary or anything else, unless you are asking MQ to convert the data for
you. Without conversion the data will arrive exactly the same as when you
transmitted it regardless of what it is. However, if you are wanting the
data converted by MQ, for example from ASCII to EBDCDIC or little-endian to
big-endian then you essentially have two choices.

1) You can define your own message format and distribute your own data
conversion exits to anyone who needs it.
There's no denying it that this is a bit of a pain, both in terms of
developing and maintaining the exit but also in terms of distribution.

2) Use one of the built-in MQ formats.
I won't claim to know all the message formats but there aren't many
which support general purpose messages which can contain both convertible
and non-convertible data. The most obvious is a PCF message. Here you could
put your identifier in a 'string' element in the message and your compressed
data in a 'bytes' element in the message. MQ will then convert the
identifier as required but leave the compressed bytes along. Of course when
the message arrives at your final destination then the application will be
responsible for decompressing the data and then applying any data conversion
if required.

Does this help at all or did I miss the point of your question? For example,
if you are talking MQ message compression over a channel then that is
somewhat different.

Cheers,
Paul.

Paul Clarke
www.mqgem.com
-----Original Message-----
From: Costa, D. (Damian)
Sent: Friday, July 19, 2013 2:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: compressed messages as part of a message payload

Hi all,
A developer asked me this question and my brain sort of popped trying to
work out what MQ would do.
The message payload begins with two ascii fields for routing and
identification purposes but then the rest of the payload is compressed.

Here's the question straight form the horse's mouth so to speak:

"The identifier is expected to be ASCII and the actual payload message will
be compressed (not sure what type of compression they will use)

From an ETL Perspective it won't be a problem - I thought I will check with

you if MQ will moan about getting both compressed and uncompressed forms of
messages on it? Or if you would suggest to tweak some MQ Configs to handle
such scenarios better."

So would the messages content be preserved across different platforms?
If no, how would one go about accommodating this type of scenario.
Thanks.



********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Ward Able, Grant]

Costa,
if the body of the message is not in STRING format, then you need to consider what FORMAT you need & the implications that will have on conversion. MQFMT_NONE seems like it may be a reasonable choice. You don't want to be doing any kind of conversion!


Regards - Grant.
Telephone Internal: 201496 (London)
Telephone External: [phone]


-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: 19 July 2013 14:14
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: compressed messages as part of a message payload

Hi all,
A developer asked me this question and my brain sort of popped trying to work out what MQ would do.
The message payload begins with two ascii fields for routing and identification purposes but then the rest of the payload is compressed.

Here's the question straight form the horse's mouth so to speak:

"The identifier is expected to be ASCII and the actual payload message will be compressed (not sure what type of compression they will use)

From an ETL Perspective it won't be a problem - I thought I will check with you if MQ will moan about getting both compressed and uncompressed forms of messages on it? Or if you would suggest to tweak some MQ Configs to handle such scenarios better."

So would the messages content be preserved across different platforms?
If no, how would one go about accommodating this type of scenario.
Thanks.



********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Bruce Lerner]

WMQ cares not at all about the message data payload. WMQ headers (MQMD,
XQH, etc.) will be converted if needed, but your app data will remain intact
(unconverted) unless the consuming app requests it (MQGMO_CONVERT), or the
sender channel specifies CONVERT(YES).

Strongly suggest that you search for, and read about, mq data conversion.
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Michael Dag]

Hi Damian,
What type of developer asked this question?
Application developer with MQI, Application developer using JMS/XMS, Message
Broker developer using nodes?

I have seen stuff like this in the past where we had an xml document with at
the end a gif or jpg attached containing a picture of a signature.
The xml size was variable so we had to search for the end and then split the
message in a 'data' and binary part.
This was in Message Broker and we didn't have DFDL at the time.

You mention routing and identification, would this be in MQ or somewhere
else? If in MQ I would make use of MQ Message Properties to store that data.

In general if MQ had nothing to do with the data it doesn't care... so
depending (!) on what you want MQ or MQ Application (like Message Broker) to
do with it makes your life more difficult or more easy...

Hope this helps.

Michael
www.mqsystems.com

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Costa, D. (Damian)
Sent: vrijdag 19 juli 2013 15:14
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: compressed messages as part of a message payload

Hi all,
A developer asked me this question and my brain sort of popped trying to
work out what MQ would do.
The message payload begins with two ascii fields for routing and
identification purposes but then the rest of the payload is compressed.

Here's the question straight form the horse's mouth so to speak:

"The identifier is expected to be ASCII and the actual payload message will
be compressed (not sure what type of compression they will use)

From an ETL Perspective it won't be a problem - I thought I will check with

you if MQ will moan about getting both compressed and uncompressed forms of
messages on it? Or if you would suggest to tweak some MQ Configs to handle
such scenarios better."

So would the messages content be preserved across different platforms?
If no, how would one go about accommodating this type of scenario.
Thanks.



********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names
of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES