The CHAIN command (TAS version 4.0 and up) allows a programmer to call another TAS program which upon QUITting returns control to the line of code immediately following the CHAIN (very much in the same way as a GOSUB, UDC or UDF would do the same thing internally within a single program). Upon chaining any data files previously opened remain open (unless the programmer specifically closes them) while the second program run.

If the second program requires one or more of the same data files as the calling program, which often is the case, the programmer normally has to decide whether to simply OPEN the same file again or instead to re-open the file using ROPEN.

When a file is simply opened again, a second instance of the open file occurs which consumes additional file handle resources (which can in turn lead to Btrieve 88 errors when two or three programs are chaining back and forth to each other and are opening a number of common data files). By using ROPEN, system resources can therefore be conserved as well as record locks potentially avoided with a minimal amount of coding. All of the fields in the currently active record can also easily be "passed" if desired.

One potential danger in using ROPEN occurs when you need to change the position in an opened file during the running of the chained to (e.g. second) program. When the second program chains back to the first program, if the position of the file has changed at all, this same positioning will automatically exist in the first program as if the positioning had occurred there.

Factors to consider would then include:

1. Whether changing the record position in the chained to program will adversely affect the chained from program;
   
2. Record locks and whether all programs involved need to lock records in the same manner;
   
3. The exact extent to which other programs will be chaining to the program using an ROPEN and whether the program might ever be run directly;
   
4. Whether the program being chained to processes a single record and would benefit by the prior program's record position or whether the chained to program processes a larger group of records or the data file involved is just being opened for some incidental reason.

So, while the use of ROPEN can be advantageous, you will not necessarily want to use it just because a given data file happens to already be open.

Here are some program samples that show the impact of using ROPEN especially in the context of record positioning.

define filedict_hndl type I  && define file handle
openv 'filedict' fnum filedict_hndl lock n && open file
findv f fnum filedict_hndl &&find first record
msg 'Value in PRO_1 BEFORE chain is '+dict_field_name &&prints first dictionary field
chain 'pro_2'  &&chain to second program
msg 'Value in PRO_1 AFTER chain is '+dict_field_name &&print field value after returning here
quit

define filedict_hndl type I RESET && reset variable to obtain value from calling program
if filedict_hndl = 0 then quit  &&if file handle was not passed, quit to calling program
ropen filedict_hndl  &&reopen the file
ask 'Re-position the file by finding the last record? Y'
if ask() then findv l fnum filedict_hndl  &&if user answers Yes, find the last record in the file
msg 'Value in PRO_2 is '+dict_field_name  &&show field value, if user answers No to question above, will be same as first program
quit

In the second program above, if the user instructs the program to re-position the file, when it quits back to the calling program, the file position remains at the last record. If the user chooses not to re-position, the position remains unchanged in the first program.

\homepage\techmemo\ad082599.htm