Choosing between FASTREXX, REXX, and DFSORT for your procedure

In general, FASTREXX is the best compromise between performance and function.

FASTREXX is somewhat more CPU-intensive than DFSORT, but much less so than REXX. It has easier syntax than DFSORT, requires only one language to be learned, and has more function and flexibility than DFSORT, with performance that is close to that of DFSORT. Be aware though that FASTREXX is a subset of REXX and can degrade into REXX, which is the slowest (but most flexible) of the three procedure languages.

REXX is a complete programming language. As such, it is more flexible, but uses significantly more CPU than DFSORT and FASTREXX. There is a Compiler and Library for REXX on zSeries product which can be purchased and used by (among others) File Manager. However, while compiled REXX is definitely more CPU-efficient than ordinary REXX, FASTREXX uses significantly less CPU than compiled REXX.

DFSORT is slightly more CPU-efficient than FASTREXX. However, using DFSORT does have some drawbacks:
  • You must use an additional language (DFSORT control statements).
  • File Manager only uses DFSORT when the data is in sequential files, or on VSAM files if there are DFSORT statements in the procedure. File Manager does not use DFSORT when the data is in a PDS or PDSE or an MQ queue.
You should only use DFSORT for jobs where performance is critical.
DFSORT licensing and installation:
  1. To use DFSORT for I/O or as your procedure language, DFSORT must be installed so that File Manager can use it. DFSORT is an optional, priced feature of z/OS®. Ordinary users cannot use DFSORT unless the site has a license for it. However, there is an installation procedure which allows File Manager to use DFSORT even if your site does not have a DFSORT license.
  2. File Manager uses DFSORT for I/O processing whenever possible. Therefore, regardless of which user procedure language you choose to use, File Manager should be enabled to use DFSORT.

Should you combine DFSORT with REXX or FASTREXX processing? If you can do this in such a way as to optimize performance (using careful measurement), the answer may be yes. However, it comes at the cost of an increase in complexity in writing, maintaining, and debugging the user procedure. The guideline of keeping things simple strongly favors using FASTREXX.