The following techniques improve the performance of Net.Data macros:
- Minimize the number of rows that the browser returns.
If you are using the row block to generate HTML output, you need a table. You can generate this table from any source (for example, as a result of an DB2/400 query). If it takes too long to return the data to the browser, experiment with RPT_MAX_ROWS and START_ROW_NUM to return a subset of table rows to the browser. Add Next and Previous buttons to view the rest of the rows.
The Sample Library page has an example of how to use START_ROW_NUM. You need the latest Net.Data PTFs to use START_ROW_NUM.
- Minimize built-in function calls within a row-block.
If you have many built-in function calls within a row-block, look for alternative methods to eliminate the built-in function calls.
For example: Instead of using a built-in function call to manipulate each field in the table, use a table built-in function that processes all the fields in a table with one call.
- Avoid using VLIST and NLIST, if possible.
Referencing these variables requires Net.Data to construct these variables from the table that is being processed in the report block. It is faster to access individual fields, such as V1 and N1.
- Avoid using the ALIGN report variable.
The ALIGN report variable results in significant overhead.
- External Rexx programs run faster than in-line Rexx programs.
Although it is nice to have all your source within a macro, performance decreases when all Rexx programs are within the macro instead of a seperate file.
Last Modified On:
No, open a new Support Case
