Instruction/ maintenance manual of the product AS/400e IBM
Go to page of 135
AS / 400e O S / 400 N e tw o r k F il e S y st e m S u p p o rt Ve r s i o n 4 SC41-5714-01 IBM.
.
AS / 400e O S / 400 N e tw o r k F il e S y st e m S u p p o rt Ve r s i o n 4 SC41-5714-01 IBM.
Note Before using this information and the product it supports, be sure to read the information in “Notices” on page 99. Second Edition (May 1999) This edition replaces SC41-5714-00. © Copyright International Business Machines Corporation 1997, 1999.
Contents Figures ........................... v i i T ables ........................... i x About OS/400 Network File System Support (SC41-5714) ....... x i Who should read this book .................... x i AS/400 Operations Navigator ................
Chapter 5. Client Mounting of File Systems ............. 3 9 What Is Mounting? ....................... 3 9 Why Should I Mount File Systems? ................. 4 1 What File Systems Can I Mount? .................. 4 2 Where Can I Mount File Systems? ...
Network Data Encryption .................... 8 2 User Authorities ........................ 8 3 User Identifications (UIDs) ................... 8 3 Group Identifications (GIDs) ................... 8 3 Mapping User Identifications .................. 8 4 Proper UID Mapping .
vi OS/400 Network File System Support V4R4.
Figures 1. AS/400 Operations Navigator Display .............. x i i 2. The local client and its view of the remote server before exporting data . . 1 3. The local client and its view of the remote server after exporting data . . 2 4. The local client mounts data from a remote server .
54. Using the End NFS Server (ENDNFSSVR) display ......... 7 1 55. Starting or stopping NFS server daemons. ............ 7 3 56. NFS Properties dialog box. .................. 7 3 57. Using the Release File System Locks (RLSIFSLCK) display ...... 7 6 58.
T ables 1. CL Commands Used in Network File System Applications ....... 9 1 © Copyright IBM Corp. 1997, 1999 ix.
x OS/400 Network File System Support V4R4.
About OS/400 Network File System Support (SC41-5714) The purpose of this book is to explain what the Network File System is, what it does, and how it works on AS/400. The book shows real-world examples of how you can use NFS to create a secure, useful integrated file system network.
This new interface has been designed to make you more productive and is the only user interface to new , advanced features of OS/400. Therefore, IBM recommends that you use AS/400 Operations Navigator , which has online help to guide you.
http://www.as400.ibm.com/infocenter http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm The AS/400 Information Center contains important topics such as logical partitioning, clustering, Java, TCP/IP , W eb serving, and secured networks.
xiv OS/400 Network File System Support V4R4.
Summary of Changes This manual includes changes made since V ersion 4 Release 1 of the OS/400 licensed program on the AS/400 system. This edition includes information that has been added to the system to support V ersion 4 Release 4. Changes made to this book include the following items: v Updated graphic files.
xvi OS/400 Network File System Support V4R4.
Chapter 1. What is the Network File System? Introduction OS/400 Network File System Support introduces a system function for AS/400 that aids users and administrators who work with network applications and file systems.
After the server exports information, the proper client (the client with the proper authorities) can be aware of the existence of file systems on the server . Furthermore, the client can mount the exported file systems or directories or objects from the server .
OS/400 Network File System Support is the replacement for the TCP/IP File Server Support/400 (FSS/400) system application. Users who are accustomed to working with FSS/400 will notice many similarities between FSS/400 and NFS. It is important to note, however , that FSS/400 and NFS are not compatible with each other .
users that all data exists and is processed on their local workstations. An efficient NFS network also gives the right people access to the right amount of data at the right times. Files and directories can be made available to clients by exporting from the server and mounting on clients through a pervasive NFS client/server relationship.
Each group of users works on sets of clients that need different file systems from the TULAB server . Each group of users has different permissions and authorities and will pose a challenge to establishing a safe, secure NFS namespace. Chris Admin will encounter common problems that administrators of NFS namespaces face every day .
6 OS/400 Network File System Support V4R4.
Chapter 2. The Network File System Client/Server Model T o understand how the Network File System works on AS/400, you must first understand the communication relationship between a server and various clients.
A daemon is a process that performs continuous or system-wide functions, such as network control. NFS uses many different types of daemons to complete user requests. A cache is a type of high-speed buffer storage that contains frequently accessed instructions and data.
Representation (XDR) and then sent to the server using a socket. The simple User Datagram Packet (UDP) protocol actually communicates between client and server . Some aspects of NFS use the T ransmission Control Protocol (TCP) as the base communication protocol.
NFS is similar to other RPC-based services in its use of server-side daemons to process incoming requests. NFS may also use multiple copies of some daemons to improve overall performance and eff iciency . RPC Binder Daemon (RPCD) This daemon is analogous to the port mapper daemon, which many implementations of NFS use in UNIX.
Network Status Monitor Daemon (NSMD) The Network Status Monitor (NSM) is a stateful NFS service that provides applications with information about the status of network hosts. The Network Lock Manager (NLM) daemon heavily uses the NSM to track hosts that have established locks as well as hosts that maintain such locks.
v Mount and Unmount commands . Users can mount and unmount a file system in the client namespace with these commands. These are general tools, used not only in NFS, but also to dynamically mount and unmount other local file systems.
Client-side caching in NFS reduces the number of RPC requests sent to the server . The NFS client can cache data, which can be read out of local memory instead of from a remote disk. The caching scheme available for use depends on the file system being accessed.
Data Cache The data cache is very similar to the directory and file attribute cache in that it stores frequently used information locally on the client. The data cache, however , stores data that is frequently or likely to be used instead of file or directory attributes.
Chapter 3. NFS and the User-Defined File System (UDFS) A user-defined file system (UDFS) is a type of file system that you directly manage through the end user interface. This contrasts with a system-defined file system (SDFS), which AS/400 system code creates.
CRTUDFS Display When you use the CRTUDFS command, you can specify many parameters and options: v The required UDFS parameter determines the name of the new UDFS.
This command creates a case sensitive user-defined file system (UDFS) named kate.udfs in the user Auxiliary Storage Pool (ASP), qasp02 . Display a User-Defined File System The Display User-Defined File System (DSPUDFS) command presents the attributes of an existing UDFS, whether mounted or unmounted.
Example Display UDFS in user ASP on TULAB2 DSPUDFS UDFS('/DEV/QASP02/kate.udfs') This command displays the attributes of a user-defined file system (UDFS) named kate.
DL TUDFS Display When you use the DL TUDFS command, you only have to specify one parameter: v The UDFS parameter determines the name of the unmounted UDFS to delete. This entry must be of the form /DEV/QASPXX/name.udfs , where the XX is one of the valid Auxiliary Storage Pool (ASP) numbers on the system, and name is the name of the UDFS.
2. Export the path to the UDFS mount point (the directory you mounted over in Step 1) The previous steps will ensure that the remote view of the namespace is the same as the local view . Afterwards, the exported UDFS file system can be mounted (T ype *NFS) by remote NFS clients.
Saving and Restoring a User-Defined File System The user has the ability to save and restore all UDFS objects, as well as their associated authorities. The Save command (SA V) allows a user to save objects in a UDFS while the Restore command (RST) allows a user to restore UDFS objects.
This window displays the properties of a user-defined file system. For more information about the DSPUDFS command, see “Display a User-Defined File System” on page 17. User-Defined File System Functions in the Network File System T o export the contents of a UDFS, you must first mount it on the local namespace.
directories. For this reason, exporting /DEV or objects within it can cause administrative diff iculties. The next sections describe how you can work around one such scenario.
EXPORTFS OPTIONS('-I -O ROOT=TUclient52X') DIR('/DEV') 2. Now the client can mount the exported directory and place it over a convenient directory on the client, like /tmp . MOUNT TYPE(*NFS) MFS('TULAB2:/DEV') MNTOVRDIR('/tmp') 3.
Chapter 4. Server Exporting of File Systems A key feature of the Network File System is its ability to make various local file systems, directories, and objects available to remote clients through the export command. Exporting is the first major step in setting up a “transparent” relationship between client and server .
The mount daemon checks the export table each time a client makes a request to mount an exported file system. Users with the proper authority can update the /etc/exports file to export file systems at will by adding, deleting, or changing entries. Then the user can use the export command to update the export table.
Chris Admin can export a directory containing only the database files with statistics of the bridge construction safety records. This operation can be performed without fear of unknown users accessing the sensitive data. Chris Admin can use the export command to allow only selected client systems to have access to the files.
After exporting, a remote client can view the exported file systems PROJ2 and PROJ3 . Not all the file systems on the server are visible to remote clients. Only the exported file systems are available for mounting by clients with proper authorities as specified on the export command or in the /etc/exports file.
On any given server file system, when you start exporting, all the objects beneath the export point will also be exported. This includes directories, files, and objects.
For example, the file system /home/sweet/home has been exported, and /home/sweet is a parent directory of /home/sweet/home . Y ou cannot now export /home/sweet unless it exists on a different local file system. 4. Y ou can only export local file systems.
Y ou can export to specific groups of clients by using the /etc/netgroup file. This file contains an alias for a group of clients to whom file systems will be exported. No other systems outside of the netgroup will be able to access the file systems.
v The directory entry is the name of the directory that you want to export. The pathname you specify will be listed in the DIR parameter on the CHGNFSEXP command. This entry specifies the path name of the existing directory to be exported (made available to NFS clients) or unexported (made unavailable to NFS clients).
CHGNFSEXP OPTIONS('-I -O RO,ANON=199,ACCESS=Prof:1.234.5.6') DIR('/engdata/mech') HOSTOPT((TULAB1 850 850)) This command exports the directory tree under the path name /engdata/mech as read-only . This command allows only two clients to mount this directory tree.
3. Choose NFS –> Properties to bring up the dialog box that is shown below . Figure 25. The Operations Navigator interface. Figure 26. The NFS Export dialog box.
4. Customize the export on a per-client basis under the Access tab. 5. Set the public access rights as desired. 6. Click on the Add Host/Netgroup button. This will allow you to add other clients with specific privileges. The figure below shows a display of the dialog box.
In the Exports dialog, clicking the Export button will immediately export the folder on the AS/400 server . Y ou also have the option of updating the /ETC/EXPORTS file with this new or changed export. Finding out what is exported Often, you need to know the items that are currently exported on an AS/400 system.
5. Select Exports . From here, you can easily add new exports or remove entries from the list. The figure below shows the dialog box for NFS Exports. Retrieve Network File System Export Entries (QZNFRTVE) API A second method of finding currently exported items on an AS/400 is using the Retrieve Network File System Export Entries (QZNFRTVE) API.
Exporting Considerations Mounted File System Loops Users and administrators can encounter diff iculty with the inability of NFS to export an already-mounted Network File System. NFS will not allow the export of a mounted file system because of the possibility of mounted file system loops.
Chapter 5. Client Mounting of File Systems The mount command places the remote file system over a local directory on an NFS client. After exporting, mounting a file system is the second major step in setting up a “transparent” relationship between client and server .
Given the proper authority , an NFS client can mount any file system, or part of a file system, that has been exported from an NFS server . Mounting is the local client action of selecting an exported directory from a remote server and making it accessible to the integrated file system namespace of the local client.
There is a “downstream” principle for mounting that is similar to the “downstream” rule for exporting. Whenever you mount a remote file system over a local directory , all of the objects “downstream” of the mount point are “covered up”.
Sometimes the namespace of a client can become too complicated or overwhelmed with information. The unmount command is an easy way to slowly disengage from the server one file system at a time. T o unmount all file systems, specify the *ALL value for the TYPE parameter on the UNMOUNT or RMVMFS (Remove Mounted File System) commands.
For example, TULAB2 exports /classes/class1 , which contains the directory /classes/class1/proj1 . A remote client has a local directory /user , which contains the directory /user/work , which contains the directory /user/work/time .
The new local directory tree on the client will display /user/work and the various contents and sub-directories, as shown here. Note: NFS clients will always see the most recent view of a file system. If the client dynamically mounts or unmounts a file system, the change will be reflected on the namespace of the client after the next refresh.
Mount Points Mount points mark the area of the local client and remote server namespaces where users have mounted exported file systems. Mount points show where the file system has been mounted from on the server and show where it is mounted to on the client.
2. If you are mounting a user-defined file system or a Network File System, then you require *R (read) authority to the file system being mounted. 3. If you are mounting a NetWare file system, then you require *X (execute) authority to the file system being mounted.
v The path name code page specifies what code page should be assumed for path names on the remote system. This is a code page to be assumed for path names on the remote system.
ADDMFS TYPE(*NFS) MFS('TULAB2:/QSYS.LIB/WORK.LIB') MNTOVRDIR('/HOME') OPTIONS('ro, nosuid, rsize=256, retrans=10') CODEPAGE(*JOBCCSID) This command mounts the /qsys.lib/work.lib file system from the remote system TULAB2 onto the local client directory /HOME .
2. a remote file system accessed via a Network File System server (*NFS) 3. a local or remote NetWare file system (*NETW ARE). If any of the objects in the file system are in use, the command will return an error message to the user .
Examples Example 1: Unmounting a Directory . RMVMFS TYPE (*NFS) MNTOVRDIR('/tools') This command unmounts a Network File System that is accessible on directory /tools . Example 2: Unmounting a User-Defined File System . RMVMFS TYPE(*UDFS) MFS('/DEV/QASP02/A.
When you use the DSPMFSINF command, you only have to specify one parameter: v The required OBJ parameter 1 on the DSPMFSINF command specifies the path name of an object that is within the mounted file system whose statistics are to be displayed.
This first display shows basic information about a mounted file system. Y ou can see from this display advanced types of information are not supported for user-defined file systems. Display Mounted FS Information Objec t............: /home/students/ann File system typ e.
Examples Example 1: Displaying Statistics of a Mounted File System . DSPMFSINF OBJ('/home/students/ann') This command displays the statistics for the mounted file system that contains /home/students/ann . Example 2: Displaying ’/QSYS.LIB’ File System Statistics .
54 OS/400 Network File System Support V4R4.
Chapter 6. Using the Network File System with AS/400 File Systems There are several exceptions to using AS/400 file systems with NFS on various clients. This is because you are able to export several dif ferent file systems on an AS/400 NFS server .
Network File System Dif ferences Case-Sensitivity When a remote UNIX client mounts an object that the server exports from the “root” (/) file system, it will always function as case-insensitive.
Read/Write Options No matter what options the client specifies on the MOUNT command, some server file systems from QOpenSys exist as read-only or read-write. However the client mounts a file system determines how the file system is treated and how it functions on the client.
Note: See the System API Reference, SC41-4801 book for more details on the open() API and the O_TEXTDATA and O_CODEPAGE options. QPWFSERVER Authorization List The QPWFSERVER is an authorization list (object type *AUTL) that provides additional access requirements for all objects in the QSYS.
from 92, which leaves a default of 80 bytes per record for source physical files. For any record length specified, the real amount of bytes per record is the number specified minus 12 bytes for source physical files. Byte-Range Locks QSYS.LIB does not support byte-range locking.
Document Library Services File System (QDLS) Network File System Dif ferences Mounting and QDLS Users can mount the QDLS file system on a client, but users cannot mount over the QDLS file system. File Creation Users cannot create regular files in the top-level /QDLS directory .
using the ADDDIRE (Add Directory Entry) command. All anonymous client requests that are mapped to QNFSANON will fail at the server if you do not enroll the QNFSANON user profile in FMS.
Case-Sensitivity QOPT is case-insensitive. It converts lowercase English alphabetic characters to uppercase when used in object names. Therefore, the path name /QOPT/volume/dir/file represents the same path as /QOPT/VOLUME/DIR/FILE .
Network File System Dif ferences Case-Sensitivity When remote UNIX clients mount objects that the server exports from a UDFS, the case-sensitivity is variable, depending on how the user created the UDFS. A UDFS that is mounted on a UNIX client can cause the case-sensitivity to change in the middle of a directory tree.
64 OS/400 Network File System Support V4R4.
Chapter 7. NFS Startup, Shutdown, and Recovery NFS startup performs separately and independently on each machine. The startup of an NFS component on one system does not trigger the startup of an NFS component on another system. For example, if you start the Network Lock Manager on a client, the NLM on the server will not automatically start up.
a. Select option 2 (Change) from the CFGTCP menu to add a name for an address. b. Select option 1 from the CFGTCP menu to add an entire new address with names. 6. V erify that the names LOOPBACK and LOCALHOST are associated with the IP address 127.0.0.
waits for requests (the standard is #2049). All server daemons will use this same port. The NFS server daemons then wait on the port for RPC requests from NFS clients to access local files. 4. The user starts the mount daemon (QNFSMNTD). This daemon registers to the local RPC binder daemon.
If you attempt to start a daemon or daemons that are already running, they will not cause the command to fail, and it will continue to start other daemons you have requested to start. The command will issue diagnostic message CPDA1BA if the daemon is already running.
STRNFSSVR Display When you use the STRNFSSVR command, you can specify many parameters: v The required SERVER parameter on the STRNFSSVR command specifies the Network File System daemon jobs to be started by this command. The specified daemon should not already be running.
This command starts the NFS mount daemon, and waits up to the default of 30 seconds for it to start. The mount daemon should not be already running, and other daemons have been started in the appropriate order . Proper Shutdown Scenario Shutting down an NFS server properly allows for all jobs to finish and all requests to be completed.
v The mount (MNT) daemon v The server (SVR) daemon v The block I/O (BIO) daemon v The Remote Procedure Call (RPC) binder daemon If you are choosing to end just one daemon, be sure you understand the appropriate order for ending NFS daemons and the possible consequences of ending deamons in an order other than that specified above.
v The required SERVER parameter on the ENDNFWSVR command specifies the Network File System daemon jobs to end. v The ENDJOBTIMO parameter on the ENDNFSSVR command specifies the number of seconds to wait for each daemon to successfully end. If a daemon has not ended within the timeout value, the command will fail.
Y ou can also display the status of each individual daemon by choosing Properties . This brings up the following dialog box: In the example, Chris Admin has decided to start 4 of the Server type daemons to give better throughput. Y ou can start up to 20 of these daemons from the General Figure 55.
tab of the previous dialog box. Notice that the Network lock manager daemon is stopped. This could indicate that it encountered a problem by trying to start up. Alternately , it could mean that the administrator chose to end it specifically because of no need for byte range locking.
If a client with a granted lock request should happen to fail, a specific set of operations will occur at startup time to recover the locks: 1. When the user restarts the NSM daemon on a system, the daemon will send a change of state RPC to other NSM daemons in the network.
RLSIFSLCK Display When you use the RLSIFSLCK command, you can specify many parameters: v The RMTLOCNAME parameter on the RLSIFSLCK command specifies the host name or internet address of a remote system whose NFS-related locks on local files are to be released.
Chapter 8. Integrated File System APIs and the Network File System Error Conditions There are two error conditions that commonly appear when working with the Network File System through integrated file system APIs (application program interface) that require special consideration.
UDP does not guarantee the delivery or order of data returned to clients. A client may receive any one of the following return codes for a successful operation: 1. Return code=0 (RC=0). The operation is completed successfully . 2. EEXIST . The operation is completed successfully .
Once a file or directory is open, subsequent requests to perform operations on a file or directory can fail. This is because attributes are checked at the server on each request. When permissions on the object are more restrictive at the server , your operations on an open file descriptor will fail when NFS receives updates.
80 OS/400 Network File System Support V4R4.
Chapter 9. Network File System Security Considerations Y ou can use the Network File System to create a seamless, transparent namespace where all users have access to the right information at any given time. However , NFS also has special security considerations.
Network Data Encryption A client existing outside the trusted community can become aware of the community’s existence. Furthermore, a malignant client can introduce a “sniff” program that can read and change data as it transfers in the client/server relationship.
User Authorities As users log on to NFS clients and servers, the user authority of each user dictates what they can and cannot do. User authorities are assigned to users by administrators, and usually.
forbidden to their profiles. It is important to become aware of which users from which groups have access to your data. GIDs can help a user from a powerful group gain unauthorized access to sensitive data. The various IDs a user has and the attached authorities can create NFS security hazards.
appropriate to both the user and the system in question. Just because users need *SECOFR authority on one system does not mean that they need that same authority on all machines. UID Mapping Examples In the TULAB, an engineering graduate student named Bill has a UID of 136 on TULAB1 and a UID of 142 on AS/400 TULAB2.
There are other ways to tap into a system of users and the objects owned by them. The administrator of a client can deliberately impersonate a remote server UID. For example, the administrator of a client can log on and access the UID of a user , Mary on TULAB2, who accesses the client.
However , instead of changing the UID and user profile for each user on each system, administrators can use the QSYCHGID API (application programming interface). This new API can be called from AS/400 command lines, C programs, COBOL programs, and through other interfaces as well.
1. Administrators should never export the “root” (/) Directory . Remember that whenever you export a file system, you also export all of the directories and objects “downstream” of the path. Should the “root” (/) directory become exported, all the other directories and objects downstream of “root” (/) will become exported as well.
v Change the file permissions for “the world” while still mapped to QNFSANON Exporting to ″ The World ″ Instead of making exported data accessible to everyone, an administrator can employ the technique of specifying selective clients. Administrators can use the ACCESS option of the CHGNFSEXP command to use this technique.
90 OS/400 Network File System Support V4R4.
Appendix A. Summary of Common Commands T able 1. CL Commands Used in Network File System Applications Command Description ADDMFS Add Mounted File System. Places exported, remote server file systems over local client directories. CHGNFSEXP Change Network File System Export.
92 OS/400 Network File System Support V4R4.
Appendix B. Understanding the /etc Files A directory named /etc exists within the integrated file system namespace. This directory contains important system files that users should never write to or change unless they are experienced NFS administrators.
In the EDTF utility , you find all the appropriate line commands by pressing the F1 (Help) Function Key . Editing stream files by using a PC based editor The second method to edit the netgroup file is by using a PC-based editor . If you want to use a PC-based editor , you need access to the /etc directory on the AS/400.
10. No tabs or line feeds can be used in the path name 1 1. All characters following the pound sign ’#’ are considered comments until the end of the line. The only exception to this rule is the HOST OPT parameter , which uses the ’#’ character as a starting point for each HOSTOPT entry .
3. Options are case-insensitive. 4. Options that are not specified will be processed as the defaults described in “Formatting the HOSTOPT (Host Options) Parameter” on page 95. Examples of Formatting /etc/exports with HOST OPT Parameter Example 1: Exporting to a host and specifying all options.
host-name The name of any host from the /etc/hosts file. AS/400 does not support the /etc/hosts file as a separate integrated file system file. The /etc/hosts is built in to AS/400 TCP/IP support. user-name The name of any user from the /etc/passwd file.
98 OS/400 Network File System Support V4R4.
Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area.
Software Interoperability Coordinator 3605 Highway 52 N Rochester , MN 55901-7829 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
Programming Interface Information This publication is intended to help you to use OS/400 Network File System Support to construct a distributed network. This publication documents General-Use Programming Interface and Associated Guidance Information provided by OS/400 Network File System Support.
102 OS/400 Network File System Support V4R4.
Bibliography This bibliography lists publications that contain background information or more details for information that OS/400 Network File System Support discusses. The list below gives the full title and order number of each book. OS/400 Network File System Support may use a shortened version of the title when referring to these books.
104 OS/400 Network File System Support V4R4.
Index Special Characters /etc/exports file 95 description 94 formatting entries 94 HOSTOPT parameter 95 HOSTOPT parameter format rules 95 purpose 94 /etc files 93, 94, 95 /etc/exports file 94 descr.
caches 14, 14 (continued) definition 14 directory and file attribute cache description 13 functions 13 introduction 12 case-sensitivity 16, 17 /etc/netgroup file 97 CASE parameter 16 create a UDFS 15 create a udfs case-insensitive 16 case-sensitive 17 CRTUDFS command 15, 16 CRTUDFS display 16 pattern-matching 59 QSYS.
DSPMFSINF command description 50 display 50 examples 53 OBJ parameter 51 purpose 50 DSPUDFS command UDFS parameter 17 E encryption definition of types 82 introduction 82 ENDNFSSVR command 72 display .
file systems 61, 15, 55, 56, 57, 58, 59, 60, 61mdit (continued) root (/) file system case-sensitivity 56 Network File System differences 55 read/write options 56 user-defined file system (UDFS) au.
Network File System 74, 9, 10, 1 1, 12, 13, 14, 65, 66mdit (continued) byte-range locks (continued) statelessness 74 why should I lock a file? 74 caches definition 8 client 8, 1 1, 77 block I/O daem.
P protocols 9, 77 NFS 4, 8 single-threaded 9 NFS protocol 77 RPC 4, 8 stateless 4 TCP 4, 8, 70 UDP 4, 8, 70 considerations 77 XDR 8 Q QDLS file system 60 Network File System differences 60 anonymous .
startup (continued) NFS server STRNFSSVR command 67 NFS server scenario 66 state 4 statefulness definition 4 statelessness definition 4 ST A TFS command description 50 display 50 examples 53 OBJ par.
user-defined file system (UDFS) 15, 16, 17, 18, 19, 20, 23, 63 (continued) display 15 example 20 process 19 Network File System differences 62 auxiliary storage pools (ASPs) 63 case-sensitivity 63 N.
Readers’ Comments — We’d Like to Hear from Y ou AS/400e OS/400 Network File System Support V ersion 4 Publication No. SC41-5714-01 Overall, how satisfied are you with the information in this bo.
Readers’ Comments — We’d Like to Hear from Y ou SC41-5714-01 SC41-5714-01 IBMR Cut or Fold Along Line Cut or Fold Along Line Fold and T ape Please do not staple Fold and T ape Fold and T ape Please do not staple Fold and T ape NO POST AGE NECESSARY IF MAILED IN THE UNITED ST A TES BUSINESS REPL Y MAIL FIRST -CLASS MAIL PERMIT NO.
.
IBMR Printed in the United States of America on recycled paper containing 10% recovered post-consumer fiber . SC41-5714-01.
Spine information: IBM AS / 400e O S / 400 N e tw o rk F il e S yst e m S u p po rt V4R4 V ersi o n 4.
An important point after buying a device IBM AS/400e (or even before the purchase) is to read its user manual. We should do this for several simple reasons:
If you have not bought IBM AS/400e yet, this is a good time to familiarize yourself with the basic data on the product. First of all view first pages of the manual, you can find above. You should find there the most important technical data IBM AS/400e - thus you can check whether the hardware meets your expectations. When delving into next pages of the user manual, IBM AS/400e you will learn all the available features of the product, as well as information on its operation. The information that you get IBM AS/400e will certainly help you make a decision on the purchase.
If you already are a holder of IBM AS/400e, but have not read the manual yet, you should do it for the reasons described above. You will learn then if you properly used the available features, and whether you have not made any mistakes, which can shorten the lifetime IBM AS/400e.
However, one of the most important roles played by the user manual is to help in solving problems with IBM AS/400e. Almost always you will find there Troubleshooting, which are the most frequently occurring failures and malfunctions of the device IBM AS/400e along with tips on how to solve them. Even if you fail to solve the problem, the manual will show you a further procedure – contact to the customer service center or the nearest service center
