What is IBM AS400?
The AS400, also known as IBM iSeries and now IBM i, is a midrange computer system developed by IBM. Launched in 1988, AS400 was designed for businesses requiring a reliable, secure, and scalable computing platform. The AS in AS/400 refers to ‘Application System’ for those unfamiliar with this technology because it relies on applications rather than processors.
The “AS400/iSeries”, also known as IBM iSeries, was a revolutionary computer system launched by IBM in 1988. It gained widespread popularity among businesses of all sizes globally due to its reliability, security, and ease of use.
Early AS/400 system were compact and powerful for their time, often housed in a single cabinet compared to room-sized mainframes of the era. This made them ideal for smaller businesses that lacked space for traditional mainframes.
Early AS400s were notable for the following key features:
Integrated design: The AS/400 simplified setup and maintenance by combining processing power, storage, and I/O into a single unit.
RPG programming language: A user-friendly language specifically designed for business applications; RPG (Report Program Generator) made developing software easier for companies.
Menu-driven interface: Even non-technical users could use the AS400 because of its simple menu-driven interface.
Multi-user support: Businesses could simultaneously share resources and improve efficiency using the AS400.
Reliability and security: Known for its rock-solid reliability and robust security features, the AS400 was a trusted platform for critical business data.
The AS400 experienced widespread adoption across diverse industries, playing a pivotal role in transforming essential business functions. In manufacturing, the AS400 became a linchpin for facilitating inventory control, production planning, and quality control. Retailers employed the AS400 for point-of-sale systems, inventory management, and the establishment of customer loyalty programs, contributing to streamlined and efficient operations. Finance experienced integrating the AS400 into the workflows of banking professionals and financial experts, serving essential functions like account management, transaction processing, and fraud detection. Healthcare institutions, including hospitals and clinics, seamlessly incorporated the AS/400 into their operations, leveraging its capabilities for managing patient records, billing, and scheduling. The widespread adoption of the AS400 across these industries underscored its versatility and effectiveness in addressing diverse business needs.
Although the AS400/i-series has evolved substantially since its inception, its fundamental tenets of reliability, security, and ease of use remain relevant today. Many businesses continue to depend on the AS400 system for critical business operations, and IBM remains committed to advancing and modernizing the platform for the future.
The IBM Application System/400 popularly known as AS/400 is a family of mid-range business computing systems, that supersedes IBM’s highly successful System/3X family. The AS/400 is available in three different types the 9402, 9404, and the 9406.
The AS/400 systems exclusively use the IBM Operating System/400 (OS/400). It is a multi-user operating system that works with the Licensed Internal Code (LIC) instructions to implement the functions that are basic to the AS/400 architecture. OS/400 can perform tasks under direct control of both the user and an application program.
The AS/400 system differs from the traditional systems in several ways. They offer more compatibility across the product line since only one operating system and architecture is used consistently across the entire family. The system offers very high performance compared to the earlier System/3X computers. This is achieved by a combination of faster processors, extended storage and improved fixed disk systems. The software architecture is different from that of more traditional systems. Implementing functions such as security, database and communications in microcode, and providing a one-piece operating system resulted in improved efficiency, consistency and simplicity.
Now, to take a look into the highlights of the system
The IBM Application System/400 popularly known as AS/400 is a family of mid-range business computing systems, that supersedes IBM’s highly successful System/3X family. The AS/400 is available in three different types the 9402, 9404, and the 9406.
Currently, here at Minnesota State University, Mankato, the Computer Services is supporting a dual processor IBM AS/400 9406 model D80, that contains 192 Megabytes of primary memory and 7.1 Gigabytes of mirrored secondary storage.
The AS/400 systems exclusively use the IBM Operating System/400 (OS/400). It is a multi-user operating system that works with the Licensed Internal Code (LIC) instructions to implement the functions that are basic to the AS/400 architecture. OS/400 can perform tasks under direct control of both the user and an application program.
The AS/400 system differs from the traditional systems in several ways. They offer more compatibility across the product line since only one operating system and architecture is used consistently across the entire family. The system offers very high performance compared to the earlier System/3X computers. This is achieved by a combination of faster processors, extended storage and improved fixed disk systems. The software architecture is different from that of more traditional systems. Implementing functions such as security, database and communications in microcode, and providing a one-piece operating system resulted in improved efficiency, consistency and simplicity.
Now, to take a look into the highlights of the system
The IBM Application System/400 popularly known as AS/400 is a family of mid-range business computing systems, that supersedes IBM’s highly successful System/3X family. The AS/400 is available in three different types the 9402, 9404, and the 9406.
Currently, here at Minnesota State University, Mankato, the Computer Services is supporting a dual processor IBM AS/400 9406 model D80, that contains 192 Megabytes of primary memory and 7.1 Gigabytes of mirrored secondary storage.
The AS/400 systems exclusively use the IBM Operating System/400 (OS/400). It is a multi-user operating system that works with the Licensed Internal Code (LIC) instructions to implement the functions that are basic to the AS/400 architecture. OS/400 can perform tasks under direct control of both the user and an application program.
The AS/400 system differs from the traditional systems in several ways. They offer more compatibility across the product line since only one operating system and architecture is used consistently across the entire family. The system offers very high performance compared to the earlier System/3X computers. This is achieved by a combination of faster processors, extended storage and improved fixed disk systems. The software architecture is different from that of more traditional systems. Implementing functions such as security, database and communications in microcode, and providing a one-piece operating system resulted in improved efficiency, consistency and simplicity.
The AS/400 is IBM’s new generation of full-range, multi-user, and general-purpose computer system. Although it is generally considered a mid-range system, the AS/400 is a mid range in price and size only. The power and functionality of the AS/400 are far more advanced than its mid-range counterparts, such as System/36 and System/38. The higher-end models of the AS/400 offer size and power comparable to the mainframes, although not with respect to cost. AS/400 is reputed for its ease of use and high level of system integration that includes the state-of-the-art system architecture, object oriented technology, and integrated database. More recently, the AS/400 has made significant inroads into networking, client/server computing, internet, intranet, and Web with the release of new system models, new version of operating system, and software designed for the net generation. All in all, the AS/400 has become the server of choice as the in the enterprise-wide internet, intranet, and client/server environment. The system architecture of the AS/400 provides many distinctive features that form this revolutionary system. These features include: High level of integration Object orientation Relational and integrated database Data and program independence Single-level storage SAA conformance
Client/Server technology Domino groupware enabling Internet, Intranet, and Web enabling SAP enabling e-business solutions and the net generation Year 2000 Ready Solutions 1.1.1 High Level of Integration One of the most distinctive features of the AS/400 system architecture is its high level of system integration. Unlike traditional systems that generally separate their database and application development tools from their operating system, the AS/400 offers a full-fledged operating system that integrates most aspects of the machine and user interface. On the AS/400, the work management, storage management, database, control language, query management, security management, and application development tools such as Data File Utility, Source Entry Utility, Programming Development Manager, and Screen Design Aid are all preloaded and integrated into the AS/400 operating system. This high level of integration offers the following advantages: It provides a single, consistent interface to all the system functions. It greatly reduces the cost of the system. For a traditional system, users frequently must purchase the operating system, storage management, database, and application development tools separately with significant add-on prices. For the AS/400, users need only pay for the hardware and the operating system. The database and most other utilities are preloaded and integrated into the operating system. All are shipped with the operating system. It greatly reduces the need for technical support, which has been traditionally provided by systems programmers, database administrators, and technical support specialists. The high level of integration means that the operating system now supports the system and management functions of the database and utilities, which are now part of the operating system’s structure.
Object Orientation An object-oriented approach is fundamental to the system architecture of the AS/400. On traditional systems only compiled programs are called objects. This is not true on the AS/400. In addition to compiled programs, many other items are also objects on the AS/400. In fact, nearly everything on the AS/400 is an object, and objects are differentiated from one another by their names and types.
Each type of object has unique characteristics and purposes within the system. Among the major types of objects are programs, files, libraries, commands, user profiles, job descriptions, folders, subsystems, job queues, message queues, and output queues. AS/400 object management provides functions necessary to group objects, to differentiate object types, and to locate and retrieve objects needed for processing. Object management keeps track of files, programs, libraries, queues, and all other types of objects on the system. Object oriented architecture offers users flexibility in performing system and programming functions on the system. 1.1.3 Relational and Integrated Database The AS/400 database, named DB2/400, is a relational database. It is one of the few systems that provides an integrated database that is part of the operating system. There is no need to purchase, install, and maintain a separate database. Some advantages of an integrated database are standardization of data definitions and structures, lower initial and maintenance costs, automatic data management and processing, and improved productivity. The database model of DB2/400 is relational. However, unlike other relational database management systems, which owe their structure to a collection of tables and views, DB2/400 masks the terms commonly used in other relational databases (i.e., tables and views) and, instead, uses the terms of physical files and logical files to accommodate the programming requirements of the system. Despite the difference in the terminology, DB2/400 is fully relational. It embodies the structure and functions of a relational database management system.
Data and Program Independence On most traditional systems, programs are tied very closely to the way the data are defined and stored on the system. Record layouts of the files (i.e., record and field specifications) are defined in the programs that process the files. When file layouts are changed, such as by adding new fields to the file, all the programs that use the file must be changed and recompiled. The AS/400 database management system, on the other hand, separates data definitions from programs by offering externally described files in addition to the traditional program described files. An externally described file is defined by a data definition that exists outside the programs. Data Description Specifications (DDS) are used for describing files externally. There are several advantages to making data independent from programs: It reduces the need for file and program maintenance. It improves data integrity. It increases programmer productivity.
Single-level Storage AS/400 storage management implements a virtual storage scheme through an advanced structure called single-level storage. The term virtual storage refers to a technique for managing a limited amount of main memory and a much larger amount of lower-speed disk storage in such a way that the distinction is largely transparent to users. On the AS/400, all disk storage is regarded by the operating system as virtual memory. No distinction is made between disk storage and main memory. All storage appears to be one homogeneous sea of main memory. Unlike most traditional systems that utilize virtual storage, the AS/400 creates and maintains only one address space for its objects. Other virtual storage implementations must create and maintain separate address spaces and often treat programs different than they treat data. The simplicity of single-level storage results in a consistent and more complete virtual storage system than most other systems.
Systems Application Architecture (SAA) Conformance Systems Application Architecture (SAA) is a
blueprint published by IBM to provide open communications architecture for developing consistent applications across IBM’s major computer systems. SAA utilizes an extensive set of software interfaces, conventions, and protocols that provides a framework to guide users building open integrated information systems. The three key elements of SAA are: Common Communications Support (CCS): a set of standards for connecting and communicating computer systems. Common Programming Interface (CPI): describes the languages to be used by developers to build SAA compliance applications. Common User Access (CUA): a set of screen standards used for interacting between applications and users. The following table shows the three major systems covered by SAA: System Operating System Mainframe MVS/ESA and VM/ESA AS/400 OS/400 PC OS/2 The AS/400 fully supports SAA. It ensures horizontal and vertical growth and enhances the customer’s investment in application software.
Client/Server Technology Client/server technology is the single most irresistible movement in the computer industry in recent years. It represents a new concept and technology that links computers from different platforms. In a client/server environment, one or more computer systems function as servers that provide services to their client systems. The services offered by server systems include administration of data retrieval and update, data processing and computing, and distributed data management. Client/server computing links the intuitive graphical user interface of client computers with the processing power and sophisticated database of a server computer. It allows end users from client systems such as PCs to access data and request services from a server such as the AS/400. With its many advanced client/server hardware and software features, the AS/400 is very well positioned in the client/server market segment. See Part 4 for more details about client/server technology on AS/400.
Domino Groupware Enabling Groupware is a software that allows an user to work together with a group of other people. The groupware enables you to: Create database to be used by a group of people working on a common project. Send e-mail to individuals and groups in an organization. Collect data from individuals in a group or in an organization. Combine data, spreadsheets, graphics, text, and tables from different systems and sources. Lotus Notes/Lotus Domino, or simply called Notes and Domino, arguably, is the most widely used groupware in the industry. Lotus and Domino go hand in hand, and use computers all connected together in a Client/Server and network environment. The clients are individual computers (i.e., PCs or workstations) that are connected together by a server acting as a central nerve center for the Notes network. The Notes’ server is named Lotus Domino or simply called Domino. In other words, Lotus Notes is the client product that runs on a variety of workstations, and Lotus Domino is the server product that runs on a variety of server platform. Server Domino integrates multiple Notes’ clients. AS/400 is enabled to be the server in the Notes network. It is a full-fledged Lotus Domino server that allows multiple clients to be connected and administer by a single AS/400 server. The AS/400 Domino server is named Domino for AS/400. It combines the strength of AS/400 and Lotus Notes to allow the integration of Domino database and DB2/400 database, flexible network communications, mature system administration, and proven security
Significance of the Study
Externally Described Files
An externally described file in IBM i (Formerly AS/400 or iSeries) refers to a file that has its structure or format defined outside the program that uses the file and it is described to the OS/400 system at the field level. In an externally described file, the compiler retrieves the description of the fields from an external file-description which was created using DDS or SQL commands. Therefore, you do not have to code the field
descriptions on input and/or output specifications within the RPG source member.
The description includes information about where the data comes from (database or device), and field description and their attributes. The file must exist and be accessible from the library list before you compile the program
Externally Described Files
An externally described file in IBM i (Formerly AS/400 or iSeries) refers to a file that has its structure or format defined outside the program that uses the file and it is described to the OS/400 system at the field level. In an externally described file, the compiler retrieves the description of the fields from an external file-description which was created using DDS or SQL commands. Therefore, you do not have to code the field
descriptions on input and/or output specifications within the RPG source member.
The description includes information about where the data comes from (database or device), and field description and their attributes. The file must exist and be accessible from the library list before you compile the program.
Externally described files offer the following advantages:
Code efficiency in RPG/400 programs. If the same file is used by many programs, the fields can be defined once to the OS/400 system and used by all the programs. This practice eliminates the need to code input and output specifications for RPG/400 programs that use externally described files.
Requires less maintenance when the file’s record format is changed. You can often update programs by changing the file’s record format and then recompiling the programs that use the files without changing any coding in the program.
Improved documentation because programs using the same files use consistent record-format and field names
Improved reliability. If level checking is specified, the RPG program will notify the user if there are changes in the external description.
Defining Externally Described Files
When defining an externally described file in fix format you have to provide file format as E whereas in free format you can use DISK(*EXT).
The information in this external description includes:
File information like file type, attributes, access method (by key or relative record number)
Record-format description, which includes the record format name and field descriptions (names, locations, and attributes).
Types of files that can be described externally in a RPGLE program
Physical files (PF): A Physical file or PF is a data file in IBMi which contains actual data that is stored on the system and its description.
Logical files (LF): A logical file contains a description of records of a Physical File. They do not contain actual data. It is a view or representation of one or more PFs. A LF cannot exists without a PF.
Display files (DSPF): Display files used in IBMi to define the layout of the screens for interactive programs. It allows developers to design user interfaces, specifying screen formats, Input fields and output areas.
Printer file (PRTF): Printer file is used to define the format of the output intended for printing or to show reports to user. PRTF specify the arrangement of text and data on printed documents and ensures proper format, presentation, and alignment.
Flat Files
A flat file is a special type of physical file that do not have any hierarchical structure or multiple records formats. It consists of a single field with long length (RCDLEN) which is defined at the time of creation. The maximum length of RCDLEN can be 32766 bytes.
Flat files have no field definitions and no indexes can be built off of them. In a flat file the file name, record format & field name are same.
We can write, read, update, delete the Flat file. Reading and deleting can be done normally whereas update and write operations required the use of Data Structures.
Usage
Flat files are mostly used as Output file to copy the data to Stream file on IFS.
Flat files are used to store data for Pre-Runtime Arrays.
Creating a flat file.
Creating a flat file is same as creating Physical File.
It is very easy to declare either in command line or even in DDS in STRSEU editor.
CRTPF (Library/FlatFileName) RCDLEN(50)
Figure 1 : Creating A Flat file
Figure 2 : Creating A Flat file
When we do DSPFFD (Display File Field Description) on a flat file. We can see that the file
name, record format name & field name is same for flat file. The record length provided at the time of creating flat file becomes its field length
Figure 3 : DSPFFD On Flat files
Operations on a flat file:
Reading a Flat File Using RPGLE PGM
Figure 4 : Reading A Flat file
Line 2 & 3 : Included a flat file “FLATFILE” in program by declaring it with usage as input and PREFIX W_ to make field name as w_flatfile to the field and renamed the record Format from FLATFILE to Ffile with RENAME.(Note: We need to RENAME the record format to ignore compile-time severity 40 error
*RNF2109 And we need to add PREFIX to the field, otherwise, we will again get compile-time severity 30 error *RNF7503)
Line 4 and 5: are comment.
Line 6: We have defined a variable FFvar with the same length as flat file RCDLEN.
Line 9: We have set the pointer on the start RRN value on the flat file.
Line 10: Read the record of a flat-file from start.
Line 11 to 15: we have started a do-while loop till end of file is reached.
Line 12: The records from flat file fields is assigned to the variable FFVar.
Line 13: Displaying the data in FFvar.
Line 14: Read the next data from flat file.
Line 17: Set the last record indicator = *ON.
Writing data in a Flat File Using RPGLE PGM
Figure 5: Writing data into a flat file
Line 2 & 3 : Included a flat file “FLATFILE” in program by declaring it with usage as input, output, update & delete and PREFIX W_ to make field name as w_flatfile to the field and renamed the record Format from FLATFILE to Ffile with RENAME.
Line 6 : Declare a variable FFvar with same length as RCDLEN.
Line 12 : Initialize the FFvar with the data.
Line 13: Assigned the value of FFVar to the flat file field w_Flatfile.
Line 14: Write the data on record format FFile using WRITE Opcode.
Line 17: Set the last record indicator = *ON
Chain and Update on Flat File Using RPGLE PGM
Figure 6 : Chain and Update on a Flat file using RPGLE Program
Figure 7 : Data in Flat file before chain and Update
Figure 8 :Data in Flat file after chain and Update
Line 2 & 3 : Included a flat file “FLATFILE” in program by declaring it with usage as
input, output, update & delete and PREFIX W_ to make field name as w_flatfile to the field and renamed the record Format from FLATFILE to Ffile with RENAME.
Line 5 : Declare a variable UpdVar with same length as RCDLEN.
Line 8 : Initialize the UpdVar with the data.
Line 9: Set the data pointer to 1 RRN with Chain operation on flat file.
Line 10 – 13: this is an If-Elseif block which get executed when the chain operation has found data in flat
file.
Line 11 : Assigns the value in UpdVar to w_Flatfile field in flat file.
Line 12: Update the flat file using UPDATE opcode and record format Ffile.
Refer Figure 7 and Figure 8 for data in Flat file before and after Chain-Update operation.
Line 15: Set the last record indicator = *ON
Chain and Delete on Flat File Using RPGLE PGM
Figure 9: Chain-Delete on a flat file using RPGLE program
Line 2 & 3 : Included a flat file “FLATFILE” in program by declaring it with usage as input, output, update & delete and PREFIX W_ to make field name as
w_flatfile to the field and renamed the record Format from FLATFILE to Ffile with RENAME.
Line 5 : Declare a variable DelVar with same length as RCDLEN.
Line 8 : Initialize the DelVar with the data.
Line 9: Set the data pointer to 1 RRN with Chain operation on flat file.
Line 10 – 13: this is an If-Elseif block which get executed when the chain operation has found data in flat
file.
Line 11 : Assigns the value in DelVar to w_Flatfile field in flat file.
Line 12: Delete the flat file record using DELETE opcode and record format Ffile.
Refer Figure 10 and Figure 11 for data in Flat file before and after Chain-Delete operation.
Line 15: Set the last record indicator = *ON
Figure 10: Data in flat file before chain delete