Re: Regarding Decryption of AES128 encrypted data in RPGLE and query regarding CRC 32

There is an "ENCRYPT" in v7.4, but I think it is for compatibility only .  Use the ones with algorithm.

The 'k1' is not valid as a key, red the manual about minimal key length.

On 9/20/19 9:44 AM, Rob Berendt wrote:

Ok, so you've proven you do have some rudimentary knowledge on how to do embedded SQL in RPGLE. That's a good start.

However you lead me to believe you have a deep reluctance to read the link I previously provided. There is no ENCRYPT function in DB2 for i. There are only those ENCRYPT* functions listed at:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/db2/rbafzscale.htm

The issue is that it's not even getting to the point of telling you that the function doesn't exist (yet). It's failing on a little known obscure error. General practice is that one ALWAYS puts a blank after a column in a SQL list.
This: ('abcde','k1',1)
Becomes: ('abcde', 'k1', 1)
Why is this the best practice? Because SQL gets confused as to whether or not you are using the comma as a decimal point or as a separator. Notice it didn't fail on the first comma? That was because 'k1' is obviously not a number following a decimal point. It died on the second one ',1' because it was thinking this just might a number after a decimal point. Some countries use the comma as their decimal point.

You may wonder why it didn't fail (yet) on the ENCRYPT. First because it just wanted to handle one error at a time. Secondly because you can always create your own functions, in either RPG or SQL. In SQL you can use the CREATE FUNCTION. In RPG you create subprocedures (not subroutines). So it hasn't gotten around to that error yet.

Rob Berendt

-- Este e-mail fue enviado desde el Mail Server del diario ABC Color -- -- Verificado por Anti-Virus Corporativo Symantec --