ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » ASCII to EBCDIC again !

Post new topic  Reply to topic
 ASCII to EBCDIC again ! « View previous topic :: View next topic » 
Author Message
careyire
PostPosted: Tue Nov 15, 2005 9:23 am    Post subject: ASCII to EBCDIC again ! Reply with quote

Newbie

Joined: 15 Nov 2005
Posts: 4

Hi.
My queue manager is on a solaris. I have a XML message that I am sending to a mainframe.
I have been asked to add in an MQIIH header to use the MQ-IMS bridge to envoke a transaction.
I have used a resetcontentdescriptor node to reset the incoming XML message to a blob.
I pass this onto a compute node were I set the MQMD and MQIIH fields and add the LLZZ and transcode string. ( see below).
On the channel definition I have set the data conversion to Yes.
However the output from the mainframe shows the MQIIH header as ebcdic hex while the message body is still ascii.
From what I read I would expect the message to be converted by MQ.
Any help is appreciated.

This is the compute node code.
DECLARE V_LEN INTEGER;
DECLARE V_BLOB BLOB;
DECLARE i INTEGER;

DECLARE MSGLEN CHARACTER;
DECLARE NUMBER INTEGER;
DECLARE RESULT INTEGER;
DECLARE REM INTEGER;

SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
SET OutputRoot.MQMD.Version = MQMD_VERSION_2;
SET OutputRoot.MQMD.Report = MQRO_PASS_MSG_ID + MQRO_PASS_CORREL_ID;
SET OutputRoot.MQMD.MsgType = MQMT_REQUEST;
SET OutputRoot.MQMD.Expiry = -1;
SET OutputRoot.MQMD.Feedback = MQFB_NONE;
SET OutputRoot.MQMD."Encoding" = MQENC_NATIVE;
SET OutputRoot.MQMD.CodedCharSetId = 285;
SET OutputRoot.MQMD.Format = MQFMT_IMS;
SET OutputRoot.MQMD.Priority = MQPRI_PRIORITY_AS_Q_DEF;
SET OutputRoot.MQMD.Persistence = MQPER_PERSISTENT;
SET OutputRoot.MQMD.Msgid = MQMI_NONE;
SET OutputRoot.MQMD.CorrelID = MQCI_NONE;
SET OutputRoot.MQMD.BacoutCount = 0;
SET OutputRoot.MQMD.ReplyToQ = 'REPLY.TO.TRAX';
SET OutputRoot.MQMD.ReplyToQMgr = 'TMQ1';
SET OutputRoot.MQMD.UserIdentifier = 'XMQSC98';
SET OutputRoot.MQMD.AccountingToken = MQACT_NONE;
SET OutputRoot.MQMD.ApplIdentityData = '';
SET OutputRoot.MQMD.PutApplType = MQAT_UNIX;
SET OutputRoot.MQMD.PutApplName = 'MQSI MSG FLOW';
SET OutputRoot.MQMD.ApplOriginData = '';
SET OutputRoot.MQMD.GroupId = MQGI_NONE;
--SET OutputRoot.MQMD.MsgSeqNumber = 0;
SET OutputRoot.MQMD.Offset = 0;
SET OutputRoot.MQMD.MsgFlags = MQMF_NONE ;
SET OutputRoot.MQMD.OriginalLength = MQOL_UNDEFINED;

SET OutputRoot.MQIIH.StrucId = MQIIH_STRUC_ID;
SET OutputRoot.MQIIH.Version = MQIIH_CURRENT_VERSION;
SET OutputRoot.MQIIH.StrucLength = 84;
SET OutputRoot.MQIIH."Encoding" = MQENC_NATIVE; --0;
SET OutputRoot.MQIIH.CodedCharSetId = 285; --0;
SET OutputRoot.MQIIH.Format = MQFMT_IMS_VAR_STRING;
SET OutputRoot.MQIIH.Flags = 0;
SET OutputRoot.MQIIH.LTermOverride = ' ';
SET OutputRoot.MQIIH.MFSMapName = ' ';
SET OutputRoot.MQIIH.ReplyToFormat = MQFMT_IMS_VAR_STRING;
SET OutputRoot.MQIIH.Authenticator = ' ';
SET OutputRoot.MQIIH.TranInstanceId = X'00000000000000000000000000000000';
SET OutputRoot.MQIIH.TranState =' ';
SET OutputRoot.MQIIH.CommitMode = MQICM_SEND_THEN_COMMIT; --MQICM_COMMIT_THEN_SEND; -- '0';
SET OutputRoot.MQIIH.SecurityScope = 'C';

SET V_LEN = LENGTH("InputRoot"."BLOB"."BLOB");


-- Converting the length to HEX.
--Set MSGLEN to non NULL to avoid errors when concatenating the first time --
SET MSGLEN ='X';

--Get the length of the BLOB and substract the length of VERSION_NUM and STORE_NUM (11+10)

SET NUMBER =LENGTH("InputRoot"."BLOB"."BLOB") + 12;

--convert NUMBER to hexadecimal.The remainder of dividing by 16 is calculated recursively.--
WHILE NUMBER >15 DO
SET RESULT =NUMBER/16;
SET REM =NUMBER -RESULT*16;
SET MSGLEN =
CASE
WHEN REM <10 THEN CAST(REM AS CHARACTER)||MSGLEN
WHEN REM =10 THEN 'A'||MSGLEN
WHEN REM =11 THEN 'B'||MSGLEN
WHEN REM =12 THEN 'C'||MSGLEN
WHEN REM =13 THEN 'D'||MSGLEN
WHEN REM =14 THEN 'E'||MSGLEN
ELSE 'F'||MSGLEN
END;
SET NUMBER =RESULT;
END WHILE;

SET REM =NUMBER;
SET MSGLEN =
CASE
WHEN REM <10 THEN CAST(REM AS CHARACTER)||MSGLEN
WHEN REM =10 THEN 'A'||MSGLEN
WHEN REM =11 THEN 'B'||MSGLEN
WHEN REM =12 THEN 'C'||MSGLEN
WHEN REM =13 THEN 'D'||MSGLEN
WHEN REM =14 THEN 'E'||MSGLEN
ELSE 'F'||MSGLEN
END;

--Add leading '0's up to a length of 5 to be able to cast as BLOB.
--Remember it started with MSGLEN set to X (length 1)

WHILE LENGTH(MSGLEN)<5 DO
SET MSGLEN ='0'||MSGLEN;
END WHILE;

--Remember to get rid of the last character as it is the X.
SET MSGLEN =SUBSTRING(MSGLEN FROM 1 FOR 4);

-- Create the message.

SET "OutputRoot"."BLOB"."BLOB" = CAST(MSGLEN as BLOB) || CAST('20205542503030344820' as BLOB) || "InputRoot"."BLOB"."BLOB" ;
Back to top
View user's profile Send private message
JT
PostPosted: Tue Nov 15, 2005 9:45 am    Post subject: Reply with quote

Padawan

Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.

Quote:
On the channel definition I have set the data conversion to Yes.

Which channel, the Sender on the Solaris platform or the Receiver on the mainframe ?
Back to top
View user's profile Send private message
jfluitsm
PostPosted: Wed Nov 16, 2005 1:03 am    Post subject: Reply with quote

Disciple

Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands

This working is correct.

This is what happens:
- You state in the MQMD that the ccsid of the MQIIH must be 285, the broker will write out the MQIIH in this codepage.
- You state in the MQIIH that the data is in ccsid 285, but as you handles the data as blob, the broker leaves it as is (ascii). Here it goes wrong, MQIHH states ebcdic while the data is actual ascii.
- On the channel the conversion detects that both the MQIIH and the data are already in ccsid 285 (as stated in the MQMD and MQIIH) and thus doesn't do any conversion.

There are a couple of possible solutions:
- Use XML as incomming message and create BITSTREAM using 285 as ccsid.
- Convert the blob to a string and then create BITSTREAM using 285 as ccsid.
Both options don't need the convert on the channel as the broker alrady does the converion,
- Get the ccsid from the original data part (probably InputRoot.MQMD.CodedCharSetId if no other headers are used) and use this value for OutputRoot.MQIIH.CodedCharSetId. The channel will convert the data to ebcdic.
_________________
Jan Fluitsma

IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6
Back to top
View user's profile Send private message Send e-mail
careyire
PostPosted: Wed Nov 16, 2005 1:10 am    Post subject: Reply with quote

Newbie

Joined: 15 Nov 2005
Posts: 4

I set the data conversion flag on the sender channel.

I will try your suggestions and revert. Thanks.
Back to top
View user's profile Send private message
careyire
PostPosted: Wed Nov 16, 2005 3:53 am    Post subject: Reply with quote

Newbie

Joined: 15 Nov 2005
Posts: 4

Hi,
I have set the CCSID on the MQIIH header to 819 ( the original CCSID).
I have output the message to a local queue.
When I browse the queue using the rfhutilc utility it is showing the CCSID as 285 on the IMS tab and yet I have a trace node after the queue and it is showing the CCSID as 819. Any ideas ?
Thanks.
Back to top
View user's profile Send private message
jfluitsm
PostPosted: Wed Nov 16, 2005 6:49 am    Post subject: Reply with quote

Disciple

Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands

The trace node states what you put into the message, the data should be in ascii.

When a message is converted, either by a channel or bij mqget with the convert options, the target ccsid is shown when the conversion succeeds.

rfhutil plays around with conversions, it looks like it got the message from the queue with the convert option. rfhutil is a bit tricky for ccsid problems as it has to convert to ascii to display readable text on the screen. Best is to look at the hex values of the message using MQ Explorer, mqmonntp (SupportPac mo71) or the hex output from program q (I think ma01).
_________________
Jan Fluitsma

IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6
Back to top
View user's profile Send private message Send e-mail
jefflowrey
PostPosted: Wed Nov 16, 2005 7:07 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

I usually recommend amqsbcg when trying to debug message data problems.

It's usually already installed.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
careyire
PostPosted: Wed Nov 16, 2005 7:38 am    Post subject: Reply with quote

Newbie

Joined: 15 Nov 2005
Posts: 4

thanks for the suggestions.
I'll try them out.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » ASCII to EBCDIC again !
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.