After reviewing your environment, there are two primary causes of your performance bottlenecks:

1. The database needs to be reorganized to achieve optimal placement of records which were stored in extended areas. This includes determining the optimal page sizes, allocations and thresholds for each storage area.

2. It appears that the platform from which you converted either did not provide for keyed access to member of user-owned sets or the application did not take advantage of this feature. The following describes some of the enhancements you may want to consider.

Except for CALC and SYSTEM owned indexed sets, your application always performs sequential walks of any user-owned set, performing your own test of the record selection criteria. That is, after each "find next <record> within <set>" your application performs its own test of the selection criteria. As a first step, you will want to modify your DML programs to include your record selection criteria within the DML verbs. Example:

PERFORM UNTIL FOUND OR END
FIND NEXT <record>
WITHIN <set>
IF PART_ID = WS_PART_ID
SET FOUND TRUE
END IF
END PERFORM

becomes:

FIND NEXT <record>
WITHIN <set>
WHERE PART_ID
= WS_PART_ID

This will simplify your code, as well as allow you to easily identify the primary access paths into your data. As part of a later exercise, you can modify your database design to provide keyed access to these primary access paths.