The full form for specifying a z/OS data set by its name is //'dsname'
or
//'dsname(member)'
where dsname is the 1-character to 44-character fully-qualified data set name and member is a 1-character to 8-character member name for a partitioned (DSORG=PO) data set or a numeric Generation Data Group (GDG) index (possibly beginning with + or -).
The pair of forward slashes signify that what follows is not an HFS file name. They are required in order to access a data set in a POSIX ON environment. When POSIX is OFF they can be omitted.
The apostrophes (single quotes) indicate that dsname is a complete data set name not subject to LE prefixing. If you omit the apostrophes, LE prefixes dsname with the PROFILE PREFIX (in TSO) or with the z/OS userid (in all other environments). (If you have enabled Oracle C runtime compatibility, prefixing occurs only in TSO.) If a TSO session has PROFILE NOPREFIX set, no prefix is added. Apostrophes also affect Oracle's tendency to add a suffix extension to a data set name; this is discussed later in the section "File Name Manipulation" on page 2-21.
The dsname and member portions of the filespec are case-insensitive: lower case letters are converted to upper case. To be usable, a data set name must ultimately have two or more name segments or qualifiers. The name in the filespec can be a single qualifier as long as prefixing and/or suffix extension applies to supply a second qualifier. If apostrophes are used to prevent prefixing (or if PROFILE NOPREFIX is set in TSO), the name in the filespec normally must have two or more qualifiers.
A data set referenced in this fashion can be physical sequential (DSORG=PS),
partitioned (DSORG=PO), or VSAM (ESDS, KSDS, or RRDS). Use of VSAM is limited to certain Oracle components or features discussed in later chapters. If the filespec is being used for output purposes and the data set does not exist, it is created through z/OS dynamic allocation as a non-VSAM (PS or PO) data set. (Creation of VSAM data sets is not supported.) Dynamic creation relies on installation default mechanisms to determine SMS classes (or unit and volume) as well as disk space allocation. These may or may not be appropriate for your application and you may want to consider preallocating such data sets and/or using a DD filespec, discussed later. Space allocation for some types of files can also be influenced using FNA, described later.
For an input file it is legal to specify a partitioned data set name with no member name. Doing so, however, accesses the directory data of the PDS rather than any member. There currently are no Oracle components that exploit this capability.
The following are examples of valid data set name filespecs.
//'JSMITH.ORAEXP.TEST.DAT' prod.sql(case1)
'ODB1.init.ora' //discard1 //SAMPLE.LOG
In the prior set of examples, the first, fourth, and fifth are unambiguous.
DD Names
You can identify a file as a DD statement or TSO allocation using the following filespec forms:
//DD:name or
//DD:name(member)
where name is the 1-character to 8-character DD name and member is a 1- to 8-character member name when the DD statement or allocation is a partitioned (DSORG=PO) data set.
The pair of forward slashes signify that what follows is not an HFS file name. When POSIX is OFF they can be omitted. If they are omitted when POSIX is ON, LE does
something surprising: it checks to see if the specified DD name is allocated in the job or address space. If it is, the DD is opened. If it is not, an HFS file named DD:name or DD:name(member) is opened. This is one case where the interpretation of an ambiguous filespec depends on more than just POSIX.
The DD: portion of the filespec is required to indicate that what follows is a DD name.
It is case-insensitive and can use any of the 4 possible combinations of upper case and lower case "D." The name and member parts are also case-insensitive and are
converted to upper case.
The DD statement or TSO allocation specified by this filespec can be any of the following:
■ Physical sequential (DSORG=PS) or partitioned (DSORG=PO) data set
■ VSAM KSDS, ESDS, or RRDS cluster
■ Instream data for input usage (DD *) or SYSOUT for output usage
■ Dummy (DD DUMMY)
■ TSO terminal (DD TERM=TS or TSO ALLOCATE DA(*))
■ HFS file (DD PATH=)
If the file is being used as input, the DD can be a concatenation of multiple data sets of compatible type and DCB attributes.
When a partitioned data set is used, either the filespec or the DD statement (but not both) can include the parenthesized member name. If neither specifies a member name, the PDS directory data is accessed rather than any member; this is allowed only with input usage.
Files specified as DD name filespecs have some specific behaviors in Oracle software.
Name manipulation operations such as extension have no effect on a DD filespec nor can such a filespec be parsed or divided into logical pieces. This affects the way some Oracle components work when using DD filespecs. This is covered in more detail in
"File Name Manipulation" on page 2-21 and in the later chapters dealing with specific Oracle components.
The following are examples of DD name filespecs:
//dd:mysql DD:LIB1(sample) dD:x
//DD:REPORT
In the prior set of examples, the second and third are ambiguous; when POSIX is ON, they are subject to the processing discussed earlier.
SYSOUT
Oracle provides a logical extension of LE file syntax for direct specification of SYSOUT data sets for output. This is usable in most places where Oracle requires an output file specification but it is associated primarily with text (message or report) files. The filespec syntax is
//SYSOUT:class,form,dest
where class is the 1-character SYSOUT class, form is a 1-character to 4-character form name, and dest is a 1-character to 8-character JES destination identifier.
The pair of forward slashes signify that what follows is not an HFS file name. They are required in order to use a SYSOUT filespec in a POSIX ON environment. When POSIX is OFF they can be omitted.
The SYSOUT: portion of the filespec is required to indicate that what follows is a SYSOUT specification. It is case-insensitive and can use any combination of upper- and lower-case letters. It also can be abbreviated to S: or s:.
The class is a valid JES SYSOUT class (letter or digit), or an * (asterisk) signifying that the job's MSGCLASS be used. If the class is omitted it defaults to *. If you omit the class but want to supply a form or destination, code a single comma.
The form is a valid JES form name. The default, when form is omitted, is
installation-dependent. If you omit the form name but want to supply a destination, code a single comma.
The dest is a valid JES destination identifier. Legal destination values and the default depend on whether your z/OS system uses JES2 or JES3.
Check with your z/OS system administrator for specific information on output classes, form names, and destinations used in your installation.
Like DDs, SYSOUT filespecs are immune to file name manipulation operations such as extension and parsing. Here are some examples of SYSOUT filespecs:
//SYSOUT:G,,JSMITH s:
sysout:*,STD //S:,,HQPRT1
The second and third examples are ambiguous and would result in oddly-named HFS files in a POSIX ON application.