We have several batch scripts which require logging into the Hyperion
server to run. The id and password are in clear-text. My manager is
concerned about Sarbanes-Oxley compliance and that this is an audit
exception. Access to the server is limited to individuals in the IT
group but even so she would prefer that the account and password not
be in clear-text. How are other companies handling this situation?

Thanks in advance.

DJK

dkunko (AT) qrinc (DOT) com (djk) wrote in message news:<6347cbb4.0405190837.11a83b39 (AT) posting (DOT) google.com>...
We use templates scripts.

For example, let's consider a template called load.tmpl for loading
data into a database using a rule:

login server ##UID## ##PSW##;
select "##APP##" "##DB##";
import 3 "/home/essbase/load/L_Sbkr.txt" 4 "Y" 2 "L_All" "N"
"/home/essbase/load/L_Sbkr.txt";
exit;


using a Perl script we replace the meta-tags this way:

##UID## ==> john45
##PSW## ==> fine42day
##APP## ==> TBC
##DB## ==> TBC

and generate a temporary Essbase script using the process number as
extension (ex: load.44512). BTW, we are running on a AIX box.

login server john45 fine42day;
select "TBC" "TBC";
import 3 "/home/essbase/load/L_Sbkr.txt" 4 "Y" 2 "L_All" "N"
"/home/essbase/load/L_Sbkr.txt";
exit;

this script is run from inside a Perl script (using a system call) and
once it finishes, the Essbase script (load.44512) is deleted. No trace
of the id and password. From within the Perl script, you can manage
the id and psw the way you want. For example, getting them from a
table, from an encrypted file, etc.

Another choice it to use the Essbase.pm Perl module that create
connections in a formal way, no need for system calls.

Hope this helps.

Regards,
Marcelo