CRTLF (Create Logical File)

CRTLF Command syntax diagram

 

Purpose

The Create Logical File (CRTLF) command creates a logical file in the database. The logical file is created from the file description parameters in this CRTLF command and from the previously entered data description specifications (DDS) that contain the source description of the logical file. A logical file is a database file that describes how data records contained in one or more physical files are presented to a program. The logical file does not contain data records. The data records are contained in the physical files associated with the logical file. To override the attributes of the logical file after it has been created, use the Override Database File (OVRDBF) command before the file is opened. To change the attributes of the logical file after it has been created, use the Change Logical File (CHGLF) command.

 

Restrictions

  1. To create a keyed logical file over one or more physical files, the user must have object operational and object management authorities or object alter authority for each of the files specified on the PFILE or JFILE keywords in DDS. To create a non-keyed logical file, only object operational authority is required.

  2. In multithreaded jobs, this command is not threadsafe for distributed files and fails for distributed files that use relational databases of type *SNA.

  3. The processing done for the *EVENTF value of the OPTION keyword is not threadsafe

 

Required Parameters

FILE
Specifies the qualified name of the file being created. If the file is used by a high-level language (HLL) program, the file name must be consistent with the naming rules of that language; otherwise, the file must be renamed in the program.

The name of the logical file can be qualified by one of the following library values:

*CURLIB: The logical file is created in the current library for the job. If no library is specified as the current library for the job, the QGPL library is used.

library-name: Specify the name of the library where the logical file is created.

Note: If a logical file and the physical file on which it is based are in different libraries, and the logical or physical file does not exist when it is to be restored (such as during disaster recovery or when the files are deleted), the access path is not restored. It is rebuilt. To make it possible for access paths to be restored and not rebuilt, the logical files and the based-on physical files must be in the same library. More information on the restoring of saved access paths is in the Backup and recovery topic in the Information Center.

logical-file-name: Specify the name of the file that is to be created.

Note: If a DDM file is specified, the logical file (specified in the RMTFILE parameter on the Create Distributed Data Management File (CRTDDMF) command) is created on a remote system (specified in the RMTLOCNAME parameter of the CRTDDMF command). See the SYSTEM parameter of this command.

 

Optional Parameters

SRCFILE
Specifies the qualified name of the source file that contains the DDS used to create the logical file. The source file contains the specifications that describe the record formats and their fields, and the access paths for the file and its members. The specifications that can be made in DDS are discussed in the Database Programming topic in the Information Center and DDS Reference topic in the Information Center.

The name of the source file can be qualified by one of the following library values:

*LIBL: All libraries in the job's library list are searched until the first match is found.

*CURLIB: The current library for the job is searched. If no library is specified as the current library for the job, the QGPL library is used.

library-name: Specify the name of the library to be searched.

QDDSSRC: The source file, QDDSSRC, contains the DDS used to create the logical file.

source-file-name: Specify the name of the source file that contains the DDS used to create the logical file.

SRCMBR
Specifies the name of the source file member that contains the DDS for the logical file being created; the member is in the source file specified in the SRCFILE parameter (or its default, QDDSSRC).

*FILE: The source file member name is the same as that of the logical file being created.

source-file-member-name: Specify the name of the member in the source file specified by the SRCFILE parameter that is used to create the logical file.

OPTION
Specifies the type of output produced when the file is created. A maximum of four of the following values can be specified in any order on this parameter. If neither or both of the values on an option are specified, the underlined value is used.

Note: The underlined values for this parameter are similar to, but not actually default values, and therefore, cannot be changed with the CHGCMDDFT (Change Command Default) command.

Source Listing Options

*SRC or *SOURCE: A printout is created of the source statements used to create the file and of the errors that occur.

*NOSRC or *NOSOURCE: No printout of the source statements is created unless errors are detected. If errors are detected, they are listed along with the record format that contains the error.

Program Listing Options

*LIST: An expanded source printout is created, showing a detailed list of the file specifications that result from the source statements and references to other file descriptions.

*NOLIST: An expanded source printout is not created.

Second-Level Message Text Options

*NOSECLVL: The messages section of the DDS printout does not contain the second-level message for the errors found during DDS processing.

*SECLVL: Second-level message text is included in the source listing.

Event File Creation Options

*NOEVENTF: The compiler does not produce an event file for the CoOperative Development Environment/400 (CODE/400) product.

*EVENTF: The compiler produces an event file that can be used by the CODE/400 product. The event file is created as a member in the file EVFEVENT in your object library. The CODE/400 product uses this file to offer error feedback integrated with the CODE/400 editor. This value is normally specified by the CODE/400 product on your behalf.

SYSTEM
Specifies whether the logical file is created on the local system or the remote system.

*LCL: The logical file is created on the local system.

*RMT: The logical file is created on a remote system using DDM. The logical file name specified on the FILE parameter must be the name of the DDM file, which is created using the Create Distributed Data Management File (CRTDDMF) command. The DDM file contains the name of the logical file being created (RMTFILE parameter on the CRTDDMF command) and the name of the remote system (RMTLOCNAME parameter on the CRTDDMF command) on which the file is to be created.

*FILETYPE: If the name specified on the FILE parameter is a DDM file, the logical file is created on the remote system specified by CRTDDMF(RMTLOCNAME) for that DDM file. Otherwise, the name on the FILE parameter cannot be the name of an existing file since a logical file of that name is created on the local system.

GENLVL
Specifies the severity level at which the create operation fails. If errors occur that have a severity level greater than or equal to this value, the operation ends.

Note: This parameter applies only to messages created while processing DDS source. Messages created anywhere else in the file creation process are not affected by this parameter.

20: If errors occur in the DDS source with a severity level greater than or equal to 20, the file is not created.

severity-level: Specify a severity level ranging from 0 through 30. The file is not created if the severity level specified for this parameter equals 0 or is less than the severity level that occurs in the data description specifications (DDS) source. This value must be greater than or equal to value specified on the FLAG parameter.

FLAG
Specifies the minimum severity level of messages to be listed in the DDS source listing.

0: The spooled file is owned by the original user profile of the job. If the job has switched to a new user profile, the original user profile is still the owner of the spooled file.

severity-level: Specify the minimum severity level of messages to be listed. Valid values range from 0 through 30. The severity level specified must be less than or equal to the severity level specified on the GENLVL parameter.

FILETYPE
Specifies whether each member of the logical file being created contains data records, or contains source records (statements) for a program or another file. The file could contain, for example, RPG source statements for an RPG program or DDS source statements for another physical, logical, or device file. More information on this parameter is in Commonly used parameters.

*DATA: The logical file contains data records.

*SRC: The logical file contains source records. This value cannot be specified for join logical files.

MBR
Specifies the name of the logical file member that is added when the logical file is created. Other members can be added to the file after it is created by using the Add Logical File Member (ADDLFM) command.

*FILE: The member being added has the same name as that of the logical file that contains the member. This name is specified on the FILE parameter.

*NONE: No member is added when the file is created.

logical-file-member-name: Specify the name of the member that is added when the logical file is created.

DTAMBRS
Specifies the names of the physical files and members that contain the data associated with the logical file member being added by this command. A logical file member can be based on all of the physical files and members on which the logical file itself is based, specified by DTAMBRS(*ALL), or the member can be based on a subset of the total members and files, specified by DTAMBRS(qualified-file-names (member-names)).

When a logical file is created, the physical files specified on the PFILE or JFILE DDS keyword are used to create the logical file. If no library name is specified for the physical files on the PFILE or JFILE keyword, the library list (*LIBL) at file creation time is used to find the physical files; the physical files from the library list are used to create the logical file. The qualified physical files from the PFILE or JFILE keyword (regardless of whether a library name was specified or if the library list was used to find the files) are the physical files associated with the logical file. The names of the physical files associated with the logical file are saved in the description of the logical file. When a member is added to the logical file, the DTAMBRS parameter is used to specify the physical file members associated with the logical file member. Each physical file name specified on the DTAMBRS parameter must be the name of a physical file that is associated with the logical file (saved in the description of the logical file).

*ALL: The logical file member being added is based on all the physical files and members (that exist at the time this CRTLF command is entered) used by the logical file. At least one member must exist in at least one of the physical files. The physical file names are specified on the PFILE or JFILE parameter in the DDS.

*CURRENT: The library where the logical file is being created is used to locate the specified physical file.

library-name: Specify the name of the library to be searched.

If a library name is not specified, the current library name (*CURRENT) from the logical file description is used. If the library name is specified, the physical file must be a physical file associated with the logical file. If the logical file is associated with more than one physical file of the same name, the library name must be specified.

Element 1: Names of Physical Files

physical-file-name: Specify the names of the physical files that contain the data being accessed by the logical file member being added.

The physical file names must match a name on the PFILE or JFILE keywords in the DDS and cannot be specified more often on the DTAMBRS parameter than on the PFILE or JFILE keywords in the DDS. For join logical files, all physical files specified on the JFILE keyword must be specified on the DTAMBRS parameter and each physical file must contain only one member. If a physical file name is not specified for a physical file that is on a PFILE or JFILE keyword in the DDS, the logical file member is not based on any member of that physical file.

Element 2: Names of Members

*NONE: A member name is not specified.

member-name: Specify the names of the members that contain the data being accessed by the logical file member being added.

When the FILE parameter specifies a join logical file or an arrival sequence logical file, only one data member must be specified on the DTAMBRS parameter for each physical file that was specified on the PFILE or JFILE keyword in the DDS. *ALL is valid only if each based-on physical file has only one member. If any of the physical files has more than one member, the specific physical file member must be specified on the DTAMBRS parameter.

The same physical file name can be specified more than once on the JFILE keyword. In this case, each occurrence of the file name is treated as a different based-on physical file, and must be specified on the DTAMBRS parameter.

Up to 32 qualified physical file names and physical file member names can be specified. Also, the total number of member names cannot exceed 32. For example, one file can specify 32 members, two files can each have 16 members, or 32 files can each have one member specified.

For DDM file:

  • The file names specified in the DTAMBRS parameter must be the names of the DDM files that represent the remote based-on physical files. If a member name was specified as part of the remote file name in the DDM file, only that member name can be specified on the DTAMBRS parameter. The member names must be the actual remote file member names.

  • The based-on physical files must be at the same system location as the logical file to which the member is being added.

  • When no member name is specified for the remote file name in the DDM file, all members are accessible. When only one member name is specified, only that member is accessible through that DDM file.

The following examples show the syntax for specifying single and multiple members for single and multiple physical files. In the examples, the abbreviation PF represents a physical file name, LIB represents a library qualifier, and M represents a member name. 

Single physical file and member:
DTAMBRS((PFA M1))
Single file with multiple members:
DTAMBRS(PFA (M1 M2 M3))
Multiple files with single members and no members:
DTAMBRS((PFA M1) (PFB M4) (PFE *NONE))
Multiple files with multiple members:
DTAMBRS((PFA (M1 M3 M4)) (PFB (M1 M2 M4)))
Multiple files with the same name in different libraries:
DTAMBRS((LIBX/PFA M1) (LIBY/PFA (M1 M2)))
Multiple files with the same name in the same library:
DTAMBRS((LIBX/PFA M1) (LIBX/PFA M1))

When more than one physical file member is specified for a physical file, the member names are specified in the order in which records are retrieved when duplicate key values occur across those members.

Refer to "Additional Considerations" at the end of this command description for more details.

MAXMBRS
Specifies the maximum number of members that the logical file being created can contain.

1: Only one member can be contained in the file.

*NOMAX: The system maximum is used.

maximum-members: Specify the maximum number of members that the logical file can contain. Valid values range from 1 through 32767.

ACCPTHSIZ
Specifies the maximum size of auxiliary storage that can be occupied by access paths that are associated with join logical files or with files that have keyed sequence access paths.

Note: For a join logical file, this parameter applies to all join secondary access paths even if the join logical file is not a keyed file.

*MAX1TB: The access paths associated with this file can occupy a maximum of one terabyte (1,099,511,627,776 bytes) of auxiliary storage.

Note: This value is not supported on releases of the system earlier than Version 3 Release 6 Modification 0 (V3R6M0). Therefore, if a logical file that has this attribute is saved, and the save operation specifies a target release earlier than V3R6M0, the access paths are not saved. If this saved version of the file is then used to restore the logical file, the system rebuilds all of the access paths.

*MAX4GB: The access paths associated with this file can occupy a maximum of four gigabytes (4,294,966,272 bytes) of auxiliary storage. This value provides compatibility with releases of the operating system earlier than Version 3 Release 6 Modification 0.

MAINT
Specifies, for join logical files or files with keyed sequence access paths, the type of access path maintenance being used for every member of the logical file.

Note: For a join logical file, this parameter applies to all join secondary access paths, even if the join file is not a keyed file.

*IMMED: The access path is maintained for each physical file member whether the source physical file is opened or closed. The access path is changed whenever a record is updated, added to, or deleted from a member of this file or a logical file member based on a member of this file.

*REBLD: The access path is completely rebuilt when a logical file member is opened. The access path is continuously maintained until the member is closed; the access path maintenance is then ended. *REBLD is not valid for access paths that require unique key values.

*DLY: The maintenance of the access path is delayed until the logical file member is opened. Then the access path is changed only for records that have been added, deleted, or changed since the file was last opened. While the file is open, all changes made to based-on file members are immediately reflected in the access paths of the opened file's own members, no matter what is specified for this parameter. To prevent a long rebuilding time when the file is opened, *DLY should be specified only when the number of changes to the access path between successive open operations are small; that is, when the file is opened frequently or when the key fields in records for this access path change infrequently. *DLY is not valid for access paths that require unique key values.

If the number of changes between a close operation and the next open operation reaches approximately 10 percent of the access path size, the system stops saving changes and the access path is completely rebuilt the next time the file is opened.

RECOVER
Specifies, for files having immediate or delayed maintenance on their access paths, when recovery processing of the file is performed after a system failure occurs while the access path is being changed. This parameter is valid only for join logical files or files with a keyed access path.

If *IMMED or *DLY is specified for the MAINT parameter, the access path can be rebuilt during initial program load (IPL) (before any user can run a job), after IPL has ended (during concurrent job running), or when the file is next opened. While the access path is being rebuilt, the file cannot be used by any job.

During the IPL, an Override Access Path Recovery display lists those paths that must be recovered and what the RECOVER parameter value is for each path. The user can override the RECOVER parameter value on this display. More information is in the Backup and recovery topic in the Information Center.

If *REBLD is specified for the MAINT parameter, the access path is rebuilt the next time its file is opened.

*NO: The access path of the file is not rebuilt during or after the IPL. The file's access path is rebuilt when the file is next opened. *NO is the default for all files that do not require unique keys.

*AFTIPL: The file has its access path rebuilt after the IPL has been completed. This option allows other jobs not using this file to start processing immediately after the completion of IPL. If a job tries to allocate the file while its access path is being rebuilt, a file open exception occurs. *AFTIPL is the default for files that require unique keys.

*IPL: The file has its access path rebuilt during the IPL. This ensures that the file's access path is rebuilt before the first user program tries to use it; however, no jobs can start running until after all files that specify RECOVER(*IPL) have their access paths rebuilt.

FRCACCPTH
Specifies, for join logical files or files with keyed access paths, whether access path changes are forced to auxiliary storage along with the associated records in the file whenever the access path is changed. FRCACCPTH(*YES) minimizes (but does not remove) the possibility that an abnormal job end could cause damage to the access path that would require it to be rebuilt.

Note: For a join logical file, this parameter value applies to all join secondary files even if the join file is not a keyed file.

*NO: The access path and changed records are not forced to auxiliary storage whenever the access path is changed.

*YES: The access path and changed records are forced to auxiliary storage whenever the access path is changed. If this value is specified, MAINT(*REBLD) cannot be specified.

FRCACCPTH(*YES) slows the response time of the system if the access path is changed in an interactive job. If the access path is changed frequently, the overall performance of the system is affected somewhat.

UNIT
This parameter is no longer supported. It exists solely for compatibility with releases earlier than Version 3 Release 6 Modification 0 of the AS/400 system. For information on using auxiliary storage pools (ASPs), refer to the Backup and recovery topic in the Information Center.

You can specify the value *ANY or a value ranging from 1 through 255 on this parameter.

FMTSLR
Specifies the qualified name of a record format selector program that is called when the logical file member contains more than one record format. The user-written selector program is called when a record is inserted into the database file and a record format name is not included in the high-level language program. The selector program receives the record as input, determines the record format used, and returns it to the database. This program must perform this function for every member in the logical file that has more than one record format, unless the high-level language program itself specifies the record format name. More information about the use of format selector programs is in the Database Programming topic in the Information Center.

This parameter is not valid if the logical file has only one record format.

*NONE: There is no selector program for this logical file. If the file has more than one logical record format, the high-level language program must specify the record format name.

The name of the program can be qualified by one of the following library values:

*LIBL: All libraries in the job's library list are searched until the first match is found.

*CURLIB: The current library for the job is searched. If no library is specified as the current library for the job, the QGPL library is used.

library-name: Specify the name of the library to be searched.

program-name: Specify the name of the format selector program to be called when a record is inserted into a member having more than one format. The selector program name can be optionally qualified by the name of the library in which the program is stored. If no library qualifier is given, *LIBL is used to find the program.

A program specified as the format selector program cannot be created with USRPRF(*OWNER) specified in its create program command.

FRCRATIO
Specifies the number of inserted, updated, or deleted records that are processed before they are forced to auxiliary (permanent) storage. More information on this parameter is in Commonly used parameters.

The force write ratio specified for a logical file cannot be less than or equal to the smallest force write ratio of its based-on files. If a larger force write ratio is specified, it is ignored and a message is sent informing the user of the action.

For example, if the force ratios of three physical files are 2, 6, and 8, the logical file force ratio that is based on these three physical files must be as restrictive as the least of them; that is 2 in this case. Two would be used even if the FRCRATIO parameter is not specified. Thus, each time a program inserts, updates, or deletes two records in the logical file (regardless of which based-on physical files are affected), those records are forced to permanent storage.

If a physical file associated with this logical file is being journaled, a large force write ratio or *NONE is specified. More information on journal management is in the Backup and recovery topic in the Information Center.

*NONE: There is no specified force ratio; the system determines when the records are written to auxiliary storage.

number-of-records-before-force: Specify the number of inserted, updated, or deleted records that are processed before they are explicitly forced to auxiliary storage.

WAITFILE
Specifies the number of seconds that the program waits for the file resources and session resources to be allocated when the file is opened, or for the device or session resources to be allocated when an acquire operation is performed to the file. If those resources are not allocated within the specified wait time, an error message is sent to the program. More information on this parameter is in Commonly used parameters.

Note: An immediate allocation of the device by the device resource is required when an acquire operation is performed to the file.

*IMMED: The program does not wait; when the file is opened, an immediate allocation of the file resources is required.

*CLS: The job default wait time is used as the wait time for the file resources being allocated.

number-of-seconds: Specify the number of seconds that a program waits for the file resources to be allocated to the job. Valid values range from 1 through 32767 seconds.

WAITRCD
Specifies the number of seconds that a program waits for a record to be updated or deleted, or for a record read in the commitment control environment with LCKLVL(*ALL) specified. More information on record locking is in the Database Programming topic in the Information Center. If the record is not allocated in the specified wait time, an error message is sent to the program.

60: A program waits for 60 seconds.

*NOMAX: The system maximum is used.

*IMMED: The program does not wait; when a record is locked, an immediate allocation of the record is required.

number-of-seconds: Specify the number of seconds that a program waits for the file resources to be allocated to the job. Valid values range from 1 through 32767 seconds.

SHARE
Specifies whether the open data path (ODP) for the logical file is shared with other programs in the routing step. When an ODP is shared, the programs accessing the file share facilities such as the file status and the buffer.

More information on shared database files is in the Database Programming topic in the Information Center.

*NO: The ODP created by the program with this attribute is not shared with other programs in the routing step. Every time a program opens the file with this attribute, a new ODP to the file is created and activated.

*YES: The ODP created with this attribute is shared with each program in the routing step that also specifies SHARE(*YES) when it opens the file, provided the scope specified on the OPNSCOPE keyword for the subsequent open of the file is compatible with the scope of the original open.

Note: When SHARE(*YES) is specified and control is passed to a program, a read operation in that program retrieves the next input record. A write operation produces the next output record.

SRTSEQ
Specifies the sort sequence used for this file. The sort sequence is used with the LANGID parameter to determine which sort sequence table is used.

*SRC: The table specified in the DDS on the ALTSEQ parameter is used. If ALTSEQ is not used in the DDS, use the value specified for *JOB on this parameter.

*JOB: The sort sequence value used is the value for the job issuing this command to create the logical file.

*LANGIDSHR: The sort sequence table uses the same weight for multiple characters, and is the shared-weight sort sequence table associated with the language specified on the LANGID parameter.

*LANGIDUNQ: The sort sequence table must contain a unique weight for each character in the code page.

*HEX: A sort sequence table is not used. The hexadecimal values of the characters are used to determine the sort sequence.

The name of the table can be qualified by one of the following library values:

*LIBL: All libraries in the job's library list are searched until the first match is found.

*CURLIB: The current library for the job is searched. If no library is specified as the current library for the job, the QGPL library is used.

library-name: Specify the name of the library to be searched.

table-name: Specify a table name.

LANGID
Specifies the language identifier to be used when SRTSEQ(*LANGIDUNQ) or SRTSEQ(*LANGIDSHR) is specified. The language identifier is used with the SRTSEQ parameter to determine which sort sequence table is used.

*JOB: The language identifier specified for the job is used.

language-identifier: Specify a language identifier.

LVLCHK
Specifies whether the record format level identifiers in the program are checked against those in the logical file when the file is opened. If so, the record format identifiers in the program must match those in the logical file. This value can be overridden by the Override with Database File (OVRDBF) command at run time.

*YES: The level identifiers of the record formats are checked when the file is opened. If the level identifiers do not match, an error message is sent to the program requesting the open, and the file is not opened.

*NO: The level identifiers are not checked when the file is opened.

AUT
Specifies the authority given to users who do not have specific authority to the logical file, who are not on an authorization list, and whose user group has no specific authority to the logical file. More information on this parameter is in Commonly used parameters.

*LIBCRTAUT: The public authority for the logical file is taken from the value on the CRTAUT parameter of the target library (the library that is to contain the logical file). The public authority is determined when the logical file is created. If the CRTAUT value for the library changes after the logical file is created, the new value does not affect any existing objects.

*CHANGE: The user can perform all operations on the logical file except those limited to the owner or controlled by object existence authority and object management authority. The user can change and perform basic functions on the logical file. Change authority provides object operational authority and all data authority.

*ALL: The user can perform all operations except those limited to the owner or controlled by authorization list management authority. The user can control the object's existence, specify the security for the object, change the object, and perform basic functions on the object. The user also can change ownership of the logical file.

*USE: The user can perform basic operations on the logical file, such as running a program or reading a file. The user cannot change the logical file. *USE authority provides object operational authority, read authority, and execute authority.

*EXCLUDE: The user cannot access the logical file.

authorization-list-name: Specify the name of the authorization list used.

TEXT
Specifies the text that briefly describes the logical file. More information on this parameter is in Commonly used parameters.

*SRCMBRTXT: The text is taken from the source file member being used to create the logical file. If the source file is a database file, the text is taken from the source member. Text can be added or changed for a database source member by using the Source Entry Utility, or by using either the Add Logical File Member (ADDLFM) or Change Logical File Member (CHGLFM) command. If the source file is an inline file or a device file, the text is blank.

*BLANK: Text is not specified.

'description': Specify no more than 50 characters of text, enclosed in apostrophes.

Examples for CRTLF

Example 1: Creating a Logical File Without Members 

CRTLF   FILE(INVEN/STOCKCTL)  SRCFILE(SRCLIB/STKLFSRC)
  MBR(*NONE)

This command creates a logical file named STOCKCTL, in the INVEN library. The source descriptions in the source file STKLFSRC in the SRCLIB library are used to create the logical file. The file is created without any members (*NONE was specified), and only one member can be added later (because one member is the default for the MAXMBRS parameters). The logical file accesses the data contained in the physical files specified in the DDS source file used to create this logical file. For successful completion of the CRTLF command, the user must have object operational authority for all the physical files specified in the DDS. If the logical file is keyed, object management authority is also required.

Example 2: Creating a Logical File With Members 

CRTLF   FILE(PAYLIB/PAYCODESEQ)
  SRCFILE(PAYLIB/PAYTXSRC)
  DTAMBRS(PAYTRANS FIRSTQTR)  AUT(*EXCLUDE)
  TEXT('Pay taxes in code sequence')

This command creates a logical file and logical file member, both named PAYCODESEQ in the PAYLIB library. The file and its member are created from the PAYTXSRC source file that is in the same library. The logical file member accesses the data contained in the FIRSTQTR member of the physical file PAYTRANS. The logical file is secured for the private use of the owner. The owner must have object operational authority for the PAYTRANS file to create the member. If the logical file is keyed, object management authority is also required.

Additional Considerations

This section supplies additional information for coding the DTAMBRS parameter when physical file names and member names are specified.

More information about data members is in the Database Programming topic in the Information Center.

Error messages for CRTLF

*ESCAPE Messages

CPF3204
Cannot find object needed for file &1 in &2.
CPF323C
QRECOVERY library could not be allocated.
CPF5702
File either not DDM file or not found.
CPF7302
File &1 not created in library &2.