| Author |
Message
|
| jgooch |
 Posted: Thu Sep 11, 2003 3:39 am Post subject: Suppressing data conversion. |
 |
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
Hi,
I'm writing a recovery script (in Perl) for our administrators to allow them to sweep up messages from various failures across our MQ/WMQI environment.
One of the situations it has to cope with is to recover some EBCDIC messages. This is on our WMQI Solaris hub. We receive messages from a qmgr on one of our clients' mainframe and our WMQI flows do not convert the data to ASCII before processing (no, I'm not sure why the developer did it this way  ). Sometimes these EBCDIC messages end up on a failed message queue and we want to be able to move them back to the source queue to try again (it's embarrassing to ask the client to re-send due to our hiccups).
Therefore, my recovery script needs to be able to move EBCDIC data from one queue to another whilst suppressing MQ's desire to convert it to ASCII.
So, I think that my question is: "what is the opposite of MQGMO_CONVERT?"
The documentation is really helpful on how to convert data during an MQGET, etc but not so helpful in telling you how to suppress it!
Thanks,
Jeremy. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Thu Sep 11, 2003 3:57 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I thought MQGMO_CONVERT was a bit that got set in a flag. If you don't want conversion done, don't set the bit. |
|
| Back to top |
|
|
| jgooch |
| Posted: Thu Sep 11, 2003 4:06 am Post subject: |
|
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
That makes sense, but the options I'm setting on open are:-
source q
Options => MQSeries::MQOO_INPUT_AS_Q_DEF |
MQSeries::MQOO_FAIL_IF_QUIESCING |
MQSeries::MQOO_SAVE_ALL_CONTEXT,
dest q
Options => MQSeries::MQOO_OUTPUT |
MQSeries::MQOO_FAIL_IF_QUIESCING |
MQSeries::MQOO_PASS_ALL_CONTEXT,
So, I'm not actually setting MQGMO_CONVERT (or the Perl equivalent).
My source message has:-
Format MQSTR
CCSID 285
Encoding 785
I then simply put the message object to the destination queue and the result is:-
Format MQSTR
CCSID 819
Encoding 273
...and the conversion has been done.
J. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Sep 11, 2003 6:26 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
If you are not converting the data, by not specifying MQGMO_CONVERT, then you also need to copy the CCSID and Encoding values from the input MQMD to the Output. Or use the Input one as the Output, if that's possible in PERL.
Without this, MQSeries will always assume that you are writing data native to the platform you are running on.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jgooch |
| Posted: Thu Sep 11, 2003 6:47 am Post subject: |
|
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
Thanks for the replies.
I think I'm getting closer now. I found this in the documentation, which rather gives the game away.
| Quote: |
GetMsgOpts
This option allows the programmer complete control over the GetMsgOpts structure passed to the MQGET() call. If this option is specified, then the Sync, and Wait options are simply ignored.
The default options specified by the OO API are
MQGMO_FAIL_IF_QUIESCING
MQGMO_CONVERT
See the MQGET() documentation for the use of GetMsgOpts. |
I'm going to override the defaults and see if this cures it.
J. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Sep 11, 2003 6:53 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Are your messages being sent across channels ??? if so check convert option on the channel definition
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| jgooch |
| Posted: Thu Sep 11, 2003 7:30 am Post subject: |
|
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
It's not a channel conversion issue. I have messages on a local queue with CCSID 285 and encoding 785. After I've taken them and put them back using the code below, they have CCSID 819 and encoding 273.
| Quote: |
$o_message = MQSeries::Message->new();
# Get Message Options value to pass to MQ
$gmo_value = ( MQSeries::MQGMO_FAIL_IF_QUIESCING +
MQSeries::MQGMO_SYNCPOINT +
MQSeries::MQGMO_NO_WAIT );
# Add values to MsgDesc hash
%GetMsgOpts = ("Options", $gmo_value);
# Create reference to %GetMsgOpts
$GetMsgOpts_ref = \%GetMsgOpts;
# get the data from the queue
eval {
$o_source_q->Get (
Message => $o_message,
GetMsgOpts => $GetMsgOpts_ref,)
};
...error handling bit snipped out...
$o_dest_q->Put
(
Message => $o_message,
Sync => 1
);
...error handling bit snipped out...
|
Is there something I need to be careful of with the PUT?
J. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Sep 11, 2003 8:35 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well there are fields in MQMD to specify the encoding to use, by default they are set to native, you need to change that on your put to the CCSID/Encoding you want it to be.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| jgooch |
| Posted: Fri Sep 12, 2003 4:50 am Post subject: |
|
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
OK, but in the code above I pass the message object taken from the source queue directly to the destination queue. This object includes the MsgDesc.
Are you saying I also need to explicitly reset the encoding and the CCSID? This seems a little mad to me as it will be akin to doing:-
set $var1 = $var1;
?? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Sep 12, 2003 5:20 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well I have written apps that we set different CCSID and it worked by changing the MQMD, you might check the CCSID field after the MQGET
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| jgooch |
| Posted: Mon Sep 15, 2003 3:39 am Post subject: Solved! |
|
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
Mr Linux,
Good idea. I dumped out the message after the GET (using Data::Dumper) and lo and behold, the conversion had already been done.
I eventually had to dig through the API code itself to discover that the only way to override the MQGMO_CONVERT on the get was to add another entry to the hash (Convert => 0).
I had inferred from the man pages that all default message options were overridden by a specific GetMsgOpts value. This is not true. I have since found this area correctly described in the documentation on the MQ API on cpan.org (http://search.cpan.org/author/HBIERSMA/MQSeries-1.20/MQSeries/Queue.pm).
For reference, this is the code that works:-
| Quote: |
$o_message = MQSeries::Message->new();
# Get Message Options value to pass to MQ
$gmo_value = ( MQSeries::MQGMO_FAIL_IF_QUIESCING +
MQSeries::MQGMO_SYNCPOINT +
MQSeries::MQGMO_NO_WAIT );
# Add values to MsgDesc hash
%GetMsgOpts = ("Options", $gmo_value);
# Create reference to %GetMsgOpts
$GetMsgOpts_ref = \%GetMsgOpts;
# get the data from the queue
eval {
$o_source_q->Get (
Message => $o_message,
GetMsgOpts => $GetMsgOpts_ref,
Convert => 0,)
}; |
Phew!
J. |
|
| Back to top |
|
|
|
|
