| Author |
Message
|
| Jeffries |
 Posted: Fri Jan 27, 2023 11:05 am Post subject: Getting Dot characters while pulling message from MQ by Main |
 |
|
Newbie
Joined: 27 Jan 2023
Posts: 4
|
Hi All,
We receiving messages from DotNet Client application to our Mainframe Queue manager and while the Mainframe application tries to pull the message from our Mainframe Queue the messages are appending with dot (.) Characters in front of each messages
Please suggest some solution for this.
Thank you.[/b] |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Jan 28, 2023 2:28 am Post subject: Re: Getting Dot characters while pulling message from MQ by |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Jeffries wrote: |
Hi All,
We receiving messages from DotNet Client application to our Mainframe Queue manager and while the Mainframe application tries to pull the message from our Mainframe Queue the messages are appending with dot (.) Characters in front of each messages
Please suggest some solution for this.
Thank you.[/b] |
What is the CCSID on the message, what is the message format and how did the message get written to the queue(API method called)? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 28, 2023 5:34 am Post subject: Re: Getting Dot characters while pulling message from MQ by |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeffries wrote: |
| ... message from our Mainframe Queue the messages are appending with dot (.) Characters in front of each messages |
I'm a bit confused by this. When you append something to something else, you attach it or add it to the end of it - not the start of it. (For example, I appended a dot character to the end of this sentence.) Conversely, prepend usually means attach (a piece of data) to the beginning of another.
A message consists of a message descriptor header (MQMD) and your application data payload.
So, are you saying that the . is now the first (left-most) non-blank character of your application data payload? Or the right-most character? Or somewhere else?
It might help if you displayed a portion of the message for us to see - both MQMD and application data payload - in character character and hex formats.
The CCSID and message format are part of the MQMD.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Jan 29, 2023 7:21 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Byte Order Mark
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Jan 30, 2023 5:07 pm Post subject: Re: Getting Dot characters while pulling message from MQ by |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| Jeffries wrote: |
| We receiving messages from DotNet Client application to our Mainframe Queue manager and while the Mainframe application tries to pull the message from our Mainframe Queue the messages are appending with dot (.) Characters in front of each messages |
A dot (.) character is classically used to represent a character that does not have a printable form. Often nulls but also other non-printable control characters.
You seem to be describing that every character has a dot in front of it? This makes me think that the message is in a UniCode codepage, where each character is represented by 2 bytes, where for many" normal" characters, e.g. your A-Z and 0-9 characters, the first of the two bytes is 0x00. If you take a stream of bytes and assume it is single-byte ASCII when it is actually Double-byte UniCode, it would be printed out as dot-character-dot-character.
Others have asked what the code page of the message is - I would reiterate that, and also ask, does your mainframe application use MQGET with MQGMO_CONVERT?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jan 31, 2023 4:56 pm Post subject: Re: Getting Dot characters while pulling message from MQ by |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Jeffries wrote: |
Hi All,
We receiving messages from DotNet Client application to our Mainframe Queue manager and while the Mainframe application tries to pull the message from our Mainframe Queue the messages are appending with dot (.) Characters in front of each messages
Please suggest some solution for this.
Thank you.[/b] |
Can you provide a dump of the message descriptor and a hex byte dump of the message data?
eg. Using MO71 browse, or using amqsbcg sample program.
This will reveal the CCSID of the message and the format of the data.
_________________
Glenn |
|
| Back to top |
|
|
| Jeffries |
| Posted: Tue Mar 28, 2023 6:30 am Post subject: |
|
|
Newbie
Joined: 27 Jan 2023
Posts: 4
|
Hi All,
Thanks all for your response.
Below is the response for some of your queries.
The CCSID is 437, format is MQSTR also i am sending the a portion of the message to provide a better clarification on this request from my end.
[ 364 bytes] Message Descriptor (MQMD)
StrucId :'MD '
Version :2
Report :00000000
Message Type :8 (Datagram)
Expiry :-1
Feedback :0 (None)
MQEncoding :0x'222'
CCSID :437
Format :'MQSTR '
Priority :4
Persistence :1 (Persistent)
Message Id :C S Q XXX . . . . { . b .
C3E2D840D5D4D4D64040404040404040DD0F5B6A8B328222
'...@....@@@@@@@@..[j.2."'
Correl. Id :. . . . . . . . . . . . . . . . . . . . . . . .
000000000000000000000000000000000000000000000000
'........................'
Backout Cnt. :0
ReplyToQ :' '
ReplyToQMgr :'XXXX '
UserId :'XXXXCHIN '
AccountingTkn:. . XXXXC H I N 3 6 F 9 3 A E 0 . . 9 . . . . . . . . . . .
1A0FD5D4D4D6C3C8C9D5F3F6C6F9F3C1C5F00036F93AE0000000000000000000
ApplIdentity :' '
PutApplType :11 (Windows NT)
PutApplName :'Unknown '
Put Date :'XXXXXXXX'
Put Time :'XXXXXXXX'
ApplOriginDat:' '
Group Id :. . . . . . . . . . . . . . . . . . . . . . . .
000000000000000000000000000000000000000000000000
Msg Seq No. :1
Offset :0
MsgFlags :00000000
Original Len.:-1
3030314C 31333030 38353732 364C3144 314E314C 31323032 33303332 36303233 31333632 30323330 33323532 001L130085726L1D1N1L120230326023136202303252
32333133 36373237 20202020 20202020 20202020 4E2F4120 20202020 20204E20 20202020 0A303032 37363032 23136727 N/A N .0027602
33354546 30412020 20202020 20202030 30303030 30303034 30202020 20202020 20202020 20202020 20202020 35EF0A 0000000040
20202020 20202020 20202020 20202020 20202020 20202020 20202020 200A3030 32373630 3233394B 53304220 .002760239KS0B
20202020 20202020 30303030 30303030 36362020 20202020 20202020 20202020 20202020 20202020 20202020 0000000066
20202020 20202020 20202020 20202020 20202020 20200A30 30323930 31323235 52423041 20202020 20202020 .002901225RB0A
20303030 30303030 30393220 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 0000000092
20202020 20202020 20202020 2020200A . |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Mar 28, 2023 2:55 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Since we can see that your message is in single-byte ASCII, I'm going to ask one of my questions again. Does your mainframe application use MQGET with MQGMO_CONVERT?
Can you show us an example of the output you are seeing on the mainframe side? i.e. show us where these dots are appearing?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Mar 28, 2023 3:47 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
I can see hex '0A' in 4 places in the message data. This is a Line Feed character in ASCII PC DOS code page 437.
It may be displayed as '.' by a mainframe message viewer, and has no direct conversion equivalent in EBCDIC code pages such as 37, 500.
_________________
Glenn |
|
| Back to top |
|
|
| Jeffries |
| Posted: Tue Mar 28, 2023 9:43 pm Post subject: |
|
|
Newbie
Joined: 27 Jan 2023
Posts: 4
|
Hi All,
Please use the below URL to view the output of the message on the Mainframe side and let me know for more clarifications required.
https://tinypic.host/i/Bmhe4
Thank you |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Mar 29, 2023 1:42 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
From the picture it looks like Glenn was spot on, it is indeed the 0A bytes that are causing the dots.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Jeffries |
| Posted: Wed Mar 29, 2023 2:20 pm Post subject: |
|
|
Newbie
Joined: 27 Jan 2023
Posts: 4
|
Thanks all for the inputs.
If 0A bytes that are causing the dots, what action need to be taken to avoid.
Please provide your suggestions.
Thank You. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Mar 29, 2023 2:33 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| Jeffries wrote: |
If 0A bytes that are causing the dots, what action need to be taken to avoid.
Please provide your suggestions. |
That rather depends on what you need. Is the intention of the 0A bytes when put into the message on Windows to cause a "new-line" in your message?
Alternatively, if there is no requirement for a new-line in the message, they could be replaced by spaces and you'd not have any conversion problems. It all depends on the processing of the message. What is SUPPOSED to be in that position when the message is received?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 29, 2023 3:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
More:
Windows follows the original MS-DOS convention of a carriage return plus a line feed (CRLF) for line endings, operating systems like Linux and Mac use only the line feed (LF) character.
So, basically, CRLF and LF indicate end-of-line of data. In m/f speak, the function of CRLF/LF is to separate one logical record from another logical record.
z/OS and z/VM editors allow you to specify the logical record length, which is very helpful when viewing data.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Mar 30, 2023 2:13 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
More:
Windows follows the original MS-DOS convention of a carriage return plus a line feed (CRLF) for line endings, operating systems like Linux and Mac use only the line feed (LF) character.
So, basically, CRLF and LF indicate end-of-line of data. In m/f speak, the function of CRLF/LF is to separate one logical record from another logical record.
z/OS and z/VM editors allow you to specify the logical record length, which is very helpful when viewing data. |
Which is very curious, because its a Windows code page, and if text line records were meant to represented in the message, CRLF should be used as the end of line, not LF on its own. However, CRLF and LF are not really z/OS concepts. I'm not sure what happens when z/OS MQ tries to convert these to an EBCDIC code page.
Referring to the OP, the dot is an artefact of whatever you are using to view the message. Its not a problem with the message data, therefore no solution is required?
_________________
Glenn |
|
| Back to top |
|
|
|
|
