Net.Data replaces DB2 WWW Connection. Details for AIX are included in the README file that is shipped with Net.Data. The README file includes this information:
When creating a language environment on the AIX platform, you need to do some specific steps because AIX requires loading shared libraries. On AIX, the language environment is required to provide a routine that is called by Net.Data and returns the addresses of the language environment interface routines such as dtw_initialize() and dtw_execute().
Net.Data uses the dtw_fp structure to retrieve pointers to the language environment interface routines from a language environment in AIX, and has this format:
typedef struct dtw_fp {
int (* dtw_initialize_fp)(); /* dtw_initialize function pointer */
int (* dtw_execute_fp)(); /* dtw_execute function pointer */
int (* dtw_getNextRow_fp)(); /* dtw_getNextRow function pointer */
int (* dtw_cleanup_fp)(); /* dtw_cleanup function pointer */
} dtw_fp_t;
This structure is passed to the language environment by Net.Data as a parameter in the dtw_getFp() routine when the shared library is loaded.
The dtw_fp structure is passed as the only parameter. This structure contains a field for each supported interface, and it is the language environment's responsibility to set these fields. If the language environment is providing the specified interface, it sets the field to the function pointer of that interface. If it is not providing the specified interface, it sets the field to NULL. The dtw_getFp() routine in the program template shows a correct implementation of this routine.
In order for Net.Data to get the pointer to this routine when the shared library is loaded, the dtw_getFp routine must be the first entry point specified in the shared library's export file. A sample export file for a library called dtwsampshr.o that supports all available language environment interface routines looks like this:
#!dtwsampshr.o dtw_getFp dtw_initialize dtw_execute dtw_getNextRow dtw_cleanup
If you have many calls to the REXX language environment on your AIX system, consider setting the RXQUEUE_OWNER_PID to 0. Macros that make many calls to the REXX language environment can easily spawn many processes, swamping system resources. For example, if your Web server is processing 2 requests each second. A macro that returns 20 rows with a call to a REXX function in the ROW block forces the server to attempts to spawn 80 (20 for the rows * 2 for REXX requests * 2 for HTTP requests ) processes each second, which is more than many servers can handle.
Setting RXQUEUE_OWNER_PID to 0 prevents no more than 2 processes starting each second, which even small AIX boxes can handle. Use DTW_rSETENV set the value:
@DTW_rSETENV("RXQUEUE_OWNER_PID", "0")
An alternative to the example above, which calls the REXX language environment in the ROW block, is to use a table variable to pass the entire fetched table to a REXX function, so the processing occurs in a single call to the language environment.