z/OS DFSMS Using Data Sets
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


JCL Parameters for UNIX Files

z/OS DFSMS Using Data Sets
SC23-6855-00

You can use the following JCL parameters when working with UNIX files.
FILEDATA
Use the FILEDATA keyword to describe the organization of a UNIX file so that the system can determine how to process the file. The access methods use both EBCDIC text and binary formats for UNIX files. Files can have differing values for the FILEDATA parameter. Each DD statement can have its own FILEDATA value. The FILEDATA value is saved with the UNIX file. If you do not code the FILEDATA keyword on the DD statement, the FILEDATA value that is associated with each file takes effect.
BINARY
Indicates the data is a byte-stream and does not contain record delimiters or record prefixes. Each record is the maximum length. Binary is the default value. Code FILEDATA=BINARY for records without line delimiters or record prefixes.
TEXT
Indicates that the data consists of records separated by a delimiter of the EBCDIC newline character (X'15'). The record delimiters are transparent to the user. Code FILEDATA=TEXT if records are text and each record ends with a line delimiter. On output, the access method inserts a record delimiter at the end of each record. On input, the access method uses the delimiter to find the end of each record and adds trailing blanks if the record format (RECFM) is fixed and is shorter than the LRECL value.
RECORD
Indicates that the data consists of records with prefixes. The record prefix contains the length of the record that follows. On output, the access method inserts a record prefix at the beginning of each record. On input, the access method uses the record prefix to determine the length of each record. The access method does not return the prefix as part of the record. Code FILEDATA=RECORD when you cannot code FILEDATA=TEXT because your data might contain bytes that are considered delimiters.
Note: the record prefix for FILEDATA=RECORD is mapped by the IGGRPFX macro. This is different from the record descriptor word (RDW) that is in z/OS physical sequential format-V data. The record prefix is four bytes in this format:
Offset  Length     Symbol       Description

  0       1          RPFX00     Reserved.
  1       3          RPFXLLL    Length of record 
                                that follows this
                                prefix.  
The value in an RDW includes the length of the RDW but the value in a record prefix excludes the length of the record prefix.

The FILEDATA parameter is effective only when the PATH parameter is also coded and the program uses BSAM, QSAM, VSAM, or BPAM.

When FILEDATA is coded for an existing UNIX file, the value specified temporarily overrides the value saved with the file. There is one exception: if the existing file does not already have a FILEDATA value saved with the file (that is, the UNIX file was created without coding FILEDATA) and the user has the proper authority to update the UNIX file, an attempt is made during OPEN to save the specified FILEDATA value with the file.

When FILEDATA is not coded and a value has not been saved with the file, the file is treated as binary.

If you code FILEDATA=RECORD, the access method follows a portion of RFC 4506, XDR, External Data Representation Standard. It is an IETF (Internet Engineering Task Force) standard, STD 67. That standard defines a variety of types of data. The records that FILEDATA=RECORD defines are either of these XDR types:
  • Variable-length opaque data
  • String
However the access method does not follow one characteristic of the XDR standard. The standard specifies that if the number of bytes of data is not a multiple of four, then the bytes are padded on the right with binary zeroes. That would require the access method to insert the bytes so that every record begins at an offset that is a multiple of four from the beginning of the UNIX file. The access method does not insert any padding. The XDR standard specifies that the string contains ASCII characters. The access method does no data conversion or test of the bytes.
PATH
Specifies the name of the UNIX file.
PATHOPTS
Use the PATHOPTS parameter to specify the file access and attributes for the UNIX file named in the PATH parameter. During allocation of a new UNIX file, if you specify either OCREAT alone or OCREAT with OEXCL in the PATHOPTS parameter, DFSMS performs an open( ) function. The path name from the PATH parameter, the options from PATHOPTS, and the options from PATHMODE, if specified, are passed to the open( ) function.

When the application program issues an OPEN macro for an existing UNIX file, the OPEN macro establishes a connection to the existing file. The path name from the PATH parameter is passed without modification. The options from PATHMODE are not passed because the UNIX file must already exist.

PATHDISP
Specifies the disposition of the UNIX file. You can specify whether to keep or delete the file when the job step ends.
PATHMODE
Specifies the file access attributes when the system is creating the UNIX file named on the PATH parameter. To create the file, specify a PATHOPTS=OCREAT parameter.

Restriction: For a DD statement that contains a PATH parameter, you cannot specify the DATACLAS, STORCLAS, and MGMTCLAS options because the ACS routines are not called.

Related reading: For more information on the JCL parameters for UNIX files, see z/OS MVS JCL Reference. For more information on using UNIX files, see z/OS UNIX System Services User's Guide.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014