PATHSEND Data disturbance

Discussion:

(too old to reply)

Henrik Paludan-Mørk

2020-10-03 18:19:35 UTC

We are sending a pathsend from a native file code 500 program on X system to a file code 100 TNS program across 2 pathways.
We are sending a payload of 26 characters over the line. the payload length is variable in nature, so the receiving program UNSTRINGs to get the data as tags.

in the Xinspect debugger in the sending program it looks like this:

7: SERVERCLASS-SEND-AREA =
PATHMON-NAME = "\DKT.$BMSB "
PATHMON-NAME-LEN = 10
SERVER-CLASS-NAME = "FHGSV497 "
SERVER-CLASS-NAME-LEN = 8
BUFFER = X"00" X"00" " " X"00" X"00" X"00" X"00" ' ' <repeats 20 tim
es>, ' X"00" ' <repeats 18 times>, "8=FIX.4.4|9=5|35=5|10=168|", ' ' <repeats 31924 times>

so the payload is "8=FIX.4.4|9=5|35=5|10=168|" + lots of spaces.

when the TNS file code 100 program reads $receive in, we get this string:
(clip from INSPECT in receiving end)

-$Y9ST(STEP 1 V)-d req-1
MESSAGE-IN.REQ-1 =
W-UXXPA100-FYLD = ?0 ?0 " " ?0 ?0 ?0 ?0 " " ?0 ?0 ?0
?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0
W-DATA = "8=FIX.4.4|9=5|35=5|10=168|01\DKT.$ZHOME

Suddenly there is an alien occurrence of "01\DKT.$ZHOME" in the string being received. it simply isnt there in the sending program.
We are scratching necks. Normally one would assume differences in declaration of variables on the 2 sides, but all seems to match.

I had expected the file code 500 program to not initialize memory, but i cannot fault the code here.

Has anyone else tried this? does the alien interference contents ring any bells?

My Best,
Henrik P

Randall

2020-10-03 19:26:40 UTC

Permalink

Post by Henrik Paludan-MÃ¸rk
We are sending a pathsend from a native file code 500 program on X system to a file code 100 TNS program across 2 pathways.
We are sending a payload of 26 characters over the line. the payload length is variable in nature, so the receiving program UNSTRINGs to get the data as tags.
7: SERVERCLASS-SEND-AREA =
PATHMON-NAME = "\DKT.$BMSB "
PATHMON-NAME-LEN = 10
SERVER-CLASS-NAME = "FHGSV497 "
SERVER-CLASS-NAME-LEN = 8
BUFFER = X"00" X"00" " " X"00" X"00" X"00" X"00" ' ' <repeats 20 tim
es>, ' X"00" ' <repeats 18 times>, "8=FIX.4.4|9=5|35=5|10=168|", ' ' <repeats 31924 times>
so the payload is "8=FIX.4.4|9=5|35=5|10=168|" + lots of spaces.
(clip from INSPECT in receiving end)
-$Y9ST(STEP 1 V)-d req-1
MESSAGE-IN.REQ-1 =
W-UXXPA100-FYLD = ?0 ?0 " " ?0 ?0 ?0 ?0 " " ?0 ?0 ?0
?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0 ?0
W-DATA = "8=FIX.4.4|9=5|35=5|10=168|01\DKT.$ZHOME
Suddenly there is an alien occurrence of "01\DKT.$ZHOME" in the string being received. it simply isnt there in the sending program.
We are scratching necks. Normally one would assume differences in declaration of variables on the 2 sides, but all seems to match.
I had expected the file code 500 program to not initialize memory, but i cannot fault the code here.
Has anyone else tried this? does the alien interference contents ring any bells?
My Best,
Henrik P

Hi Henrik,

It looks like the extra data is in the server not in the sender. The "01\DKT.$ZHOME" is after 26 bytes, so it looks like it is what is in memory on the server side. There is no initialization of the buffer being read through READUPDATEX beyond the length of the number of bytes read. The contents beyond the bytes read count are whatever was in memory in the server before the IO completes. Note that if you are using NOWAIT I/O, there is absolutely no guarantee of what happens to your buffer while the I/O has not completed. Trying sticking at the bytes read position in your buffer, since it looks like you are depending on NULL-termination.

Regards,
Randall

Henrik Paludan-Mørk

2020-10-03 21:05:15 UTC

Permalink

Hi Randall, the fault was actually an ancient one, the old Cobol teacher got a dust-off.
The problem was a READ $receive. the solution was a READ $RECEIVE INTO My-Record.
when you read a record off the file, which is not as long as the record area, you do not get space-fill in the end. but risk random memory fill.
only READ INTO delivers that. ancient, knowledge. Already the old egyptians .

Happy to crack THIS nut.

//Henrik P

Post by Randall

Hi Henrik,
It looks like the extra data is in the server not in the sender. The "01\DKT.$ZHOME" is after 26 bytes, so it looks like it is what is in memory on the server side. There is no initialization of the buffer being read through READUPDATEX beyond the length of the number of bytes read. The contents beyond the bytes read count are whatever was in memory in the server before the IO completes. Note that if you are using NOWAIT I/O, there is absolutely no guarantee of what happens to your buffer while the I/O has not completed. Trying sticking at the bytes read position in your buffer, since it looks like you are depending on NULL-termination.
Regards,
Randall

Randall

2020-10-04 21:19:50 UTC

Permalink

Post by Henrik Paludan-MÃ¸rk
Hi Randall, the fault was actually an ancient one, the old Cobol teacher got a dust-off.
The problem was a READ $receive. the solution was a READ $RECEIVE INTO My-Record.
when you read a record off the file, which is not as long as the record area, you do not get space-fill in the end. but risk random memory fill.
only READ INTO delivers that. ancient, knowledge. Already the old egyptians .
Happy to crack THIS nut.
//Henrik P

Post by Randall

Hi Henrik,
It looks like the extra data is in the server not in the sender. The "01\DKT.$ZHOME" is after 26 bytes, so it looks like it is what is in memory on the server side. There is no initialization of the buffer being read through READUPDATEX beyond the length of the number of bytes read. The contents beyond the bytes read count are whatever was in memory in the server before the IO completes. Note that if you are using NOWAIT I/O, there is absolutely no guarantee of what happens to your buffer while the I/O has not completed. Trying sticking at the bytes read position in your buffer, since it looks like you are depending on NULL-termination.
Regards,
Randall

Glad it was simple :)