Pass encrypted variable to job

surfsup · Post by **surfsup** » Fri Sep 02, 2016 2:00 am

Hi folks,

Due to non-technical reasons, I am trying to pass the value of an encrypted environment variable to a DataStage job from within a calling sequence. The environment variable name is not known at design time and therefore is not a parameter to the job.

I found an obscure technote that DS is somehow meant to detect if a value supplied as a parameter from a file is encrypted, but I am not sure if this also applies when the value is passed directly. At the moment, the encrypted value is reencrypted and this results in the wrong value being used in the job.

I can easily decrypt DS encrypted values, but it requires manual intervention. Has anyone either manage to pass encrypted values to a job or decrypt the password through code? (Please no "that would defeat the purpose of encryption" posts since DS encryption is not secure; storing the value as unencrypted is also not an option).

Cheers,
A

qt_ky · Post by **qt_ky** » Fri Sep 02, 2016 4:47 am

It looks like the encryption in version 11.3 or newer is quite strong. Prior versions used something I would call a weak encoding scheme. I won't call it encryption.

Could you share the technote link? I'm not quite clear on your goals or questions yet. What kind of resolution are you looking for, one that will achieve better security or one that will do the opposite, etc.?

surfsup · Post by **surfsup** » Fri Sep 02, 2016 6:06 am

The tech note is at this address http://www-01.ibm.com/support/docview.w ... wg1JR47902 , but I since found out it is only present in v11 (this is the reason why it wasn't working on v9).

I am trying to find a way to duplicate the parameter set functionality (for non-technical reasons that I will not go into).

One way I thought of was to have the parameter set values as environment variables and then have them grouped in a set in some sort of metadata table. It all works, bar this small encryption ... erm ... encoding snag.

FranklinE · Post by **FranklinE** » Fri Sep 02, 2016 8:50 am

I do respect your desire to not divulge the "non-technical reasons", but there's a basic problem I have with all such situations: why would a variable not be known at design time?

How do you know if such a variable is what you need to use (in this case) as an encrypted value? Seems like a lot of extra work to accommodate those "reasons", and while I would easily sympathize with non-technical interference, I'd want to reject it in favor of something that at least remotely conforms with basic design standards.

My sympathy is fully for developers who must try to accommodate, um, ridiculous (a stronger word not used) requirements.

For any singular problem point, my first instinct is to build an isolated process around it to create a reasonable "hook" I can use in code. Would it be possible for you to do something like that, create a process (script, specialized job) along that line?

Good luck.

surfsup · Post by **surfsup** » Fri Sep 02, 2016 2:31 pm

Variables are not "known" since I'd need to replicate parameter set functionality without using parameter sets (e.g. a new parameter set value set requires 4 new project variables and the calling sequence cannot be recompiled/ edited - the value is retrieved at run-time from the environment).

The untried resolution would be to install the IBM patch.

ray.wurlod · Post by **ray.wurlod** » Fri Sep 02, 2016 3:59 pm

Can you use an environment variable parameter with a default value of $ENV ?

surfsup · Post by **surfsup** » Mon Sep 05, 2016 9:07 am

Don't think so - I've never used $ENV, but if I understand correctly, it sets the default parameter to the value of the environment variable at compile time. Subsequently, if a value would need to be changed the job would have to be recompiled in the right environment. This wouldn't work.

chulett · Post by **chulett** » Mon Sep 05, 2016 11:59 am

It picks up the current value of the environment variable at runtime.

ray.wurlod · Post by **ray.wurlod** » Mon Sep 05, 2016 4:54 pm

It picks up the value of the environment variable from the shell. At run time, as Craig noted. You should also investigate the other special values $PROJDEF and $UNSET, to round out your knowledge.

surfsup · Post by **surfsup** » Tue Sep 06, 2016 2:37 am

Thanks - I've used these magic settings ($PROJDEF), but I obviously misunderstood $ENV. Though now I'm equally not sure how to use it.

Inside a job, whether an environment value is retrieved from the shell or project definition is irrelevant, right? So it would only make sense to use whenever changing an environment variable is easier from the shell than from the Admin client which I rarely found to be the case.

roy · Post by **roy** » Thu Sep 08, 2016 8:20 am

Hi,
Can you use parameter set files?
they can be set with limited access and can be updated as needs be
would that work for you?