Network File System, NFS is the strategic file-sharing protocol for the z/OS platform. The DFSMS/MVS server or an NFSS feature implements the NFS protocols. NFSS enables the host processor to act as a file server to authorize NFS clients and a TCP/IP network. NFSS allows remote access to data on the z/OS host from workstations, personal computers, or any system in the network that is using NFS client software. A client system can be Windows or any Unix or Linux system with the NFS client software and z/OS. The NFS Server allows access to z/OS datasets and HFS files on the z/OS host as if they were local files on the client system. Workstation user can access the z/OS file system by using the MVS login command to log into the z/OS. A z/OS user ID password and authorization to access requested fast as needed. The mount command is used to create a temporary link between specific z/OS datasets and an empty Unix directory or a dummy PC drive. A z/OS high-level qualifier is used in the mount command to specify which z/OS datasets to mount at a mount point. The z/OS datasets beginning with the specified high-level qualifier appear as files under the mount point. If the specified datasets include partitioned datasets, a second level of hierarchy is shown. The NFSS support for z/OS Unix provides transparent access to HFS file system mounted by an NFS client. The NFS client user is not restricted to the z/OS naming conventions by HFS data access. Path names and filenames can contain special characters and can be mixed case, just go wild. An NFS client user can mount a part of the z/OS Unix HFS on their local file system and thereafter create, delete, rewrite, and otherwise treat that part of the z/OS Unix file system as an extension to their local workstation file system. Let's transition into file security. In z/OS Unix, each user has a user ID, a UID, and the group ID, a GID. When a user creates a directory or a file, it's automatically associated with the user's GID, and the GID is set to the GID of the parent directory. A user's UID and GID can be defined in RACF or an equivalent security product. The system verifies that the user or a program has access to a file by comparing the UID and GID and RACF with the definitions in the hierarchical file system. There are three classes of users. There's owner, the user's UID must match the UID for the file. There's group, a member of any group whose GID matches the GID of the file and other which is anyone else? Access to files and directories is controlled by permission bits. Each file gets it's permission bits set when it's created. The permission bits can be changed by the chmod command. Those are, read notated by r, write notated by w, and execute notated by x. The diagram here shows a conceptual overview of how far security is controlled user with UID 103 and GID 42 wants to open file/user/lib/lib.a. The system checks with RACF if UID 103 and GID 42 are valid, and if they are valid, what authority they have to access the filelib.a. User GID 103 is not the owner of this file, but belongs to the same group the file is associated with. A group permission is rwx, which means this user will have read, write, and execute access to the file. Now as this chart shows, the permission bits have different meanings when related to files and directories. If you want to put a new file in a directory, you need both search and write access to the directory. The system needs to search the directory to determine if the entry is already there. As you create files and directories, default permission bits are defined. These differ depending on the method used to create the entity. The z/OS Unix file system can be accessed by using a bunch of methods. TSO/E has commands for browsing and editing HFS files, copying data between HFS files and z/OS datasets, mounting file systems and invoking the z/OS Unix shell. There's also a command with I shell, which provides an ISPF menu-driven interface to the file system. JCL provides keywords which support the specification of HFS path names. REXX has a set of z/OS Unix extensions, Cisco commands to access the z/OS Unix callable services. Z/OS Unix shell is the Unix interface to the file system. It contains commands and utilities to access HFS files. Z/OS Unix supports many C functions to access HFS files and finally, shell scripts which are similar to REXX execs where shell commands and utilities can be stored in a text file which can be executed. There are TSO/E commands which support the hierarchical files. For example, MKDIR creates a new directory and MKNOD create a character special file. OEDIT creates or edits the file using the ISPF editor and OBROWSE, browses a file using ISPF and ISHELL or ISH invokes the z/OS ISPF shell power interface. File copy between z/OS datasets and HFS files can be useful if you need to send them the C files between z/OS systems for DFSMS backup and restore of HFS files or to copy HFS files to tapes. OGET copies an HFS file into a z/OS sequential file or to a PDS/PDSE member. OCOPY conversion can also be specified. OGETX does the same thing for an HFS directory. OPUT copies the z/OS sequential file or a PDSE member into an HFS file and OPUTX copies all members of a PDS or PDSE into an HFS directory. OCOPY copies data in either direction between a z/OS dataset and an HFS file using DD names. The cp and mv Unix commands have support for z/OS datasets. To specify a z/OS dataset name, proceed the name with double forward slashes. To cp or mv to a PDS or a PDSE, the dataset must be allocated before the copy or move. The same is true for pax and tar or tar for creating portable archives or extracting files from the archive. Don't forget those double forward slashes for z/OS dataset names. Speaking of which, let's quickly recap the difference in file identification. In z/OS a dataset is identified by dataset name. If the dataset is a PDS or a PDSE, the file has a member name. Characteristics of that dataset are kept in catalogs or the VTOC, a volume table of contents. Executable modules can have multiple names for an alias. In the hierarchical file systems, files are identified by path names which consists of directory names and filename. Files can have multiple names created by symbolic links and hard links. There is no concept of a defined a record format or block size. But despite these differences, as you can see, there's some great support between z/OS datasets and z/OS Unix files. That wraps up the module. I said at the beginning, there was a lot to cover here, but this gives us a great grounding for the rest of the class.
