Getting the current environment

For security and consistency you should always 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, and sending out notifications (email). For other examples, have a look at the article on refreshing from production.

Ways to determine the current environment

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.

Some examples includes:

Option 1: Use the Environment Settings in PSOPTIONS.

This is configured under PeopleTools > Utilities > Administration > PeopleTools Options

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.

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.

Note that report nodes are stored in the system table PS_CDM_DIST_NODE.

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 PeopleTools > Process Scheduler > Process Types 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);

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()

Which option is the best?

Personally, I think that 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.

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.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License