Scripting Preprocessing


What are some of the ways that preprocessing can be useful?

The following example shows a couple practical applications of external and internal preprocessing variables.

We first use preprocessing to find an external environmental variable name, WH_UTL_DIR, where the value of the name is a shared directory that contains a file of commonly-used Warehouse FUNCTIONS and DEFINEs.

We then create two internal preprocessing variables, node and database, with which to open a database. Should the open fail, we trap the error and exit the script.

* script cannot run if the environment variable is missing
# if not defined(WH_UTL_DIR)
#     print ‘WH_UTL_DIR : environment variable missing’
#     exit 1
# endif
* include the common functions and defines
xeq ${WH_UTL_DIR}\utllib.whs

* set preprocessing variables for the data source
# setvar node = &
“remote sol22 ” &
“user=qa ” &

# setvar database = &
“oracle scott/tiger ” &
“home=/b/u01/oradata/ora ” &

* open the data source
open db ${node} ${database}
#  if wherrno <> 0
#     print “wherror”, wherrno, “on db open :”, node
#     exit 1
# endif


Why does my script fail when I access an environmental variable while preprocessing?

The variable TRACE_FLAG is used in many of my scripts in the following manner:
# … do something…
# endif

When I set TRACE_FLAG to “True”, the script fails at compile time with a Warehouse error 8284. However when I set the TRACE_FLAG variable to “TRUE”, the script doesn’t fail and the condition evaluates correctly. Is there some case sensitivity that I need to be aware

Case sensitivity is indeed a contributing factor.  A test for the condition # if TRACE_FLAG in the preprocessing environment produces one of four results: true, false, neither, or undefined variable (WHERR 8271). The WHERR 8284 is generated when the test evaluates to the third condition, neither.

As the Warehouse Manual explains, the preprocessor variables TRUE and FALSE are not the same as the script constants $TRUE and $FALSE. The preprocessor expects that if an environmental variable is going to be tested as a boolean, then that variable should contain either TRUE or FALSE (uppercase). If the environmental variable contains anything else, then it will evaluate to neither true nor false and Warehouse will generate the error you saw. In order to test an existing environmental variable as a boolean without incurring an error, try the following:



What happens if I modify an environmental variable while preprocessing?

The short answer is that for this script you have modified the contents of the environmental variable and that any subsequent reference in this script to that variable name will access the modified contents. For example, assuming that the environmental variable FOO has been set in the shell to bar:

1> # print FOO
2> # setvar FOO = ‘bar_none’
3> # print FOO
4> print ‘${FOO}’


If you wish to retain the original contents of the environmental variable, you should make use of a second preprocessing variable:

1> # setvar FOO2 = FOO
2> # print FOO, FOO2
bar bar
3> # setvar FOO2 = ‘bar_none’
4> # print FOO, FOO2

bar bar_none


How can I determine what lines of preprocessing code have and haven’t been executed?

Examine the compilation output, since preprocessing occurs during that phase. If the line of code is flagged with an asterisk, it has not been executed; otherwise it has been executed.

In the example below, the environment variable WH_UTL_DIR is not initially defined. So the code within the first if not defined( block is executed, setting WH_UTL_DIR. In the compilation output these lines are not flagged with an asterisk.

The second time the same check is made, the code within the if not defined( block is skipped. In the compilation output the lines that have been skipped (7-9) are flagged with an asterisk.

1> # if not defined(WH_UTL_DIR)
2> #       print ‘\tWH_UTL_DIR : environment variable missing, will be set’
WH_UTL_DIR : environment variable missing, will be set
3> #       setvar WH_UTL_DIR = ‘c:\\mydir’
4> # endif
6> # if not defined(WH_UTL_DIR)
7* #       print ‘\tWH_UTL_DIR : environment variable missing’
8* #       exit
9* # endif
11> # print WH_UTL_DIR



How can I code a script to conditionally compile based on platform type? 

Simpler than invoking and parsing an external system command is to examine the version of the Warehouse client that is compiling the script. The following script output will give you an idea of what you can do:

Warehouse 3.00.3440-W (c) Taurus Software, Inc. 2004
Installed for: Taurus Software Inc.
1> print “You are running ${WHVERSION}”
2> print “This version of Warehouse “; token(“${WHVERSION}”,2,” -“); &
3>       ” with suffix “; str(“${WHVERSION}”,len(“${WHVERSION}”), 1); ” runs under “;
5> #IF str(WHVERSION,len(WHVERSION),1) = “W”
6>        print “Windows”
7> #ELSE IF  str(WHVERSION,len(WHVERSION),1) = “L”
8*        print “Linux”
9* #ELSE
10*        print “unrecognized OS suffix “; str(“${WHVERSION}”,len(“${WHVERSION}”), 1)
11* #ENDIF
12> go
You are running Warehouse 3.00.3440-W
This version of Warehouse 3.00.3440 with suffix W runs under Windows