Author |
Message
|
careyire |
Posted: Tue Nov 15, 2005 9:23 am Post subject: ASCII to EBCDIC again ! |
|
|
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 |
|
 |
JT |
Posted: Tue Nov 15, 2005 9:45 am Post subject: |
|
|
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 |
|
 |
jfluitsm |
Posted: Wed Nov 16, 2005 1:03 am Post subject: |
|
|
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 |
|
 |
careyire |
Posted: Wed Nov 16, 2005 1:10 am Post subject: |
|
|
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 |
|
 |
careyire |
Posted: Wed Nov 16, 2005 3:53 am Post subject: |
|
|
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 |
|
 |
jfluitsm |
Posted: Wed Nov 16, 2005 6:49 am Post subject: |
|
|
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 |
|
 |
jefflowrey |
Posted: Wed Nov 16, 2005 7:07 am Post subject: |
|
|
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 |
|
 |
careyire |
Posted: Wed Nov 16, 2005 7:38 am Post subject: |
|
|
Newbie
Joined: 15 Nov 2005 Posts: 4
|
thanks for the suggestions.
I'll try them out. |
|
Back to top |
|
 |
|