Hope that someone can help or guide?  We have Datapower javascript to write to a Linux MQ Queue manager to forward to z/OS MQ Queue manager to transfer to MQ IMSBridge. The javascript determines the length and inserts the LLZZ (not straight forward .js) in front of the transaction+payload.
If  LL is <256 then this all works, and I get the expected response in the reply queue.  
If LL>256, for example 1708, then LL should be x'06AC' something is inserting a x'C2', i.e. x'06C2AC' following by ZZ etc. And then get an IIH error.

I am not sure of the LL should be little-endian or big-endian, and MQIIH.Encoding=0; I tried both ways, and the x'C2' is still inserted before the x'AC'. 
Q: How can I get around this issue?
Appreciate any suggestions.

BTW: There is a hack! Set the LL to x'7F7F' irrespective of the length and the problem goes away. IMS is forgiving.

------------------------------
hirschel wasserman
------------------------------

Please show your code.

"C2AC" is the UTF-8 encoding of unicode character U+00AC.

------------------------------
Hermann Stamm-Wilbrandt
Compiler Level 3 support & Fixpack team lead
IBM DataPower Gateways (⬚ᵈᵃᵗᵃ / ⣏⠆⡮⡆⢹⠁⡮⡆⡯⠂⢎⠆⡧⡇⣟⡃⡿⡃)
------------------------------

Original Message:
Sent: Tue May 05, 2020 07:34 PM
From: hirschel wasserman
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hope that someone can help or guide?  We have Datapower javascript to write to a Linux MQ Queue manager to forward to z/OS MQ Queue manager to transfer to MQ IMSBridge. The javascript determines the length and inserts the LLZZ (not straight forward .js) in front of the transaction+payload.
If  LL is <256 then this all works, and I get the expected response in the reply queue.  
If LL>256, for example 1708, then LL should be x'06AC' something is inserting a x'C2', i.e. x'06C2AC' following by ZZ etc. And then get an IIH error.

I am not sure of the LL should be little-endian or big-endian, and MQIIH.Encoding=0; I tried both ways, and the x'C2' is still inserted before the x'AC'. 
Q: How can I get around this issue?
Appreciate any suggestions.

BTW: There is a hack! Set the LL to x'7F7F' irrespective of the length and the problem goes away. IMS is forgiving.

------------------------------
hirschel wasserman
------------------------------

Thanks. I has a suspicion that it had to with extended characterset.
Here are two code excerpts
...
//construct MQ headers
var mqHeaders=constuctMqHeaders(imsUserId, imsCredential, config);

//construct IMS request message
var imsRequestMessage = constuctImsRequestMessage(imsRequestData);
// 
//construct url open options
var mqTarget = 'dpmq://IMSMQ_QMgr_LB/?RequestQueue=' + config.mq.REQUEST_QUEUE + ';ReplyQueue=' + config.mq.REPLY_QUEUE
+ ';Model=true;SetReplyTo=true;TimeOut=' + config.mq.TIMEOUT + ';PMO=9220;ParseHeaders=true';
var options = {
  target: mqTarget,  
  headers: mqHeaders,
  data: imsRequestMessage
};

const open = util.promisify(urlopen.open);
open(options)
  .then(function(response) {
  var mqrc = response.statusCode; ...etc

function constuctImsRequestMessage(imsRequestData) {
var moduleName = 'constuctImsRequestMessage';
log.infoLog(moduleName, "Entering...");

var LLdec = imsRequestData.length + 4;
// add leading zeros, and the trailing ZZ, and take rightmost 8 characters
var LLZZhex = (('000').toString() + LLdec.toString(16) + ('0000').toString()).slice(-8);
// convert and prepend the LLZZ
var LLZZchar = hex2bin(LLZZhex) ;
var imsRequestMessage = LLZZchar + imsRequestData;

log.infoLog(moduleName, "...Leaving");
return imsRequestMessage;
}

function hex2bin(hex)
{
 var bytes = [], str;
 for(var i=0; i< hex.length-1; i+=2) 
    bytes.push(parseInt(hex.substr(i, 2), 16));
return String.fromCharCode.apply(String, bytes);
}
// end of new code



------------------------------
hirschel wasserman
------------------------------

Original Message:
Sent: Thu May 07, 2020 06:37 AM
From: Hermann Stamm-Wilbrandt
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Please show your code.

"C2AC" is the UTF-8 encoding of unicode character U+00AC.

------------------------------
Hermann Stamm-Wilbrandt
Compiler Level 3 support & Fixpack team lead
IBM DataPower Gateways (⬚ᵈᵃᵗᵃ / ⣏⠆⡮⡆⢹⠁⡮⡆⡯⠂⢎⠆⡧⡇⣟⡃⡿⡃)

Original Message:
Sent: Tue May 05, 2020 07:34 PM
From: hirschel wasserman
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hope that someone can help or guide?  We have Datapower javascript to write to a Linux MQ Queue manager to forward to z/OS MQ Queue manager to transfer to MQ IMSBridge. The javascript determines the length and inserts the LLZZ (not straight forward .js) in front of the transaction+payload.
If  LL is <256 then this all works, and I get the expected response in the reply queue.  
If LL>256, for example 1708, then LL should be x'06AC' something is inserting a x'C2', i.e. x'06C2AC' following by ZZ etc. And then get an IIH error.

I am not sure of the LL should be little-endian or big-endian, and MQIIH.Encoding=0; I tried both ways, and the x'C2' is still inserted before the x'AC'. 
Q: How can I get around this issue?
Appreciate any suggestions.

BTW: There is a hack! Set the LL to x'7F7F' irrespective of the length and the problem goes away. IMS is forgiving.

------------------------------
hirschel wasserman
------------------------------

Hi

Further to Hermann's response, the fact that you are seeing UTF-8 indicates that you are likely using JS String (string?) type to deal with the data rather than JS Buffer (or buffer?) type.

Because you need to work with binary data (in the LLZZ field) you will most likely need to handle everything using buffers, not strings.

My recollection of dealing with the MQ IMS bridge (it's been a while, but it's hard to forget) is that the 16 bit LL field is a big-endian integer. You will be responsible for ensuring that it is in the correct byte order.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-20
+61 (0) 414 615 334
------------------------------

Original Message:
Sent: Tue May 05, 2020 07:34 PM
From: hirschel wasserman
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hope that someone can help or guide?  We have Datapower javascript to write to a Linux MQ Queue manager to forward to z/OS MQ Queue manager to transfer to MQ IMSBridge. The javascript determines the length and inserts the LLZZ (not straight forward .js) in front of the transaction+payload.
If  LL is <256 then this all works, and I get the expected response in the reply queue.  
If LL>256, for example 1708, then LL should be x'06AC' something is inserting a x'C2', i.e. x'06C2AC' following by ZZ etc. And then get an IIH error.

I am not sure of the LL should be little-endian or big-endian, and MQIIH.Encoding=0; I tried both ways, and the x'C2' is still inserted before the x'AC'. 
Q: How can I get around this issue?
Appreciate any suggestions.

BTW: There is a hack! Set the LL to x'7F7F' irrespective of the length and the problem goes away. IMS is forgiving.

------------------------------
hirschel wasserman
------------------------------

Neil is right, you need to use Buffer methods and not strings:

return String.fromCharCode.apply(String, bytes);

Here is the API:

https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.7.0/com.ibm.dp.doc/buffer_js.html

Construct the header as new Buffer, you can access the bytes directly.
You can find several cool examples for what I did with Buffer datatype here:
https://web.archive.org/web/20151004125215/https://www.ibm.com/developerworks/community/blogs/HermannSW?lang=en_us

I do like "readUtfAsJSON.js - detect UTF encoding and parse JSON (rfc7159)" most.

------------------------------
Hermann Stamm-Wilbrandt
Compiler Level 3 support & Fixpack team lead
IBM DataPower Gateways (⬚ᵈᵃᵗᵃ / ⣏⠆⡮⡆⢹⠁⡮⡆⡯⠂⢎⠆⡧⡇⣟⡃⡿⡃)
------------------------------

Original Message:
Sent: Thu May 07, 2020 07:14 PM
From: Neil Casey
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hi

Further to Hermann's response, the fact that you are seeing UTF-8 indicates that you are likely using JS String (string?) type to deal with the data rather than JS Buffer (or buffer?) type.

Because you need to work with binary data (in the LLZZ field) you will most likely need to handle everything using buffers, not strings.

My recollection of dealing with the MQ IMS bridge (it's been a while, but it's hard to forget) is that the 16 bit LL field is a big-endian integer. You will be responsible for ensuring that it is in the correct byte order.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-20
+61 (0) 414 615 334

Original Message:
Sent: Tue May 05, 2020 07:34 PM
From: hirschel wasserman
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hope that someone can help or guide?  We have Datapower javascript to write to a Linux MQ Queue manager to forward to z/OS MQ Queue manager to transfer to MQ IMSBridge. The javascript determines the length and inserts the LLZZ (not straight forward .js) in front of the transaction+payload.
If  LL is <256 then this all works, and I get the expected response in the reply queue.  
If LL>256, for example 1708, then LL should be x'06AC' something is inserting a x'C2', i.e. x'06C2AC' following by ZZ etc. And then get an IIH error.

I am not sure of the LL should be little-endian or big-endian, and MQIIH.Encoding=0; I tried both ways, and the x'C2' is still inserted before the x'AC'. 
Q: How can I get around this issue?
Appreciate any suggestions.

BTW: There is a hack! Set the LL to x'7F7F' irrespective of the length and the problem goes away. IMS is forgiving.

------------------------------
hirschel wasserman
------------------------------

Thanks both Hermann and Neil. I will pursue the buffer method.

------------------------------
hirschel wasserman
------------------------------

Original Message:
Sent: Fri May 08, 2020 03:56 AM
From: Hermann Stamm-Wilbrandt
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Neil is right, you need to use Buffer methods and not strings:

return String.fromCharCode.apply(String, bytes);

Here is the API:

https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.7.0/com.ibm.dp.doc/buffer_js.html

Construct the header as new Buffer, you can access the bytes directly.
You can find several cool examples for what I did with Buffer datatype here:
https://web.archive.org/web/20151004125215/https://www.ibm.com/developerworks/community/blogs/HermannSW?lang=en_us

I do like "readUtfAsJSON.js - detect UTF encoding and parse JSON (rfc7159)" most.

------------------------------
Hermann Stamm-Wilbrandt
Compiler Level 3 support & Fixpack team lead
IBM DataPower Gateways (⬚ᵈᵃᵗᵃ / ⣏⠆⡮⡆⢹⠁⡮⡆⡯⠂⢎⠆⡧⡇⣟⡃⡿⡃)

Original Message:
Sent: Thu May 07, 2020 07:14 PM
From: Neil Casey
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hi

Further to Hermann's response, the fact that you are seeing UTF-8 indicates that you are likely using JS String (string?) type to deal with the data rather than JS Buffer (or buffer?) type.

Because you need to work with binary data (in the LLZZ field) you will most likely need to handle everything using buffers, not strings.

My recollection of dealing with the MQ IMS bridge (it's been a while, but it's hard to forget) is that the 16 bit LL field is a big-endian integer. You will be responsible for ensuring that it is in the correct byte order.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-20
+61 (0) 414 615 334

Original Message:
Sent: Tue May 05, 2020 07:34 PM
From: hirschel wasserman
Subject: Datapower to MQ IMSBridge in javascript: LL problem

Hope that someone can help or guide?  We have Datapower javascript to write to a Linux MQ Queue manager to forward to z/OS MQ Queue manager to transfer to MQ IMSBridge. The javascript determines the length and inserts the LLZZ (not straight forward .js) in front of the transaction+payload.
If  LL is <256 then this all works, and I get the expected response in the reply queue.  
If LL>256, for example 1708, then LL should be x'06AC' something is inserting a x'C2', i.e. x'06C2AC' following by ZZ etc. And then get an IIH error.

I am not sure of the LL should be little-endian or big-endian, and MQIIH.Encoding=0; I tried both ways, and the x'C2' is still inserted before the x'AC'. 
Q: How can I get around this issue?
Appreciate any suggestions.

BTW: There is a hack! Set the LL to x'7F7F' irrespective of the length and the problem goes away. IMS is forgiving.

------------------------------
hirschel wasserman
------------------------------