Getting the Current Environment

For security and consistency you should wrap code that is environment specific around logic that determines the environment you are in.

You should apply this to anything you wouldn't want to run in a development environment the same way as a production environment. Some common examples include interfaces to 3rd party systems, sending out notifications (email) and dangerous database operations.

There are a number of ways to work out which environment you are in, and these vary in success depending on your environment and configuration. This article covers 4 options:

1. Use the Environment Settings in PSOPTIONS.
2. Use the distribution node in PS_SERVERDEFN
3. Look at the database name field in the process request table - PSPRCSRQST.DBNAME
4. Use the %DbName PeopleCode system variable
5. Query the database meta-tables.

Option 1: Use the Environment Settings in PSOPTIONS.

This is configured under:

You can set:

• An environment long name (a description for your environment, e.g. Development Master)
• An environment short name (typically your 8 character database name)
• A system type (e.g. Demo, Development, Production, Sandbox, System Test, Training etc)

As long as this information is maintained and kept to date between refreshes then this is certainly the best way to store information about your database. However, the issue with this approach is it relies on consistency and setup to work. It can fail for example if there is a refresh and PSOPTIONS doesn't get updated, so you think you are in production when in fact you are in test or development.

Option 2: Use the distribution node in PS_SERVERDEFN

Another option is to use the process scheduler server distribution settings. However this assumes that your report node definition name matches the database name, which may not always be the case. So this is not a very reliable way of getting the database name and one of the other options is a far better choice.

Option 3: Look at the database name field in the process request table - PSPRCSRQST.DBNAME

This is the database name passed through the process run parameters. If you have a look under:

For various process types that you can run through process scheduler (e.g. Application Engine, COBOL and SQR), this is usually the process scheduler variable %%DBNAME%%.

Option 4: Use the %DbName PeopleCode system variable

Very simple - here's a message box example:

MessageBox(0, "", 0, 0, "Database Name = " | %DbName);

This has the advantage of just "working" in PeopleCode without query the database.

Option 5: Query the database meta-tables.

Oracle: select name from v$database; Oracle: select ora_database_name from dual for the fully qualified database name Microsoft SQL Server: select db_name()

Of course this one is database platform specific.

Which option is best?

As usual, it depends here are the caveats:

• Option 1 can provide the most information provided that database information is maintained when new environments are created and refreshed. I like the fact that you can also store the database type. However, it has the issue of having to be maintained and updated which can mean errors with the data in the table.
• Option 2 is unreliable as it depends on the report node having the same name as the database. I've included it to show an option you should avoid as there are better ways to get the current environment.
• Options 3 and 4 use the internal database name. Option 3 should work after a refresh provided the environment is using the correct process schedulers. This appears to be same for Option 4 however you might want to verify this for yourself.
• Option 5 is quite reliable as it just queries the database itself but is database platform specific