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) Z Data Tools. 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).
  • Z Data Tools only uses DFSORT when the data is in sequential files, or on VSAM files if there are DFSORT statements in the procedure. Z Data Tools does not use DFSORT when the data is in PDS(E)s or MQ queues.
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 Z Data Tools 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 Z Data Tools to use DFSORT even if your site does not have a DFSORT license.
  2. Z Data Tools uses DFSORT for I/O processing whenever possible. Therefore, regardless of which user procedure language you choose to use, Z Data Tools 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.