1) commit frequency
2) Length of data read/written
3) Read with hold
4) # of database I/O's
5) communication protocol and settings

I'll briefly discuss each.

1) commit frequency (Commit Mode, Process Additional Attributes).

We have determined that a commit is very "expensive" in terms of performance. If you can reduce the number of commits, then performance will almost always increase, sometimes significantly. Deferring commits to the End of Process probably maximizes performance for this factor but may increase the size of the rollback logs and will certainly increase the number of rows in the database which are "locked" to other users while updates are pending.

2) Length of data read/written

This may be the most significant factor which impacts performance. As the length of the data being read or written increases, the run time increases, sometimes dramatically. This is why we added the Partial Record I/O feature. If possible, you should avoid reading the entire record if the record is large. How large? I seem to remember that each increment of about 800 bytes caused a significant incremental loss of performance. Even if you must read the entire record, then try to avoid a rewrite of the entire record. If you are only updating a single field, then do a rewrite of just that field. If you are rewriting several fields, wrap them in a group and rewrite the group. If necessary, you can add a "group" of synonyms to the end of the record to accomplish this.

3) Read with hold

Don't read with hold unless you need to. If you are only going to actually update a small percentage of the records read, read each record first without a hold and then, after you determine that an update is needed, read it with hold. A read with hold is very "expense" in terms of performance. Keep in mind that an output or update process will automatically read the PCF with hold if a REWRITE or DELETE statement is detected. If only a small percentage of records will actually be updated, it might be much more efficient to write a Subroutine process as an alternative to an update process.

4) # of database I/O's

Use the new file cache capability to load read-only "code" files into memory where they can be very efficiently read. Accessing of code files in a database is much slower than accessing the same code files from memory.

5) communication protocol and settings

If possible, install the Oracle database and APPX on the same machine so that you can avoid database I/O across a network. If they are both on the same machine, configure Oracle to use "pipes" for communication instead of TCP/IP. Define the ORACLE_SID environment variable instead of specifying the database name in the FMS group. APPX will then use the local communications protocol which will probably be pipes. Pipes are much more efficient than TCP/IP.

If you are using TCP/IP make sure that the packet size is large. I'm not sure how large you can define the packet size to be, but 10K or more might be desirable if you are reading/writing large rows.