There are some basic concepts that you must understand before you use Net.Data. In particular, the HTTP server you are using and the Integrated File System.
Net.Data can only be invoked as a common gateway interface (CGI) program on the AS/400. As a CGI program, Net.Data follows the CGI interface that has become a standard: client (e.g. browser user) data, such as form or URL data, is received by a CGI program from stdin, and output data generated by a CGI program is returned to the client by writing to stdout.
The main points that you need to worry about if you want to run Net.Data with an HTTP server is whether:
If the answers to both questions yes, then Net.Data can be used with the HTTP server of your choice.
One final note. In the following sections, we show you how to get Net.Data up and running using Internet Connection for AS/400, which is the HTTP server that is a standard part of the OS/400 operating system in V3R2 and V3R7 (and subsequent releases). If you are not using Internet Connection for AS/400, you will need to determine how to enable your HTTP server to invoke Net.Data as a CGI program.
All object references that can be specified when using Net.Data is assumed to be in path name format. A path name tells the system how to locate an object. The path name is expressed as a sequence of directory names followed by the name of the object. Individual directories and the object name are separated by a slash (/) character; for example:
/directory1/directory2/file
Path names are intimately tied to the integrated file system.
The integrated file system is a part of OS/400 that supports stream input/output and storage management similar to personal computer and UNIX operating systems, while providing an integrating structure over all information stored in the AS/400.
Some of the key features of the integrated file system are the following:
A file system provides the support that allows users and applications to access specific segments of storage that are organized as logical units. These logical units are files, directories, libraries, and objects.
Each file system has a set of logical structures and rules for interacting with information in storage. These structures and rules may be different from one file system to another. In fact, from the perspective of structures and rules, the OS/400 support for accessing database files and various other object types through libraries can be thought of as a file system. Similarly, the OS/400 support for accessing documents (which are really stream files) through the folders structure may be thought of as a separate file system.
The integrated file system does indeed treat the library support and folders support as separate file systems. Other types of file management support that have differing capabilities are also treated as separate file systems. Here are some of the file systems available on the AS/400:
Path names have the following form:
/Directory/Directory . . . /Object
Each component of the path name can be up to 255 characters long, much longer than in the QSYS.LIB or QDLS file systems. The full path name can be extremely long, up to 16 megabytes. There is no limit to the depth of the directory hierarchy other than program and system space limits.
The file system preserves the same uppercase and lowercase form in which object names are entered, but no distinction is made between uppercase and lowercase when the system searches for names.
Path names have the following form:
/Directory/Directory/ . . . /Object
Each component of the path name can be up to 255 characters long. The full path name can be up to 16 megabytes long. There is no limit to the depth of the directory hierarchy other than program and system space limits.
Unlike the "root" (/) file system, the QOpenSys file system distinguishes between uppercase or lowercase when searching for object names. For example, a character string supplied in all uppercase characters will not match the same character string in which any of the characters is lowercase.
Each component of the path name must contain the object name followed by the object type of the object. For example:
/QSYS.LIB/CGI.LIB/MYPGM.PGM
/QSYS.LIB/EMP.LIB/PAY.FILE/TAX.MBR
The object name and object type are separated by a period (.). Objects in a library can have the same name if they are different object types, so the object type must be specified to uniquely identify the object. The object name in each component can be up to 10 characters long, and the object type can be up to 6 characters long. The directory hierarchy within QSYS.LIB can be either two or three levels deep (two or three components in the path name), depending on the type of object being accessed. If the object is a database file, the hierarchy can contain three levels (library, file, member); otherwise, there can be only two levels (library, object). If / and QSYS.LIB are included as the first two levels, the directory hierarchy for QSYS.LIB can be up to five levels deep.
In general, the QSYS.LIB file system does not distinguish between uppercase and lowercase in the names of objects. A search for object names achieves the same result regardless of whether characters in the names are uppercase or lowercase. However, if a name is enclosed in quotation marks, the case of each character in the name is preserved. A search involving quoted names, therefore, is sensitive to the case of the characters in the quoted name.
To learn more about the integrated file system, including other file systems not listed above, see the Integrated File System Introduction.