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