On 11-Jun-2014 13:16 -0500, Alan Shore wrote:
I am trying to create a Hex HMAC encryption
Here is the result

<<SNIP>> when I attempt to trim this, or move it to another field,
all the x'40's are dropped and the result is


Which is NOT equal to


When working with binary stream data, there are a number of issues that can arise; sometimes the constraints on the data prevent ever seeing such issues. The given case whereby a binary stream might end with a 0x40 is such an issue, because that is the EBCDIC blank [aka space] /character/ data. Various functions like STRIP, TRIM, etc. are incompatible in such a scenario, because those scalar functions when operating against a "character" data type will treat that data as a character string; as one might expect and hope for. Thus one could conclude that the chosen data type in such a scenario was a poor choice. One resolution could be to use the BINARY data type; note however, if a constraint on the data does not preclude significant trailing 0x00, then trimming functions again\still could be a problem.

However other possible solutions are available when overlooking the data type nuances, and simply restricting the operations on the data according to *length* information provided by the interfaces; e.g. after the encryption, the length of the result should be known, and typically such a length feedback would be utilized. Thus instead of a RTRIM() function, a SUSBTR() function could be used to extract the specific portion of the data from the buffer; i.e.:

The undesirable result from trimming the significant trailing /blank/ occurs with:

SET :AnotherField = RTRIM(:ResultFeld)

Whereas the desirable result maintaining the trailing /blank/ occurs with:

SET :AnotherField = SUBSTR(:ResultFeld, 1, :EncryptedResultLen)

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page