Use these variables with your SQL functions to help you customize the way FUNCTION blocks are processed. You must define these variables before referencing them. You can set or reference report variables in any Net.Data macro block.
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X |
| X | X | X | X |
Net.Data uses this variable to establish a connection with the specified database. On all platforms, except OS/400, only one database connection is allowed for each macro unless you use Live Connection to set up a persistent connection. If this variable is not defined, an error occurs when attempting to access a database.
On the OS/400 platform, you can establish multiple database connections. In addition, the DATABASE variable is optional. Net.Data for OS/400, by default, specifes DATABASE="*LOCAL"; the DTW_SQL language environment uses the local relational database directory entry.
You can change DATABASE for different HTML blocks in the same Net.Data macro, as shown in examples 2 and 3.
Examples
Example 1: Any SQL in this Net.Data macro is performed on the CELDIAL database.
%DEFINE DATABASE="CELDIAL"
Example 2: The HTML block queries the database DB2D1, regardless of what the previous value for DATABASE was.
%HTML(monthRpt){
@DTW_ASSIGN(DATABASE, "DB2D1")
%INCLUDE "rpthead.htm"
@getRpt()
%INCLUDE "rptfoot.htm"
%}
Example 3: This example is the same as example 2, but uses DEFINE to set the DATABASE variable instead of DTW_ASSIGN. This works because Net.Data processes the entire Net.Data macro from the top each time an HTML block is called.
%DEFINE DATABASE="DB2D1"
%HTML(monthRpt){
%INCLUDE "rpthead.htm"
@getRpt()
%INCLUDE "rptfoot.htm"
%}
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X | X | X | X | X | X |
Specify which case to use for SQL commands. If this variable is not defined, the default action is not convert the SQL command. Specify "UPPER" or "LOWER" to force all characters in the SQL command to upper or lower case.
Examples
Example 1:
%DEFINE DB_CASE="UPPER"
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
|
|
|
| X |
|
|
|
|
Net.Data for OS/390 uses this variable to allocate a plan for a connection to a local DB2 subsystem. The variable specifies the plan name of a plan for the Net.Data SQL language environment at the local DB2 subsystem that Net.Data will access. An error occurs if the macro attempts to execute an SQL function when this variable is not specified within the Net.Data for OS/390 configuration file and also not defined within a macro.
Examples
Example 1:
%DEFINE DB2PLAN="DTWGA105"
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
|
|
|
| X |
|
|
|
|
Net.Data for OS/390 uses this variable to establish a connection to a local DB2 subsystem. The variable specifies the subsystem ID of the local DB2 subsystem that Net.Data will access. Only one local database connection is allowed for each macro. An error occurs if the macro attempts to execute an SQL fuction when this variable is not specified within the Net.Data for OS/390 configuration file and not defined within a macro.
Examples
Example 1:
%DEFINE DB2SSID="DB2G"
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X | X | X | X | X | X |
This variable identifies a TABLE variable that the SQL language environment uses to store table data from a query. This table can then be used later, for example, in a REXX program that analyzes table data.
Examples
In this example, the REXX FUNCTION block calls the REXX program anzTbl.cmd, which uses the table variable theTable to analyze data in the table. The variable theTable was returned from a previous SQL function call.
%DEFINE theTable = %TABLE(2)
%DEFINE DTW_SAVE_TABLE_IN = "theTable"
%FUNCTION(DTW_SQL) doQuery() {
SELECT MODNO, COST, DESCRIP FROM EQPTABLE
WHERE TYPE='MONITOR'
%}
%FUNCTION(DTW_REXX) analyze_table(myTable) {
%EXEC{ anzTbl.cmd %}
%}
%HTML(doTable) {
@doQuery()
@analyze_table(theTable)
%}
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
|
|
|
| X |
|
|
|
|
Net.Data for OS/390 uses this variable to establish a connection to a remote database server. The variable specifies the name by which the remote server is known to the local DB2 subsystem. The value of LOCATION must be defined in the SYSIBM.SYSLOCATIONS table of the Communications Database (CDB). If this variable is not defined within a macro, then any SQL requests made by the macro are executed at the local DB2 subsystem.
Examples
Example 1:
%DEFINE LOCATION="QMFDJ00"
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X |
| X | X | X | X |
Provides access to protected data by entering a user ID. Use this variable with PASSWORD to incorporate the security algorithms of DB2. The default is to use the user ID that started the Web server. You can hardcode this value in the Net.Data macro, or have the application user enter it in an HTML form.
Examples
Example 1: This example restricts access to the user ID DB2USER only.
%DEFINE LOGIN="DB2USER"
Example 2: This example shows a line you can include as part of an HTML form for application users to input their user IDs.
USERID: <INPUT TYPE="text" NAME="LOGIN" SIZE=6>
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X |
| X | X | X | X |
Provides access to protected data by entering a password. Use this variable with LOGIN to incorporate the security algorithms of DB2. You can hardcode this value in the Net.Data macro or have people enter it in an HTML form.
Examples
Example 1: This example restricts access to people with the password NETDATA only.
%DEFINE PASSWORD="NETDATA"
Example 2: This example shows a line you can include as part of an HTML form for application users to input their own passwords.
PASSWORD: <INPUT TYPE="password" NAME="PASSWORD" SIZE=8>
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X | X | X | X | X | X |
Hide or display the SQL of the query used on the Web browser. The default is to hide the SQL. Set this variable to YES to display the SQL sent to the database. Set it to NO to hide the SQL. Displaying the SQL during testing is especially useful to debug your Net.Data macros.
Examples
Example 1: This example shows how to display the SQL every time.
%DEFINE SHOWSQL="YES"
Example 2: This example shows how to specify whether to display SQL using HTML form input.
SHOWSQL: <INPUT TYPE="radio" NAME="SHOWSQL" VALUE="YES"> Yes
<INPUT TYPE="radio" NAME="SHOWSQL" VALUE="" CHECKED> No
Purpose
| AIX | HP-UX | OS/2 | OS/390 | OS/400 | SCO | SUN | Win NT |
| X | X | X | X | X | X | X | X |
Specifies the transaction scope for SQL commands. The default is "MULTIPLE", which means Net.Data issues a COMMIT only after all SQL commands in an HTML block complete successfully. An unsuccessful SQL command causes all previously executed SQL to the same database in that block to be rolled back. Specifying "SINGLE" means that Net.Data issues a COMMIT after each SQL command in an HTML block successfully completes.
On platforms other than OS/400 and OS/390, updates to the database receiving unsuccessful responses might be rolled back while the updates to the other databases accessed in the same HTML block might be committed when all of the following conditions are true:
If you access multiple databases from Net.Data using the DataJoiner software, you can achieve multiple database update coordination and consistency when updating from Net.Data.
On OS/400 and OS/390, TRANSACTION_SCOPE = "MULTIPLE" causes all IBM database updates issued from a single HTML block to be committed or rolled back together.
On platforms other than OS/400, the REXX, Perl, and Java language environments run in their own separate operating system processes. Thus, any database updates you issue from these language environments are commited or rolled back separately from database updates issued from a Net.Data macro file, regardless of the Net.Data TRANSACTION_SCOPE value.
Examples
Example 1:
%DEFINE TRANSACTION_SCOPE="SINGLE"