Editor’s Note: This is the second installment in an ongoing series exploring the different ways you can utilize the AS/400 Integrated File System (AS/400 IFS) to provide additional capabilities on your AS/400-centric network.
The AS/400 supports many types of communication protocols, allowing it to participate in file serving with a variety of other systems. In this example solution, I will show you how the AS/400 can be used to let two other systems, a Sun workstation and an NT Server, share a file. The two systems in the example are unable to share the file because they do not speak the same file serving “language.” Because the AS/400 can share files with both of these systems, it becomes the interpreter between them.
In this fictitious example, Joe uses a Sun workstation to develop source code. The tools and environment on the workstation are familiar and comfortable, and he is most productive there. Joe’s current project is to provide an application for an NT server; therefore the code must be compiled and run on Windows NT, rather than on his Sun workstation. One possible solution would be for Joe to copy the file—either by putting it on disk or using FTP—to transfer a copy of the file from one machine to the other. However, this is tedious; Joe will have many updates to the code as he develops it. The source code needs to be current on the NT server immediately.
Joe normally uses Network File System (NFS) on his Sun workstation to share files with other systems. For example, he shares files to his company’s AS/400s (those that are at OS/400 V3R7 or later), for which he also develops applications. Although there are NFS products available for Windows NT, the NT servers at Joe’s company do not have NFS. The system administrator explains that the NT servers use their native file sharing capability based on the industry-standard Server Message Block (SMB) protocol to do file sharing. (For more information on new features for how the AS/400 integrates with the Windows NT SMB protocol, see “An AS/400 Client for Windows NT” on page 20.) One
NT server has the Client Access/400 product installed on it. The administrator explains that the NT servers can share files with the company’s AS/400s using either the Client Access/400 product or AS/400 Support for Windows Network Neighborhood (NetServer). NetServer is available in OS/400 on AS/400s that are at V4R2 or later. (For an introduction to NetServer, see “Client Access Without Client Access,” Client Access/400 Expert, July/August 1998.)
Now Joe understands how he can solve his problem using the configuration shown in Figure 1. He can use NFS to share the source code to an AS/400. The AS/400 can then share this file to the NT servers using Client Access/400 or NetServer.
To set up his communications, Joe first goes to his Sun workstation, in this example it is named Sun1. His source code is stored in a directory on his Sun workstation called /Applications/1998/NT. He makes sure NFS is started on the Sun workstation (the command to do this is platform-dependent) and exports this directory to the AS/400 or AS/400s. An export in NFS makes the files available to selected clients. Next, he gets the administrator of the AS/400 (called QAS400SYS1) to run the Start NFS Server (STRNFSSVR) command on the specified AS/400 as follows:
STRNFSSVR SERVER(*ALL)
This command starts several daemon jobs in the QSYSWRK subsystem. These daemon jobs are responsible for listening for NFS requests on the network and processing them. There are six daemons that start when you use the SERVER(*ALL) parameter. IBM recommends that you start all the daemons unless your administrator is an expert on NFS and understands the daemons and their interdependencies. For more information about the NFS daemons, refer to the book OS/400 Network File System Support (SC41-5714) or Exploring NFS on AS/400 (SG-24-2158-00).
The administrator then mounts the directory from the Sun workstation into /home/joe on the AS/400 using the following command:
MOUNT TYPE(*NFS) MFS(‘SUN1:/Applications/1998/NT’)MNTOVRDIR(‘/home/joe’)
After this command is run, the files in /Applications/1998/NT are available to the AS/400 namespace in /home/joe. The files are not copied; operations on the files are sent to the Sun workstation to be executed on the original source files. It’s helpful to mention that the AS/400 implementation of NFS includes the ability to specify data conversion. On both the EXPORTFS and MOUNT commands, the user can specify that outgoing (exported) or incoming (mounted) data should be converted. On EXPORTFS (which is not covered here), a code page can be specified for outgoing data or path names on the HOSTOPT parameter. On the MOUNT command, there is a CODEPAGE parameter to specify the code page of the incoming data so that it can be correctly labeled on the file.
Some special options, such as *BINARY, *ASCII, and *JOBCCSID, are provided for those not familiar with numerical code pages so Joe doesn’t have to worry about file conversion.
The second step is to make the files available on the NT servers. On the NT server running Client Access, the administrator must map a network drive to the AS/400 and make /home/joe available to users (as shown in Figure 2). To do this, he specifies the following drive mapping:
QAS400SYS1HOMEJOE
When Joe logs on, he has the authority to access this directory because he is the owner. If the administrator does not map a network drive, the files in JOE can also be accessed by using the Universal Naming Convention (UNC) (e.g., QAS400SYS1JOE).
In order for the NT Servers using NetServer to share files with the AS/400, Joe must create a share. The easiest way to create a share is from Operations Navigator. (AS/400 APIs can also be used.) From Operations Navigator in Client Access/400 V3R2, the administrator pulls up NetServer properties by following the Network/Servers/TCP/IP/NetServer path for his AS/400 (for V3R1M3, the path is Network/Servers/NetServer). The administrator right-clicks Shared Objects under NetServer, then selects New and File to get to the NetServer File Share screen shown in
Figure 3. The directory name /home/joe and read/write access for Joe are specified. Once /home/joe is shared and NetServer is started on your AS/400, the directory can be accessed from Windows Explorer on the NT Server. (For information on how individual Windows computers use NetServer to access AS/400 files, please see “Client Access Without Client Access,” Client Access/400 Expert, July/August 1998.)
From his Sun workstation, Joe writes to his files in /Applications/1998/NT. The files are actively shared to the NT server through the AS/400 and can be compiled and tested immediately. In this example, the data is never actually stored on the AS/400; it merely acts as an interpreter to the file-sharing scheme.
Figure 1: The AS/400 can act as interpreter to share files between Sun and Windows NT servers by using NFS between the AS/400 and the Sun workstation and Client Access/400 or NetServer on the Windows NT server.
Figure 2: On NT servers using Client Access/400 to share files with the AS/400, the administrator can map a network drive to the Sun directory that was mounted on the AS/400.
Figure 3: For NT computers using NetServer to share files with the AS/400, you need to use Operations Navigator to create a share for the AS/400 directory that contains the exported Sun data.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online