MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » June 2014

RE: Attempting to use SQL HEX



fixed

Jon, Scott, Chuck
MUCH appreciated for your help (plus any one else that I am forgetting)
Using subst seems to be the answer, along with changing the field to varying
This is in a test program, which I created using logic from a serviceprogram - now that I have COMPLETELY bastardized it from the original version, I have to make the same changes to my service program



Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, June 11, 2014 2:51 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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)

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.





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

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact