Stepped out of the office for a little bit, new surroundings. Let's take this opportunity for a bit of a recap. zFS is a physical file system like HFS. It's not an HFS replacement, it's complimentary. However, note that HFS has been functionally stabilized since z/OS version 1.6 and new enhancements are only brought in the context of zFS. A zFS aggregate is a dataset that contains the zFS file system. The aggregate is a VSAM linear dataset or VSAM LDS, and is a container that contain one or more zFS file systems. The name of the aggregate is the same as the VSAM LDS name. A zFS aggregate that contains only a single zFS file system can be defined and is called a compatibility mode aggregate. Compatibility mode aggregates are more like HFS. Aggregates, that contain multiple file systems are called multi file system aggregates, and this type of aggregate is no longer supported. You can choose whether each file system is to be an HFS or a zFS on the dataset attributes panel or with the change of DSN type command. The root file system can also be a zFS. VSAM and zFSs are not quite as easy to work with as HFS is. For example, you can't uncatalog them and renaming them is a bit more difficult. Although the HFS dataset does not have to be SMS managed, it is still highly recommended. Multi-volume HFS datasets are only supported as SMS managed. That is, you cannot have multi-volume Non SMS managed data sets. Finally, you do not need to migrate all of your file systems to zFS all at once. HFS and zFS can coexist and you can migrate some or all at your own pace. Previously, you could only migrate mounted HFS file systems to zFS. Now with z/OS 2.1, you can use the BPX WMIG F command to migrate mounted HFS file systems to zFS. If you expect a file system to grow larger than four gigabytes and it's not SMS managed with extended addressability, you'll need to copy it to an SMS managed zFS dataset with a data class that includes extended addressability. If a zFS aggregate is to be larger than four gigabytes, it must be SMS managed with a data class that includes extended addressability. However there can be Non SMS managed VSAM linear datasets that are larger than four gigabytes with the extended addressability feature. Hierarchical file system datasets have partitioned organization, have the same structure as the PDSE and might or might not be SMS managed. To create an HFS dataset, specify the usual DD statement parameters which are necessary to create any COS dataset. One way of using a file in the hierarchical file system is to refer to it by JCL. The following changes have been made to support hierarchical files. First off, DSN type equals HFS or PIPE, specify HFS to create a hierarchical file system dataset or PIPE to specify a name to PIPE. PATH identifies a file in the hierarchical file system. The JCL support allows a path name to be up to 255 characters long, including the slashes. If the path name contains lowercase letters, the name must be enclosed by single quotes. Path specifies the disposition of a hierarchical file after normal or abnormal, and it can be keep or delete. PATHMODE specifies the file access attributes when the file specified in the path parameter is created. The file access attributes define who has access to read, write, or execute the file. PATHOPTS specifies the access and status for a file. There are two file option groups, the access group and the status group. Now, this shows an example of how to allocate an HFS dataset for the root file system, the important JCL keyword here is DSN type equals HFS. Note that an HFS can be either SMS or Non SMS managed, but must be cataloged furthermore to succeed. An alternative to using JCL would be to use the TSO allocate command. The IOEAGFMT utility is used to format an existing VSAM LDS as a zFS aggregate. All zFS aggregates must be formatted before use, including HMS compatibility mode aggregates. IOEAGFMT does not require the zFS physical file system to be active on the system. Here is an example of a job to create and format a compatibility mode aggregate. It's a two-step job, the first step creates the aggregate and the second step formats it. Since it's a compatibility mode, aggregate, the second step also creates a file system with the same name as the VSAM LDS plus the entry name. Since the quota to the size of the aggregate. Just briefly, z/OS 2.1 supports a new directory format v5, using an extensible hashing system. You can optionally migrate to a new version 1.5 file system. There are multiple means to convert to a new file system. There are new parameters and commands in support of zFS extended directories. A v5 Directory can only exist in a v1.5 aggregate. Version 1.5 aggregates support extended v5 directories. Extended v5 directories can support larger directories, store names more efficiently than v4 directories and reclaim space when names are removed. A v5 directory cannot be created unless the file system is v5. A file system can only be converted to v5 or created as v5 by using either the IOEFSUTL convert format or zFS ADM convert. This JCL example shows a program in a z/OS dataset being re-linked to reside in the hierarchical file system. PATH defines the path name of the directory where the program payroll resides when a link edited. The pathname is in lowercase letters, and therefore enclosed by single quotes. We have some path option, options, OWR only specifies the file will be opened far right, OCREATE specifies that if the file doesn't exist, it's created, and if it's existing, it is reused. OTRUNC specifies that the file length will be truncated to zero if the file already exists. For Path Mode, SIRWXU specifies that the file owner has read, write, and execute permission. SIRWXG specifies that the file group has read, write, and execute permission, and SIRWXO specifies that all other users have read, write, and execute permission. Next, we're going to talk about how to get some stuff done in your Unix environment using the ice shell and directory list utility.
