NOTE: Migrating Code Without Changing It (Where Am I?)

Developing code that needs no change when being moved from development through test and into production is important. In such circumstances it can be useful to know what environment the code is running in. Environment-specific information can be held in a control file; to look-up the correct items of information in that control file the code needs to know what environment it's running in.

If your prescribed directory structure takes this into account, finding-out the environment can be easy. For instance, you might design a directory structure whereby the second-level directory specifies the environment: F:\PensionApp\\code\macros. If the default execution directory for the stored process server or workspace server is F:\PensionApp\live\code then we can get the environment as follows:

401 data _null_;
402   rc = libname('HERE','.');
403   put rc=;
404   dir = pathname('HERE');
405   put dir=;
406   env = scan(dir,2,'\');
407   put env=;
408   rc = libname('HERE',' ');
409 run;


rc=0
dir=H:\PensionApp\live\code
env=live

Note the use of the SCAN function. If you can't be sure of the top-level directories (the number of them may differ in different environments) but you know that the penultimate directory specifies the environment then you can use a negative value in SCAN. To explain:

DEVELOPMENT:  /home/helen/PensionApp/dev/code
TEST:  /PensionApp/test/code
PRODUCTION:  /PensionApp/live/code

Use scan(dir,-2,'\') to find the penultimate directory name. The negative word number (-2) tells SCAN to count from the right-hand end of the string instead of the left-hand.