mqput js string with NewLine

[davidrosee]

Hi,

I've managed to do mqput using this package... However I have a problem, after mqput the message triggers a cobol application which begins processing the message.

However it does not detect the newline characters from my javascript string (mq message) which I put on the queue.

Any suggestions on how to make a mq message EBSIDIC "friendly" before the put?

[ibmmqmet]

You need to make sure that the codepages are being converted as expected. And that the application is actually doing what you want it to do. It's impossible to say exactly what to change as it will depend hugely on configuration and what the receiving application is doing with the message body.

The message that has been PUT will presumably have "0x0A" as the newline char; the EBCDIC equivalent would normally be "0x15". What the COBOL app does with that 0x15 would be something you need to check with the app source code. For example, it might print it as CR, not LF; or it might be ignoring it.

Using raw message browsers like amqsbcg at various stages of the flow (eg disable the cobol app from starting) will tell you exactly what bytes are in the message body.

[davidrosee]

Appreciate your reply, and some new hints ...

I tried converting the message in the javascript application from utf-8 to cp278 (EBCIDIC Finland, Sweden) using codepages before doing the put.

This results in a string which looks something like:

200,195,212,196,240,242,215,133,153,134,150,153,148,194,150,150,146,137,149,135,64, ...

I used https://github.com/SheetJS/js-codepage for this and:
var msg = cptable.utils.encode(1143, message); // (1143 = IBM cp278)

I also set:
mqmd.CodedCharSetId = 278;
before the put in the javascript application.

However after doing the put the message ends up looking the same on the queue:
200,195,212,196,240,242,215 ...

I must be missing something crucial :)

On the mainframe side and in the cobol application, a new line needs to be 0D 25. In utf-8 and on the pc side I think its
0D0A.

[ibmmqmet]

You should be putting the message in ASCII and rely on the MQGET-with-conversion in the COBOL end.

But I think you are mixing up the CR and LF characters. And possibly also getting confused with Windows conventions of CRLF being the line-end in text files, instead of the single LF. You might want to play with seeing what happens with using both "\r" and "\n" in the string that's put.

                      ASCII      EBCDIC
                      -----      ------
(LF/line feed):       X'0a' <--> X'25' (LF/line feed)
(CR/carriage return): X'0d' <--> X'0d' (CR/carriage return)
(NEL/next line):      X'85' <--> X'15' (NL/new line)

Exactly which combination of these characters constitutes an "end-of-line" delimiter might vary from application to application.

[davidrosee]

I tried a few new things...

Converting into ascii before put:
(removed cp278)

      let msg = iconv.encode(message, 'ascii');
      return mq.PutPromise(hObj,mqmd,pmo,msg);

1. Converted the message to use LF instead of CRLF (in notepad++) before posting the string converting it into ASCII with code above. All characters on the queue except linefeed and swedish characters looks good, linefeed gets converted into: "L..NER"

2. same when using \n and \r

It also seems like Swedish characters do not work very well with ASCII, so seems like I have to find a way to convert correctly into cp278...

I know of a JAVA application using the same queue / cobol application using something similar to:

Writer file = new OutputStreamWriter(new FileOutputStream(path + "msg.txt", true), "Cp278");

it also uses prior to put:

for (i = 0; i < bytesRead.size(); i++){
	if (bytesRead[i] == 0x15)
		bytesRead[i] = 0x25
}

To convert certain bytes because of this bug:
https://www.ibm.com/support/pages/apar/IV93693
which causes 0D0A on the PC to 0D15 instead of 0D25 in the mainframe ...

Wish I could figure out how to do something similar in Javascript ...