Analysis of System of Files Provided by IBM System I

NB: We do not resell your papers. Upon ordering, we do an original paper exclusively for you.

NB: All your data is kept safe from the public.

Table of Contents

The New File System
Features and Advantages
The New I/O
Pre-history: The S/38
iSeries and the Internet
Types of files in the IBM System I
Reference List

The New File System

The file system is one of the most visible parts of the operating system. Almost all operating systems let users specify named objects, called files. Files hold programs, data, or anything else the user desires. The operating system also provides various APIs to create, read, write, destroy, and manage files. Moreover, most operating systems have their own unique and distinct file types. For example, UNIX has regular directories, files, and special block and character stream files. Regular files hold user data. Directories are essentially used to keep track of files and consist of information needed to supply files with symbolic names. Also, block and character stream files are used for modeling disk and terminal-like devices. Moreover, the very first application enablers added was the ability to store files from other operating system environments, like UNIX. At V3R1, the integrated file system (IFS) was introduced which not only created a consistent structure for all the existing file systems seen in the AS/400, but also created a new file system structure altogether needed for other operating systems. With passage of time, new file systems have been added. The IFS supported 10 file systems and three server types, by the time the iSeries was announced.

Features and Advantages

The IFS is said to be a part of OS/400, and provides a consistent structure for applications and users that were previously part of the AS/400. In addition, it provides support for the stream I/O files utilized by the PC and UNIX operating systems. Stream files, which contain long continuous strings of data, have become increasingly significant for storing images, audio, and video files (Soltis, 2001). Moreover, the IFS provides a common view of stream files that are stored either locally on the iSeries or a remote server. To manage all the files, a new hierarchical directory structure was created. This hierarchical directory permits access to objects by specifying the path to the objects, through the directories, in a way similar to the one seen in PC and UNIX file systems. This directory and file structure allows information such as UNIX stream files, record-oriented database files, and file serving to be handled through separate file systems or a common interface, depending on the application’s needs. The main advantage and unique capability of the IFS is the ability to support separate file systems through a common, consistent interface. In the original S/38, it was easy to search for an object in the database by simply looking up the name in a library. A library supplied a means by which objects could be organized into distinct groups, and allowed objects to be found by a name. The similar library structure was incorporated into OS/400 (Soltis, 2001).

Libraries: Libraries are said to be OS/400 objects which are used for finding other objects in the database. Moreover, the library is arranged in a single-level hierarchical manner, unlike the directory structure found in UNIX and PC operating systems which show a multi-level hierarchy. Finding an OS/400 object needs the object names and the library along with the object type to uniquely identify the object. Exceptionally, a library cannot reference other libraries, which will, conversely, violate the single-level hierarchy of Library/Object. However, there is a unique and special library called QSYS that is used to reference other libraries (Soltis, 2001).

Shared Folders: Shared folders were brought into OS/400 primarily to support Office/400 functions. The S/36 was an efficient office system, and most of the concepts related to folders originated from this system. An OS/400 folders object was included to support these Office functions. In other words, the integrated Office support provided a filing system for all Office objects that contained data for an Office product. Documents, emails, programs, and file were amongst the conventional items that were present in this file system. Furthermore, document library services allow users to treat the filing system as an electronic filing cabinet furnished with document library objects in folders. Folder management services allow users to organize the objects in these folders. Additionally, folders may contain other folders and may be searched interactively. Therefore, along with the traditional Office items as stated above, shared folders contain stream, files for graphs, images, spreadsheets, PC programs, and PC files. Moreover, IBM replaced PC support with a product called Client Access that provided a platform for distributed client-server computing (Soltis, 2001). Initially, the primary challenge had been to determine how to construct a single file system that could integrate all file system types, since the separate file system was not designed to be compatible to each other. As previously discussed, the single-level-hierarchy OS/400 library structure is a subset of the one used in PC operating system with different names but similar structure. The PC operating systems contain files instead of objects, and a library is called a directory in which files exist. Unlike the OS/400 library structure, directories which exist within directories on the PC are usually called sub-directories. This arrangement, thus, creates a multi-level hierarchy for PC file naming, as opposed to the single-level structure employed by the OS/400 library. A PC file name takes the form DIR1DIR2…..DIRnFILENAME. This is a superset of the OS/400 library naming structure, except for the backward slashes (). Likewise, a UNIX file structure is a superset of the OS/400 library structure. Moreover, a UNIX file system allows multiple paths to the same object. The solution for combining all these file systems was to use a single root from a UNIX-like file system and to place all others under this root. A path name then takes the form DIR1/DIR2/…DIRn/FILENAME. The lengths of the file and directory names in IFS are increased to match the UNIX-based open system standards, like Posix and XPG. In OS/400, the names in the IFS directories are stored in a format known as Unicode, which is an international standard supporting multiple languages, which includes the double-byte character sets used by many nations (Soltis, 2001). The data format must be compatible with the application that requests it, because the IFS allows accessing the data, or the data must be converted to a compatible format. OS/400 manages the conversion between data formats such as Extended Binary Coded Decimal Interchange Code (EBCDIC) used for native iSeries applications, and the American Standard Code for Information Interchange (ASCII) in the PC world. All the files and file systems in the IFS are treated like OS/400 objects. Moreover, file system supports the same set of operations, described for each file in a standard operations table. Each file system possesses its own set of logical structures and rules to interact with information in storage, and these structures and rules differ from one file system to another. By employing a table approach, new file systems can be introduced to the IFS without requiring changes to existing file systems or the operations corresponding to those file systems. Furthermore, the IFS considers the original library support and original folders support as separate and distinct systems; along with the other file support that has varying capabilities. With this structure, new file systems may be integrated into the IFS as and when required. The virtual file system architecture provides a common interface to every file system in the IFS. VFS is an object-oriented interface which provides objects called as nodes which are abstract objects that represent the real objects stored in the file system. The nodes allow a collection of abstract operations to be defined that can be performed on real objects (Soltis, 2001). The UNIX-, Windows-, and OS/400-based servers allow the iSeries to act as both client and server when sharing data over a network. Additionally, the IFS supports the xSeries servers, either remotely attached to the iSeries or integrated into it, and Linux server running in an iSeries partition.

NFS Server: The NFS file system and NFS server let the iSeries act as both client and server by allowing remote file systems or directories to be mounted locally on a PC, a UNIX workstation, or the iSeries. The NFS file system allows users to access data and objects stored on a remote NFS server. Through the NFS server, the iSeries can export a network file system. This server also lets data to be exported from any of the following file systems: Root (/), QSYS.LIB, QOpenSys, QOPT, and UDFS. Communications between client and server are, therefore, accomplished through the use of Remote Procedure Calls (RPCs) (Soltis, 2001).

OS/400 NetServer: OS/400 NetServer allows Windows PCs access IFS directories and OS/400 output queues, with TCP/IP configured on both the iSeries and PC. The PC users access the shared information via Windows Network Neighborhood. The PC user who is connected to the iSeries views the IFS as a disk drive containing directories and objects, and can operate with files in the IFS by utilizing either the file-sharing clients built into Windows and NetWare or Client Access Express for Windows. Major changes have been made to the Client Access support of the iSeries. Previously, the Client Access family of products used proprietary support for printers and network drives. These products are now replaced with two new products that do not require the proprietary support, i.e. iSeries Client Access Express for Windows and iSeries Access for Web. The iSeries Express client uses in-built features of the Windows OS to communicate with OS/400 NetServer for network file and print access. By using the Express client, users can access files using Client Access SPIs through the File System in Operations Navigator (OpsNav). Directories may be created, removed, and renamed when working with the IFS under File System in OpsNav. Moreover, drag-and-drop functions are also available in the Express Client under Integrated File System with the Client Access SPIs. This is particularly important to take advantage of Secure Socket Layer (SSL). The SPIs support SSL while OS/400 NetServer does not (Soltis, 2001).

IFS objects can be accessed using either OpsNav or CL commands, the command language for OS/400 that was carried forward from S/38. Moreover, all the APIs used in the IFS are thread safe when they are directed at an object in a thread-safe file system. QOpenSys, QSYS.LIB, QOPT, QNTC, and user-defined file systems are all thread safe. Also, DataLinks extend the types of data stored in a database file. DataLink columns in the database are used for holding references to non-database files that are stored in the local IFS, remote IFS, or in the file system of any attached UNIX or Windows server that has IBM’s DataLink Manager installed. A DataLink is used to specify the object’s file location rather than storing the data object itself in the database columns. Furthermore, DataLink support lets the user assign directories in the Root to hold data link objects. Once a directory is set as a DataLink directory, all objects in that directory are accessed via the DataLink File Manager, i.e. DLFM. Therefore, the IFS is a fundamental application enabler for the iSeries. It enhances the existing data management capabilities of OS/400 and extends these capabilities to support the emerging new application environments (Soltis, 2001).

The New I/O

The I/O subsystem diffuses almost every part of a computer system. Though it is considered to be only one-third of the processor, memory, and I/O complex, I/O is considerably larger than either of the other two. I/O configuration requires more hardware and more lines of operating system code, as compared to anything else in the system. Briefly, the I/O sub-system constitutes of the group of components, both hardware and software, responsible for processing input and delivering output to various types of devices attached to the system. Whenever a user requires any system resource, such as reading from or writing to a file, requesting instructions of a program to be executed, requires another system object, creating or destroying an object, and that resource has not already been brought into memory, the computer goes through the I/O sub-system to retrieve or store, create or destroy the resource. Although I/O impacts every level in a computer system, it is usually relegated to second-class citizenship (Soltis, 2001). Along with the memory subsystem, the I/O subsystem finds out the response time and throughput for most computers. With the approaching time, when computers from low-end PCs to the fastest supercomputers will use the same microprocessor building blocks, I/O capabilities may be the only feature that distinguishes one computer system from another. Therefore, it can be debated that, as many are now starting to do, I/O is the most important component in the system. The I/O subsystem residing in the iSeries has undergone major transitions in the past few years, so it is appropriate to examine those changes to see how they will affect IBM’s future system designs. The iSeries uses a hierarchy of components for the attachment of I/O, which includes I/O buses, I/O hubs, I/O bridges, I/O processors (IOPs), I/O adapters (IOAs), and lastly, I/O devices and network connections. The history of I/O hubs subsystem designs in the AS/400 and S/38 is partially technical and partly political. For both systems, the I/O designs were heavily influenced by the factors outside the Rochester development lab (Soltis, 2001).

Pre-history: The S/38

The S/38 employed an I/O channel that was similar to an IBM System/370 (S/370) channel, in many ways. A channel can be thought of as a specialized computer built alongside the main processor that is designed to offload the I/O processing from the main processor. A channel has its own instruction set designed especially to interact with the bus-attached I/O adapter and to transfer data between the memory and I/O devices. The main processor passes the channel hardware to the channel programs which then executes simultaneously with other executing programs in the main processor. When a channel finishes with its program, it interrupts the main processor to get more work. The main reason behind S/38 using a channel was because of the people involved. Many new people had to be brought into Rochester to design and build the S/38 (Soltis, 2001). Most of them came from other parts of IBM, and since the designers of the I/O hardware had previously operated S/370 channels, they decided to use a variant of a design they were familiar with. However, unlike the S/370, which supported multiple channels, the S/38 had only single channel. The second channel was designed but never implemented. The S/38 channel could be described as a block-multiplexer channel operating in a fixed burst mode (Soltis, 2001). For the very first AS/400s, the new I/O structure was developed. Unlike a channel, where the I/O intelligence is placed alongside the main processor or is even part of it, the new structure distributed the intelligence throughout some specialized IOPs designed to perform I/O operations. The concept of using separate processors for I/O had initially been adopted by System/36 (S/36), so the concepts were well known to Rochester developers. A fundamental part of this new I/O structure was the System Products Division (SPD) bus. During the 1980s, IBM corporate management was pertained to the fact that IBM had too many midrange computers all competing for the same customer market. To solve this problem, management moved the responsibility for five distinct midrange systems into one development division, i.e. the SPD. Two of those systems, the S/34 and the S/38, were products from Fortress Rochester. Soon, a new project with the code name Fort Knox was started in SPD, to converge all five systems into one system. The various parts of the new system would be built in different locations that were part of SPD (Soltis, 2001).

From 1988 through 1997, the system I/O bus used in all AS/400s was the SPD bus. Moreover, specialized hardware generated the signals for one or more SPD buses and handled the transitions from the high-speed system memory bus to these SPD system I/O buses. The SPD bus has itself undergone some various updates over the years, but otherwise it is a packet-oriented bus with enhancements that allow efficient streaming of data. Packet-oriented data transmit messages in small blocks, known as packets. Streaming entails continuous blocks of data can be sent, which permits higher data rates to be achieved on the bus. In a streaming mode, the SPD bus can support data rates of 25 to 36 megabytes per second (MB/sec), depending on direction and contention on the bus. Furthermore, the SPD bus supported a parallel copper implementation that could be used inside a single enclosure. This parallel copper bus had 32 lines to transfer data, 8 lines to transfer command and status information, 8 lines for origin-destination identification, and several other control lines. When the AS/400 system was brought in, in 1988, the parallel copper SPD bus was the only one available. Afterwards, a serial optical version of the SPD bus was introduced, which could go outside the single enclosure. Moreover, this serial optical bus was able to cover distances up to 500 meters and even two kilometers in certain environments (Soltis, 2001). Connected to the SPD bus were the IOAs and IOPs that worked together to perform several functions. Additionally, they moved data between the system’s main memory and the I/O devices as well as network connections. They transposed data from one form to another and provided a buffer for high-speed devices like disks for data required by the processors. Earlier, the implementation of these I/O functions utilized dedicated-function IOPs. However, the exception was the multifunction I/O processor where multiple functions could be executed on one IOP. Since most IOPs were dedicated to a single function, the various adapter cards which contained the IOPs and IOAs tended to share very less. As a result of this, numerous different processors were used for the IOPs mostly from the Motorola 68000 family; and many unique AS/400 interfaces to devices were established/ created. A good example of these unique AS/400 interfaces are SCSI, SCSI-2, Workstation, LAN, FDDI, ATM, WAN, Token-Ring, ISDN, Frame Relay. In short, standardization was not a higher priority (Soltis, 2001). Rather than totally altering and immediately phasing out the SPD bus and all SPD I/O adapters, the changes were staged over four releases. This technique would allow customers to migrate to the new AS/400e models and move many of the SPD I/O adapter cards to the new system. Furthermore, a transition I/O structure was created to support both SPD and PCI adapter cards for the next few releases. Soon the necessity arose to increase the bus bandwidths beyond the SPD bus’s capability since customers demanded for tremendous increases in processor, I/O device, and the interconnection network speeds, and to prepare for the likes of 1 to 2 gigabit/sec Fiber Channel buses and 1 to 2 gigabit/sec. The result of this effort is the RIO bus, which consists of a pair of byte-wide unidirectional point-to-point buses, each one containing 8 data lines, one clock line, and one flag line. Another major change during this transition period focused on the IOPs. Starting with V4R1, all new IOPs were being designed to have a more uniform structure. Apart from PowerPC processors, the IOPs use the 32-bit 603 and 740 family of PowerPC. Unlike most of the previous IOPs, these support the attachment of multiple IOAs (Soltis, 2001). Before V4R1, the internal buses of the IOPs were based on the Intel 960 bus, the Motorola 68000 bus, the IBM Micro Channel, or the proprietary magnetic media bus architecture. Since V4R1, all new IOPs now use only the PCI bus. Furthermore, the PCI bus architecture allows a shared bus to be used for interconnecting the I/O components in the server. When one device is using the bus at a given instance of time, no other device can use the same bus at that time. Though multiple PCI buses may be used in a server, however, the shared bus architecture restricts the total I/O bandwidth that can be achieved. With InfiniBand, the shared bus is replaced by high-bandwidth, high-speed, point-to-point connections between devices. Additionally, InfiniBand is known as switched fabric architecture because it uses switches for making point-to-point connections, similar to the way switches are used in the iSeries memory subsystem. Moreover, the InfiniBand architecture is also called channel architecture because of its similarity in the concept to the S/370 channel that inspired the I/O structure in the S/38. Also, because InfiniBand is a channel, it has more intelligence built into it than a PCI bus does.

iSeries and the Internet

IBM has placed iSeries as the best hardware platform for the Internet-based applications by offering software development and management tools like the WebSphere, as well as creating a multifaceted iSeries environment called the Integrated File System (IFS). Server software is written to run in a UNIX or Windows operating system environment. In other words, servers expect an environment wherein there are directories, subdirectories, and stream files, and not libraries, objects, and members. But in reality, everything in the iSeries native environment may be classified as a library, object, or member (Janson, 2007). In other words, there are many alternative system environments on the iSeries. The iSeries supports and affirms many universes, of which the native environment is only one. The IFS encompasses all storage on an iSeries and is comprised of several directories of which the Root directory (/) is the parent or primary directory. Everything stored on the iSeries is placed in the Root directory. Directories are similar to libraries, i.e. they are used to organize files. However, unlike libraries, directories can have subdirectories. The Root already contains a series of predefined subdirectories that support other common computer system environments. For example, QOpenSys subdirectory operates like UNIX system environment, and QSYS subdirectory encompasses the iSeries native environment. Moreover, each of the separate environments has its own rules regarding storing information and executing programs (Janson, 2007). Data or a program stored in the Root or QOpenSys is stored as a stream file; there are many variations amongst these predefined directories. For example, Root is not case sensitive and QOpenSys is. In addition to this, the IFS also supports a “current directory”. The current directory depicts a current library in the native environment. Whenever a user does not specify a directory, the system uses the current directory, which may be set to the Root or created by the user.

Working in the IFS: Studio’s Remote System Explorer (RSE) provides a tree diagram interface to all the directories and files of IFS. The iSeries native environment supplies IFS commands that allow users to work with any object irrespective of which directory is it stored in. These commands can be implemented from the command line on any menu or screen just like CL commands. Furthermore, prompting will also work on these commands. The workhorse of these commands is WRKLNK, i.e. Work with Object Links. WRKLNK displays a list of object names, i.e. links that are contained within a specified subdirectory. Thus, when issuing the WRKLNK command, the user is required to identify the path to be displayed. For example, to display all the objects within YOURLIBXX, the full IFS path of the Root, QSYS, and YOURLIBXX should be specified. The syntax for the WRKLNK command would be: WRKLNK OBJ (‘/QSYS.LIB/YOURLIBXX.LIB/*’) (Janson, 2007)

In the above command the QSYS and YOURLIBXX need types of LIB, and the file-naming convention of separating the object name and type with a period is required. Additionally, the path is enclosed in single quotes, and the Root is indicated by the first forward slash. Also, a forward slash is used to separate the subdirectory from its parent directory; an asterisk must also be specified. The asterisk entails all the objects within YOULIBXX are displayed. Subsetted lists may be displayed by using asterisk(s) to replace the object links’ names, types, or portions of the name and types. For example, specifying *.file would display only file objects, while specifying ‘/A’ would display object links in the Root directory that have names beginning with A only. The “Work with Object Links” display screen functions exactly like the “Work with Objects Using PDM” screen. Functions are carried out by specifying options to the left of the object links or pressing a function key (Janson, 2007). Server software on an iSeries is usually installed in the Root or QOpenSys directory. Each server requires Web pages to be stored in a certain directory. In this case, the server requires all Web pages to be stored in the following directory path:

QIBM/ProdData/HTPP/Public/HTTPSVR/HTML/
The IP address of the iSeries followed by that path and the file name can be, for instance, given as: 123.456.789.3/QIBM//ProdData/HTPP/Public/HTTPSVR/HTML/coolpage.html

As far as typing mistakes made by the user before entering the address, is concerned, fortunately, “nicknames” for these paths can be established. These nicknames are configured or defined with the WRKHTTPCG command, i.e. Work with HTTP Configuration. Issuing this command displays a screen with all sorted of configuration information. Configuration information contains both required information and the preferences. When the HTTP server starts, the configuration information is read and the HTTP server performs all the necessary set-up tasks that are defined in the configuration information (Janson, 2007). In the above example, the server is required to set-up a “path nickname”. The Pass command assigns a nickname to an existing directory path, and when added to the configuration information, the following Pass command will establish ‘/sample’ as nickname for the server’s Web page path: Pass/sample/* /QIBM//ProdData/HTPP/Public/HTTPSVR/HTML/*

Many commands may be too long to fit on the “Work with HTTP Configuration” screen. To display and edit a line, a 2 is typed in the option area to the left of the line and ENTER is pressed. The “Change HTTP Configuration Entry” screen is displayed with the full command. This Pass command creates a nickname of ‘/’ for the Web page stored the Welcome.html file (Janson, 2007). The Welcome.html file comes with HTTP server software and contains a sample Web page. The Pass command entails the Welcome.html file will be displayed when the URL or IP address is specified. In short, this Pass command establishes Welcome.html as the default home page for the server. Furthermore, Pass command can be added to make “/ sample” as a nickname for the default Web page path. To add a line, a 3 is typed in the option files on the blank line on the “Work with HTTP Configuration” screen, and a sequence number is entered where the new line is to be added in the configuration data. Restarting the HTTP server will establish the user-friendly path name of ‘/sample’ for the path /QIBM/ProdData/HTPP/Public/HTTPSVR/HTML

There are some ways to move a Webpage to the correct directory on the iSeries. For example, SEU could be used to enter the HTML source code into a member, and then the CPYTOSTMF command could be used to move pages to the correct IFS file. However, Studio is infinitely easier. Publishing a page is called Exporting in Studio. For the said example, the StudioPage.html is to be exported to the iSeries directory path of /QIBM/ProdData/HTPP/Public/HTTPSVR/HTML. To do this, first the file StudioPage.html is selected in the Navigator tree. FILE and then EXPORT is clicked on the screen to display the Export window. At the Export window, the Remote File System option is selected and the Next button is clicked. At the Export RFS window, the directory path may be typed in the Folder textbox. The path can also be specified by using the Browse for Folder window, which provides a navigation tree for all external systems identified by WebSphere. In this case, the user needs to expand on the iSeries entry and drill down the path of /QIBM/ProdData/HTPP/Public/HTTPSVR/HTML (Janson, 2007).

Types of files in the IBM System I

Keyed Files: Storage devices physically access the storage media either sequentially or directly. Direct access entails that the storage media or media can go directly to any storage location and read the information stored there. Sequential access means that the storage device should go through all storage location that physically precedes the storage location being sought (Janson, 2007). Tape devices and computer disks provide the same type of access to data records. When accessing a particular data record, however, there needs to be a way to identify that record. That is, each record is allocated a number based on its relative position within the file, called the relative record number. This is the number DFU that has been used to identify records. Relative record numbers can work wonders for CDs with small number of songs, for instance, but with data files containing thousands of records, it is difficult to keep track of each record’s record number. The most common method of identifying records is with a primary or unique key. Earlier, the primary key controlled the physical location of data records. Also, there could be many unique keys but only one primary key. The iSeries allows one to define a single primary key for a physical file. However, the primary key does not control the location of data records. Files may also have secondary keys. These fields do not essentially have a unique value for each record. For example, the student file may have the field “eye color” as a secondary key. Finding the file based on a particular eye color will not result in finding a single record, i.e. the search would result in multiple records. Thus, non-unique secondary keys cannot be used for identifying a particular record (Janson, 2007). Sequential files store records in a sequential manner, one after another in key order. Access to a sequential file is limited to the sequential access method, i.e. each record is processed in the order in which it is placed in the file. Such type of files can support access to the file in only one key field order. This is the main reason why sequential organization is never used. Furthermore, keyed sequential files allow each record to be uniquely identified. However, retrieving a specific record means that each record is read and the key field’s value is checked. In an indexed sequential file, each record contains a unique value for the key, records are grouped into blocks, and each block contains records for specific range of key values. Within the block, the records are stored in a sequential manner in key order; blocks do not have to be in key order. The main reason behind this organization is the concept of index, which is a file that contains an index record for each block of data records. Additionally, the index record contains two major pieces of information: the highest key value contained within the block, and the starting storage location/ address of the block. Moreover, the index records are stored in key order (Janson, 2007). Also, the index contains only the key fields and the storage location. While accessing an indexed sequential file for a particular record, the first step is to sequentially search the index. Each index record’s key value is checked against the key value that is being searched for. If the index value is greater than the value being searched for, the block containing the data record is found. The system then goes directly to that block as indicated by the storage location in the index record, and reads each data record sequentially in the block, looking for the accurate key value. Space utilization in the system memory can be improved by using a more complicated calculation called a hashing routine. There are several types of hashing routines but what characterizes them all is that they generate a smaller range of addresses. A typical example is the division/remainder method wherein the number of storage location that will be in the file will be determined. Then, the largest prime number is chosen that is less than the number of records to be stored. This method is based on the fact that the number of possible remainders generated by division is equal to the divisor (Janson, 2007). Each operating system or file management system implements the file organizations and access procedures, in a unique manner. Also, they generally have their naming conventions. For instance, the iSeries supports access to files in the form of arrival sequence order. That is, a user or program can access records in the order in which they arrive into a file. As far as access is concerned, arrival sequence is similar to sequential access. However, the iSeries does not store records in arrival order. It employs sophisticated algorithms that calculate the most efficient utilization of available space and resources and may even scatter records across physical storage devices. The iSeries provides arrival sequence access through an access path. This access path can be thought of as an index. For example, an arrival sequence access path that supports only sequential access to a file could simply consist of a list of storage locations. To access the file, the access path would be searched sequentially and the records read directly (Janson, 2007).

Logical Files: A Database Management System will usually provide three ways of viewing a database, i.e. physical view, global view, and the ability of building multiple user views of the data. Because of the iSeries’ single level approach to storage, the physical view of data is mostly hidden from the iSeries. One need not know the disk, track, or sector on which data is stored. Additionally, any specific location addresses or indices are used internally by the DBMS and are not readily available to the user. However, the iSeries does not offer a limited physical view of the data, with the DSPPFM command, along with some capability to manipulate the physical organization of the data, with the RGZPFM command. DDS does, however, provide a global view of all the data as files as well as it allows construction of individual views. This is obtained through both logical and physical files. Physical files contain the definition of individual fields within the file and include an access path to the data (a key) and the data itself (Janson, 2007). These definition “pieces” taken as a whole provide a global view of all data on the iSeries. Users often want to see data in a form other than how it is organized. The iSeries employs another type of object called a logical file that provides an alternative access to data in physical files. Like physical files, logical files contain file definitions. However, logical files contain only field definitions and an access path, and no data is stored in a logical file. Since logical files do not contain any data, they must reference data already defined in a physical file. But a logical file can reference field from many physical files.

Through logical files, unique combinations of data seem to exist without duplication of any data (Janson, 2007). Logical files are defined with DDS and are created by compiling the member of the source physical file that contains the logical file’s DDS definition, similar to physical files. To create a logical file, first a member with a type of LF is created, and then the logical file’s DDS source definition is entered. And finally, the DDS is compiled to create the logical file. Since logical files do not contain any data, they simply point to data contained in physical files (Janson, 2007). There are several benefits offered by logical files. Firstly, logical files can be used to easily generate customer reports. This relieves the programmer of having to write and maintain large reporting system. The programmer can greatly reduce the number of report programs through logical files. The specialized access provided by logical files to physical files also simplifies program input and output logic. Because logical files are defined externally, they can also be used by many programs. Without logical files, every program would have to contain the duplicate program code to access the separate physical files. Lastly, logical files do not create any duplicate data (Janson, 2007).

Reference List

Janson, R. (2007). Introduction to the iSeries and Websphere Studio Client. USA: Shroff/ Janson Publishers.

Soltis, F.(2001). The Inside Story of the IBM iSeries. Colorado, USA: 29^th Street Press.

Click Here To Order Now!