Override files within RPGLE with EXTFILE, EXTMBR

Often when there was a need to override a file OVRDBF was used and usually either in a CL program before calling the RPGLE program (and before opening the file) or by coding USROPN, OPEN, calling QCMDEXC, and CLOSE the file at end. Now this can be more easily accomplished by adding EXTFILE() and/or EXTMBR(), to the File Specifications in RPGLE.

For example, the program described file named TYPECODE needs to be overridden to file named MYCODES prior to reading (from *LIBL):

FTYPECODE IF  E           K DISK    EXTFILE(MYCODES)

To read a specific member, say MBR1, add EXTMBR.

FTYPECODE IF  E           K DISK    EXTFILE(MYCODES) EXTMBR(MBR1)

The external file can be qualified with a library (and if not, *LIBL is used).

FTYPECODE IF  E           K DISK    EXTFILE(MYLIB/MYCODES) EXTMBR(MBR1)

The file name can be a (case-sensitive) variable (which must be defined before the file is OPENed). The variable can be defined in the first subroutine or passed in as a parameter.

FTYPECODE IF  E           K DISK    USROPN EXTFILE(MYLIB/VarCode) EXTMBR(MBR1)
/free
 exsr *inzsr;

 *inlr=*on;
 return;


 begsr *inzsr;
  VarCode=%char(%trim(WSID));
   monitor;
   open VarCode;
   on-error *file;
 endsr;
/end-free

It should be noted that there are several reasons why some caution is needed when using these new RPGLE keywords.

The implications when using EXTFILE and EXTMBR in conjunction with the LIKEFILE keyword must be understood. The external file may or may not affect the file defined with LIKEFILE. This depends on how the file specifications are coded. The EXTFILE and EXTMBR will usually be used for the LIKEFILE if the original (parent) file and/or member are constants. If the override (library, file, member) is not wanted then EXTFILE and EXTMBR can be specified on the LIKEFILE file spec.

FTYPECODE  IF  E           K DISK    USROPN EXTFILE(MYLIB/VarCode) EXTMBR(MBR1)
FTYPECODEX IF  E           K DISK    USROPN LIKEFILE(MYLIB/VarCode) EXTMBR(MBR2)

There are other concerns regarding this new method including limiting the undesirable practice of memberization of physical files and some possible future maintenance issues. For example, if the same file name is used OVRDBF(filename) will override EXTFILE(filename).

Creating physical files (as opposed to source file members) with multiple members  increases confusion and clutter and should be avoided. Often it is hard to recall exactly which physical files have more than one member. This adds a step of checking the file for multiple members prior to doing common file tasks such as dspfd, cpyf, runqry, etc. Of course, often this situation is inherited where multi-member files already exist. In that case, caution reigns supreme as blindly processing members *first or *frommbr may cause the wrong data set to be accessed which can cause major data corruption.

When physical file memberization takes the form of temporary processing of segregated data (for example, today's purchase orders) these members are frequently not removed when processing is completed making for bulky, cumbersome files.

That said, the EXTFILE and EXTMBR are powerful enhancements that should be used righteously so that future maintenance does not become convoluted. When implementing EXTFILE and EXTMBR make sure you have a good grasp of LIKEFILE and EXTDESC.