From Support
Configuring Net.Data
Net.Data for OS/400 is delivered as a standard part of:
IBM TCP/IP Connectivity Utilities/400 V3R2, V3R7, V4R1, and V4R2
IBM HTTP Server for AS/400 V4R3
There is nothing extra to buy; and there is no Net.Data software that you need to download and install.
The AS/400 TCP/IP and HTTP Server software that you need comes standard with OS/400, but is optionally installed. The following optional software should be installed on your system for the following versions of the OS/400 operating system:
For IBM OS/400 operating system Version 3 Release 2, Version 3 Release 7, and subsequent versions and releases (57xx-SS1):
IBM TCP/IP Connectivity Utilities/400 (57xx-TC1)
For IBM OS/400 operating system Version 4 Release 3, and subsequent versions and releases (57xx-SS1):
IBM HTTP Server for AS/400 (57xx-DG1)
After installing Net.Data, complete the steps described in the following sections to configure Net.Data for OS/400. The steps include:
Copying the Net.Data Program Object to Your CGI-BIN Library
Configuring the Web Server
Customizing the Net.Data Initialization File
Creating an Initialization File
Granting Access Rights to Objects Accessed by Net.Data
--------------------------------------------------------------------------------
Copying the Net.Data Program Object to Your CGI-BIN Library
Before using Net.Data, you must copy the Net.Data program object to the CGI-BIN library and provide access rights to the object.
To copy the Net.Data program object:
Using the Create Duplicate Object (CRTDUPOBJ) command, copy the Net.Data program object, DB2WWW, from the QTCP library to a CGI-BIN library.
OS/400 V4R3 users: Use the program object in library QHTTPSVR; the program object in the QTCP library routes Net.Data requests to the QHTTPSVR library.
Change the DB2WWW program object in the CGI-BIN directory so that the user profile that CGI programs run under has access to the program object.
By default, the DB2WWW program object authority for *PUBLIC users is set to *EXCLUDE. To provide access to the program object, change the program object's authority for *PUBLIC users to *USE, or specifically give the user profile access to the DB2WWW program object.
You can copy the Net.Data program object to multiple libraries for different applications. This allows you to have more than one version of the Net.Data initialization file or multiple protection schemes. See Customizing the Net.Data Initialization File for more information about the Net.Data initialization file; see Using Authentication for information on authentication.
To copy the Net.Data program object to multiple libraries:
Copy the Net.Data program object, DB2WWW, to a library using the steps listed above.
Associate the Net.Data program object with a CL program in each library.
Create a CL program that calls the Net.Data program object located in the library specified in step 1.
Copy the CL program to each library.
In effect, the CL program you created becomes the Net.Data program object. If you do not associate the program object with a CL program, and copy the Net.Data program object DB2WWW to the different libraries, you get a -901 SQL code when using the SQL language environment.
In the following sections, the CL program you created should be treated as the Net.Data program object, if you chose to create the CL program to call Net.Data.
--------------------------------------------------------------------------------
Configuring the Web Server
The Common Gateway Interface (CGI) is an industry-standard interface that enables a Web server to invoke an application program such as Net.Data. Net.Data's support for CGI lets you use Net.Data with your favorite Web server.
Configure the Web server to invoke Net.Data by adding directives to the HTTP configuration file so that Net.Data gets invoked.
For example, assuming the Net.Data program object resides in library CGI, then the following directives redirect Net.Data requests to /QSYS.LIB/CGI.LIB/DB2WWW.PGM:
Map /cgi-bin/db2www/* /QSYS.LIB/CGI.LIB/DB2WWW.PGM/*
Map /CGI-BIN/DB2WWW/* /QSYS.LIB/CGI.LIB/DB2WWW.PGM/*
Exec /QSYS.LIB/CGI.LIB/*
The Map directives map entries using the format /cgi-bin/db2www/* to the library where the Net.Data program resides on your system. (The asterisk (*) at the end of the string refers to anything that follows the string.) Both upper- and lower-case map statements are included, because the directives are case sensitive. In this example, both Map statements point to the same location.
The Exec directive enables the Web server to execute any CGI programs in the CGI library. Specify the library where the program resides (not the program itself) on the directive.
Pass directives are not used by Net.Data. If you want to simplify your URL, then use the MACRO_PATH statement in a Net.Data initialization file, discussed in the following section.
--------------------------------------------------------------------------------
Customizing the Net.Data Initialization File
The information contained in the initialization file is specified using three types of configuration statements, described in the following sections:
Configuration Variable Statements
Path Configuration Statements
Environment Configuration Statements
See Creating an Initialization File to learn how to create an initialization file.
The sample initialization file shown in Figure 2 contains examples of these statements.
Figure 2. The Net.Data initialization file
1 DTWR_CLOSE_REGISTRIES YES
2 MACRO_PATH /WWW/MACRO;/QSYS.LIB/WWW.LIB/MACRO.FILE
3 INCLUDE_PATH /WWW/MACRO;/QSYS.LIB/WWW.LIB/MACRO.FILE
4 EXEC_PATH /QSYS.LIB;/QSYS.LIB/WWW.LIB
5 ENVIRONMENT(DTW_REXX) /QSYS.LIB//QTCP.LIB/QTMHREXX.SRVPGM ( )
6 ENVIRONMENT(DTW_SQL) /QSYS.LIB/QTCP.LIB/QTMHSQL.SRVPGM
(IN DATABASE, LOGIN, PASSWORD, TRANSACTION_SCOPE, SHOWSQL,
DB_CASE, RPT_MAX_ROWS, START_ROW_NUM,
DTW_SET_TOTAL_ROWS, OUT DTWTABLE, SQL_CODE,
TOTAL_ROWS)
7 ENVIRONMENT(DTW_SYSTEM) /QSYS.LIB/QTCP.LIB/QTMHSYS.SRVPGM ( )
Line 1 sets the values of the configuration variables
Lines 2- 4 define paths to the files that Net.Data needs to access
Lines 5 - 7 define the environment statements that are available.
The text of each individual configuration statement must all be on one line. (An ENVIRONMENT statement is shown on several lines for readability.) The ENVIRONMENT statements are not needed if you do not plan to call any language environments in your Net.Data macros. Nor do you have to specify any of the path configuration statements if you fully qualify all references to files within the macro file.
The following sections describe how to create the initialization file and customize the configuration statements in the INI file.
--------------------------------------------------------------------------------
Configuration Variable Statements
Net.Data configuration variable statements set the values of configuration variables. Configuration variables are used for various purposes. Some variables are required by a language environment to work properly or to operate in an alternate mode. Other variables control the character encoding or content of the Web page being constructed. Additionally, you can use configuration variable statements to define application-specific variables.
The configuration variables you use depend on the language environments you are using, as well as other factors that are specific to the application.
To update the configuration variable statements:
Customize the initialization file with the configuration variables that are required for your application. A configuration variable has the following syntax:
NAME[=]value-string
The equal sign is optional, as denoted by the brackets.
The following sub-sections describe the configuration variables statements, used by Net.Data-supplied language environments, that you can specify in the initialization file:
DTW_SQL_ISOLATION: DB2 Isolation Variable
DTW_SQL_NAMING_MODE: SQL Table Naming Variable
DTWR_CLOSE_REGISTRIES: Open Web Registry Variable
DTW_SQL_ISOLATION: DB2 Isolation Variable
The DTW_SQL language environment uses the DTW_SQL_ISOLATION configuration statement to determine the degree to which the database operations executed by the DTW_SQL language environment are isolated from concurrently executing processes.
Syntax:
DTW_SQL_ISOLATION locking_method
Where locking_method is one of the following values:
DTW_SQL_NO_COMMIT
Specifies not to use commitment control. For the OS/400 operating system, do not specify this value if a relational database is specified in the relational database directory and the relational database is on a non-OS/400 system.
DTW_SQL_READ_UNCOMMITTED
Specifies locking for the objects referred to in SQL ALTER, COMMENT ON, CREATE, DROP, GRANT, LABEL ON, and REVOKE statements and the rows updated, deleted, and inserted. The objects are locked until the end of the unit of work (transaction). Uncommitted changes in other processes can be seen.
DTW_SQL_READ_COMMITTED
Specifies locking for the objects referred to in SQL ALTER, COMMENT ON, CREATE, DROP, GRANT, LABEL ON, and REVOKE statements and the rows updated, deleted, and inserted. The objects are locked until the end of the unit of work (transaction). A row that is selected, but not updated, is locked until the next row is selected. Uncommitted changes in other processes cannot be seen.
DTW_SQL_REPEATABLE_READ
Specifies locking for the objects referred to in SQL ALTER, COMMENT ON, CREATE, DROP, GRANT, LABEL ON, and REVOKE statements and the rows selected, updated, deleted, and inserted. The objects are locked until the end of the unit of work (transaction). Uncommitted changes in other processes cannot be seen.
DTW_SQL_SERIALIZABLE
Specifies locking for the objects referred to in SQL ALTER, COMMENT ON, CREATE, DROP, GRANT, LABEL ON, and REVOKE statements and the rows selected, updated, deleted, and inserted. The objects are locked until the end of the unit of work (transaction). Uncommitted changes in other processes cannot be seen. All tables referred to in SELECT, UPDATE, DELETE, and INSERT statements are locked exclusively until the end of the unit of work (transaction).
DTW_SQL_NAMING_MODE: SQL Table Naming Variable
The DTW_SQL_NAMING_MODE configuration statement specifies how a table name can be specified in an SQL statement.
Syntax:
DTW_SQL_NAMING_MODE mode
Where mode is one of the following values:
SQL_NAMING
Specifies that tables are qualified by the collection name in the form:
collection.table
where collection is the name of the collection and table is the table name. The default qualifier is the user ID running the process that executes the SQL statement and is used when the table name is not explicitly qualified and the default collection name is not specified. SQL_NAMING is the default table name.
SYS_NAMING
Specifies that files are qualified by library name in the form:
library/file
where library is the name of the library and file is the table name. The default search path is the library list (*LIBL) for the unqualified table name, if the table name (file) is not explicitly qualified and a default collection name (library) is not specified.
DTWR_CLOSE_REGISTRIES: Open Web Registry Variable
Specifies whether to close or keep a Web registry open. This variable lets you keep the Web registry open so that subsequent invocations of Net.Data macros that access the same Registry do not have to reopen the registry.
Syntax:
DTWR_CLOSE_REGISTRIES YES|NO
Where:
YES
Specifies to close all open Web registries after a Net.Data macro has been processed.
NO
Specifies to leave all open Web registries open after a Net.Data macro has been processed. NO is the default.
Performance tip: You can use the DTWR_CLOSE_REGISTRIES configuration statement to improve the performance of accessing a Web registry (with the Web registry built-in functions) by minimizing the opening and closing of registries.
--------------------------------------------------------------------------------
Path Configuration Statements
Net.Data determines the location of files and executable programs used by Net.Data macro files from the settings of path configuration statements. The path statements are:
MACRO_PATH
EXEC_PATH
INCLUDE_PATH
FFI_PATH
These path statements identify one or more directories that Net.Data searches when attempting to locate macro files, executable files, text files, and include files. The path statements that you need depend on the Net.Data capabilities that your macros use.
Update guidelines:
Several general guidelines apply to all path statements.
Each specified directory is delimited by a semicolon (;).
Forward slashes (/) and back slashes (\) are treated the same.
Each path statement can specify multiple paths. Paths are searched from left to right in the order specified. This multiple-path capability lets you organize your files within multiple directories. For example, you can place each of your Web applications in its own directory.
It is recommended to use absolute path statements.
Tip: Net.Data searches all specified directories, but not the subdirectories. For example, if you have Net.Data macros in the following directories, you must specify each subdirectory in the path statement:
/usr/test/client
/usr/test/assoc
/usr/test/partner
Your MACRO_PATH statement might look like this:
MACRO_PATH [=] /usr/test/client;usr/test/assoc;usr/test/partner
The following sections describe the purpose and syntax of each path statement and provide examples of valid path statements.
MACRO_PATH
The MACRO_PATH configuration statement identifies the directories that Net.Data searches for Net.Data macro files. For example, specifying the following URL requests the Net.Data macro with the path and file name macro/sqlm.d2w:
http://server/cgi-bin/db2www/macro/sqlm.d2w/report
Syntax:
MACRO_PATH [=] path1;path2;...;pathn
The equal sign (=) is optional, as indicated by brackets.
Net.Data appends the path macro/sqlm.d2w to the paths in the MACRO_PATH configuration statement, from left to right until Net.Data finds the macro file or searches all paths. See Invoking Net.Data for information on invoking Net.Data macros.
Example: The following example shows the MACRO PATH statement in the initialization file and the related link that invokes Net.Data.
Net.Data initialization file:
MACRO_PATH = /u/user1/macros;/usr/lpp/netdata/macros;
HTML link:
<A HREF="http://server/cgi-bin/db2www/query.d2w/input">Submit another query.</A>
If the file query.d2w is found in the directory /u/user1/macros, then the fully-qualified path is /u/user1/macros/query.d2w.
If the file is not found in the directories specified in the MACRO_PATH statement, Net.Data will search for the file in the root (/) directory. For example, if the following URL is submitted:
http://myserver/cgi-bin/db2www/myfile.txt/report
and the file myfile.txt was not found in any of the directories specified in MACRO_PATH, then Net.Data attempts to find the file in the root (/) directory:
/myfile.txt
EXEC_PATH
The EXEC_PATH configuration statement identifies one or more directories that Net.Data searches for an external program that is invoked by the EXEC statement or an executable variable. If the program is found, the external program name is appended to the path specification, resulting in a fully qualified file name that is passed to the language environment for execution.
Syntax:
EXEC_PATH [=] path1;path2;...;pathn
Example: The following example shows the EXEC PATH statement in the initialization file and the EXEC statement in the macro file that invokes an external program.
Net.Data initialization file:
EXEC_PATH = /qsys.lib/programs.lib;/qsys.lib/rexx.lib/rexxpgms.file;
Net.Data macro:
%FUNCTION(DTW_REXX) myFunction() {
%EXEC{ myFunction.mbr %}
%}
If the file myFunction.mbr is found in the /qsys.lib/rexx.lib/rexxprgms.file directory, the qualified name of the program is /qsys.lib/rexx.lib/rexxpgms.file/myFunction.mbr.
If the file is not found in the directories specified in the EXEC_PATH statement:
If the specified path is absolute, Net.Data searches for the file in the specified path. For example, if the following EXEC statement were specified:
%EXEC{/qsys.lib/programs.lib/rpg1.pgm %}
Net.Data would search for the file rpg1.pgm in the /qsys.lib/programs.lib directory.
If the specified path is relative, Net.Data searches the current working directory. For example, if the following EXEC statement were specified:
%EXEC { rpg1.pgm %}
then Net.Data would attempt to find the file rpg1.pgm in the current working directory.
INCLUDE_PATH
The INCLUDE_PATH configuration statement identifies one or more directories that Net.Data searches to find a file specified on an INCLUDE statement in a Net.Data macro. When it finds the file, Net.Data appends the include file name to the path specification to produce the qualified include file name.
Syntax:
INCLUDE_PATH [=] path1;path2;...;pathn
Example 1: The following example shows both the INCLUDE_PATH statement in the initialization file and the INCLUDE statement that specifies the include file.
Net.Data initialization file:
INCLUDE_PATH = /u/user1/includes;/usr/lpp/netdata/includes;
Net.Data macro:
%INCLUDE "myInclude.txt"
If the file myInclude.txt is found in the /u/user1/includes directory, the fully-qualified name of the include file is /u/user1/includes/myInclude.txt.
Example 2: The following example shows the INCLUDE_PATH statement and an INCLUDE file fully-qualified by a subdirectory name.
Net.Data initialization file:
INCLUDE_PATH = /u/user1/includes;/usr/lpp/netdata/includes;
Net.Data macro:
%INCLUDE "/OE/oeheader.inc"
The include file is searched for in the directories /u/user1/includes/OE and /usr/lpp/netdata/includes/OE. If the file is found in /usr/lpp/netdata/includes/OE, the fully qualified name of the include file is /usr/lpp/netdata/includes/OE/oeheader.inc.
If the file is not found in the directories specified in the INCLUDE_PATH statement:
If the specified path is absolute, Net.Data searches for the file in the specified path. For example, if the following INCLUDE statement were specified:
%INCLUDE "/u/user1/includes/oeheader.inc
then Net.Data would search for the file oeheader.inc in the /u/user1/includes directory.
If the specified path is relative, Net.Data searches the current working directory. For example, if the following INCLUDE statement were specified:
%INCLUDE "oeheader.inc"
then Net.Data would attempt to find the file oeheader.inc in the current working directory.
FFI_PATH
The FFI_PATH configuration statement identifies one or more directories that Net.Data searches for a flat file that is referenced by a flat file interface (FFI) function.
Syntax:
FFI_PATH [=] path1;path2;...;pathn
Example: The following example shows an FFI_PATH statement in the initialization file.
Net.Data initialization file:
FFI_PATH = /u/user1/ffi;/usr/lpp/netdata/ffi;
When the FFI language environment is called, Net.Data looks in the path specified in the FFI_PATH statement.
Because the FFI_PATH statement is used to provide security to those files not in directories in the path statement, there are special provisions for FFI files that are not found. See the FFI built-in functions section in Net.Data Reference.
--------------------------------------------------------------------------------
Environment Configuration Statements
An ENVIRONMENT statement configures a language environment. A language environment is a component of Net.Data that Net.Data uses to access a data source such as a DB2 database or to execute a program written in a language such as REXX. Net.Data provides a set of language environments, as well as an interface that allows you to create your own language environments. These language environments are decribed in Using Language Environments and the language environment interface are described in Net.Data Language Environment Reference.
Net.Data requires that an ENVIRONMENT statement exist in the Net.Data initialization file for a language environment before you can invoke the language environment.
Net.Data specifies several variables that affect the way in which Net.Data language environments interpret calls to functions that are defined in FUNCTION blocks. The settings of these variables must be passed to a language environment to have an effect.
For example, a macro can define a DATABASE variable to specify the name of a database at which an SQL statement within a DTW_SQL function is to be executed. The value of DATABASE must be passed to the SQL language environment (DTW_SQL) so that the SQL language environment can connect to the designated database. To pass the variable to the language environment, you must add the DATABASE variable to the parameter list of the environment statement for DTW_SQL.
The sample Net.Data initialization file makes several assumptions about customizing the setting of Net.Data environment configuration statements. These assumptions may not be correct for your environment. Modify the statements appropriately for your environment.
To add or update an ENVIRONMENT statement:
ENVIRONMENT statements have the following syntax:
ENVIRONMENT(type) library_name (parameter_list, ...)
Parameters:
type
The name by which Net.Data associates this language environment with a FUNCTION block that is defined in a Net.Data macro. You must specify the type of the language environment on a FUNCTION block definition to identify the language environment that Net.Data should use to execute the function.
library_name
The name of the service program containing the language environment interfaces that Net.Data calls. On OS/400, the service program name is specified with the .SRVPGM extension.
parameter_list
The list of parameters that are passed to the language environment on each function call, in addition to the parameters that are specified in the FUNCTION block definition.
The parameters are passed in the parm_data_array field of the dtw_lei structure, following the parameters that are specified in the FUNCTION block definition. (See Net.Data Language Environment Reference for information about these structures.)
You must define these parameters as configuration variables or as variables in your macro file before executing a function that will be processed by the language environment. If a function modifies any of its output parameters, the parameters keep their modified value after the function completes.
When Net.Data processes the INI file, it does not load the language environment service programs. Net.Data loads a language environment service program when it first executes a function that identifies that language environment. The service program then remains loaded for as long as Net.Data is loaded.
Example: ENVIRONMENT statements for Net.Data-provided language environments
When customizing the ENVIRONMENT statements for your application, add the variables on the ENVIRONMENT statements that need to be passed from your initialization file to a language environment or that Net.Data macro writers need to set or override in their macros.
1 MACRO_PATH /WWW/MACRO;/QSYS.LIB/WWW.LIB/MACRO.FILE
2 INCLUDE_PATH /WWW/MACRO;/QSYS.LIB/WWW.LIB/MACRO.FILE
3 EXEC_PATH /QSYS.LIB;/QSYS.LIB/WWW.LIB
4 ENVIRONMENT(DTW_REXX) /QSYS.LIB//QTCP.LIB/QTMHREXX.SRVPGM ( )
5 ENVIRONMENT(DTW_SQL) /QSYS.LIB/QTCP.LIB/QTMHSQL.SRVPGM (IN DATABASE,
LOGIN, PASSWORD, TRANSACTION_SCOPE, SHOWSQL, DB_CASE,
RPT_MAX_ROWS, START_ROW_NUM, DTW_SET_TOTAL_ROWS,
OUT DTWTABLE, SQL_CODE, TOTAL_ROWS)
6 ENVIRONMENT(DTW_SYSTEM) /QSYS.LIB/QTCP.LIB/QTMHSYS.SRVPGM ( )
Each ENVIRONMENT statement must be on a single line.
--------------------------------------------------------------------------------
Using Language Environments
Net.Data supplies language environments that you use to access data sources and to execute application programs containing business logic. For example, the SQL language environment lets you pass SQL statements to a DB2 database, and the REXX language environment lets you invoke REXX programs. You can also use the SYSTEM language environment to execute a program or issue a command.
With Net.Data, you can add user-written language environments in a pluggable fashion. Each user-written language environment must support a standard set of interfaces that are defined by Net.Data and must be implemented as a service program. You must add an ENVIRONMENT statement to the Net.Data initialization file to associate a service program with the language environment written by you. Net.Data loads and executes a service program once, the first time it encounters a function call for a FUNCTION block that specifies the language environment name. Subsequent function calls for FUNCTION blocks that specify the same language environment name merely cause Net.Data to execute the loaded service program.
For complete details on how to create a user-written language environment, see the Net.Data Language Environment Reference.
The following sections describes each of the language environments that are included with Net.Data, including how to configure and use the language environments.
REXX Language Environment
The REXX language environment can interpret internal REXX programs, which are specified in a FUNCTION block of the Net.Data macro, or it can execute external REXX programs stored in a separate file.
SQL Language Environment
Use the SQL language environment to execute SQL statements using DB2. Any valid SQL statement can be passed to the SQL language environment as long as the SQL statements are valid DB2 for OS/400 commands.
System Language Environment
The System language environment supports calls to external programs, such as RPG, COBOL, and C, as well as the execution of CL commands identified in an EXEC statement of the FUNCTION block. The System language environment interprets the EXEC statement by passing the specified program name or command and parameters to the operating system for execution using the C language system() function call.
------------------------------------------------------------------------------
Creating an Initialization File
Creating an initialization file is optional when using Net.Data for OS/400. You should create an initialization file if:
You want to set any of the Net.Data configuration variables to non-default values.
You want to define the path statements for macro, include, and executable program files to shorten references to these files.
You are using a language environment not supplied by Net.Data.
To create an initialization file:
In the library where the DB2WWW program object resides, use the Create Source Physical File (CRTSRCPF) command to create the initialization file.
File name:
INI
Member name:
DB2WWW
It is recommended that you create the initialization file with a record length of 240 because the text of configuration statements must all be on one line.
Use the Source Entry Utility (SEU) or a workstation editor to add configuration statements to the file as demonstrated in the sample macro and in the following sections.
If you create an initialization file and then update it, you do not need to end or restart the Web server in order for the changes to take effect. Net.Data reads the initialization file once, during the initial invocation by an HTTP server job. The configuration data is saved so that on subsequent Net.Data invocations, Net.Data does not have to read the initialization file. However, if a change is made to the initialization file, Net.Data detects the change to the initialization file and reads the initialization file again.
Authorization Tip: Ensure that the user IDs under which Net.Data executes have the appropriate access rights to this file. See Granting Access Rights to Objects Accessed by Net.Data for more information.
--------------------------------------------------------------------------------
Granting Access Rights to Objects Accessed by Net.Data
Before using Net.Data, you need to ensure that the user IDs under which Net.Data executes have the appropriate access rights to objects that are referenced in a Net.Data macro and to the macro that a URL references.
More specifically, ensure that the user IDs under which Net.Data executes have the following authorizations:
To read the Net.Data initialization file, INI.FILE/DB2WWW.MBR
To execute the Net.Data executables and service programs, and to search the directories (libraries) in the paths to the executables and service programs
To read the appropriate Net.Data macro files and search the appropriate directories identified by the MACRO_PATH path configuration statement
To execute the appropriate files and to search the appropriate directories identified by the EXEC_PATH path configuration statement
To read the appropriate files and to search the appropriate directories identified by the INCLUDE_PATH path configuration statement
To read and write the appropriate files, and to search the appropriate directories identified by the FFI_PATH path configuration statement
Examples:
Depending on the file system in which you choose to store your Net.Data macros, you need to authorize the user profile under which the Net.Data CGI program is run to the Net.Data macro. The following methods give the QTMHHTP1 user profile authority (in V3R2 and V3R7, Internet Connection for AS/400 ran CGI programs only under the QTMHHTP1 user profile.):
In the root file system, use the Change Authority (CHGAUT) CL command to give authority to the user profile:
CHGAUT OBJ('/WWW') USER(QTMHHTP1) DTAAUT(*RX)
CHGAUT OBJ('/WWW/macro') USER(QTMHHTP1) DTAAUT(*RX)
CHGAUT OBJ('/WWW/macro/*') USER(QTMHHTP1) DTAAUT(*RX)
You need to give authority to all objects in the path.
In the library file system (QSYS.LIB), use the Grant Object Authority (GRTOBJAUT) CL command to give authority to the user profile:
GRTOBJAUT OBJ(WWW) OBJTYPE(*LIB) USER(QTMHHTP1) AUT(*USE)
GRTOBJAUT OBJ(WWW/MACRO) OBJTYPE(*FILE) USER(QTMHHTP1) AUT(*USE)
You need to give authority only to the library and the source physical file.
You can also use the CHGAUT CL command to give authority to objects in the QSYS.LIB file system as follows:
CHGAUT OBJ('/QSYS.LIB/WWW.LIB') USER(QTMHHTP1) DTAAUT(*RX)
CHGAUT OBJ('/QSYS.LIB/WWW.LIB/MACRO.FILE') USER(QTMHHTP1) DTAAUT(*RX)
Language environment-specific authority considerations are documented in each language environment section in Using Language Environments.
