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)
midrange.com
