I/O Functions

Choosing I/O Techniques and File Organization

Because of the wide variety of I/O techniques and 370 file types, it is not always easy to select the right combination for a particular application. Also, the considerations differ for new applications and for existing applications ported from another environment.

New Applications

Recommendations for I/O in new programs depend on whether the program needs to run on other systems. For portable applications, the following guidelines are recommended:

If USS is available on your system, use USS files wherever appropriate. Because USS files implement UNIX semantics, I/O to these files is more portable than I/O to traditional OS/390 files.
Use standard I/O rather than UNIX style I/O. Because standard I/O is endorsed by the ISO/ANSI standard, it is more portable than UNIX style I/O. It is also more efficient than UNIX style I/O on 370 systems, and it is not appreciably slower on most other systems.
Open a file for text access if the file will be processed as a series of lines. Open it for binary access if it will be processed as a series of characters.
If file positioning is required for text applications, use the fseek and ftell functions, which are more widely available than fsetpos or fgetpos . Note that you cannot use file positions arithmetically with these functions. (You may be forced to use fsetpos and fgetpos rather than fseek and ftell if you need to support very large files.)
If file positioning is required for binary applications, use UNIX style I/O, use fsetpos and fgetpos , or restrict the application to using files suitable for "rel" access. The advantage of UNIX style I/O is that it is applicable to most files and is somewhat portable. The advantage of fsetpos and fgetpos is that they are defined by the C Standard, so they are portable. The advantage of restricting the application to files suitable for "rel" access is that maximum efficiency is achieved with the most portable interface. If the file is only used by C programs (for example, if the file is a work file, or if it is not accessed by the outside world), then requiring suitable file attributes is clearly the best solution.

If your application does not have to be portable, there are several additional possibilities. Note, however, that even if portability is not a requirement, one of the portable techniques described earlier may still be most appropriate.

If your application needs to process data one record at a time, consider using the augmented standard I/O routines afread and afwrite . These routines are especially useful if the records may contain control characters (which makes standard I/O text access inappropriate).
For nonportable applications, use fsetpos and fgetpos rather than fseek and ftell for file positioning. These routines have fewer restrictions and their results are more easily interpreted.
If efficiency is a major consideration, you may want to use low-level I/O, as described in Chapter 2, "CMS Low-Level I/O Functions," and Chapter 3, "OS/390 Low-Level I/O Functions," in SAS/C Library Reference, Volume 2.
Avoid UNIX style I/O.

Existing Applications

For existing applications, the choices are more difficult. With an existing program, you may be forced to choose between rewriting the program's I/O routines, accepting poor performance, and restricting use of the program to certain types of files. The following is a partial list of the considerations:

If the program uses standard I/O and processes a file as text, changes are required if the file position must be a relative character number. Changes may also be required if the program reads or writes control characters, or is sensitive to the presence or absence of trailing blanks.
If the program uses standard I/O, processes a file as binary, and uses fseek and ftell for file positioning, you must modify the program or restrict it to use only the "rel" access method. (Such an application could be modified to use UNIX style I/O or to use fsetpos and fgetpos for positioning.) Further modifications or restrictions on file type may be required if the program cannot tolerate the addition of trailing nulls at end of file.
If a program uses standard I/O to modify a file and requires that later data in the file be preserved, the program must be restricted to certain file types (for example, VSAM or CMS-format disk files) or be modified to use UNIX style I/O.
A program that uses standard I/O to append data to an existing file cannot update an OS/390 PDS member. Such a program must be restricted to use of files with sequential organization or (provided binary access is used) converted to use UNIX style I/O.
If the program uses UNIX style I/O and processes a file as binary, it usually executes without modification. Performance is improved if the file is suitable for "rel" access, because then the file can be processed without copying. If the program does not depend on some of the details of UNIX style I/O (for instance, if it is not sensitive to the exact nature of file positions), it can be converted to use standard I/O for better performance.
If the program uses UNIX style I/O, processes a file as text, and uses lseek to do file positioning, it requires substantial modification. The library does not support file positioning by character number when UNIX style I/O is used to access a file as text.
If a program using either I/O package treats a file sometimes as text and sometimes as binary (that is, it interprets a new-line character as both a line separator and a physical character), the program must be modified.

Chapter Contents
Previous
Next
Top of Page