AS-400 All in One

AS/400 System Overview Chapter 1
Major Characteristics of AS/400

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
Operating System/400
The Integrated Operating System: OS/400
Javas Integration into the AS/400 System
AS/400 Advanced Series

A Full Range of Product Lines
Major Traits of the AS/400 System Units
AS/400e Series and e-business Solutions

e-commerce and e-business Solutions
AS/400e Series at a Glance
Review Questions
AS/400 1 Venkat BAS

Major Characteristics of AS/400
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 systems 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. Objectoriented
architecture offers users flexibility in performing system and programming functions on the system.
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
AS/400 2 Venkat BAS

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.
On the AS/400, main memory is called main storage. Disk storage is called auxiliary storage. You may
also hear disk storage referred to as DASD (direct access storage device).
Many other computer systems require you to take responsibility for how information is stored on disks.
When you create a new file, you must tell the system where to put the file and how big to make it. You
must balance files across different disk units to provide good system performance. If you discover later
that a file needs to be larger, you need to copy it to a location on disk that has enough space for the
new, larger file. You may need to move other files to maintain system performance.
The AS/400 system takes responsibility for managing the information in auxiliary storage. When you
create a file, you estimate how many records it should have. The system places the file in the best
location for good performance. In fact, it may spread the data in the file across multiple disk units.
When you add more records to the file, the system assigns additional space on one or more disk units.
The system uses a function that is called virtual storage to create a logical picture of how the data
looks. This logical picture is similar to the way we think of the data. In virtual storage, all of the
records that are in a file are together (contiguous), even though they may be physically spread across
multiple disk units in auxiliary storage. The virtual storage function also keeps track of where the most
current copy of any piece of information is-in main storage or in auxiliary storage.
Single-level storage is the unique architecture of the AS/400 that allows main storage, auxiliary storage,
and virtual storage to work together accurately and efficiently. With single-level storage, programs and
system users ask for data by name, not by where the data is located. Now lets move one more step up
the technical ladder for a little more information! Kenneth
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 IBMs major computer
AS/400 3 Venkat BAS

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
customers 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 4 Venkat BAS

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.
Internet, Intranet, and Web Enabling
Internet is the world-wide network of networks that are connected to each other sharing
information. Intranet is an organizations internet network that uses internet tools within the
organization. World Wide Web, or simply called WWW or Web, is a mesh of interconnected
servers and clients that use the same standard format for creating documents (HTML) and
accessing documents (HTTP).
Internet technology is fundamentally changing the way organizations do business. AS/400
provides internet, intranet, and Web support such as:
TCP/IP (Transmission Control Protocol/Internet Protocol) and LAN (Local Area Network)
networking capabilities.
Internet Connect for AS/400 enables you to put together internet and intranet solutions in an
organization. AS/400 is enabled to be used as a Web server. DB/2 WWW can deliver data to users
over the internet or intranet. The AnyMail server provides an integrated e-mail service between an
AS/400 internet server and Lotus Notes on various client workstations. The IBM Internet Connect
Secure Server (ICSS) for AS/400 supports the Secure Sockets layer (SSL) protocol for securing
World Wide Web communications between an AS/400 server and Web browsers.
In the system area, AS/400e series and advanced series with Internet Connect for AS/400 delivers
the simplicity and ease of use in an internet and/or intranet environment. Firewall for AS/400
provides security and data integrity in the internet environment where AS/400 is the internet server.
It controls the access and flow of information between a secure network and an unsecured
network.
SAP Enabling
SAP AG, is the third largest software company worldwide. It is the worlds leading
provider of client/server business applications. Its suite of client/server data processing products,
called SAP R/3, is based on the concept of combining all the business activities and technical
processes that are used within an organization into a single, integrated software. SAP R/3 has
been installed in most of the Fortune 500 companies, and has become a software standard in
many industries.
SAP AG and IBM AS/400 Division have been working together to provide business reengineering
and the ultimate business management solution for organizations. Both companies
are worldwide leaders in their respective fields. AS/400 is the leading commercial business system
with over 275,000 systems installed in over 140 countries. SAP AG is the leading provider of
integrated business applications in more than 4300 companies and is represented in 41 countries.
The strengths of both AS/400 and SAP R/3 system complement each other to provide a complete
business solution. The SAP R/3 System on AS/400 provides user interface (presentation clients),
application logic (application server), and data management (database server). It allows SAP R/3
to port on AS/400, incorporating AS/400 existing function into R/3.
e-businesss Solutions and Net Generation
AS/400 5 Venkat BAS

The term, e-business solutions, is used by IBM to emphasize the information system
technologies that integrate internet, intranet, web, electronic network, client/server, and traditional
data processing capabilities for companies to conduct their business in a the net generation.
Please note that the first letter of e-business e is not supposed to be capitalized. AS/400e series
is an integrated system designed to reduce complexity and provide faster development of e-
business applications. It offers a series of new system models, including AS/400e server, such as
Models 150, 170, S10, S20, S30, and S40, and AS/400e system, such as Models 600, 620, 640,
and 650. These models have expanded their integrated environment to embrace todays newest
Web technologies.
AS/400e series with the latest release of the AS/400 new system models, the new release
of AS/400 operating system, and a variety of new Web enabled software offering including Domino
for AS/400, DominoGo (formerly Internet Connection Server), Java, Net.Commerce, and Net.Data,
makes it easier for an organization to conduct its business in the net generation.
Year 2000 Ready Solutions
All AS/400 system models running on AS/400 operating system, OS/400, are Year 2000 ready.
From its cutting-edgy applications to its advanced technology, AS/400 provides year 2000
interfaces that are fully integrated and tested.
For any organization that uses application software, such as Accounts Payable, Inventory Control,
and Cost Accounting, chances are that these software rely on accurate date calculation. The
organization must ensure that its hardware, operating system, and applications are Year 2000
ready. If that organization currently runs on AS/400, it is ready for Year 2000 on all counts.
AS/400 operating system incorporates flexible ways to handle dates and use dates in calculation.
In addition, AS/400 and IBM business partners provides a number of tools and application
software designed to assist organizations with their Year 2000 transformations. These products
provide AS/400 users and developers with a standard set of system calls for date retrieval, date
arithmetic, date format conversions and other routines. An impact analysis tool and a conversion
tool, SEARCH2000 and BYPASS2000, developed by an IBM business partner, assist in finding
dates, identifying their formats, and converting old date formats to new formats.
Operating System/400
The Integrated Operating System: OS/400
An operating system is a set of software routines that directs the operation of the computer. It
manages the hardware resources and executes tasks under the control of software or interactive
commands. All AS/400 models are supported by a single, integrated operating system called
Operating System/400 (OS/400).
OS/400 is a preloaded, integrated operating system for all models of the AS/400. The
single, integrated system approach makes it easy for AS/400 users to upgrade their models within
the system unit and to standardize their software development. For users who have a System/36
or System/38, OS/400 provides migration capabilities to the AS/400.
In addition, OS/400 uses the blueprints and principles of Systems Application Architecture (SAA).
AS/400 6 Venkat BAS

It allows support for many application programs that have already been developed on other
operating systems such as MVS/ESA. It also provides features for connecting the AS/400 with
other IBM systems and for sharing data and documents. OS/400 controls the operating system
functions, manages system resources, controls security, handles messages, supports database
management, provides work management, and controls job processing. The key components and
functions of OS/400 include Work Management controls job processing. This allows multiple
interactive and batch jobs to run simultaneously in different subsystems and job queues. It also
schedules jobs and governs input and output spool functions.
Database Management facilitates the retrieval, addition, and updating of data on the
AS/400 database. It adopts the relational model for a database management system. This allows
users to use physical files as well as logical files. It also permits data definitions to be independent
from application programs and, thus, ensures greater data integrity. Communications Support
offers a wide range of communications and networking capabilities. It allows the AS/400 to
communicate and transfer data among AS/400 machines, mainframe systems, and PCs.
Control Language (CL) provides CL commands and CL programs that allow users to perform
various system, operational, and programming functions.
Application Development Support provides utilities such as Source Entry Utility (SEU),
Data File Utility (DFU), Programming Development Manager (PDM), and Screen Design Aid
(SDA). They are collectively called the Application Development Tools. These utilities increase the
productivity of application programmers in developing and maintaining application software.
System Operation Support allows operators to perform work from the system workstations using
menus and CL commands.
Message Handler controls communications between the users, between users and the operating
system, and between users and programs.
System Security polices system access, manages object authorizations, and protects data and
other system resources from unauthorized access.
Online Help and Index Search allows users to obtain instant information through the use of Help
Key, command prompting, and Index Search.
Object Management provides the functions necessary to create objects, to maintain objects, and
to locate and retrieve objects for processing in accordance with the names, types, and attributes
specified by users.
Storage Management performs functions necessary for placing objects into storage, for retrieving
them from storage, and for updating objects in storage. It also allows users to compress storage
and reclaim storage space.
Query Management provides a query utility that enables users to retrieve data from the database
and to create and format reports quickly and efficiently.
Javas Integration into the AS/400 System
OS/400 enables integrated network computing, object-oriented portability, and Web technology to
open gateway for Java functionality. The latest release of AS/400 operating system provides an
integrated Java compliant implementation that includes Virtual Machine (JVM). JVM is
implemented under the machine interface (MI), the AS/400 Developer Kit for Java, and the AS/400
Toolbox for Java.
Java has become predominant programming language for Web development and network
AS/400 7 Venkat BAS

computing. It can be used for stand-alone applications or client/server applications running over
the internet. Remote Method Innovation (RMI) is built into the AS/400 Java software and can be
used to communicate with AS/400 Toolbox for Java. Only the client part of the client/server
applications need to be written. Since the client application programs are written in Java, they can
run virtually on any client platform (i.e., PC or UNIX) that communicates with the AS/400 server
Client application programs can be developed using IBM Visual Age for Java. The Visual Age for
Java software is delivered with OS/400 license.
AS/400 Advanced Series
A Full Range of Product Lines

The AS/400 system units consist of a family of models that forms a full range of product
lines. Since its introduction in 1988, these modes have been revamped many times. They have
evolved from the original B models to C, D, E, and F models, with each new generation of models
becoming more powerful and versatile than its predecessor.
As part of the client/server product strategy, the AS/400 product lines were overhauled.
This new family of products, called the AS/400 Advanced Series, include three major lines:
Advanced Portable Model, Advanced System Models, and Advanced Client/Server Models.
Advanced Portable Models
AS/400 Advanced Portable models P02 and its subsequent P series. As the name implies,
it is a small, portable, and highly mobile computer. The portable system is targeted toward AS/400
users who operate in a single-user environment and who need greater flexibility and mobility.
Advanced System Models
The AS/400 Advanced System Models are the first to offer IBM Powerful 64-bit RISC PowerPC AS
microprocessors. The Advanced System models are optimized for business transactions in a
batch mode as well as for an interactive server environment. All Advanced System models offer
various processor capacities, which are identified by different feature codes. This allows
customers to choose the different features from the same model based on their speed and
performance requirements.
Advanced Server Models
The AS/400 Advanced Server Models are the core of IBMs new client/server hardware solution.
These models are specifically designed and built for client/server computing. They use different
processors and microcode designed to meet the special requirements of the client/server
environment.
Major Traits of the AS/400 System Units
The AS/400 system units have many unique traits. Some of the more important traits include All
AS/400 models use the same operating system, OS/400. All AS/400 models use the same
database, DB2/400.
All AS/400 models use the same basic utilities, including PDM, SEU, DFU, and SDA.
AS/400 8 Venkat BAS

AS/400e Series and e-business Solutions
e-Commerce and e-Business Solutions

The latest industry buzz is the development of Web applications, such as e-commerce, internet,
and intranet that integrate an organizations in-house systems and database with Web Browser
interfaces. The introduction of new AS/400e series is intended to position AS/400 as the server
platform for e-commerce and to provide integrated solutions for the net generation. The term, e-
business solutions, is used by IBM to depict the solutions that integrate operating system,
database, network, software, and applications in a single system platform such as AS/400.
Please note that the first letter of e-business e is not supposed to be capitalized.
AS/400e series are the collection of new models that embrace latest internet and web
technologies in order to provide e-business solutions to organizations to conduct their business in
the client/server environment. The solutions combine the latest internet, intranet, web, and
client/server features with the traditional information system technologies that allow organizations
to conduct their business competitively and effectively.
Programming Development Manager Chapter 2
With the programming development manager (PDM), you can perform the following functions:
. Work with libraries

. Work with objects
. Work with members
. Search for a character string or a numeric string
. Work with user-defined options
. Change system default values
PDM also gives you access to other objects on the AS/400* system so that you can use the
following utilities in the Application Development ToolSet/400 licensed
program:
. Source entry utility (SEU)

. Data file utility (DFU)
. Screen design aid (SDA)
. Report layout utility (RLU)
. File compare and merge utility (FCMU)
. Interactive source debugger (ISDB)
Objects, Libraries, Files, and Members in the AS/400 System
AS/400 9 Venkat BAS

Objects
are the basic unit with which commands perform operations in the AS/400 system. An object is a
named unit that consists of a set of features that describes the object, and a value. The features
of an object include its name, type, size, the date it was created, and a text description. The value
of an Object is the collection of information stored in the object. The value of a program, for
example, is the executable code that makes up the program. The value of a file is the collection of
records that make up the file. There are many types of objects. For example, the object type of a
library is *LIB, the object type of a file is *FILE, and the object type of a program is *PGM.
library
is a special type of object (object of type *LIB) that is used to group related objects. A library,
therefore, is a directory to a group of objects. There are only two types of libraries: *PROD
(Production) and *TEST (Test). Every AS/400 system has a system library named QSYS that is
provided in the
OS/400* operating system to contain system-oriented objects. QSYS is a large library that points
to all the system-oriented objects.
File
is an object of type *FILE that has an attribute that describes the type of the file. For example, a
source physical file has an attribute of PF-SRC, a data file has an attribute of PF-DTA, and a
printer file has an attribute of PRTF. Physical files and logical files both contain members.
Member
is a subset of records in a physical file (PF-SRC or PF-DTA). Each member conforms to the
characteristics of the file. You can define the type of a member, or select a type used with PDM
commands.
Starting the Programming Development Manager
You can start the programming development manager (PDM) from the AS/400 Main Menu or by
typing the STRPDM command on the command line. You can also start PDM by typing any of the
following commands on the command line:
. WRKLIBPDM
. WRKOBJPDM
. WRKMBRPDM
Starting PDM from the AS/400 Main Menu
To start PDM from the AS/400 Main Menu:

1. Select option 5 (Programming) from the AS/400 Main Menu, and press Enter. The
Programming menu is displayed.
2. Select option 2 (Programming Development Manager (PDM)), and press Enter. The AS/400
Programming Development Manager (PDM) menu appears. You can select one of the options
from this menu to work with libraries, objects, members, or user-defined options.
AS/400 10 Venkat BAS

Starting PDM by Using the STRPDM Command
To start PDM by using the STRPDM command, type STRPDM on any command line and press
Enter. The AS/400 Programming Development Manager (PDM) menu is displayed.
Starting PDM by Using the WRKLIBPDM Command
To start PDM and work with the list of libraries from your previous PDM session, type
WRKLIBPDM on the command line without specifying any parameters, and press Enter. The
Work with Libraries Using PDM display appears. To display a specific list of libraries, specify
parameters after the WRKLIBPDM command. For example, to display a list of all libraries starting
with BA, type the following command on any command line, and
press Enter:WRKLIBPDM LIB(BA\) The Work with Libraries Using PDM display appears.
Starting PDM by Using the WRKOBJPDM Command
To start PDM and work with all the objects in a library from your previous PDM session, type
WRKOBJPDM on the command line without specifying any parameters, and press Enter. The
Work with Objects Using PDM display appears. To display a specific object in a library, specify
parameters after the WRKOBJPDM command. For example, for a list of all the CLP programs in
the ATEST library that start with CHG, type the following command on any command line, and
press Enter:
WRKOBJPDM LIB(ATEST) OBJ(CHG\) OBJTYPE(\PGM) OBJATR(CLP)
The Work with Objects Using PDM display appears.
Starting PDM by Using the WRKMBRPDM Command
To start PDM and work with all the members in the file and library from your previous PDM
session, type WRKMBRPDM on the command line without specifying any parameters, and press
Enter. The Work with Members Using PDM display appears. To work with a specific list of
members, specify parameters after the WRKMBRPDM command. For example, for a list of all
members in the CMDSRC
file in the ATEST library with a type of CMD that start with C, type the following command on any
command line, and press Enter:
WRKMBRPDM FILE(ATEST/CMDSRC) MBR(C\) MBRTYPE(CMD)
The Work with Members Using PDM display appears.
Working with Libraries
You can perform the following tasks when working with libraries:
View a library list
View a list of libraries
Work with an alphabetical list of libraries
Create a library

Delete a library
Rename a library
Change the type and text description of a library
Work with objects in a library
Copy a library
Copy to an existing library
Display the description of a library
Create a subset of a list of libraries
Add an existing library to a library list
Move a user library to the user portion of a library list
Remove a user library from the user portion of a library list
Differences between a Library List and a List of Libraries
A library list is an ordered list of library names. It identifies the libraries that are searched and the
order of the search. A list of libraries, however, is an alphabetic list of all the libraries, or a subset
list of all the libraries, on the system.
Viewing a Library List
To view a library list:
1. Select option 1 (Work with libraries) from the AS/400 Programming Development Manager
(PDM) menu, and press Enter. The Specify Libraries to Work With display appears.
2. Type one of the following values in the Library prompt, and press Enter:*LIBLDisplays a list of
all libraries in your library list
*USRLIBL Displays a list of all libraries in the user portion of your library list
Note: You can also specify these values for the LIB parameter of the WRKLIBPDM command.
3. Press F3 (Exit) to return to the AS/400 Programming Development Manager (PDM) menu. You
can add libraries to, or remove them from, the library list. When you remove a library from the
library list, you are only taking the library off the library list temporarily. The library is not deleted
from the system. You can also change the search order by changing the position of libraries in
your library list.
Viewing a List of Libraries
To view a list of libraries:
1. Select option 1 (Work with libraries) from the AS/400 Programming Development Manager
(PDM) menu, and press Enter. The Specify Libraries to Work With display appears.
2. Type one of the following values in the Library prompt, and press Enter.
*ALL
Displays a list of all libraries in the system.
*ALLUSR
Displays a list of all nonsystem libraries, including a list of all user-defined
libraries.

*CURLIB
Displays a list containing only the current library.
Library name
Displays a list containing only the library you specify.
10 Programming Development Manager (PDM)
Generic name
Displays a list containing libraries that meet specific criteria. The generic name can be in one of
the following formats:
ABC*
Displays a list of all items that begin with the characters ABC for example, ABC, ABCD, or
ABCTEST.
*ABC
Displays a list of all items ending with the characters ABC, for example, ABC, DABC, or
TESTABC.
*B*
Displays a list of all items that have the character B anywhere in the name, for example, B,
BALL, or ABCD.
A*C
Displays a list of all items that begin with the character A and end with the character C, for
example, AC, ABC, or AZZZC.
a*
Displays a list of all items within quotation marks that start with the character a, for example, a,
aB, or aD.
**ALL
Displays a list of all items ending with ALL, for example, ALL, BALL, or TESTALL. The double
asterisk is needed in this case because ALL is defined as the value to display a list of all libraries.
Note: You can also specify these values for the LIB parameter of the WRKLIBPDM command.
3. Press F3 (Exit) to return to the AS/400 Programming Development Manager
(PDM) menu.
Creating a Library
You can create a library if you are working with a list of libraries (list type *ALL or*ALLUSR). To
create a library called ANEXAMP:
CRTLIB press F4
Type ANEXAMP in the Library prompt, \PROD or \TEST in the Library type prompt,and a
description of the library in the Text text description prompt, and press Enter. This example
creates library ANEXAMP.
A message at the bottom of the display indicates that the library was created.
Deleting a Library
Using PDM, you can delete libraries you no longer need by selecting the Delete option.
To delete library ANEXAMP and library AOLD:
Type DLTLIB and enter the lib name to delete
Renaming a Library

Changing the Type and Text Description of a Library
Working with Objects in a Library

WRKOBJPDM
Displaying the Description of a Library
When using PDM, you can display the following information about a library:
. Library size
. Time and date the library was created
. Time and date the library was changed
. Time and date the library was last saved
. Time and date the library was last restored
Adding a Library to a Library List

ADDLIBLE
Sample User-Defined Options
The following sample user-defined options are shipped with PDM:
Option Name Command Called Explanation
C CALL &O/&N Allows you to run a program on the Work with

Members Using PDM display.
CC CHGCURLIB CURLIB(&L) Changes the library on the Work with Objects

UsingPDM display or the Work with Members Using
PDMdisplay to the current library in the library list.
CD STRDFU OPTION(2) Allows you to create a DFU program.
CL CHGCURLIB CURLIB(&N) Changes selected library on the Work with

LibrariesUsing PDM display to the current library in the
library list.

CM STRSDA OPTION(2) SRCFILE(&L/&F) ??SRCMBR()
Allows you to create a member (menu) using SDA.
CS STRSDA OPTION(1) SRCFILE(&L/&F)??SRCMBR()

Allows you to create a member (display) usingSDA.
DM DSPMSG Allows you to display messages.
The relationships between the various objects
QSYS (*LIB)
[special library]
|
| contains
|
Library (*LIB)
|
| contains
|
.------------------+----^-----------------.--------.
| | | |
Programs (*PGM) Out queues (*OUTQ) Files (*FILE) Other
[Executable] | | objects
| contains |
Spooled Files |
[Output intended for Printer] |
|
.----------------^--.
| |

Physical Data Logical
file file
(PF) (LF-DTA)
| ^ contains
.------^-----. Member(s)
| | [Reorganized data]
Source Data
Physical Physical
File File
(PF-SRC) (PF-DTA)
| |
contains | | contains
| |
Member(s) Member(s)
[Program source] [Actual Data]
DB2/400 Chapter 3
Database files
A database file is one of several types of the system object type *FILE kept in the system that
contains descriptions of how input data is to be presented to a program from internal storage and
how output data is to be presented to internal storage from a program. There are several types of
database files:
Source file
Physical file
Logical file
Source file
A source file contains uncompilable programming code and input data needed to create some
types of objects. A source file can contain source statements for such items as high-level
language programs and data description specifications. A source file can be a source physical
file, diskette file, tape file, or inline data file.

Physical file
A physical file is a database file that stores application data. It contains a description of how data
is to be presented to or received from a program and how data is actually stored in the database.
A physical file consists of fixed-length records that can have variable-length fields. Physical files
contain one record format and one or more members. From the perspective of the SQL interface,
physical files are identical to tables.
Logical file
A logical file is a database file that logically represents one or more physical files. It contains a
description of how data is to be presented to or received from a program. This type of database
file contains no data, but it defines record formats for one or more physical files. Logical files let
users access data in a sequence and format that is different from the physical files they
represent. From the perspective of the SQL interface, logical files are identical to views and
indexes.
Data type for physical and logical files (position 35)
For a physical file, use this position to specify the data type of the field within the database.
Specify data type in a logical file only to override or change the data type of the corresponding
field in the physical file on which this logical file is based. If you leave this position blank, the field
you are defining has the same data type as the corresponding field in the physical file(s) on
which the logical file(s) is based.
Valid data type entries are as follows
Entry Meaning
P Packed decimal
S Zoned decimal
B Binary
F Floating-point
A Character
H Hexadecimal
L Date
T Time
Z Time stamp
Data Type Valid Lengths

Character 1 through 32 766 characters
Hexadecimal 1 through 32 766 bytes
Binary 1 through 18 digits
Zoned decimal 1 through 31 digits
Packed decimal 1 through 31 digits
Floating-point
(single precision) 1 through 9 digits
Floating-point
(double precision) 1 through 17 digits
Date 6, 8, or 10 characters
Time 8 characters
Time stamp 26 characters
The length for fields with data type L (date), T (time), or Z (timestamp) is determined by the
system. You should not enter a field length in positions 30 through 34. The field length for date
and time includes the separator. A timestamp has a fixed format that has the following form:
YYYY-MM-DD-hh.mm.ss.uuuuuu
Type in a maximum of 9 digits for single precision and 17 digits for double precision. The OS/400
program supports a floating-point accuracy of 7 digits for single precision and 15 digits for double
precision. The total number of bytes occupied by all the fields in a record must not exceed 32 766
(in storage). The system determines the number of bytes actually occupied in storage as follows:
Data Type Bytes Occupied in Storage
Character Number of characters
Hexadecimal Number of bytes
Binary
1 through 4 digits 2 bytes
Zoned decimal Number of digits
Packed decimal (Number of digits/2) + 1 (truncated if fractional)
Floating-point 4 bytes
(single precision)
Keyword entries for physical and logical files

(positions 45 through 80)

This section contains keyword entries valid for describing physical and logical files. They are
typed in positions 45 through 80 (functions). See the DDS Reference: Concepts information for a
discussion of the
The following keywords are valid for both physical and logical files (except where noted):
ABSVAL FLTPCN
ALIAS FORMAT
ALL (logical files only) LIFO
ALWNULL (physical files only) NOALTSEQ
CHECK RANGE
CHKMSGID REF (physical files only)
CMP REFFLD (physical files only)
COLHDG REFSHIFT
COMP RENAME (logical files only)
CONCAT (logical files only) SIGNED
DATFMT SST (logical files only)
DATSEP TEXT
DESCEND TIMFMT
DFT (physical files only) TIMSEP
DIGIT TRNTBL (logical files only)
DYNSLT (logical files only) UNIQUE
EDTCDE UNSIGNED
EDTWRD VALUES
FCFO VARLEN
FIFO ZONE
The following keywords are valid only for simple and multiple format logical files:
PFILE
REFACCPTH
The following keywords are valid only for join logical files:
JDFTVAL JOIN
JDUPSEQ JREF
JFILE
JFLD
When you use DDS to describe a source file (usually created without DDS, using the
CRTSRCPF command or when a logical file is based on a physical file to be used as a source
file, you cannot use the following keywords:
ABSVAL NOALTSEQ
ALTSEQ SIGNED
DESCEND UNIQUE
FCFO VARLEN
FIFO ZONE
LIFO

File: ST@MST Record: ST@REC Library: ASIFLIB
A R ST@REC
A ST@SID 5A
A ST@NAM 20A
A ST@GEN 1A
A ST@DOB 8P 0
A ST@AD1 15A
A ST@AD2 15A
A ST@AD3 15A
A ST@PHO 12P 0
A ST@COU 15A
File: ST@MST1 Record: ST@REC Library: ASIFLIB

A R ST@REC
A ST@SID 5A
A ST@NAM 20A
A ST@GEN 1A
A ST@DOB 8P 0
A ST@AD1 15A
A ST@AD2 15A
A ST@AD3 15A
A ST@PHO 12P 0
A ST@COU 15A
A K ST@SID
File: ST@MST2 Record: ST@REC Library: ASIFLIB
A UNIQUE
A R ST@REC
A ST@SID 5A
A ST@NAM 20A
A ST@GEN 1A
A ST@DOB 8P 0
A ST@AD1 15A
A ST@AD2 15A
A ST@AD3 15A
A ST@PHO 12P 0
A ST@COU 15A
A K ST@SID
COLHDG (Column Heading) keyword for physical and logical files
Use this field-level keyword to specify column headings used as a label for this field by text
management, the query utility, the data file utility (DFU), and the screen design aid (SDA).
The format of the keyword is:
COLHDG(line-1 [line-2 [line-3]])
A maximum of three lines of 20 characters each is allowed. Each line of the column heading
must be enclosed in apostrophes. Use double apostrophes ( ) to specify apostrophes within
column headings. Use one or more blanks to separate the first column heading line from the
second and the second from the third. For a physical file, if you do not specify COLHDG and it is
not retrieved from a referenced field, the field name is used. If you do not specify COLHDG for a
logical file, the column heading from the physical file is used, except when the field is a
concatenation of fields; in this case, the default is the field name. If you specify COLHDG but do
not specify TEXT, 50 positions of column heading information are used as text. For example,
COLHDG(Order Date) is equivalent to TEXT(Order Date).
Example:
The following example shows how to specify the COLHDG keyword for a physical file.
00150 A ORDDAT 5 0 COLHDG(Order Date)

00160 A NAME 2 0 COLHDG(Customers Name)
00170 A CITY 2 0 COLHDG(Customer City Field)
Decimal positions or data type must be specified for ORDDAT since Order Date is a numeric
field (denoted by NNNNN below). The following display illustrates how the column headings can
appear when running text management,query, DFU, or SDA.
Customer
Order City
Date Customers Name Field
NNNNN XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX
DATFMT (Date Format) keyword for physical and logical files
Use this field-level keyword to specify the format of a date field. This keyword is valid only for
date fields (data type L) or for logical file zoned fields (data type S), packed fields (data type P),
or character fields (data type A) whose corresponding physical file fields are date fields (data
type L).

DATFMT(date-format)
Example:
The following example shows how to specify the DATFMT keyword.
00010 A
00020 A R RECORD
00030 A DATFLD1 L DATFMT(*JUL)
00040 A DATFLD2 L DATFMT(*EUR)
The DATSEP keyword overrides the job attribute. It does not change the system default.
Example:
The following example shows how to specify the DATSEP keyword.
00010 A
00020 A R RECORD1
00030 A DATFLD2 L DATFMT(*DMY) DATSEP(-)
00040 A DATFLD4 L DATSEP( )
DESCEND (Descend) keyword for physical and logical files
Use this key field-level keyword to specify that the values of this character, hexadecimal, or
numeric key field are retrieved in descending sequence. The default is ascending sequence.
See SIGNED (Signed) keyword for physical and logical files on page 69 for an example of
data sorted using the DESCEND keyword.
This keyword has no parameters.
Example:
The following example shows how to specify the DESCEND keyword for a logical file.
00010 A K ITEM
00020 A K BALDUE DESCEND
DFT (Default) keywordphysical files only
Use this field-level keyword to specify a default value for a field.

DFT(value | numeric-value | Xhexadecimal-value | *NULL)
Without this keyword, character and hexadecimal fields default to blanks and numeric fields
default to
zeros. However, if you specify the ALWNULL keyword for the field, then the character,
hexadecimal, and numeric fields default to the null value.
Physical and Logical Files, DFT

When the program does an output operation to a logical file based on this physical file
and the recordformat in the logical file does not name this field.
When you use the Initialize Physical File Member (INZPFM) command for a member in
this file.
When you use the Copy File (CPYF) command with FMTOPT(*MAP) specified and a
field in the to-file is not in the from-file.
This keyword does not affect the physical file on input operations.
Example:
The following example shows how to specify the DFT keyword.
00010 A R RECORD1
00020 A CHARFLD1 20A DFT(Sample field)
00030 A CHARFLD2 5A DFT(XD985955185)
00040 A HEXFLD1 3H DFT(ABC)
00050 A HEXFLD2 3H DFT(XC1C2C3)
00060 A NUMFLD1 5S 0 DFT(99999)
00070 A NUMFLD2 5S 2 DFT(999.99)
00080 A NUMFLD3 5S 2 DFT(999)
00090 A NUMFLD4 5S 2 DFT(*NULL)
00100 A ALWNULL
00110 A NUMFLD5 5S 2 DFT(999.99)
00120 A ALWNULL
00130 A DATFLD1 L DATFMT(*MDY) DATSEP(-)
00140 A DFT(12-31-91)
00150 A TIMFLD1 T DFT(11.15.00)
ALIAS (Alternative Name) keyword for physical and logical files
Use this field-level keyword to specify an alternative name for a field. When the program is
compiled, the alternative name is brought into the program instead of the DDS field name.

ALIAS(alternative-name)
Example: 00010 A FIELDA 25A ALIAS(CUSTOMERNAME)
ALL (All) keywordlogical files only
Use this select/omit field-level keyword to specify the action to be taken after all other select/omit
specifications have been processed for this logical file. Specify ALL with S in position 17 to direct
the OS/400 program to select any records that do not meet any of the other select/omit rules.
Specify O in position 17 to direct the OS/400 program to omit any records that do not meet any
of the other select/omit rules. If specified, ALL must follow the other select/omit keywords. You
cannot specify a field name with the ALL keyword.
If you do not specify the ALL keyword, the default action taken is the opposite of the last
select/omit
specification you made for the file. If the last specification was a select, the default is to omit all.
If the last
specification was an omit, the default is to select all.
Example:
The following example shows how to specify the ALL keyword.
00010 A S ACT COMP(EQ 3000)

00020 A S ACT COMP(GT 3100)
00030 A OAMT COMP(LT 0)
00040 A OALL
A
ALWNULL (Allow Null Value) keywordphysical files only
Use this field-level keyword to define this field to allow the null value.
When you specify the ALWNULL keyword, the maximum length you can specify in positions 30
to 34 is 32765 bytes (32 739 if the field is also variable length). For physical files, when you
specify the DATFMT keyword with values of *JOB, *MDY, *DMY, *YMD, or *JUL and the field
allows null value, you must specify a valid date on the DFT keyword for this field.
Example:
00010 A R RECORD1
00020A FIELD1 75A ALWNULL
00030A FIELD2 100A
00040A FIELD3 L ALWNULL
00050A DATFMT(*MDY)
00060A DFT(12/25/93)
A
FIELD1 is defined to allow the null value. The default value of FIELD1 is the null value. FIELD2
is defined to not allow the null value. The default value of FIELD2 is blanks.
CHECK (Check) keyword for physical and logical files
Use this field-level keyword to specify validity checking in display files.
The format of the keyword is: CHECK(edit-check-code [. . .]
CHECK does not affect the physical or logical file being defined. When you define an input-
capable field in a display file, refer to the field you are now defining by specifying R in position 29
and using the REF or REFFLD keyword. At display file creation, the OS/400 program copies the
CHECK keyword and other field attributes from the field in the physical or logical file into the field
in the display file. You can override the CHECK keyword (as well as all other validity-checking
keywords and the CHKMSGID keyword) by specifying any validity checking keyword for the field
in the display file. See the Reference for display files topic for details.
The rules for specifying this keyword in a physical or logical file are similar to those for a display
file.
However, only the following codes are allowed in physical or logical files:
Code Meaning
AB Allow blank
ME Mandatory enter
MF Mandatory fill
M10 IBM* Modulus 10 self-check algorithm
M10F IBM Modulus 10 self-check algorithm
M11 IBM Modulus 11 self-check algorithm
M11F IBM Modulus 11 self-check algorithm
VN Validate name
VNE Validate name extended
You cannot specify the CHECK(AB), CHECK(VN), CHECK(VNE), CHECK(M10), CHECK(M11),

CHECK(M10F), or CHECK(M11F) keywords on a floating-point field (F in position 35). You
cannot specify the CHECK keyword on a hexadecimal field (H in position 35). Do not specify the
CHECK keyword on a date, time, or timestamp field (L, T, or Z in position 35).
COMP (Comparison) keyword for physical and logical files

Use this field-level keyword to specify validity checking for the field you are defining when it is
referred to later during display file creation. For logical files, you can also specify this keyword at
the select/omit-field level. COMP is equivalent to CMP.
The format of the keyword is: COMP(relational-operator value)
At the select/omit-field level, the format of the keyword is: COMP(relational-operator field-name)
Valid relational operators are:

Relational Operator Meaning
EQ Equal to
NE Not equal to
LT Less than
NL Not less than
GT Greater than
NG Not greater than
LE Less than or equal to
GE Greater than or equal to
Specify the value parameter at either the field level or the select/omit field level. Specify the field
name parameter only at the select/omit field level.
Example 1:
The following example shows how to specify the COMP keyword for character and numeric
strings.
00010 A R RECORD PFILE(PF1)

00020 A
00030 A FIELDA 1 0 COMP(NE O) 1
C0040 A FIELDB 1 COMP(NE A) 1
00050 A FIELDC
00060 A FIELDD
00070 A FIELDE
00080 A K FIELDB
00090 A S FIELDC COMP(EQ FIELDD) 2
00100 A S FIELDA COMP(NE O) 2
00110 A S FIELDE COMP(NE *NULL) 2
00120 A O FIELDB COMP(GE A) 2
1 COMP is specified for FIELDA and FIELDB as a validity checking keyword for display files that
refer to FIELDA and FIELDB.
2 COMP is specified as a select/omit keyword for FIELDC, FIELDA, FIELDB, and FIELDE.
Records
from the physical file PF1 are retrieved through this logical file record format depending on the
following comparisons:
FIELDC: Records are selected when FIELDC equals FIELDD.
FIELDA: Records not meeting FIELDC test are selected only when FIELDA is not equal
to zero.
PFILE (Physical File) keywordlogical files only
Use this record-level keyword to identify the physical file(s) containing the data to be accessed
through the record format you are now defining.
The format of the keyword is: PFILE([library-name/]physical-file-name [.32])
The following examples show how to specify the PFILE keyword.
Example 1:
00010 A R LOGRCD1 PFILE(PF1)
In this example, LOGRCD1 can use fields only in PF1.
Example 2:
00010 A R LOGRCD2 PFILE(PF1 PF2)
A:
00020 A R LOGRCD3 PFILE(PF1 PF2 PF3)

A:
A:
In this example, LOGRCD2 must use fields common to PF1, and PF2, and LOGRCD3 must
use fields common to PF1, PF2, and PF3.
Example 3:
A:

A:
A:
00030 A R LOGRCD6 PFILE(LIB1/PF6)
A
In this example, LOGRCD4, LOGRCD5, and LOGRCD6 can have unique fields. LOGRCD6
specifies a qualified physical-file name.
RANGE (Range) keyword for physical and logical files
Specify this keyword at the field level, the select- or omit-field level, or both.
RANGE(low-value high-value)
Example 1:
The following example shows how to specify character and numeric strings for the RANGE
keyword.
00010A R RECORD PFILE(PF1)

00020A FIELDA 1 0 RANGE(2 5) 1
00030A FIELDB 1 RANGE(2 5)
00040A FIELDC
00050A K FIELDD
00060A S FIELDA RANGE(1 4) 2
A
In this example, RANGE (1) is specified for FIELDA and FIELDB as a validity checking keyword
for display files that refer to FIELDA and FIELDB. In the display file, RANGE requires that the
work station
CONCAT (Concatenate) keywordlogical files only
Use this field-level keyword when you want to combine two or more fields from the physical file
record format into one field in the logical file record format you are defining. The name of this
concatenated field must appear in positions 19 through 28.

CONCAT(field-1 field-2...)
Examples:
The following examples show how to specify the CONCAT keyword.
Example 1:
MTH, DAY, and YEAR are fields in the physical file that are concatenated into one field DATE in
the logical file, as shown in the following example.
00010 A R RECORD1 PFILE(PF1)

00020 A DATE CONCAT(MTH DAY YEAR)
Example 2:
In the following example, if the program changes DATE from 01 03 81 to 02 05 81, the value
placed in the physical record does not change because the fields specified last are MTH (value
01), DAY (value 03), and YEAR (value 81). However, if MTH, DAY, and YEAR are changed to
new values, the value of DATE in the physical record also changes.
Physical and Logical Files, CONCAT 40 OS/400 DDS Reference: Physical and Logical Files

00030 A MTH
00040 A DAY
00050 A YEAR
Example 3:
In the following example, fields from the physical file are concatenated into more than one field
in the logical file.

00030 A CMPDAT CONCAT(DAY MTH YEAR)
Example 4:
In the following example, if the fields from PF1 are:
FIXED1 is a fixed length field.
FIXED2 is a fixed length field.
VARLEN1 is a variable length field.
The resulting fields are:

FIELD1 is a variable length field.
FIELD2 is a fixed length field.
FIELD3 is a variable length field.

00020 A FIELD1 CONCAT(FIXED1 VARLEN1)
00030 A FIELD2 CONCAT(FIXED1 FIXED2)
00040 A FIELD3 CONCAT(FIXED1 FIXED2)
00050 A VARLEN
JOIN (Join) keywordjoin logical files only
Use this join-level keyword to identify which pair of files are joined by the join specification in
which you specify this keyword.

JOIN(from-file to-file)
This keyword is valid only for join logical files.
On each JFILE keyword, the from file must occur before the to file.
If you specify numbers, they correspond to the files specified on the JFILE keyword. The
following are the valid values:
File Valid Values

From-file number
1 through 31
To-file number
2 through 32
The from-file number must always be less than the to-file number.
Special rules apply to the order in which you specify from and to files. See example 3 below for
details.
In a join logical file, each secondary file can be a to file only once.
JFILE (Joined Files) keywordjoin logical files only
Use this record-level keyword to identify the physical files containing the data to be accessed
through the join logical file you are defining.

JFILE([library-name/]physical-file-name [..32])
This keyword is similar to the PFILE keyword except it identifies this file as a join logical file.
The JFILE keyword is not allowed with the PFILE keyword. The JFILE keyword is required at
the record level in a join logical file. The JFILE keyword requires a minimum of two physical file
names. You can specify the same file name more than once. The first file is called the primary
file, which is the file from which the join will begin. All other files are called secondary files. Up
to 31 secondary files can be specified (32 total files on the JFILE keyword).
Note: If the names in the physical file are not unique, you must specify relative file numbers.
JFLD (Joined Fields) keywordjoin logical files only
Use this join-level keyword to identify the from and to fields whose values are used to join
physical files in a join logical file. These fields are both referred to as join fields.
The format of the keyword is: JFLD(from-field-name to-field-name)
The join fields must correspond to fields in the physical files identified on the JOIN keyword for
this join specification. The name you specify on the JFLD keyword must be the same as the
name specified in the physical file unless it was renamed in the join logical file. If you do not
specify a JOIN keyword, then the JFILE keyword is used. This keyword is valid only for join
logical files. At least one JFLD keyword is required for each join specification. A join
specification is identified by J in position 17. Since at least one join specification is required in a
join logical file, you must have at least one JFLD keyword specified in a join logical file.
Examples:
The following examples show how to specify the JFILE keyword.
Example 1:
00010 A R JREC JFILE(PF1 PF2)
00020 A J JOIN(PF1 PF2)
00030 A JFLD(NAME1 NAME2)
Example 2:
In the join logical file, PF1 is the primary file and PF2 is the secondary file.
00010 A R JREC JFILE(MYLIBA/PHYSICAL1 +

00020 A MYLIBB/PHYSICAL2 MYLIBC/PHYSICAL3)
00030 A J JOIN(1 2)
00040 A JFLD(FIELD1 FIELD2)
00050 A J JOIN(1 3)
00060 A JFLD(FIELD1 FIELD2)
In the join logical file, file PHYSICAL1 in library MYLIBA is the primary file. File PHYSICAL2 in
library MYLIBB and file PHYSICAL3 in library MYLIBC are secondary files.
Example 3:
In the join logical file, the JFLD keywords specify that NAME1 in physical file PF1 is used to join
to NAME2 in physical file PF2.
Example 4:
00040 A JFLD(ADDR1 ADDR2)
Example 5:
00010 A R RECORD1 JFILE(PFA PFB PFC)
00020 A J JOIN(PFA PFB)
00040 A J JOIN(PFA PFC)
00060 A NAME1
A
In this example, PFA is joined to PFB and also to PFC.
Example 6:
The following example shows how to specify JOIN using relative file numbers.
00010 A R RECORD1 JFILE(PFA PFB PFC)

00020 A J JOIN(1 2)
00040 A J JOIN(1 3)
00060 A NAME1
Example 7:
The following example shows the order of associated physical files.
00010 A R J3 JFILE(VENDORS PARTS PARTWARE +

00020 A WAREHOUSE
1
00030 A J JOIN(1 2) 2
00040 A JFLD(VNBR VNUM)
00050 A J JOIN(2 3) 3
00060 A JFLD(PNBR PNBR)
00070 A J JOIN(3 4) 3
00080 A JFLD(WNBR WNBR)
00090 A VNAME
00100 A VAD1
00110 A VAD2
00120 A PNBR JREF(2)
00130 A WNBR JREF(4)
00140 A BIN
00150 A QOH
A
The join logical file in this example is based on four physical files. The VENDORS file, which is
specified first on the JFILE keyword, is the primary file and has relative file number 1. The
PARTS, PARTWARE, and WAREHOUSE files, which are secondary files, have relative file
numbers 2, 3, and 4, respectively. Notice the pattern of numbers specified on the JOIN
keywords:
1 The first parameter value on the first JOIN keyword (the first from file) must be the primary
file.
2 The second parameter values specified on the JOIN keywords (to files) must reflect the same
order as the secondary files on the JFILE keyword. If file names were specified instead of
relative
file numbers, they would have to be specified in the following order:
JREF (Join Reference) keywordjoin logical files only
Use this field-level keyword in join logical files for fields whose names are specified in more
than one
physical file. This keyword identifies which physical file contains the field.

JREF(file-name | relative-file-number)
This keyword is valid only in a join logical file.
Join logical files are based on two or more physical files (up to 32). Field names specified in the
record
format in a join logical file must uniquely identify only one field from the physical files on which
the join logical file is based. For example, if the join logical file is based on two physical files,
and each physical file has the field named NAME, you must specify the JREF keyword to
identify which physical file the field comes from.
Examples:
The following examples show how to specify the JREF keyword.
Example 1:
00010 A R JOINREC JFILE(PFA PFB PFC)

00020 A :
00030 A :
00040 A :
00050 A NAME JREF(PFB)
DYNSLT (Dynamic Select) keywordlogical files only
Use this file-level keyword to indicate that the selection and omission tests specified in the file
(using
select/omit specifications) are done at processing time. This keyword specifies dynamic
select/omit rather than access path select/omit.

As your program does input operations to a logical file with the DYNSLT keyword specified, all
the records in the associated physical file are tested by the system to see if they satisfy the
select/omit values. Only those records that satisfy the values are supplied to your program. The
testing of each record can result in slower I/O performance, but may be more efficient than
maintaining an access path for the file. This is particularly likely for files read only occasionally,
especially when the physical files they are based on are updated frequently. Using dynamic
select/omit is probably also more efficient for files with a high percentage of selected records.
You must use the DYNSLT keyword when you want to select or omit fields and any of the
following are true:
The logical file has arrival sequence (no key fields are specified). See example 1 below.
The logical file is a join logical file with the JDFTVAL keyword specified.
The logical file is a join logical file, select/omit fields come from more than one of the
physical files the
logical file is based on, and one of the following is true:
The select/omit fields are on the same select or omit statement. See example 3 below.
The select/omit fields are on a mixture of select and omit statements. See example 4 below.
The select/omit fields are on select statements that are ORed together.
The select/omit fields are on omit statements that are ANDed together.
You cannot specify the DYNSLT keyword with the REFACCPTH keyword.
Examples:
The following examples show how to specify the DYNSLT keyword.
Example 1:
The following example shows how to specify dynamic select with arrival sequence.
00010 A DYNSLT
00030 A FLD1
00040 A FLD2
00050 A S FLD1 COMP(GT 2)
The DYNSLT keyword is required because there are no key fields.

The logical file supplies records to your program in arrival sequence. Assume that physical file
PF1 has the following records:
FLD1 FLD2
1 aaaa
2 dddd
3 jjjj
4 bbbb
As your program does input operations, the system tests the first two records according to the
select/omit values, but does not supply them to your program. Your program only sees the last
two records:
FLD1 FLD2
3 jjjj
4 bbbb
Example 2:
The following example shows how to specify dynamic select with keyed sequence access path.
00010 A DYNSLT
00030 A FLD1
00040 A FLD2
00050 A K FLD1
00060 A S FLD2 COMP(GT bbbb)
A
In this example, the DYNSLT keyword is not required. The logical file supplies records to your
program in keyed sequence. Assume that physical file PF1 has the following records:
FLD1 FLD2
1 aaaa
2 dddd
3 jjjj
4 bbbb
When your program requests a record, the system tests the value of FLD2 for that record
according to the select/omit values. Your program only sees the following records:
FLD1 FLD2
2 dddd
3 jjjj
Example 3:
The following example shows how to specify a join logical file with select/omit comparing fields
from two physical files.
00010 A DYNSLT
00020 A R RECORD1 JFILE(PF1 PF2)
00030 A J JFLD(FLD1 FLD3)
00040 A FLD1 JREF(PF1)
00080 A S FLD1 COMP(GT FLD4)
A
FLD1 and FLD2 come from the primary file (PF1), and FLD3 and FLD4 come from the
secondary file
(PF2). The select specification compares FLD1 from the primary file with FLD4 from the
secondary file. Therefore, the DYNSLT keyword is required.
Example 4:
The following example shows how to specify a join logical file with select and omit using fields
from more than one physical file.
00010 A DYNSLT
00040 A JFLD(FLD1 FLD2)
00080 A K FLD1
00090 A S FLD1 COMP(GT 0)
00100 A O FLD3 COMP(GT 4)
FLD1 and FLD3 come from different physical files and are specified in a mixture of select and
omit statements. Therefore, the DYNSLT keyword is required.
JDUPSEQ (Join Duplicate Sequence) keywordjoin logical files only
Use this join-level keyword to specify the order in which records with duplicate join fields are
presented when your program reads a join logical file.
The format of the keyword is: JDUPSEQ(sequencing-field-name [*DESCEND])
This keyword has no effect on the ordering of unique records. If you do not specify the
keyword, the system does not guarantee the order in which records with duplicate join fields
are presented If more than one JDUPSEQ keyword is specified in one join specification, the
order in which you specify the JDUPSEQ keywords determines the order of presentation of
duplicate records. This is similar to specifying an additional key field, in that it determines the
order in which records with duplicate keys are presented.
This keyword is valid only for join logical files.
Example 1:
The following example shows how to specify the JDUPSEQ keyword.

00040 A JDUPSEQ(PHONE)
00050 A NAME1
00060 A ADDR
00070 A PHONE
This example assumes that PF1 and PF2 have the following records:
PF1 NAME1 ADDR PF2 NAME2 TELEPHONE

Anne 20 1st St. Anne 555-1111
Doug 40 Pillsbury Anne 555-6666
Mark 2 Lakeside Dr. Anne 555-2222
PF1 NAME1 ADDR PF2 NAME2 TELEPHONE

Doug 555-5555
There are three records for Anne in PF2, showing three telephone numbers. With JDUPSEQ
specified as shown, the records are returned as follows:
NAME ADDR TELEPHONE

Anne 120 1st St. 555-1111
Anne 120 1st St. 555-2222
Anne 120 1st St. 555-6666
Doug 40 Pillsbury 555-5555
The JDUPSEQ keyword only affects the order of records when duplicates exist.
Example 2:
This example assumes the logical file is based on the same physical files as example 1. There
are three records for Anne in PF2, showing three telephone numbers.

00040 A JDUPSEQ(PHONE *DESCEND)
00050 A NAME1
00060 A ADDR
00070 A PHONE
When you specify JDUPSEQ with *DESCEND, the records are returned as follows:
NAME1 ADDR TELEPHONE

Anne 120 1st St. 555-6666
Anne 120 1st St. 555-2222
Anne 120 1st St. 555-1111
Doug 40 Pillsbury 555-5555
The list shows Annes telephone numbers in descending order.

Control Language / 400 Chapter 4
It is a set of commands that we use to control operation

It is integrated part of the OS/400 not a separate product
Some times it is looking like PC-DOS commands like copying files,
redirecting output,making directories.
AS/400 version of CL announced in 1988.
Capabilities of CL:
Starts jobs by calling program/submitting jobs for batch process

Control the sequence of processing
Check for the security and existence of the program
Handle error conditions
Send messages between programs
Manipulate the variable information
Changes configuration of your AS/400
CL programs have limited printing capabilities and can not be used to
send data over communication lines
Control language is mainly used to manipulate and control the application

execution environment generally as front end to the HLL applications like
RPG/400,COBOL/400
Limitations
Database manipulations are limited to reading files and only a single file can be opened for I/O
operation
Controlling work flow with CL
We can control work flow with job streams

Using messages we can communicate between the process on AS/400
CL is Permanent Object on the AS/400
How we can execute the CL

CL commands can be used on command line or included in a CL Program
Individual cl command also can be submitted for batch processing by using SBMJOB
CL commands consists of smaller elements that include
VERB
MODIFIER
OBJECT
PARAMETER
Verbs and Objects

CL made up of more than 1000 IBM supplied commands
CL command names are shorthand form. Command consists of a Verb or Action followed by
the object that will be acted upon
English Verb CL Abbreviation English Verb CL Abbreviation
ADD ADD ALLOCATE ALC

CALL CALL CHANGE CHG
CLEAR CLR COPY CPY
REATE CRT DECLARE DCL
DELETE DLT DO DO
DISPLAY DSP END END
HOLD HLD GOTO GOTO
INITIALIZE INZ MOVE MOV
OVERRIDE OVR REORGANIZE RGZ
RELEASE RLS REMOVE RMV
RESTORE RST RETRIVE RTV
SAVE SAV SEND SND
START STR WORKWITH WRK
Examples of Common Object Abbreviations of CL
Object CL Abbreviation object CL Abbreviation

Attribute A AUTHORITY AUT
CONFIGURATION CFG COMMAND CMD
COMMUNICATION CMN DESCRIPTION D
DESKETTE DKT DOCUMENT DOC
ENTRY E FILE F
FOLDER FLR JOB JOB
LIBRARY LIB LIST L
MEMBER M MESSAGE MSG
OBJECT OBJ PROGRAM PGM
QUEUE Q SUBSYSTEM SYS
TAPE TAP
Examples:
1.WRKJOB :Work with job
2.WRKACTJOB :Work with active job
3.WRKUSRJOB :Work with user job
4.CRTRPGPGM :Create RPG Program
5.CRTCBLPGM :Create COBOL program
6.CRTCLPGM :Create Control Language Program
7.CRTLF :Create Logical File
8.CRTPRTF :Create Printer File
9.CRTDSPF :Create Display File
Basic CL Programming Chapter 5

In many instances, only one CL command is required to perform a function. For instance, if you
wanted to back up Inventory Library on the system to a magnetic tape, you could type the CL
command
SAVLIB LIB(INVLIB) DEV(TAP01)
But at the same time you wanted to send messages to users in the Inventory department first
informing them that you will be backing up their library, and the letting them know when ht backup
is completed? You could do this from a command line by typing in a series of CL commands similar
like
SNDBRKMSG MSG(The Backup of INVENTORY Is Starting) TOMSGQ(INVDSP1)

SAVLIB LIB(INVLIB) DEV(TAP01)
SNDBRKMSG MSG(The Backup of INVENTORY Is Completed)TOMSGQ(INVDSP1)
But if this were a backup routine performed regularly, typing the required series of CL commands
each time the backup was to run would be tedious and error-prone. A better solution would be to
write a cl program that incorporates all the commands. Then instead of typing the CL commands
like that shown above you would type one command to call your program
Example: CALL INVBACKUP
To write the CL programs we need Data Types, Operators, Control Structure to control the flow of
the program and functions..
Data Type Means which type of data will be stored in the memory. Here we have 3 types Data
Types
1.Character *char 9999 bytes in length Default length 32
2.Decimal *dec 15.9 Default length 15(5 decimals)
3.Logical *lgl 0 or 1 Default length 1
Declaration of a variable is must in this environment
DCL VAR(&VARIABLE1) TYPE(*CHAR) LEN(10)

DCL VAR(&VARIABLE1) TYPE(*DEC) LEN(5)
DCL VAR(&VARIABLE1) TYPE(*LGL)
Variable Means it varies the value during the execution of the program, in this environment the length
of the variable is 11
Constant Means it doesnt change its value at any cost
Operator Means it is used to operate two operands in CL we have Arithmetic, Relational and Logical
Operators
Operators
|
----------------------------------------------------------------------
| | | |
Arithmetic Relational Logical String
+ *EQ &(AND) *CAT

- *GT |(OR) *BCAT
* *LT (NOT) *TCAT
/ *GE %SST
*LE OR
*NE %SUBST
*NG
*NL
%SUBSTRING(character-variable-name starting-position length)
%SST(character-variable-name starting-position length)
Control Structures are used to control the flow of the execution of the program
Control Structures
|
----------------------------------------------------------
| | |
Conditional Structure Iterative/Repetitive Structure Unconditional Branching
Simple If DO..ENDDO with IF GOTO

Simple If else
Nested If
CL is hampered by its lack of support for standard control structures such as DOWHILE,
DOUNTIL, And CASE. To help compensate for this lack of control structures, the GOTO command
frequently used. The GOTO command causes the program to branch to a statement identified by a
label. This is called unconditional branching statement .
Note :IF/THEN/ELSE structures can be nested up to 10 levels.
Simple IF statement: An if statement without else

General form of IF statement
IF COND(User Condition)THEN(Statement)
Simple IF ELSE statement: An if statement with else

General form of IF ELSE statement
IF COND(User Condition)THEN(Statement)
ELSE(Statement)
Nested IF statement: An if statement which contains another IF

General form of Nested IF statement
IF (User Condition) +
Statement
Nested IF else statement:
IF cond(User Condition) THEN(CL COMMAND) +
ELSE IF(User Condition)CL COMMAND +
ELSE CL COMMAND
DO..ENDDO With IF
LOOP:
Command
IF COND(User Condition) THEN(DO)
CALL PGM(PGM1)
GOTO CMDLBL(LOOP)
ENDDO
What is an Expression?
An expression is a group of symbols used to represent a single value. The group of symbols in the
expression 10+2, for example, can be used to represent the value 12
In CL four types of expressions can be used to represent CL command parameter values.
Arithmetic expressions
Character String Expressions
Logical Expressions
Relational Expression.
Using Arithmetic Expressions In CL, you can use an arithmetic expression in three situations
Within the VALUE parameter of the CHGVAR command
Within the COND parameter of the IF command
Within the MAPFLD parameter of the OPNQRYF command
When more than one operator appears within an arithmetic expression you must be awareof the
order in which the operators will be evaluated. CL follows the algebraic standard order of
operations
Order Operator
Signed decimal values(such as 3 or +&num1)
Multiplication(*) and division(/)
Addition(+) and subtraction(-)
CL does not directly support a binary number data type. The only numeric data type CL supports is
*DEC. But CL does provide a way to extract a number stored in binary format and convert it to a
decimal variable by using %BIN (binary) built-in function as an operand in an arithmetic
expression.
The %BIN function operates on a *CHAR variable, extracting a binary numeric value that can be
used in an arithmetic expression. %BIN can extract either 2 or 4 bytes
Example : (%BIN(&number 1 2) + 16)
CL would evaluate the above expression as follows (1) extract the binary number form the
character variable &number starting at position 1 for a length of 2, then (2) add the extracted value
to the number 16 to produce the derived value of the expression.
If you want to extract the binary equivalent of an entire variable, you don`t need to specify a
starting position or length for the %BIN function.
Example: (%BIN(&NUMBER) + 16)
Using Character Expressions

you can use character string expression to combine character data into one derived value. The
following character string expression is evaluated as the single character string value My name is
Asif. (My name is *CAT Asif)
*CAT (Concatenation)
*BCAT (Concatenation will be a blank)
*TCAT (Concatenation with truncation)
or you can use symbols in place of the predefined value. The following symbols can be used within
character string expression
||(*CAT)
|>(*BCAT)
|<(*TCAT)
Using the %SST Built In Function

Sub string function is used to get the part of the string from the given string
Example :string1 contains Asif.Shaik

%SST(&string1 1 4) means this will take the data from 1 character to 4th character that means
Asif
Using Relational Expressions
A relational expression contains two operands that are compared. The derived value of the
expression will be either True(1) or False(0) depending on the result of the comparison.
The operands in a relational expression can be any of the following.
Decimal constants
Decimal variables
Arithmetic expressions
Character constants
Character variables
Character string expressions
Logical constants
Logical variables
Logical expression
Relational Operators
Relationship Predefined Value Symbol

Equal to *EQ =
Greater than *GT >
Less than *LT <
Greater than or equal to *GE >=
Less than or equal to *LE <=
Not equal *NE !=
Not greater than *NG !>
Not less than *NL !<
Using Logical Expressions which evaluate the logical relationship between two operands, are very
similar to relational expression. The value of logical expression is evaluated as either True(1) or False
(0).
Predefined Symbol Meaning

Value
*AND & The expression is true if both operand 1 & 2 are true
*OR | The expression is true if either 1 or 2 is true
*NOT ! the value of the expression would be reversed
The Program Structure of CL/400
There are few hard and fast rules for structuring entries within a CL source member. CL source
members, when properly structured, contain the following four sections.
1. The program information section

2. The program linkage section
3. The declaration section
4. The procedure section
The program information section this section is not compulsory, good programming style
dictates that It should be present in every CL source member. This section entirely of comments, to
provide information and documentation about the source member and the program.
The program linkage section marks the beginning of the CL program. It is required, and always
contains only CL command: the PGM(program) command.
The declaration section which defines any variables or files that will be used in a CL program,
follows the program linkage section. All received parameters, as well as any other variables that
will be used in the CL program must be declared in the declarations section.
The procedure section this specifies what procedures and processes the program will perform.
This section contains CL commands that specify what the program will do at execution time
Example:1 Example On Simple CL
PGM
SNDPGMMSG MSG('HELLO THIS IS MY FIRSCT CL PROGRAM')
ENDPGM
Example:2 Get The Name From The User And Display
PGM
DCL VAR(&NAME) TYPE(*CHAR) LEN(10)
SNDUSRMSG MSG('ENTER U R NAME') MSGRPY(&NAME)
SNDUSRMSG MSG('U R NAME IS :' *CAT &NAME)
ENDPGM
Manipulating Variables with the CHGVAR Command
Unlike many high level languages, CL uses the same command (CHGVAR) to move values to any
variables, regardless of their data type you can use the chgvar command in any of these with
equal case
To move a character value to a character type variable
To move a decimal value to a decimal type variable
To move a logical value to logical type variable
In addition you can use the CHGVAR command for data conversion the CHGVAR command can:
Convert numeric value to a character value and store it in a character variable
Convert a character value to a decimal valu and store it in a decimal variable
Using CHGVAR with Decimal variable
The value specified can contain only digits, the decimal point ,and leading sign(+ or -) The value
moved into the receiver variable will be properly aligned at the decimal point, as declared in the
DCL command for the receiver variable. If a decimal point isnot included in the VALUE, the VALUE
is auumed to be an integer with no decimal position. The VALUE contains more decimal position
than the receiver the extra digits will be truncated Specifying a VALUE with more integer digits
than the variable can hold will result in an error at the time of the program is executed.
Converting Decimal Data To Character Data
The numeric value cannot be a quoted string

The value of the receiver variable will be right justified and padded to the left with zeros
If the numeric value is negative, the left-most position of the receiver variable will contain the sign
The receiver variable will contain the decimal point, if any
Receiver variable is declared with enough length to accommodate all the numbers.
Converting Character data To Decimal Data

The character value can contain a leading sign(+ or -) with no inventing blanks. The rest of the
character variable can consist only of numbers and a decimal point.
If the character variable contains a decimal point, the decimal point will be placed in the proper
position in the receiver variable.
Excess characters to the right of the decimal point are truncated without error.
Example:3 Addition of Two Numbers
PGM
DCL VAR(&NUM1) TYPE(*CHAR) LEN(3)
DCL VAR(&NUM2) TYPE(*CHAR) LEN(3)
DCL VAR(&NUM3) TYPE(*DEC) LEN(3)
DCL VAR(&VAL1) TYPE(*DEC) LEN(3)
DCL VAR(&VAL2) TYPE(*DEC) LEN(3)
DCL VAR(&VAL3) TYPE(*CHAR) LEN(3)
SNDUSRMSG MSG('ENTER FIRST NUMBER:') MSGRPY(&NUM1)
SNDUSRMSG MSG('ENTER SECOND NUMBER:') MSGRPY(&NUM2)
CHGVAR &VAL1 &NUM1
CHGVAR &VAL2 &NUM2
CHGVAR &NUM3 (&VAL1 + &VAL2)
CHGVAR &VAL3 &NUM3
SNDUSRMSG MSG('THE SUM OF TWO NUMBERS ::' *CAT &VAL3)
ENDPGM
Example:4 Find the given No is -VE or +VE
PGM
DCL VAR(&NUM) TYPE(*CHAR) LEN(3)
DCL VAR(&VAL) TYPE(*DEC) LEN(3)
SNDUSRMSG MSG('ENTER ANY NUMBER:') MSGRPY(&NUM)
CHGVAR &VAL &NUM
IF COND(&VAL < 0) THEN(SNDUSRMSG MSG('IT IS -VE NUMBER'))
ENDPGM
Example:5 Find the given No is -VE or +VE 2
PGM
DCL VAR(&NUM) TYPE(*CHAR) LEN(3)
DCL VAR(&VAL) TYPE(*DEC) LEN(3)
SNDUSRMSG MSG('ENTER ANY NUMBER:') MSGRPY(&NUM)
CHGVAR &VAL &NUM
IF COND(&VAL < 0) THEN(SNDUSRMSG MSG('IT IS -VE NUMBER'))
ELSE (SNDUSRMSG MSG('IT IS +VE NUMBER'))
ENDPGM
Example 6: Biggest Of Three Numbers
PGM
DCL VAR(&A) TYPE(*CHAR) LEN(3)
DCL VAR(&B) TYPE(*CHAR) LEN(3)
DCL VAR(&C) TYPE(*CHAR) LEN(3)
DCL VAR(&X) TYPE(*DEC) LEN(3)
DCL VAR(&Y) TYPE(*DEC) LEN(3)
DCL VAR(&Z) TYPE(*DEC) LEN(3)
SNDUSRMSG MSG('ENTER FIRST NUMBER:') MSGRPY(&A)
SNDUSRMSG MSG('ENTER SECOND NUMBER:') MSGRPY(&B)
SNDUSRMSG MSG('ENTER THIRD NUMBER:') MSGRPY(&C)
CHGVAR &X &A
CHGVAR &Y &B
CHGVAR &Z &C
IF COND(&X > &Y & &X>&Z) THEN(SNDUSRMSG MSG('A IS BIG'))
ELSE IF (&Y>&Z) SNDUSRMSG MSG('B IS BIG')
ELSE SNDUSRMSG MSG('C IS BIG')
ENDPGM
Example 7: String Concatination *CAT
PGM
/*CONCATINATE WITHOUT EDITING*/
DCL VAR(&STR1) TYPE(*CHAR) LEN(10)
SNDUSRMSG MSG('ENTER FIRST STRING1:') MSGRPY(&STR1)
SNDUSRMSG MSG('ENTER SECOND STRING2:') MSGRPY(&STR2)
CHGVAR &STR3 (&STR1 *CAT &STR2)
SNDUSRMSG MSG('THE RESULTANT STRING IS ::' *CAT &STR3)
ENDPGM
Example 8: String Concatination *BCAT
PGM
/*TRAILING BLANKS IN 1 STRING ARE TRUNCATED*/
CHGVAR &STR3 (&STR1 *BCAT &STR2)
ENDPGM
Example 9:String Concatination *TCAT
PGM
/*IT WILL NOT GIVE ANY BLANKS BETWEEN THE TWO STRINGS*/
CHGVAR &STR3 (&STR1 *TCAT &STR2)
ENDPGM
Example 10: Substring Operation %SUBSTRING

PGM
SNDUSRMSG MSG('THE SUBSTRING IS ::' *CAT %SUBSTRING(&STR1 2 3))
ENDPGM
Controlling Work flow
Work management overview how the AS/400 organizes and process work is called work
management. Work management is the complex topic linking together many facets of the OS/400
operating system.
Work Management Concepts

|
|
^
--------------------------------------------------------------------
| | | | |
Interactive Jobs Batch Jobs Job Descriptions Job Queue Library List
What is a Job?
A job is a unit of work, including all the programs,files instructions and other objects necessary to
perform that work. A Job can be a simple task, such as running a report, or it can be a very
complex series of tasks, such as the entire paryroll operation for a day.
Job Types
|
|
^
-----------------------------
| |
Interactive Job Batch Job
When sign on to the AS/400 you start an interactive job. When you sign off, you end the job. A
batch job, on the other hand requires little or no interaction with the user. Usually you will submit a
batch job from an Interactive job. Once you submit job it will run without any rurther input from
you. In fact wile the batch job runs, you can continue to do work in your interactive job. Batch jobs
usually involve printing reportsor processing complex transactions.
AS/400 assigns a unique name to every AS/400 job. The job name has three parts
The job number

The user profile of the user associatedwithe job
General job name identifying either the purpose of the job or batch job.
What is a Job Description every active job on the AS/400 is associated with a job description.
Usually your system admin will assign a job description to you when he creates your user profile.
A job descrption is an AS/400 object type *JOBD. It defines how a job is to be processed. It
contains such attributes as the hobs execution priority.
What is a Job Queue When you submit a job for processing, it is not processed immediately,
instead it is placed on a job queue to wait for available processor resources. The Object is *JOBQ
that act as a waiting room. Usually, batch job excutes sequentially in the order they were placed
on the job queue.
What is a Library List A jobs library list defines the path of libraries that it will follow when trying
to find programs, files, or other AS/400 Objects
Parts of Library List

|
^
------------------------------------------------------------
| | | |
System Lib List Product Lib List Current Lib List User Lib List
SYSLIBL PRDLIB CURLIB USRLIBL
Examples Examples Examples Examples
QSYS QPDA STUDENT1 QTEMP
QHLPSYS TESTFILES
QUSRSYS TESTPGMS
A library list is not an AS/400 object. It is instead, an attribute of a job. The library list is determined
primarily by the job description. You can use the following CL commands to display and/or alter
the contents of a library list:
ADDLIBLE(Add lib list entry)

CHGCURLIB(Change current lib)
CHGLIBL(Change lib list)
CHGSYSLIBL(Change system lib list)
DSPLIBL(Display lib list)
EDITLIBL(Edit lib list)
RMVLIBLE(Remove lib list entry)
Executing commands in Batch Using SBMJOB This command allows you to submit a job to
job Queue. You can hold a submitted job on the job queue and release it later. You can also
schedule a job to run at a specific date and time. The SBMJOB has many parameters but in its
simples form it is expressed as follows. SBMJOB CMD(CL-command)
A batch job is entirely separate from the job that submitted it with its won program stack and its
won main storage requirements. The main advantage with this SBMJOB is we can do other work
on your workstation without waiting for the batch job to finish.
Ex:SBMJOB CMD(CALL PGM(INVENTORY) PARM(UPDATE 123))
The parameters of SBMJOB it offers many parameters tohelp you specify the environment in
which you want a batch job to execute as well as the jobs attributes.
Paramters:JOB,JOBQ,JOBD,SYSLIBL,CURLIB,INLLIBL,PRTDEV,OUTQ,HOLD,SCDDATE,SCDT
IME
The following exmple tells u about the scheduling parameters
EX:SBMJOB CMD(CALL INVENTORY) SCDDATE(080473) SCDTIME(140000)
This will fired on the date & time mentioned in the SBMJOB
SCDDATE parameters: *MON,*TUE,*WED,*THU,*FRI,*SAT,*MONTHSTR,*MONTHEND
EX:SBMJOB CMD(CALL INVENTORY) SCDDATE(*MON) SCDTIME(140000)
Basic Error Handling
This chapter will introduce ways to handle expected and unexpected errors that occur when a CL
program is executed. We will discuss the CL MONMSG(Monitor message)
There may be occasions when a CL program cannot successfully execute some or all of
the commands contained within the program. The result is a program error
Some program errors may be anticipated. For instance, if a CL program contains a

command to check for the existence of a file, you could reasonably expect that the file
might not exist. When the command is executed and the file you are checking for does not
exist, an error condition occurs.
Another type of error that could occur is a program logic error. A logic error can occur if you
make a mistake when writing the program.
Error Messages if an error condition occurs during execution of a CL program, a special kind of
message, called an escape message(*ESCAPE), is automatically sent to the program. The
escape message will identify the error that occurred. If the system detects an escape message
the system sends an inquiry(*INQ) message to the end user to the system operator(for a batch
job), and does not continue until the end user or the system operator responds.
Error Messages
|
|
^
------------------------------------
| |
Command Level Program Level
Command Level message monitor checks only for escape messages generated by a single
command
Program Level message monitor checks for escape messages issued by all commands within
the program
Message Files the description of error messages that can be generated by a CL program are
stored I message files. Message files(AS/400 object type *MSGF) are similar to database files
(object type *FILE). Most messages that can be generated within a CL program are stored in an
IBM-supplied message file named QCPFMSG in lib QSYS. You can display contents of message
file by using DSPMSGD(display message description) or WRKMSGD(work with message
description)
Some Messages
WRKMSGD
Work with Message Descriptions
System: HBUASSOC
Message file: QCPFMSG Library: QSYS
Position to . . . . . . . Message ID
Type options, press Enter.
2=Change 4=Delete 5=Display details 6=Print
Opt Message ID Severity Message Text

CAE0041 40 Division by zero attempted.
CAE0104 40 Application &1 cannot run in batch mode.
CAE9035 40 Source does not exist in this object.
CAE9044 10 DDS source created. Use CRTLF or CRTPF to create fi
CPF9801 40 Object &2 in library &3 not found.
CPF9802 40 Not authorized to object &2 in &3.
CPF9803 40 Cannot allocate object &2 in library &3.
CPF9804 40 Object &2 in library &3 damaged.
CPF9805 40 Object &2 in library &3 destroyed.
CPF9806 40 Cannot perform function for object &2 in library &3
CPF9807 40 One or more libraries in library list deleted.
CPF9808 40 Cannot allocate one or more libraries on library li
CPF2103 Already exists in library list More...
Example : Example On Command Level MONMSG

PGM
CHKOBJ ASIFLIB/SAMPLE *FILE
MONMSG MSGID(CPF9801) +
EXEC(CRTPF FILE(ASIFLIB/SAMPLE) RCDLEN(80))
ENDPGM
Example : Example On RTVJOBA

PGM
DCL VAR(&JOB1) TYPE(*CHAR) LEN(10)
DCL VAR(&USER1) TYPE(*CHAR) LEN(10)
DCL VAR(&OUTQ1) TYPE(*CHAR) LEN(10)
DCL VAR(&OUTQLIB1) TYPE(*CHAR) LEN(10)
DCL VAR(&DATE1) TYPE(*CHAR) LEN(6)
RTVJOBA JOB(&JOB1) USER(&USER1) OUTQ(&OUTQ1) +
OUTQLIB(&OUTQLIB1) DATE(&DATE1)
SNDUSRMSG MSG('JOB IS :' *CAT &JOB1)
SNDUSRMSG MSG('USER IS :' *CAT &USER1)
SNDUSRMSG MSG('OUTQ IS :' *CAT &OUTQ1)
SNDUSRMSG MSG('OUTQ LIBLIST IS :' *CAT &OUTQLIB1)
SNDUSRMSG MSG('DATE IS :' *CAT &DATE1)
ENDPGM
Example:On Job Type
PGM
DCL VAR(&JOBTYPE) TYPE(*CHAR) LEN(1)
RTVJOBA TYPE(&JOBTYPE)
IF COND(&JOBTYPE='1') THEN(SNDUSRMSG MSG('INTERACTIVE'))
ELSE (SNDUSRMSG MSG('BATCH MODE'))
ENDPGM
Example :Change Priority of the Job
PGM
DCL VAR(&RUNPTY1) TYPE(*DEC) LEN(2 0)
DCL VAR(&TEMP) TYPE(*CHAR) LEN(10)
RTVJOBA RUNPTY(&RUNPTY1)
IF COND(&RUNPTY1 *LT 50) THEN(CHGJOB RUNPTY(50))
ELSE (CHGJOB RUNPTY(&RUNPTY1))
CHGVAR &TEMP &RUNPTY1
SNDUSRMSG MSG('RUN PRIORITY IS :' *CAT &TEMP)
ENDPGM
The following program will convert the Julian date to MDY vice versa
The following is a sample of CL programming. The program interactively converts dates from Julian to
mdy and vice versa. Results are displayed on line 24 of the terminal. It accepts two parameters. The
&IN parameter which is the date string to be converted. If a Julian string it should be in the format
yynnn where yy is the year number and nnn is the day number of the year. If a MDY string it must be
in the format mmddyy. The second parameter is &TYP which is the type of date to be converted to. It
must be 'J' (Julian) or 'M' (mdy). For example: the command CALL PGM(ICVTDATC) PARM('04180'
'M') will convert the Julian date 04180 to 062804 (June 28, 2004).
PGM PARM(&IN &TYP)
DCL VAR(&IN) TYPE(*CHAR) LEN(6)

DCL VAR(&OUT) TYPE(*CHAR) LEN(8)
DCL VAR(&TYP) TYPE(*CHAR) LEN(1)
DCL VAR(&MSG) TYPE(*CHAR) LEN(80)
IF COND(&TYP = J) THEN(DO)
CVTDAT DATE(&IN) TOVAR(&OUT) FROMFMT(*MDY) +
TOFMT(*JUL) TOSEP(*NONE)
ENDDO
IF COND(&TYP = M) THEN(DO)
CVTDAT DATE(&IN) TOVAR(&OUT) FROMFMT(*JUL) +
TOFMT(*MDY) TOSEP(*NONE)
ENDDO
CHGVAR VAR(&MSG) VALUE('IN=' || &IN || ' OUT=' || +

&OUT)
SNDPGMMSG MSG(&MSG)
ENDPGM
Data Areas/Data Queues
Data Areas: A data area is an object used to hold data for access by any job running on the
system data area can be used whenever you need to store information of limited size, independent
of the existence of procedures or files. Typical uses of data areas are:
To provide an area (perhaps within each job's QTEMP library) to pass information within a
job.
To provide a field that is easily and frequently changed to control references within a job,
such as:
Supplying the next order number to be assigned
Supplying the next check number
Supplying the next save/restore media volume to be used
To provide a constant field for use in several jobs, such as a tax rate or distribution list.
To provide limited access to a larger process that requires the data area. A data area can be
locked to a single user, thus preventing other users from processing at the same time.
To create a data area other than a local or group data area, use the Create Data Area
(CRTDTAARA) command. By doing this, you create a separate object in a specific library, and you
can initialize it to a value. To use the value in a CL procedure or program, use a Retrieve Data Area
(RTVDTAARA) command to bring the current value into a variable in your procedure or program. If
you change this value in your CL procedure or program and want to return the new value to the
data area, use the Change Data Area (CHGDTAARA) command.
To display the current value, use the Display Data Area (DSODTAARA) command. You can delete
a data area using the Delete Data Area (DLTDTAARA) command.
You can journal your data areas. This allows you to recover the object to a consistent state, even if
the object was in the middle of some change action when the abnormal IPL or crash occurred.
Journaling also provides for replication of the data area journal to a remote system (using remote
journal for instance). This lets the system reproduce the actions in a similar environment to
replicate the application work.
Local Data Area:A local data area is created for each job in the system, including autostart jobs,
jobs started on the system by a reader, and subsystem monitor jobs.
Group Data Area:The system creates a group data area when an interactive job becomes a group
job (using the Change Group Attributes (CHGGRPA) command).
Create Data Area:Unlike variables, data areas are objects and must be created before they can be
used.
Syntax:CRTDTAARA DTAARA(Lib Name/Data Area Name) +
TYPE(Data Area Type) +
LEN(Length of the Data Area) +
Value(Initial Value) Text('Description')
Display Data Area:You can display the attributes (name, library, type, length, data area text
description) and the value of a data area.
Syntax:DSPDTAARA DTAARA(Lib Name/Data Area Name)
Change Data Area:You can change the value of a data area.
Syntax:CHGDTAARA DTAARA(Lib Name/Data Area Name +
(SUBSTRING-Starting Position Substring Length)) +
VALUE(New Value)
Retrieve Data Area:You can retrieve a data area and copy it to a variable.
Syntax:RTVDTAARA DTAARA(Lib Name/Data Area Name +
(SUBSTRING-Starting Position Substring Length)) +

RTNVAR(&CL Variable Name)
Delete Data Area:You can delete the data area.
Data Queues:
Data queues are a type of system object that you can create, to which one HLL procedure or
program can send data, and from which another HLL procedure or program can receive data.
The receiving program can be already waiting for the data, or can receive the data later.
The advantages of using data queues are:
Using data queues frees a job from performing some work. If the job is an interactive job,
this can provide better response time and decrease the size of the interactive program and
its process access group (PAG). This, in turn, can help overall system performance. For
example, if several workstation users enter a transaction that involves updating and adding
to several files, the system can perform better if the interactive jobs submit the request for
the transaction to a single batch processing job.
Data queues are the fastest means of asynchronous communication between two jobs.
Using a data queue to send and receive data requires less overhead than using database
files, message queues, or data areas to send and receive data.
You can send to, receive from, and retrieve a description of a data queue in any HLL
procedure or program by calling the QSNDDTAQ, QRCVDTAQ, QMHRDQM, QCLRDTAQ,
and QMHQRDQD programs without exiting the HLL procedure or program or calling a CL
procedure or program to send, receive, clear, or retrieve the description.
When receiving data from a data queue, you can set a time out such that the job waits until
an entry arrives on the data queue. This differs from using the EOFDLY parameter on the
OVRDBF command, which causes the job to be activated whenever the delay time ends.
More than one job can receive data from the same data queue. This has an advantage in
certain applications where the number of entries to be processed is greater than one job
can handle within the desired performance restraints. For example, if several printers are
available to print orders, several interactive jobs could send requests to a single data
queue. A separate job for each printer could receive from the data queue, either in first-in-
first-out (FIFO), last-in-first-out (LIFO), or in keyed-queue order.
Data queues have the ability to attach a sender ID to each message being placed on the
queue. The sender ID, an attribute of the data queue which is established when the queue
is created, contains the qualified job name and current user profile.
In addition to these advantages, you can journal your data queues. This allows you to recover the
object to a consistent state, even if the object was in the middle of some change action when the
abnormal initial program load (IPL) or crash occurred. Journaling also provides for replication of
the data queue journal to a remote system (using remote journal for instance). This lets the system
reproduce the actions in a similar environment to replicate the application work.
The following example shows how data queues work. Several jobs place entries on a data queue.
The entries are handled by a server job. This might be used to have jobs send processed orders to
a single job that would do the printing. Any number of jobs can send to the same queue.
Another example using data queues follows. A primary job gets the work requests and sends the
entries to a data queue (by calling the QSNDDTAQ program). The server jobs receive the entries
from the data queue (by calling the QRCVDTAQ program) and process the data. The server jobs
can report status back to the primary job using another data queue.
Data queues allow the primary job to route the work to the server jobs. This frees the primary job to
receive the next work request. Any number of server jobs can receive from the same data queue.
When no entries are on a data queue, server jobs have the following options:
Wait until an entry is placed on the queue

Wait for a specific period of time; if the entry still has not arrived, then continue processing
Do not wait, return immediately.
Data queues can also be used when a program needs to wait for input from display files, ICF files,
and data queues at the same time. When you specify the DTAQ parameter for the following
commands:
Create Display File (CRTDSPF) command

Change Display File (CHGDSPF) command
Override Display File (OVRDSPF) command
Create ICF File (CRTICFF) command
Change ICF File (CHGICFF) command
Override ICF File (OVRICFF) command
you can indicate a data queue that will have entries placed on it when any of the following
happens:
An enabled command key or Enter key is pressed from an invited display device
Data becomes available from an invited ICF session
Support is available to optionally associate a data queue to an output queue by using the Create
Output Queue (CRTOUTQ) or Change Output Queue (CHGOUTQ) command. The system logs
entries in the data queue when spooled files are in ready (RDY) status on the output queue. A user
program can determine when a spooled file is available on an output queue by using the Receive
Data Queue (QRCVDTAQ) API to receive information from a data queue.
Jobs running on the system can also place entries on the same data queue as the one specified in
the DTAQ parameter by using the QSNDDTAQ program.
An application calls the QRCVDTAQ program to receive each entry placed on the data queue and
then processes the entry based on whether it was placed there by a display file, an ICF file, or the
QSNDDTAQ program.
Create Data Queue:
CRTDTAQ DTAQ(Lib Name/Data Q Name) +
MAXLEN(Length) +
SENDEREID(Attached Sender ID) +
KEYLEN(Key length) +
Text( 'Text')
Delete Data Queue:
DLTDTAQ DTAQ(Lib Name/Data Q Name)
Sending An Entry To Data Q:
CALL PGM(QSNDTAQ) PARM(&Qname &Qlib &Entrylen &Entry)
Receiving An Entry From Data Q:
CALL PGM(QRCVDTAQ) PARM(&Qname &Qlib &Entrylen &Entry &Wait)
Clearing a Data Q:
CALL PGM(QCLRDTAQ) PARM(&Qname &Qlib)
Example: Data Q
PGM
DCL VAR(&NAME) TYPE(*CHAR) LEN(10) VALUE('DTAQ')
DCL VAR(&LIB) TYPE(*CHAR) LEN(10) VALUE('ASIFLIB')
DCL VAR(&LEN) TYPE(*DEC) LEN(5) VALUE(50)
DCL VAR(&DATA) TYPE(*CHAR) LEN(3) VALUE('10')
/* CRTDTAQ DTAQ(ASIFLIB/DTAQ) MAXLEN(64512) */

SNDUSRMSG MSG('DATA Q IS CREATED')
CALL PGM(QSNDDTAQ) PARM(&NAME &LIB &LEN &DATA)
SNDUSRMSG MSG('DATA IS SENT ' || &DATA)
ENDPGM
An Introduction to RPG Chapter 6

The RPG/400 programming language is designed to make it easier for you to create business
software applications. RPG is a language under evolution. A slightly different version of RPG is
available on each machine that supports it. The AS/400 system is the most recent of these
computing systems. You should know that, as well as offering a new enhanced version of RPG,
the AS/400 system also supports the previous versions of RPG available on System/38 and
System/36.
This chapter provides an overview of the following subjects:
The OS/400 system and Control Language (CL)

RPG/400 functions on the AS/400 system
The System/38 Environment on the AS/400 system
Available languages and utilities
The RPG/400 programming cycle
RPG/400 program design
Structured programming in RPG/400 programs
Application design.
Subtopics:
1.1 The OS/400 System

1.2 The AS/400 Control Language
1.3 System/38 Environment on the AS/400 System
1.4 AS/400 Utilities and Languages
1.5 Designing Your RPG/400 Program
1.6 Structured Programming in the RPG/400 Programming Language
1.7 Designing Applications
The OS/400 System
The operating system that controls all of your interactions with the
AS/400 system is called the Operating System/400 (OS/400) system. From
your work station, the OS/400 system allows you to:
Sign on and sign off

Interact with the displays
Use the online help information
Enter control commands and procedures
Respond to messages
Manage files
Run utilities and programs.
Refer to the Publications Guide for a complete list of publications that

discuss the OS/400 system.
The AS/400 Control Language

You can manipulate the OS/400 system with the CL. You interact with the system
by entering or selecting CL commands. The AS/400 system often displays a series
of CL commands or command parameters appropriate to the situation on the screen.
You then select the desired command or parameters.
Commonly Used Control Language Commands

The following table lists some of the most commonly used CL commands,
their function, and the reasons you might want to use them.
________________________________________________________________________
| RPG/400 Function | Associated Control Language Commands and their |
| | Uses |
|_______________________|________________________________________________|
| Calling | CALL program-name Run an RPG/400 program |
| | CALL QCL Access the System/38 |
| | environment |
|_______________________|________________________________________________|
| Commitment Control | CRTJRN Prepare to use commitment |
| | control. |
| | CRTJRNRCV Prepare to use commitment |
| | control. |
| | ENDCMTCTL Notify the system you want |
| | to end commitment control. |
| | JRNPF Prepare to use commitment |
| | control. |
| | STRCMTCTL Notify the system you want |
| | to begin commitment control. |
|_______________________|________________________________________________|
| Compiling | CRTRPGPGM Create RPG Program |
| | CRTRPTPGM Create Auto Report Program |
|_______________________|________________________________________________|
| Consecutive | OVRDBF Override with Database file |
| Processing | |
|_______________________|________________________________________________|
| Control Specification | CRTDTAARA Create Data Area |
| Data Area | DSPDTAARA Display Data Area |
|_______________________|________________________________________________|
| Debugging | ADDBKP Add Breakpoint |
| | ADDTRC Add Trace |
| | DSPBKP Display Breakpoint |
| | STRDBG Start Debug |
|_______________________|________________________________________________|
| Edit Codes | CRTEDTD Create Edit Description (For |
| | User Defined Edit Code) |
| | DSPDTAARA Display Data Area |
|_______________________|________________________________________________|
| Printer Files | CRTPRTF Create Print File |
| | OVRPRTF Override Print File |
|_______________________|________________________________________________|
| System Editor | STRSEU Start Source Entry Utility |
|_______________________|________________________________________________|
AS/400 Utilities and Languages

The AS/400 system offers two utilities and a language that you may find
useful for programming. They are the Screen Design Aid (SDA) utility, the
Source Entry Utility (SEU), and the Structured Query Language (SQL).
Subtopics:
The Source Entry Utility

The Screen Design Aid
The Structured Query Language
The Source Entry Utility
You use the SEU to enter your code into the system. SEU also provides extensive syntax checking.
For more information about SEU, refer to the SEU User's Guide and Reference.
The Screen Design Aid
The SDA utility makes it easier for you to create the displays your program requires. For more
information about SDA, refer to the SDA User's Guide and Reference.
The Structured Query Language
The AS/400 system allows you to insert SQL/400 statements into RPG/400 programs. You enter
SQL/400 statements on a calculation specification. The syntax is shown in Figure 2. You must
observe the following rules:
The starting delimiter /EXEC SQL must be entered into columns 7-15,
with the slash in column 7.
SQL/400 statements can be started on the same line as the starting
delimiter.
SQL/400 statements can be continued on any number of subsequent

continuation lines. The continuation line delimiter is the + in
column 7.
SQL/400 statements cannot go past column 74.
The ending delimiter /END-EXEC must be entered in columns 7-15, with

the slash in column 7, on a separate line. This signals the end of
the SQL/400 statements. It must be entered by itself, with no SQL/400
statements following it.
C |
C/EXEC SQL (the starting delimiter)
C+
C+ (continuation lines containing SQL statements)
C+
.
C/END-EXEC (the ending delimiter)
C |
C |
Figure 2. Syntax for Entering SQL/400 Statements into an RPG/400 Program
You must enter a separate command to process the SQL/400 statements.
Refer to the SQL/400* Programmer's Guide and the SQL/400* Reference for
the descriptions of how to code SQL/400 statements.
Subtopics:
Restrictions
Restrictions
In the RPG/400 programming language, SQL/400 statements cannot be specified in the referred
source member of a /COPY statement. You should not use SQL/400 statements in an RPG
automatic report program. Instead, you should use the CRTRPTPGM command to process your
RPG automatic report programs and to save the generated RPG/400 source. Automatic report
will generate RPG/400 source, to which you can add SQL/400 statements. To process your
SQL/400 statements and generate an RPG object program, you should use the SQL/400
preprocessor. If SQL/400
statements are processed by the RPG/400 automatic report preprocessor, unpredictable results
may occur. Refer to the SEU User's Guide and Reference for information on how the SEU
handles SQL/400 statement syntax checking, and to the SQL/400* Programmer's Guide and the
SQL/400* Reference for more information on the SQL/400 preprocessor.
Designing Your RPG/400 Program

Designing a program includes:
Deciding what output you need from your program

Deciding what processing will produce the output you need
Deciding what input is required by and available to your program.
This sequence may seem backwards because it starts at the results (the output) and ends at the
beginning (the input). Designing the output first is like knowing where you are going before you
set out on a trip: it helps you decide the best way to get there.
Subtopics:
Designing the Output

Designing the Processing
Designing the Input
Designing the Output
Your program produces output records. You must decide what to do with those records. In
general, you have three choices (or any combination of the three choices):
You can display them.

You can print them.
You can store them.
If you want to display the output records at your display station, you have to decide what
information you want displayed and how you want it laid out. To define how you want your
displays laid out, you use the display layout sheet. You can then use the SDA utility to create
your own displays. For more information about SDA, refer to the SDA User's Guide and
Reference.
If you want to print the output records, you have to decide what information you want printed
(which fields from which records) and how you want that information laid out on the printed report.
To indicate how you want the printed report laid out, use the printer layout sheet. If you want to
keep the output records in storage, you have to decide what information you want to keep and
how you want to organize the fields in the output records.
After you design all your output records, you code those records on the RPG/400 file description
specifications and output specifications.
Designing the Processing
Designing the processing means planning the calculations that produce the necessary output.
When you design the processing, you must be aware of how the RPG/400 program cycle works.
The RPG/400 program cycle controls certain read and write operations done on each record. As
a result, the program cycle partly determines how you can process your data.
Designing the Input

After you decide what output you need and the calculations that produce the output, the next step
is to determine where the input data for your program will come from. It might come from one or
more files already on the system, from one or more display stations on your system, from one or
more other systems, or from a combination of these sources. You have to know the names used
for input files, the location of fields in the input records, the sequence of record types, the formats
of numeric data, and the indicators used. When you know all these kinds of information, you can
describe your input records on the RPG/400 input specifications.
Data Types & Structured Programming in the RPG/400 Programming Language
Type Description
A Character
E Fixed Binary
D Date Field
F Floating Point
G Graphics character set
I Signed integer
P Packed Decimal
S Zoned Field
T Time Field
U Unsigned Integer Field
Z Time stamp Field
* Pointer Field
Structured programming is an approach to design and coding that makes

programs easy to understand, debug, and modify.
Three structures used in every computer program are:

Sequential operation
Conditional branching
Repeating an operation based on a certain condition.
Ideally, a structured program is a hierarchy of modules that can have a

single entry point and a single exit point. Control is passed downward
through the structure without unconditional branches to higher levels of
the structure.
The following discuss how the three structures can be accomplished in the
RPG/400 programming language.
Subtopics:
Sequential Operation
Conditional Branching
Repeating an Operation
Summary of Structured Programming Operation Codes
Sequential Operation
Sequential operation means any series of instructions that is processed one instruction after
another, without transferring control to another part of the program.
Conditional Branching
Subtopics:
If Else Structure
SELEC Structure
Other Conditional Branching Structures
If Else Structure
An example of an If-Then-Else conditional branching structure in simple English is:
IF the weather is cold,
THEN I will wear my coat;
ELSE, I will leave my coat at home.
Figure 3 is a flowchart of a conditional branch.
Figure .Flowchart of a Conditional Branch

In the RPG/400 programming language, the If-Then-Else structure is carried
out through the operation codes IFxx, ELSE, and END. Figure 4 shows a
design for a conditional branch using the IFxx, ELSE, and END operation
codes.
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ..*

C*
C* In this example, if CENTR equals Y or if CENTR equals N, then
C* indicator 52 is set off by moving '0' to *IN52. If CENTR equals
C* neither Y nor N, then indicator 52 is set on by moving '1' to
C* *IN52. The END statement ends the IF/THEN/ELSE group.
C*
C CENTR IFEQ 'Y'
C CENTR OREQ 'N'
C MOVE '0' *IN52
C ELSE
C MOVE '1' *IN52
C END
SELEC Structure
An example of a SELEC-WHEN-OTHER conditional branching structure in simple english is:
SELEC
WHEN the weather is warm
I will wear my sunhat
I will go to the beach
WHEN the weather is cool
I will wear my jacket
OTHERwise, I will not go outside
Figure is a flowchart of a SELEC-WHEN-OTHER conditional branch.

Figure . Flowchart of a SELEC-WHEN-OTHER Conditional Branch
In the RPG/400 programming language, the SELEC-WHEN-OTHER structure is carried out

through the operation codes of SELEC, WHxx, and OTHER.
Figure shows conditional branching using the SELEC, WHxx, and OTHER operation codes.
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ..*

CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComments++++++*
C*
C* If X equals 1 then do the operations in sequence 1; if
C* X does not equal 1, then if Y=2 and X<10 do the operations
C* in sequence 2. If neither condition is true, then do the
C* operations in sequence 3.
C*
C SELEC
C X WHEQ 1
C : seq 1
C Y WHEQ 2
C X ANDLT10
C : seq 2
C OTHER
C : seq 3
C ENDSL
C*
Other Conditional Branching Structures
There are three other ways you can create conditional branches:
The CASxx operation

The GOTO operation and conditioning indicators
The CABxx operation.
You can also create a branch to a subroutine with the EXSR operation and
conditioning indicators.
Repeating an Operation
The RPG/400 programming language implements three repeat structures-Do, Do

While, and Do Until-by means of the DOWxx, DOUxx, and DO operation codes
and the END operation code.
Subtopics:
Do Operation
Do While Operation
Do Until Operation
Do Operation
Figure is a flowchart of a Do operation, and Figure 8 illustrates the
coding.
Figure Flowchart of a Do Operation
This is how the Do operation works:
1. Set the index field (result field) to the starting value (factor 1).
2. Test if the index field value is greater than the ending value (factor
2).
If the index field value is greater than the ending value, control
passes to the statement following the END statement.
3. If the index field value is not greater than the ending value, the
operations between the DO statement and the END statement are
processed.
4. At END, the index field value is increased by the increment value

specified in factor 2 on the END statement, or by 1 if the increment
is not specified.
5. Control passes to step 2 above.
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ..*

C*
C* The following example illustrates a Do operation. Because factor
C* 1 of the DO statement is blank, the starting value of Y is 1, and
C* because factor 2 of the END statement is blank, the increment
C* value of Y is 1. Factor 2 of the DO statement contains the value
C* 10, which is the ending value for the DO routine.
C*
C Z-ADD1 X 20
C DO 10 Y 30
C X LOKUPTABA TABR 50
C 50 TABR MULT 1.04 RATE 72
C MOVE '1' *IN90
C EXCPT
C MOVE '0' *IN90
C ADD 1 X
C END
Do While Operation
If you test the condition first and then process the operations, the
structure is called a Do While. An example of a Do While operation is:
1. Compare a sum with 5.
2. If the sum is less than 5, add 1 to the sum.
3. Repeat steps 1 and 2 until the sum is equal to or greater than 5.
Figure 9 is a flowchart of a Do While operation, and Figure 10 illustrates

the coding of a Do While operation.
Figure 9. Flowchart of a Do While Operation
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ..*

C*
C* The following code determines if the subfile has been filled.
C* If indicator 32 is off (*IN32 equal 0), the DOWEQ operation
C* processes until the remainder of the subfile is filled with
C* blank records.
C*
C *IN32 DOWEQ'0'
C MOVE *BLANKS STATUS
C MOVE *BLANKS PRCDEX
C MOVE *BLANKS RSCDEX
C Z-ADD0 EHWRKX
C Z-ADD0 ACDATX
C Z-ADD0 TFRRN
C ADD 1 RECNO
C WRITEEMPFIL 32
C END
C* The preceding END denotes the end of the Do While operation.
Figure Design for a Do While Operation Using the DOWxx Operation Code Notice in Figure 10 (the Do
While) that the program first tests if the condition is true. If it is true, the code between the DOW and
the END operations is processed. The program then goes back to test again if the condition is still
true, and the entire cycle is repeated. If the condition is no longer true, control passes to the
instruction immediately following the END operation.
Do Until Operation
If you process the operations first and then test the condition, the structure is called a Do Until
operation. An example of a Do Until operation is:
1. Add 1 to a sum.
2. Compare the sum with 5.
3. If the sum is less than 5, repeat steps 1 and 2 .
Figure 11 is a flowchart of a Do Until operation, and Figure 12

illustrates the coding.
Figure 11. Flowchart of a Do Until Operation
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ..*

CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComments++++++*
C*
C* The following lines of code perform a Do Until condition. The
C* program loops between the DOUEQ statement and the END statement
C* until end of file (*IN50 equal 1) is reached.
C EMPSR BEGSR
C*
C *IN50 DOUEQ'1'
C READ RCEMP 50
C* The following lines of code add current month hours to the year-
C* to-date hours for the employee master file. Since factor 1 is
C* not specified in the statements, factor 2 is added to the result
C* field and the result is placed in the result field. If *INU4
C* is on, this session is being run for year end, and the current
C* year hours are moved to the prior year hours.
C ADD EPHRC EPHRY
C ADD EPNRC EPNRY
C U4 MOVE EPHRY EPHRP
C U4 MOVE EPNRY EPNRP
C* The following code clears the current month hours fields by
C* zeroing them and adding 0 to them. If *INU4 is on, this session
C* is being run for year end, and the current year hours must be
C* zeroed as well.
C Z-ADD0 EPHRC
C Z-ADD0 EPNRC
C U4 Z-ADD0 EPHRY
C U4 Z-ADD0 EPNRY
C* The following code updates the employee master file using the
C* RCEMP format.
C UPDATRCEMP
C END
C* The preceding END statement is associated with the DOUEQ
C* statement.
Summary of Structured Programming Operation Codes
The structured programming operation codes are:
IFxx (If/Then)
ELSE (Else Do)
ENDyy (End)
DO (Do)
DOWxx (Do While)
DOUxx (Do Until)
ANDxx (And)
ORxx (Or)
CASxx (Conditional Invoke Subroutine)
SELEC (Select a module)
WHxx (When)
OTHER (Otherwise).
where xx can be:
GT Factor 1 is greater than factor 2.

LT Factor 1 is less than factor 2.
EQ Factor 1 is equal to factor 2.
NE Factor 1 is not equal to factor 2.
GE Factor 1 is greater than or equal to factor 2.
LE Factor 1 is less than or equal to factor 2.
Blanks Factor 1 is not compared to factor 2 (unconditional processing).
This is valid for CASxx operation only.
and where yy can be:

CS End a CAS group.
DO End a DO, DO UNTIL, or DO WHILE group.
IF End an IF group.
SL End a SELEC group.
Designing Applications
Application design involves determining whether to create one program to do all of the required
functions, or to create multiple programs to make up an application.
Subtopics:
Single Program Design

Modular Program Design
Examples of Application Design
Single Program Design
In a single program design, all functions are done within one program.Single program design
applies to both batch and interactive programs. It is best used when there are few, relatively
simple functions.For example, an interactive inquiry program that accepts a customer number
from an operator, finds the corresponding record in a customer master file, and displays the
record as a simple program that could have a single program design.
A slightly more complex program that might also have a single program design is a file
maintenance program that allows an operator to:
Inquire into a record

Change a record
Delete a record
Add a record.
An example of a batch program that has a single program design is a program that prints a list of
orders that each operator entered during the day.
Modular Program Design
Modular program design includes using multiple programs to do multiple functions, one function
per program. Modular program design can be applied to both batch and interactive programs.
For example, the order entry application shown in Figure 13 is designed to have four programs:
An RPG/400 or CL mainline program

An RPG/400 program that prompts for the customer number and shows
customer information on the display
An RPG/400 program that accepts input of line items from the order
An RPG/400 program that calculates totals for the order.
Mainline Program
________________ Program
| | Call ________________
____| |________| _____________ |_____ Prompt for
| | | | _____________ | Customer
| | | | _____________ | Number
| | |________| _____________ |
| | | |________________|
| | |
| | | Program
| | | Call ________________
| | |________| _____________ |_____ Line Item
| | | | _____________ | Input
| | | | _____________ |
| | |________| _____________ |
| | | |________________|
| | |
| | | Program
| | | Call ________________
| | |________| _____________ |_____ Totals
| | | | _____________ |
| | | | _____________ |
|_____| |________| _____________ |
|________________| |________________|
Figure 13. Modular Design for an Order Entry Application
A modular program design has several potential advantages:
Designing, coding, testing, and maintaining several small programs can be easier than
designing, coding, testing, and maintaining one large, complex program. This choice is a
matter of personal preference, but it is often beneficial to keep your programs small and as
simple as possible.
CL functions can be requested from RPG/400 programs because the AS/400 system allows
RPG/400 programs and CL programs to call one another.
A single, long-running program might have sections of code that run infrequently. A modular
design could arrange to have the seldom-used code called only when needed. A potential
disadvantage of modular program design is the additional calling of programs that is required.
These calls take time to code and might require additional system overhead for program
processing.
Entering RPG/400 Specifications

After designing your program, you must write the individual statements that you will combine into
a source program. These statements are coded on RPG/400 specification sheets. Each line
coded on a specification sheet represents a statement in the source program. Each specification
sheet contains 80 columns. Column headings indicate the kind of information to code in particular
columns.
This chapter describes the kinds of specifications you can enter when creating an RPG/400
source program. This chapter also describes how to use a text editor, such as SEU, to enter this
information directly into the system and thus begin creating your source program online.
Subtopics:
The RPG/400 Specifications

Entering Your Program
The RPG Specifications
There are seven kinds of RPG/400 specifications. When your source program is compiled, these
specifications must be in the following sequence:
RPG/400
1. Control specifications
2. File description specifications
3. Extension specifications
4. Line counter specifications
5. Input specifications
6. Calculation specifications
7. Output specifications.
RPGILE
1. Header specifications
2. File description specifications
3. Declaration specifications
4. Input specifications
5. Calculation specifications
6. Output specifications.
7. Procedure specifications.
Each of these specifications is described briefly in this chapter. The RPG/400 Reference provides
detailed descriptions for these specifications. RPG/400 programs do not have to use all
specifications. A typical program may use file description, input, calculation, and output
specifications.
Subtopics:
The Control Specification

File Description Specifications
Extension Specifications
Line Counter Specifications
Input Specifications
Calculation Specifications
Output Specifications
The Control Specification
The control specification provides the RPG/400 compiler with information about your program and
your system. This includes:
Name of the program

Date format for the program
If an alternative collating sequence or file translation is used.
Note: The control specification is optional.
File Description Specifications
File description specifications describe all the files that your program uses. The information for
each file includes:
Name of the file

How the file is used
Size of records in the file
Input or output device used for the file
If the file is conditioned by an external indicator.
Extension Specifications
Extension specifications describe all record address files, table files, and array files used in the
program. The information includes:
Name of the file, table, or array

Number of entries in a table or array input record
Number of entries in a table or array
Length of the table or array entry.
Line Counter Specifications
Line counter specifications describe the page or form on which output is printed. The information
includes:
Number of lines per page
Line of the page where overflow occurs.
Input Specifications
Input specifications describe the records, fields, data structures and named constants used by the
program. The information in the input specifications includes:
Name of the file

Sequence of record types
Whether record-identifying indicators, control-level indicators,
field-record-relation indicators, or field indicators are used
Whether data structures, lookahead fields, record identification
codes, or match fields are used
Type of each field (alphanumeric or numeric; packed-decimal,
zoned-decimal, or binary format)
Location of each field in the record
Name of each field in the record
Named constants.
Calculation Specifications
Calculation specifications describe the calculations to be done on the data and the order of the
calculations. Calculation specifications can also be used to control certain input and output
operations. The information includes:
Control-level and conditioning indicators for the operation specified

Fields or constants to be used in the operation
The operation to be processed
Whether resulting indicators are set after the operation is processed.
Output Specifications
Output specifications describe the records and fields in the output files and the conditions under
which output operations are processed. The information includes:
Name of the file

Type of record to be written
Spacing and skipping instructions for PRINTER files
Output indicators that condition when the record is to be written
Name of each field in the output record
Location of each field in the output record
Edit codes and edit words
Constants to be written
Format name for a WORKSTN file.
Compiling an RPG/400 Program
There are two environments that you can compile source programs from: the AS/400 system
environment, and the System/38 Environment. Consequently, there are two ways of compiling
source programs. This chapter describes:
Using the CL command CRTRPGPGM to compile an RPG/400 source program in

AS/400 system environment
Using the CL commands CALL QCL and CRTRPGPGM to compile an RPG/400

source program in the System/38 Environment.
This chapter also contains information on interpreting a compiler listing. To compile a program,
you must ensure that the library QTEMP is in the library list. The CL command CRTRPGPGM
calls the compiler to create an RPG/400 program object and a listing. (If externally described files
are used in the program, the OS/400 system provides information about the files to the program
during compilation.) The following figure shows an overview of the compilation process:
Figure. Overview of the Compilation Process
The compiler checks the syntax of the RPG/400 source program line by line and the
interrelationships between the lines. For example, it checks that all field names are defined and, if
a field is multiply defined, that each definition has the same attributes. The RPG/400 compiler
supports a source file record length of 102. In addition to the usual fields of sequence number (6
characters), last-changed date (6 characters), and the data (80 characters), a field of 10
characters that can contain additional information is placed at the end of the record (positions 93-
102). This information is not used by the RPG/400 compiler but is placed on the extreme right of
the compiler listing. You, the programmer, place information into this field. If you want to use the
additional field, create a source file with a record length of 102. The AS/400 system has an IBM-
supplied RPG/400 source file called QRPGSRC, which has a record length of 92.
Indicators
An indicator is a special type of one byte flag, which is always denoted '0' when off and '1' when
on. Indicators are of two types General and Special indicators.
General Indicators may treated as an array of 99 elements.01 through 99.
Special Indicators are
Level Indicators
Halt Indicators
(Page) Overflow indicators
Command key Indicators
Match indicators
First Page Indicators
Return indicators
Level Indicators: A control level indicator is defined by an entry in positions 63 and 64 of the input
specifications, designating an input field as a control field. It can then be used to condition
calculation and output operations. The valid control level indicator entries are L1 through L9.
Halt Indicators:H1 H9 This indicator can be set on you feel that a severe error has occurred. You
should not use the same halt indicator for more than one error condition.
Page Overflow Indicators:An overflow indicator is defined by the OFLIND keyword on the file
description specifications. It is set on when the last line on a page has been printed or passed.
Valid indicators are *INOA through *INOG, *INOV, and *IN01 through *IN99. A defined overflow
indicator can then be used to condition calculation and output operations. A description of the
overflow indicator and fetch overflow logic is given in Overflow Routine.
Command Key Indicators: These indicators are set on when the corresponding command key is
pressed. [CF1] sets on KA, [CF2] sets on KB and so on.
Match Indicators: Match indicator MR is set on when a record i the primary file matches a record
in a secondary file and does not work in fully procedural programs i.e it does not work outside the
cycle.
First Page Indicators: 1P The first page indicators is meaningful only with internally defined output
files used within the cycle. It provides a way of ensuring that the first pages heading print before
the firs detail line.
You can specify the following indicators on the RPG IV specifications:

Overflow indicator (the OFLIND keyword on the file description specifications).
Record identifying indicator (positions 21 and 22 of the input specifications).
Control level indicator (positions 63 and 64 of the input specifications).
Field indicator (positions 69 through 74 of the input specifications).
Resulting indicator (positions 71 through 76 of the calculation specifications).
*IN array, *IN(xx) array element or *INxx field (See Indicators Referred to As Data for a
description of how an indicator is defined when used with one of these reserved words.).
The defined indicator can then be used to condition operations in the program.
Prompt Type D:
Name - Type the name of the data structure, data-structure subfield, named constant, table,
standalone field, or array definition. You can leave this field blank within data-structures.
E -Choose from the following:

Blank Leave the field blank if the item specified in the Name field is not
an externally described data structure.
E Type E if the item specified in the Name field is an externally
described data structure.
Note: The entry in positions 24 to 25 must be DS for data structure
S/U:Choose from the following:

Blank Leave the field blank if this is not a program-status or a data-area data structure.
S Type S if this is a program-status data structure.
U Type U if this a data-area data structure.
Declaration Type:Choose from the following:
Blank Leave the field blank if this specification does not define a data structure, a constant, a
standalone field, an array, or a table.
DS Type DS if this specification defines a data structure.
C Type C if this specification defines a constant.
PI Type PI if this specification defines a procedure interface.
PR Type PR if this specification defines a prototype for a call.
S Type S if this specification defines a standalone field, an array,
or a table.
From: Chose the following
Blank Leave the field blank to indicate that the To/Length field is the length of the field.
1-32767 Type a value from 1 to 32767 to indicate the beginning position of the field.
Keyword Type a special keyword to define the beginning position of thew subfield in the data
structure.
For a program status data structure choose from the following:
o *PARMS
o *PROC
o *ROUTINE
o *STATUS
For an information data structure choose from the following:
o *FILE
o *OPCODE
o *RECORD
o *ROUTINE
o *STATUS
Internal Data Type:Choose from the following:
Blank Leave the field blank for a character field, or a packed decimal
standalone field, or a zoned decimal field data structure subfield.
For zoned or packed data types, the decimal positions field must be
nonblank.
A Type A if this is a character field.

B Type B if this is a fixed binary field.
D Type D if this is a date field.
F Type F if this is a floating-point field.
G Type G if this is a graphic character field.
I Type I if this is a signed integer field.
N Type N if this is an indicator field.
P Type P if this is a packed decimal field.
S Type S if this is a zoned field.
T Type T if this is a time field.
U Type U if this is a unsigned integer field.
Z Type Z if this is a timestamp field.
* Type * if this is a pointer field.
Keywords: Chose from the following
Choose from the following keywords( Keyword Syntax ):
ALIGN
Type this keyword if alignment is required for signed and unsigned
integer subfields.
ALT(array_name)
Indicates that the compile-time or pre-runtime array or table is in
alternating format.
ALTSEQ(*NONE)
Specifies that the normal collating sequence is to be used for
character comparison even when an alternate collating sequence is
specified. This keyword is valid for character definitions.
ASCEND or DESCEND
ASCEND indicates that the array or table is in ascending sequence.
DESCEND indicates that the array or table is in descending sequence.
BASED(ptr)
Indicates that the data structure, run-time array or table, or field
definitions are based on the pointer.
CONST(literal)
Specifies the value of a named constant.
CTDATA
Specifies that the array is a compile-time array.
DATFMT(format{separator})
Specifies the date format for a date type field.
Choose one of the following date formats:

*MDY (mm/dd/yy)
*DMY (dd/mm/yy)
*YMD (yy/mm/dd)
*JUL (yy/ddd)
*ISO (yyyy-mm-dd)
*USA (mm/dd/yyyy)
*EUR (dd.mm.yyyy)
*JIS (yyyy-mm-dd)
The separator is optional. If you specify an ampersand (&) as the eparator, a blank is used as the
separator character.
DIM(numeric_constant) Specifies the number of elements of an array or table.
DTAARA{(data_area_name)}
Specifies the name of the external data area that is associated with a field, data structure, data
structure subfield, or data area data structure.
EXPORT{(external-name)}
Indicates that the storage for the field is allocated in this module, and optionally specifies the
external name of the exported variable.
EXTFLD(ext_field_name)
Specifies which field in the externally described data structure is renamed.
EXTFMT(data_type)
Choose one of the following external data type values:
B Binary
F Floating-point
I Integer
L Numeric sign Left
P Packed Decimal
R Numeric sign Right
S Zoned numeric
U Unsigned
Keywords: Choose from the following keywords( Keyword Syntax ):

EXTNAME(file_name{:format_name})
Specifies the name of the externally described file and optionally the format name used to
describe the externally described data structure.
EXTPGM(name)
Type this keyword on a prototype definition to indicate the external name of a dynamically-
bound program.
EXTPROC(name)
Type this keyword on a prototype definition to indicate the external name of a statically-bound
procedure.
FROMFILE(file_name)
Specifies the file name for the prerun-time array or table to be read from.
IMPORT{(external-name)}
Indicates that the storage for the field is allocated in another module and optionally specifies
the external name of the imported variable.
LIKE(like_name)
Specifies that the attributes of the item are derived from 'like_name'.
NOOPT
Use this keyword to ensure that the content of the field or structure contains the latest assigned
value.
OCCURS(numeric_constant)
Defines the number of occurrences of a multiple occurrence data structure.
OPDESC
Type this keyword on a prototype definition to indicate that operational descriptors are to be
passed with the parameters.
OPTIONS(*NOPASS *OMIT *VARSIZE *STRING)
Type this keyword on the parameter definition.
*NOPASS indicates that the parameter does not have to be passed.
*OMIT means that the special value *OMIT may be passed. Both *OMIT
and *NOPASS may be specified for the same parameter.
*VARSIZE indicates that your program can receive character, graphic, or array parameters
passed by reference that are shorter than the length defined for the parameter.
*STRING means that you can pass character strings where a basing pointer is expected.
When a pointer parameter is prototyped with OPTIONS(*STRING), then either a pointer or a
character expression can be specified as the passed parameter. If a character expression is
specified, then the compiler will copy the value of the expression to a temporary pointer and add a
null-terminator at the end. Then it will pass the address of this temporary pointer to the called
procedure.
OVERLAY(name{:position})
For data structure subfields, indicates that the subfield overlays the storage of the subfield
specified by the name value at the position value.
PACKEVEN
Type this keyword to indicate that the packed field, or the elements of a packed array, has an
even number of digits. The PACKEVEN keyword is valid only for program-described data-
structure subfields where FROM/TO positions are used to define the field.
PERRCD(numeric_constant)
Specifies the number of elements per record for a compile-time or a prerun-time array or table.
PREFIX(prefix_name{:nbr_of_characters_replaced})
Type the prefix to be applied to the names of all fields defined in all records of an externally
described file.
PROCPTR
Defines a pointer as a procedure pointer.
STATIC
Type this keyword in the D specifications of sub-procedures to indicate that a standalone field
or data structure is stored in static storage.
TIMFMT(format{separator})
Specifies the time format for a time type field.
Choose one of the following time formats:
*HMS (hh:mm:ss)
*ISO (hh.mm.ss)
*USA (hh:mm AM or hh:mm PM)
*EUR (hh.mm.ss)
*JIS (hh:mm:ss)
The separator is optional. If you specify an ampersand (&) as the oeparator, a blank is used as
the separator character.
VALUE
Type this keyword on a parameter definition to indicate that the parameter is passed by value.
TOFILE(file_name)
Specifies the file for a prerun-time or compile-time array or table that the data is written to.
VARYING
Specify this keyword on any character or graphic field definition, to indicate that the field can
have both a maximum length and a current length.
Programs ILERPG
Example 1: To Add Two Number
DCON1 C CONST('Asif.shaik M.Tech')
DNUM1 S 3I 0 INZ(10)
DNUM2 S 3I 0 INZ(20)
DRES S 5I 0
C CON1 DSPLY
C EVAL RES = NUM1 + NUM2
C RES DSPLY
C EVAL RES = NUM1 - NUM2
C RES DSPLY
C EVAL RES = NUM1 * NUM2
C RES DSPLY
C EVAL RES = NUM1 / NUM2
C RES DSPLY
C Seton LR
Example 2:Rounding Results Of Calculation
DNUM1 S 5S 3 INZ(1.124)
DNUM2 S 5S 3 INZ(0.001)
DRES S 5S 2 INZ(0)
C EVAL RES = NUM1 + NUM2
C RES DSPLY
C EVAL (H) RES = NUM1 + NUM2
C RES DSPLY
C Seton LR
OUTPUT:1.13(ROUNDED) 1.12 (NOT ROUNDED)
Example 3:Biggest of Two Numbers
DNUM1 S 5S 0 INZ(10)
C IF NUM1 > NUM2
C NUM1 DSPLY
C ELSE
C NUM2 DSPLY
C ENDIF
C Seton LR
OUTPUT:20
Example 4:Biggest Of Three Numbers
C IF ((NUM1 > NUM2) AND (NUM1 > NUM3))
C NUM1 DSPLY
C ELSE
C IF (NUM2 > NUM3)
C NUM2 DSPLY
C ELSE
C NUM3 DSPLY
C ENDIF
C ENDIF
C Seton LR
OUTPUT:30
Example 5:Sum of 20 Numbers
DNUM1 S 5S 0 INZ(1)
DRES S 5S 0 INZ(0)
C DOW NUM1 <= NUM2
C EVAL RES = RES + NUM1
C EVAL NUM1 = NUM1 +1
C ENDDO
C RES DSPLY
C Seton LR
OUTPUT:210
Example 6:Sum Of 5 Numbers Using Do Until Loop
DNUM1 S 5S 0 INZ(1)
DNUM2 S 5S 0 INZ(5)
DRES S 5S 0 INZ(0)
C DOU NUM1 >= NUM2
C EVAL NUM1 = NUM1 +1
C ENDDO
C RES DSPLY
C Seton LR
OUTPUT:10
Example 7:Sum Of 5 Numbers Using For Loop
DNUM1 S 5S 0 INZ(0)
DRES S 5S 0 INZ(0)
C FOR NUM1=10 DOWNTO 1 BY 2
C ENDFOR
C RES DSPLY
C Seton LR
OUTPUT:30
Example 8:Using ITER
DNUM1 S 5S 0 INZ(1)
C DOW NUM1 <= NUM2
C EVAL NUM1 = NUM1 + 2
C IF NUM1 = 5
C ITER
C ENDIF
C ENDDO
C NUM1 DSPLY
C Seton LR
OUTPUT:11
Example 9:Using LEAVE
DNUM1 S 5S 0 INZ(1)
C DOW NUM1 <= NUM2
C IF NUM1 = 5
C LEAVE
C ENDIF
C ENDDO
C NUM1 DSPLY
C Seton LR
OUTPUT:7
Example 10:Using Select
DMARKS1 S 5S 0 INZ(70)
C SELECT
C MARKS1 WHENLT 35
C MARKS2 ORLT 35
C MARKS3 ORLT 35
C 'FAIL' DSPLY
C OTHER
C 'PASS' DSPLY
C ENDSL
C Seton LR
OUTPUT:FAIL
Programs - Built in Functions ILERPG

%ABS - Absolute Value of Expression
%ADDR - Get Address of Variable
%ALLOC - Allocate Storage
%CHAR - Convert to Character Data
%CHECK - Check Characters
%CHECKR - Check Reverse
%DATE - Convert to Date
%DAYS - Number of Days
%DEC - Convert to Packed Decimal Format
%DECH - Convert to Packed Decimal Format with Half Adjust
%DECPOS - Get Number of Decimal Positions
%DIFF - Difference Between Two Date, Time, or Timestamp Values
%DIV - Return Integer Portion of Quotient
%EDITC - Edit Value Using an Editcode
%EDITFLT - Convert to Float External Representation
%EDITW - Edit Value Using an Editword
%ELEM - Get Number of Elements
%EOF - Return End or Beginning of File Condition
%EQUAL - Return Exact Match Condition
%ERROR - Return Error Condition
%FLOAT - Convert to Floating Format
%FOUND - Return Found Condition
%GRAPH - Convert to Graphic Value
%HOURS - Number of Hours
%INT - Convert to Integer Format
%INTH - Convert to Integer Format with Half Adjust
%LEN - Get or Set Length
%LOOKUPxx - Look Up an Array Element
%MINUTES - Number of Minutes
%MONTHS - Number of Months
%MSECONDS - Number of Microseconds
%NULLIND - Query or Set Null Indicator
%OCCUR - Set/Get Occurrence of a Data Structure
%OPEN - Return File Open Condition
%PADDR - Get Procedure Address
%PARMS - Return Number of Parameters
%REALLOC - Reallocate Storage
%REM - Return Integer Remainder
%REPLACE - Replace Character String
%SCAN - Scan for Characters
%SECONDS - Number of Seconds
%SHTDN - Shut Down
%SIZE - Get Size in Bytes
%SQRT - Square Root of Expression
%STATUS - Return File or Program Status
%STR - Get or Store Null-Terminated String
%SUBDT - Extract a Portion of a Date, Time, or Timestamp
%SUBST - Get Substring
%THIS - Return Class Instance for Native Method
%TIME - Convert to Time
%TIMESTAMP- Convert to Timestamp
%TLOOKUPxx - Look Up a Table Element
%TRIM - Trim Blanks at Edges
%TRIML - Trim Leading Blanks
%TRIMR - Trim Trailing Blanks
%UCS2 - Convert to UCS-2 Value
%UNS - Convert to Unsigned Format
%UNSH - Convert to Unsigned Format with Half Adjust
%XFOOT - Sum Array Expression Elements
%XLATE - Translate
%YEARS - Number of Years
Example 11:
* Syntax
* %ABS(numeric expression)
*
* %ABS returns the absolute value of the numeric expression specified
* as the parameter. If the value of the numeric expression is
* non-negative, the value is returned unchanged. If the value is
* negative, the value returned is the value of the expression but with
* the negative sign removed.
*
DPi C const(3.1432)
DRadious S 7P 2 Inz(-5.2)
DArea S 7P 2 Inz(0.0)
C Eval Area = Pi * %ABS(Radious)**2
C Area Dsply
C SETON LR
* OUTPUT Area = 8499
Example 12:
* SYNTAX
* %CHAR(expression{:format})
*
* %CHAR converts the value of the expression from graphic, UCS-2,
* numeric, date, time or timestamp data to type character. The
* converted value remains unchanged, but is returned in a format that
* is compatible with character data.
*
* If the parameter is a constant, the conversion will be done at compi
* time
DNum1 S 5i 0 Inz(504)
DStr1 C Const('Asif.Shaik ID:')
DRes S 20A
C Eval Res = Str1 + %CHAR(Num1)
C Res Dsply
C SETON LR
* OUTPUT Res = Asif.Shaik ID:504
Example 13:
* SYNTAX : %CHECK(comparator : base {: start})
*
DRes S 3I 0 Inz(0)
C Eval Res = %CHECK('i':Str1:9)
C Res Dsply
C SETON LR
Example 14:
DDIGITS C '0123456789'
C Z-ADD 0 N 1 0
C MOVE '$1200' SALARY 6
C DIGITS CHECK SALARY:2 N
C IF %FOUND
C N DSPLY
C ENDIF
C SETON LR
Example 15:
* SYNTAX : %CHECK(comparator : base {: start})

*
DRes S 3I 0 Inz(0)
C Eval Res = %CHECK('i':Str1:9)
C Res Dsply
C SETON LR
Example 16:
* %LEN(expression)
* %LEN can be used to get the length of a variable expression or to se
* the current length of a variable-length field.
DNum1 S 7P 2
DNum2 S 5S 1
DNum3 S 5I 0 Inz(10)
DRes S 5I 0 Inz(0)
C Eval Res = %Len(Num1)
C Res Dsply
C Eval Res = %DecPos(Num2)
C Res Dsply
C Eval Res = %Len(Num1*Num2)
C Res Dsply
C SETON LR
Example 17:
* SYNTAX
* %REPLACE(replacement string: source string{:start position {:source
* length to replace}})
*
* %REPLACE returns the character string produced by inserting a
* replacement string into the source string, starting at the start
* position and replacing the specified number of characters.
*
DStr1 S 20A Inz('Asif.Shaik') Varying
DStr2 S 20A Varying
C Eval Str1 = Str1 + ',' + '4Soft'
C Str1 Dsply
C Eval Str2 = %Replace('M.Tech' : Str1 : 12)
C Str2 Dsply
C SETON LR
Example 18:
* SYNTAX
* %SUBST(string:start{:length})
*
* %SUBST returns a portion of argument string. It may also be used as
* result of an assignment with the EVAL operation code.
DStr1 S 20A Inz('Asif.Shaik') Varying

DStr2 S 20A Varying
C Eval Str1 = Str1 + ',' + '4Soft'
C Str1 Dsply
C Eval Str2 = %SUBST(Str1:1:4)
C Str2 Dsply
C SETON LR
Example 19:
* SYNTAX
* %TRIM(string)
*
* %TRIM returns the given string less any leading and trailing blanks.
*
DStr1 S 20A Inz(' Asif')
DStr2 S 20A Inz(' Shaik')
C Eval Str2 = Str1 + '.' + Str2
C Str2 Dsply
C Eval Str2 = %Trim(Str1) + '.' + %Trim(Str2)
C Str2 Dsply
C Eval Str2 = %TrimR(Str1)
C Str2 Dsply
C Eval Str2 = %Trim(Str1)
C Str2 Dsply
C SETON LR
Example 20:
* SYNTAX
* %SCAN(search argument : source string {: start})
*
* %SCAN returns the first position of the search argument in the
* source string, or 0 if it was not found. If the start position is
* specified, the search begins at the starting position. The result is
* always the position in the source string even if the starting
* position is specified. The starting position defaults to 1.
*
DName S 15A Inz('Asif.Shaik')
DPos S 5U 0
C Eval Pos = %Scan('S':Name)
C Pos Dsply
C SETON LR
* OUTPUT : Pos = 6
Example 21:
* SYNTAX
* %SQRT(numeric expression)
* %SQRT returns the square root of the specified numeric expression.
* If the operand is of type float, the result is of type float;
* otherwise, |the result is packed decimal numeric. If the parameter
* has a value less |than zero, exception 00101 is issued.
*
DNum1 S 10i 0
DNum2 S 9p 2
DNum3 S 4f
C Eval Num1 = %Sqrt(239874)
C Num1 Dsply
C Num2 Dsply
C Num3 Dsply
C SETON LR
* OUTPUT : Num1 = 489
* OUTPUT : Num2 = 489.76
* OUTPUT : Num3 = +4.8976936E+02
Example 22:
* SYNTAX
*
* %DATE{(expression{:date-format})}
* %DATE converts the value of the expression from character, numeric,
* or timestamp data to type date. The converted value remains
* unchanged, but is returned as a date.
*
DStr C Const('121406')
DDate S D
C Eval Date = %Date(Str:*MDY0)
C Date Dsply
C SETON LR
Example 23:
* SYNTAX
*
* %TIME{(expression{:time-format})}
* %TIME converts the value of the expression from character, numeric,
* ortimestamp data to type time. The converted value remains
* unchanged, but is returned as a time.
*
DStr C Const('12:14 PM')
DTime S T
C Eval Time = %Time(Str:*USA)
C Time Dsply
C SETON LR
*OUTPUT Time : 12.14.00
Example 24:
* SYNTAX
* %DAYS(number) + %MONTHS(number)
* %DAYS converts a number into a duration that can be added to a date
* or timestamp value.
* %DAYS can only be the right-hand value in an addition or
* subtraction operation. The left-hand value must be a date or
* timestamp. The result is a date or timestamp value with the
* appropriate number of days added or subtracted. For a date, the
* resulting value is in *ISO format.
*
DDate S D
C Date Dsply
C Eval Date = Date + %Days(10)
C Date Dsply
C SETON LR
*
* OUTPUT :2006-12-14
* 2006-12-24
Example 25:
* SYNTAX
* %DAYS(number) + %MONTHS(number)
* %DAYS converts a number into a duration that can be added to a date
* or timestamp value.
* %DAYS can only be the right-hand value in an addition or
* subtraction operation. The left-hand value must be a date or
* timestamp. The result is a date or timestamp value with the
* appropriate number of days added or subtracted. For a date, the
* resulting value is in *ISO format.
*
DDate S D
C Date Dsply
C Eval Date = Date + %Months(02)
C Date Dsply
C Date Dsply
C SETON LR
*
* OUTPUT :2006-12-14
* 2007-02-14
Example 26:
* SYNTAX
* %REM(n:m)
* %REM returns the remainder that results from dividing operands n by
* m. The two operands must be numeric values with zero decimal
* positions. If either operand is a packed, zoned, or binary numeric
* value, the result is packed numeric. If either operand is an integer
* numeric value, the result is integer. Otherwise, the result is
* unsigned numeric. Float numeric operands are not allowed. The result
* has the same sign as the dividend. (See also %DIV (Return Integer
* Portion of Quotient).)
*
* %REM and %DIV have the following relationship:
*
* %REM(A:B) = A - (%DIV(A:B) * B)
*
DRes S 3i 0 Inz(0)
C Eval Res = %Div(Num2:Num1)
C Res Dsply
C Eval Res = %Rem(Num2:Num1)
C Res Dsply
C SETON LR
*
* OUTPUT :2
* 0
Example 27:
*Reserved Words
C *Date Dsply
C *Month Dsply
C *Year Dsply
C *Day Dsply
C SETON LR
*OUTPUT:12142006
* 12
* 2006
* 14
Example 28:
* SYNTAX
HDATFMT(*MDY)
DDate S D
C Date Dsply
C SETON LR
* OUTPUT:
* DATFMT(*YMD) = 06/12/14 DATFMT(*YMD-) = 06-12-14
* DATFMT(*DMY) = 14/12/06 VALID SEPERATORS ARE - . /
* DATFMT(*MDY) = 12/14/06
* DATFMT(*ISO) = 2006-12-14
* DATFMT(*USA) = 12/14/2006
* DATFMT(*EUR) = 14.12.2006
* DATFMT(*JIS) = 2006-12-14
Example 29:
* TO Check Whether the given String is Palindrome Or Not

DStr1 S 20A Inz('MALAYALAM') Varying
DStr2 S 20A Varying
DLen S 3i 0
C Eval Len = %len(%trim(Str1))
C Dow Len >= 1
C Eval Str2 = Str2 + %Subst(Str1:Len:1)
C Eval Len = Len-1
C Enddo
C*
C IF Str1 = Str2
C 'Palin' Dsply
C Else
C 'Not Pa' Dsply
C Endif
C SETON LR
Interactive Source Debugger

Step1 : Compile the program with Debugging Views set to *SOURCE. This allows the debugger to
access the source code of the program and display it.
Step2 : Use STRDBG and press F4. Specify Display Module Source parameter as *YES. Press
enter.
Step3 : The source code will be displayed. Take the cursor to the line that needs break point and
press F6.
H Specification
Example 30: Example On H Specification.
*Valid Date Formats : *ISO *MDY *YMD *JUL *USA *JIS *EUR
*Valid Date Formats : *HMS *USA *EUR *JIS
*For Date Separators : DATFMT(DMY-)
HDATFMT (*YMD) CURSYM('')

DDATE1 S D INZ(D'06/08/19')
C DATE1 DSPLY
C Seton LR
Output:06/08/19
Example 31:Example On Time Formats
HTIMFMT (*HMS)
DSTRTIM S T INZ(T'07:00:00')
DENDTIM S T INZ(T'10:50:00')
DH1 S 3S 0
DM1 S 3S 0
C STRTIM DSPLY
C ENDTIM DSPLY
C ENDTIM SUBDUR STRTIM H1:*H
C ENDTIM SUBDUR STRTIM M1:*MN
C H1 DSPLY
C M1 DSPLY
C Seton LR
Output:07:00:00
10:50:00
3
230
Example 32:Example On Subtract Duration
The SUBDUR operation can be used to subtract a duration specified in factor

2 from a field or constant specified in factor 1 and place the resulting
Date, Time or Timestamp in the field specified in the result field.
HDATFMT (*DMY)
C DATE1 SUBDUR 3:*DAYS DATE2
C DATE2 DSPLY
C Seton LR
Output:16/08/06
Example 33:Example On Subtract Duration
HDATFMT (*DMY)
DDATE1 S 8D INZ(D'19/08/06')
DDATE2 S 8D
DNUM S 2S 0 INZ(31)
C DATE1 ADDDUR NUM:*DAYS DATE2
C DATE2 DSPLY
C Seton LR
Output:19/09/06
Example 34:Extracting Date, Month, Year From Date
H DATFMT(*ISO)
DDATE1 S D INZ(D'2006-03-10')
DYY S 4S 0 INZ(0)
DMM S 2S 0 INZ(0)
DDD S 2S 0 INZ(0)
C EXTRCT DATE1:*Y YY
C EXTRCT DATE1:*M MM
C EXTRCT DATE1:*D DD
C YY DSPLY
C MM DSPLY
C DD DSPLY
C Seton LR
Output:2006
3
Arrays & Tables

Arrays and tables are both collections of data fields (elements) of the same:
Field length
Data type
Character
Numeric
Date
Time
Timestamp
Graphic
Basing Pointer
Procedure Pointer
UCS-2
Format
Number of decimal positions (if numeric)
Arrays and tables differ in that:
You can refer to a specific array element by its position
You cannot refer to specific table elements by their position
An array name by itself refers to all elements in the array
A table name always refers to the element found in the last LOOKUP (Look Up a Table or
Array Element) operation
Note:
You can define only run-time arrays in a subprocedure. Tables, prerun-time arrays, and compile-
time arrays are not supported.
Types Of Arrays
There are three types of arrays:
The run-time array is loaded by your program while it is running.
The compile-time array is loaded when your program is created. The initial data becomes
a permanent part of your program.
The prerun-time array is loaded from an array file when your program begins running,
before any input, calculation, or output operations are processed.
The essentials of defining and loading an array are described for a run-time array. For defining
and loading compile-time and prerun-time arrays you use these essentials and some additional
specifications.
Array Name and Index

You refer to an entire array using the array name alone. You refer to the individual elements of an
array using (1) the array name, followed by (2) a left parenthesis, followed by (3) an index,
followed by (4) a right parenthesis -- for example: AR(IND). The index indicates the position of the
element within the array (starting from 1) and is either a number or a field containing a number.
The following rules apply when you specify an array name and index:
The array name must be a unique symbolic name.
The index must be a numeric field or constant greater than zero and with zero decimal positions
If the array is specified within an expression in the extended factor 2 field, the index may be an
expression returning a numeric value with zero decimal positions
At run time, if your program refers to an array using an index with a value that is zero, negative, or
greater than the number of elements in the array, then the error/exception routine takes control of
your program.
The Essential Array Specifications

You define an array on a definition specification. Here are the essential specifications for all
arrays:
Specify the array name in positions 7 through 21
Specify the number of entries in the array using the DIM keyword
Specify length, data format, and decimal positions as you would any scalar fields. You may
specify explicit From- and To-position entries (if defining a subfield), or an explicit Length-
entry; or you may define the array attributes using the LIKE keyword; or the attributes may
be specified elsewhere in the program.
If you need to specify a sort sequence, use the ASCEND or DESCEND keywords.
Loading a Run-Time Array

You can assign initial values for a run-time array using the INZ keyword on the definition
specification. You can also assign initial values for a run-time array through input or calculation
specifications. This second method may also be used to put data into other types of arrays.
For example, you may use the calculation specifications for the MOVE operation to put 0 in each
element of an array (or in selected elements).
Using the input specifications, you may fill an array with the data from a file. The following
sections provide more details on retrieving this data from the records of a file.
Note:
Date and time runtime data must be in the same format and use the same separators as the date
or time array being loaded.
Loading a Run-Time Array in One Source Record
If the array information is contained in one record, the information can occupy consecutive
positions in the record or it can be scattered throughout the record.
If the array elements are consecutive on the input record, the array can be loaded with a single
input specification. Figure shows the specifications for loading an array, INPARR, of six elements
(12 characters each) from a single record from the file ARRFILE.
Figure Using a Run-Time Array with Consecutive Elements

*...1....+....2....+....3....+....4....+....5....+....6....+....7...
DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++
DINPARR S 12A DIM(6)
IFilename++SqNORiPos1+NCCPos2+NCCPos3+NCC................................
I........................Fmt+SPFrom+To+++DcField+++++++++L1M1FrPlMnZr....
IARRFILE AA 01
I 1 72 INPARR
If the array elements are scattered throughout the record, they can be defined and loaded one at
a time, with one element described on a specification line. Figure shows the specifications for
loading an array, ARRX, of six elements with 12 characters each, from a single record from file
ARRFILE; a blank separates each of the elements from the others.
Figure Defining a Run-Time Array with Scattered Elements

*...1....+....2....+....3....+....4....+....5....+....6....+....7...
DARRX S 12A DIM(6)
IFilename++SqNORiPos1+NCCPos2+NCCPos3+NCC................................
I........................Fmt+SPFrom+To+++DcField+++++++++L1M1FrPlMnZr....
IARRFILE AA 01
I 1 12 ARRX(1)
I 14 25 ARRX(2)
I 27 38 ARRX(3)
I 40 51 ARRX(4)
I 53 64 ARRX(5)
I 66 77 ARRX(6)
Loading a Run-Time Array Using Multiple Source Records

If the array information is in more than one record, you may use various methods to load the
array. The method to use depends on the size of the array and whether or not the array elements
are consecutive in the input records. The ILE RPG program processes one record at a time.
Therefore the entire array is not processed until all the records containing the array information
are read and the information is moved into the array fields. It may be necessary to suppress
calculation and output operations until the entire array is read into the program.
Sequencing Run-Time Arrays
Run-time arrays are not sequence checked. If you process a SORTA (sort an array) operation, the
array is sorted into the sequence specified on the definition specification (the ASCEND or
DESCEND keywords) defining the array. If the sequence is not specified, the array is sorted into
ascending sequence. When the high (positions 71 and 72 of the calculation specifications) or low
(positions 73 and 74 of the calculation specifications) indicators are used in the LOOKUP
operation, the array sequence must be specified.
Coding a Compile-Time Array
A compile-time array is specified using the essential array specifications plus the keyword
CTDATA. In addition, on a definition specification you can specify:
The number of array entries in an input record using the PERRCD keyword. If the keyword
is not specified, the number of entries defaults to 1.
The external data format using the EXTFMT keyword. The only allowed values are L (left-
sign), R (right-sign), or S (zoned-decimal). The EXTFMT keyword is not allowed for float
compile-time arrays.
A file to which the array is to be written when the program ends with LR on. You specify
this using the TOFILE keyword.
See Figure 67 for an example of a compile-time array.
Loading a Compile-Time Array

For a compile-time array, enter array source data into records in the program source member. If
you use the **ALTSEQ, **CTDATA, and **FTRANS keywords, the array data may be entered in
anywhere following the source records. If you do not use those keywords, the array data must
follow the source records, and any alternate collating sequence or file translation records in the
order in which the compile-time arrays and tables were defined on the definition specifications.
This data is loaded into the array when the program is compiled. Until the program is recompiled
with new data, the array will always initially have the same values each time you call the program
unless the previous call ended with LR off.
Compile-time arrays can be described separately or in alternating format (with the ALT keyword).
Alternating format means that the elements of one array are intermixed on the input record with
elements of another array.
Rules for Array Source Records
The rules for array source records are:
The first array entry for each record must begin in position 1.
All elements must be the same length and follow each other with no intervening spaces
An entire record need not be filled with entries. If it is not, blanks or comments can be
included after the entries (see Figure 67).
If the number of elements in the array as specified on the definition specification is greater
than the number of entries provided, the remaining elements are filled with the default
values for the data type specified.
Figure 67. Array Source Record with Comments
DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++++++
DARC S 3A DIM(12) PERRCD(5) CTDATA
**CTDATA ARC
48K16343J64044HComments can be placed here
12648A47349K346Comments can be placed here
50B125 Comments can be placed here
Each record, except the last, must contain the number of entries specified with the
PERRCD keyword on the definition specifications. In the last record, unused entries must
be blank and comments can be included after the unused entries.
Each entry must be contained entirely on one record. An entry cannot be split between two
records; therefore, the length of a single entry is limited to the maximum length of 100
characters (size of source record). If arrays are used and are described in alternating
format, corresponding elements must be on the same record; together they cannot exceed
100 characters.
For date and time compile-time arrays the data must be in the same format and use the
same separators as the date or time array being loaded.
Array data may be specified in one of two ways:
**CTDATA arrayname: The data for the array may be specified anywhere in the compile-
time data section.
**b: (b=blank) The data for the arrays must be specified in the same order in which they
are specified in the Definition specifications.
Only one of these techniques may be used in one program.
Arrays can be in ascending(ASCEND keyword), descending (DESCEND keyword), or no
sequence (no keyword specified).
For ascending or descending character arrays when ALTSEQ(*EXT) is specified on the
control specification, the alternate collating sequence is used for the sequence checking. If
the actual collating sequence is not known at compile time (for example, if
SRTSEQ(*JOBRUN) is specified on a control specification or as a command parameter)
the alternate collating sequence table will be retrieved at runtime and the checking will
occur during initialization at *INIT. Otherwise, the checking will be done at compile time.
Graphic and UCS-2 arrays will be sorted by hexadecimal values, regardless of the
alternate collating sequence.
If L or R is specified on the EXTFMT keyword on the definition specification, each element
must include the sign (+ or -). An array with an element size of 2 with L specified would
require 3 positions in the source data as shown in the following example.
*....+....1....+....2....+....3....+....4....+....5....+....6....+....*
D UPDATES 2 0 DIM(5) PERRCD(5) EXTFMT(L) CTDATA

**CTDATA UDPATES
+37-38+52-63-49+51
Float compile-time data are specified in the source records as float or numeric literals.
Arrays defined as 4-byte float require 14 positions for each element; arrays defined as 8-
byte float require 23 positions for each element.
Graphic data must be enclosed in shift-out and shift-in characters. If several elements of
graphic data are included in a single record (without intervening nongraphic data) only one
set of shift-out and shift-in characters is required for the record. If a graphic array is
defined in alternating format with a nongraphic array, the shift-in and shift-out characters
must surround the graphic data. If two graphic arrays are defined in alternating format,
only one set of shift-in and shift-out characters is required for each record.
Coding a Prerun-Time Array
In addition to the essential array specifications, you can also code the following specifications or
keywords for prerun-time arrays.
On the definition specifications, you can specify
The name of the file with the array input data, using the FROMFILE keyword.
The name of a file to which the array is written at the end of the program, using the
TOFILE keyword.
The number of elements per input record, using the PERRCD keyword.
The external format of numeric array data using the EXTFMT keyword.
An alternating format using the ALT keyword.
Note:
The integer or unsigned format cannot be specified for arrays defined with more than ten digits.
On the file-description specifications, you can specify a T in position 18 for the file with the array
input data.
Example of Coding Arrays

Figure 68 shows the definition specifications required for two prerun-time arrays, a compile-time
array, and a run-time array.
Figure 68. Definition Specifications for Different Types of Arrays
*....+....1....+....2....+....3....+....4....+....5....+....6....+....*
HKeywords+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
H DATFMT(*USA) TIMFMT(*HMS)
D*ame+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++++++
* Run-time array. ARI has 10 elements of type date. They are
* initialized to September 15, 1994. This is in month, day,
* year format using a slash as a separator as defined on the
* control specification.
DARI S D DIM(10) INZ(D'09/15/1994')
*
* Compile-time arrays in alternating format. Both arrays have
* eight elements (three elements per record). ARC is a character
* array of length 15, and ARD is a time array with a predefined
* length of 8.
DARC S 15 DIM(8) PERRCD(3)
D CTDATA
DARD S T DIM(8) ALT(ARC)
*
* Prerun-time array. ARE, which is to be read from file DISKIN,
* has 250 character elements (12 elements per record). Each
* element is five positions long. The size of each record
* is 60 (5*12). The elements are arranged in ascending sequence.
DARE S 5A DIM(250) PERRCD(12) ASCEND
D FROMFILE(DISKIN)
*
* Prerun-time array specified as a combined file. ARH is written
* back to the same file from which it is read when the program
* ends normally with LR on. ARH has 250 character elements
* (12 elements per record). Each elements is five positions long.
* The elements are arranged in ascending sequence.
DARH S 5A DIM(250) PERRCD(12) ASCEND
D FROMFILE(DISKOUT)
D TOFILE(DISKOUT)
**CTDATA ARC
Toronto 12:15:00Winnipeg 13:23:00Calgary 15:44:00
Sydney 17:24:30Edmonton 21:33:00Saskatoon 08:40:00
Regina 12:33:00Vancouver 13:20:00
Searching Arrays
|The following can be used to search arrays: |
|The LOOKUP operation code
|The %LOOKUP built-in function
|The %LOOKUPLT built-in function
|The %LOOKUPLE built-in function
|The %LOOKUPGT built-in function
|The %LOOKUPGE built-in function |
|For more information about the LOOKUP operation code, see: |
|Searching an Array with an Index
|Searching an Array Without an Index
|LOOKUP (Look Up a Table or Array Element) |
|For more information about the %LOOKUPxx built-in functions, see %LOOKUPxx (Look Up an
Array Element).
Searching an Array Without an Index
When searching an array without an index, use the status (on or off) of the resulting indicators to
determine whether a particular element is present in the array. Searching an array without an
index can be used for validity checking of input data to determine if a field is in a list of array
elements. Generally, an equal LOOKUP is requested.
In factor 1 in the calculation specifications, specify the search argument (data for which you want
to find a match in the array named) and place the array name factor 2.
In factor 2 specify the name of the array to be searched. At least one resulting indicator must be
specified. Entries must not be made in both high and low for the same LOOKUP operation. The
resulting indicators must not be specified in high or low if the array is not in sequence (ASCEND
or DESCEND keywords). Control level and conditioning indicators (specified in positions 7
through 11) can also be used. The result field cannot be used.
The search starts at the beginning of the array and ends at the end of the array or when the
conditions of the lookup are satisfied. Whenever an array element is found that satisfies the type
of search being made (equal, high, low), the resulting indicator is set on.
Figure 73 shows an example of a LOOKUP on an array without an index.
Figure 73. LOOKUP Operation for an Array without an Index
*...1....+....2....+....3....+....4....+....5....+....6....+....7...
FFilename++IPEASFRlen+LKlen+AIDevice+.Keywords++++++++++++++++++++++++++++
FARRFILE IT F 5 DISK
F*
DDPTNOS S 5S 0 DIM(50) FROMFILE(ARRFILE)
D*
CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq..
C* The LOOKUP operation is processed and, if an element of DPTNOS equal
C* to the search argument (DPTNUM) is found, indicator 20 is set on.
C DPTNUM LOOKUP DPTNOS 20
ARRFILE, which contains department numbers, is defined in the file description specifications as
an input file (I in position 17) with an array file designation (T in position 18). The file is program
described (F in position 22), and each record is 5 positions in length (5 in position 27).
In the definition specifications, ARRFILE is defined as containing the array DPTNOS. The array
contains 50 entries (DIM(50)). Each entry is 5 positions in length (positions 33-39) with zero
decimal positions (positions 41-42). One department number can be contained in each record
(PERRCD defaults to 1).
Searching an Array with an Index

To find out which element satisfies a LOOKUP search, start the search at a particular element in
the array. To do this type of search, make the entries in the calculation specifications as you would
for an array without an index. However, in factor 2, enter the name of the array to be searched,
followed by a parenthesized numeric field (with zero decimal positions) containing the number of
the element at which the search is to start. This numeric constant or field is called the index
because it points to a certain element in the array. The index is updated with the element number
which satisfied the search or is set to 0 if the search failed.
You can use a numeric constant as the index to test for the existence of an element that satisfies
the search starting at an element other than 1.
All other rules that apply to an array without an index apply to an array with an index.
Figure 74 shows a LOOKUP on an array with an index.
Figure 74. LOOKUP Operation on an Array with an Index
*...1....+....2....+....3....+....4....+....5....+....6....+....7...
FFilename++IPEASFRlen+LKlen+AIDevice+.Keywords++++++++++++++++++++++++++++
FARRFILE IT F 25 DISK
F*
DDPTNOS S 5S 0 DIM(50) FROMFILE(ARRFILE)
DDPTDSC S 20A DIM(50) ALT(DPTNOS)
D*
CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq..
C* The Z-ADD operation begins the LOOKUP at the first element in DPTNOS.
C Z-ADD 1 X 3 0
C* At the end of a successful LOOKUP, when an element has been found
C* that contains an entry equal to the search argument DPTNUM,
C* indicator 20 is set on and the MOVE operation places the department
C* description, corresponding to the department number, into DPTNAM.
C DPTNUM LOOKUP DPTNOS(X) 20
C* If an element is not found that is equal to the search argument,
C* element X of DPTDSC is moved to DPTNAM.
C IF NOT *IN20
C MOVE DPTDSC(X) DPTNAM 20
C ENDIF
This example shows the same array of department numbers, DPTNOS, as Figure 73. However,
an alternating array of department descriptions, DPTDSC, is also defined. Each element in
DPTDSC is 20 positions in length. If there is insufficient data in the file to initialize the entire array,
the remaining elements in DPTNOS are filled with zeros and the remaining elements in DPTDSC
are filled with blanks.
Example1 :
DArray1 S 4S 0 Dim(5)
DNum S 4S 0 Inz(1)
C Num DowLt 5
C Eval Array1(Num) = Num
C Array1(Num) Dsply
C Eval Num = Num + 1
C Enddo
C SETON LR
* OUTPUT :1 2 3 4
Example2 :Compile Time Array

0001.10 DArray1 S 3 Dim(12) CTDATA PERRCD(2)
0001.20 C Movel 'ASF' Var
3
0001.30 C Var Lookup Array1
25
0001.40 C If *In25 = *On
0001.50 C 'Found' Dsply
0001.60 C Else
0001.70 C 'Not Found' Dsply
0001.80 C Endif
0001.90 C Array1(1) Dsply
0004.00 C SETON
LR
0005.00 **
0006.00 JANFEB
0007.00 MARAPR
0008.00 MAYJUN
Example3 :Pre run time array

FPF1 IT F 35 DISK
DArray1 S 35 Dim(25) FROMFILE(PF1) PERRCD(1)
DNum S 4S 0 Inz(1)
C Num DowLt 5
C Array1(Num) Dsply
C Enddo
C SETON LR
%XFOOT(array-expression)
%XFOOT results in the sum of all elements of the specified numeric array expression.
The precision of the result is the minimum that can hold the result of adding together all array
elements, up to a maximum of 30 digits. The number of decimal places in the result is always the
same as the decimal places of the array expression.
For example, if ARR is an array of 500 elements of precision (17,4), the result of %XFOOT(ARR)
is (20,4).
For %XFOOT(X) where X has precision (m,n), the following table shows the precision of the result
based on the number of elements of X:
Elements of X Precision of %XFOOT(X)
1 (m,n)
2-10 (m+1,n)
11-100 (m+2,n)
101-1000 (m+3,n)
1001-10000 (m+4,n)
10001-32767 (m+5,n)
Normal rules for array expressions apply. For example, if ARR1 has 10 elements and ARR2 has
20 elements, %XFOOT(ARR1+ARR2) results in the sum of the first 10 elements of ARR1+ARR2.
Example4 : Example On %XFOOT
DNum S 4S 0 Inz(1)
DRes S 4S 0 Inz(0)
C Num DowLt 5
C Array1(Num) Dsply
C Enddo
C Eval Res = %XFOOT(Array1)
C Res DSPLY
C
C SETON LR
Example5 : Example on %XFOOT (Two Arrays)

DNum S 4S 0 Inz(1)
DRes S 4S 0 Inz(0)
C Num DowLt 5
C Eval Array2(Num) = Num * 10
C Enddo
C Eval Res = %XFOOT(Array1 + Array2)
C Res DSPLY
C
C SETON LR
* OUTPUT :110
Example6 : Example On SORTA (Descend/Ascend)
DArray1 S 4S 0 Dim(5) Descend

DNum S 4S 0 Inz(1)
C Num DowLt 5
C Enddo
C SortA Array1
C Eval Num = 1
C Num DowLt 5
C Array1(Num) Dsply
C Enddo
C
C SETON LR
%LOOKUPxx (Look Up an Array Element)
%LOOKUP(arg : array {: startindex {: numelems}})

%LOOKUPLT(arg : array {: startindex {: numelems}})
%LOOKUPGE(arg : array {: startindex {: numelems}})
%LOOKUPGT(arg : array {: startindex {: numelems}})
%LOOKUPLE(arg : array {: startindex {: numelems}})
The following functions return the array index of the item in array that matches arg as follows: |
%LOOKUP
An exact match.
%LOOKUPLT
The value that is closest to arg but less than |arg.
%LOOKUPLE
An exact match, or the value that is closest to arg but less than arg.
%LOOKUPGT
The value that is closest to arg but greater than |arg.
%LOOKUPGE
An exact match, or the value that is closest to arg but greater than arg. |
If no value matches the specified condition, zero is returned.
The search starts at index startindex and continues for numelems elements. By default, the entire
array is |searched. 10
Display Files
Edit Code - Help
Type an edit code to display numeric fields. The values of the edit codes
are as
follows:
Edit Code No CR -Sign -Sign
Description Sign Sign (R) (L)
Commas and zero balances 1 A J N
Commas 2 B K O
Zero balances 3 C L P
No commas or zero balances 4 D M Q
User-defined edit codes 5-9
Date edit (4 digits) W
Date edit Y
Suppress leading zeros Z
Replace Leading Zeros - Help
* Type * to specify that an asterisk should replace all leading zeros.

A zero-
balance field will contain a complete field of asterisks.
$ Type $ to specify that a currency symbol should appea to the left of
the first
significant digit. The symbol does not print on a zero-balance field
when yo
select an edit code that suppresses the zero-balance field.
Example:35 Calculate Simple Sinterest
UUUUUUUUUU TT:TT:TT
Simple Interest Calculation
DD/DD/DD
Enter Principal Amount: 33333.33
Enter Rate Of Interest: 33.33
Enter Time: 333-
Simple Interest is: 666.66
Amount is: 6666.66
F3=Exit
DDS for the above display file

A DSPSIZ(24 80 *DS3)
A R REC1
A CF03(03 'Exit')
A 2 2USER
A 4 2DATE
A EDTCDE(Y)
A 2 69TIME
A 3 27'Simple Interest Calculation'
A COLOR(WHT)
A 6 22'Enter Principal Amount:'
A 8 22'Enter Rate Of Interest:'
A 10 34'Enter Time:'
A 12 26'Simple Interest is:'
A 14 35'Amount is:'
A XPAMT 7Y 2B 6 48EDTWRD(' . ')
A 98 DSPATR(RI)
A 98 DSPATR(PC)
A XRINT 4Y 2B 8 48EDTWRD(' . ')
A 97 DSPATR(RI)
A 97 DSPATR(PC)
A XTIME 3S 0B 10 48
A 96 DSPATR(RI)
A 96 DSPATR(PC)
A XSINT 5Y 2O 12 48EDTWRD(' . ')
A XAMT 6Y 2O 14 48EDTWRD(' . ')
A 23 3'F3=Exit'
A COLOR(WHT)
RPG Program for the above display file

FILE016FM CF E WORKSTN
* Process Until User Hits F3
*
C DOW *IN03=*OFF
C EXFMT REC1
C MOVEA '0000' *IN(96)
C 03 LEAVE
C EXSR $$EDIT
C *IN99 IFEQ *OFF
C EVAL XSINT = (XPAMT * XRINT * XTIME)/100
C EVAL XAMT = XPAMT + XSINT
C ELSE
C ITER
C ENDIF
C ENDDO
C SETON LR
C*
C $$EDIT BEGSR
C XPAMT IFLE 0
C SETON 9899
C ENDIF
C*
C XRINT IFLE 0
C SETON 9799
C ENDIF
C*
C XTIME IFLE 0
C SETON 9699
C ENDIF
C ENDSR
Example 36: Handling Subroutine
UUUUUUUUUU TT:TT:TT
Handling Subroutines
DD/DD/DD
Enter First Nuber: 999- Enter Second Number: 999-
Action Level: B
A. Addtion
S. Subtraction
D. Division
M.Multiplication
R e s u l t I s : 6666
F3=Exit

A R REC1
A CF03(03 'Exit')
A 2 2USER
A 4 2DATE
A EDTCDE(Y)
A 2 69TIME
A 23 3'F3=Exit'
A COLOR(WHT)
A 3 31'Handling Subroutines'
A COLOR(WHT)
A DSPATR(UL)
A 6 14'Enter First Nuber:'
A XFNO 3S 0B 6 33
A 98 DSPATR(RI)
A 98 DSPATR(PC)
A 6 44'Enter Second Number:'
A XSNO 3S 0B 6 66
A 97 DSPATR(RI)
A 97 DSPATR(PC)
A 8 14'Action Level:'
A XACTL 1A B 8 29DSPATR(HI)
A 96 DSPATR(RI)
A 96 DSPATR(PC)
A 10 29'A. Addtion'
A 12 29'S. Subtraction'
A 14 29'D. Division'
A 16 29'M.Multiplication'
A 18 28'R e s u l t I s :'
A XRES 4S 0O 18 48
*
* Process Until User Hits F3
*
C DOW *IN03=*OFF
C EXFMT REC1
C MOVEA '0000' *IN(96)
C 03 LEAVE
C EXSR $$EDIT
C *IN99 IFEQ *OFF
C SELECT
C XACTL WHENEQ 'A'
C EXSR ADD
*
C XACTL WHENEQ 'S'
C EXSR SUB
*
C XACTL WHENEQ 'M'
C EXSR MUL
*
C XACTL WHENEQ 'D'
C EXSR DIV
*
C ENDSL
C ELSE
C ITER
C ENDIF
C ENDDO
C SETON LR
C*
C $$EDIT BEGSR
C XFNO IFLE 0
C SETON 9899
C ENDIF
C*
C XSNO IFLE 0
C SETON 9799
C ENDIF
C ENDSR
*
C ADD BEGSR
C EVAL XRES = XFNO + XSNO
C ENDSR
*
C SUB BEGSR
C EVAL XRES = XFNO - XSNO
C ENDSR
*
C MUL BEGSR
C EVAL XRES = XFNO * XSNO
C ENDSR
*
C DIV BEGSR
C EVAL XRES = XFNO / XSNO
C ENDSR
Example:On Read Operation
UUUUUUUUUU Student`s Information System TT:TT:TT
DD/DD/DD
Student No...... 666
Student Name.... OOOOOOOOOOOOOOOOOOOOOOOOO
Student Address. OOOOOOOOOOOOOOOOOOOOOOOOO
Course Name..... OOOOOOOOOOOOOOO
Course Fees..... 66666.66
F3 = Exit
A*%%TS SD 20070402 073126 ASF REL-V5R1M0 5722-WDS

A*%%EC
A R REC
A CF03(03 'Exit')
A 1 2USER
A 3 2DATE
A EDTCDE(Y)
A 1 72TIME
A 1 26'Student`s Information System'
A DSPATR(UL)
A DSPATR(HI)
A 6 21'Student No......'
A 8 21'Student Name....'
A 10 21'Student Address.'
A 12 21'Course Name.....'
A 14 21'Course Fees.....'
A XSTNO 3 0O 6 43
A XSTNAME 25 O 8 43
A XSTADR 25 O 10 43
A XSTCRSE 15 O 12 43
A XSTFEE 7 2O 14 43EDTWRD(' . ')
A 24 2'F3 = Exit'
A DSPATR(HI)
FSTMAST IF E DISK
C
C READ STMAST
C DOW NOT %EOF(STMAST)
C Z-ADD STNO XSTNO
C MOVEL STNAME XSTNAME
C MOVEL STADR XSTADR
C MOVEL STCRSE XSTCRSE
C Z-ADD STFEES XSTFEE
* ============
C EXFMT REC
* ============
C 03 LEAVE
C READ STMAST
C ENDDO
C SETON LR
Example:On ReadP Operation
FSTMAST IF E DISK
C
C
C *HIVAL SETGT STMAST
C READP STMAST
C DOW NOT %EOF(STMAST)
C Z-ADD STNO XSTNO
* ============
C EXFMT REC
* ============
C 03 LEAVE
C READP STMAST
C ENDDO
C SETON LR
Example:On Chain Operation

UUUUUUUUUU Student`s Information System TT:TT:TT
DD/DD/DD
Enter Student No. 999
Student Name..... OOOOOOOOOOOOOOOOOOOOOOOOO
Student Address.. OOOOOOOOOOOOOOOOOOOOOOOOO
Course Name...... OOOOOOOOOOOOOOO
Course Fees...... 66666.66
F3 = Exit

A*%%EC
A R REC
A CF03(03 'Exit')
A 1 2USER
A 3 2DATE
A EDTCDE(Y)
A 1 72TIME
A 1 26'Student`s Information System'
A DSPATR(UL)
A DSPATR(HI)
A 6 21'Enter Student No.'
A 8 21'Student Name.....'
A 10 21'Student Address..'
A 12 21'Course Name......'
A 14 21'Course Fees......'
A XSTNO 3Y 0B 6 43
A XSTNAME 25A O 8 43
A XSTADR 25A O 10 43
A XSTCRSE 15A O 12 43
A XSTFEE 7Y 2O 14 43EDTWRD(' . ')
A 24 2'F3 = Exit'
A DSPATR(HI)

FSTMAST IF E DISK
C DOW *IN03 = *OFF
C EXFMT REC
C 03 LEAVE
C XSTNO CHAIN STMAST
C IF %FOUND(STMAST)
C ELSE
C Z-ADD 0 XSTNO
C MOVE *BLANKS XSTNAME
C MOVE *BLANKS XSTADR
C MOVE *BLANKS XSTCRSE
C Z-ADD 0 XSTFEE
C ENDIF
C ENDDO
C SETON LR
Data structures
The ILE RPG compiler allows you to define an area in storage and the layout of the fields, called
subfields, within the area. This area in storage is called a data structure. You define a data
structure by specifying DS in positions 24 through 25 on a definition specification.
You can use a data structure to:
Define the same internal area multiple times using different data formats
Define a data structure and its subfields in the same way a record is defined.
Define multiple occurrences of a set of data.
Group non-contiguous data into contiguous internal storage locations.
Operate on all the subfields as a group using the name of the data structure.
Operate on an individual subfield using its name.
In addition, there are four special data structures, each with a specific purpose:
A data area data structure (identified by a U in position 23 of the definition specification)
A file information data structure (identified by the keyword INFDS on a file description
specification)
A program-status data structure (identified by an S in position 23 of the definition
specification)
An indicator data structure (identified by the keyword INDDS on a file description
specification).
Data structures can be either program-described or externally described, except for indicator data
structures, which are program-described only. |One data structure can be defined like another
using the LIKEDS |keyword.
A program-described data structure is identified by a blank in position 22 of the definition
specification. The subfield definitions for a program-described data structure must immediately
follow the data structure definition.
An externally described data structure, identified by an E in position 22 of the definition
specification, has subfield descriptions contained in an externally described file. At compile time,
the ILE RPG compiler uses the external name to locate and extract the external description of the
data structure subfields. You specify the name of the external file either in positions 7 through 21,
or as a parameter for the keyword EXTNAME.
Note:
The data formats specified for the subfields in the external description are used as the internal
formats of the subfields by the compiler. This differs from the way in which externally described
files are treated.
An external subfield name can be renamed in the program using the keyword EXTFLD. The
keyword PREFIX can be used to add a prefix to the external subfield names that have not been
renamed with EXTFLD. Note that the data structure subfields are not affected by the PREFIX
keyword specified on a file-description specification even if the file name is the same as the
parameter specified in the EXTNAME keyword when defining the data structure using an external
file name. Additional subfields can be added to an externally described data structure by
specifying program-described subfields immediately after the list of external subfields.
Special Data Structures

Special data structures include:
Data area data structures
File information data structures (INFDS)
Program-status data structures
Indicator data structures.
Note that the above data structures cannot be defined in subprocedures.
Data Area Data Structure
A data area data structure, identified by a U in position 23 of the definition specification, indicates
to the compiler that it should read in and lock the data area of the same name at program
initialization and should write out and unlock the same data area at the end of the program.
Locking does not apply to the local data area (see Local Data Area (*LDA)). Data area data
structures, as in all other data structures, have the type character. A data area read into a data
area data structure must also be character. The data area and data area data structure must have
the same name unless you rename the data area within the ILE RPG program by using the
*DTAARA DEFINE operation code or the DTAARA keyword.
You can specify the data area operations (IN, OUT, and UNLOCK) for a data area that is implicitly
read in and written out. Before you use a data area data structure with these operations, you must
specify that data area data structure name in the result field of the *DTAARA DEFINE operation or
with the DTAARA keyword.
A data area data structure cannot be specified in the result field of a PARM operation in the
*ENTRY PLIST.
Local Data Area (*LDA)
If you specify blanks for the data area data structure (positions 7 through 21 of the definition
specification that contains a U in position 23), the compiler uses the local data area. To provide a
name for the local data area, use the *DTAARA DEFINE operation, with *LDA in factor 2 and the
name in the result field or DTAARA(*LDA) on the definition specification.
File Information Data Structure
You can specify a file information data structure (defined by the keyword INFDS on a file
description specifications) for each file in the program. This provides you with status information
on the file exception/error that occurred. The file information data structure name must be unique
for each file. A file information data structure contains predefined subfields that provide
information on the file exception/error that occurred. For a discussion of file information data
structures and their subfields, see File Information Data Structure.
Program-Status Data Structure
A program-status data structure, identified by an S in position 23 of the definition specification,

provides program exception/error information to the program. For a discussion of program-status
data structures and their predefined subfields, see Program Status Data Structure.
Indicator Data Structure
An indicator data structure is identified by the keyword INDDS on the file description
specifications. It is used to store conditioning and response indicators passed to and from data
management for a file. By default, the indicator data structure is initialized to all zeros ('0's).
The rules for defining the data structure are:
It must not be externally described.
It can only have fields of indicator format.
It can be defined as a multiple occurrence data structure.
%SIZE for the data structure will return 99. For a multiple occurrence data structure,
%SIZE(ds:*ALL) will return a multiple of 99. If a length is specified, it must be 99.
Subfields may contain arrays of indicators as long as the total length does not exceed 99.
Table . Contents of the Program Status Data Structure
Program name 1 10 @@PGM

Status code 11 15 @@STS
Previous status code 16 20 @@PSTS
Source Statement # 21 28 @@SRC#
Name of rpg routine(*GETIN, *DET,etc..) 29 36 @@RTN
# of parameters passed to program 37 39 @@PARM
Error type(CPF, MCH) 40 42 @@ETYP
Error # 43 46 @@ERR#
Error message id cpfxxxx,mchxxxx 40 46 @@ERR
Mi/odt # 47 50 @@ODT
Work area for messages 51 80 @@WRKM
Library program is running out of 81 90 @@LIB
Retrieved exception data 91 170 @@DATA
Exception that caused RPG9001 message 171 174 @@9001
Unused 175 200 @@FIL1
Name of file last file op occured(only if error) 201 208 @@FILE
Status info on last file used 209 243 @@FINE
Job name 244 253 @@JOBN
User name from the user profile 254 263 @@USER
Job number 264 269 @@JOB#
Job entered system date 270 275 @@EDTE
System date 276 281 @@SDTE
System time 282 287 @@TIME
Compile date 288 293 @@CDTE
Compile time 294 299 @@CTME

Compile level 300 303 @@CLVL
Source file 304 313 @@SFLE

Source library 314 323 @@SLIB
Source member 324 333 @@SMBR
Unused 334 429 @@FIL2
From To
(Pos. (Pos.
26- 33-
32) 39) Format Length Keyword Information
1 10 Character 10 *PROC Name of the main procedure, if

there is one; otherwise, the name
associated with the main source
section.
11 15 Zoned 5,0 *STATUS Status code. For a description of
decimal these codes, see Program Status
Codes.
16 20 Zoned 5,0 Previous status code.
decimal
21 28 Character 8 RPG IV source listing line number
or statement number. The source
listing line number is replaced by
the source listing statement
number if OPTION(*SRCSTMT) is
specified instead of
OPTION(*NOSRCSTMT). The full
statement number is included when
it applies to the root source
member. If the statement number is
greater than 6 digits (that is, it
includes a source ID other than
zero), the first 2 positions of
the 8-byte feedback area will have
a "+ " indicating that the rest of
statement number is stored in
positions 354-355.
29 36 Character 8 *ROUTINE Name of the RPG IV routine in
which the exception or error
occurred. This subfield is updated
at the beginning of an RPG IV
routine or after a program call
only when the *STATUS subfield is
updated with a nonzero value. The
following names identify the
routines:
*INIT
Program initialization
*DETL
Detail lines
*GETIN
Get input record
*TOTC
Total calculations
*TOTL
Total lines
*DETC
Detail calculations
*OFL
Overflow lines
*TERM
Program ending
*ROUTINE
Name of program or procedure
called (first 8 characters).
Note:
*ROUTINE is not valid unless
you use the normal RPG IV
cycle. Logic that takes the
program out of the normal RPG
IV cycle may cause *ROUTINE to
reflect an incorrect value.
37 39 Zoned 3,0 *PARMS Number of parameters passed to

decimal this program from a calling
program. The value is the same as
that returned by %PARMS. If no
information is available, -1 is
returned.
40 42 Character 3 Exception type (CPF for a OS/400
system exception or MCH for a
machine exception).
43 46 Character 4 Exception number. For a CPF
exception, this field contains a
CPF message number. For a machine
exception, it contains a machine
exception number.
47 50 Character 4 Reserved
51 80 Character 30 Work area for messages. This area
is only meant for internal use by
the ILE RPG compiler. The
organization of information will
not always be consistent. It can
be displayed by the user.
81 90 Character 10 Name of library in which the
program is located.
91 170 Character 80 Retrieved exception data. CPF
messages are placed in this
subfield when location *STATUS
contains 09999.
171 174 Character 4 Identification of the exception
that caused RNX9001 exception to
be signaled.
175 184 Character 10 Name of file on which the last
file operation occurred (updated
only when an error occurs). This
information always contains the
full file name.
185 190 Character 6 Unused.
191 198 Character 8 Date (*DATE format) the job
entered the system. In the case of
batch jobs submitted for overnight
processing, those that run after
midnight will carry the next day's
date. This value is derived from
the job date, with the year
expanded to the full four years.
The date represented by this value
is the same date represented by
positions 270 - 275.
199 200 Zoned 2,0 First 2 digits of a 4-digit year.
decimal The same as the first 2 digits of
*YEAR. This field applies to the
century part of the date in
positions 270 to 275. For example,
for the date 1999-06-27, UDATE
would be 990627, and this century
field would be 19. The value in
this field in conjunction with the
value in positions 270 - 275 has
the combined information of the
value in positions 191 -198.
Note:
This century field does not
apply to the dates in
positions 276 to 281, or
positions 288 to 293.
201 208 Character 8 Name of file on which the last
file operation occurred (updated
only when an error occurs). This
file name will be truncated if a
long file name is used. See
positions 175-184 for long file
name information.
209 243 Character 35 Status information on the last
file used. This information
includes the status code, the RPG
IV opcode, the RPG IV routine
name, the source listing line
number or statement number, and
record name. It is updated only
when an error occurs.
Note:
The opcode name is in the same
form as *OPCODE in the INFDS
The source listing line number is

replaced by the source listing
statement number if
OPTION(*SRCSTMT) is specified
instead of OPTION(*NOSRCSTMT). The
full statement number is included
when it applies to the root source
member. If the statement number is
greater than 6 digits (that is, it
includes a source ID other than
zero), the first 2 positions of
the 8-byte feedback area will have
a "+ " indicating that the rest of
statement number is stored in
positions 356-357.
244 253 Character 10 Job name.
254 263 Character 10 User name from the user profile.
264 269 Zoned 6,0 Job number.
decimal
270 275 Zoned 6,0 Date (in UDATE format) the program
decimal started running in the system
(UDATE is derived from this date).
See User Date Special Words for a
description of UDATE. This is
commonly known as the 'job date'.
The date represented by this value
is the same date represented by
positions 191 - 198.
276 281 Zoned 6,0 Date of program running (the
decimal system date in UDATE format). If
the year part of this value is
between 40 and 99, the date is
between 1940 and 1999. Otherwise
the date is between 2000 and 2039.
The 'century' value in positions
199 - 200 does not apply to this
field.
282 287 Zoned 6,0 Time (in the format hhmmss) of the
decimal program running.
288 293 Character 6 Date (in UDATE format) the program
was compiled. If the year part of
this value is between 40 and 99,
the date is between 1940 and 1999.
Otherwise the date is between 2000
and 2039. The 'century' value in
positions 199 - 200 does not apply
to this field.
294 299 Character 6 Time (in the format hhmmss) the
program was compiled.
300 303 Character 4 Level of the compiler.
304 313 Character 10 Source file name.
314 323 Character 10 Source library name.
324 333 Character 10 Source file member name.
334 343 Character 10 Program containing procedure.
344 353 Character 10 Module containing procedure.
354 355 Binary 2 Source Id matching the statement
number from positions 21-28.
356 357 Binary 2 Source Id matching the statement
number from positions 228-235.
358 367 Character 10 Current user profile name.
Example 1:Program Status Data Structure

D SDS
DPgName 1 10
DUName 254 263
DDate 270 275
DTime 282 287
C PgName Dsply
C UName Dsply
C Date Dsply
C Time Dsply
C SETON LR
Example 2:Multiple Occurrence Data Structure
DBranch DS 6 Occurs(10)
DCode 1 2
DName 3 6
C 1 Occur Branch
C Movel '01' Code
C Movel 'Asif' Name
C 2 Occur Branch
C Movel '02' Code
C Movel 'Basha' Name
C 1 Occur Branch
C Code Dsply
C Name Dsply
C 2 Occur Branch
C Code Dsply
C Name Dsply
C Branch Dsply
C SETON LR
Example 3:Data Area Data Structure
DBranch UDS
DCode 1 2
DName 3 6
C Code Dsply
C Name Dsply
C SETON LR
Example 4:File Information Data Structure

FPF1 IF E DISK INFDS(INFDS1)
DINFDS1 DS
D FILE *FILE
D CODE *OPCODE
D STATUS *STATUS
D RECORD *RECORD
D ROUTINE *ROUTINE
C FILE DSPLY
C CODE DSPLY
C STATUS DSPLY
C RECORD DSPLY
C ROUTINE DSPLY
C SETON LR
C*OUTPUT
C* DSPLY PF1
C* DSPLY OPEN I
C* DSPLY 0
C* DSPLY
C* DSPLY *INIT
Prompt type . . . D Sequence number . . . 0004.30

Declaration To /
Name E S/U Type From Length
FILE _ _ __ *FILE
Internal Decimal
Data Type Positions Keywords
_ _ _________
Comment
____________
Example 5:Auto Increment with Data Area

* AUTO INCRIMENT
DDTA1 S 5S 0 DTAARA(INVOICE)
DTEMP S 5S 0
C *LOCK IN DTA1
C DTA1 DSPLY
C Z-ADD DTA1 TEMP
C EVAL TEMP = TEMP + 1
C Z-ADD TEMP DTA1
C OUT DTA1
C DTA1 DSPLY
C UNLOCK DTA1
C SETON LR
Data structure Examples From Manual
The following examples show various uses for data structures and how to define
them.
Example Description
Figure 1 Using a data structure to subdivide a field
Figure 2 Using a data structure to group fields
Figure 3 Data structure with absolute and length notation
Figure 4 Rename and initialize an externally described data
structure
Figure 5 Using PREFIX to rename all fields in an external
data structure
Figure 6 Defining a multiple occurrence data structure
Figure 7 Aligning data structure subfields
Figure 8 Defining a *LDA data area data structure
Figure 9 Using data area data structures (1)
Figure 10 Using data area data structures (2)
Figure 11 Using an indicator data structure
Figure 12 Using a multiple-occurrence indicator data
structure
Figure 1. Using a Data structure to subdivide a field

*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++
D.....................................Keywords+++++++++++++++++++++++++++++
*
* Use length notation to define the data structure subfields.
* You can refer to the entire data structure by using Partno, or by
* using the individual subfields Manufactr, Drug, Strength or Count.
*
D Partno DS
D Manufactr 4
D Drug 6
D Strength 3
D Count 3 0
D
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
IFilename++SqNORiPos1+NCCPos2+NCCPos3+NCC..................................
I........................Fmt+SPFrom+To+++DcField+++++++++L1M1FrPlMnZr......
*
* Records in program described file FILEIN contain a field, Partno,
* which needs to be subdivided for processing in this program.
* To achieve this, the field Partno is described as a data structure
* using the above Definition specification
*
IFILEIN NS 01 1 CA 2 CB
I 3 18 Partno
I 19 29 Name
I 30 40 Patno
Figure 2. Using a data structure to group fields
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

D.....................................Keywords+++++++++++++++++++++++++++++
*
* When you use a data structure to group fields, fields from
* non-adjacent locations on the input record can be made to occupy
* adjacent internal locations. The area can then be referred to by
* the data structure name or individual subfield name.
*
D Partkey DS
D Location 4
D Partno 8
D Type 4
D
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
IFilename++SqNORiPos1+NCCPos2+NCCPos3+NCC..................................
I........................Fmt+SPFrom+To+++DcField+++++++++L1M1FrPlMnZr......
*
* Fields from program described file TRANSACTN need to be
* compared to the field retrieved from an Item_Master file
*
ITRANSACTN NS 01 1 C1 2 C2
I 3 10 Partno
I 11 16 0Quantity
I 17 20 Type
I 21 21 Code
I 22 25 Location
I
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....
*
* Use the data structure name Partkey, to compare to the field
* Item_Nbr
*
C :
C Partkey IFEQ Item_Nbr 99
C :
C*
Figure 3. Data structure with absolute and length notation
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

D.....................................Keywords+++++++++++++++++++++++++++++
*
* Define a program described data structure called FRED
* The data structure is composed of 5 fields:
* 1. An array with element length 10 and dimension 70(Field1)
* 2. A field of length 30 (Field2)
* 3/4. Divide Field2 in 2 equal length fields (Field3 and Field4)
* 5. Define a binary field over the 3rd field
* Note the indentation to improve readability
*
*
* Absolute notation:
*
* The compiler will determine the array element length (Field1)
* by dividing the total length (700) by the dimension (70)
*
D FRED DS
D Field1 1 700 DIM(70)
D Field2 701 730
D Field3 701 715
D Field5 701 704B 2
D Field4 716 730
*
* Length notation:
*
* The OVERLAY keyword is used to subdivide Field2
*
D FRED DS
D Field1 10 DIM(70)
D Field2 30
D Field3 15 OVERLAY(Field2)
D Field5 4B 2 OVERLAY(Field3)
D Field4 15 OVERLAY(Field2:16)
Figure 4. Rename and initialize an externally described data structure
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

D.....................................Keywords+++++++++++++++++++++++++++++
*
* Define an externally described data structure with internal name
* FRED and external name EXTDS and rename field CUST to CUSTNAME
* Initialize CUSTNAME to 'GEORGE' and PRICE to 1234.89.
* Assign to subfield ITMARR the DIM keyword.
* The ITMARR subfield is defined in the external description as a
* 100 byte character field. This divides the 100 byte character
* field into 10 array elements, each 10 bytes long.
* Using the DIM keyword on an externally described numeric subfield
* should be done with caution, because it will divide the field into
* array elements (similar to the way it does when absolute notation
* is used for program described subfields).
*
D Fred E DS EXTNAME(EXTDS)
D CUSTNAME E EXTFLD(CUST) INZ('GEORGE')
D PRICE E INZ(1234.89)
D ITMARR E DIM(10)
Figure 5. Using PREFIX to rename all fields in an external data structure
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

D.....................................Keywords+++++++++++++++++++++++++++++
D
D extds1 E DS EXTNAME (CUSTDATA)
D PREFIX (CU_)
D Name E INZ ('Joe's Garage')
D Custnum E EXTFLD (NUMBER)
D
*
* The previous data structure will expand as follows:
* -- All externally described fields are included in the data
* structure
* -- Renamed subfields keep their new names
* -- Subfields that are not renamed are prefixed with the
* prefix string
*
* Expanded data structure:
*
D EXTDS1 E DS
D CU_NAME E 20A EXTFLD (NAME)
D INZ ('Joe's Garage')
D CU_ADDR E 50A EXTFLD (ADDR)
D CUSTNUM E 9S0 EXTFLD (NUMBER)
D CU_SALESMN E 7P0 EXTFLD (SALESMN)
Figure 6. Defining a multiple occurrence data structure
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

D.....................................Keywords+++++++++++++++++++++++++++++
*
* Define a Multiple Occurrence data structure of 20 elements with:
* -- 3 fields of character 20
* -- A 4th field of character 10 which overlaps the 2nd
* field starting at the second position.
*
* Named constant 'Max_Occur' is used to define the number of
* occurrences.
*
* Absolute notation (using begin/end positions)
*
D Max_Occur C CONST(20)
D
DDataStruct DS OCCURS (Max_Occur)
D field1 1 20
D field2 21 40
D field21 22 31
D field3 41 60
*
* Mixture of absolute and length notation
*
D DataStruct DS OCCURS(twenty)
D field1 20
D field2 20
D field21 22 31
D field3 41 60
Figure 7. Aligning Data Structure Subfields
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

* Data structure with alignment:
D MyDS DS ALIGN
* Properly aligned subfields
* Integer subfields using absolute notation.
D Subf1 33 34I 0
D Subf2 37 40I 0
* Integer subfields using length notation.
* Note that Subf3 will go directly after Subf2
* since positions 41-42 are on a 2-byte boundary.
* However, Subf4 must be placed in positions 45-48
* which is the next 4-byte boundary after 42.
D Subf3 5I 0
D Subf4 10I 0
* Integer subfields using OVERLAY.
D Group 101 120A
D Subf6 5I 0 OVERLAY (Group: 3)
D Subf7 10I 0 OVERLAY (Group: 5)
D Subf8 5U 0 OVERLAY (Group: 9)
* Subfields that are not properly aligned:
* Integer subfields using absolute notation:
D SubfX1 10 11I 0
D SubfX2 15 18I 0
* Integer subfields using OVERLAY:
D BadGroup 101 120A
D SubfX3 5I 0 OVERLAY (BadGroup: 2)
D SubfX4 10I 0 OVERLAY (BadGroup: 6)
D SubfX5 10U 0 OVERLAY (BadGroup: 11)
* Integer subfields using OVERLAY:
D WorseGroup 200 299A
D SubfX6 5I 0 OVERLAY (WorseGroup)
D SubfX7 10I 0 OVERLAY (WorseGroup: 3)
*
* The subfields receive warning messages for the following reasons:
* SubfX1 - end position (11) is not a multiple of 2 for a 2 byte field.
* SubfX2 - end position (18) is not a multiple of 4 for a 4 byte field.
* SubfX3 - end position (103) is not a multiple of 2.
Figure 8. Defining a *LDA data area data structure
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

D.....................................Keywords+++++++++++++++++++++++++++++
*
* Define a data area data structure based on the *LDA.
*
* Example 1:
* A data area data structure with no name is based on the *LDA.
* In this case, the DTAARA keyword does not have to be used.
*
D UDS
D SUBFLD 1 600A
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
* Example 2:
* This data structure is explicitly based on the *LDA using
* the DTAARA keyword. Since it is not a data area data
* structure, it must be handled using IN and OUT operations.
*
D LDA_DS DS DTAARA(*LDA)
D SUBFLD 1 600A
...
C IN LDA_DS
C OUT LDA_DS
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
* Example 3:
* This data structure is explicitly based on the *LDA using
* the DTAARA keyword. Since it is a data area data
* structure, it is read in during initialization and written
* out during termination. It can also be handled using IN
* and OUT operations, since the DTAARA keyword was used.
*
D LDA_DS UDS DTAARA(*LDA)
D SUBFLD 1 600A
...
C IN LDA_DS
C OUT LDA_DS
Figure 9. Using data area data structures (program 1)
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

HKeywords++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
H DFTNAME(Program1)
H
*
FFilename++IPEASF.....L.....A.Device+.Keywords+++++++++++++++++++++++++++
FSALESDTA IF E DISK
*
D.....................................Keywords+++++++++++++++++++++++++++++
*
* This program uses a data area data structure to accumulate
* a series of totals. The data area subfields are then added
* to fields from the file SALESDTA.
D Totals UDS
D Tot_amount 8 2
D Tot_gross 10 2
D Tot_net 10 2
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
CL0N01Factor1+++++++Opcode(E)+Factor2++++++++++++++++++++++++++++++++++++++
*
C :
C EVAL Tot_amount = Tot_amount + amount
C EVAL Tot_gross = Tot_gross + gross
C EVAL Tot_net = Tot_net + net
Figure 10. Using data area data structures (program 2)
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

HKeywords++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
H DFTNAME(Program2)
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
D.....................................Keywords+++++++++++++++++++++++++++++
*
* This program processes the totals accumulated in Program1.
* Program2 then uses the total in the subfields to do calculations.
*
D Totals UDS
D Tot_amount 8 2
D Tot_gross 10 2
D Tot_net 10 2
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8
*
C :
C EVAL *IN91 = (Amount2 <> Tot_amount)
C EVAL *IN92 = (Gross2 <> Tot_gross)
C EVAL *IN93 = (Net2 <> Tot_net)
C :
Figure 11. Using an indicator data structure
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

FFilename++IPEASFRLen+LKlen+AIDevice+.Keywords++++++++++++++++++++++++++
* Indicator data structure "DispInds" is associated to file "Disp".
FDisp CF E WORKSTN INDDS (DispInds)
D.....................................Keywords+++++++++++++++++++++++++++++
*
* This is the indicator data structure:
*
D DispInds DS
* Conditioning indicators for format "Query"
D ShowName 21 21N
* Response indicators for format "Query"
D Exit 3 3N
D Return 12 12N
D BlankNum 31 31N
* Conditioning indicators for format "DispSflCtl"
D SFLDSPCTL 41 41N
D SFLDSP 42 42N
D SFLEND 43 43N
D SFLCLR 44 44N
*
* Set indicators to display the subfile:
C EVAL SFLDSP = *ON
C EVAL SFLEND = *OFF
C EVAL SFLCLR = *OFF
C EXFMT DispSFLCTL
*
* Using indicator variables, we can write more readable programs:
C EXFMT Query
C IF Exit or Return
C RETURN
C ENDIF
Figure 12. Using a multiple-occurrence indicator data structure
*.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8

FFilename++IPEASFRLen+LKlen+AIDevice+.Keywords++++++++++++++++++++++++++
* Indicator data structure "ErrorInds" is associated to file "Disp".
FDisp CF E WORKSTN INDDS (ERRORINDS)
D.....................................Keywords+++++++++++++++++++++++++++++
D @NameOk C 0
D @NameNotFound C 1
D @NameNotValid C 2
D @NumErrors C 2
*
* Indicator data structure for ERRMSG:
*
D ERRORINDS DS OCCURS(@NumErrors)
* Indicators for ERRMSG:
D NotFound 1 1N
D NotValid 2 2N
*
* Indicators for QUERY:
D Exit 3 3N
D Refresh 5 5N
D Return 12 12N
*
* Prototype for GetName procedure (code not shown)
D GetName PR 10I 0
D Name 50A CONST
*
C DOU Exit or Return
C EXFMT QUERY
* Check the response indicators
C SELECT
C WHEN Exit or Return
C RETURN
C WHEN Refresh
C RESET QUERY
C ITER
C ENDSL
*
* Check the name
C EVAL RC = GetName(Name)
*
* If it is not valid, display an error message
C IF RC <> @NameOk
C RC OCCURS ErrorInds
C EXFMT ERRMSG
C ENDIF
C ENDDO
...
C *INZSR BEGSR
*
* Initialize the occurrences of the ErrorInds data structure
C @NameNotFound OCCUR ErrorInds
C EVAL NotFound = '1'
C @NameNotValid OCCUR ErrorInds
C EVAL NotValid = '1'
C ENDSR
Subfiles
Example :1 Load All
A R SFLREC SFL
A XNO 3S 0B 7 4
A XNAME 15A O 7 14
A XCRSE 10A O 7 34
A XFEES 5S 2B 7 52
A R CTLREC SFLCTL(SFLREC)
A CA03(03 'Exit')
A OVERLAY
A 30 SFLDSP
A SFLDSPCTL
A SFLSIZ(0006)
A SFLPAG(0005)
A 1 2DATE
A EDTCDE(Y)
A 1 72TIME
A 1 27'Students Information system'
A COLOR(WHT)
A 5 2'Student No'
A 5 15'Student Name'
A 5 32'Student Course'
A 5 50'Student Fee'
A R FOOTER
A 23 3'F3->EXIT'
A DSPATR(HI)
Rpg Program for the above sub file
All the bellow subfiles are in RPGIII
Declaration in RPGILE:
FSUB1 CF E WORKSTN SFILE(SFLREC:@rrn)
FSUB1 CF E WORKSTN
F @RRN KSFILE SFLREC
FPF1 IF E DISK
C WRITEFOOTER
C EXFMTCTLREC
C EXSR @CMD
C @CMD BEGSR
C *IN03 IFEQ *ON
C SETON LR
C RETRN
C ENDIF
C ENDSR
C @LOAD BEGSR
C READ STREC 50
C *IN50 DOWEQ*OFF
C MOVE STNO XNO
C MOVELSTNAME XNAME
C MOVELSTCRSE XCRSE
C MOVELSTFEES XFEES
C ADD 1 @RRN
C @RRN IFGT 9999
C LEAVE
C ENDIF
C WRITESFLREC
C READ STREC 50
C ENDDO
C @RRN IFGE 1
C SETON 30
C ENDIF
C ENDSR
C *INZSR BEGSR
C Z-ADD0 @RRN 40
C EXSR @LOAD
C ENDSR
Example :2 Expanding
A R SFLREC SFL
A XNO 3S 0B 7 4
A XNAME 15A O 7 14
A XCRSE 10A O 7 34
A XFEES 5S 2B 7 52
A CF03(03 'Exit')
A N99 ROLLUP(25)
A OVERLAY
A 30 SFLDSP
A SFLDSPCTL
A SFLSIZ(0006)
A SFLPAG(0005)
A 1 2DATE
A EDTCDE(Y)
A 1 72TIME
A COLOR(WHT)
A 5 2'Student No'
A 5 50'Student Fee'
A R FOOTER
A 23 3'F3->EXIT'
A DSPATR(HI)
FSUB2 CF E WORKSTN
FPF1 IF E DISK
C WRITEFOOTER
C EXFMTCTLREC
C EXSR @CMD
C @CMD BEGSR
C *IN03 IFEQ *ON
C SETON LR
C RETRN
C ENDIF
C *IN25 IFEQ *ON PAGE DOWN
C SETOF 25
C EXSR @LOAD
C ENDIF
C ENDSR
C @LOAD BEGSR
C DO 5
C READ STREC 99
C *IN99 IFEQ *ON
C LEAVE
C ENDIF
C MOVE STNO XNO
C MOVELSTNAME XNAME
C MOVELSTCRSE XCRSE
C MOVELSTFEES XFEES
C ADD 1 @RRN
C @RRN IFGT 9999
C LEAVE
C ENDIF
C WRITESFLREC
C ENDDO
C @RRN IFGT 0
C SETON 30
C ENDIF
C ENDSR
C *INZSR BEGSR
C Z-ADD0 @RRN 40
C EXSR @LOAD
C ENDSR
Example :3 Single Page Sub file
A R SFLREC SFL
A XSTNO 3 0B 6 13
A XNAME 15 B 6 24
A XCRSE 15 B 6 42
A XFEE 5 0B 6 64
A 50 SFLDSP
A 51 SFLDSPCTL
A 52 SFLCLR
A SFLSIZ(0004)
A SFLPAG(0004)
A PAGEUP(25 'UP')
A PAGEDOWN(26 'DN')
A 1 31'Single Page Subfile'
A COLOR(WHT)
A 4 10'Student No Student Name St-
A udent Course Course Fee'
A COLOR(WHT)
A R FOOTER
A CA03(03 'Exit')
A OVERLAY
A 23 3'F3 -> Exit'
A COLOR(WHT)
ileRpg Program for the above sub file
FDSP3 CF E WORKSTN SFILE(SFLREC:RRN)

FPF1 IF E DISK
DRecPtr S 5i 0 INZ(1)
DRRN S 5i 0 INZ(0)
*
C Exsr ClrSr
C Exsr LoadSr
C Dow *in03 = *Off
C Exsr DspSr
C Exsr UsrSr
C Enddo
C SETON LR
*
C CLRSR BEGSR
C Eval Rrn = 0
C SETON 52
C WRITE CTLREC
C SETOFF 52
C ENDSR
*
C LoadSr Begsr
C Exsr ClrSr
C RecPtr Setll Pf1 40
C If *in40 = *On
C Eval RecPtr = Recptr - 4
C Setoff 40
C RecPtr Setll Pf1 40
C Endif
C Read Pf1
C Do 4
C Z-add Stno Xstno
C Movel Stname Xname
C Movel Stcrse Xcrse
C Z-add Stfees Xfee
C Eval RRN = RRN + 1
C Write SflRec
C Read Pf1
C If %Eof
C Leave
C Endif
C EndDo
C Endsr
*
C DspSr BegSr
C Seton 50
C Seton 51
C Exfmt CtlRec
C Setoff 50
C Setoff 51
C EndSr
*
C UsrSr BegSr
* Page Up
C If *in25 = *on
C Setoff 25
C Eval RecPtr = RecPtr - 4
C If RecPtr < 1
C Eval RecPtr = 1
C Endif
C Exsr LoadSr
C Endif
* Page Down
C If *in26 = *on
C Setoff 26
C Eval RecPtr = RecPtr + 4
C Exsr LoadSr
C Endif
C EndSr
Example :3a Single Page Sub file
A R SFLREC SFL
A XNO 3S 0B 7 4
A XNAME 15A O 7 14
A XCRSE 10A O 7 34
A XFEES 5S 2B 7 52
A CF03(03 'Exit')
A N99 ROLLUP(25)
A N98 ROLLDOWN(26)
A 31 SFLCLR
A OVERLAY
A 30 SFLDSP
A SFLDSPCTL
A SFLSIZ(0005)
A SFLPAG(0005)
A 1 2DATE
A EDTCDE(Y)
A 1 72TIME
A COLOR(WHT)
A 5 2'Student No'
A 5 50'Student Fee'
A R FOOTER
A 23 3'F3->EXIT'
A DSPATR(HI)
FSUB3 CF E WORKSTN
FPF1 IF E K DISK
C WRITEFOOTER
C EXFMTCTLREC
C EXSR @CMD
C @CMD BEGSR
C *IN03 IFEQ *ON
C SETON LR
C RETRN
C ENDIF
C SETON 31
C WRITECTLREC
C SETOF 31
C Z-ADD0 @RRN
C SETOF 25
C SETOF 98
C EXSR @LOAD
C ENDIF
*
C SETON 31
C WRITECTLREC
C SETOF 31
C SETOF 26
C Z-ADD6 @DO 30
C ADD @RRN @DO
C *IN99 IFEQ '1'
C *HIVAL SETGTSTREC
C ENDIF
C DO @DO
C READPSTREC 26
C *IN26 IFEQ '1'
C SETON 98
C *LOVAL SETLLSTREC
C LEAVE
C ENDIF
C ENDDO
C Z-ADD0 @RRN
C EXSR @LOAD
C ENDIF
C ENDSR
C @LOAD BEGSR
C DO 5
C READ STREC 99
C *IN99 IFEQ *ON
C LEAVE
C ENDIF
C MOVE STNO XNO
C MOVELSTNAME XNAME
C MOVELSTCRSE XCRSE
C MOVELSTFEES XFEES
C ADD 1 @RRN
C @RRN IFGT 9999
C LEAVE
C ENDIF
C WRITESFLREC
C ENDDO
C @RRN IFGT 0
C SETON 30
C ENDIF
C ENDSR
C *INZSR BEGSR
C Z-ADD0 @RRN 40
C EXSR @LOAD
C ENDSR
Example : Update The file Which are modified in the subfile
UUUUUUUUUU Students Details - Update TT:TT:TT
DD/DD/DD
S.No Name Address Course Fees
999 BBBBBBBBBBBBBBB BBBBBBBBBBBBBBB BBBBBBBBBB 9999999

F2->Update F3->Exit
DDS for the above Screen

A R SFLREC SFL
A XSTNO 3Y 0B 6 6
A XSTNME 15A B 6 14
A XSTADR 15 B 6 34
A XSTCRS 10 B 6 54
A XSTFEE 7Y 0B 6 69
A SFLSIZ(0006)
A SFLPAG(0005)
A CF02(02 'Update')
A CF03(03 'Exit')
A OVERLAY
A 30 SFLDSP
A SFLDSPCTL
A 1 2USER
A 2 2DATE
A EDTCDE(Y)
A 1 72TIME
A 1 27'Students Details - Update
A DSPATR(HI)
A DSPATR(UL)
A 4 6'S.No'
A DSPATR(HI)
A 4 14'Name'
A DSPATR(HI)
A 4 34'Address'
A DSPATR(HI)
A 4 54'Course'
A DSPATR(HI)
A 4 69'Fees'
A DSPATR(HI)
A R FOOTER
A 23 24'F3->Exit'
A DSPATR(HI)
A 23 3'F2->Update'
A DSPATR(HI)
RPG for the above Screen
FASIFPF UF E K DISK
FSUB006FM CF E WORKSTN SFILE(SFLREC:@RRN)
D@RRN S 4P 0
C WRITE FOOTER
C DOW *IN03 = *OFF
C EXFMT CTLREC
C 03 LEAVE
C SETOFF 51
C READC SFLREC 51
C DOW *IN51 = *OFF
C XSTNO CHAIN ASIFPF 50
C IF *IN50 = *OFF AND *IN02=*ON
C Z-ADD XSTNO STNO
C MOVEL XSTNME STNME
C MOVEL XSTADR STADR
C MOVEL XSTCRS STCRS
C Z-ADD XSTNO STNO
C UPDATE STREC
C ENDIF
C READC SFLREC 51
C ENDDO
*
C ENDDO
C SETON LR
C
C *INZSR BEGSR
C EXSR $$LOAD
C ENDSR
*
C $$LOAD BEGSR
C READ ASIFPF 50
C DOW *IN50 = *OFF
C Z-ADD STNO XSTNO
C MOVEL STNME XSTNME
C MOVEL STCRS XSTCRS
C MOVEL STFEE XSTFEE
C ADD 1 @RRN
C IF @RRN>9999
C LEAVE
C ENDIF
C WRITE SFLREC
C READ ASIFPF 50
C ENDDO
C IF @RRN>=1
C SETON 30
C ENDIF
C ENDSR
Example : Update The file Which are modified and Option field must be 'Y'in the subfile
DD/DD/DD
Opt S.No Name Address Course Fees
B 999 BBBBBBBBBBBBBBB BBBBBBBBBBBBBBB BBBBBBBBBB 9999999

F2->Update F3->Exit

A R SFLREC SFL
A XSTNO 3Y 0B 6 9
A XSTNME 15A B 6 16
A XSTADR 15A B 6 36
A XSTCRS 10A B 6 56
A XSTFEE 7Y 0B 6 71
A XOPT 1 B 6 4
A SFLSIZ(0006)
A SFLPAG(0005)
A CF02(02 'Update')
A CF03(03 'Exit')
A OVERLAY
A 30 SFLDSP
A SFLDSPCTL
A 1 2USER
A 2 2DATE
A EDTCDE(Y)
A 1 72TIME
A DSPATR(HI)
A DSPATR(UL)
A 4 9'S.No'
A DSPATR(HI)
A 4 16'Name'
A DSPATR(HI)
A 4 36'Address'
A DSPATR(HI)
A 4 56'Course'
A DSPATR(HI)
A 4 71'Fees'
A DSPATR(HI)
A 4 3'Opt'
A DSPATR(HI)
A R FOOTER
A 23 24'F3->Exit'
A DSPATR(HI)
A 23 3'F2->Update'
A DSPATR(HI)
FASIFPF UF E K DISK
D@RRN S 4P 0
C WRITE FOOTER
C DOW *IN03 = *OFF
C EXFMT CTLREC
C 03 LEAVE
C SETOFF 51
C READC SFLREC 51
C DOW *IN51 = *OFF
C IF *IN50 = *OFF AND *IN02=*ON AND XOPT='Y'
C Z-ADD XSTNO STNO
C Z-ADD XSTNO STNO
C UPDATE STREC
C ENDIF
C READC SFLREC 51
C ENDDO
*
C ENDDO
C SETON LR
C
C *INZSR BEGSR
C EXSR $$LOAD
C ENDSR
*
C $$LOAD BEGSR
C READ ASIFPF 50
C DOW *IN50 = *OFF
C Z-ADD STNO XSTNO
C ADD 1 @RRN
C IF @RRN>9999
C LEAVE
C ENDIF
C WRITE SFLREC
C READ ASIFPF 50
C ENDDO
C IF @RRN>=1
C SETON 30
C ENDIF
C ENDSR
Example : Update The file Which are modified and Option field must be 'Y'in the subfile and
with Validations

DD/DD/DD
Opt S.No Name Address Course Fees

F2->Update F3->Exit

A R SFLREC SFL
A XSTNO 3Y 0B 6 9
A XSTNME 15A B 6 16
A 97 DSPATR(RI)
A 97 DSPATR(PC)
A XSTADR 15A B 6 36
A XSTCRS 10A B 6 56
A XSTFEE 7Y 0B 6 71
A XOPT 1A B 6 4
A SFLSIZ(0006)
A SFLPAG(0005)
A CF02(02 'Update')
A CF03(03 'Exit')
A OVERLAY
A 30 SFLDSP
A SFLDSPCTL
A 1 2USER
A 2 2DATE
A EDTCDE(Y)
A 1 72TIME
A DSPATR(HI)
A DSPATR(UL)
A 4 9'S.No'
A DSPATR(HI)
A 4 16'Name'
A DSPATR(HI)
A 4 36'Address'
A DSPATR(HI)
A 4 56'Course'
A DSPATR(HI)
A 4 71'Fees'
A DSPATR(HI)
A 4 3'Opt'
A DSPATR(HI)
A R FOOTER
A 23 24'F3->Exit'
A DSPATR(HI)
A 23 3'F2->Update'
A DSPATR(HI)
FASIFPF UF E K DISK
D@RRN S 4P 0
C WRITE FOOTER
C DOW *IN03 = *OFF
C EXFMT CTLREC
C 03 LEAVE
C SETOFF 51
C READC SFLREC 51
C DOW *IN51 = *OFF
C EXSR $$EDIT
C UPDATE SFLREC
C IF *IN50 = *OFF
C AND *IN02 = *ON
C AND *IN99 = *OFF
C AND XOPT = 'Y'
C Z-ADD XSTNO STNO
C Z-ADD XSTNO STNO
C UPDATE STREC
C ENDIF
C READC SFLREC 51
C ENDDO
*
C ENDDO
C SETON LR
C
C *INZSR BEGSR
C EXSR $$LOAD
C ENDSR
*
C $$LOAD BEGSR
C READ ASIFPF 50
C DOW *IN50 = *OFF
C Z-ADD STNO XSTNO
C ADD 1 @RRN
C IF @RRN>9999
C LEAVE
C ENDIF
C WRITE SFLREC
C READ ASIFPF 50
C ENDDO
C IF @RRN>=1
C SETON 30
C ENDIF
C ENDSR
*
C $$EDIT BEGSR
C IF XSTNME = *BLANKS
C SETON 9799
C ELSE
C SETOFF 97
C ENDIF
C ENDSR

AS-400 All in One

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

AS-400 All in One

Caricato da

Copyright:

Formati disponibili

AS/400 System Overview Chapter 1

Major Characteristics of AS/400

AS/400 Advanced Series

AS/400e Series and e-business Solutions

AS/400 1 Venkat BAS

An object-oriented approach is fundamental to the system architecture of the AS/400. On

Relational and Integrated Database

Data and Program Independence

AS/400 2 Venkat BAS

Systems Application Architecture (SAA) Conformance

Systems Application Architecture (SAA) is a blueprint published by IBM to provide open

AS/400 3 Venkat BAS

Domino Groupware Enabling

AS/400 4 Venkat BAS

e-businesss Solutions and Net Generation

AS/400 5 Venkat BAS

Year 2000 Ready Solutions

The Integrated Operating System: OS/400

AS/400 6 Venkat BAS

Javas Integration into the AS/400 System

AS/400 7 Venkat BAS

AS/400 Advanced Series

A Full Range of Product Lines

Advanced Server Models

Major Traits of the AS/400 System Units

AS/400 8 Venkat BAS

e-Commerce and e-Business Solutions

Programming Development Manager Chapter 2

. Work with libraries

. Source entry utility (SEU)

Objects, Libraries, Files, and Members in the AS/400 System

AS/400 9 Venkat BAS

Starting the Programming Development Manager

Starting PDM from the AS/400 Main Menu

To start PDM from the AS/400 Main Menu:

AS/400 10 Venkat BAS

Starting PDM by Using the WRKLIBPDM Command

Starting PDM by Using the WRKOBJPDM Command

Starting PDM by Using the WRKMBRPDM Command

Working with Libraries

AS/400 11 Venkat BAS

Differences between a Library List and a List of Libraries

Viewing a Library List

To view a library list:

Viewing a List of Libraries

To view a list of libraries:

AS/400 12 Venkat BAS

AS/400 13 Venkat BAS

Working with Objects in a Library

Displaying the Description of a Library

Adding a Library to a Library List

Sample User-Defined Options

The following sample user-defined options are shipped with PDM:

Option Name Command Called Explanation

C CALL &O/&N Allows you to run a program on the Work with

CC CHGCURLIB CURLIB(&L) Changes the library on the Work with Objects

CD STRDFU OPTION(2) Allows you to create a DFU program.

CL CHGCURLIB CURLIB(&N) Changes selected library on the Work with

AS/400 14 Venkat BAS

CS STRSDA OPTION(1) SRCFILE(&L/&F)??SRCMBR()

DM DSPMSG Allows you to display messages.

The relationships between the various objects

AS/400 15 Venkat BAS