Hi, I've been using the Mendelson OFTP2 product for several years now and am largely satisfied with it.
Recently, however, with a partner we've been exchanging data with for some time (but *have* been having repeated interrupted transmissions with [I may post on that issue later]), have noticed that several transactions have gone through where my Mendelson (they also are using Mendelson OFTP2, I think the most recent community version) thinks the file has transmitted successfully, but when they reply w/ their EERP, I see this message in the detail log:
[Sep 18, 2016 4:47:31 PM] [Session 147423524838915] The computed hash value of the transmitted data differs from the received hash value of the received acknowledgement (EERP/NERP). Generated hash value: [e7 97 58 69 3d eb 85 8a 43 50 16 46 40 fd 85 ad e3 9d 22 8a], received hash value: [26 14 4b 52 91 d6 c8 92 ec a9 74 6c ad 14 48 0f 1d df 41 20]
This is critical! In fact, what I know happened on this last one on Sep 18th is that they received a significantly truncated version of the file, with maybe only 60-80% of the total.
My first main question is, why is my Mendelson treating this transmission as successfully completed when the hashes don't match? Is there a setting I can change to affect this?
If not, I'd submit that this is a bug that I've somehow stumbled onto and should be reviewed ASAP, such that Mendelson properly marks (and runs the 'Command on msg receipt (error)' script, if any) the transmission as failed, as it already does for me in other situations where the transmission is for some reason detected as having been interrupted.
I'll attempt to provide any further data if needed, but was wondering if a developer knew the answer to this problem already, or could take a quick glance at the code to see if there was an oversight that allowed this particular error to slip through without triggering a failure of the whole transmission.