File Open Persistence
There are a few ramifications of the fact that files remain open across subroutine calls that you should be careful of. One is that it works both ways. That is, files that are opened within a subroutine remain open (unless explicitly closed or the AF_SBXASRUN flag in Xcall ASFLAG is set) when the subroutine returns to the calling program. So, for example, you could create an "open file" subroutine whose job was to figure out which file to open and then returned the file channel number. Then, the calling program would have to use MX_FLSET as described above to hook its control variables to the file.
A second ramification is that a file opened by the main program and closed by the subroutine remains closed when the subroutine returns to the calling program. This would surely be a dubious programming technique, but is still worth watching out for. Of course this also works both ways: a file opened in the subroutine may be closed in the parent program.
A third ramification derives directly from the previous one but is much more useful: a file opened in a subroutine may remain open across multiple calls to the subroutine. For example, if you have a subroutine that reads a single response from a serial port under Unix, rather than opening and closing the file on each subroutine call, or opening the file in main program even though it is only accessed in the subroutine, you may decide to open it the first time the subroutine is called, but just leave it open in case the subroutine is called multiple times.
This raises the question of how to tell if a file is open on a specified channel. The answer is the EOF() function. EOF(CH) (where CH is the file channel number you are inquiring on) will return negative one if the file is not open. Otherwise, it will return 0, or possibly 1 (to indicate a sequential input file at EOF).
Because these persistence issues are invitations to confusion, it is a good idea to think through your SBX-related file access strategy with an eye towards simplicity.
If you open a RANDOM, ISAM, or ISAM-A file within an SBX routine and then wish to access it in a later call to that routine, you should repeat the MX_FLSET operation to reset the file’s control variables. This is not necessary for sequential files which don’t have control variables, but is essential otherwise, since the control variables are referenced by the file table via their address in memory, and that address is almost certain to change with each call to the subroutine.
See Also
