Standard Libraries

370 I/O Considerations

Many C++ programs were developed under UNIX operating systems, which are where the first C++ translators were available. Unfortunately, I/O is very different under OS/390 and CMS than under UNIX. This may require you to make some changes to existing C++ applications to adapt to the mainframe environment. This section discusses some of these issues. For a more detailed discussion of the differences between 370 I/O and traditional UNIX I/O, and of portable I/O coding techniques, see the SAS/C Library Reference, Volume 1.

Text and Binary Access

Under UNIX and some other operating systems, files are stored as sequences of characters, and the newline character serves to separate one line from the next. Under OS/390 and CMS, files are stored as sequences of records, separated by gaps (which do not contain any characters). Files in such systems therefore support two forms of access: text and binary. When a file is accessed in binary mode, only the characters are accessed and information about lines or records is lost. When a file is accessed in text mode, record gaps are treated as if they contained a newline character. That is, a newline is inserted at the end of each record on input, and writing a newline on output causes a record gap to be generated, but no physical character is written.

Text access is generally more suitable for programs that need to be aware of line boundaries, while binary access is suitable for programs that must read or write data exactly as specified. (For example, a program that writes an object deck must use binary access, to keep newlines in the object deck from being translated to record gaps.)

When a stream is associated with an external file, the default access mode is text. You can specify ios::binary in the open mode if you need binary access, as in the following statement:

ostream object("tso:fred.obj",
               ios::out|ios::binary);

Filenames

Mainframe systems offer several unique ways of naming files, most of which bear little resemblance to traditional MYFILE.TXT style filenames found under UNIX. The general form of a file name is

style:name

where style is a code describing how the rest of the name is to be interpreted. The style: portion of a filename can be omitted, in which case a default is assumed.

OS/390 filenames

Under OS/390, the following filename styles are supported:

ddn:name: indicates the name portion is a DDname, associated with a batch JCL DD statement or a TSO ALLOCATE command. This style is the default OS/390 filename style; that is, a filename of XYZ is assumed to refer to DDname XYZ.
dsn:name: indicates the name portion is a fully qualified data set name, for example, dsn:SYS1.MACLIB(DCB).
tso:name: indicates the name portion is a data set name in TSO style. A fully qualified name is generated from it by using the prefix name with the TSO userid. For instance, opening tso:MY.DATA opens the file userid.MY.DATA, where userid is the userid of the user running the program. tso : style names most closely resemble typical filenames under UNIX systems.

CMS filenames

Under CMS, the following filename styles are supported:

cms:name: indicates the name portion is a CMS filename, composed of a filename, a filetype, and an optional filemode, separated by blanks, for example, cms:PROFILE XEDIT. As a convenience, periods can be used in place of blanks to separate the portions of the filename, so that cms:PROFILE.XEDIT and cms:PROFILE XEDIT identify the same file. This style is the default CMS filename style.
sf:fileid dirid: indicates the file is stored in the CMS Shared File System (SFS). The fileid specifies the name of a file and dirid specifies a directory path in the CMS Shared File System. For more information about this sort of filename, see the SAS/C Compiler and Library User's Guide.
ddn:name: indicates the name portion is a DDname, defined using the FILEDEF command. This form of filename is useful mostly for compatibility with OS/390.

You can change the default style for your program by including a declaration for an external char* variable named _style . For example, the following statement specifies that by default all filenames are to be interpreted as tso: style names:

char *_style = "tso:";

Amparms

To successfully and efficiently use a file on IBM 370 systems, it is often necessary to provide information about actual or desired file attributes in addition to the filename. For example, when you create a new file under OS/390, it may be necessary to specify the file size and how large the records are to be. File attributes of this sort are specified via amparms, which are keyword parameters defined by the SAS/C library. Amparms can be specified as a third argument to an fstream constructor or open() member function. For example, the following statements specify that the DDname SYSLIN should define a file with fixed-length 80-byte records, grouped into blocks of 3,200 characters:

ostream objfile;
objfile.open("syslin", ios::out|ios::binary,
           "recfm=f,reclen=80,blksize=3200");

The translator supports the same amparms as the SAS/C Compiler, as described in the SAS/C Library Reference, Volume 1.

An additional optional argument to stream constructors and open() member functions is an access method name. For instance, the following statement defines an iostream processed by the "rel" access method.

iostream work("dsn:&wkfile",
              ios::out|ios:binary,
              "alcunit=cyl,space=5","rel");

See the SAS/C Library Reference, Volume 1 for a discussion of the meaning and utility of specifying an access method.

File Positioning

Under UNIX systems, it is generally possible to reposition any file to a particular character, for example, the 10,000th character. Due to the inner workings of mainframe I/O, this is generally not possible under OS/390 or CMS. One exception is for files accessed for binary access, using the "rel" access method. These files can be freely positioned to particular characters in a way compatible with UNIX systems.

The streams library defines two different types to deal with file positioning, streampos and streamoff . The streampos type is used to hold file positions, while streamoff is used to hold offsets of one point in a file from another.

In UNIX implementations of C++, both streampos and streamoff are integral types and both may be used freely with any file. However, in the SAS/C implementation, only streamoff is an integral type. Further, streamoff can only be used for files that behave like UNIX files, namely, those opened for binary access using the "rel" access method. streampos is a nonintegral type that encodes a file position in a system-dependent manner. You can use the tellg() and tellp() member functions to obtain a streampos for a particular point in the file, and you can use the seekg() and seekp() functions to position to a point whose location has previously been determined. Because no arithmetic or other operations are defined on streampos values, more general positioning operations such as seeking 10,000 characters past a specific location in the file are not supported.

Other Differences between UNIX and 370 I/O

370 I/O is not based on file descriptors. For this reason, member functions such as fd() and attach() are not meaningful in the IBM 370 environment and are not supported. Similarly, UNIX protection modes are not meaningful to OS/390 or CMS and constructors or open() calls that specify a protection mode will be rejected at compile time.

Chapter Contents
Previous
Next
Top of Page