• Aucun résultat trouvé

INPUT AND OUTPUT

Dans le document IBM System/360 (Page 92-101)

blocked, however" at" say, 10 records to a block, each block of 10 records would take up 1 inch, plus 0.6 inches for the gap, making a total of 1.6 inches. Thus, 100 records would now take up only 16 inches of tape: this is less than 25 percent of the amount needed for unblocked records.

Most data processing applications are concerned with logical records rather than physical records. Therefore. the input and output statements of PL/I generally refer to logical records: this allows the pro-grammer to concentrate on the data to be processed, without being directly concerned about its physical organization in external storage.

Two different types of data transmission can be used by a PL/I program, stream-oriented transmission and record-oriented transmission.

In stream-oriented transmission, the data in the data set is considered to be a continuous stream of data items in character form. Consequently. data conver-sion is implied in stream transmission, from character form to internal form on input, and from internal form to character form on output. The GET and PUT statements are the data transmission statements used in stream-oriented transmission. Varia-bles, to which input data items are assigned, and expressions, from which out-put data items are transmitted, are gener-ally specified in a data list with each GET or PUT statement.

Although data in the data set exists in record format, either unblocked or blocked.

in stream transmission such organization is ignored within the program, and the data is treated as though i t actually were a con-tinuous stream of individual data items.

In record-oriented transmission, data in the data set is considered to be a collec-tion of discrete logical records, recorded in any format acceptable to the computer.

No data conversion is performed during record transmission; on input it is trans-mitted exactly as it is recorded in the data set: on output i t is transmitted exactly as it is recorded internally.

The READ, REWRITE, LOCATE, and WRITE statements cause a single logical record to be transmitted to or from a data variable.

Note that although records may be blockedf in which case the physical record actually is transmitted to or from the data set as an entity, each data transmission statement in record I/O is concerned with a logical record. Blocked records are unblocked automatically.

The following discussion of files and file attributes should be of particular interest to a programmer using record-oriented transmission. File handling is simpler when using stream-oriented transmission, and, as can be noted, fewer attributes are applicable to stream files.

To allow a source program to deal pri-marily with the logical aspects of data rather than with its physical organization in a data set, PL/I employs a symbolic representation of a data set called a file.

This symbolic representation determines how input and output statements access and process the associated data set. Unlike a data set, however, a file has significance only within the source program and does not exist as a physical entity external to the program.

PL/I requires a file name to be declared for a file and allows the characteristics of a file to be described with keywords

call~d file attributes, which are specified for the file name.

FILE ATTRIBUTES

The following lists show file attributes that are applicable to each type of data transmission:

90

Stream Transmission

FILi-;--STREAM INPUT OUTPUT PRINT INTERNAL EXTERNAL ENVIRONMENT

Record Transmission FILE

RECORD INPUT OUTPUT UPDATE INTERNAL EXTERNAL ENVIRONMENT SEQUENTIAL DIRECT BUFFERED UNBUFFERED KEYED BACKWARDS EXCLUSIVE

A detailed description of each of these attributes appears in Part II. Section I,

"Attributes." The discussions below give a brief description of each attribute and show how attributes are declared for a file.

The FILE Attribute

The FILE attribute indicates that the associated identifier is a file name. For example, the identifier MASTER is declared to be a file name in the following state-ment:

DECLARE MASTER FILE;

Alternative and Additive Attributes

The attributes associated with the FILE attribute fall into two categories: alter-native attributes and additive attri~utes.

An alternative attribute is one that is chosen from a group of attributes. If no explicit or implicit declaration is given for one of the alternative attributes in a group and if one of the alternatives is required, a default attribute is assmned.

An additive attribute is one that must be stated-e;{plicitly --or is impli<ed by another explicitly stated attribute or name. The additive attribute KEYED can be implied by the, DIRECT attribute. The addi-tive attribute PRINT can be implied by the standard output file name SYSPRINT. An additive attribute can never be applied by defaul t.

Note: With the exception of the IN'rERNAL and EXTERNAL scope attributes. all the alternative and additive attributes imply the FILE attribute. Therefore, the FILE attribute need not be specified for a file that has at least one of the alternative or

additive attributes already specified explicitly. The FILE attribute must be specified explicitly, however, if only the INTERNAL or EXTERNAL attribute is speci-fied; otherwise, the identifier will be assumed, by default, to be an arithmetic variable rather than a file name.

~].t,ernative ¥Eibutes

PL/I provides five groups of alternative file attributes. Each group is discussed individually. Following is a list of the groups and the default for each:

Group Alternative Default

~ Attributes Attribute

Usage STREAM I RECORD STREAM Function INPUT I OUTPUT I UPDATE INPUT A.ccess SEQUENTIAL I DIRECT SEQUENTIAL Buffering BUFFERED I UNBUFFERED BUFFERED Scope EXTERNAL I INTERNAL EXTERNAL

The STREAM and RECORD Attributes

....,... i

The STREAM and cribe the type

(stream-oriented used in input and file.

RECORD attributes des-of data transmission or record-oriented) to be output operations for the The STREAM attribute causes a file to be treated as a continuous stream of data it.ems recorded only in character form.

The RECORD attribute causes a file to be treated as a sequence of logical records, each record consisting of one or more data i·tems recorded in any internal form acceptable to the implementation.

DECLARE MASTER FILE RECORD, DETAIL FILE STREAM;

±he INPUT" OUTPUT" and UPDATE At:t.ributes The function attributes determine the direction of data transmission permitted for a file. The INPUT attribute applies to files that are to be read only. The OUTPUT attribute applies to files that are to be

created~ and hence are to be written only.

The UPDATE attribute describes a file that is to be used for both input and output; it allows records to be inserted into an

existing file and other records already in that file to be altered or deleted.

DECLARE

DETAIL FILE INPUT, REPORT FILE OUTPUT, MASTER FILE UPDATE;

The SEQUENTIAL and DIRECT Attributes

The access attributes apply only to a file with the RECORD attribute and describe how the records in the file are to be accessed.

The SEQUENTIAL attribute normally speci-fies that successive records in the file are to be accessed on the basis of their successive physical positions, such as they are on magnetic tape.

The DIRECT attribute specifies that a record in a file is to be accessed on the basis of its location in the file and not on the basis of its position relative to the record previously read or written. The location of the record is determined by a key; therefore, the DIRECT attribute implies the KEYED attribute. The associat-ed data set must be in a direct-access volume.

The BUFFERED and UNBUFFERED Attributes The buffering attributes apply only to a file that has the SEQUENTIAL and RECORD attributes. The BUFFERED attribute indi-cates that logical records transmitted to and from a file must pass through an intermediate internal-storage area. The size of a buffer usually corresponds to the size of the blocks <physical records) in the data set associated with the file (a discussion of block size and buffer alloca-tion appears in this chapter in

"ENVIRONMENT Attribute"). The use of buf-flers may help speed up processing by allow-ing an overlap of transmission and comput-ing time. It further allows the automatic blocking and unblocking of records.

The UNBUFFERED attribute indicates that a logical record in a data set need not pass through a buffer but may be transwit-tled directly to and from the internal storage associated with a variable. The logical records and physical records are generally the same size in a data set that is associated with an UNBUFFFRED file.

Note: Specification of UNBUFFERED does not preclude the use of buffers. In some cases, "hidden buffers" are required.

Those cases are listed in the discussion of the BUFFERED and UNBUFFERED attributes in Part II. S~ction I, "Attributes."

Adgitive Attributes

The additive attributes are:

PRINT BACKWARDS KEYED EXCLUSIVE

ENVIRONMENT (option-list)

The PRINT Attribute

~ ...

---

(

The PRINT attribute applies only to files with the STREAM and OUTPUT attri-butes. It indicates that the file is eventually to be printed, that is~ the data associated with the file is to appear on printed pages, although i t may first be written on some other medium. The PRINT attribute causes the associated record to be created with the initial byte reserved for a printer control character.

The BACKWARDS attribute applies only to files with the SEQUENTIAL. RECORD, and INPUT attributes and only to data sets on magnetic tape. It indicates that a file is to be accessed in reverse order, beginning with the last record and proceeding through the file until the first record is accessed.

']~he KEYED attribute indicates that records in the file are to be accessed using one of the key options (KEY. KEYTO, or KEYFROM) of data transmission statements or of the DELETE statement. Note that the KEYED attribute does not necessarily indi-cate that the actual keys exist or are to be written in the data set. consequently, it need not be specified unless one of the 92

key options is to be used, even if keys actually exist in the associated data set.

The STREAM and PRINT attributes cannot be applied to "a file that has the KEYED attribute. The use of keys is discussed in detail in the sections "Environmental Con-siderations for Data Sets" and

"Record-Oriented Transmission" in this chapter.

The EXCLUSIVE Attribute

The EXCLUSIVE attribute applies only to files with the RECORD, DIREC'I, and UPDATE attr ibutes. It specifies that any :record in the file may be automatically lock,ed by a task while it is operating on that record, to prevent interference by another concurrent task. It can be suppressed by the NOLOCK option on the READ statement.

For detailed information on the effects of operations on EXCLUSIVE files, see "The EXCLUSIVE Attribute," in Chapter 14.

The ENVIRONMENT Attribute

The ENVIRONMENT attribute specifies information about the physical organization of the data set associated with a file.

These characteristics are indicated in a parenthesized option list in the ENVIRON-MENT attribute specification and are depen-dent upon the implementation. The option list for the F Compiler is discussed in

"Environmental Considerations for Data sets."

OPENING AND CLOSING FILES

Before the data associated with a file can be transmitted by input or output statements, certain file preparation activ-ities must occur, such as checking for the availabili ty of external storage media., positioning the medium, and allocating appropriate programming support. Such activity is known as opening a file,. Also"

when processing is completed~ the file must be closed. Closing a file involves releas-ing the facilities that were established during the opening of the file.

PL/I provides two statements, OPEN and CLOSE, to perform these functions. These statements, however, are·optional. If an OPEN statement is not executed for a file, the file is opened automatically when the first data transmission statement for that

file is executed: in this case, the auto-matic file preparation consists of standard system procedures that use information about the file as specified in a DECLARE statement (or assumed from a contextual declaration). Similarly, if a file has not been closed before completion of a program, the file is closed automatically upon nor-mal completion of the program.

The following discussions show the effect of OPEN and CLOSE statements upon files specified in these statements.

'I'he OPEN stateIIJent

Execution of an OPEN state~ment causes one or more files to be opened explicitly.

']~he OPEN statement has the following basic format:

OPEN FILE(file-name) [option-list]

[,FILE(file-name) [option-list]] ••• : The option list of the OPEN statement can specify any of the alternative and additive attributes, except the INTERNAL., EXTERNAL, and ENVIRONMENT attributes. Attributes included as options in the OPEN statement are merged with those stated in a DECLARE statement. The same attributes need not be listed in both an OPEN statement and a DECLARE statement for the same~ file, and, of course, there can be no conflict. Other options that can appear in the OPEN state-ment are the TITLE option, used to asso-ciate the file name with the dat.a set" and the PAGESIZE and LINESIZE options, used to

I

specify layout of a data set. All of these options are discussed later in this chap-ter. The option list may precede the FILE

(file name) specification.

For the F Compiler, the OPEN statement is executed by library routines that are loaded dynamically at the time the OPEN statement is executed. Consequently, exe-cution time can be reduced if more than one file is specified in the same OPEN state-ment, since the routine~ need be loaded only once, regardless of the number of files being opened. Note, however, that such multiple opening may require consider-ably more storage than might otherwise be needed .•

For a file to be opened explicitly, the OPEN statement must be executed before any of the input and output statements listed below in "Implicit Opening" are executed for the same file.

Implicit Opening

An implicit opening of a file occurs

",'hen one of the statements listed below is executed for a file for which an OPEN statement has not already been executed.

The statement type determines which unspe-cified alternatives are applied to the file when it is opened.

The following list contains the state-ment identifiers and the attributes deduced from each:

statement Identifier GET

PUT READ WRITE LOCATE REWRITE DELETE UNLOCK

Attributes Deduced STREAM, INPUT STREAM, OUTPUT RECORD, INPUT

(see Note) RECORD, OUTPUT

(see Note) RECORD, OUTPUT, SEQUENTIAL, BUFFERED RECORD, UPDATE

RECORD, UPDATE RECORD, DIRECT, UPDATE, EXCLUSIVE An implicit opening caused by one of the above statements is equivalent to preceding t.he statement with an OPEN statement that specifies the deduced attributes.

Note: INPUT and OUTPUT are deduced from READ and WRITE only if UPDATE has not been explicitly declared.

Mer.ging of Attributes

There must be no conflict between the attributes specified in a file declaration and the attributes merged -- explicitly or implicitly as the result of the file opening. For example, the attributes INPUT and UPDATE are in conflict, as are the attributes UPDATE and STREAM~

After the attributes are merged, the attribute implications listed below are applied prior to the application of the default attributes discussed earlier.

Implied attributes can also cause a con-flict. If a conflict in attributes exists after the application of default attri-butes, the UNDEFINEDFILE condition is x'aised.

Following is a list of merged attributes and attributes that each implies after merging:

Me~~Attributes

UPDATE

Implied Attributes RECORD

SEQUENTIAL DIRECT BUFFERED UNBUFFERED PRINT BACKWARDS

KEYED EXCLUSIVE

RECORD

RECORD, KEYED RECORD,

SEQUENTIAL RECORD,

SEQUENTIAL OUTPUT, STREAM RECORD,

SEQUENTIAL, INPUT RECORD

RECORD, KEYED, DIRECT, UPDATE The following two examples illustrate attribute merging for an explicit opening and for an implicit opening.

Explicit opening:

DECLARE LISTING FILE STREAMi

OPEN FILE(LISTING) PRINTi

Attributes after merge due to execution of the OPEN statement are STREAM and PRINT.

Attributes after implication are STREAM, PRINT, and OUTPUT. Attributes after default application are STREAM, PRINT, OUT-PUT, and EXTERNAL.

Note: The attributes SEQUENTIAL or DIRECT and:E.UFFERED or UNBUFFERED do not apply to a file with the STREAM attribute.

Implicit opening:

DECLARE MASTER FILE KEYED INTERNALi

READ FILE (MASTER) INTO

(MASTER RECORD) KEYTO(MASTER_KEY)i Attributes after merge due to the opening caused by execution of the READ statement are KEYED, INTERNAL, RECORD, and INPUT.

Attribut.es after implic~tion are KEYED, INTERNAL, RECORD, and INPUT. There are no additional attributes implied. Attributes

aftE~r default. application are KEYED, INTER-94

NAL, RECORD, INPUT, SEQUENTIAL, and BUF-FERED.

With the System/360 Operating System, the association of a file with a specific data set is accomplished using job control language, outside the PL/I program. .~t the time a file is opened, the PL/I file name is associated with the name (ddname) of a data definition statement (CD statement), which is, in turn, associated with the name of a specific data set (dsname). Nob~ that the direct association is with the name of a DD statement, not with the name of the data set itself.

A ddname can be associated with a PL/I file either through the file name or through the character-string value of the expression in the TITLE option of the associated OPEN statement.

If a file is opened implicitly, or if no TITLE option is included in the OPEN state-ment that causes explicit opening of the

file, the ddname is assumed to be the same as the file name. If the file name is longer than eight characters, the ddname is assumed to be composed of the first eight characters of the file name.

~ Since external names are limi t.ed to seven characters for the F Compiler, an external file name of more than seven characters is shortened into a concatena-tion of the first four and the last three characters of the file name. such a shor-tened name is not, however, the namE~ used as the ddname in the associated DD state-ment.

consider the following statements:

1. OPEN FILE(MASTER)i 2. OPEN FILE(OLDMASTER)i 3. READ FILE(DETAIL) ••• i

When statement number 1 is executed, the file name MASTER is taken to be the salme as the ddname of a DD statement in the current job step. When statement number 2 is executed, the name OLDMASTE is taken to be the same as the ddname of a DD statemE!nt in the current job step. (The first eight characters of a file name form the ddname.

Note, however., that if OLDMASTER i.s an external name, it will be shortened by the compiler to OLDMTER for use within. the program.) If statement number 3 causes implicit opening of the file DETAIL, the name DETAIL is taken to be the same as the

ddname of a DD statement in the current job s·tep .•

In each of the above cases. a corres-ponding DD statement must appear in the job stream; otherwise, the UNDEFINID)FILE condi-tion would be raised. The three DD state-ments would appear, in part, as follows:

1. //MASTER DD DSNAME=., ••

2. / /OLDMASTE DD DSNAME= .... a

2. / /OLDMASTE DD DSNAME= .... a

Dans le document IBM System/360 (Page 92-101)