Create User-Defined FS (CRTUDFS)

The Create User-Defined File System (CRTUDFS) command creates a file system that can be made visible to the rest of the integrated file system name space through the Add Mounted File System (ADDMFS) or MOUNT command.

A UDFS is represented by the object type *BLKSF, or block special file.

Restrictions:

The user must have input/output (I/O) system configuration (*IOSYSCFG) special authority to use this command.
The audit (*AUDIT) special authority is required when specifying a value other than *SYSVAL on the Auditing value for objects (CRTOBJAUD) parameter.
The user must have all object (*ALLOBJ) and security administrator (*SECADM) special authorities to specify a value for the Scanning option for objects (CRTOBJSCAN) parameter other than *PARENT.
A maximum of approximately 4,000 user-defined file systems can be created on an independent auxiliary storage pool (ASP).

Parameters

Keyword	Description	Choices	Notes
UDFS	User-defined file system	Path name	Required, Positional 1
DTAAUT	Public authority for data	Name, INDIR, RWX, RW, RX, WX, R, W, X, EXCLUDE, NONE	Optional
OBJAUT	Public authority for object	Single values: INDIR, NONE, ALL Other values (up to 4 repetitions): OBJEXIST, OBJMGT, OBJALTER, *OBJREF	Optional
CRTOBJAUD	Auditing value for objects	SYSVAL, NONE, USRPRF, CHANGE, *ALL	Optional
CRTOBJSCAN	Scanning option for objects	PARENT, YES, NO, CHGONLY	Optional
RSTDRNMUNL	Restricted rename and unlink	NO, YES	Optional
CASE	Case sensitivity	MIXED, MONO	Optional
DFTFILEFMT	Default file format	TYPE1, TYPE2	Optional
TEXT	Text 'description'	Character value, *BLANK	Optional

Top

User-defined file system (UDFS)

Specifies the path name of the file system to be created. It must be in one of the following two forms:

/dev/qaspXX/udfsname.udfs, where XX is one of the valid system or basic user auxiliary storage pool (ASP) numbers on the system, and udfsname is the name of the user-defined file system. All other parts of the name must appear as in the example above.
/dev/aspname/udfsname.udfs, where aspname is one of the valid independent ASP names on the system, and udfsname is the name of the user-defined file system. All other parts of the name must appear as in the example above.

The name part of the path must be unique within the specified qaspXX or aspname directory.

This is a required parameter.

Public authority for data (DTAAUT)

Specifies the public data authority given to the user for the new user-defined file system (UDFS), or specifies that all authorities are inherited from the directory it is to be created in.

*INDIR: The authority for the UDFS to be created is determined by the directory it is to be created in. This means the new UDFS will inherit its primary group, authorization list, and its public, private and primary group authorities from the /dev/qaspXX or /dev/aspname directory. If the value *INDIR is specified for either the Public authority for object (OBJAUT) parameter or the DTAAUT parameter, then *INDIR must be specified for both parameters.
*RWX: The user can change the object and perform basic functions on the object except those limited to the owner or controlled by object existence (*OBJEXIST), object management (*OBJMGT), object alter (*OBJALTER) and object reference (*OBJREF) authority. Read, write, execute (*RWX) provides object operational (*OBJOPR) and all data authorities.
*RW: The user can view and change the contents of an object. Read, write (*RW) authority provides *OBJOPR and data read (*READ), add (*ADD), update (*UPD) and delete (*DLT) authorities.
*RX: The user can perform basic operations on the object, such as run a program or display the contents of a file. The user is prevented from changing the object. Read, execute (*RX) authority provides *OBJOPR and data *READ and *EXECUTE authorities.
*WX: The user can change the contents of an object and run a program or search a library or directory. Write, execute (*WX) authority provides *OBJOPR and data *READ, *UPD, *DLT, and *EXECUTE authorities.
*R: The user can view the contents of an object. Read (*R) authority provides *OBJOPR and data *READ authorities.
*W: The user can change the contents of an object. Write (*W) authority provides *OBJOPR and data *READ, *UPD, and *DLT authorities.
*X: The user can run a program or search a library or directory. Execute (*X) authority provides *OBJOPR and data *EXECUTE authorities.
*EXCLUDE: The user cannot access the object. The OBJAUT value must be *NONE, if this special value is used.
*NONE: The user is given no data authorities to the object. This value cannot be used with OBJAUT value of *NONE.
authorization-list-name: The format of the authorization list name remains the current ten-character format. The OBJAUT value must be *NONE, if this special value is used.

Public authority for object (OBJAUT)

Specifies the public object authority given to users for the user-defined file system, or specifies that all authorities are inherited from the directory it is to be created in.

*INDIR: The object authority for the UDFS to be created is determined by the directory it is to be created in. This means the new UDFS will inherit its primary group, authorization list, and its public, private and primary group authorities from the /dev/qaspXX or /dev/aspname directory. If the value *INDIR is specified for either the OBJAUT parameter or the Public authority for data (DTAAUT) parameter, then *INDIR must be specified for both parameters.
*NONE: None of the other object authorities (*OBJEXIST, *OBJMGT, *OBJALTER or *OBJREF) are given to the users. If *EXCLUDE or an authorization list is specified for the DTAAUT parameter, *NONE must be specified. This value cannot be used with the DTAAUT value of *NONE.
*ALL: All of the other object authorities (*OBJEXIST, *OBJMGT, *OBJALTER or *OBJREF) are given to the users.
The user can specify up to four of the following values:
*OBJEXIST: The user is given object existence (*OBJEXIST) authority to the object. The user can delete the object, free storage of the object, perform save and restore operations for the object, and transfer ownership of the object.
*OBJMGT: The user is given object management (*OBJMGT) authority to the object. With this authority the user can specify security for the object, move or rename the object and add members to database files.
*OBJALTER: The user is given object alter (*OBJALTER) authority to the object. The user is able to alter the attributes of the objects. On a database file, the user can add and remove triggers, add and remove referential and unique constraints, and change the attributes of the database file. With this authority on an SQL package, the user can change the attributes of the SQL package. Currently, this authority is used only for database files and SQL packages.
*OBJREF: The user is given object reference (*OBJREF) authority to objects. Used only for database files, the user can reference an object from another object such that operations on that object may be restricted by the other object. On a physical file, the user can add a referential constraint in which the physical file is the parent.

Auditing value for objects (CRTOBJAUD)

Specifies the auditing value of root directory objects created in this user-defined file system.

*SYSVAL: The object auditing value for the objects in the UDFS is determined by the Create object auditing (QCRTOBJAUD) system value.
*NONE: Using or changing this object does not cause an audit entry to be sent to the security journal.
*USRPRF: The user profile of the user accessing this object is used to determine if an audit record is sent for this access. The OBJAUD parameter of the Change User Auditing (CHGUSRAUD) command is used to turn on auditing for a specific user.
*CHANGE: All change accesses to this object by all users are logged.
*ALL: All change or read accesses to this object by all users are logged.

Scanning option for objects (CRTOBJSCAN)

Specifies whether the root directory objects created in the user-defined file system will be scanned when exit programs are registered with any of the integrated file system scan-related exit points.

The integrated file system scan-related exit points are:

QIBM_QP0L_SCAN_OPEN - Integrated File System Scan on Open Exit Program
QIBM_QP0L_SCAN_CLOSE - Integrated File System Scan on Close Exit Program

For details on these exit points, see the System API Reference information in the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter.

Even though this attribute can be set for user-defined file systems, only objects which are in *TYPE2 directories in that user-defined file system will actually be scanned, no matter what value is set for this attribute.

*PARENT: The create object scanning attribute value for this user-defined file system is copied from the create object scanning attribute value of the parent directory.
*YES: After an object is created in the user-defined file system, the object will be scanned according to the rules described in the scan-related exit programs if the object has been modified or if the scanning software has been updated since the last time the object was scanned.
*NO: After an object is created in the user-defined file system, the object will not be scanned by the scan-related exit programs.
Note: If the Scan file systems control (QSCANFSCTL) value *NOPOSTRST is not specified when an object with this attribute is restored, the object will be scanned at least once after the restore.
*CHGONLY: After an object is created in the user-defined file system, the object will be scanned according to the rules described in the scan-related exit programs only if the object has been modified since the last time the object was scanned. It will not be scanned if the scanning software has been updated. This attribute only takes effect if the Scan file systems control (QSCANFSCTL) system value has *USEOCOATR specified. Otherwise, it will be treated as if the attribute is *YES.
Note: If the Scan file systems control (QSCANFSCTL) value *NOPOSTRST is not specified when an object with this attribute is restored, the object will be scanned at least once after the restore.

Restricted rename and unlink (RSTDRNMUNL)

Specifies whether special restrictions apply for rename and unlink operations performed on objects within the root directory of the user-defined file system. This attribute is equivalent to the S_ISVTX mode bit for this directory.

*NO

No additional restrictions for renaming or unlinking objects from the root directory of the user-defined file system.

*YES

Objects within the root directory of the user-defined file system may be renamed or unlinked only if one or more of the following are true for the user performing the operation:

The user is the owner of the object.
The user is the owner of the directory.
The user has all object (*ALLOBJ) special authority.

Default file format (DFTFILEFMT)

Specifies the format of stream files (*STMF) created in this user-defined file system.

*TYPE2: A *TYPE2 *STMF has high performance file access and was new in Version 4 Release 4 of i5/OS. It has a minimum object size of 4096 bytes and a maximum object size of approximately 1 terabyte. A *TYPE2 stream file is capable of memory mapping as well as the ability to specify an attribute to optimize disk storage allocation.
*TYPE1: A *TYPE1 *STMF has the same format as *STMF objects created on releases prior to Version 4 Release 4 of i5/OS. It has a minimum size of 4096 bytes and a maximum object size of approximately 256 gigabytes.

Examples

Example 1: Create UDFS in System ASP

CRTUDFS   UDFS('/dev/QASP01/joe.udfs)  TEXT('Joe Smith')

This command creates a user-defined file system (UDFS) named joe.udfs in the system auxiliary storage pool (ASP 1).

Example 2: Create UDFS in ASP 3

CRTUDFS   UDFS('/dev/QASP03/harry.udfs')  CASE(*MIXED)

This command creates a case-sensitive user-defined file system (UDFS) named harry.udfs in user auxiliary storage pool (ASP) 3.