Re: Attempting to use SQL HEX

On 11-Jun-2014 13:16 -0500, Alan Shore wrote:

<<SNIP>>
I am trying to create a Hex HMAC encryption
<<SNIP>>
Here is the result
fbc2164ef24fe7c9e55bc1e09e03a0c674a5114619b071c3a24faf2eddeede40

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

FBC2164EF24FE7C9E55BC1E09E03A0C674A5114619B071C3A24FAF2EDDEEDE

Which is NOT equal to

fbc2164ef24fe7c9e55bc1e09e03a0c674a5114619b071c3a24faf2eddeede40

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)