A Look at Three Distributed File Systems for OS/390 Users

DFSMS

Table of Contents

Introduction
Preliminary concepts
Capabilities
Access to MVS data
Access to other systems' from OS/390
Transparent access
Data availability and robustness
Security features
Other considerations
Summary
Appendix A
Appendix B
Tables

Introduction

If you use an IBM OS/390T system interlinked with other types of systems, do you ever want to access data from one system and use it on another? This white paper describes three IBM products that might help you when one of the systems is an OS/390 system and the data resides in files. These products, which provide various types of distributed file systems, are:

• The OS/390 Distributed File Service (DFS)
• The DFSMS/MVS Distributed File Manager (DFM), a part of the DFSMSdfp functional component
• The OS/390 Network File System (NFS), formerly known as DFSMS/MVS NFS

In this discussion, we'll refer to these products as DFS, DFM, and NFS, respectively. We'll also use the generic term "product" for each of these file systems, although they are actually components of a larger product set.

If you read about these products to any extent, you'll discover that they all provide the ability to access files from one system where the files themselves reside on another system. You might have also heard that each of these distributed file systems provides access in a transparent manner. If they all provide these capabilities, what's the difference between them? Why would you chose one product over another? And does transparent access mean the same thing for all of these distributed file products?

We'll address these and other questions throughout this white paper to help give you a starting point for considering DFM, NFS, and DFS for your particular situation. This paper assumes a certain familiarity with OS/390 (MVS) files, or data sets. The distributed world is described with more care, since this might be a less familiar area. The ultimate goal of this paper is to help you understand where one or more of the NFS, DFS, and DFM distributed file systems best fits into your enterprise.

Let's start with why you would want to consider a distributed file system at all. You no doubt want to do some of the following:

• Keep your critical data on an OS/390 system to take advantage of the availability, security, and backup strengths inherent in OS/390 software and ESA/390 hardware.
• Access MVS data sets--in their conventional format--from other systems. (Other systems could be a heterogeneous combination of S/390, AS/400, RISC-based, and Intel-based systems.)
• Access other MVS files--where the data is organized to look like open systems files--from other systems. (Here open systems means Intel- and/or RISC-based systems with operating systems that include Windows, AIX, Sun Solaris, HP-UX, OS/2, and others.)
• Access data residing on other systems from OS/390.
• Provide consistent data access from the requestor's standpoint, no matter what type of system (OS/390, RISC, PC) contains the data.
• Protect access to your data so that requests coming across the network are checked out before permission is given to read or modify the data.

There are other things that might be high on your criteria list for deciding about appropriate distributed software, including:

• How easily you can learn to use the software
• How easily you can set up the software the first time (installation and customization)
• How easily you can modify and monitor the software (and its hooks to user data) over time

Understanding some preliminary concepts

The client/server model
NFS, DFS, and DFM are all client/server software packages, meaning:

• The software is logically built in two pieces: the client and server, which know how to communicate with each other (according to some predefined way). The programs typically are run on two different systems and communicate over a network. (There's no absolute requirement that these programs reside in different machines, but for this discussion, we'll assume the client is in a different machine from the server machine.)
• The client originates "requests" on behalf of an end user or an application program and sends these requests to its server partner.
• The server fulfills requests from its partner clients. Depending on the rules (the protocol) used for communicating with the clients, the server might tell the client a little or a lot about how successful it is in responding to the request.

Rules set by each distributed protocol

One of the characteristics that stands out between NFS, DFS, and DFM is that they each adhere to different distributed protocols. In other words, the rules through which the client and server communicate are different.

The good news is that each protocol is a set of public, industry- wide rules for sharing and accessing data between systems. The NFS, DFS, and DFM products are said to "implement" the SUN NFS protocol, the OSF DFS/DCE protocol, and the IBM Distributed Data Management (DDM) architecture, respectively. Some vital statistics about these protocols are listed in Table 1 on page 3.

Why should this protocol information matter to you? Each protocol is designed around certain concepts that set out to achieve certain goals. These protocols can make tradeoffs to achieve one goal to a greater extent than other goals. If you have a goal to improve your computing enterprise that relates closely to the themes of one of these protocols, this might help you choose software that best matches your needs.

Take a look at Table 2 on page 4. The behavior of the specific product that implements each protocol will be explained later.

Other required software

These distributed file systems all need the help of other software to do their jobs. For instance, both NFS and DFS need the OS/390 TCP/IP product or equivalent. TCP/IP products are networking software that are used pervasively today for systems tied into the Internet or an intranet. The chances are good that TCP/IP is already part of your enterprise (and your organization's knowledge base).

DFM uses the SNA Advanced Program-to-Program Communication (APPC) protocol for its network communications. Thus, it needs communications software that provides APPC protocols between systems, such as APPC/MVS (part of MVS) and VTAM. These are part of OS/390's base elements.

There is one subtlety to keep in mind: until OS/390 Version 2.6 is available, NFS requires the UDP protocol within the OS/390 TCP/IP product (or equivalent) to be installed. In OS/390 Version 2.6, NFS can use either TCP or UDP for its network communications. This can be confusing, because the OS/390 TCP/IP product handles both transport protocols.

DFS uses the UDP protocol. (Appendix A provides additional details about the SNA, TCP, and UDP protocols.)

DFS has one other major dependency. It requires DCE software to be installed. In particular, OS/390 DFS requires the OS/390 OpenEdition DCE Base Services to be installed first (for the current version of OS/390 DFS). This too is a client/server software package in the OS/390 base elements. DFS is an application of DCE--it talks to DCE and asks it to perform services to achieve the capabilities that DFS provides to the outside world. Later on, we'll take a brief look into the world of DCE services, as viewed by DFS.

Supported platforms

Both NFS and DFS are available on a large number of platforms. DFM has a more limited set of platforms. This is summarized in Table 3 on page 5, from the perspective of each server residing on OS/390. Note that both NFS and DFS have clients on OS/390 (which can communicate with servers on other systems), whereas DFM does not.

Note also that both DFS and NFS clients have line commands that are the main interface for the external user or application called the client. The DFM client, on the other hand, is composed of a collection of run-time APIs that you can access directly in a C program or through COBOL or PL/I programs with IBM software.

Next, we'll examine how the three distributed file systems fit into the various objectives mentioned in the introduction.

Understanding the capabilities of the products

Accessing conventional MVS data sets

What is meant by "conventional" MVS data sets? These are the types of data sets MVS users have allocated for years: partitioned, sequential, direct access, and/or VSAM data sets.

Accessing this type of data brings to light an immediate difference among the three distributed file systems. All three file systems can access (in a certain manner) many of these data set types. But the exact manner of access differs in a major way for DFM, compared to NFS and DFS.

The types of data sets each distributed file system can access is summarized in Table 4 on page 6. Note that both NFS and DFS can access the same types of conventional MVS data sets. (The server part of DFM, NFS, and DFS provides this access.)

If you have used conventional MVS data sets, you know that "the system" accesses the contents of a data set in units of records. Sequential data sets have a strict ordering between the records. Each record in a keyed data set can be accessed by its key name. The conceptual model here is that a data set is organized as a collection of records. An MVS access method helps you read and write these records in a predefined way: by key, by sequential order-of-creation, and so on.

The big difference between DFM and the other two file systems is that DFM gives you "record access" to MVS conventional data sets like you are accustomed to. The DFM server understands DDM file models and how to translate these models into equivalent record-oriented MVS access method requests.

DFS and NFS, in contrast, access these MVS conventional data sets in a byte stream manner. NFS and DFS see the data as one long stream of bytes, just like open systems (such as AIX, Windows, and OS/2) see the data. With this "stream view" of a file, reading and writing are done by using a byte offset (from the beginning of the file) and a byte length. Both NFS and DFS servers on OS/390 convert byte stream operations, requested from a remote system by their partner clients, into standard access methods operation on OS/390.

To accomplish this task, the DFS or NFS server has to determine which record in an MVS file contains the offset in the client's read or write request. To do this, the server reads--mapping byte offsets to records--from the last known location in the file until the record containing the requested byte offset is located. The server then reads (or writes) more records, if necessary, to find enough bytes to satisfy the request.

Note that the idea of "keys" for each record is not detectable with stream access. DFS and NFS do not support keyed access to conventional MVS files (VSAM KSDSs), but DFM does. Also, relative record access is available only with DFM.

What if you want to create a new file remotely by using one of these distributed methods? You can do this for many types of conventional MVS files with any of the three file systems.

The MVS data set access and creation capabilities of DFS, NFS, and DFM are summarized in Table 4. There are a few intricacies beyond what is discussed here: things like the REUSE attribute of VSAM files might have to be set on or off, depending on what you're trying to do. The finer points of stream access and how it affects file size, time-stamps, and text/binary transmissions are covered in the respective product documentation (see Appendix A).

Data set sharing

Both NFS and DFM work closely with MVS access methods to achieve a high degree of data sharing consistent with using local MVS files. NFS allocates VSAM and PDSE data sets with a share option, enabling the MVS access functions to manage data sharing. PDSs are allocated to give MVS users write integrity if they have allocated the PDS as exclusive. Otherwise, the PDS is allocated as "share" and a PDS member is serialized for write operations. If a sequential data set is opened for output, it is allocated exclusively.

DFM enables the DFM client to declare its level of record sharing. The DFM server propagates this to the MVS access methods.

DFS serialization mechanisms are very different. Refer to the latest product specifications for more information.

Access to MVS data that is organized like open systems data

Both NFS and DFS enable remote users to access data in the Unix System Services (formerly OpenEdition) Hierarchical File System (HFS). The HFS file system is much like a Unix file system in the sense that each HFS file resides in a directory, which in turn is a file in a higher level directory. Both NFS and DFS can access files in an HFS file system located on an OS/390 system as if the files were on a directory in AIX, HP-UX, Sun Solaris, or another Unix system. Specifically, the names of the files follow the same conventions as Unix. Both NFS and DFS recognize the same kind of permission bits that are defined for Unix-style files. The hierarchical directory structure to get to a file (its pathname) is likewise similar.

The HFS files are accessed as stream-oriented files by NFS and DFS. This is the same type of access a Unix system performs for its local files. Why is this important? Access to HFS files enables Unix applications to access data on MVS in an hierarchical manner similar to the way the application would access a file local to a Unix system. With either distributed file system, the application can perform reads and writes on the data as if the data were stored locally. At the same time, the data can be managed by using the large system strengths of MVS storage management and the high-performance disk storage of the OS/390 high-end server environment.

DFM (the DFM server on OS/390), on the other hand, does not support HFS files.

DFS and its local file system

DFS offers a third capability for creating and storing files on OS/390 by using the DCE Local File System (LFS). This is a high-performance, log- based file system managed by DFS in conjunction with the services of DCE. Once a program creates a file in this file system, DFS can control it, replicate it, move it, back it up, and generally oversee its life in the DCE world.

Note that the DFS/DCE administrator controls where such a newly created file is stored: on an OS/390 system or on another system in the DFS/DCE environment.

Access to other systems' data from OS/390

This section takes us in the reverse direction from what we've been discussing so far. What is the capability of these distributed file systems to support an OS/390 application that wants to access a file on another system? In other words, does NFS, DFS, or DFM allow the OS/390 application to read and write to a remote file in the same way that it does for a local file?

The answer again begins with DFM versus NFS and DFS. There is currently no support to do this with DFM. What would be needed is a DFM client that runs on OS/390 to intercept the application's read/write request and restructure these requests into requests that a DFM server on another system could understand. There is no such DFM client.

Access to remote files for OS/390 applications

The OS/390 NFS client provides access for Unix System Services (HFS) applications that need to read and write remote files. The NFS client also provides remote file access for OS/390 (batch) applications that use BSAM, QSAM, and VSAM ESDS access methods (with some restrictions). The JCL PATH parameter is crucial for BSAM and QSAM applications to indicate that a remote file is being referenced. The NFS client operates behind the scenes as a physical file system within Unix System Services to pick up this reference and access the right file.

The OS/390 DFS client provides similar access for Unix System Services applications, positioning itself behind the scenes just like NFS does. DFS considers an HFS file hierarchy to be a non-local file set and requires the DFS EXPORT command to have been issued to link the remote file set into DCE's global namespace. If the Unix System Services application on OS/390 also has the proper DCE-level access to these remote files, it can then access the data through its DFS client. (Users unknown to DCE can access only data that is "authorized" to unauthorized users.)

DFS and extended remote file access

DFS goes further than NFS regarding access to remote data from the OS/390 system. If an application runs on OS/390 and knows how to specify files in the manner DFS recognizes, the DFS client on the OS/390 system can search for the file anywhere in the DFS file system. If the DCE authorization mechanisms have been set up to allow access to this file, and the user running the OS/390 application is also allowed access to the file, DFS responds to the read/write request. In short, a DFS client can access data anywhere in its DCE/DFS complex in the same way as long as the DCE protection mechanisms are set up to allow this access. Any program (for instance, an editor) that can be put under the umbrella of DCE and DFS can take advantage of this capability.

This brings up a fundamental fact about DFS: it is oriented towards having data in its own world of a DCE Logical File System (LFS). The DCE LFS is separate and distinct from conventional MVS data sets and is distinct from the standard Unix System Services HFS file system (one that is created outside the control of DCE/DFS). Applications that run as Unix System Services applications can access data in an LFS through the DFS client. Then the DFS file system assumes full management of that data. For data in an LFS, the DFS software calls upon the services of DCE to provide its own brand of security, backup, and availability where overall directives are established by the DCE/DFS administrator.

Transparent access: remote or local files

Now let's consider what is meant by transparent access from the perspective of these distributed file systems. For all three systems, one definition of transparency is held in common: once an application starts running on a system and accessing a remote file, all three systems can step in and provide the remote data for read and write request without any changes to the application itself. This is within the constraints of the types of files or data sets and the types of access discussed previously. Thus, all three file systems provide transparent file access at the read/write level.

DFS goes even further in the world of transparency by using the capabilities of DCE to provide transparent end-user access to files. Whenever a user names a file in the DFS system, the name of the system on which the file resides is not required. DFS figures this out for the end user based on earlier setup work done by a DFS system administrator. This is a very attractive capability in an enterprise where large numbers of systems are interlinked. The administrator of a DFS system can add systems to the network and move sets of files from one system to another without requiring end users to modify how they interact with their files.

DFM and NFS, in contrast, both require that the network identifier for the system where a file is located be encoded when the file is initially opened. NFS requires this in its MOUNT command, and DFM requires this in its DDMOpen API. Somebody who knows about that application (possibly an application owner if not an end user) has to change this network identifier if the file is moved to another system. This can cause a rare, low-impact event for some installations or a major headache for others.

So far, we've seen differences between NFS and DFS in how they access files. There are other differences. Two more topics where these systems differ significantly are data availability and security.

Data availability and robustness: caching

NFS provides in-memory caching of data on the NFS server. This saves time on the server for accessing frequently used files. Both DFS and NFS provide caching by their clients. NFS clients can cache in memory, and DFS clients can do both in-memory and disk caching. Thus, users accessing a file on a very frequent basis will have a greater likelihood of having the data they need right in the client machine, creating a faster response for data access requests. DFS caching has more room to cache data by using disk space on the client system.

The NFS client caching system has a user-controlled time lag associated with cached data, typically set to a few seconds. This means that, for a file open in read/write mode, a client application has the potential of reading less than up-to-the-minute information. Or, multiple clients can be looking at slightly different levels of a file if they're all caching the same file at the same time. However, the time lag can be set very small, or caching can be turned off by NFS client applications for situations where data must be guaranteed to be current.

DFS is more sophisticated in its detection of out-of-date data in its cache. The DFS server tracks when a centrally stored copy of a file changes. The DFS client detects this change for a cached file and retrieves a new version of the file when an application next requests data from it. This mechanism enables you to keep the cache turned on, which reduces network traffic and load on the server compared to having the cache turned off. This in turn enables better scaling (more DFS clients) compared to NFS.

When a system or network connection goes down, NFS requires its servers to re-access the files it had cached in its server. The user also has to remount the file unless this file is automatically remounted by prior setup instructions to NFS. For data that has not been cached in the NFS client, access to the data is disrupted until the NFS server comes back up. So there's some likely disruption to the behavior of accessing files if you're using NFS and something bad happens on the network or a remote system.

DFS provides features to mitigate the impact of such events. For instance, DFS provides a replication feature for LFS files, so that copies of files can be created (and updates to them can be propagated automatically) on several systems connected by a network. If one system or network connection has a problem, DFS can access a copy of the file on another system. The data continues to be available to DFS client systems, even if one copy of the data is not accessible.

The DFM clients do not currently have a caching facility. The DFM server can perform caching for stream processing (for OS/2 DFM clients).

Security features

No distributed system can be complete without considering its security features. Here is an initial look at the security features of these three file systems along with some exploration into the underlying dependent software they are built on. We will look at this topic from the perspective of the servers for each file system, since this is the side of the client/server software that responds to requests.

First, let's consider the DFM server on an OS/390 system. You can establish access security for the DFM server so that only authorized users and applications on DFM client systems can remotely access the DFM server. Using the options available through your SNA-based networking software and RACF (or an equivalent product), you can protect access to the DFM server by:

• Limiting which Logical Units (LUs) can enter your OS/390 system, where each LU is associated with a particular workstation or other system in your SNA network.
• Ensuring that requests coming from DFM clients contain security information such as user IDs and passwords.
• Limiting by user ID or group who can access the DFM server.
• Limiting the number of administrators who can define and update the APPC profile for the DFM server.

Now let's consider the NFS server. On OS/390, the NFS server performs two security checks before it effectively unlocks the door to its data. When an NFS client initially requests a mount to a directory (which can be one or more of the high-level qualifiers of a conventional MVS data set), that client (another system) is scrutinized. The NFS server looks in its export file- set up earlier by an administrator-to confirm that this remote system (the NFS client) is authorized to access the particular MVS directory.

The second security check occurs when a user on the remote system asks to access an MVS file. The NFS server then requires the remote user to use an MVSLOGIN command to authenticate himself to the OS/390 system. NFS uses the SAF facility (RACF or equivalent product) to confirm that the user is authorized for access to this file. If you are familiar with RACF, this means the same level of checking is performed on the data set as if the user were accessing the file locally through RACF. One caveat is that the MVSLOGIN command is unencrypted (the user ID and password are "garbled" instead).

NFS offers options for less secure modes of operation, reducing administrative support of NFS for network complexes where security over the net is not a major concern.

With OS/390 Version 2 Release 6, NFS clients have a new access procedure to query the OS/390 NFS server if a remote application has authority to access a conventional MVS data set. The NFS server asks the SAF facility if the remote application (user) has the proper authority. (This access procedure is available only for NFS clients and servers using Version 3 of the NFS protocol. It closes a gap in NFS client security support for caching conventional MVS data.)

Now let's look at the DFS server. It uses the facilities of the underlying DCE security service to perform its style of security checking. DFS maintains security through login mechanisms (optionally encrypted) and access control lists on files and directories. The access control lists--or ACLs- -are set up by a DCE administrator. ACLs enable the administrator to specify the operations different users and groups can perform on files and directories in DFS. This authorization distinguishes between permission to read information versus change information.

The login is actually handled by the DCE software. This means that each user of a DFS system has to be set up to be authenticated to DCE. The security check can occur when the user enters dce_login on the DFS client system. Alternatively, many systems (for instance, OS/390 and AIX) provide for single sign-on capability where the user logs in once to the main system and this login automatically carries over to DCE. The DFS client caching operations also use DCE security services to ensure that data access is controlled.

Both APPC/MVS and OS/390 DCE can interface to optional encryption components. For DCE, look at the DCE User Data Privacy optional feature of OS/390 Version 2 Release 4. For APPC/MVS, one product available for encryption on MVS systems is the Integrated Cryptographic Service Facility/MVS (ICSF/MVS). A compatible cryptographic product would also have to be available on your non- MVS systems in the SNA network.

Other considerations

DCE and DFS planning and deployment

In several places, we have mentioned that DFS requires DCE. DCE requires that a network complex--and users of the complex--be organized and defined to DCE software. This in turn requires an enterprise to invest in learning about DCE and planning how to logically group its systems and users into the DCE structure. This can be worth the effort to embrace the advantages of the DFS system offers (for large numbers of machines). But it is not an overnight or over-the-weekend task. The learning and planning typically take an investment in personnel and cooperation of groups to use DCE across a complex.

Part of the planning will probably include looking at the applications you want to run in the DCE environment. If they assume the path names for files, for instance, have a predefined format that conflicts with the DFS naming conventions, these path names would either have to be changed, or symbolic links would have to be provided for the equivalent DCE path names. You might have to build a test and/or migration plan for your more complex applications.

DFS, however, offers many advantages when you're considering managing data for a large number of machines. The investment in learning, planning, and set up time might readily be offset by streamlined administration of data after the data is put in the DCE structure. For an enterprise that expects to see continual growth in the number of systems accessing data across a network complex, DFS has many features to help with scalability.

NFS, in contrast

With NFS, less effort is required to learn about the product and set it up on OS/390 (the server and client). Users continue to need to know about where their files or data sets are located (which system). However, users also keep control of locating their data. This might be the distributed file system of choice when the number of systems is small and it makes sense to have user groups participate in knowing where their data is located.

DFM packaging

The DFM approach to handling distributed files has been implemented for COBOL and PL/I applications that run on the AIX, Windows, and OS/2 platforms. These IBM software products use the DFM client to access conventional MVS data sets. The DFM client APIs for these workstations are currently packaged with either the COBOL or PL/I VisualAge product.

As part of the package for OS/2, you also get some DFM agent modules, which enable OS/2 end users to submit MVS jobs from OS/2 workstations.

As part of the AIX and Windows packages, you get a more sophisticated data conversion component that allows for converting numeric data intermixed with character (text) data in your files. Note that data conversion has its own world of special concepts, terms, and functions, and is too complex to discuss in this introductory paper. Be assured that data conversion between unlike systems for an all-text file can be done by all three distributed file products.

Summary

Hopefully, you now have more insight into the three ways you can handle distributed files in an OS/390 setting. It might be apparent that DFS is a very robust direction to go, providing complete transparency for the end user to access distributed files and enabling a scalable solution at the potential cost of more learning, planning, and deployment time on the administrative side. NFS is simpler to learn and set up and might fit very well in environments with comparatively few interlinked systems. DFM is aimed at supporting various file models that might suit particular applications in your distributed environment.

Appendix A contains Web sites and IBM online information along with pointers to hardcopy books for further reference. Keep in mind that the technology and products will continue to evolve. If you face a close call among these products, check for up-to-date announcements about what they offer because they continue to evolve with new customer requirements and new technologies.

Appendix A: Where to go for more information

IBM Online OS/390 bookshelf

To access OS/390 books on the Internet, visit:
www.s390.ibm.com/os390. Select "Library," then the OS/390 release. Some of the book titles and their order numbers that you might find useful are categorized below.

For OS/390 NFS (OS/390 Version 2 Release 6)

• OS/390 NFS Customization and Operation (SC26-7253)
• OS/390 NFS User's Guide (SC26-7254)
• OS/390 NFS Performance Tuning Guide (SC26-7255)

For OS/390 (releases prior to OS/390 Version 2 Release 6)

• OS/390 NFS Customization and Operation (SC26-7029)
• OS/390 NFS User's Guide (SC26-7028)

OS/390 application access to remote files

The following book's section "Accessing HFS Files Via BSAM and QSAM" addresses how OS/390 applications can access remote files (specifically HFS files):

• DFSMS/MVS: Using Data Sets (SC26-4922)

In addition, if you have access to RETAIN, a focused discussion about BSAM and QSAM remote file access is available in Information APAR II09184.

DFM

• DFSMS/MVS DFM/MVS Guide and Reference (SC26-4915)

DFS and DCE

• OS/390 DFS Configuring and Getting Started (SC28-1722)
• OS/390 DCE Introduction (CG28-1581)
• OS/390 DCE Planning (SC28-1582)

TCP/IP and VTAM

• TCP/IP for MVS: User's Guide (SC31-7136)
• TCP/IP for MVS: Planning and Migration Guide (SC31-7189)
• VTAM AnyNet SNA Over TCP/IP (SC31-8376)
• VTAM Release Guide (GC31-6545)

APPC/MVS

• OS/390 MVS Planning: APPC/MVS (GC28-1807)

Information from other sources

DFS and DCE

For OS/390 DFS, visit: www.raleigh.ibm.com/dce/dceoedfs.html or visit the Transarc Corporation Web site at www.transarc.com. Select "products," then "DFS."

For additional DCE information, visit the Open Group Web site at: www.camb.opengroup.org/dce/.

DFM clients

The DFM client software has the following user's guides available (to order, call 800-879-2755):

• SMARTData UTILITIES for Windows Distributed FileManager User's Guide (SC26- 7134)
• SMARTData UTILITIES VSAM Application Programming Interface Reference (SC26- 7133)
• SMARTData UTILITIES for OS/2 VSAM in a Distributed Environment (SC26-7063)
• SMARTData UTILITIES for AIX VSAM in a Distributed Environment (SC26-7064)

NFS and DFM

For information about NFS and DFM (DFSMS), visit: www.storage.ibm.com/software. Select "DFSMS Network File System." Or select "DFSMS," then "Product Information" or "White Papers."

Appendix B: Transport protocol terms and features

Tables

* DFM stream is currently available on OS/2 only (through the SMARTData Utilities DFM client)

(c) International Business Machines Corporation 1998

Printed in the United States of America
6-98
All rights reserved

IBM hardware products are manufactured from new parts, or new and used parts. In some cases, the hardware product may not be new and may have been previously installed. Regardless, IBM warranty terms apply.

Publication Number G522-2436-00