In some fashion, nearly everyone uses the iSeries IFS to store some Windows-type files, but few iSeries professionals do the reverse: store data for their iSeries applications on a Windows server. Within a Windows network, the iSeries is capable of joining in all the reindeer games.

Last month, we talked about Windows applications using files stored on the iSeries through the services provided by NetServer, a network program that supports Server Message Block (SMB), the Windows file server protocol. This time, we'll go the other way and look into how the iSeries allows an iSeries application to access data stored on a Windows server.

The QNTC File System

Among the services provided by NetServer is the QNTC file system, a subset of the iSeries IFS. The QNTC file system is a feature of the iSeries NetServer program that uses the SMB protocol to request network services from a Windows server. Curiously, this arrangement makes the iSeries the client and a PC the server.

The only snag is that the iSeries NetServer program must be configured under the same TCP/IP domain or workgroup as your Windows network, and your user ID and password must be the same on the iSeries and PCs. This isn't such a big deal, though. You can either hard-code your domain name across all participants or configure your Windows WINS server to provide it for you.

Configuring the QNTC File System

The SMB protocol that the QNTC file system uses revolves around Windows file shares. File shares are permissions to allow access to files stored within a Windows server. At least one file share must be created on each Windows server that is participating in the network. A share can apply to a disk or a folder and may be tailored to allow access to everyone, only certain users, or only certain levels of access (e.g., read only). So step one is to create your Windows file shares on each PC.

Next, each Windows server must have a user ID and password combination that matches your iSeries user ID and password. QNTC will supply your current iSeries user ID to Windows when it accesses the shares on your PCs.

Finally, you have to configure the NetServer program to be a part of the Windows domain or workgroup. From the iSeries Navigator display, go to Network>Servers>TCP/IP. On the right panel, right-click NetServer, select Properties, and click Next Start. In the Properties dialog box, you may either hard-code the domain name or specify the Windows server that is to provide WINS naming services. (Note: You'll have to end and restart NetServer to make the changes effective.)

Once the NetServer program is started, NetServer will create links leading to your Windows shares and, in turn, the files within them. From an iSeries green-screen command line, key WRKLNK QNTC to see the file shares that NetServer sees in your network (Figure 1).

Figure 1: The NetServer program shows you what Windows network servers it has discovered on your system. (Click images to enlarge.)

The example in Figure 1 shows that two Windows PCs have been configured to share their contents. Key a 5 next to the link name to display the shares that are available on each server (Figure 2).

Figure 2 shows a number of shares on the Windows server. Of interest are wwwroot$, which is the file share created by a running instance of Internet Information Server (IIS), and C Drive, which is the general-purpose file share manually created for Windows networking.

Figure 2: This is an example of the file shares configured within a Windows server.

Again, if you key in a 5 next to a share name, the folders and files that are represented by the share will be displayed. These files and folders will look remarkably like those displayed by something like Windows Explorer.

The fully qualified names of the files that live on the Windows server will take this form: /QNTC/PC Name/Share Name/Path Name/File name and extension. For example, the qualified name /QNTC/DESKTOP1/C Drive/JBuilder9/MyProg.java indicates to NetServer that the file MyProg.java can be found on the DESKTOP1 server, in the C Drive share (which includes the physical folder Jbuilder9). The fully qualified name for a given file is displayed when you press F22.

Stream Files and ASCII

To get a feel for the QNTC treatment of data, one must understand what stream files are. Whereas iSeries data is represented in a structured format called "records," Windows data is just a succession of bytes. There is no such thing as a "record" in a stream file. The closest representation of a record in a stream file would be the bytes that lie between two sets of carriage return/line feed characters, be there 1 byte or 1,000 bytes.

Reading from and writing to a stream file is likewise different with Windows data than it is with iSeries data. Reading stream file data is like turning on a garden hose. Data will squirt into your program in a string of bytes without regard for record definitions or field boundaries. It's up to your program to control the flow of the incoming data by some means (count the number of bytes received, examine the incoming bytes for CR/LF, or the like).

There's a bit more. As you know, PC data is represented in ASCII and iSeries data is in EBCDIC. So for most applications using QNTC, a translation must take place. This is usually accomplished with the help of a translation table.

Using the QNTC File System

OK, so what do you do with the QNTC file system? Well, some pretty handy things. Beyond the obvious benefit of transferring certain types of iSeries physical files to a Windows server, the QNTC file system allows an application running on the iSeries to interact with data residing on the Windows server.

As an example, let's take a simple case in which a member in a source file on the iSeries will be transferred to the Windows server. (This might be the case when iSeries Java code is brought into a development environment like JBuilder.) You may have used one of the handy iSeries commands for moving iSeries data into the IFS file system: Copy to Stream File (CPYTOSTMF) or Copy from Stream File (CPYFRMSTMF). These commands work nicely with the QNTC file system to move stream data to a Windows server. In this example, a source file member is being copied to a stream file that will be created on the Windows server named DESKTOP1 in the share named C Drive.

(Note the use of the more reliable code page 437 instead of *PCASCII.)

A stream file will be created on the Windows PC that is a representation of the source physical file member copied.

Stream File APIs

For the more intrepid developer, a set of IBM APIs is available to allow closely controlled manipulations of stream file data. Using the APIs in, say, an RPG program gives you the same high level of control you've come to expect. These iSeries APIs read stream file data:

• Open
• Read
• Write
• Close
• __errno

Each is referenced as an "ExtProc" prototype specification in the RPG data specifications, along with the appropriate structure for passing data to and from the API. This is the sequence of steps within the RPG program's calculation specifications:

1. Get a handle to the stream file with the Open API.
2. Read or write bytes of the stream file within a loop with the Read or Write API (note that your program must determine the number or type of bytes read or written and behave accordingly).
3. Translate the ASCII data to EBCDIC and vice versa (you can call the IBM program QDCXLATE with translation tables QASCII and QEBCDIC employed to perform the translations).
4. Close the stream file(s).

With this sort of arrangement, the data that lives on your Windows servers can be accessed and modified by applications running on the iSeries. In certain circumstances, perhaps where a PC application is creating local data and an iSeries application must make use of that data, the QNTC file system can present a viable solution.

Chris Peters has 26 years of experience in the IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries/400 Report Downloader. Chris is the author of The OS/400 and Microsoft Office 2000 Integration Handbook, The AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400 (MC Press). He is also a nationally recognized seminar instructor. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..